Стартаперы глазами разработчика: с какими работать, а каких избегать

В веб-разработке я работаю более пяти лет. За это время управлял как самой разработкой сайтов, так и управлением процессами. В работе я стараюсь всю поступающую информацию систематизировать и классифицировать: это касается как самих процессов, так и подходов к работе с заказчиками.

Хочу познакомить читателей Cossa с одной из таких классификаций — классификацией российских стартаперов. Эта классификация — плод реального опыта и набитых шишек. И часто я могу предсказать, как поведёт себя тот или иной стартапер, с какими проблемами столкнутся разработчики и взлетит ли стартап вообще. В этой статье делюсь опытом делюсь с разработчиками, — то есть с теми, кто будет разрабатывать программное решение, а не продумывать идею.

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

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

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

Стихийный стартапер

Маркеры. «У меня тут инвесторы, давайте быстро сделаем лендинг, чтобы было что-то показать», «Идея бизнеса? Ну, блокчейн, транзакции, всё же понятно», «Криптобиржа», «Аналог авито», «У нас новый раунд переговоров и надо на сайте, который вы делали, заменить пару кнопок, поменять картинки, добавить тексты, убрать информацию про это и вот это, так как мы немного переиграли. Завтра будет готово?» «Для чего тут кнопки и куда будут вести? Не важно, сделайте просто кнопки».

Что характерно. Пребывает в постоянном поиске инвесторов, партнёров. Как правило, не разбирается в том, что продает.

Периодически пускает «пыль в глаза» разработчикам о том, что вот-вот будут работы на год и больше. Обещает космические объёмы и интересные задачи, но при уточнении «что именно будем делать?» — просто пропадает. В плане ответственности, тут вполне всё ОК — не кинут, заплатят (если будут деньги), как минимум до следующего раунда переговоров. Возможно, из-за того, что искать другого подрядчика — это серьёзная потеря времени, когда надо «здесь и сейчас». Проект, скорее всего, так и не взлетит, даже не дойдёт до стадии MVP.

Решение. 100% предоплата «в чёрную» или сразу с подписанным актом выполненных работ (понимаю, что нереальная задача), только фиксированные работы и максимально детализировать. Если есть свободные ресурсы, и вы осознаете ситуацию, то можно брать в работу.

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

Хипстер

Маркеры. Часто в речи слышим: «Энивей», «Фасилитирует», «Суппортит», «Асап», «Рисёрч», «Заапрувим», «Сэскалируйте».

Что характерно: за «модностью» и некой айтишностью этих слов, как правило, низкая самоорганизация, слабое понимание хода работы, зачастую отсутствие понимания процесса разработки ИТ-продукта. Например, после продолжительного молчания вам могут сказать «У нас был воркшоп и не было времени ответить», а могут вообще уехать в отпуск перед финальным релизом. Как правило, у руля проекта стоят или бывшие маркетологи, или менеджеры, которые побывали на многих семинарах по разработке сайтов или получили незначительный опыт работы в веб-студиях, ловко оперирующие ИТ-жаргонами. Главной их особенностью является делегирование всего и вся (принцип «передал и забыл»), своеобразная «кратковременная память» («забывают» о проекте и о работах), любят решать все вопросы в мессенджерах или по телефону, низкая вовлечённость в проект, так как помимо этого проекта ещё много других важных дел, участия в ивентах и тому подобного. Про таких говорят: любят сидеть в коворкингах, пить смузи и рассуждать о прекрасном, пока не закончатся инвестиционные деньги.

Решение. Всё фиксировать и протоколировать, любые пожелания или изменения должны быть присланы по почте (переписка в мессенджере не канает, так как есть риск её потерять в груде сообщений или удалить), график Ганта — не просто must have, а жизненно необходим. Если что-то идёт не так — пишем всем кому можно (аларма!), никаких устных договоренностей. Только предоплаты, только короткие спринты, только полная официальная фиксация всех процессов и материалов.

Риски. Продукт может быть и вполне жизнеспособный, но управление им со стороны стартапера всю «красоту» может свести на нет. Очень часто заказчик во всём полагается на исполнителя, даже в том, в чём обязан разбираться сам (например, бизнес-процесс и бизнес-план).

