С оценкой времени выполнения задачи в программировании все сложно. Менеджерам очень важно знать точный срок, за который работа будет выполнена. Программисты этот срок оценить не могут. Обычно это выливается в бесконечные конфликты. Менеджеры считают программистов ленивыми уродами, программисты считают, что менеджеры не понимают их тонкую программерскую душу. Все счастливы.
Но мы не такие! Мы решаем проблемы, а не ищем виноватых. Мы ищем способ, а не причину. Мы не жалуемся на Злую Судьбу, Законы Вселенной и не вздыхаем обреченно "оно всегда так".
Эта статья ориентирована прежде всего на программистов. Со стороны менеджеров тоже требуются определенные усилия - например, если менять постановку задачи каждый день, то оценить время станет сильно сложнее. Но на этом я останавливаться не буду.
Итак, как обычно происходит оценка сроков? Вот очень распространенный сценарий. Программиста спрашивают "сколько времени этой займет?" Ответ ожидается прямо сейчас, у программиста есть несколько секунд на раздумья. У него в голове возникает некий срок. Пускай будет "три недели". При этом программист отбрасывает время, нужное для отладки, учитывается только время кодирования. Потом внутренний голос говорит ему "Ты же крут! Какие три недели! За две справишься!". "Две недели" - отвечает программист. После этого начинается торг. Менеджер пытается уменьшить уже сильно заниженный срок. В итоге они сторгуются на неделе. Это просто какой-то срок, взятый с потолка, который выполнен не будет.
Через некоторое время становится очевидным, что данные оценки по срокам не выполнялись никогда. Программист приходит к выводу, что оценить время выполнения работы невозможно. Мысль "я не умею, значит это невозможно" гораздо приятнее мысли "я не так крут, как мне казалось, эта задача занимает гораздо больше времени".
Увы, я не знаю волшебных заклинаний и HOWTO как всегда со стопроцентным попаданием рассчитывать сроки. Но есть несколько известных мне приемов, которые ситуацию с оценкой сроков улучшают значительно. Я их все использовала, опробовала на себе. Все они требуют активного сотрудничества между менеджером и программистами. Если такого сотрудничества нет, попробуйте делать временные оценки для себя. Это полезный навык, может потом пригодиться.
Оценка времени программирования задач в часах
Этот способ рекламировал Джоэл Спольски у себя в блоге. Там вы найдете его подробную статью об этом: Evidence Based Scheduling. Разбиваем задачу на подзадачи, оцениваем время каждого этапа в часах.
Если вы привыкли брать сроки с потолка, то оценки по этому методу будут получаться пугающе большими. Это нормально.
Временные отсечения
У нас есть задача, требующая определенных исследований. Наши программисты ни разу такое не делали. И вообще не представляют как это делать. Мы начинаем исследование и бросаем его в определенный срок. Например, 20 мая. Если до этого времени не успели - все. Даже если "почти все готово", даже если "вот сейчас заработает". Откатываемся к предыдущей версии. Беремся за следующую задачу.
Разработка по спирали
Наверное, у этого способа есть какое-то умное название. Задача как можно быстрее получить работающую версию продукта. В случае игры - играбельная версия, один уровень, почти без графики, без спецэффектов, без меню или с убогим меню. А потом уже на нее навешиваем фичи. Добавляем спецэффекты. Делаем оптимизацию. Разработка получается гибкой. Мы на ранних этапах можем отказаться от каких-то фичей, от спецэффектов.
Предоставить другую информацию
Если программист не знает когда задача будет выполнена, то зачастую он может назвать срок, в который она точно выполнена не будет. Этого может оказаться достаточно менеджеру, чтобы принять какое-то решение. Например, перенести собрание или вовсе отказаться от выполнения этой задачи. Можно побеседовать и выяснить, что программист может предложить некое решение, которое можно сделать очень быстро, но оно будет обладать существенными недостатками. Например, не будет работать в некоторых случаях или будет работать очень медленно. Его можно будет использовать в качестве заглушки. Зачастую бывает лучше продемонстрировать медленно работающую программу, чем вообще ничего не продемонстрировать.
Постмортемы
После окончания проекта полезно сверить реальные оценки с теми, что были напланированы и попытаться уяснить где были допущены ошибки и почему. Что нужно сделать, чтобы их не повторить. Очень важно тут не скатиться к поиску виноватых.
Это нужная вещь, потому что научиться делать хорошие оценки с первого раза вряд ли получится. Это итеративный процесс. Постепенно будет получаться все лучше и лучше.
Пример из жизни
В одном очень критичном по времени проекте я оценивала время в часах, по Спольски. И там действительно счет шел на часы. Проект вышел вовремя, при этом сразу же были порезаны минорные фичи, когда по оценкам стало ясно, что они занимают неприлично много времени.
Для того, чтобы лучше понимать нужды менеджера полезно бывает что-нибудь отменеджить. Если вам предоставится такая возможность, то вы увидите, что важен не столько срок, сколько общий контроль над процессом. Пускай что-то пойдет медленнее, чем ожидалось, главное, что мы можем этим управлять, знаем причины, знаем как на это влиять. Главная цель - удержать контроль над ситуацией.
Atom feed