Наверх ▲

Про СУК. Разговоры двух мужчин среднего возраста не только о бабах

Денис Бугров Денис Бугров Директор в QuattroLab. Денис Самосеев Денис Самосеев Microsoft Consulting Services, Microsoft Russia, Project manager

Денис Самосеев: Я представлю Дениса Геннадьевича Бугрова, который на текущий момент является владельцем собственного бизнеса, небольшой компанией, которая специализируется на программном обеспечении в области медицины, в области лабораторных исследований.

Денис Бугров: Не только лабораторных – но, в общем, да.

Денис Самосеев: Познакомились мы очень давно, в очень веселой организации под названием ФГУП «Почта России», куда пришли вместе (если я правильно помню) в 2002-м или в 2003-м году. Там одной из задач, которая нами в том числе решалась, была задача разработки и внедрения системы менеджмента качества на основе стандартов ISO 9000, 9001:2000.

Денис Бугров: В общем, с тех пор мы в этом, так или иначе.

Денис Самосеев: Да. Но ФГУП «Почта России» – печально известная организация низким уровнем качества оказания услуг. Мы были призваны разрешить эти проблемы с помощью построения системы менеджмента качества. В 2005-м году (если я опять же правильно помню) мы оба покинули эту организацию. 

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

С тех времен прошло 8 лет – с момента начала работы по проекту внедрения подобной системы – а воз и ныне там. «Почта России» как работала безобразно, как доставляется у нас почта из Москвы до Санкт-Петербурга за месяц – так она и работает.

Денис Бугров: Ладно, «лирическое вступление» можно закончить. Мой друг и коллега Денис Самосеев – PJM в очень крупной мировой корпорации.

Денис Самосеев: PJM – project manager. Аббревиатура не очень известная. 

Денис Бугров: Предыстория такого провокационного названия. На самом деле все очень просто. Я пришел в одну из организаций – в достаточно крупную консалтинговую компанию – возглавить службу качества. Называлась она почему-то не просто «Служба качества», а «Служба управления качеством». 

Там были замечательные девочки, которые проводили внутренний аудит: бегали и всех доставали. Проверяли, насколько хорошо и правильно все делается. Насколько это соответствует тому, что прописано (методикам и так далее). Замеряли какие-то показатели. Писали, грубо говоря, кляузы (с точки зрения народа). 

Система Управления Качеством – СУК. …И девочки получили точно такое же прозвище.

Стоит отметить, что когда я пришел туда, должность в народе у меня так и называлась… 

Денис Самосеев: Командир СУК.

Денис Бугров: Да. Оттуда это название и пошло, собственно. В дальнейшем все это переименовали. Но, как говорят, «ложечки нашлись, а осадок остался».

Ладно, о чем мы хотели поговорить. 

Когда мы говорим о качестве на производстве – все достаточно просто. Когда мы говорим о качестве проектов – ситуация немного меняется. 

  • Как управлять качеством проекта. 
  • Можно ли это делать. 
  • Какие процедуры для этого есть. 
  • Что вам уже известно, что, может быть, вам еще неизвестно. 
  • Стоит ли вообще это делать. 
  • Насколько целесообразны те или иные мероприятия. 

Об этом мы и хотим поговорить.

Денис Самосеев: Пока решаем технические проблемы (идет настройка смены слайдов) я потравлю байки… Но уже более близко к теме. 

Тут стоит подразделять: система менеджмента качества существует как минимум двух видов. 

oПервый. 

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

oВторой тип систем управления качеством в организациях проектного типа. 

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

Все, отдаю слово Денису.

Денис Бугров: Вот о чем мы будем говорить. Такие красивые плакаты выпускает Международная ассоциация качества. Все это рекламируется на уровне лозунгов и так далее. В презентации будут такие плакаты: можете на них тоже посматривать.

Прежде чем говорить о том или ином управлении качеством, давайте определимся: зачем это нужно, и о чем мы будем говорить. Термины, которые лежат в основе управления качеством.

Денис Самосеев: Стоит сказать, зачем управлять качеством. Тут несколько моментов. Существует мнение, что высококачественный продукт, который вышел на рынок, – это продукт успешный. В первую очередь, успешный с точки зрения продаж. 