Эстет

Маркеры. «Давайте подвигаем шрифты, а ещё заменим фото — мужчина слишком несимпатичный и не такой какой-то», «Давайте добавим побольше визуальных эффектов, хотим WOW, а ещё давайте снова переосмыслим главную страницу».

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

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

Риски. Неконтролируемый и затяжной период согласований макетов, вёрстки, сдачи сайта. Потому что «что-то не так» или «мы тут посмотрели и нужно ещё внести правки». Проект скорее всего не взлетит, а за время разработки команда со стороны заказчика может легко поменяться несколько раз. Поэтому только предоплаты, начинать с бэка, ограничивать количество изменений.

Гаджетоманы

Маркеры. «У моего конкурента недавно появился новые функции, давайте это добавим и на наш новый сайт. А ещё хочу, чтобы было 7 разных калькуляторов, будет мини-блог, возможность интегрироваться с разными сервисами (какими? неважно, решим), ещё хочу чтобы заказчики тут организовали общение и делились впечатлениями, отзывы обязательно поставим, шаринг, возможность прикладывать видео и фотоконтент, и у меня ещё родилась идея, но вы пока это делайте, а я сформулирую и вам направлю, а потом поищу в инете что-нибудь ещё интересное».

Что характерно. То же, что и с «эстетами». Не интересует или не осознают смысл собственного проекта, считают проект идеальным, когда будет всё, что нужно (а где границы этого «нужно» и нужно ли это вообще?), отсутствие УТП. В отличие от «эстетов», такие стартапы могут взлететь, если владелец вовремя «остановится» с внедрением фич, а бюджета хватит и на реализацию, и на запуск, и на продвижение (реклама, seo и так далее). Но, даже после запуска, такие проекты долго не живут, так как лишены позиционирования, УТП и, самое важное — необходимости для конечного пользователя. Ещё одна особенность таких стартаперов — высокая степень осведомлённости о процессе разработки интернет-проектов, что приводит к постоянному соучастию в принятии или даже указании технических решений (вплоть до постановки условий «или так, или никак»), раздаче советов, что серьёзно мешает процессу.

Решение. В какой-то момент постараться остановить с внедрением «фич», провести совместный конф-колл — определиться с позиционированием (если это возможно и разработка не ушла совсем далеко), определить минимальную функциональность и требования к MVP, помочь, уберечь от лишних трат ресурсов (время в данном случае тоже ресурс). А затем наметить сроки по функциональности следующих этапов и её реализации, приступать к следующему этапу после запуска предыдущего. Контролировать данные по метрикам и получать обратную связь от пользователей. Занять стартапера доработкой бизнес-логики, продумыванием дальнейшего продвижения, чтобы не отвлекал от процесса разработки.

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

Прижимистый

Маркеры. «А почему разработка сайта так дорого стоит, давайте сделаем лендинг, а хотя нет, давайте вы сделаете нам дизайн, а наш штатный маркетолог его на конструкторе сделает».

Что характерно. Денег немного, но хочется «стартапнуть» красиво, «как у всех» и с количеством идей, которые должны разорвать рынок.

Решение. Практически отсутствует. Если есть возможность, то лучше не работать на подобных проектах. За небольшие деньги вы пройдёте все круги ада — от «ещё правки» до «мы с вами договорились, я вашу работу оплачиваю, поэтому будьте добры выполнять её качественно, завтра ещё вышлю правки». Если всё же ввязались — ограничьте заказчика количеством итераций, весь процесс должен быть формализован, а в спецификации детализирован объём работ, который вы должны выполнить (такие стартаперы любят получать что-то в виде бонуса под предлогом «так это же очевидно»), только 100% предоплата.

Риски. Затянушийся проект с бесконечными правками, доработками и нервотрёпкой, об окончании которого вы будете рады просто забыть.

Невовлечённый

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

