А за процессы у нас отвечает… Маша

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

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

Вводить ее нужно потому, что при достижении определенного количества людей в компании (я бы начал с 20-30 и больше) начинается разброд, каждый работает как считает нужным, результаты работы соответственно получаются разными, да и вообще наступает ощущение всеобщего бардака от чего страдает и бизнес и мотивация сотрудников.

Заблуждение же заключается в том, что если назначить кого-то «ответственного за процесс», то все будет пучком. Очень часто этим кем-то назначается, простите за прямоту, – дешевый и малонужный ресурс, да-да именно «ресурс» (наречем ресурса – Маша), а не человек и специалист. И тут руководство компании радуется, что удалось-таки порешить этот процессный подход ДЕШЕВО, а сотрудники искоса смотрят на Машу и свое руководство, и намереваются это все… игнорировать. Хотя в последнее время намечаются сдвиги в правильную сторону, и это радует.

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

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

Теперь давайте спросим себя:

  • Действительно ли Маша компетентна во всех инженерных и управленческих практиках, чтобы их формализовывать, а еще и увязывать между собой?
  • Понимаем ли мы (объяснили ли нам) что такое процессный подход, зачем он нам тут нужен, зачем нам Маша, и сколько это займет времени (денег)?

Прежде чем читать дальше, давайте возьмем минуту (нет, не молчания), чтобы хорошо вдуматься в эти вопросы…




Ок, что же получается по первому вопросу. А то, что никакая Маша, будь она даже семнадцати пядей во лбу не сможет быть компетентной во всех инженерных и управленческих практиках. Отсюда напрашивается вывод, что душа (не голова) должна болеть за правильные процессы именно у специалистов, делающих те или иные практики. Например: а) — у менеджеров проектов за то, как правильно делать управленческие практики и как их описать в процессах; б) — у тестировщиков за процессы тестирования и т.д. Физически это выливается в необходимость создания так называемых инженерных групп, или, по научному – Engineering Process Group. Но, важно чтобы люди там были как минимум мотивированные. Достаточно пары человек в каждой специальности, чтобы довольно быстро и качественно формализовать процессы, обучить остальных и собственно внедрить их.

Что же касается второго вопроса, то тут требуется две вещи:

  • Пресловутая поддержка руководства, которая выражается не только в указании – «делайте». Но и в формальном выделении времени и даже денег на то, чтобы обучить инженерные группы процессному подходу или какой-либо системе управления качеством, а также обеспечить наличие достаточного времени у них сделать процессную работу. Тут нужно принять тот факт, что или понадобится договариваться с заказчиками о меньшей отдаче, или каким-то другим способом обеспечить время на это. Хочу заметить, что первичное описание процессов – это врЕменная нагрузка, которая действительно требует формального выделения времени, на дальнейшие улучшения процессов много времени скорее всего не потребуется. По опыту, на первичное описание процессов нужно 10-20% занятости у представителей инженерных групп. Как долго? – это уже зависит от того, что вы хотите построить.
  • Маша все равно нужна, но не «дешевый и малонужный ресурс», иначе ничего толком не получится, а если получится, то будет долго, болезненно, и дорого. Нужен или человек внутри компании с достаточно высокими полномочиями и профессиональными знаниями как в процессном подходе, так и в разнообразных системах управления качеством. Или же нужен квалифицированный внешний консультант, но только в связке с «человеком внутри с достаточно высокими полномочиями и профессиональными знаниями». И консультант ни в коем случае не должен делать работу по формализации процессов :), это должны сделать инженерные группы.

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

Tags: , ,

Comments are closed.