Как научиться правильно определять сроки выполнения работы — отвечают эксперты

Разработчику обычно требуется учесть сразу несколько параметров, чтобы оценить время выполнения задачи:

1. Опыт выполнения таких заданий и работы с данным технологическим стеком. Если предстоит делать что-то принципиально новое, нужно быть особенно осторожным с оценкой.
2. Опыт работы с данным клиентом. Зная заказчика, можно примерно предугадать некоторые дополнительные требования и объём правок.
3. Качество кода, с которым предстоит работать. Это — самый влиятельный фактор, из-за которого всё может сильно затянуться и вообще пойти не по плану. Если в проекте есть тесты, везде только явные зависимости и функциональность хорошо изолирована, всё не так страшно. Намного хуже, если вы имеете дело с легаси-кодом без тестов или с кодом, перенасыщенным неявными зависимостями. Осложнять дело могут также такие вещи, как «магические функции» (когда по коду тяжело увидеть конечный стек вызовов) и дублирование кода (когда для изменения какой-либо функциональности нужно править несколько независимых участков).

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

К объективной оценке времени, нужного чисто на работу, следует прибавлять небольшой запас для покрытия форс-мажорных ситуаций. Его часто оценивают в процентах от выполнения основной задачи, но у всех он разный: кто-то прибавляет 20 % времени, кто-то — 10 %, а кто-то — 50 %.

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

Методикам оценки трудоёмкости проекта, включая длительность работ и отдельных задач, посвящено большое количество статей. Однако до сих пор это является причиной возникновения конфликтов как внутри проектной команды, так и при общении с заказчиком.

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

Обратите внимание на сопутствующие этапы — если нужно разработать сервис, то в оценку необходимо включить также и юнит-тестирование (а может, и не только юнит), определённое время займёт подготовка тестовых данных. Следует продумать интеграцию с другими сервисами и т. д. Заложите время на исправление дефектов, которые вы найдёте самостоятельно или с помощью тестировщиков. Много времени может утекать в «незаметные» задачи. Например, есть оценка по разработке и есть оценка по тестированию, но передача артефакта на тестирование может быть сопряжена с разворачиванием стендов. Поэтому важно мысленно себе представить весь процесс, чтобы ничего не упустить.

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

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

Вопрос, на который невозможно ответить в краткой форме. Если бы это было просто, то проблемы нарушения сроков не существовало бы.

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

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

Прибегнем к простой аналогии — если вы никогда не копали канавы, вы не можете точно сказать, сколько времени у вас займет выкопать траншею 30 см шириной, 60 см глубиной и 20 метров длинной. Если вы раньше копали, оценка времени работы у вас будет гораздо ближе к фактической длительности работы.

Вторая причина — программисты по своей природе оптимисты. То есть, рассматривая задачу, подбирая для неё вариант реализации, давая оценку доработкам, разработчик ожидает, что всё будет работать так, как он предполагает. И не думает о тех проблемах, что ему встретятся на пути. Зачастую он и не может их предвидеть. Например, есть задача, которую программист может реализовать, используя стороннюю open-source программную библиотеку. На этапе оценки он нашел её в интернете, прочитал её описание — она ему подходит. И он даже верно оценил объём своей работы, чтобы встроить использование этой библиотеки. Но он совсем не предусмотрел, что в окружении его программного продукта в этой библиотеке возникнет ошибка.

Разработчику придётся не только встроить использование библиотеки в свой код, но и исправить ошибку в самой библиотеке. А ещё зачастую разработчик не предусматривает время на исправление своих ошибок. Как показывает статистика, тестирование и исправление ошибок может занимать порядка 50 % от времени, что было затрачено на кодинг. Цифра зависит от квалификации разработчика, окружения, используемых практик разработки (например, юнит тесты существенно это время сокращают и итоговая длительность/трудоёмкость задачи по разработке получается меньше).

Если вернуться к аналогии с землекопом, то землекоп не предполагал, что у него сломается лопата и придётся потратить два часа на поиски нового черенка.

