Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 10 153 веб-студии, 892 CMS, 217 374 сайта.
РегистрацияCMS MagazineВход
CMS Magazine CMS Magazine

Почему программисты ошибаются в оценке сроков?

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

1Время чистое и время грязное

Когда программист оценивает задачу, он обычно мыслит категориями «чистого» времени. «Можно сделать, если заниматься этим пять часов подряд, без перекуров и перерыва на обед». В реальности «чистого» времени почти никогда не бывает (люди должны переключаться, питаться, ходить в туалет и пр.), а если программист работает в коллективе, то не бывает вообще никогда. При этом объём «грязи» может достигать совершенно невообразимых размеров, если коллектив дружный, а программист участвует в нескольких задачах одновременно. Тогда перерывы на «быстрое общение у кофемашины» органично переплетаются с отвлечениями на внезапные «Коля, срочно, на пять минут, исправь тут по-быстромууууу!», и время идёт, а основная задача все не закрывается.

2Производительность

Отдельным пунктом идёт вопрос производительности. При оценке программисты обычно исходят из классного самочувствия, высокой работоспособности, и не делают скидок на неожиданное «что-то сегодня калган не варит» и «да, понедельник день тяжёлый...». Но из реальности эти явления никуда не деваются, и ВНЕЗАПНО на типовую задачу уходит в два раза больше времени, чем обычно.

3Исследования

Это, наверное, самое страшное для сроков дело. Выглядит оно так: программист оценивает задачу в три часа, напряжённо работает и заканчивает только через восемь. На вопрос «Почему?!» объясняет, что в процессе возникло альтернативное и очень многообещающее решение, и на его рассмотрение ушла куча времени. Но, к сожалению, это решение не подошло, в итоге делать пришлось так, как планировалось изначально.

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

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

4Сложные системы

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

5Исправление ошибок

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

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

6Составные и нетиповые задачи

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

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

Более-менее точная оценка может быть дана после предварительного исследования задачи, которое само по себе требует времени. Т.е. при возникновении задач новых, «не имеющих аналогов», нужно не требовать от программиста быстрой и точной оценки сроков, а ставить предварительную задачу «провести оценку».

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

Более-менее приблизить оценку составной задачи к реальности можно, только если оценить отдельно каждую из подзадач, а итоговое время рассчитывать уже как их сумму, с соответствующими «добавками» как на каждую задачу, так и на их итоговое сопряжение.

7Оценка под давлением

Наш список причин некорректной оценки времени будет неполным без упоминания такого замечательного явления как «Клиентское давление». Это ситуация, когда заказчик (внутренний или внешний) так или иначе влияет на оценку. Например, даёт понять, что хочет услышать оптимистичное «Завтра будет готово!», ну или что-то типа этого.

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

Итого

Резюмируем.

Первое: программистская оценка без применения специальных «поправочных коэффициентов» действительно может оказаться очень неточной.

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

Третье: таки да, к первоначальной программистской оценке времени нужно относиться сдержанно, не считая её высеченным в граните обязательством. Эту оценку можно внести в план, чтобы получить повод потом покапать программисту на мозги (если вас интересуют такие развлечения), но на самом деле ориентироваться на больший срок.

От редакции



Автор рассказывает о причинах срыва сроков. А мы (редакция) можем вам рассказать про то, насколько актуальна эта проблема. Согласно исследованиям CMS Magazine, вот уже несколько лет пролет мимо дедлайна происходит почти в 40% случаев!

Хотите снизить риски? Обращайтесь к проверенным студиям. Например, к участникам рейтинга веб-студий.

Отгадайте, сколько сайтов мы ежегодно изучаем, чтобы составить данный рейтинг? Десятки тысяч. Причем рассматриваются работы более четырех тысяч веб-студий Беларуси, Украины и, естественно, России. И все для вас!

Автор: Андрей Коновалов, HR-Journal.ru (Управляющий партнёр)

