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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии: 8 (feed)

  1. Alex Lebedev

    Иван, спасибо за развернутый комментарий.

    Способ планирования "от Джоэля" пробовал и мне, в целом, понравилось. Очень просто и весьма эффективно, гораздо лучше, чем большинство альтернативных тяжеловесных подходов.

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

    Это замечательно, но есть одна проблема. Такой подход не сочетается с agile-разработкой. Чтобы знать, что через 3 недели нужно создавать таблицу с полями A, B и C нужна достаточно подробная спецификация на функциональность, для которой будет использоваться эта таблица. Если в проекте уже используются подробные спецификации - отлично, вы можете воспользоваться ими для создания очень эффективного плана. Если спецификаций нет, то нет смысла вводить их для большей предсказуемости сроков работ.

    По поводу дедлайнов - согласен, очень нужная штука. Позволяющая, например, отсечь ненужную но красивую функциональность и забыть о ней навсегда. Джоэль пишет об этом в своей статье Set Your Priorities:

    Mike Conte taught me this system during the planning of Excel 5, where it only took a couple of hours even with a couple of dozen people in a conference room. The cool thing was that the roughly 50% of the features that we didn't have time to do were really stupid features, and Excel was better because it didn't have them.

    Резюме:
    План работ - очень полезный инструмент для решения вполне определенных задач. Только никогда не показывайте свой план руководству! Срабатывает общая закономерность: если полезная рабочая метрика начинает использоваться руководством, для того чтобы запустить руки в процесс разработки, то все становится хуже, чем было вообще без использования этой метрики.

  2. Горбунов Олег

    Немного не в тему статьи: Вчера после 6 часов вечера переслали письмо из одного отдела, со стандартными фразами: "...разработать и внедрить...", срок исполнения стоял 10.08.06.
    после этого фраза "Вы все еще думаете что вам нужен подробный план работ?" приобретает какой-то издевательский оттенок... Я к тому, что хорошо если можно составить план и сообщить о сроках, а если необходимо вписыватся в указанные сроки?

    PS. Естественно, после хождения и кричания на всех и вся с самого утра, все таки дали составить план и сообщить о сроках разработки. Даже сослался на данную статью перед начальством, начальство ознакомилось... и, о чудо! согласилось. За что отдельное спасибо.

  3. Иван Сагалаев

    Это замечательно, но есть одна проблема. Такой подход не сочетается с agile-разработкой.

    Ну почему же... Agile-методы ставят во главу угла изменчивость плана, и предварительная подробная спецификация этому не противоречит. Она тоже может меняться, и быть при этому такой же подробной.

    Хотя такая agile-методология, как <a href="http://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D1%82%D1%80%D0%B5%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5" rel="nofollow"><acronym title="Экстремальное программирование">XP</acronym></a>, насколько я знаю, действительно не предполагает такого подхода. Там планирование не только изменчивое, но и очень быстрое, и делается по ходу разработки. На дедлайны все особенно не завязано, а система считается готовой практически в любой момент. Но XP подходит для текущих проектов, не ограниченных сроками: например постоянное написание и совершенствование внутреннего софта внутренней командой разработчиков. А вот в контрактных работах "сделать такую-то систему за N месяцев" без предварительного планирования будет тяжело.

  4. Иван Сагалаев

    Я к тому, что хорошо если можно составить план и сообщить о сроках, а если необходимо вписыватся в указанные сроки?

    Этот вопрос уже, на самом деле, выходит за рамки планирования как такового, и переходит в раздел "как решать проблемы человеческого общения". В любом случае, даже если начальство генерирует волюнтаристские планы и отказывается эту практику менять, разработчики могут вести свой собственный план, и пользоваться им. В зависимости от отношений с начальством его можно прятать, а можно наоборот показывать всякий раз, говоря, что вот наш-то план как раз удался. Причем, прятать — это не партизанщина, это так же нормально, как не грузить начальство другими подробностями своей работы: названиями алгоритмов, структурой объектов...

    P.S. То, что начальство согласилось, лично мне очень приятно :-).

  5. Voldemar

    хорошо если можно составить план и сообщить о сроках, а если необходимо вписыватся в указанные сроки?

    Планирование полезно и в этом случае. План поможет показать начальству, какие из планируемых фич реально разработать к указанному сроку, понять, привлечение каких ресурсов позволит выдержать сроки, и в конце концов выяснить, стоит ли овчинка выделки.

    А уж реакция начальства на предъявленные разработчиками планы зависит, как справедливо заметил Иван, от взаимоотношений в коллективе. Если цели разработчиков и начальства кардинально различаются (например, когда руководству главное слупить денег за проект с клиента, а не сделать успешный, формирующий положительный имидж фирмы продукт), то усилия, направленные на достижение одной, не помогут в реализации другой.

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

  6. [...] Маниакальный Веблог » Планирование планированию рознь Одну из недавних статей, посвященную планированию, мне очень хочется прокомментировать. (tags: планирование sagalaev) [...]

  7. Alex V. Koval

    <blockquote cite=""><p> Даже дедлайны, которые являются сутью традиционных “планов”, на самом деле тоже имеют смысл. Они, например, могут быть продиктованы какими-то внешними причинами, и их действительно нельзя нарушать </p></blockquote>

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

    Deadline - это понятие для заказчика а не для девелопера. Это сам заказчик должен рулить что он хочет видить в версии X продукта на дату Y а что нет. А задача команды разработки - давать timeline по тому списку задач, хотя бы приблизительный.

  8. Денис Шаповаленко

Добавить комментарий

Format with markdown