Всем привет! Меня зовут Антон Репьёв, я основатель IT-компании A2Seven. Сегодня расскажу, почему абсолютно любой проект пойдет не по плану, как при этом правильно его оценить с помощью предпроектной аналитики и сохранить бюджет.
Оценить проект можно только когда он закончился
В 1991 году начался самый масштабный инженерный проект в истории США. Бостон страдал от многочасовых пробок. Шестиполосная автострада в центре города не справлялась и руководство города решило построить новую десятиполосную под землей.
Проект Центральной Артерии тщательно планировали девять лет. Он состоял из тоннеля длиной 2,6 км, нового моста через реку Чарльз и трех крупных развязок. Правительство планировало закончить работы за семь лет в 1998 и потратить на них $2,8 млрд.
Всё пошло не по плану. При раскопках под домами строители находили затонувшие корабли, соленая вода из Атлантического океана постоянно размывала бетонные опоры, а эпоксидный клей для панелей на крыше тоннеля не выдерживал их веса.
Уже на старте в 1991 году бюджет Центральной Артерии вырос до $5,8 млрд. Работы закончились только в 2007 году, на девять лет позже рассчитанного срока. США потратило $22 млрд денег налогоплательщиков с учетом инфляции.
История Бостонской Центральной артерии показывает, что даже девять лет проработки проекта не дают 100% точности оценки. И даже 50% точности. Реальные затраты выросли в десять раз. Причина этому — неопределенность во время оценки.
Как неопределенность убивает проекты
Очень упрощенно можно считать, что проект состоит из идеи, ресурсов для её реализации и потенциальной выгоды. Например компания планирует выпустить «убийцу RAID: Shadow Legends» за год и отъесть кусок рынка мобильных игр.
Когда на руках маленький бриф на две страницы, разработка «убийцы» выглядит привлекательно. После маркетингового исследования и ТЗ окажется, что существуют 20 клонов игры, и можно надеяться только на 1% рынка. Через полгода после старта проекта понадобится два новых программиста, дизайнер и миллион рублей на рекламу.
Каждый проект идёт не по плану.
Не существует способа написать 500 страниц технического задания, выполнить его до строчки, при этом сохранить бюджет и дедлайны.
Когда есть только идея никто не знает нюансов разработки и возможных проблем. Оценка становится точнее, когда мы собираем информацию о проекте и внешней среде. Зависимость точности оценки от количества информации показывает конус неопределенности.
Компании недооценивают большинство проектов, они попадают в нижнюю часть конуса. Но проект можно и переоценить. Например, нужные функции окажутся в бесплатной библиотеке. Тогда вместо месяца разработки уйдет три часа гугления и подключения файлов в проект. На графике позитивные ошибки находятся в верхней части конуса неопределенности.
Конус работает для каждой составляющей проекта: оценки идеи, ресурсов, времени, нужного функционала и потенциальной выгоды. В худшем случае проект окажется в 500 раз сложнее! В реальности крайние значения выпадают редко, и задача может оказаться сложнее всего в 30–40 раз.
Проект с такими ошибками в планировании маленькую компанию обанкротит, а большую отбросит в развитии. Чтобы этого не допустить нужно снизить неопределенность — получить максимум информации до начала разработки. Для этого нужна предпроектная аналитика.
Как предпроектная аналитика снижает неопределенность и экономит бюджет
Предпроектная аналитика — это правильные вопросы и поиск ответов до старта проекта. От самых банальных «кто будет пользоваться продуктом?» до специфичных «как юридически оформить 200 пользователей для интеграции в единую CRM?». О шести самых важных вопросах перед началом разработки, я рассказываю в видео:
Предпроектная аналитика решает три задачи:
- Прорабатывает первоначальную идею;
- Снижает неопределенность, оценивает бюджет и время проекта с заданной точностью;
- Описывает функционал в ТЗ.
После аналитики готова оценка, техническое задание, примерный план разработки и перспективы проекта. На конусе неопределенности это точка с ошибкой не больше 50%. Т.е. аналитика снижает ошибку в десятки раз за небольшую стоимость. Обычно это 2–5% от бюджета.
Теперь руководитель должен решить судьбу проекта. Варианты зависят от долгосрочных и краткосрочных целей компании и ситуации на рынке. Серебрянной пули не существует. Например, если отменять все сложные проекты, компания перестанет развиваться.
Наша команда запустила больше 100 проектов, которые выжили в первые два года после запуска и развиваются сейчас. Их руководители верили в идею, искали способы обойти сложности и всё равно запустить их. Но иногда это невозможно.
Вот два примера из практики, где проекты не запустились так как задумали клиенты.
В А2SEVEN пришел клиент с идеей системы управления проектами в капитальном строительстве. Он хотел взять лучшее от двух существующих систем на рынке и объединить в собственном продукте.
Первоначальный бюджет был больше 40 млн рублей, но у клиента не было ТЗ. Мы договорились провести предпроектную аналитику.
Реальная стоимость оказалась в 3 раза выше, а за 40 млн не получилось бы выпустить конкурентный продукт на рынок. В итоге клиент отказался от проекта. Он потратил меньше 1,5 млн рублей на аналитику или всего 4% от бюджета.
Второй пример — стартап конструктор интернет-магазинов. Через два месяца директор презентовал MVP потенциальным инвесторам.
Предпроектная аналитика показала, что за 2 месяца не собрать вариативный конструктор. Поэтому MVP для инвесторов состоял из трех самых популярных шаблонов интернет-магазинов, которые были заранее запрограммированы. Проект понравился инвесторам и получил инвестиции.
Когда предпроектная аналитика не нужна
Неизвестна потенциальная выгода продукта или идея настолько инновационная, что никто так не делал. Если есть неделя на разработку, то лучше выпустить MVP и отдать его пользователям для обратной связи. Или сделать маркетинговое исследование, анализ конкурентов и CustDev.
Проект по шаблону. Если это сотый сайт-визитка компании на вордпрессе, то оценка от реальности не сильно будет отличаться.
Разработка дешевле предпроектной аналитики. Попробовать, а потом переделать в некоторых ситуациях лучший выход. Если проект маленький и его тест не ломает систему, в бюджет часто умещаются 3–4 возможных переделки.
Предпроектная аналитика поможет руководителю проекта:
— увеличить точность оценки
— превратить идею в план реализации
— контролировать результаты исполнителей
В двух случаях аналитика обязательна:
1. От проекта зависят жизни и здоровье людей. Нельзя тестировать вживую систему управления химической установкой, которая может взорваться и накрыть весь город.
2. Проект меняет старую реализацию. Например переезд на новую БД, или CMS.
Как выбрать компанию для предпроектной аналитики
Общих правил нет. Клиент выбирает индивидуально по цене, реализованным проектам, советам знакомых и отзывам.
Но есть 3 правила, которые позволят избежать множества ошибок:
- Предпроектную аналитику делает будущий исполнитель. У каждого исполнителя свой стек технологий, опыт и процессы разработки. Сделать аналитику в одной компании, а отнести реализовывать в другую можно. Но это откат по конусу неопределенности на одну ступень. Потому что аналитик не знает, что не сможет реализовать команда, без консультации у технического директора.
Например, аналитик назвал срок исполнения месяц и сделал ТЗ. Это значит, что с поправкой на ошибку проект займет месяца полтора. Но в другой компании известно одно — это точно не 1,5 месяца. Реализация может затянуться на полгода, или наработки с похожего проекта ускорят её до недели. - Исполнитель делал сомасштабные проекты. Сложность проекта от масштаба зависит нелинейно. Если 2 разработчика сделали проект за месяц, это не значит, что проект в десять раз сложнее 20 разработчиков сделают за тот же месяц.
- Заказчик вовлечен в аналитику. Никто лучше владельца бизнеса не знает, что ему нужно и как это должно работать. Поэтому если аналитик не задает вопросы, не вовлекает клиента в диалог — это тревожный звонок. Все, о чем не спросили на этапе аналитики всплывет в работе в самый неудобный момент.
Первые две ошибки случились с Бостонской Центральной артерией, о которой я рассказывал в начале статьи. План много раз обновлялся, отклонялся президентом Рональдом Рейганом и запустился через 9 лет.
В 1997 году весь проект перешел к Управлению магистралями Массачусетса. У них не было опыта в реализации проектов такого масштаба, поэтому они взяли для аналитики и помощи еще одного подрядчика. В итоге проект вели две компании без четкого разграничения ответственности по плану 20-летней давности.
Я рассказал об опыте компании в предпроектной аналитике. Мы часто делимся наработками A2SEVEN на вебинарах, конференциях и ютубе. Чтобы не пропустить полезное, заходите в мой телеграмм канал «Айтибиз от Антона Репьева».
#разработка #аналитика #it #оценка_проектов #бюджет #тз
Антон, спасибо за материал, ценно. Скажите, пожалуйста, в 3 месяца отведенных на анализ вы закладываете срок на "разобраться максимально глубоко в тематике" или стараетесь строить свою работу на аутсорсинговых платформах, которые уже имеют опыт/экспертизу в нужных направлениях? И да, 3 месяца - в некоторых нишах это достаточно серьезный срок, что с актуальностью выводов по итогу работы?
Богдан, я не помню, чтобы я говорил, что анализ и аналитика будет занимать 3 месяца. Возможно вы не правильно что-то поняли.
Обычно предпроектная аналитика, конечно сильно зависит от конкретного проекта, занимает 2 - 4 недели. Сюда входят работы по выявлению требований у клиента, выбор и обоснование инструментов и технологий, часто еще проработка ваерфреймов, юзерстори, этапов работы и конечно же ТЗ на основании которого можно уже делать оценки.
Насчет «разобраться максимально глубоко в тематике» или строить работу на аутсорсинговых платформах. На мой взгляд, как глубоко ты бы не старался погрузиться, заказчик или представители заказчика намного глубже в теме. Задача предпроектной аналитике не глубоко вникнуть в тему и стать там экспертами, а вытянуть необходимые данные из экспертов, найти узкие места, и применить уже свою экспертизу в построении ИТ решений. Другими словами, найти инструменты и решения, которые смогут решить задачи клиента, с минимальными рисками.
Норм статья зашла) Спасибо, интересно было почитать
Спасибо, рад что зашла.
Ок, пред проектная аналитика пройдена, ошибка всего 50% погнали разработку, допустим MVP даже подтвердила гипотезу, но как контроллить правильное направление развития, стартапы в целом делятся на две категории в своем развитии - реализация конкретной фичи (путь половины программ в апсторе) и теперь, кто хочет сделать многое, как не распыляться во втором случае и корректировать вектор и ресурсы. Сколько раз нужно корректировать развитие, в какие вехи итд?
Андрей, цель статьи не рассказать как сделать успешный стартап, она вообще не про продвижение, маркетинг и прочее, не про отработку всех гипотез. Более того я сомневаюсь что есть «серебряная пуля», которая будет одним решением для всех стартапов.
Я хотел донести основную мысль – есть идея на миллион баксов, лучше ее разбить, и не начинать сразу с кодинга, если нет четкого понимания как реализовать проект, то необходимо провести предпроектную аналитику, это тоже большой пласт работы, который, почему-то всегда стараются пропустить и сразу нанять разработчиков, дать им направление куда «копать» и потом удивляются почему мы получили не то что хотели, или не получил вообще ничего.
Про развито стартапов вы правильно сказали, но это за рамками данной статьи :)
Тогда ждём ещё статьи 😉
Из своего опыта не могу вспомнить подтверждение этому: "Попробовать, а потом переделать в некоторых ситуациях лучший выход. Если проект маленький и его тест не ломает систему, в бюджет часто умещаются 3–4 возможных переделки.". Можете перечислить или описать какой-то конкретный случай? Интересно узнать.
p.s. "в народе стройку стали звать «Big Dig»", как мне кажется, тут еще созвучно с другим словом)
Да, конечно есть такие случае и их много, думаю что не только в моей практике.
Например однажды к нам пришел клиент и хотел сделать сервис по обработке изображений для e-commerce. Чтобы можно было врезать фон, добавлять тени, кропать и подгонять картинки под разные платформы. Мы начали с ним прорабатывать предпроектную аналитику и поняли, что для реализация полноценной автоматизированной системы его бюджета не хватит. Тогда в процессе он предложил, сделать упрощенную систему и картинки обрабатывались в ручную филиппицами и индусами. Позже, когда он запустился, отработал гипотезу, понял что половина фич, что он хотел вообще не нужна пользователям, получил инвестиции и уже с пониманием переделал сервис и заменил индусов нейроной сетью.
Бедные индусы и филиппинцы
ну почему же бедные, им дали возможность заработать. Лучше уж так, чем с утра до ночи таскать мешки, собирать мусор или пасти коров.
“Если есть неделя на разработку, то лучше выпустить MVP и отдать его пользователям для обратной связи” а какой вам давали самый короткий срок на разработку ?
Так как мы не делаем коробочные решения, то в среднем срок на проработку небольшой MVP обычно занимает около трех месяцев. Но один раз мы сделали MVP для отработки гипотезы создания социальной сети – мессенджера для хиппи за месяц.
Но приложение в итоге не стреляного, но человек не потратил кучу денег на полноценное преложение с масштабированием, сложной архитектурой и прочей на идею, которая нужна была только ему и его друзьям
Чет переусложненно все всегда у студий.
А в чем переусложнение?
Графики, стены текста, модели. А нужно просто брать и запускать. К сожалению, для девшопов такая модель — смерть, ведь жизненно необходимо доить клиентов максимальное количество времени: 3-6-9-12 месяцев, лучше несколько лет.
Когда MVP запускается за две недели, практически любой.
Я с вами не соглашусь насчет «доить клиентов максимальное количество времени». Возможно такие и существуют, но сегодня большинство компаний, по крайней мере из тех что я знаю, заточены именно на помощь клиенту. В наших же интересах, чтобы клиент как можно быстрей выпустил проект на рынок, получил инвестиции или начал зарабатывать, так как потом поддерживать и улучшать приложение он придет обратно к тебе, если ты действительно помог! И сотрудничество может стать долгим. Нет смысла, как вы выражаетесь доить клиентов, особенно на этапе MVP когда у клиента сильно ограниченный ресурс. Надо стремиться стать именно партнером и помогать и тогда будет win win.
К сожалению, чаще всего происходит именно наоборот, далеко не все клиенты понимают, что надо брать и запускать, пусть криво, пусть не оптимально, но их приходится переубеждать иначе они наровятся вставить в MVP все фичи, которые у них в голове. MVP разрастается до невероятных размеров, а потом заканчиваются деньги и... на этом наши полномочия все!
Кому от этого хорошо?!
Как раз на этапе предпроектной аналитики мы и стараемся все выяснить и помочь, и иногда где-то притормозить клиента с его хотелками.