KIT

Прочитал замечательную книгу Ицхака Адизеса «Развитие лидеров». После ее прочтения захотелось пересмотреть и первую часть — «Идеальный руководитель». Первая книга не произвела сильного впечатления на меня. Было ощущение, что просто познакомился еще с одной концепцией, приближением или теорией по формированию сбалансированных команд. Эта же книга («Развитие лидеров») очень запала мне в душу. По его классификации (PAEI) я больше всего — «p-Ei» (ну либо с маленькой очень «a»). И его описание людей с ярковыраженным E очень точно бьет в цель...

Сколько раз мы брали задачу в работу, а в середине ее разработки выясняли, что некоторая часть требований не описана, а API, с которым будем интегрироваться в процессе, еще не готов? В итоге половина запланированного времени уходит на уточнения, описания и переделку того, что уже сделали (привет, миграции Liquibase!). В таких случаях стоит внедрить в процессы команды практику Definition if Ready (DoR). DoR — это парная практика к Definition of Done, которую мы разбирали чуть раньше. Множество людей...

В прошлом посте мы разобрали ловушку оптимизма, в которую попадают при попытке оценки нового проекта. Главная причина — Planning Fallacy: когда наш мозг из раза в раз моделирует идеальный сценарий и игнорирует прошлые провалы. В этом разберем, как оценивать так, чтобы потом попадать в свои оценки. При оценке сроков нужно переключить свой взгляд с изнутри (Inside view) проекта/задачи на взгляд снаружи (Outside view): Inside view — вы детально разбираете именно этот проект: какие шаги предпринять, что нужно сделать и т...

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

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