Статья была написана три года назад но так и пылилась в черновиках. Публикую без изменений. Много воды утекло с тех пор. Однако может быть мой опыт кому-то пригодится.
Хочу обсудить проблемы, связанные с предварительной оценкой времени и сроков проектов. В этой статье я расскажу как обстоят дела на проекте, который я веду немногим более 5 месяцев. Я приведу некоторые свои мысли, объясню какие эксперименты с оценками я делал и какие выводы получил по пришествию этого срока.
Но сначала пару слов о себе. Мне 26 лет, я рaботаю в текущей компании чуть более четырех лет. Компания — типичный аутсорсер со штаб-квартирой в штатах. До этого (с 2002-го) я сменил 3 веб-студии.
Fixed Fee vs Time & Material
Так уж сложилось, что у нас в компании не любят Fixed Fee проекты. Причин тому много, но, по-большому счету, все упирается в неправильную первоначальную оценку как бюджета так и сроков. Это выливалось в проваленные сроки и убытки. Поэтому мы изо всех сил старались все проекты делать по схеме Time and Material — считали сколько времени потратили и умножали на стоимость часа. В этом случае мы ничем не рискуем когда у нас в корне неверные оценки бюджета. В самом худшем случае мы говорим клиенту “Простите, мы ошиблись в оценке. Мы не учли вот это и это, к тому же вы захотели переделать вот это и это. Поэтому ваш проект обойдется вам в Х раз дороже”.
Однако, не всех заказчиков устраивает ситуация, когда невозможно спрогнозировать бюджет. И я их понимаю. О каком финансовом планировании в компании может идти речь если вы не знаете во сколько вам обойдется “создание сайта”? Наш опыт показал что единственный действенный случай для успеха бессрочных проектов — это когда ваши услуги обходятся клиенту сравнительно дешево и его устраивает выкладывать какую-то небольшую сумму ежемесячно. Это напоминает ситуацию когда у вас нет достаточно денег что бы сделать ремонт всего дома целиком. И вы годами делаете ремонт частями — по-немногу каждый месяц, насколько хватает свободных средств.
Такие проекты могут тянуться очень долго: у заказчика постоянно возникают какие-то идеи и изменения. Вы их выполняете, затем у него рождаются новые идеи и так по кругу. До тех пор пока он с легкостью оплачивает счета.
Однако это неприменимо к новым проектам. Заказчик хочет увидеть результат как можно скорей. И, естественно, потратив как можно меньше средств.
Социальная сеть
Поэтому когда к нам пришел заказчик и сказал что хочет узнать сколько будет стоить сделать “социальную сеть” мы улыбнулись. Наметился тренд. Дело в том, что до этого мы делали… тоже социальную сеть.
Мы сказали что это займет очень примерно 3-4 месяца у 4-6 разработчиков и умножили цифру на нашу почасовую ставку что бы очертить порядок бюджета. Если вам нужно привлечь нового заказчика — такой вариант срабатывает почти всегда (если у них действительно большой проект) и они соглашаются начать разработку.
Когда выяснилось, что клиент ни в какую не соглашается на Time and Material я уже не улыбался. Было не до шуток. Задача по оценке бюджета социальной сети с нечеткими требованиями мягко говоря нетривиальна.
Еще интересным фактом было то что заказчик начинал разработку в другой компании, где ему сделали весь дизайн, сверстали большинство страниц в HTML и сделали первоначальную оценку дальнейшей стоимости работ. Потом они что-то не поладили и каким-то образом нашли нас. Таким образом у нас был готовый дизайн, частично готовый HTML (относительно сносного качества) и список функциональных возможностей системы.
Мы приняли решение взять этот список и прикинуть сколько времени может потребоваться на каждую из них. Мой американский коллега применил следующую методику: по 8 часов на страницу + какое-то количество общих часов (40-120) на отдельно взятую подсистему. Так, если под личные сообщения было сверстано 5 разных страниц то это выливалось в 80-100 часов работы.
Да, эта оценка была очень грубой. В последствии я подсчитал что она отличалась от реально потраченных часов в среднем в 2.25 раза. Сразу я очень был не доволен этой оценкой и понимал что она не адекватная. Однако полезность этой оценки я понял позже. Для более детальной оценки нужно потратить много дней на то что бы вникнуть в каждую возможность системы, увязать их между собой, учесть все возможные нюансы в пограничных условиях и т.д. А это сделать фактически невозможно — документации либо технического задания просто нет и не будет. Заказчик обсуждал все с предыдущей командой и у него уже постоянно есть ощущение “мы же это уже обсуждали”. И он считает что из макетов можно узнать что и как система должна делать. Со временем я понял что плохая и грубая оценка лучше чем ее отсутствие. А хорошую оценку во многих случаях сделать просто невозможно. Проект в процессе своего развития постоянно изменяется. Изменяются и требования к его функциям, внешнему виду и т.д. Соответственно должна меняться и первоначальная оценка. И именно поэтому первоначальные сроки и бюджеты просто не могут быть точны.
Хотя, бывают и исключения. Один из наших проектов — система учетов рисков для очень крупного швейцарского банка. Их бюрократия просто идеальна для нас. Они сначала утверждают все необходимые изменения, четко документируют их и только затем присылают их нам на оценку. В этом случае мы точно можем просчитать смету ибо все требования известны, все четко документировано и ничто уже до сдачи проекта не изменится. Но так бывает крайне редко. Это скорее исключение их правил.
Смета
Итак, при составлении сметы нашей социальной сети мы решили пойти не совсем обычным путем. Мы решили делать все функциональные системы отдельными фазами. Каждая фаза обсуждается, оценивается и утверждается заказчиком непосредственно перед ее выполнением. Когда мы составляли представление по наборе задач мы могли уже достаточно точно оценить время на их выполнение и составить коммерческое предложение по этим задачам. Таким образом у нас получилось нечто среднее между Time & Material и Fixed Fee.
Раньше с Fixed Fee проектами я особо дел не имел и поэтому мне было крайне интересно научится трезво их оценивать. Среди разработчиков постоянно ходили шутки вроде “возьми эстимейт, умножь на два а лучше три и получишь что нужно”. Шутки — шутками, а как же все обстоит на самом деле? Это мне и предстояло выяснить.
Раньше я дробил задачи на максимально мелкие подзадачи, оценивал их, складывал сумму, умножал на магические цифры (добавлял 10% на deployment, 10% на тестирование и 10% на management&communication). Полученную цифру умножал на текущую стоимости часа работы разработчика и озвучивал цифру клиенту.
Если что-то шло не так то это было не критично — ведь это была лишь оценка стоимости проекта и мы работали по Time and Materials поэтому убытка просто не могло получится. Клиент все оплатит в любом случае. С Fixed Fee так не получится. Мужик сказал — мужик слелал. Сказал, что сделаешь за $5000 — будь добр сделай за $5000. Даже если это заняло вдвое больше времени чем планировалось.
Поэтому по завершению первого же набора фаз (их делали разные люди) я начал собирать все данные для статистического анализа и строил всевозможные интересные для меня графики.
Проблема
Первые же цифры показали что дело — дрянь. Мы в убыте. Но почему?
Первый эстимейт был паршивый. Это было очевидно. К тому же американское руководство в процессе работы потребовало что сайт был полностью AJAX без единой перегрузки страницы. А мы этого не учитывали при оценке. Мы считали что сделаем несколько отдельных страниц со своими ajax-вызовами. И мы были вынужденны переделывать много вещей так, что бы перегрузки страниц не было вообще.
Подумав, я увеличил коэффициенты и добавил еще одни новый — прибыль. Я его добавил под влиянием какой-то статьи то ли на хабре то ли еще где-то. Ведь помимо оплаты труда мы должны получить еще и прибыль, верно? :) С новыми коэффициентами мы выполнили еще три фазы (они шли параллельно). Попутно я вел работу с разработчиками, старался выяснить причины просрочек и исключать их. По завершению этих фаз графики показали что мы перестали терять деньги такими сумасшедшими темпами. Однако все еще разработчики тратили больше времени на выполнение задач чем предполагалось сметой. Это меня заинтересовало. Почему?
Провалы сроков
Я наблюдал следующую картину. Разработчик получает задачу на 8 часов. И он тратит на нее 8 часов. Ровно 8 часов. Иногда больше, но почти никогда — меньше. Потом показывает результат и этот результат нуждается в доработке. Я его отправляю переделывать и после второй или третей итерации я получаю удовлетворительный результат. К этому моменту сроки уже превышены. Просьбы показывать заранее и т.д. не возымели эффекта. И я пошел на хитрость — немного занизил выделенное время на задачу.
На 8-часовой задаче занижение эстимейта на 1-2 часа никто не заметил. Выделил шесть часов — разработчики по-прежнему тратил шесть часов, приходил и потом доделывал. Так мы стали кое-как вкладываться в сроки. Затем я пошел дальше и дошел до сокращения сроков вполовину. И это работало! Иногда, правда, ребята начали приходить и жаловаться что не успеют сделать задачу за такой срок и им понадобится больше времени. Я спрашивал сколько, они отвечали что еще 1-2 часа, получали мое согласие и делали в этот новый срок. А по итогу — получалось что делали быстрее чем начальный эстимейт. Процентов на 10-15% быстрее, а не на 15-20% дольше как это было раньше. Однако, это не очень хорошо сказалось на их настроении. Они были напряжены и нервничали из-за того что они не вкладываются в выделенное время. Я решил так кардинально не играть со сроками и просто занижаю их на четверть когда заполняю систему учета задач.
Дальнейшим шагом был переход к оценке задачи исполнителем. Раньше я сам оценивал сколько займет задача времени и сам выставлял сроки. Со временем, я перешел к схеме когда я только составляю список задач, мы их обсуждаем и разработчики говорят сколько времени у них займет их реализация. Таким образом я избавился от фраз типа “Не мы же оцениваем задачи! Вот поэтому и не вкладываемся в сроки!”. Теперь они оценивают свои задачи и с них весьма честный спрос если они сорвали сроки. Однако как занизить срок, который разработчик сам себе выбрал? Я перенес это занижение в коэффициенты, на которые в последствии умножаю общую сумму часов.
Итог
Постепенно, после всех итераций и разбирательств, мы вышли из фазы потерь и перешли к фазе зарабатывания денег. Сейчас мы почти полностью компенсировали первоначальные потери и вот-вот перейдем к чистой прибыли (получим стоимость часа большую чем при Time & Material). И знаете какрй я сделал вывод после 5 месяцев работы над этим проектом? Хочешь заработать денег — умножай предварительную оценку на три.
Автор: kuzmuk