Комментарии экспертов

Дмитрий Ничипорчук

Компания: Time Design
Должность: Руководитель

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

Статья понравилась, так как разложила все по полочкам.
Теперь проще будет объяснять клиентам, что при кажущейся стандартности задачи, есть свои нюансы. Большинство не понимают это. Так как думают, что работа вся шаблонная и делают ее роботы.

Василий Румянцев

Компания: Студия Валерия Комягина
Должность: Технический директор

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

Совершенно другой вопрос заключается в том, что необходимо сделать для того, чтобы сократить пропасть между оценкой сроков линейным программистом и реальным сроком исполнения задачи? Мы, полагаясь на собственный опыт, могли бы рекомендовать следующие действия:

  1. Просветительская работа с программистами — люди должны понимать, почему компании важна честная и объективная оценка сроков. Кроме этого, они должны знать о «подводных камнях», описанных в этой статье. Для того, чтобы уметь оценивать сроки, важно знать, как это делать — и эту статью можно использовать как краткое руководство.
  2. Выделение отдельного времени для изучения всего проекта и отдельной задачи.
     
  3. Обязательная фрагментация сложных задач — отказ от этого этапа, по нашему мнению, является одной из критических составляющих некорректной оценки сроков.
     
  4. Отказ от оценки задач с большим числом неопределенных факторов. Иными словами, если не до конца понятно, что нужно сделать, значит время для оценки сроков еще не наступило. Перед оценкой сроков жизненно важно предельно конкретизировать постановку задачи.
     
  5. Критическое отношение к прогнозируемым срокам со стороны руководителя проекта (умножайте хотя бы на 1.5 ... а лучше — на 2 :-)
     
  6. Если речь идет об оценке сроков по всему проекту (бывает и такая необходимость), пятый пункт мы реализуем, как включение поправочной строки «риски», которая, как правило, включает как раз поправочный коэффициент по всему объему задач — можно и так поступать, чтобы не заниматься микро-менеджментом с каждой задачей.

Кирилл Тавониус

Компания: "Wide-Web"
Должность: Руководитель отдела интернет-маркетинга

Почему взяли именно программисты?

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

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

 

Денис Германенко

Компания: CleverPumpkin Ltd.
Должность: CEO

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

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

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

 

Евгений Голубев

Компания: Red Graphic
Должность: технический директор

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

Любой программист вам скажет о необходимости «слиться» с задачей. Программист берёт задачу и тратит некоторое время на осознание и построение «виртуальной модели» в своей голове. Затем начинается процесс реализации этой модели, которая видоизменяется в процессе реализации. Время на осознание и построение модели зависит от сложности и стандартности задачи для разработчика.

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

Решить эту проблему могут не только поправочные коэффициенты, но и наличие строгого процесса, а также менеджер ресурсов, планирующий людей на работы.

Артур Кротов

Компания: Nimax
Должность: Технический директор

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

Для того, чтобы вводить точную поправку на названный программистом срок, менеджер может использовать планирование с учётом прежних результатов — Evidence Based Scheduling. Смысл EBS состоит в том, чтобы по каждому программисту накапливать данные оценок сроков и отклонений этих оценок от реальных сроков и по методу Монте-Карло строить прогноз.

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

Если вдаваться в детали, то про EBS можно написать отдельную статью. Подробный разбор на английском есть в материале «Evidence Based Scheduling».

Андрей Рыжкин

Компания: AGIMA
Должность: Руководитель отдела разработки

В статье в принципе все описано правильно и достаточно подробно.

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

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

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

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

Ольга Русакович

Компания: Webway
Должность: Заместитель директора

