Изображение с сайта projectimo.ru
Даже в такой продуманной и формализованной сфере, как разработка программного обеспечения, не перестает быть актуальным вопрос управления рисками. Можно ли вообще управлять неопределенностью, случайными величинами?
Оптимисты утверждают, что их можно классифицировать и научиться предугадывать. В случае разработки ПО риск-менеджеры пытаются предугадать, какая часть проекта вызовет больше проблем, на каком этапе это случится, кто в команде – самое слабое звено, какие фичи могут дать задержку по времени. Сложнее понять, какие фичи заказчик захочет доработать в процессе разработки – как говорится, на полном ходу. Высший пилотаж – добавить в план разработки ту функциональность, о которой заказчик забыл сказать или вообще не знал, что она ему понадобится.
А риск того, что проект неожиданно покинут ключевые разработчики, вообще приводит в ужас многих риск-менеджеров.
Если еще принять во внимание всевозможные риски, связанные с ситуацией в стране, магнитным полем Земли, колебанием валют, изменением баланса спроса и предложения, закрытием фирмы клиента наконец, то каждой компании придется создавать для учета и анализа всех этих рисков свой исследовательский центр с высоким уровнем паранойи.
Часть вышеперечисленных проблем, так или иначе, помогают решить гибкие методологии управления проектами. Но существуют еще проблемы, связанные с недостаточной компетенцией самих риск-менеджеров, ALM-менеджеров и низкой мотивацией сотрудников к строгому соблюдению принципов этих методологий.
Безусловно, на различных этапах разработки указанные проблемы и риски проявляются в разной степени: на этапе формирования плана работы больше риск ошибиться с оценками и приоритетами фич; на этапе проектирования разработчики могут внести «роковые» ошибки в проект; на ранних итерациях существует соблазн перенести слишком много задач на последующие итерации; на этапе развертывания стоит готовиться к тому, что процесс не пройдет гладко.
Неслучайно при описании рисков возникает ассоциация с соблазном. Разработчики – живые люди, которые не могут постоянно работать с одинаково высокой эффективностью. Каждодневные соблазны «отложить на завтра», «уйти пораньше», «прийти попозже», и так далее, имеют накопительный эффект. Если N сотрудников пойдут на поводу у M соблазнов, это значительно снизит общую дисциплину и локальную производительность труда.
У этой истории есть продолжение: рано или поздно этим сотрудникам придется наверстать упущенное, и тут их подстерегает риск допустить ошибки из-за спешки и переутомления. Получается, что незначительные отклонения в силу «человеческих слабостей» могут привести к значительному «проседанию» проекта. Как предсказать, когда тот или иной сотрудник устанет? Сколько риск-менеджеров понадобится, чтобы следить за всеми?
А если у некоторых участников команды просто испортятся отношения? Можно ли предсказать такое? Если да, то риск-менеджер должен быть по совместительству психологом, либо работать в связке с ним. Возможно, в мелких проектах за всеми уследить можно, но удастся ли это в более крупных?
Конечно, для каждой ИТ-компании в этом вопросе нужно искать золотую середину. Но пока на каждом этапе разработки и внедрения программных продуктов участвуют недетерминированные механизмы (то есть, люди), человеческий фактор будет оставаться главным риском.
Так мы приходим к самому главному вопросу – можно ли каким-то образом зарезервировать «человеческому фактору» место в списке рисков и научиться управлять им?
Первое решение, которое приходит в голову, – по возможности, лишить всех сотрудников статуса «незаменимый». Речь идет о таких подходах, как парное программирование или, например, тестирование, code review, ротация сотрудников между разнотипными задачами и прочее коллективное творчество. Сюда же примыкает создание большого резерва времени, выделяемого на задачи с учетом возможных рисков. Однако это получается далеко не всегда.
Вторым решением, которое никак не исключает первое, могут стать мотивационные тренинги, team building и другие мероприятия, направленные на формирование командного духа, донесение ценностей фирмы до каждого сотрудника и поддержание дружеских отношений между работниками.
Третье решение выглядит еще проще, но немного наивно: нужно нанимать сотрудников, которые практически не будут уставать, не будут разлагать дисциплину и конфликтовать. И конечно же, их профессиональные качества и результативность должны быть на высшем уровне, что позволит им практически не допускать ошибок. Сочетание положительных качеств встречается не так уж и часто, если не сказать редко. За такими людьми обычно ведется масштабная «охота» и нанимают их в основном в перспективные стартапы с богатыми инвесторами. Если специалисты такого уровня работают за идею, значит, кому-то очень повезло.
Вообще в стартапах отношение к риску другое: зачастую такие проекты разрабатываются в условиях максимальной неопределенности. В равной степени, к краху или успеху стартапа может привести как написанный «на коленке», недоделанный софт с кучей ошибок, так и готовый продукт, разработанный по всем канонам прогрессивных методологий.
Более сложные решения по минимизации человеческого фактора могут сводиться к усилению слежки за сотрудниками, введению контрольно-пропускной системы и системы штрафов, ужесточению режима труда, введению строгих правил и процедур. За послушание и эффективность работники могут поощряться различными «плюшками» в виде рейтингов, значков, досок почета, и конечно, премий. Причем, в отличие от первого пункта, здесь не идет речь об изменении техпроцесса как такового. Здесь имеется в виду некий тоталитаризм, который обычно называют корпоративной культурой.
Изображение с сайта joyreactor.cc
Данный подход не дает сотруднику задумываться о своем настроении и состоянии, не дает сдвинуть режим труда ни на йоту, тем самым «защищая» его от прокрастинации и прочих «соблазнов». Формула успеха в данном случае проста: «Делай все по инструкции». Такой подход больше характерен для крупных ИТ-компаний, где одной из главных ценностей является стабильность. В этом контексте серьезным риском является вероятность отступления каких-либо сотрудников от инструкций. Это воспринимается, как прямая угроза целостности системы, и такой сотрудник жестоко наказывается, либо изгоняется с позором. В таких ИТ-компаниях обычно не стоит вопрос о том, что кто-то из работников является «незаменимым» или выдающейся личностью. Потому что такой системе нужны в основном «винтики», чтобы участвовать в серийном, а не штучном производстве.
Но, согласно крылатой фразе, чужая душа – потемки. В мягкой нише еще меньше определенности и условий для формализации, чем в более материальных, структурированных или осязаемых сферах. Какое бы решение ни было предложено, однозначной и предсказуемой реакции каждого сотрудника мы не добьемся.
Иногда сама мысль о том, что проект чуть ли не каждый день находится под угрозой провала, демотивирует команду. Кого-то эта мысль, наоборот, мобилизует. Кого-то мобилизует сама критическая ситуация. Сколько историй мы слышим про то, как некий разработчик, перепробовав стандартные решения и нарушив все инструкции, был вынужден «танцевать с бубном», чтобы сдать проект в срок.
Обычно подобные импровизации не приветствуются, но часто в таких ситуациях другого выхода просто нет. Но если конечный результат достигнут и проект сдан – честь и хвала герою. Несмотря на то, что такие сотрудники несут потенциальный внутренний риск для проекта, они спасают компанию от весьма конкретных денежных рисков и проблем с недовольными заказчиками.
Таким образом, перед талантом и нестандартным отступают строгие методологии и каноны. С точки зрения управления рисками, – это безумие: риск увеличивается еще сильнее для того, чтобы получить в итоге маловероятное событие, то есть, успех. Но человеческий фактор предполагает, помимо своих негативных качеств, еще и способность идти до конца и верить в лучшее. Даже если вместо этого происходит худшее, компания приобретает ценный опыт.
Знание и предвидение рисков накапливается в процессе естественной жизнедеятельности компании и откладывается как бы в ее «подсознании». В таком случае и происходит естественное принятие упреждающих решений и обучение компании. Она, как любой живой организм, обладает известной степенью саморегуляции и способна эволюционировать. В этом ей как раз и помогает человеческий фактор.
Если же рисками умозрительно пытается «управлять» некий обособленный, специально предназначенный для этого, специалист, то человеческий фактор может сыграть против него. Все потому что, он пытается в ручном режиме управлять процессом, который обычно происходит автоматически. Вмешиваясь в естественный ход вещей, он, во-первых, может встретить явное или неявное сопротивление команды, а во-вторых, загрузить гипотетическими проблемами, которые ни разу решать не приходилось.
Принцип «кто предупрежден, тот вооружен» работает далеко не всегда. Зная о тех или иных рисках, компания может потратить много времени, чтобы моделировать варианты решения соответствующих проблем. Однако встретившись с ними в реальности, когда некогда рассуждать и взвешивать ситуацию, компания может «инстинктивно» выбрать решение проблемы, которое до этого вовсе не рассматривалось. Это будет естественной, и возможно, окажется самой лучшей, реакцией в сложившейся ситуации.
Оставаясь главным риском в разработке ПО, человеческий фактор служит хорошей причиной для развития ИТ-компании, для ее «взросления». Каждый сотрудник (независимо от должности), преодолевая сложности при решении собственных профессиональных задач, учится решать их с меньшей долей риска нанести вред всему проекту. Таким образом, управление собственными рисками, основанное на личном опыте, вносит вклад в формирование коллективного опыта.
Конечно же, речь не идет об изобретении велосипеда. Речь о том, что какую-то часть чужого опыта можно присвоить и адаптировать, а какую-то – нет. Обычно элементарные правила и меры предосторожности усваиваются достаточно просто, а задачи с неочевидным решением часто требуют собственного процесса поиска и накопления своего, пусть не всегда удачного опыта.
Автор: semen_grinshtein