Третья причина — непредусмотренные требования. Ни в одной области материального производства, с которыми так любят сравнивать заказчики разработку ПО, нет такого потока новых требований. Представьте себе пассаж землекопа, который выкопал 19 метров из 20 и услышал от заказчика пожелание, чтобы канава шла не по прямой, а змейкой с длиной плеча 97 сантиметров.

Как со всем этим бороться и как жить в условиях подобной неопределённости? Уменьшая неопределённость и закладывая резерв времени.

Самый простой способ привести свои ожидания ближе к реальности — это использовать шутливое эмпирическое правило «Пи». Получив оценку от разработчика (по срокам или трудоёмкости), надо умножить её на число Пи (= 3,14159). Чем более опытный разработчик делал оценку, тем меньше может быть этот коэффициент.

Обязательной является практика декомпозиции исходной задачи до маленьких задач размером не более 4 часов. Чем детальнее выполнена декомпозиция, тем выше шансы, что оценка окажется близка к фактической трудоёмкости/длительности.
Если вернуться к выделению резерва — это время должно быть выделено в конце проекта. Плохая практика делать резерв и включать его для каждой задачи. Закон Паркинсона «Работа заполняет всё время, отпущенное на неё» выполняется неукоснительно.

Если подвести краткое «итого», то чтобы правильно определить сроки выполнения работы, полезны будут следующие действия:

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

Ну, и помнить, что если факт превышает вашу оценку на 30 % — то это очень хороший результат.

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

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

Далее — оценить само время на разработку. Особенность программирования в том, что не бывает абсолютно одинаковых задач. Это делает нашу работу интереснее, но оценку сроков — сложнее. Здесь хорошо работает декомпозиция, т.е. разделение сложной уникальной задачи на последовательность маленьких знакомых подзадач. А каждую из них уже можно оценить в часах достаточно адекватно. Сложим оценки подзадач — и получим оценку всей задачи.

Как правило, такая оценка включает в себя только затраты непосредственно на кодирование. Это, безусловно, самая важная часть разработки, но далеко не единственная (а часто — и не самая объёмная). Полное выполнение задачи включает в себя еще чтение и прояснение ТЗ, встречи с коллегами или заказчиком, отладку и тестирование, составление документации, сдачу результата (демонстрацию заказчику и возможные переделки по его замечаниям). Сколько именно времени у вас уйдёт на эти действия, подскажет только опыт. На первых порах важно, как минимум, не забыть их учесть в расчётах, а примерную оценку времени можно спросить у более опытных коллег.

Итак, мы берём оценку трудозатрат на кодирование, добавляем оценку затрат на дополнительные работы — и получаем искомую оценку времени на выполнение задачи. Но и это ещё не всё! Нужно обозначить планируемую дату завершения задачи. Ошибкой будет просто взять и разделить трудозатраты (в часах) на 8 часов и прибавить к текущей дате. В реальной практике разработчик никогда (ну ладно, почти никогда) не работает 100% времени над одной конкретной задачей. У вас обязательно будет уходить время на другие работы — важные, но не связанные напрямую с главной. Например, помощь коллегам, обучение, составление отчётов и т.п. Обычно при планировании считают, что непосредственно на работу над текущим проектом уходит 60-70% рабочего времени. Дополнительно надо учесть ещё возможные задержки, которые не дадут вам непрерывно работать над задачей. Например, если для этого вам нужно взаимодействовать с другими людьми (коллегами, заказчиками), то учитывайте их занятость, график работы и т.п.

Вот основные правила, которые, на мой взгляд, помогут разработчику избежать проблем в оценке и соблюдении сроков. Кроме этого, ключевым является накопление собственного опыта как в реализации задач, так и в оценке. Например, очень полезно после завершения задачи сравнивать свою первоначальную оценку с фактическими сроками и делать выводы на будущее. И, конечно, стоит изучить чужой опыт. Я бы порекомендовал по теме книги С. Макконнелла «Сколько стоит программный проект» и С. Архипенкова «Лекции по управлению программными проектами».

При оценке и планировании сроков необходимо:

