Оценка сроков (стоимости) вашего проекта фантазия

У вас есть идея, ваш планируемый сайт, проект. Вы понимаете как он должен работать, какую пользу приносить людям, как и кто им сможет пользоваться. Многие моменты вы продумали и разработали ТЗ, задание для команды разработки (студии, фрилансера).

Для вас проект кажется очевидным и понятным и вы выходите на рынок и выбираете того, кто сможет для вас выполнить эту работу. Как вы оцениваете предложения? Обычно это делают по цене. Вроде эта студия сделает мне сайт за 900 000 рублей, другая команда сделает это за 500 000, а этот фрилансер за 250 000.  Оценивая риски, вы соглашаетесь работать со студией (или фрилансером) за оговоренный бюджет.

В чем здесь проблема? Кто здесь не прав?

Суть в том, что неправы все.

Если ваш проект не является точным клоном (1-в-1) того, что делал фрилансер или студия до этого, то точно оценить трудоемкость работы невозможно. В лучшем случае в оценку заложено в 3 раза больше часов, чем реальная оценка. Таким образом разработчик компенсирует неопределенность. Но это плохо для вас и для него вы переплачиваете, а он несет риск, что даже такая оценка может оказаться неправдоподобной.

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

Ни вы, ни разработчик не может точно определить сколько времени займет разработка сколько-нибудь сложного проекта (я не включаю сюда сайты-визитки, блоги и все те проекты, которые не требуют особых фукнций, модулей и могут быть созданы на основе готовых движков wordpress, magento и т.п.).

Это всегда фантазия, предположение, что наверное, если я что-то типа того делал за 1.5 месяца, то это я сделаю тоже самое где-то за такое же время не работает.

Что же делать с оценками? Как обозначить бюджет заранее?

Ведь это то естественно, вы предполагаете заранее знать сколько вы потратите. Это понятное стремление, но оно не реализуется. По моему опыту, ровно 0% проектов было завершено в тот срок, который был заранее заложен в оценки и согласован обоими сторонами. Просто это так не работает.

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

  1. Изменения

Разработка занимает несколько месяцев и в процессе работы в 99% случаев возникает ситуация, что вы хотите что-то изменить кнопку, модуль, текст, шаблон. Все, что угодно, это ведь не трудно? Да, это не трудно, но любое изменение это неопределенность. Если мы поменяет этот текст как сайт будет смотреться на мобильном устройстве, а на планшете? Я не знаю, нужно тестировать тратить время, работать в сервисе browserstack.com или чем-то подобном. Оп, и мы добавили несколько часов работы тестировщику\дизайнеру. И так в каждой мелочи, чем сложнее изменение, тем больше добавляется работы.

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

  1. Неоднозначность

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

Как правильно подходить к оценке проекта без предоплаты?

Оценка проекта это важно, написание ТЗ это важно, проговаривание всех деталей это важно. Но, это не может быть основанием для финальной оценки бюджета проекта.

Оптимальным решением будет следующий подход итеративная работа. Итерация это короткий цикл от постановки задачи до сдачи результата. Удобнее всего делить весь проект на короткие сценарии использования (user stories). Например, интернет-магазин может иметь такие сценарии (неполный список):

  1. менеджер магазина имеет возможность открыть админку и редактировать категории товаров (добавлять, менять порядок, удалять);
  2. менеджер может добавлять товар в систему через админку (такие-то поля) и присваивать товару любое кол-во категорий (см. сценарий 1.)

Каждый сценарий описывает как пользователи (менеджеры, клиенты) работают на сайте.

Ок, мы составили список таких историй и отсортировали их по приоритету (что делать первым, а что можно отложить). Теперь на каждую итерацию (цикл) мы выбираем сценарии, которые будут созданы. Например, в первую неделю мы договорились, что будут созданы сценарии 1. и 2.

В конце цикла вы смотрите работу, принимаете ее, вносите правки (эти правки будут выполнены в след. цикле, т.е. на следующей неделе). Разработчики неделю работали и воплотили оговоренные две истории в жизнь. Они выставляют вам счет потраченных часов. Ну, например, 40 000 рублей. Вы его оплачиваете и согласуете что будет сделано на следующей неделе.

Т.о. вся работа превращается в короткие дистанции, где каждая сторона уменьшает свои риски.

  1. Вы как заказчик можете в любой момент отказаться от сотрудничества со студией по любым причинам, сохранив у себя уже созданный к этому моменту код (те сценарии, которые были выполнены на прошедших циклах). У вас всегда есть текущая рабочая версия проекта;
  2. Разработчики получают оплату за потраченное по факту время и уменьшают риск неправильной оценки проекта.
  3. Разработчики спокойно и с энтузиазмом относятся к изменениям, т.к. они не зафиксировали стоимость на берегу и работают по коротким циклам. Что будет сделано в следующем цикле запланированные истории или что-то новое, что придумал заказчик неважно.

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

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

P.s. рекомендую вам эту книгу Scrum.

Из нее вы узнаете как подходят к работе в проекте в 21 веке в стартапах и инновационных компаниях.