Планирование планированию рознь

Наткнулся недавно на интересный блог: Алекс Лебедев пишет про разработку. Блог открылся недавно, но там уже есть некоторое количество интересных статей. Хотя лично меня в первую очередь привлекло то, что причины, побудившие автора уйти с зарплаты и начать работать самостоятельно, уж очень во многом совпадают с моими :-).

Одну из недавних статей, посвященную планированию, мне очень хочется прокомментировать.

Когда-то я прочитал уже ставшую классической статью о планировании Джоела Спольского, которая показалась мне очень логичной. За последний год у меня была возможность потренироваться с этим подходом, и должен сказать, что как только я его "грокнул", я убедился, что он реально работает. Буквально, Джоел оказался прав практически во всем. Поэтому, если ваши планы все время проваливаются, я утверждаю, что "вы просто не умеете их готовить". Поэтому эту статью я теперь рекомендую к обязательному прочтению всем разработчикам и их менеджерам. Больше того, лучше всего прочитайте ее прямо сейчас.

Статья же Алекса Лебедева оставила у меня странные впечатления, потому что сначала я был совершенно не согласен, потом совершенно согласен, а с выводом — не согласен опять :-).

Немного разобравшись в причинах этого эффекта, я и хочу расставить акценты.

Первая часть начинается так:

Регулярно сталкиваюсь с желанием того или иного руководства составить подробный план работ и строго следовать ему. Зачем это нужно? Никакой объем планирования не может ускорить работу.

Я бы уточнил: никакой объем планирования разработки, составленный руководством, не может ускорить работу. Дальше автор углубляется в описание того, почему планы не работают, почему не помогает ни жесткий контроль исполнения, ни военная дисципина. Это все так, но я в корне не согласен с тем, что проблема лежит в самом факте подробного планирования. Реальная причина неработы такого подхода только в том, что никто, кроме того человека, который пишет код, не может физически знать, сколько на это уйдет времени. Ни руководитель, ни его коллеги разработчики. Только он сам, и как раз только тогда, когда спланирует все подробно.

А вот дальше автор делится работающей моделью планирования:

Всегда имейте максимально полный и актуальный список работ. Расставляйте приоритеты и работайте в первую очередь над высокоприоритетными вещами. Оценивайте трудоемкость работ и примерные даты окончания. Только не пытайтесь зафиксировать сроки и взвалить ответственность за их соблюдение на разработчиков.

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

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

А вот для того, чтобы план был наиболее близок к реальности, он просто обязан быть подробным. Никто не знает, сколько занимает "система профайлов пользователей", потому что в это понятие можно включить от двух часов до полугода работы. Только когда это разбито на задачи "создать таблицу с полями A, B, C", "вывести поля в виде формы", "обработать submit" и т.д., тогда это можно посчитать.

Даже дедлайны, которые являются сутью традиционных "планов", на самом деле тоже имеют смысл. Они, например, могут быть продиктованы какими-то внешними причинами, и их действительно нельзя нарушать. И здесь план-инструмент позволяет команде сделать информированный выбор, от каких функций надо отказаться, чтобы успеть. А не обманывать себя до самого последнего момента, что "надо только еще чуть-чуть постараться и поднажать". Так не бывает в разработке, потому что программист не может заставить мозг "думать быстрее", и как любой творческий человек, не может генерировать у себя в мозгу озарения по собственному желанию.

Поэтому на вопрос в конце статьи:

Вы все еще думаете что вам нужен подробный план работ?

... ответ — конечно да.