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

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

Сооснователь 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 два года делала зарядку, в итоге ничего не вышло. А это всего лишь зарядка, которых на рынке сотни! 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.