Блог

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


Рабочий день начинается с интуиции 

Очередная планёрка в веб-студии, программисты подтягиваются, а вы уже сидите с блокнотом со списком задач. Ребята делают несчастный вид, у кого-то резко поднимается температура, а ведь сейчас начнётся самое интересное – вы начнёте распределять часы и требовать от программистов спланировать трудозатраты.


Об оценке в программировании



И дальше как повезёт. Программист Вася с 3-х летним стажем оценит самую сложную задачу вплоть до минуты, программист Петя с таким же стажем изречёт: «Ну я точно не знаю…». Разрыв шаблона? Нет, дело в психологии. 


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


Итог: опыт в определённой области + постоянная практика помогут решить задачу «на автомате» и определиться со временем. Это как с вкусным бифштексом – вам достаточно его увидеть, всё остальное сделает за вас желудок.



Можно ли научиться этому? 


Да. Просто делайте то, чему хотите научиться. Постоянно и много. Когда мы устанавливаем для себя временные рамки – мы основываемся на своём опыте, а не на чужом. Этакий своеобразный внутренний замер. Помните, как нас учили в детстве – с утра зарядка и ещё раз зарядка? Так и здесь.


Замеры в программировании



Но не забывайте о том, что даже когда вы «накачаетесь» - вы всё равно будете измерять задачи идеальным сферическим временем. Как будто вы в вакууме. Например, всегда ли вы учитываете при оценке трудозатрат любого программного проекта принципы «где пятая чашка кофе, там и десятая», «прогуляться и размяться» и т.п.? 


Подавляй и властвуй 


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


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



О чём не забыть в оценке? 


1. В 90% случаев срабатывает правило – умножьте расчёты разработчика на два и получите реальные сроки. Причина – идеализация распорядка дня и «роботизирование» человека. 


2. Помните об идеализации времени. Программисты и их оценка трудозатрат на создание какого-нибудь сайта или ПО живут в разных временных измерениях. Разработчик ни ест, ни пьёт и, конечно, не отдыхает. 


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


4. Сложность планирования учёта затрат, которые будут потрачены на исследование и поиск решения. Это актуально, если задача не слишком типовая или сотрудник просто не опытен. 


5. Высокая связность кода. При изменении простого участка кода разработчики могут перелопатить всю структуру. Закладывается ли это в оценку – вопрос риторический. 


6. Ошибки. Ни один человек не признается в том, что намерен совершать ошибки, ломать код и т.п. Это из серии очередных иллюзий. Все мы люди. 


Чужой код


7. Правка связанных или обнаруженных ошибок. Заблуждение из разряда риторических вопросов «планировал ли я править код предшественника». 


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


9. Составные задачи. Сравнить их можно лишь с марафоном. Реальные сроки составных задач всегда больше запланированных, поэтому главный помощник программиста в работе с ними – разбиение на подзадачи и оценка с учётом «утечки времени». 


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


11. Заниженная оценка под давлением. Подобные оценки фатально влияют как на работу программиста, так и на качество кода. Далее цепная реакция: низкая реальная производительность труда, деморализованное состояние, переработка созданного или разработка нового. 


12. «Исправить что-то». Типичная ситуация в веб-студии – исправлено 3 строчки кода, а затрачено на неё 2-3 часа. Почему вместо 15-30 минут на неё ушло столько времени? Всё просто – время потрачено на изучение проблемы, выстраивание логики и структуры в голове.


Автор: Максим Кузнецов, программист отдела высоконагруженных систем


Возврат к списку