Страница-источник на сайте falconspace.ru
Создание сайта, мобильного приложения или сложного сервиса — это марафон, а не спринт. И многие владельцы проектов сходят с дистанции, даже не добежав до первого финиша. Почему? Потому что с самого начала допускают одни и те же ошибки в планировании.
Эта статья — не про абстрактные теории. Это выжимка из реального опыта и ошибок, которые мы видели в десятках проектов. В ней вы найдете конкретные работающие принципы, которые помогут вам не слить бюджет, быстрее получить обратную связь от пользователей и построить устойчивый продукт. Ваша выгода: вы научитесь отделять нужное от лишнего, не тратить деньги на то, что не взлетит, и выстраивать доверительные отношения с командой разработчиков.
Часто заказчик хочет расписать в ТЗ всё, что только можно представить. «А вдруг пригодится?» — думает он. И это главная ловушка.
Вот почему такой подход — зло:
Правильный подход:
Пример из практики: Один наш клиент хотел сделать маркетплейс с десятками категорий, сложной системой рейтингов и чатом. Мы предложили начать с простого каталога и формы заявки. Запустились за 3 недели. Оказалось, что пользователям не нужен чат, им достаточно просто оставить заявку. Мы сэкономили кучу денег. Если бы делали «по-максимуму» — выбросили бы их на ветер.
Часто вижу ситуацию: у клиента горят глаза, он хочет сделать «проект мечты», но ресурсов (денег, компетенций, времени) хватает только на скромный старт. Это прямой путь к провалу.
Проект — это не спринт, а марафон.
Не пытайтесь выстрелить на короткой дистанции. Если у вас нет запаса прочности по финансам и экспертизе, вы рискуете утонуть. Метафора простая: переплыть океан на надувной лодке теоретически можно, но шансы на успех стремятся к нулю.
Что делать на практике? Умерьте аппетит. Сделайте продукт меньше. Не играйте в «больших дядей», которые живут за счет инвесторов годами. Ваша задача — чтобы проект как можно быстрее начал приносить хоть какой-то доход. Пусть маленький, но стабильный ручеек. Это даст вам возможность бесконечно долго экспериментировать и расти.
Понятно, что хочется знать точную сумму. Но в IT-проектах с постоянно меняющимися требованиями это невозможно. Никто не знает, что за углом: может, придется интегрироваться с новым API, а может, выйдет закон, который запретит вашу рекламу. Все это влияет на бюджет.
Начальные оценки нужны, но относитесь к ним как к прикидке, а не к истине в последней инстанции. Лучшее лекарство от неопределенности — двигаться маленькими шагами, анализировать обратную связь и постоянно сверяться с компасом: «Туда ли мы идем? Не вышли ли за бюджет?». Это как свет фар в темноте: вы не видите всю дорогу, но освещаете себе путь на ближайшие метры.
Есть тип заказчиков, которые любят рассказывать по телефону, «какую крутую систему» им нужно. Это крайне неэффективно. Во-первых, каждому новому подрядчику придется пересказывать всё заново. Во-вторых, на слух информация воспринимается плохо. В-третьих, это сложно передать другому человеку для проработки.
Всю активность лучше формировать через документы. Гораздо проще написать ТЗ, убрать из него лишнее и добавить конкретику, чем обсуждать «на пальцах».
Используйте Google Docs или аналоги. Это позволяет всем участникам видеть, комментировать и править документ. Для меня лично манера заказчика всё объяснять по телефону — это красный флаг. Это либо человек, который просто «отрабатывает время», либо сложный клиент, с которым придется постоянно сидеть в созвонах. И то, и другое — плохой знак.
В любом проекте есть три связанных параметра: объем работ, сроки, бюджет. Измените один — поменяются остальные.
- Хотите больше фич — готовьтесь к росту бюджета и сроков.
- Хотите ускориться — можно доплатить за скорость.
- Хотите снизить затраты — придется что-то выкинуть из версии.
Есть еще четвертый параметр — качество. Мое мнение: его нельзя ронять. Соблазн сэкономить на качестве, чтобы уложиться в бюджет, — это ловушка. Вы просто переносите проблемы на будущее, и они вернутся с процентами. Гораздо лучше ускорять или удешевлять проект за счет правильного снижения объема. Что-то можно сделать проще (но качественно), а от чего-то вообще отказаться. Помните: проект — это не глыба, а переменная величина, которой можно управлять.
Никогда не планируйте «точь-в-точь». В любом проекте есть неопределенность, и она потребует затрат. Всегда нужен запас прочности. Кроме неопределенности в требованиях, есть и форс-мажоры. Стартап — это сам по себе большой форс-мажор.
Я не раз видел, как проект сжигает весь бюджет на первую версию, а на доработки и улучшения денег уже нет. Главная причина — слишком большой начальный объем. Уменьшайте первую версию, не жгите весь бюджет на нее. Оставьте средства на будущие переделки, оптимизацию (скорость, юзабилити) и шлифовку.
Для учета всех «хотелок» используйте беклог. Это может быть простая Excel-таблица с полями: Требование, Приоритет, Сложность, Статус, Этап. Не тащите каждую новую идею сразу разработчикам. Положите ее в беклог, подумайте, точно ли она нужна. Очень много «хотелок» отваливаются сами собой после такого анализа. Это экономит бюджет и сохраняет фокус продукта. Ведение беклога — это задача владельца продукта.
Некоторые заказчики воспринимают работу с разработчиками как поле боя: «прожать», «выбить скидку», «поругаться». Да, вы платите деньги и имеете право на результат. Но задумайтесь: что вы получаете взамен?
На личном опыте: мы стараемся не брать проекты с «воинственными» заказчиками. Если клиент показывает когти на этапе обсуждения, мы отказываемся. Экономически это выгоднее, чем завязнуть в бесконечных конфликтах.
Как построить нормальное сотрудничество?
Мы разобрали ключевые принципы, которые помогут вам не угробить проект на старте. Если вы только начинаете, первым делом напишите концепцию проекта. Сформулируйте для себя видение продукта. Это нужно в первую очередь вам, а не подрядчику.
Краткий план действий:
Хотите глубже разобраться в смежных темах? Почитайте про ключевые риски на старте разработки и о том, с чего начать, если есть идея сайта. А если хотите узнать, как выстроить процесс разработки с минимальными затратами, вот полезная статья.