Конечно же, это не так. Иначе бы не покупалась продукция завода «ВАЗ», а покупалась бы только продукция завода “BMW” или “Ferrari”. Потому что у “BMW” или “Ferrari”, безусловно, более качественные продукты по сравнению с продуктами «ВАЗ».

По нашему мнению, успешный продукт – это тот продукт, который наиболее соответствует показателю «Цена по отношению к качеству». 

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

Пара моментов для дополнительной мотивации. Как мы уже говорили вначале, так получилось, что управлением качеством при реализации проектов в России мало кто занимается. 

Занимаются некими интерпретациями либо подобиями управления качеством. Например, подсчетом того, сколько строк кода было накодировано. Либо подсчетом количества выловленных багов. Либо количеством проведенных тест-кейсов. Все это переносят на показатели качества, говоря: «Выловив 50 багов в очередном build’е какой-то системы, мы сегодня провели ряд процедур по управлению качеством».

Конечно, количественные показатели (что строки кода, что количество багов) ни разу не говорят о качестве самого продукта.

О терминах. 

Сразу стоит сказать, что существует десяток широко известных стандартов по управлению качеством. Хорошо известны ISO в группе 9000: 9001, 9004. Это различные «Шесть сигм», TQA (мы дальше расскажем).

Существует несколько сотен отраслевых стандартов (в медицине, в геологоразведке, в нефтеразработке), которые также регламентируют то, что касается качества получаемого итогового результата. Каждый из этих стандартов имеет свои термины: что такое качество, как им можно управлять, как строить систему.

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

Хотелось бы подчеркнуть один из самых главных моментов. По нашему мнению, качество – это степень соответствия того, что мы запланировали в настоящем, тому, что ожидает от нас в будущем заказчик. Это очень важно как с точки зрения получения будущих метрик, так и просто укладывания кирпичиков в голове в отношении того, что строится, что необходимо построить, чтобы мы могли управлять качеством.

Денис Бугров: Немного скажем о стандартах. Про ISO все слышали? Постоянно везде читаем надписи: «Соответствует ISO», «Сертифицировано по ISO» и так далее. На самом деле (в рамках России) – это бред Я ни разу не видел в России компанию, реально работающую по ISO. Где-то даже пытался внедрять. Приходил на уже внедренную систему – не работает. 

Неправда это все.

Официально декларируется вот так (указывает на слайд): все красиво, куча плюсов. Прозрачность процессов. Контролируемость. Измеряемость. Улучшение непрерывное, постоянное, тотальное. Корректирующие и предупреждающие воздействия и так далее. Все это огромные плюсы. 

На самом деле – ни фига это не так. Это не плюсы – это минусы. Декларируется столько минусов, сколько здесь названо. На самом деле все плюсы точно так же являются минусами.

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

Что дальше. Измеряем. Что измеряем, зачем измеряем?.. В большинстве случаев все показатели, которые меряются, притянуты за уши. Ничего общего они не имеют с качеством. Если имеют, то весьма опосредованно. Лучше не мерить, не тратить на это время, деньги и так далее.

Может быть, кто-то слышал или не слышал: так называемая BSC или KPI. О ней вы слышите постоянно, она также упоминается в этом ISO. Что это такое.

Денис Самосеев: Я попробую продемонстрировать из нашего собственного опыта то, о чем говорит Денис. Та самая «Почта России», в которой внедрялась система менеджмента качества по стандартам ISO. Когда мы туда пришли, внешним разработчиком этой системы выступала хорошая, богатая консалтинговая компания, которая набрала кучу консультантов. Их первой задачей было описать бизнес организации на уровне «как есть». Создать карту всех бизнес-процессов организации. Этот процесс затянулся.

Денис Бугров: Поэтому останавливаться на принципах Деминга, на циклах Деминга и так далее смысла нет. Я повесил старую баянистую картинку. Как должно быть по классическому циклу Деминга и как оно по факту обычно выглядит. Кто еще не видел – можете посмотреть. Я думаю, что большинство уже видело.

Если вы посмотрите на классический цикл, он очень близок к тем итерационным моделям, которые происходят, которые есть в методологиях. В принципе, «уши» всех этих подходов оттуда и растут. Так или иначе эти методологии пытаются учинять, чтобы применять их к проектному управлению.

Еще одна достаточно известная методология управления качеством, подход к управлению качеством – «Шесть Сигм». 

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

