Рубрика «управление качеством»

Продолжаем тему управления качеством, начало здесь.

Что такое качество – допустим, разобрались, это степень соответствия требованиям потребителя. Вы, возможно, не согласны, по крайней мере с моей категоричностью, но вроде явных ляпов в этом определении нет.

Определение — понятно, но для управления качеством этого недостаточно. Это какая-то базовая, фундаментальная ценность, цель системы, а не руководство к действию. Что делать-то надо?

На что направить свои усилия, чтобы повысить качество? И качество чего надо повысить? Все слышали, что есть качество продукта, а есть – качество процесса. В чем разница? Что важнее?

А может, усилия надо направить на требования потребителя? Оставить качество на месте, а потребителя убедить, что его требования не обоснованы, и ему совсем другое нужно – не то, что он просит. Например, убедить покупателя, что колбаса из курицы – лучше, чем колбаса из мяса. Несложно ведь? Курица – диетическая, жира меньше, легче усваивается, да и стоит дешевле. Если убедить в этом покупателей, то они изменят свои требования, и качество продукта резко возрастет.

Это что такое получится? Управление качеством? В конечном итоге – да, но путь немного странный. Мы не качеством управлять будем, а требованиями. Есть вроде такая область знаний – управление требованиями? В ИТ, в частности. Хотя, если посмотреть телевизор, там только и занимаются, что управлением требованиями – кажется, это «пропагандой» называется.

Попробую рассказать то, что я успел узнать за свою жизнь про «нормальное» управление качеством.Читать полностью »

Когда собирали доклады на голосование для участия в одной специализированной конференции, я хотел рассказать такую тему – как подсидеть директора по качеству. Это был бы конъюнктурный доклад про карьерный рост для программиста или ИТ-директора.

С одной стороны, рост в сторону директора по качеству кажется странным – это вроде совсем другая область. Но, как мы все уже знаем, из программиста может вырасти дофига чего интересного. Это не только я говорю – такая мысль звучит все чаще. Например, на той же конференции другого года был доклад на эту тему — как на западе ИТ-директора уходят в операционный менеджмент, не связанный с ИТ.

Тема управления качеством лично мне кажется невероятно, просто ужасно интересной и безумно полезной. Не потому, что управление качеством – как новый сезон Шерлока или тряхнувшего стариной Джека Бауэра. Просто управление качеством в нашей стране – это пример исключительно наглого, циничного, элементарного, тупейшего, и оттого удивительно эффективного шарлатанства.

Я не знаю ни одной другой отрасли знаний, в которой трудилось бы такое же количество людей, ничего не понимающих в своей профессии. Это не шутка, не гипербола. Я наблюдаю за этими ребятами больше 15 лет — еще с тех пор, когда сертификат ISO еще был престижной редкостью. Я работал с директорами по качеству и специалистами, консультантами и аудиторами, преподавателями ВУЗов и президентами ассоциаций, студентами и аспирантами. Сколько из них, по-вашему, знают и понимают, что такое управление качеством и как его осуществлять? А, вы же знаете, я выше написал – ноль. Ладно, пусть будет 1 % — наверняка где-то, случайно, или волею небес, есть люди, которые что-то понимают. Ну и вы, если внимательно и без предубеждения отнесетесь к управлению качеством, тоже будете понимать. Так, может, и до 2% дотянем.Читать полностью »

10 заповедей безопасности полётов, которые могли бы пригодиться любой организации - 1
Designed by fanjianhua / Freepik

В статье «Как авиакатастрофа может улучшить разбор факапов в ИТ» автор поднял интересную тему методов и средств организации безопасности полётов. В частности были перечислены принципы solution without blame, SWOB («решение без обвинений»). В дополнение к этой статье я хотел бы привести отрывок из книги профессора И.С. Шумилова «Авиационные происшествия. Причины возникновения и возможности предотвращения», в котором автор ссылается на т.н. «10 заповедей безопасности полётов» и комментирует каждую из них.
Под катом цитата из книги.
Читать полностью »

Вечером 16 августа 1987 года из аэропорта Детройта вылетел рейс 255 компании Northwest Airlines. Он разбился спустя минуту, и в катастрофе погибли 156 человек. Вроде бы очевидная ошибка пилотов привела к исследованиям с участием NASA, изменениям конструкции самолетов и полетных процедур. А еще эта история имеет отношение к управлению качеством, управлению проектами и к вопросу вины и наказания не только сборщиков потерпевшего аварию «Союза МС-10», но и людей, совершивших ошибки на вашей работе.

Как авиакатастрофа может улучшить разбор факапов в ИТ - 1
Фото с места аварии из Бюро архивов авиационных инцидентов
Читать полностью »

Предисловие

