Пять наблюдений о планировании

В этой короткой статье будут некоторые соображения об общих проблемах задержки сроков проектов. Часть из них лежит на стыке между технологиями планирования и технологиями разработки. Если вы сталкивались с тем, что после середины проекта каждый шаг не особо приближает его к завершению — знайте, план был так себе. Более конкретно под катом.

Почему нужно искать проблему в плане

Неважно, гибкий или водопадный план — будучи любым, он определяет порядок появления функциональности (пусть даже и внутренней или промежуточной). Фактический срок — это функция не только объема функционала на одного человека, но еще и качества продукта (пусть даже не кода), причем она монотонно возрастающая по объему, монотонная по качеству, хотя и ограничена в этом случае. Пишите хоть hello world, хоть поисковик — качество конечно, а вот функционал можно добавлять и менять неограниченно.

Остается причиной изменения фактических сроков при фиксации объема и качества — только "внутренняя кухня", что в каком порядке делается. Естественно, всё это для некоторого абстрактного программиста в рамках 40-часовой рабочей недели. Теперь еще дальше углубимся в конкретику.

Какие бывают проблемы и что делать

Неправильное разбиение на задачи ведёт к сложности их последующего обьединения в результат. Что значит неправильное разбиение? Это то разбиение, в котором все сделанные задачи не образуют конечный продукт, и в конце появляется задача "Интеграция". Её срок спрогнозировать невозможно, не зная промежуточных деталей. Но она есть, и её надо делать.

Мораль — не стоит откладывать интеграционные риски на конец проектов. Если у вас есть, например, API, используйте подходящие инструменты для разработки — например mock-сервисы (заглушки, тестовые данные и тому подобное).

План не должен быть сложнее системы, система не сможет быть реализована по нему. Это следует из того, что чтобы "понять" (отразить) одной системе другую, первая должна быть не меньшей сложности, а в нашем случае — продукт должен быть сложнее плана. Иначе план не будет реализован, то есть (если следовать плану) план реализовывает не тот продукт (что в ТЗ например).

Мораль — критерием достаточности детализации плана служит мера разброса его сроков. Если она ниже планки допустимого, план можно брать в работу.

Исследования как часть плана проекта — это прямой путь к потерям. К потерям именно в проекте. Причём исследования могут быть по типу "сделаем половину, а там видно будет", или по типу "выбор фреймворка заложим в проект". Если вы не оцениваете проект по методу дерева событий и решений — то этот проект очень вероятно не уложится в сроки. Потому что исследования могут выдать решение наподобие "подходящего фреймворка нет, надо делать самим".

Мораль — всё, последствия чего нельзя оценить приемлемо точно — не должно присутствовать в плане проекта, сроки которого предмет оплаты.

Какова вероятность ошибиться в одной точке (дате) и какая в интервале (дат)? Естественно, под точкой понимают некий луч (влево), но и тогда мы имеем вероятность из разряда "встретить динозавра": либо до точки будем, либо после (вероятность 50% — это отсутствие информации в прикладном случае). Исходя из этого, интервальный срок проекта всегда точнее конкретной даты — он менее рискован. Конечно, интервал никто не пишет в договорах, там можно записать правый край для уверенности. Если бы вы оценивали всё сразу по максимуму (а не среднее по трём точкам с коэффициентами), то неизбежно столкнулись бы с неэффективностью на конкурентном рынке.

Мораль — лучше взвесить разные оценки в одну, чем верить одной оценке (задачи).

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

Представьте, что каждая задача не доделана до конца: тогда чтобы доделать до конца следующую зависимую, вам нужно доделать уже две.

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

Заключение об идеальном плане

Суммируя все морали каждой истории, идеальный план выходит чуть ли не противоречивым:

1. План растет органически, от малого к большому, а не от частей к целому.
2. План должен быть проще того, что по нему реализуется (иначе план нереализуем),
3. В плане одного проекта (речь не про серии) не должно быть роковых событий,
4. Интервальные оценки дают большую надежность просто по своему определению,
5. В плане не должно быть долгов, все что используется в последующем, должно быть работоспособным.

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