Что характерно. Крайне редкий вид стартаперов, но бывает. И если уж он вам попадётся, будьте начеку. При казалось бы очевидных плюсах (не лезет в работу, не пушает по срокам) отсутствие вовлечённости обязательно скажется негативно практически на любом этапе работ по проекту — вплоть от «я не увидел, а вы меня не предупредили», до «мы приостанавливаем работы по проекту — просьба сдать материалы» или просто длительного молчания. Природа появления таких стартаперов неизвестна — возможно, это полученные гранды, которые нужно освоить или проект от госконторы или что-то ещё, но точно не на свои деньги.

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

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

Неопытный

Маркеры. «Как делаются сайты, что за чем следует?», «Зачем вы мне прислали эскизы, я просил готовый сайт», «А какие ещё есть варианты главной?», «А может придумать название сайта?», «Зачем нам подключать смс-рассылку, сайт сам это сделать не может?», «Подскажите, как продвигать в соцсетях?».

Что характерно. Зачастую полное незнание процесса разработки сайта, не проработанный бизнес-процесс (принцип «придумал идею, а там разберёмся»), и, соответственно, идея может и не работать вовсе, или результат полученный в ходе многомесячных работ может оказаться не тем, который «виделся» заказчику. Кстати, даже если вы сделаете так, как хотел заказчик, но проект не «стрельнет», то в этом будут винить вас, даже не сомневайтесь.

Решение. Желательно провести тщательную аналитику с разъяснениями «что и как», есть вариант проскочить этап прототипирования и написания детализированного ТЗ (нужно будет только ТЗ для программистов), сразу приступать к макетам (желательно, интерактивным с помощью перелинковки, figma или invision), этап вёрстки не показывать, сложные функции сайта лучше отнести на второй-третий этапы. Как вариант, убедить заказчика сделать только MVP (это будет лучший вариант в данном случае), но есть риск не суметь объяснить, для чего мы делаем MVP. И не получится объяснить, что MVP — это не финальная версия.

Риски. Самый непредсказуемый тип заказчика — почти как «невовлечённый». Отсутствие осведомлённости может негативно отразиться как на ходе процесса (долгие согласования из-за недопонимания или отсутствия желания понимать, больше времени на разъяснения, отсутствие понимания длительности и стоимости дополнительных работ), так и его результата (очень велик риск в конце получить — «это не то, чего я ожидал»).

Идеальный

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

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

Решение. Всё в рабочем режиме.

Риски. Как и во всех коммерческих проектах — всегда есть, и от них никто не застрахован, но они хотя бы предсказуемы.

Элементарные советы стартаперам

Если у вас есть идея, финансы и желание реализовать нужное, важное и суперприбыльное, то:

1. Изучите рынок и конкурентов. Если ваша супер-идея ещё не реализована на рынке, то либо вы самый умный, либо рынку это не нужно. К сожалению, в современном мире всё вторично и верх берёт тот, у кого сервис отвечает запросам пользователя.
2. После изучения рынка проработайте бизнес-план. Да, об этом говорят все кому не лень, но мало кто делает. Продумайте бизнес-процессы (то есть что с чем связано, как проходят потоки информации, «вход-выход» и прочее) и как проект должен приносить прибыль (за счёт чего и каких инструментов).
3. Обязательно заложите бюджет на продвижение и рекламу, который должен быть в размере двух–трёх, а иногда четырёх–пяти бюджетов на разработку.
4. Разберитесь в предметной области, матчасти и возможных подводных камнях как самого продукта, так и его разработки. Такие слова, как «хостинг», «интеграции», «spa», «back end» и «front end» вас не должны вводить в ступор.
5. Вам придётся уделять время разработке проекта — ни в коем случае не отпускать в свободное плавание. А если вы заняты другими бизнесами, работой или «просто заняты», то изыщите возможность нанять опытного и толкового менеджера
6. Помните: чем быстрее вы запустите проект, тем быстрее получите фидбэк от пользователей и увидите изъяны (а они точно будут). И тем быстрее сможете внести изменения и сэкономить приличную сумму для того, чтобы доделать, дошлифовать и выпустить на рынок по настоящему прибыльный продукт.

Удачи!

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.