О разрушительной силе мелочей: в чём проблема?
Начну с банальности: разработка ПО — деятельность плохо предсказуемая. Трудно с высокой точностью определить объём предстоящих работ и предугадать все «узкие» и «скользкие» места. Это происходит из-за того, что самой области свойственна высокая неопределённость и изменчивость, поэтому, даже имея на руках детализированный план действий, можно с уверенностью сказать, что что-нибудь пойдёт не так.
Управление разработкой или управление проектом по разработке подвержено влиянию неопределённости в ещё большей степени: добавляются проблемы, связанные с коммуникациями, интеграцией и т.д. и т.п.
Как мы боремся с этой вариативностью?
- Пытаемся детализировать планы, чтобы найти потенциальные источники проблем и заранее подготовиться.
- Набираем в команду людей опытных, чтобы они подсказали нам, где прячутся неожиданности.
- Набираем людей умных и высококвалифицированных, чтобы они не спасовали перед неожиданно возникшей проблемой.
И это всё правильно, но…
Но весь мой опыт указывает на то, что причины большинства тактических провалов далеко не в отсутствии вышеперечисленных факторов. Под стратегическим провалом я понимаю ситуацию, когда мы запустили продукт в срок и в должном качестве, а он «не взлетел». А под тактическим — срыв сроков, релиз с ошибками, неудачную попытку релиза и прочие «факапы»: — Админ выкатил код и ушёл, не дождавшись от разработчика подтверждения, что всё ок. — В пятницу бросились править злой баг и выкатили вместе с хотфиксом апдейт, запланированный на понедельник и ещё не проверенный менеджером.
— «Забыли» про зависимость и при запуске новой фичи положили кусок функционала в «другом конце» проекта.
И так далее...
Декомпозиция, опыт, квалификация — это попытки прояснить ситуацию, увеличить объём того, что мы знаем. Это попытка избежать ошибок, связанных с незнанием. Но в описанных мной примерах причиной ошибок является не “незнание”.
Проблема в «игнорировании» очевидного, настолько очевидного, что оно просто выпадает из поля зрения.
Другими словами проблема в «мелочах»:
— Не убедился, что все ок. — Не посмотрел состав релиза. — Не предупредил админов, что завтра релиз (мы три недели его уже готовим!). — Забыл уточнить, забыл согласовать, забыл запустить автотест (я его три года гонял и ни разу в этом кейсе сбоя не было).
Это мелочи, но они создают столько операционных проблем, что до уровня, где проекту начинает угрожать вариативность, порождаемая сложностью и неизвестностью, до уровня, где требуются глубокие предметные знания, мы можем и не дойти.
Избегание подобных «досадных ошибок», кстати это относительно недорогой процесс, может дать значительный эффект. В некоторых областях эффект более чем значим: Атул Гаванде в своей замечательной книге «Чек-лист» описал, как насаждение привычки мытья рук перед хирургической операцией снизило количество смертей из-за осложнений на несколько десятков процентов.
Поэтому игра стоит свеч и я убеждён, что каждый руководитель должен сосредоточиться на искоренении глупых ошибок в своих процессах и командах.
Ещё
Во второй части заметки я поделюсь своими соображениями, почему мы делаем глупые ошибки и про то, как с этим бороться: да, про чек-листы и не только.
