«За две недели хороший программист сделает из экскрементов мамонта и палок более-менее годный проект». Как разработчики оценивают сроки (+Рекомендации)

9 комментариев
«За две недели хороший программист сделает из экскрементов мамонта и палок более-менее годный проект». Как разработчики оценивают сроки (+Рекомендации)

dev.by спросил у продуктовиков и аутсорсеров, как они оценивают сроки реализации проектов. 

​исследования

Склонность человека нереалистично оценивать сроки давно интересует исследователей. Даниэль Канеман и Амос Тверский назвали это явление «ошибкой планирования». Роджер Бюлер и его коллеги решили измерить ошибку планирования. Они попросили студентов, которые работали над дипломными проектами, предсказать дату их завершения. Большинство указало цифру на 64 процента ниже итоговой. Исследователи нашли аналогичные ошибки планирования среди биржевых маклеров, инженеров-электриков и врачей. Они также обнаружились в планировании повседневных дел, таких как рождественские покупки или уплата налогов. Бюлер указывает на два фактора, которые обусловливают разрыв между намерениями и результатами:

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

Сооснователь Rubyroid Labs Валентин Завадский: «Мы же не машины, которые конвертируют кофе в код»

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

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

Есть конкретные методологии для оценки проекта, но не уверен, что они гарантируют 100-процентный результат.

Моя любимая методика расчёта носит имя Bobuk’а, Григория Бакунова.

По теме
Все материалы по теме

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

3.14 х 1 (месяц) : 2 = 1.57 (месяца). Правда, к этой цифре Бобук рекомендует всегда добавлять ещё 2 недели.

Почему? Если вдруг окажется, что вы дошли до точки Б, а ваш проект не готов, то за 2 недели любой высококвалифицированный программист сделает из экскрементов мамонта и палок более-менее годный проект.

Знаю, что некоторые компании перешли на оценку тикетов по принципу размеров одежды: S —1-2 часа, M — 3-4, L — 4-8. В продуктовых командах часто оценивают не часами, а Story points. И в этих виртуальных поинтах вы живёте и понимаете, что 1 поинт — задача попроще, 13 — сложнее. Мне кажется, это интересный подход, помогает уходить от часов. Заодно можно измерять производительность команды от недели к неделе. 

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

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

Перед началом проекта мы рисуем диаграмму Ганта, чтобы визуализировать таймлайн. Периодически используем белорусский продукт GanttPro.

По теме
Все материалы по теме

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

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

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

Технологические риски тоже учитываем: например, если технология молодая. Иногда даже крупные игроки целыми командами на этом этапе проваливаются. Помните, как Apple два года делала зарядку, в итоге ничего не вышло. А это всего лишь зарядка, которых на рынке сотни! 

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

Качество эстимации проекта измеряем при помощи единственной метрики — доволен заказчик или нет. Первоначальные цифры были увеличены в два раза? Это не имеет значения, если заказчика всё устраивает.

​Рекомендации

  1. Большие задачи делить на маленькие, каждую из них оценивать отдельно и накидывать сверху риски. 
  2. Лучше завысить ожидания, чем занизить. Если сказал, что сделаешь за час, а сделал за три — плохо, а если наоборот, то хорошо.  
  3. Никогда не нужно давать точную цифру. Лучше оценивать в промежутке: от 2 до 5 часов, потому что может случиться всякое, например, упал GitHub, и ты два часа не работал. 
  4. Соблюдайте баланс скорости и качества: не пытайтесь сделать проект за 500 часов, в то время как все компании делают за 1000. 

Глава геймдев-направления в Gismart Андрей Михлин: «5 дней на задачу — это значит, что разработчик не представляет, как её реализовывать»

По теме
Все материалы по теме

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

В моей практике сроки затягиваются примерно в 90 процентов случаев. Даже в NASA дедлайны порой не соблюдаются, потому что нет смысла идти к цели путём человеческих жертв. 

В Gismart мы обычно начинаем планирование с составления диаграммы Ганта, в которой описываем все объекты и взаимодействия между ними. Затем этот документ рассылаем на всю команду, каждый может внести свои коррективы. После этого собираемся на митинг, посвящённый оценке спринта. Участвуют в этом сами сотрудники, PM и Team Lead — это необходимый минимум. 

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

10 дней на задачу — это очень много. Даже 5 дней — это уже значит, что разработчик не представляет, как её реализовывать. Задачу нужно разбивать так, чтобы она укладывалась в день-два. Если разработчик тычет пальцем в небо, допустим, 5 дней, дня нас это сразу красная лампочка, говорящая о том, что над задачей нужно ещё поработать и разбить на более мелкие. 

