Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>Теги: управление командой разработки, head of development, руководитель разработки, декомпозиция, вариативность, разрушительная сила мелочей, атул гаванде, управление проектом по разработке</p>

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

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

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

5 <ol><li>Пытаемся детализировать планы, чтобы найти потенциальные источники проблем и заранее подготовиться.</li>

6 <li>Набираем в команду людей опытных, чтобы они подсказали нам, где прячутся неожиданности.</li>

7 <li>Набираем людей умных и высококвалифицированных, чтобы они не спасовали перед неожиданно возникшей проблемой.</li>

8 </ol><h2>И это всё правильно, но…</h2>

9 <p>Но весь мой опыт указывает на то, что причины большинства тактических провалов далеко не в отсутствии вышеперечисленных факторов. Под стратегическим провалом я понимаю ситуацию, когда мы запустили продукт в срок и в должном качестве, а он "не взлетел". А под тактическим - срыв сроков, релиз с ошибками, неудачную попытку релиза и прочие "факапы": - Админ выкатил код и ушёл, не дождавшись от разработчика подтверждения, что всё ок. - В пятницу бросились править злой баг и выкатили вместе с хотфиксом апдейт, запланированный на понедельник и ещё не проверенный менеджером.</p>

10 <p>- "Забыли" про зависимость и при запуске новой фичи положили кусок функционала в "другом конце" проекта.</p>

11 <h2>И так далее...</h2>

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

13 <p>Проблема в "игнорировании" очевидного, настолько очевидного, что оно просто выпадает из поля зрения.</p>

14 <h2>Другими словами проблема в "мелочах":</h2>

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

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

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

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

19 <h2>Ещё</h2>

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