Но для проектов он тоже не подходит никоим разом. Он нам ничего не даст. Нужна статистика, которая постоянно могла бы собираться. Мы не можем ее собирать. Проект постоянно меняется, все проекты разные. У нас не будет реальных показателей.

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

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

Нужно постоянство, нужны одинаковые процедуры. Фактически нужен процесс, а этого процесса нет. Проект – это проект. Процесс – это отдельно.

Все это красиво, когда вы приходите и говорите заказчику: «Мы ISO – вот красивая бумажка». Где мы висели(?), нам выдавали такие бумажки. Я даже не помню, куда ее положил. Больше ни разу и не доставал: нечем гордиться, собственно говоря.

Что же интересно в этом плане заказчику. 

Забота о качестве, внимание к себе любимому – это прекрасно. Вовлечение заказчика. Мы постоянно говорим об этом не только в отношении качества, но и в отношении любого проекта. Это тоже замечательно, заказчик от этого «прется». Когда вы на этапе обсуждения проекта говорите «о, мы тебя будем привлекать к контролю наших процедур, чтобы постоянно убеждался» и так далее – заказчик «прется». Хлопает в ладоши, дергает ножками и так далее. Радуется и пускает слюни.

Когда вы говорите, что у вас все зарегламентировано, уделяется огромное внимание к деталям, ни одна фичечка не пропадет, не потеряется – это тоже замечательно. Вообще заказчик любит слово «качество», а забота о качестве для него прекрасно. 

Это все обычно хорошо до одного маленького момента – до подписания контракта.

Как только вы подписали контракт – все, не хочет заказчик ничего делать. Он не хочет, чтобы вы его отвлекали. Ему нафиг это не надо. Внимание к нему в этот момент перестает быть ему нужным. Все, он вам отдал деньги – он хочет получить результат, и больше он ничего не хочет. 

Он не хочет вникать в суть того, как вы работаете. Бесполезно пытаться его привлекать к каким-то процедурам качества. Бесполезно писать для него тонны бумажек по качеству. Я с этим сталкивался. Денис тоже подтвердит, что достаточно часто на проекте приходиться писать некие документы (они по-разному называются), некие процедуры обеспечения качества на проекте. 

Опять же. Пока мы написали бумажку красивую – все замечательно. Как только это нужно читать и реализовывать – заказчику этого не хочется. Не любит он этого делать. Всем красивым словам «качество-качество-качество» он будет радоваться ровно до тех пор, пока вы в контракте не выставите за это цену отдельно. Как только вы поставите отдельную сумму, что обеспечение качества стоит столько-то – он забудет о качестве. 

Денис Самосеев: Я добавлю к тому, что сказал Денис. Классическая процедура управления качеством, которая описана в PM блоке, стандартами по управлению проектами, подразумевает создание ряда регламентирующих документов. Как на старте работ по проекту (например, план по управлению качеством), так и ряда других документов (например, план по управлению коммуникациями). В этих документах добросовестный проджект-менеджер, либо архитектор, либо тимлид описывают очень важные и правильные вещи (если это хороший тимлид или проджект-менеджер). 

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

Заказчику заявляешь: «Уважаемый, посмотри систему либо ее модуль. Проверь функциональность. Посмотри, как мы ее сделали. Это то, что ты ждешь?». Заказчик уже начинает кривить лицо. Когда же заказчика просишь подписать какие-то документы, становится совсем грустно.

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

Денис Бугров: Упаси Господи, просить.

Денис Самосеев: Да. Как правило, конечно же, никто не просит. Все это внутренние процедуры по обеспечению успешности реализации проекта. На старте реализации проекта заказчик всегда очень доволен. «Да, будет план по управлению качеством. Супер, ребята. Вы молодцы, очень квалифицированные». 

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

Денис Бугров: Да, контролировать качество надо. Как контролировать качество? Во всех стандартах рекомендуются метрики. Измеряем, измеряем, измеряем. Все что угодно – любую деятельность пытаемся измерить. Кто измеряет, кстати? Есть люди, которые что-то меряют? Если не секрет, что меряете?

Голос из зала: Мы измеряем количество времени, которое планировалось потратить.

Денис Бугров: В конечном итоге получается какие-то конкретные условия показать?

Голос из зала: Да.

Денис Бугров: Что они дают вам?