Ошибаются в оценке сроков не программисты, а люди любых профессий, опыт работы которых в компании меньше 4-5-ти лет. На программистов это тоже распространяется, потому что их средний опыт работы меньше, часто 1-3 года. Не ошибаются люди, опыт которых лет 10 и выше, причем опыт не по профессии, а опыт именно в этой компании или именно в этом бизнесе, ибо они на подкорке предвидят все нюансы, которые могут возникнуть. Парадокс в том, что даже если человек с опытом работы от 10 лет никогда не был программистом, он все равно не ошибается в оценке сроков по программированию :-). В частности в нашей компании никакие разработчики не привлекаются к оценке сроков, это делают люди с опытом около 12-ти лет. И они никогда не ошибаются :-).

Если Вы хотите дать экспертный комментарий к статьям, публикуемым на CMS Magazine, следите за анонсами материалов в нашей группе в Facebook.

Комментарии (Facebook)

Комментарии (5)

Анатолий      Создано: 2.11.2012, 14:32          

Работаю фрилансером. Могу подписаться лишь под ошибками, которые не входят в план, но обычно заканчиваю работу примерно за день до сдачи, что бы обнаружились ошибки. Никогда я не нарушал сроков за свой стаж в 4 года, разве что в самом начале по неопытности. Полный бред то что срок нужно умножать на 2. Я сказал 7 дней, значит я рассчитал возможные проблемы, время работы, отдых итд. И в итоге за 6 дней я делаю заказ, показываю заказчику, и там уже смотрим ошибки если возникают, вдвоем же легче. Те кто работает с людьми которые кормят завтраками - удаляйте их контакты. Здесь сказано мнение о безответственных исполнителях, но никак о людях которые правильно рассчитывают свои силы и являются специалистами в своем деле.

Гость      Создано: 2.11.2012, 15:08          

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

Ваш же опыт основан только на взаимодействии заказчика с исполнителем в единичном лице - вы один и вы фрилансер. Несколько не корректно проводить такое сравнение.

Анатолий      Создано: 2.11.2012, 15:16          

Ну а то за проф. команда разработчиков, которая сидит и алялял мы веселые ребята, мы крутые профи. Зачем таких брать на работу? Любой человек понимает если в срок попадает праздник - то тогда нужно делать поправку на срок т.к. алкоголь все дела, как это человек не считает свой обед, туалет и покурить, я просто не могу представить. Это безответственные программисты. И раз уж статья про команды написана почему в заголовке темы это НЕ указано? почему автор всех подгребает под одну кучу этим понятием. Нужно было назвать так как назвал выше Александр Коваленко.

Антон      Создано: 2.7.2013, 18:58          

Бухали бы меньше - вкладывались бы в сроки.

Артур Кондратьев      Создано: 2.6.2015, 18:36          

Опыт человека в любой профессии оказания услуг да и не только напрямую зависит на точность определения времени решения задачи с учетом всех туалетов...покурить неожиданностей и т.д.
Статья - я бы назвал - Отмазаsmile.gif - почему мы говорим 30 дней, а отдаем через 60.
Просто у нас еще как в РФ - в штате полтора специалиста - понтов и ЧСВ директора овер 1000. Все обещают и т.д. А нанять или поделиться с подрядчиками - если не успевают - жаба душит. Чисто бизнес по-Русски
Оглашать срок выполнения задачи выше - пропорционально шансу на то, что от услуг откажутся.
У нас в РФ - так все работает. Европейский(Азиатский, Американский) подход - но с реализацией на уровне Самали (утрирую). Короче много красивых слов- терминов галстуков и т.д. но очень редко это соответствует качеству исполнения - в том числе и определение срока.
ИМХО)
это по всем сферам за ооочень редким исключением.

В фирмах - особенно по веб программированию и т.д. должны работать первоклассные психологи и комьюнити менеджеры.

Заказчик не обязан вникать в сложности исполнителя. Его задача во время оплатить услуги. И сказать что он хочет на доступном ему языке.

При чем тут дядя заказавший себе лендинг - его задача сказать что там будет (тематика) и оплатить во время.


CMS Magazine CMS Magazine
RSS-подписка комплексные решения
CMS Magazine CMS Magazine
CMS Magazine