1. Декомпозировать задачу до небольших функциональных кусков таким образом, чтобы было чёткое понимание, сколько времени займёт разработка каждого такого куска.
2. Параллельно с декомпозицией обязательно будут возникать дополнительные вопросы по функциональности, которая не была описана в постановке задачи. Необходимо получить ответы на такие вопросы, т. к. это напрямую касается объёма работ и, следовательно, сроков.
3. К итоговой оценке добавить какой-то процент рисков. Это определяется опытным путём. Можно начать, например, с рисков размером в 10–15 %.
4. Понять, сколько часов в день программист готов выделять на выполнение задачи.
5. Делим итоговую оценку на количество часов, которые выделяем в день, и получаем количество дней, необходимых на реализацию.
6. Ориентируемся на календарь и необходимое количество дней на выполнение. Учитываем выходные и другие дни, когда программист не сможет заниматься задачей, а также дату начала работ (не всегда разработчик готов взять задачу в работу в тот же день). Таким образом, получаем дату начала и окончания работ.

В нашей компании планирование задач всегда проходит несколько этапов. На стороне бизнеса мы формулируем 5–6 стратегических целей на год. Это высокоуровневые задачи, например повысить какой-либо параметр на столько-то процентов. Далее различные подразделения компании формируют бизнес-задачи на все команды ИТ. Сроки по этим задачам получают первичную грубую оценку, которая часто формируется всеми участниками команды — менеджером, аналитиком, разработчиком и тестировщиком. Получив эту оценку, бизнес приоритезирует задачи, учитывая стратегические цели компании. В этом помогают сквозные стратегические цели, с ними становится очевидно, что все мы работаем на какое-то общее дело, нет такой ситуации, когда кто-то тянет только в свою сторону. Из точно оцененных по срокам задач мы собираем спринты. У некоторых команд они квартальные, у некоторых — месячные. Нескольким задачам, по предварительной оценке попадающим в следующий спринт, команды дают точную оценку. Крупные задачи разбиваются на более низкоуровневые, за каждую из которых отвечает конкретный исполнитель, именно он и даёт точную оценку.

На данном этапе важно не забывать добавлять запас времени на исправление багов, ведь не ошибается только тот, кто ничего не делает. Это прекрасно понимают и Product Owner, и бизнес-заказчики. При этом требуемый запас времени должен быть адекватным: никто не поймёт разработчика, который поставит простой задаче слишком длинный срок исполнения, его попросят обосновать решение. Самое сложное — объяснить бизнесу, зачем нужно время на рефакторинг. Мы благодарны нашей компании за то, что периодически нам это удаётся, ведь в конечном счёте рефакторинг ведёт к облегчению инфраструктуры и наведению порядка в коде, что повышает стабильность системы и может существенно ускорить разработку новых функций.

Иногда ошибки в оценке всё же возникают. Отделу разработки в крупных компаниях с развитой инфраструктурой полностью избежать этого, на мой взгляд, невозможно. В данном случае важно, чтобы разработчик вовремя информировал о происходящем своего менеджера, а тот, в свою очередь, успел предупредить бизнес и что-то «переиграть» в общих планах компании. В таком режиме работать намного более правильно, чем судорожно пытаться сделать за 3 дня то, что занимает 5, а потом утонуть в большом количестве ошибок, возникших из-за подобной спешки.

Правильный ответ на обе части вопроса [как научиться правильно планировать и сдавать проект вовремя — Ред.] — опыт. Других путей «познания Дзена» не существует. Согласно теории принятия решений, сколько-нибудь точные умозаключения можно строить только на основе анализа ряда уже имеющихся данных. И чем больше этих данных — тем точнее итоговый прогноз и оценка.

Говоря словами Герберта Шоу: «Опыт — это школа, в которой человек узнаёт, каким дураком он был раньше». Отсюда следует достаточно простой вывод: если у программиста уже есть коррелирующий с поставленной задачей опыт — он может опереться на него, если нет — на опыт «коллег по цеху».

