Зачастую разработчики, особенно неопытные, теряются, когда их просят обозначить сроки выполнения задач. Однако умение планировать — очень полезный и нужный навык, который помогает не только в работе, но и в жизни. Мы решили узнать у экспертов, как научиться правильно планировать и сдавать проекты вовремя.
Михаил Адигеев, руководитель отдела программных разработок и поддержки ГЭНДАЛЬФ:
Для максимально точной оценки нужен опыт реальной разработки, причём именно в конкретной области. Но есть и общие правила, которые помогут избежать ошибок в планировании и проблем при сдаче работы заказчику. Я бы описал эти правила так.
Во-первых, нужно понять задачу. Это вроде бы очевидно и не относится напрямую к оценке сроков, но на самом деле это ключевой момент. Даже в серьёзных крупных проектах одним из основных факторов неудачи и затягивания сроков является проблема в определении требований. У начинающих разработчиков, к сожалению, это серьёзная проблема — не читают ТЗ или читают и понимают очень избирательно (из десяти пунктов запомнили и выполнили пять, а про оставшиеся вспомнили уже при сдаче результата). Понятно, что неправильно понятую задачу невозможно правильно реализовать в срок.
Далее — оценить само время на разработку. Особенность программирования в том, что не бывает абсолютно одинаковых задач. Это делает нашу работу интереснее, но оценку сроков — сложнее. Здесь хорошо работает декомпозиция, т.е. разделение сложной уникальной задачи на последовательность маленьких знакомых подзадач. А каждую из них уже можно оценить в часах достаточно адекватно. Сложим оценки подзадач — и получим оценку всей задачи.
Как правило, такая оценка включает в себя только затраты непосредственно на кодирование. Это, безусловно, самая важная часть разработки, но далеко не единственная (а часто — и не самая объёмная). Полное выполнение задачи включает в себя еще чтение и прояснение ТЗ, встречи с коллегами или заказчиком, отладку и тестирование, составление документации, сдачу результата (демонстрацию заказчику и возможные переделки по его замечаниям). Сколько именно времени у вас уйдёт на эти действия, подскажет только опыт. На первых порах важно, как минимум, не забыть их учесть в расчётах, а примерную оценку времени можно спросить у более опытных коллег.
Итак, мы берём оценку трудозатрат на кодирование, добавляем оценку затрат на дополнительные работы — и получаем искомую оценку времени на выполнение задачи. Но и это ещё не всё! Нужно обозначить планируемую дату завершения задачи. Ошибкой будет просто взять и разделить трудозатраты (в часах) на 8 часов и прибавить к текущей дате. В реальной практике разработчик никогда (ну ладно, почти никогда) не работает 100% времени над одной конкретной задачей. У вас обязательно будет уходить время на другие работы — важные, но не связанные напрямую с главной. Например, помощь коллегам, обучение, составление отчётов и т.п. Обычно при планировании считают, что непосредственно на работу над текущим проектом уходит 60-70% рабочего времени. Дополнительно надо учесть ещё возможные задержки, которые не дадут вам непрерывно работать над задачей. Например, если для этого вам нужно взаимодействовать с другими людьми (коллегами, заказчиками), то учитывайте их занятость, график работы и т.п.
Вот основные правила, которые, на мой взгляд, помогут разработчику избежать проблем в оценке и соблюдении сроков. Кроме этого, ключевым является накопление собственного опыта как в реализации задач, так и в оценке. Например, очень полезно после завершения задачи сравнивать свою первоначальную оценку с фактическими сроками и делать выводы на будущее. И, конечно, стоит изучить чужой опыт. Я бы порекомендовал по теме книги С. Макконнелла «Сколько стоит программный проект» и С. Архипенкова «Лекции по управлению программными проектами».
Источник: Типичный программист
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
