Разработка на коленке

"тут должна быть красивая цитата о программировании"

Сроки, планирование и точные оценки

2010-03-24 15:41

В работе программиста есть такая штука как сроки разработки, которые нужно определить заранее, и которые нужно выдерживать. Проблема планирования сроков есть у всех. У кого-то получается вложиться в срок, у кого-то нет. Часто планы меняются, но это не отменяет процесса планирования. И от программиста всегда хотят услышать заветные цифры, когда ж он сделает работу. Хотят все: заказчики, менеджеры, технические директора, в общем - начальство.

Выдать правдивые сроки, которые можно выдержать - самое сложное, потому что каждый проект - это что-то новое. Либо новые технологии, либо новая предметная область, либо алгоритмы, либо... Да мало ли этих "либо".

Для того, чтобы получить адекватную оценку работы я стал использовать разбиение на очень подробные задачи, вплоть до вызова функций.

Например, нужно написать редактор карт помещений на Flash для какой-нибудь системы наблюдения. Тогда я сажусь и пишу:

  • Шаблон приложения. 2 часа.
  • Загрузка картинок с сервера. 4 часа.
  • Загрузка данных о наблюдаемых объектах. 3 часа.
  • Создание картинок для наблюдаемых объектов. 2 часа на каждую разновидность. 5 разновидностей. Итого 10 часов.
  • Интеграция с HTML. 4 часа.
  • JavaScript-интерфейс для вызовы функция A, B и C. 6 часов, по два на каждый метод.
  • Ну и так далее.
  • ...
  • Анимация объектов. НЕТ ОЦЕНКИ. Нужны исследования. 4 часа.

Преимущества такого подхода:

  • очень мала вероятность обмануть себя самого и поставить маленький срок, которого не хватит;
  • у руководства нет манёвра для сокращения сроков, потому что расписана каждая задача, даже исследования неизвестных частей;
  • если сроки всё же сократят без объективных причин, а просто потому что так захотелось, то это уже не будет проблемой разработчика
  • такой план - более подходящий плацдарм для обсуждения проекта, чем "я сделаю всё за месяц", так как "всё" понятие расплывчатое;
  • такая подробная подготовка покажет и руководству и заказчику, что вы вникаете в работу и знаете, с какой стороны к ней подступиться.

Я несколько раз делал следующую штуку. Берусь за новую задачу. Делаю оценку путём прикидывания и медитирования (как делают многие программисты), причём оценку пессимистичную, и пишу необходимое время на листок бумаги. Потом оцениваю всё, расписывая каждую микрозадачу или микроисследование (не всё же можно точно предсказать) и пишу этот срок на листок бумаги. Второй срок всегда больше, даже если вторые оценки оптимистичные. При этом, в первом подходе всегда есть соблазн сократить срок, поддавшись оптимизму, а во втором случае, сокращать некуда, так как всё подробно расписано.

comments powered by Disqus