Голос из зала: Они нам дают понимание, сколько времени в итоге у нас выгорает из того времени, что мы могли потратить полезного.

Денис Бугров: А если меньше было? Получилось меньше, чем в плане. Это показатель чего?

Голос из зала: Показатель того, что во время работы (неделя, месяц) что-то происходило, что мешало выполнять задачу, которая запланирована.

Денис Бугров: Нет. Если запланировано, допустим, две недели. Задача была реализована через два дня. То есть показатель – это качество, вообще говоря.

Голос из зала: Это же не является показателем…

Денис Бугров: Существует огромная вариативность. А показатель качества однозначно вам говорит: «Это качественно». В данном случае, по-моему, это не показатель качества.

Голос из зала: Я понял вас. Измеритель качества у нас, возможно, неэффективен.

Денис Бугров: Я даже с эффективностью поспорю в этом случае. Извиняюсь, что немного от качества ухожу. Чья эффективность работы кривая, когда было запланировано много по срокам, а сделано гораздо быстрее?

Голос из зала: У себя такой ситуации, честно говоря, не помню. Чтобы планировали на две недели, сделали за два дня. Планировали сделать за день, сделали за полдня – такое было. Возможно, этот вариант подойдет больше к теме. У нас измеряется количество обращений клиента с ошибками по отношению к тем ошибкам, которые мы сами нашли в продукте.

Денис Бугров: Пропорции. Не знаю. Сложный показатель. Ладно.

Денис Самосеев: Разреши мне все же рассказать случай про самарскую компанию.

Денис Бугров: Долго. Если интересно, можно потом у Дениса спросить. У него есть очень веселый опыт в этом плане, когда мерили выходными ошибками, и что из этого получилось.

Денис Самосеев: Внутреннее тестирование по сравнению с тестированием заказчика. Если будет интересно, потом расскажу.

Денис Бугров: На самом деле, все метрики врут. Нет таких метрик. Я не знаю, я не придумал для проекта. Можно мерить все что угодно. Я пытался найти перед выступлением статью, которую я видел.

Денис Самосеев: Не все метрики врут. Врут метрики, которые были придуманы с точки зрения управления качеством в проектах. Метрики, которые имеют прямое отношение к сервисной модели оказания услуг. Например, предоставление сервиса файлового доступа к файловому сервису.

Денис Бугров: С сервисными процессами, действительно, все понятно и правильно. Если у кого-то есть вопросы по таким вещам, по тому, как мерить сервисы поддержки, можете потом отдельно нас поспрашивать. Благо собаку съели на этом деле. 

Все равно врут. На проектах врут. Я говорю: я достаточно давно читал статейку (полез искать ее, но не нашел), где кто-то писал про метрики качества в гибкой разработке. К сожалению, даже автора уже не помню. Назывались такие метрики, как количество фич, перешедших из одной итерации в другую. Кто-то читал? 

Количество багов – прекрасно. Любимая метрика измерения – количество багов. Все меряют количество багов. Говорят: «Мы померили. Было 10 багов. Второе измерение – 10 багов». И что дальше? А почему 10? Из-за того, что так хорошо программисты работают, стабильно? Или из-за того, что пока тестировщик проверяет предыдущие 10 багов, они не прогнали еще две сотни кейсов, которые должны были прогнать и просто не выявили еще 25, которые зависли там, просто потому что времени не хватило.

Что это показывает? Да ничего это не показывает. Это нужно делать, естественно. Тестирование нужно. Но считать количество багов, на мой взгляд, абсолютно не нужно.

Денис Самосеев: Считать, может быть, тоже нужно. Но ориентироваться на них как на показатель качества – вряд ли. Первый build – 10 багов, второй build – 10 багов новых, но 5 осталось старых. О чем это говорит? О контроле разработки – да. Но не о качестве производимого продукта.

Денис Бугров: В общем-то, это не метрика качества. Честно могу сказать, за свою практику я очень много где пытался вводить какие-то метрики, в том числе и в проектные компании. По юности, по малолетству – давайте мерить. Показатели – это попадание, непопадание в сроки проекта, бюджет и так далее. Все это наивно. Не помогает и ничего не дает, собственно говоря. 

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

Денис Самосеев: Требований к результатам работ по проекту.

Денис Бугров: Да, естественно.