«У нас брака нет!» именно с этой фразы начинается общение почти с каждым директором по качеству на производственных предприятиях в России. Многие из них даже будут уверять, что добились качества мирового уровня в виде 3,4 бракованных изделий на 1 000 000 произведенных. Да и в целом на всех профильных форумах и конференциях мы слышим, что в России лучшее качество в мире, а все остальные страны нам завидуют.

Обычно за этими громкими лозунгами скрываются огромные потери от внутреннего брака, раздутый штат контролеров, сокрытие дефектов, отсутствие автоматизации и еще множество проблем, которые сказываются в итоге на потребителях и акционерах.

Во времена СССР качество достигалось за счет полного и непрекословного соблюдения всевозможных ГОСТов. Но, к сожалению, в наших реалиях соблюдение ГОСТов не является приоритетным требованием, а главная цель любого производства — сделать все быстрее и дешевле. Исходя из этого тезиса у нас активно внедряются методы оптимизации в виде инструментов Lean и сокращается персонал при увеличении объемов производства.Читать полностью »

Стоимость качества в разработке программного обеспечения - 1

  1. Что такое качество в разработке ПО?
  2. Во сколько нам обходится некачественное ПО?
  3. Кто отвечает за качество?

Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.

Ниже результаты моих теоретических и практических исследований в поисках ответов. Постарался изложить их просто, без «мозговзрыва» присущего этой теме.
Читать полностью »

Мы уже три года делаем сервис «Кнопка». У нас отличные сотрудники, клёвый офис, приятные клиенты, милый кот и неплохая маржинальность. Нет, правда, мы привыкли думать, что мы молодцы. Недавно нам пришлось поменять эту привычку и научиться жить совсем в другом мире: где мы регулярно ошибаемся и на этих ошибках нужно учиться.

image
Читать полностью »

Вступление

Эта статья ориентирована на тех, у кого есть SharePoint и кто не знает, что с ним делать. :)

Много везде говорят о бизнес-процессе, но мало кто подразумевает под этим действительно процессный подход, скорее представляют себе некоторый черный ящик, где, в лучшем случае, есть вход и выход, иногда даже структурированный – определено, что имеем на входе и на выходе. Фактически, если в ящике за процесс отвечают более двух человек — легкий хаос вам обеспечен, а с ростом количества вовлеченных обеспечен и экспоненциальный рост энтропии. :)

Процесс в управлении организацией — это совокупность действий, повторяемых во времени, с конкретным началом и концом, целью которых является создание ценности для внешних и внутренних клиентов. По сути – преобразование ресурсов на входе в продукт на выходе, продукт может быть любым – как материальным, так и неосязаемым знанием. Преобразование в ящике может быть предельно простым, не требующим декомпозиции, а может быть очень сложным, вовлекающим в работу много сотрудников и времени, имеющим множество условий и зависимостей. Вопрос уровня декомпозиции процесса лежит в плоскости рациональности, целесообразности и здравого смысла, мне нравится методологический принцип «Бритва Оккама», который гласит, что «Не следует привлекать новые сущности без крайней на то необходимости», там, где можно обойтись без формализации действия — формализовывать действие не стоит. :)
Читать полностью »

Продолжаем нашу серию заметок по статическому анализатору кода Kiuwan.

Данный класс инструментов исследует текст программ на предмет выявления в них каких-то известных шаблонов уязвимостей, ошибок, неточностей, неэффективных действий и многого другого. Откуда берутся эти шаблоны, мы писали в прошлый раз. Для каждого языка программирования эти шаблоны будут свои в силу понятных отличий в синтаксисе, но будут и общие правила качественного кода, типа избегать использования повторяющихся блоков кода.

Однако, не всегда этих шаблонов и правил хватает для оценки определенных качеств написанной программы. В каждом конкретном случае может понадобиться свой определяющий параметр. Например, нам важно убедиться, нет ли в написанной банковской программе скрытых транзакций копеечек на чей-нибудь счет. Или проверить, что не используются никакие недопустимые внешние библиотеки. В этом случае, нам просто необходимо иметь возможность заставить анализатор проверять не только штатные шаблоны, но и наши дополнительные правила.

Написание кастомных правил для анализатора кода Kiuwan - 1
Читать полностью »

Анализируй это или о качестве программного обеспечения - 1 Почти всю свою сознательную карьеру разработчика, руководителя проектов, консультанта по процессам разработки я оставался в плену очень распространенного и простого заблуждения. Если программа выполняет требуемые функции, претензий к стабильности и производительности нет, то это «нормальная» программа. Прошу прощения за несколько утрированную формулировку, но так оно и есть, если разобраться.

За определениями термина «качество программного обеспечения» не грех обратиться к стандартам. Несколько определений из разных стандартов удобно приведены на одной странице wiki. И что же?! В фокусе способности программы удовлетворять потребностям Заказчика.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js