Несколько дней новогоднего волшебства:
Успейте начать обучение в 2018-ом году со скидкой до 30%!
Выбрать курс

О разрушительной силе мелочей: в чём проблема?

DevHead_Deep_LAST_11.07_4_site.png

Начну с банальности: разработка ПО — деятельность плохо предсказуемая. Трудно с высокой точностью определить объём предстоящих работ и предугадать все «узкие» и «скользкие» места. Это происходит из-за того, что самой области свойственна высокая неопределённость и изменчивость, поэтому, даже имея на руках детализированный план действий, можно с уверенностью сказать, что что-нибудь пойдёт не так.

Управление разработкой или управление проектом по разработке подвержено влиянию неопределённости в ещё большей степени: добавляются проблемы, связанные с коммуникациями, интеграцией и т.д. и т.п.

Как мы боремся с этой вариативностью?

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

И это всё правильно, но…

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

— «Забыли» про зависимость и при запуске новой фичи положили кусок функционала в «другом конце» проекта.

И так далее...

Декомпозиция, опыт, квалификация — это попытки прояснить ситуацию, увеличить объём того, что мы знаем. Это попытка избежать ошибок, связанных с незнанием. Но в описанных мной примерах причиной ошибок является не “незнание”.

Проблема в «игнорировании» очевидного, настолько очевидного, что оно просто выпадает из поля зрения.

Другими словами проблема в «мелочах»:

— Не убедился, что все ок. — Не посмотрел состав релиза. — Не предупредил админов, что завтра релиз (мы три недели его уже готовим!). — Забыл уточнить, забыл согласовать, забыл запустить автотест (я его три года гонял и ни разу в этом кейсе сбоя не было).

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

Избегание подобных «досадных ошибок», кстати это относительно недорогой процесс, может дать значительный эффект. В некоторых областях эффект более чем значим: Атул Гаванде в своей замечательной книге «Чек-лист» описал, как насаждение привычки мытья рук перед хирургической операцией снизило количество смертей из-за осложнений на несколько десятков процентов.

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

Ещё

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

Автор
0 комментариев
Для комментирования необходимо авторизоваться