Денис Самосеев: Тот самый раздел, который является вторым по главности после цены, а именно требование к результату проекта. Чем лучше он будет описан на этапе контрактования по проекту, тем проще будет создать систему управления качеством при реализации проекта.

Метрика: фича A должна обладать такими-то свойствами в таком-то модуле. Фича B должна обладать другими свойствами во втором модуле. В соответствии с такими записанными метриками в контракте потом будет осуществляться контроль качества создания продукта. 

Денис Бугров: Единственная проблема таких метрик. До какого-то этапа мы не можем мерить их нормально. Нужно какой-то результат уже видеть. Даже если мы говорим о спринтах итерационной разработки, все равно нам нужны определенные наработки, чтобы понимать, насколько правильно мы двигаемся.

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

На наш взгляд, опытным путем единственная вещь, которая может вам помочь на всем ходе проекта в определенный момент контролировать и управлять его качеством, – это Total Quality Assurance. Мы специально о ней не говорили, когда говорили про методологии и стандарты.

Денис Самосеев: Плавный переход. Единственное, громко сказано: самый оптимальный лучший. Я не буду столь категоричным, говоря о том, что TQA – это единственный способ контролировать. Я скажу о том, что мой опыт реализации проектов говорит, что это наиболее оптимальный способ.

Что такое Total Quality Assurance. Дословный перевод – всеобъемлющий контроль качества. При этом Total Quality Assurance подразделяют как минимум на два вида. TQA, проводимый внешними силами и проводимый внутренними силами. 

Денис Бугров: Я поясню. Попросту это некий аудит того, что происходит.

Денис Самосеев: Я постарался выписать тут несколько плюсов и минусов при проведении TQA силами внутренними, силами внешними. Вы их можете прочитать, ничего уникального нет. Все очевидно.

Денис Бугров: Здесь сразу вопрос. Кто попадал под аудитора? Есть такие? Ни у кого на проекте никогда аудита не было?

Голос из зала: Внутренний считаем?

Денис Бугров: Неважно. Внутренний хотя бы. Внутренний аудит у вас есть.

Денис Самосеев: Как он проходил?

Голос из зала: Независимая команда экспертов посмотрела проект. Кто-то почему-то умер.

Денис Самосеев: Аудитор умер?

Голос из зала: Аудит тоже умер. Мягко так, люди рассмотрели все. Прошлись по коду, прошлись по практикам, прошлись по всему. Я помню эти совещания 3 или 5 лет назад. Что-то такое старое, я даже не могу вспомнить это. Но почему-то он умер. Почему – об этом как раз на том совещании и записано. 

Он все разобрал, почему он умер. Вскрытие показало, что больной умер в результате вскрытия. На самом деле, причины были с этим не связаны. Но проведение аудита – штука такая. Это все равно лучше, чем аудит внешними людьми.

Денис Бугров: Почему?

Голос из зала: Потому что… Или хуже. Обратиться к врачу и открыть ему свои внутренности. Не знаю, я начал вспоминать свой личный медицинский опыт и решил не делиться с аудиторией.

Денис Бугров: Хорошо.

Денис Самосеев: Я выписал некую последовательность вполне очевидных шагов при проведении аудита, если аудитором являешься ты. Наверное, мы все же не успеваем пробежаться целиком, поэтому пойдем галопом по европам. 

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

Да, это крайне неприятная процедура, может быть, при некачественном проведении. А может быть проведена во вполне фоновом режиме, если за дело берется некий профессионал. При этом этот профессионал должен обладать рядом определенных качеств.

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

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

На мой взгляд, это очень полезно и хорошо. Записывается оно подобным же образом. Если у вас есть такое хранилище...

Денис Самосеев: Сейчас я расскажу более подробно о том отчете, который я продемонстрировал. Это Project Quality Review, выходной документ по итогам аудирования. Хочу прежде сказать пару слов о том, что аудируется и зачем это нужно.

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

Человек, обладающий достаточно высокой квалификацией, пробегается по верхнему уровню и пытается понять, соответствует ли то, что реализуется на текущий момент, тому, что хочет заказчик, что записано в контрактном документе. На выходе создается некий документ – матрица соответствия (traceability matrix, если говорить о названиях, которые используются в нашей компании). 

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

