Работая над крупным, постоянно развивающимся проектом, почти ежедневно имею дело с различными формами утверждения задач: от «Очень срочно, поправь тут. За час уложишься?» до «Оцени, на сколько недель потянет эта задачка». Я, как исполнитель, сам оцениваю время и сложность выполнения каждой задачи и считаю это единственным правильным подходом к оценке фронта предстоящих работ в сфере разработки ПО.
Но, наблюдая за многими проектами — сторонними, о которых пишут в статьях и блогах, а также проектами соседних отделов компании, вижу что разные руководители проектов применяют разные подходы к оценке сроков выполнения задач. И не всегда они совпадают с моим отношением к этому делу.
Обобщив накопленную по теме оценки сроков информацию, получил следующие принципы оценки сроков выполнения работы:
Соблюдая данные принципы, становится виден свет в конце туннеля даже до первой строчки кода. Непосредственный исполнитель (или исполнители, в случае групповой разработки) сам разбивает общую задачу на подзадачи для более точной оценки и сам же указывает риски для каждой из подзадач. Таким образом, сложив время на каждую из подзадач, можно получить очень оптимистичные сроки выполнения всего объема работы. Эти сроки умножаются на риски и получается примерное время, необходимое на всю работу целиком. Главное, чтобы эти принципы понимал не только исполнитель, но и заказчик, иначе он захочет сыграть с исполнителем в «угадайку».
В процессе выполнения задачи могут появиться обстоятельства, требующие дополнительного времени на решение. Например, выясняется, что архитектура системы не позволяет решить задачу «быстро и красиво», и группе разработчиков приходится выбирать: делать хаки и множество другой лишней работы, усугубляющей состояние системы в целом, или предложить ведущему проекта сделать рефакторинг необходимых модулей.
Оба решения очевидны, как и то, что второе более приемлемо в долгосрочной перспективе. Сложность ситуации в том, что некоторые ответственные за принятие решений люди думают, что все в фирме играют в «угадайку»: раз программист назвал срок, должен в него уложиться. И его не волнуют изменившиеся обстоятельства, ему важнее «спихнуть» ответственность за сроки на исполнителя, чем постараться найти оптимальное решение общей проблемы.
Почти у каждого проекта своя архитектура и свое наследие (обычно «тяжелое»), поэтому при оценке задачи разумно делать поправку на специфичность проекта. Одно дело, когда проект молод, продуман, а код написан с дотошным соблюдением всех норм и правил проектирования и кодирования, и совсем другое дело, когда проект в непрерывной разработке уже лет 5, за которые сменилось десятки разработчиков, написавших сотни тысяч строк кода методом «лишь бы заработало».
Чем запутаннее архитектура и неряшливее существующий код, тем больше риск не соблюсти сроки выполнения задачи. В таких случаях я вижу решение в вводе специальных коэффициентов, на которые умножается предварительная оценка времени на задачу.
Сколько бы опыта не было у человека, ставящего задачу разработчику, сроки ее реализации он может только «прикинуть», слишком много нюансов необходимо учесть в каждом конкретном случае: новый это функционал или доработка существующего, гибкость архитектуры системы и качество существующего кода, специфичность подхода к решению задачи в рамках конкретного проекта.
А если постановщик задачи не имеет технического образования, сроки выполнения задачи он может только угадать. И делать это он может разве что из любопытства — угадает или нет, потому что практической ценности такая оценка не имеет.
Все дело в том, что некоторые менеджеры проектов пытаются лично поставить сроки программисту на выполнение конкретной задачи, что в принципе абсурдно. Корни этого невежества идут из непонимания специфики работы в IT-сфере: только системный администратор может прикинуть срок, за который он настроит сервер, и только программист может сказать время, которое будет затрачено на задачу. Дело менеджера — управлять задачами, а вот процессы внутри задачи уже не в его компетенции.
Есть ряд задач, которые должны предусматривать возможность переноса функционала на другие проекты. Если у компании несколько проектов и оцениваемая задача должна быть выполнена в рамках каждого из них, настало время пересмотреть оценку сроков и сложности данной задачи.
Во-первых, требование «универсальности» должно быть заявлено сразу, а не после того, как задача уже вошла в стадию реализации. Если заказчик захочет сделать функционал универсальным на одном из поздних этапов разработки, это приведет к переписыванию немалой части кода, а следовательно — к пересмотру сроков.
В моей практике был случай, когда уже по завершении сложного механизма для одного из проектов, заказчик захотел применить его на другом проекте и, получив ответ о специфичности реализации задачи, посетовал на то, что функционал сделан не универсальным. Но это уже тяжелый случай…
Отдельно хочется упомянуть случаи, когда постановщик задачи (заказчик) считает себя профессионалом, хотя на самом деле на это даже не претендует. Такой заказчик не верит ни во что из обозначенного в этой статье и полагает, что способен сам оценить сроки выполнения задачи с точностью до минуты, даже не имея достаточного количества технических знаний.
Лучше отказаться от дел с подобным самодурством. Это лучший выход для всех: исполнитель избавляется от нереальных сроков, заказчик после бессчетных попыток таки умерит свой «профессионализм».
На моей памяти был случай, когда руководство хотело «заморозить» один вялый и абсолютно не прибыльный проект, после некоторой доработки функционала. У программистов попросили оценку задачи, те оценили ее без рисков — выдали очень оптимистичный, минимальный срок. Когда начали «копать» поняли, что попали на серьезный рефакторинг. После бессонных ночей в офисе и работы по субботам-воскресеньям, сроки в итоге были соблюдены, но с небольшими недоделками. За эти недоделки от начальства последовал вердикт: программеры сорвали названные ими же сроки. Налицо игра в «угадайку», никто не желал слышать ни о каких рисках.
Программисты сами подставили себя, в итоге их дополнительно также обвинили в убыточности проекта и разгильдяйстве, а само руководство зато хорошо выглядело на совещании с инвестором, свалив убыточность проекта на безалаберность команды разработчиков.
Но, наблюдая за многими проектами — сторонними, о которых пишут в статьях и блогах, а также проектами соседних отделов компании, вижу что разные руководители проектов применяют разные подходы к оценке сроков выполнения задач. И не всегда они совпадают с моим отношением к этому делу.
Принципы
Обобщив накопленную по теме оценки сроков информацию, получил следующие принципы оценки сроков выполнения работы:
- Конечную оценку задаче может дать только непосредственный исполнитель;
- Оценки времени всегда слишком оптимистичны;
- Оценить целиком время на задачу, требующую дробления на подзадачи, невозможно.
Соблюдая данные принципы, становится виден свет в конце туннеля даже до первой строчки кода. Непосредственный исполнитель (или исполнители, в случае групповой разработки) сам разбивает общую задачу на подзадачи для более точной оценки и сам же указывает риски для каждой из подзадач. Таким образом, сложив время на каждую из подзадач, можно получить очень оптимистичные сроки выполнения всего объема работы. Эти сроки умножаются на риски и получается примерное время, необходимое на всю работу целиком. Главное, чтобы эти принципы понимал не только исполнитель, но и заказчик, иначе он захочет сыграть с исполнителем в «угадайку».
Угадайка
В процессе выполнения задачи могут появиться обстоятельства, требующие дополнительного времени на решение. Например, выясняется, что архитектура системы не позволяет решить задачу «быстро и красиво», и группе разработчиков приходится выбирать: делать хаки и множество другой лишней работы, усугубляющей состояние системы в целом, или предложить ведущему проекта сделать рефакторинг необходимых модулей.
Оба решения очевидны, как и то, что второе более приемлемо в долгосрочной перспективе. Сложность ситуации в том, что некоторые ответственные за принятие решений люди думают, что все в фирме играют в «угадайку»: раз программист назвал срок, должен в него уложиться. И его не волнуют изменившиеся обстоятельства, ему важнее «спихнуть» ответственность за сроки на исполнителя, чем постараться найти оптимальное решение общей проблемы.
Индивидуальный подход
Почти у каждого проекта своя архитектура и свое наследие (обычно «тяжелое»), поэтому при оценке задачи разумно делать поправку на специфичность проекта. Одно дело, когда проект молод, продуман, а код написан с дотошным соблюдением всех норм и правил проектирования и кодирования, и совсем другое дело, когда проект в непрерывной разработке уже лет 5, за которые сменилось десятки разработчиков, написавших сотни тысяч строк кода методом «лишь бы заработало».
Чем запутаннее архитектура и неряшливее существующий код, тем больше риск не соблюсти сроки выполнения задачи. В таких случаях я вижу решение в вводе специальных коэффициентов, на которые умножается предварительная оценка времени на задачу.
Игры разума
Сколько бы опыта не было у человека, ставящего задачу разработчику, сроки ее реализации он может только «прикинуть», слишком много нюансов необходимо учесть в каждом конкретном случае: новый это функционал или доработка существующего, гибкость архитектуры системы и качество существующего кода, специфичность подхода к решению задачи в рамках конкретного проекта.
А если постановщик задачи не имеет технического образования, сроки выполнения задачи он может только угадать. И делать это он может разве что из любопытства — угадает или нет, потому что практической ценности такая оценка не имеет.
Все дело в том, что некоторые менеджеры проектов пытаются лично поставить сроки программисту на выполнение конкретной задачи, что в принципе абсурдно. Корни этого невежества идут из непонимания специфики работы в IT-сфере: только системный администратор может прикинуть срок, за который он настроит сервер, и только программист может сказать время, которое будет затрачено на задачу. Дело менеджера — управлять задачами, а вот процессы внутри задачи уже не в его компетенции.
Универсальность
Есть ряд задач, которые должны предусматривать возможность переноса функционала на другие проекты. Если у компании несколько проектов и оцениваемая задача должна быть выполнена в рамках каждого из них, настало время пересмотреть оценку сроков и сложности данной задачи.
Во-первых, требование «универсальности» должно быть заявлено сразу, а не после того, как задача уже вошла в стадию реализации. Если заказчик захочет сделать функционал универсальным на одном из поздних этапов разработки, это приведет к переписыванию немалой части кода, а следовательно — к пересмотру сроков.
В моей практике был случай, когда уже по завершении сложного механизма для одного из проектов, заказчик захотел применить его на другом проекте и, получив ответ о специфичности реализации задачи, посетовал на то, что функционал сделан не универсальным. Но это уже тяжелый случай…
Тяжелый случай
Отдельно хочется упомянуть случаи, когда постановщик задачи (заказчик) считает себя профессионалом, хотя на самом деле на это даже не претендует. Такой заказчик не верит ни во что из обозначенного в этой статье и полагает, что способен сам оценить сроки выполнения задачи с точностью до минуты, даже не имея достаточного количества технических знаний.
Лучше отказаться от дел с подобным самодурством. Это лучший выход для всех: исполнитель избавляется от нереальных сроков, заказчик после бессчетных попыток таки умерит свой «профессионализм».
История
На моей памяти был случай, когда руководство хотело «заморозить» один вялый и абсолютно не прибыльный проект, после некоторой доработки функционала. У программистов попросили оценку задачи, те оценили ее без рисков — выдали очень оптимистичный, минимальный срок. Когда начали «копать» поняли, что попали на серьезный рефакторинг. После бессонных ночей в офисе и работы по субботам-воскресеньям, сроки в итоге были соблюдены, но с небольшими недоделками. За эти недоделки от начальства последовал вердикт: программеры сорвали названные ими же сроки. Налицо игра в «угадайку», никто не желал слышать ни о каких рисках.
Программисты сами подставили себя, в итоге их дополнительно также обвинили в убыточности проекта и разгильдяйстве, а само руководство зато хорошо выглядело на совещании с инвестором, свалив убыточность проекта на безалаберность команды разработчиков.
