KIT

Как мы выяснили в прошлых постах, срыв сроков у команды — признак систематических проблем в процессах. Теперь разберем главную причину, с которой начинаются большая часть провалов — проблема оценки сроков. Сильная команда ≠ точные прогнозы. Самая главная несправедливость — чем сильнее команда, тем больше менеджмент верит в чудо, тем сильнее давление и тем менее точны оценки сроков, а в результате — очередной срыв сроков. В психологии это называется Planning Fallacy — когнитивное искажение, при котором...

Разработка часто страдает от болезни «почти готово». Это состояние, когда код написан, но функциональность еще не выпущена в продакшен, потому что «еще не дописали тесты», «забыли дополнительное условие» или «дизайнер еще не смотрел». И такие мелочи тянуться неделями и превращаются в бесконечные доработки. Definition of Done (DoD) — это ваш «чек-лист качества», который не дает задаче считаться выполненной, пока она не соответствует стандартам команды. Это способ синхронизировать ожидания. DoD не должен быть на 3 страницы...

Итак, мы установили, что даже команды, которые состоят из суперзвезд, могут легко провалить все мыслимые и не мыслимые строки. Какой должна быть идеальная команда? Команды, которые показывают стабильный результат, обычно отличаются не "супер людьми", а зрелыми процессами планирования и контроля, культурой прозрачности и ответственности. Уровень недопонимания в них снижен до минимума, при тех же внешних вызовах они видят риск заранее, осознанно фокусируются на необходимых работах и договариваются, а не терпят до последнего...

Довольно часто возникают такие ситуации: Давайте обсудим, почему так происходит. Самый распространенный миф — если не успели, значит, плохо работали/слабая команда и тому подобное. Я видел сильные команды, которые: Срывы сроков проекта — это чаще всего системные проблемы в процессах, планировании и коммуникациях. Множество мелких задержек и проблем, оставленных без контроля, имеют свойство накапливаться и приводят к каскадным системным сбоям. Даже сильная команда может стабильно нарушать сроки разработки,...

Иногда приходится интегрироваться с системами, которые работают в асинхронном режиме, но при этом выставляют API с синхронными вызовами. Часто возникает такая последовательность действий: ① Отправляем запрос, получаем request_id и время ожидания. ② Ожидаем заданное время. ③ Через некоторое время вызываем метод для получения статуса запроса по request_id, здесь можем либо получить подтверждение выполнения, либо опять уйти в ожидание (переходим в ② и потом опять в ③). ④ Получаем статус выполнения запроса, понимаем, что нужно отправить дополнительные данные...