Понимается в целом настроение команды. Как правило, проект – это распределенная команда, как минимум состоящая из двух частей (люди со стороны заказчика, люди со стороны исполнителя). Любой аудит является, по сути, встряской команды, пониманием, что им провели ревизию, они на текущий момент имеют некий чек-поинт. Они знают, где они находятся. Они понимают степень соответствия календарным срокам (помимо прочего).

Переходим к отчету, который виден на картинке. Я взял из реального документа. Надеюсь, там ничто не попадает под confidential. Ни одного названия заказчика я не вижу, и слава Богу. 

Стоит сказать о том, что любой отчет об аудите содержит описание тех ошибок, которые были обнаружены в рамках аудита. Тут стоит провести знак равенства между ошибкой, обнаруженной аудитором, и рисками, которые существуют при реализации проекта. 

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

Что такое риски и что такое управление качеством. Про управление качеством и про метрики мы проговорили. Это выявление метрик. То же самое у рисков – это выявление предпосылок возникновения. 

Денис Бугров: Тут Стас сказал, что у них проект умер. В общем-то, это тоже результат аудита, что же делать. Хорошо, хоть не люди умерли. Иногда полезно, чтобы проекты умирали.

Голос из зала: Кто может проводить аудит?

Денис Бугров: Аудит бывает внутренним и внешним, как уже сказали. Кто же может проводить аудит внутри. На наш взгляд, это самая оптимальная процедура, самая экономичная. То, что доступно вам. 

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

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

Денис Самосеев: Да и потом, по ходу прохождения первого десятка аудитов, как-то привыкаешь к этому делу. Это подстегивает. У меня сейчас в производстве три больших проекта, каждый стоимостью два миллиона долларов с точки зрения трудочасов (без оборудования, без лицензии). В среднем я прохожу аудиты раз в неделю.

Денис Бугров: Основной аспект, как готовить аудит. Тоже немаловажные вещи. Нужно команду всю подготовить к этому делу. Неожиданный аудит – это ужас. Это кошмар.

Денис Самосеев: Как некое «Итого». Мы коротко поговорили о процессной модели управления качеством. Там все просто. Выявление метрик – очень простой процесс. Поговорили о том, что содержится в разного рода стандартах. Пару слов сказали о том, что есть PM блоки. PM блок, в первую очередь, ориентируется на тот же самый ISO и прямо говорит: «Вы не сможете управлять качеством реализации проекта, пока у вас не будет внедрена в компании система менеджмента качества в целом». Странный подход к управлению качеством по проектам. Я с ним не совсем согласен.

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

Денис Бугров: Получилось так. Вопросы. 

Вопросы и ответы

Вопрос из зала: А как проверить аудит?

Денис Бугров: Проверить будет тяжело, придется так вспомнить. А что там было?

Вопрос из зала: Делать, не делать.

Денис Бугров: Я могу озвучить. 

Делать – максимальная информированность всех, кого будет затрагивать аудит. Не делать – неожиданности. Почему-то часто на моей практике вопрос читают следующим образом. «Мы сейчас неожиданно приведем людей…». Еще хуже: один раз на моей практике было так, что предварительно всю документацию и все исходники отдали внешним аудиторам. Предварительно, без всякого информирования команды. Когда аудиторы, уже нашпигованные этими знаниями, появились в компании, это был просто кромешный ужас.

Делать – информировать, объяснять. Не делать – не делать неожиданно.

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

Хотя достаточно часто есть неминуемость наказания, неизбежность. «Мы тут проверили: вы тут вообще все лохи. Делаете не то. Сейчас мы будем всех вас ногами…». Это отличный результат аудита. Но после этого вторая половина точно работать не станет. Это с гарантией.

Денис Самосеев: Спасибо.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Олег Илларионов

Олег Илларионов

Разработчик социальной сети ВКонтакте.

Олег Илларионов (ВКонтакте) рассказывает об изменениях принципов работы с вебом и отвечает на вопросы о самой популярной российской соцсети.

Константин Осипов

Константин Осипов

Разработчик и архитектор СУБД Tarantool.

Разработчик Tarantool Константин Осипов и его активный пользователь Александр Календарев сравнили Tarantool с Redis.

Александр Шуркаев

Александр Шуркаев

Руководитель IT-проектов.

Александр Шуркаев рассказывает о дешёвых и быстрых методах A/B-тестирования, а также о необходимых для него инструментах, ресурсах и регламентах.