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

Это были вводные, теперь перехожу конкретно к нашим фейлам.

Ошибка № 1: работы мы оценили в сумму, за которую сейчас делаем корпоративные сайты, поскольку представляли проект как простой сайт с личным кабинетом. Ну, максимум с интеграциями.

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

Затем команда собиралась приступить к написанию ТЗ и программированию минимально работающего прототипа (МРП). Но клиент заявлял о сжатых сроках и утверждал, что работать надо без ТЗ, по уже написанной логике проекта...

Ошибка № 2: мы согласились — боялись потерять интересный проект и клиента.

Полное ТЗ показало бы в 2-2,5 раза больший объем работ. Клиент, вероятно, знал об этом и потребовал перейти к программированию, манипулируя сроками и разрывом контракта.

Ошибка № 3: не обсудили с заказчиком видение готовности МРП. Мы считали, что МРП — это сайт с работающими основными функциями. С точки зрения заказчика МРП — готовый и протестированный продукт (бета-версия без дизайна). Из визуализации имелся только прототип, поэтому верстали на шаблонах bootstrap, а начинку программировали на основании имеющейся скудной информации.

Когда заказчик определился с платежной системой и требованиями работы с ней (например, холдирование карты для безопасной сделки), мы поняли, что внедрение сервиса потребует еще как минимум половину бюджета, который уже заканчивался.

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

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

Выводы и советы коллегам:

— настаивайте на написании полного ТЗ со спецификациями баз данных и описанием методов;

— разбейте договор на этапы;

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

Это поможет увидеть четкую картину проекта и не фейлить, как мы. Удачи!

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

Но, несложно это было технически. А на организацию процесса нам пришлось потратить примерно год.

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

Какие выводы мы сделали исходя из этого опыта? Много всяких. Один из самых важных: считать нужно сразу. Сегодня это стало довольно просто и есть масса соответствующих инструментов. И нет смысла их игнорировать, если ваша цель — расти, сохраняя рентабельность бизнеса.

Был такой проект — мы автоматизировали субъект РФ, выполняли поручение Президента. Взяли на контроль около 700 млрд рублей в режиме онлайн. Отслеживаем каждую копейку и фиксируем каждое нарушение (в т.ч. коррупционное). Не выполнить поручение Президента нельзя, а вот трудоемкость принесла в итоге 7 млн рублей чистого убытка. Но репутационные плюсы дали нам новые заказы и компенсировали предыдущие издержки.

Поэтому, я считаю: не надо бояться потерять 5-10-15 млн. Если вы делаете работу хорошо и чувствуете, как все устроено, свои затраты, вы, возможно, «отобъете», а то и выйдете в плюс.

На оценку проектов всегда влияют минимум два фактора:

1. Взаимоотношения с клиентом,

2. Нестандартность/сложность проекта.

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

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

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

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

Мне кажется, у любой студии есть или были фейловые проекты.

Был случай, когда мы взялись за перевод сайта в адаптив, запланировали месяц на работу, а по факту получилось 6 месяцев. Ошибка была в том, что не составили технического задания. На момент подписания проект казался простым, но позже оказалось, что не все так просто. А поскольку ошибка была с нашей стороны, мы завершить проект в ущерб себе без увеличения стоимости. Заказчик ведь не виноват, что мы посчитали неправильно.

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

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

Поэтому рекомендую коллегам делать как минимум прототип в AXURE. Или как вариант — разрабатывать «кейсы», в которые уже входит определенный объем работы и зафиксированная стоимость. Это особенно хорошо подходит для готовых решений на базе шаблонов.

Чтобы свести ошибки к минимуму, необходимо оценивать каждый из этапов проекта и сразу вписывать в договор возможное увеличение стоимости на +10%. При этом важно объяснять заказчику, что это увеличение стоимости будет, если со стороны заказчика появятся новые требования к проекту, которые будут фиксироваться дополнительным соглашением к договору.

Если вам предстоит сделать какую-то работу, которую вы ни разу не делали (хитрую синхронизацию, парсинг и т.п.), то это необходимо выделять в отдельный этап. Это необходимо для того, если вы сделали проект классно и подписывали акты после каждого из этапов, но на последнем этапе случились проблемы. То ли вы неправильно оценили этот этап и на него надо не 10 часов, а 100 часов, то ли заказчик некорректно объяснил, что ему нужно. В общем произошла неприятная ситуация, а в таких ситуациях искать надо не виноватых, а компромисс и пути решения проблемы. И даже если вы не найдете общий язык, то на основании актов сможете получить оплату за весь проект, за исключением последнего этапа. Главное помните, всё должно быть зафиксировано на бумаге, на не на устных договоренностях.

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

Когда мы делали первый интернет-магазин, срок в 2 месяца казался даже завышенным. А сейчас дедлайн в 3 месяца нас сильно настораживает, так как все наши крупные магазины были в работе минимум полгода.

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