Мы оцениваем задачи по трём векторам: оптимистично, пессимистично и реалистично. А потом с помощью нехитрой формулы рассчитываем некую приближенную к правде цифру. Художники обычно чаще попадают в цель, примерно в 90 процентах случаев, потому что у них, как правило, уже есть опыт реализации похожих артов. С разработчиками сложнее: если мы делаем продукт с новой механикой, то скорее всего у них не было аналогичного опыта, поэтому они будут исследовать тему, и мы должны заложить время на ресерч. 

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

На простых задачах процент риска снижается, на сложных — увеличивается. Например, человек говорит, что ему нужно два дня для реализации фичи, а ты понимаешь, что он юный, горячий и ничего не знает о программировании, и подход у него такой: сейчас шашкой махнёт и вперёд с песней. Цифру таких разработчиков можно сразу умножать в несколько раз. Люди всегда излишне оптимистичны, особенно джуниоры. Чем опытнее специалист, тем более взвешенно он к этому подходит и тем более реалистичные сроки называет. 

В Gismart игровое направление появилась недавно, поэтому у меня ещё не было возможности проверить все свои идеи на практике.

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

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

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

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

​Рекомендации

  1. Если хотите уложиться в срок, нужно запускать максимально простой и безрисковый продукт. 
  2. Не стремитесь сразу делать что-то супернавороченное и загрузить проект огромным количеством фич. 
  3. Чем раньше запустился продукт, тем быстрее вы сможете понять, нужен он кому-то или нет. Но не всегда раньше значит лучше. Не гонитесь за планом в ущерб качеству. 

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

В Беларуси задержали шеф-редактора интернет-проектов российского «Ельцин Центра»
В Беларуси задержали шеф-редактора интернет-проектов российского «Ельцин Центра»
В Беларуси задержали шеф-редактора интернет-проектов российского «Ельцин Центра»
1 комментарий
На студента БГУИР завели уголовное дело. Он уехал
На студента БГУИР завели уголовное дело. Он уехал
На студента БГУИР завели уголовное дело. Он уехал
В Минске задержали 25+ студентов БГУИР. Один — в больнице со сломанной лодыжкой
В Минске задержали 25+ студентов БГУИР. Один — в больнице со сломанной лодыжкой
В Минске задержали 25+ студентов БГУИР. Один — в больнице со сломанной лодыжкой
1 комментарий
Чемоданова: работник госпредприятия «сливал» данные силовиков
Чемоданова: работник госпредприятия «сливал» данные силовиков
Чемоданова: работник госпредприятия «сливал» данные силовиков
7 комментариев

Обсуждение

2

Есть хорошая книжка по оценке: Стив Макконнелл - Сколько стоит программный проект. На английском - Software Estimation: Demystifying the Black Art
by Steve McConnell.

Там собраны и структурированы многие полезные советы и методы к котором вы так или иначе придёте.

В целом, активно занимаюсь оценкой проектов и с удовольствием поделюсь опытом. Пишите в личку.

Anonymous
Anonymous
0

У Дубакова был как-то отличный лонгрид на эту тему. https://tinyurl.com/y2tywete. Если вкратце, то эстимация и оценка продуктивности вообще не работает при оплате за человеко-часы в условиях неопределенности или продуктовой разработки да и вообще меняет сознание, что отработка человеко-часов будет в приоритете перед продуктом. Как я понял Михаил не очень-то и эстимирует. Интересно, а изменилось ли у него мнение на этот счет, и как он там в Fibery теперь строит планы? Он ведь тут читает иногда статьи и коменты, может и ответит.

0

Там статья вероятнее всего всё-таки о другом.

В целом, я думаю если у кого-то что-то не работает, то как обычно это во многом связано с его личным видением ситауции и личным опытом включая непринятие/неприятие некоторых подходов.

И ещё - магия работает у того кто в неё верит )

1

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

1

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

1

Все методики по эстимейту это шлак. Единственная методика это максимальная проработка требований и архитектуры, а дальше пальцем в небо основываясь на своём опыте.

Александр Коротыш
Александр Коротыш Директор в ООО "Эни Реквест"
-1

Лепилы с опытом (PHP/Python) пишите на почту, экскременты для работы найдем. :)

0

«За две недели хороший программист сделает из экскрементов мамонта и палок более-менее годный проект».
Однозначно в цитатник.
Двусмысленно получилось:
1. Наш специалист "переварит" ваши "экскременты мамонта и палки" за 2 недели сделают из него конфетку.
2. Хороший программист за 2 недели возьмет "экскременты мамонта и палки" и сделает вам по быстрому полусырой проект.

amok
amok Team Lead в 2018-05-01
0

Согласен с gismart. Если вы не знаете, что и как вы делаете, то не сможете дать оценку и выпустить в срок. Все участники процеса должны иметь одинаковое понимание требований, а конечные исполнители детально понимать что они будут делать, и в каком порядке.

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже