Почему стартапы с собственной разработкой обречены на провал?
Аргументы в копилки апологетов и внешних, и внутренних команд разработчиков Дата публикации: 02.02.2017 Давно мечтали начать какой-нибудь материал со слов «В нашу редакцию пришло письмо». И вот этот момент настал! Кирилл Гришанин, партнер WB—Tech, отразил очень любопытную точку зрения, на которую мы не смогли не отреагировать и решили организовать отдельную публикацию. Правда, с некоторыми оговорками… Но обо всем по порядку. Более 5 лет Кирилл Гришанин и его студия специализируется на заказной разработке для стартапов. За это время, по его словам, через его студию прошло больше сотни запросов и, он решил как-то подытожить этот опыт в довольно резкой и категоричной форме. Необходим сайт, мобильное приложение, услуги по SEO или контекстной рекламе? Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. База проекта насчитывает более 10 500 агентств. Сервис работает БЕСПЛАТНО как для заказчиков, так и для исполнителей. В своем сообщении автор обращается, собственно, к самим стартаперам: Комментарий: Кирилл Гришанин, партнер WB—Tech Итак, у вас есть идея стартапа или, может быть, вы уже начали её реализовывать. Но если вы не гуру разработки, не написали ни строчки кода и не понимаете основ разработки ПО, то неизбежно встаёт вопрос — кто будет отвечать за техническую часть проекта? Один из самых ключевых вопросов для подавляющего числа новых бизнес-проектов, не так ли? И вот какие три основные модели он приводит далее, нанизывая на них различные вариации и аргументы: 1 вариант Вы можете оценить техническую часть проекта как «несложную». И чаще всего такой подход заканчивается поиском фрилансера или привлечением знакомых из разряда «тыжпрограммист». Давайте помнить, что стартап в 99% случаев — это не типовая разработка. Поэтому сложности начинаются уже здесь. А именно — с постановки ТЗ. Вы можете неверно оценить объем или сроки работы, чем введете в заблуждение своего разработчика. Или вы забудете уточнить какие-то моменты, которые тоже могут существенно сказаться на условиях. Или вообще в корне неправильно поставите задачу (да, так тоже бывает), и в результате получите совершенно другой продукт, чем вы предполагали. Этот сценарий развития проекта несёт больше всего рисков. Не делайте так. 2 вариант Вы сразу берете в штат программиста, чтобы он писал весь необходимый софт инхаус. Здесь уже возможны вариации: с учетом того, что у вас небольшой опыт (а точнее — никакой) в разработке, есть огромная вероятность, что вы возьмете на работу просиживальщика штанов. На что вы будете ориентироваться при выборе кандидата? Как будете контролировать его работу? Как-то на просторах Фейсбука я встретил человека, который оценивал работу своих программистов… по количествам строк кода, которые те писали в день. А когда я попросил посмотреть продукт и заглянул в его внутренности, у меня чуть кровь из глаз не пошла! Тем программистам впору было бы пойти в копирайтеры с оплатой за символы. Или, что уж там, они вполне могли конкурировать с Толстым за раздувательство текстов. :) допустим, вам улыбнулась удача, и ваш нанятый в офис разработчик оказался добросовестным и толковым парнем (или не парнем). Но и тут есть риски! Хороший программист не думает о UX, потому что это не его работа. А еще он немного иначе воспринимает мир, чем обычные юзеры, на которых, как правило, ориентирован сервис. Часто в пример ставят craigs list и reddit, как продукты, явно без UX проектировки. Стоит учесть, что я не знаю примеров, кроме craigs list. А reddit — это тусовка гиков, где обычный новый или случайно зашедший пользователь просто офигевает от неудобства. Хороший программист просто делает фичи. Как правило, он не думает о том, как продукт будет жить в реальном мире с его ограничениями. В итоге продукт не получится адекватным реальности. Безусловно, что любая первая версия, кем бы она ни была сделана, не будет на 101% адекватной запросам, но в случае одного программиста, который предоставлен самому себе (мы помним, что фаундер ничего не понимает в разработке) результат будет неадекватным реальным условиям. Вот простой пример. В 2014 году нас пригласили в один финансовый проект. Уже был готов некий прототип, и ребята хотели делать нормальный сервис, который сам получает данные, сам делает расчеты, и далее уже выводит конечный результат. Я достаточно долго вникал (2 недели), потому что предметная область была не очень-то простая. Мы насчитали достаточно большую сумму. Ребятам это показалось это очень дорогим и они продолжили пилить своим составом — на тот момент у них был бекенд, фронтенд, менеджер (а как без него) и инвестором. В конце 2016 года у сервиса появилась первая публичная версия и я знаю, что в 2015 команда инхаус выросла до 20 человек, а затраты составили $1М. Это цифра ровно в два раза больше той, что посчитали мы. Не у каждого стартапера есть такая сумма и именно она в данной ситуации оказалась гарантией того, что проект вышел — инвестору просто все равно было сколько платить. Или вот еще история. Я слежу за отказами и периодически мониторю результаты отказников. В прошлом году очередной великий стартапер судьбы предлагал делать агрегатор шин. Я посчитал ему 1,5 млн рублей и ±полгода. Он нашел кого-то в интернете и пошел делать за 400 тр. Через год я спросил у него как дела. Ответ был такой: «Готовы прототипы всех версий и ТЗ.» 3 вариант Вы берете себе технического партнера. Бинго! Оптимальный вариант! Но и в этом случае вы можете не получить результат, который можно будет развивать дальше. Потому что опять возникает риск при выборе человека выше уровня программиста, который бы собрал команду и качественно настроил процессы. Ведь фаундер не понимает критериев и ему придется оставлять это на контроль партнера. И часто в таких партнерских историях плачевный результат всплывает уже, когда бюджет трещит по швам, а продуктом (или даже прототипом) еще и не пахнет. По моему опыту очень часто в такую роль «технического партнера» вписываются люди, которые не очень круто шарят. Да, скорее всего что-то они соберут, но вероятность, что эта машинка доедет до инвесторских денег, не очень велика. Это получается из-за того, что у действительно опытного человека нет интереса идти в ваш стартап, так как он слишком хорошо знает свою цену. Вам просто нечего предложить ему. Осилили? Готовы двигаться дальше? Тогда сначала ознакомьтесь с выводами, собственно, самого автора — Кирилла Гришанина: Комментарий: Кирилл Гришанин, партнер WB—Tech В большинстве случаев самый эффективный сценарий — заказывать разработку на аутсорсе, у команд, которые специализируются на кастомных решениях. Такой аутсорс на 100% выгоден, если не умеешь следить за инхаус командой, если инновационность бизнеса основана не на софте (то есть это не космическое распознавание лиц). Во-первых, это получается дешевле, если брать в расчет совокупность материальных и временных ресурсов. Во-вторых, такие команды уже заточены под работу с фаундерами-«гуманитариями». Уже на первом этапе они рассчитывают проект до мелочей, из-за чего риск со срывом сроков разработки практически полностью исчезает. Ну, и в-третьих, сотрудничая с опытной командой на первом этапе, вы получаете качественный фундамент для дальнейшего масштабирования проекта уже своими силами. Точка зрения, на наш взгляд, довольно радикальная. Поэтому с разрешения автора, мы решили узнать мнения людей, чей опыт немного (или вовсе) не укладывается в такой расклад. Нам же нужна объективность, правда? Одним из первых на нашу просьбу откликнулся Константин Бочарский. В его бэкграунде — богатый опыт работы редактором различных изданий (в том числе — в ИД «Коммерсантъ»). Ныне он является основателем и локомотивом проекта Pressfeed, ориентированного на пиарщиков и смишников. И вот, что он нам рассказал: Комментарий: Константин Бочарский, основатель проекта Pressfeed Как известно, есть два способа реализовать проект — правильный и тот, который работает. Правильным принято считать тот, когда каждый занимается своим делом. Программист — программирует, веб-дизайнер делает макет, верстальщик — верстает, а автор идеи — выбирает подрядчика, пишет ТЗ, ставит задачи, контролирует реализацию и платит. Способ, который работает — это когда ты просто берешь и делаешь. Работая в СМИ у меня было много идей о том, как «оптимизировать» мой рабочий процесс. И пытался воплотить эти идеи в жизнь. Я писал ТЗ, рисовал «мокапы», платил исполнителям, но почему-то это не срабатывало. В результате я просто научился программировать и сделал Pressfeed сам. К моменту, когда я решил делать Pressfeed я был знаком с веб-версткой: html, css. Мог сделать простенький html-макет. Проблема была именно с программированием. Я несколько раз подступался к этой задаче — покупал книги, проходил курсы на Coursera и других ресурсах, меня пытался учить в режиме репетитора мой хороший приятель и я даже прошел базовый курс php в «Специалисте», но все как-то не «заходило». До тех пор пока желание сделать задуманное не стало настолько острым, что я вдруг как будто «увидел» все то, что не мог понять, запомнить раньше. С этого момента началось мое настоящее «обучение» — я пытался реализовать свои реальные идеи и штурмовал их с очень высокой вовлеченностью и энтузиазмом. Этот период учебы занял около полугода — с февраля по июль 2014. Еще около полугода — с августа по ноябрь — я писал сам Pressfeed. И 5 декабря 2014 Pressfeed вышел на рынок. Итак, полгода плотного обучения на базе реальных проектов и еще 4 месяца, чтобы написать и запустить Pressfeed. В результате сервис сейчас использует четверть всех российских редакций и более 20 тыс компаний, заинтересованных в работе с медиа. Я согласен с автором статьи, что начинать ИТ-проект без компетенций в этой сфере, это как переходить оживленный проспект с завязанными глазами. Как оценивать сроки, объем работ, их стоимость, как ставить задачи исполнителям и спрашивать результат, как принимать решения, сталкиваясь с проблемами (а они будут возникать постоянно). Никому же не приходит в голову объявить себя нейрохирургом и встать к операционному столу, или пилотом самолета и сесть за штурвал. Хотя, возможно, первое время будет казаться, что все идет нормально. Разработка ИТ-проекта — сложная инженерная задача. Она требует большого объема знаний. Без них, ввязываясь в такую историю, можно уповать только на удачу. Хотя кому-то, наверное, повезет. Спасти дилетанта-заказчика может компетентный партнер, везение с порядочным исполнителем и другие подобные «удачи». К слову, удачный выбор профессиональной студии я также отношу к категории «везения». Как оценить адекватность сметы, сроков и используемых технологических решений? И что произойдет с проектом после того, как у заказчика закончатся осмеченные Х млн рублей? Занимайтесь тем, в чем разбираетесь, или сперва разберитесь в том, чем собираетесь заниматься. Не перебегайте дорогу с завязанными глазами. Безусловно, опыт Константина — если не уникальный, то, по крайней мере, резко отличающийся от большинства. Согласитесь, редко какой человек просто так возьмет и выучит языки программирования, научится верстать и делать так, чтобы не лагало. Для этого нужен какой-то особый мозг, особые обстоятельства и особенная мотивация. К тому же, такой проект как Pressfeed практически не имеет аналогов. Соответственно, нет такой студии, для которой он был бы идеально понятен и прозрачен. Даже сам Константин признался: Комментарий: Константин Бочарский, основатель проекта Pressfeed Во сколько бы обошлась разработка Pressfeed, если бы я доверил ее сторонней команде, я могу оценить уже сейчас, когда проект готов. В компьютерной игре Warcraft было такое понятие «туман войны». Чтобы увидеть кусок карты, надо было туда дойти, тогда «туман» рассеивался и ты точно знал, что там находится. Это сейчас я могу написать точное ТЗ на Pressfeed и оценить время и стоимость его разработки. Потому что я уже прошел этот путь. Но на момент старта, огромное количество задач, было вопросами, на которые надо было найти ответ. А часть проблем и вовсе была не очевидна. По мере работы над проектом, мне приходилось принимать много сложных решений, порой — ошибаться, порой — идти на компромиссы. И я не представлю, как бы я принимал решения, если бы не был компетентен. Все что я знал на момент старта: что это довольно большой проект с большим количеством неопределенностей, и чтобы написать ТЗ, мне надо эти неопределенности снять. А для этого я должен сам развеять «туман войны» — понять в первую очередь для себя. Словом, задача нетиповая и явно выпадает из 80–90% проектов. Поэтому мы обратились за комментарием еще и к Кириллу Антошину, CEO RentaCarFor.Me. Его история не менее интересна. Последние шесть лет он провел в Черногории, где создал сервис для онлайн-бронирования автомобилей, а теперь решил расширить свой бизнес, открыв офис в России. Итак, вот какой историй Кирилл поделился с нами: Комментарий: С первым разработчиком были знакомы по другому проекту, где я был менеджером со стороны заказчика. Беда была в том, что это был фрилансер прожект-менеджер, который сам искал и нанимал исполнителей. И беда была в том, что исполнители его были весьма так себе. Например, разработчик допускал кучу багов, а за фиксы требовал дополнительную оплату. И речь не про хотели клиента, а за просто нефункционирующий код. Из-за столь плохой реализации проект чуть не умер. Нового разработчика нашёл почти случайно. Я искал плагин на Вордпресс для формы контактов. Нашёл очень красивое и функциональное решение, посмотрел кто автор. Им оказался русский парень. Я написал ему, посмотрел другие его плагины. Все они были простыми, но с хорошим UI и имели высокие оценки клиентов за стабильность работы. Я спросил, знает ли он php и может ли помочь мне исправить баги. Полгода он фиксил баги, а потом переписал 80% кода на Ruby on Rails. Итак, у нас есть: мнение Кирилла Гришанина, который всецело уверен, что заниматься сайтами стартаперов должны внешние команды; история Константина Бочарского, который разработал сайт собственного стартапа своими силами, самостоятельно научившись программированию; опыт Кирилла Антошина, который нашел разработчика-фрилансера, спасшего в итоге весь проект. Что думаете, коллеги? Какой из трех вариантов более жизнеспособен? Согласны ли вы с позицией Кирилла Гришанина? Знаете ли вы о других успешных моделях и кейсах? Пишите в комментариях, давайте обсудим! Автор: Катерина Логвинова, CMS Magazine & «Рейтинг Рунета» (Директор по коммуникациям) Please enable JavaScript to view the comments powered by Disqus. Рекомендуем: Как вырастить в себе CEO Так ли на самом деле просто стать и быть генеральным директором, как кажется? 5 ключевых способностей успешных основателей стартапов Создатели стартапов — удивительные люди. Они должны быть многогранными и динамичными, но при этом четко мыслящими и очень сфокусированными. В первое время они должны быть готовы совмещать несколько должностей и выполнять несвойственные для них обязанности, такие как HR, PR, продажи, разработка и дизайн продукта. Но самое главное, они должны быть несколько сумасшедшими, чтобы замахиваться на бешеный, как американские горки, ритм жизни, называемый «предпринимательством». Игрофикация для стартапов. Пять этапов создания клиентской лояльности Один из недавно появившихся способов создания лояльности основывается на игрофикации. Как ни крути, если лояльность — это стимуляция постепенного роста активности пользователей, то именно с помощью игрофикации можно достичь резкого увеличения аудитории, сделать клиентов довольными и увеличить доход. Устройте мне статью Несколько банальных, но и при этом очень действенных советов о том, как стартаперам общаться с журналистами и чего от них ждать.Полный текст статьи читайте на CMS Magazine