Далее нужно понимать, что прямое планирование сроков — задача, с которой люди справляются очень и очень плохо, особенно в разработке. При оценке сроков сдачи хорошей практикой считается введение «поправочных коэффициентов» на исходную оценку. Данная метрика может колебаться в интервале от 1,5 до 3, в зависимости от опыта разработчика и совокупности степеней неопределённости задач, решаемых в рамках проекта.

При определении сроков важно учитывать многие факторы.

Например опыт работы. Насколько чётко вы представляете себе объём предстоящих работ? Делали ли ранее что-то подобное? Понятно, что чем больше опыта, тем быстрее работа будет выполнена.

Немалую роль в определении сроков играет грамотно составленное техническое задание. С этим в нашей сфере дела обстоят очень туго. Часто клиент сам не знает, чего хочет, поэтому я советую потратить лишний день-два, но добиться от клиента чёткого представления о желаемом результате. Важно, чтобы это представление было обоюдным. И только после этого можно начинать оговаривать сумму и сроки.

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

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

Выстроить чёткий план гораздо сложней, чем определить срок выполнения отдельно взятой задачи. При этом важно не только сдать проект вовремя, но и сделать так, чтобы разработанная вами система корректно решала задачи бизнеса. Здесь ИТ-командам помогают различные методологии разработки ПО: от RUP и MSF до SCRUM и других Agile-форматов. Выбор инструментов весьма обширен, и многие наши заказчики хотят заранее понимать, как мы будем с ними работать в проекте, каких принципов мы придерживаемся.

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

Agile-команда всё планирует вместе и определяет оптимальный уровень трудозатрат, которые понадобятся для решения той или иной задачи. Например, одна из техник называется «Poker Planning», где каждый участник анонимно даёт свою оценку необходимых трудозатрат по конкретной задаче. После этого команда определяет средний вес задачи в story points или человеко-часах и распределяет дела по принципу «кому что нравится». При этом ежедневно команда собирается на 15-минутный митинг, когда каждый за пару минут рассказывает о статусах своих текущих задач, в том числе сообщает о возникших трудностях. Обнаруженную проблему команда быстро устраняет, поэтому и заказчик смотрит на очередной этап работы программиста максимально оперативно. Разработчики не затягивают со сроками выполнения задач из-за нежелания лишний раз дёргать команду или тщетных попыток разобраться самостоятельно, убивая драгоценное время. Кстати, на таких мини-статусах у разработчиков появляется желание проявить себя с лучшей стороны, показать, что ты ответственно подходишь к работе. Это реально мотивирует и самодисциплинирует.

Программисту необходимо научиться хорошо вникать в текущий проект — это самое важное. Нужно быть не только технически квалифицированным специалистом, но и немножко менеджером, думать наперёд, понимать, какие именно элементы системы затронет решение поставленной задачи, насколько глубоко затронет. Например, в каких-то случаях поменять 1 строку кода достаточно, а в других — лучше переписать сразу целый модуль.

Также надо учитывать качество проработки архитектуры.

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

Когда все навыки и менеджерское мышление складываются воедино, то приходит понимание сроков выполнения работы.

Прежде всего необходимо убедиться, что вы правильно поняли цель — у вас и у вашего заказчика должны быть одинаковые ожидания от результата. Для этого полезно согласовать так называемый DoD (Definition of Done). Формулировку задач полезно проверять на соответствие критериям, заложенным в принцип SMART.
Если задача объёмная, её необходимо декомпозировать на подзадачи, так, чтобы трудоёмкость выполнения атомарных задач была не более нескольких дней.

Проекты мы советуем разбивать на этапы, двигаясь к цели итеративно и инкрементально, в этом лучше всего вам помогут гибкие методологии (Agile). Будьте ближе к заказчику, не уходите «в себя», будьте открытыми, демонстрируйте промежуточные результаты с ценными для заказчика доработками, валидируйте их соответствие ожиданиями заказчика, не бойтесь изменений: цели по мере продвижения могут уточняться, а иногда и меняться. Но не перегибайте палку — не нужно обращаться к заказчику по каждому пустяку, необходимо обеспечить для него такой уровень вовлечённости, которой будет для него комфортен.

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