Давно мечтали начать какой-нибудь материал со слов «В нашу редакцию пришло письмо». И вот этот момент настал!

Кирилл Гришанин, партнер WB—Tech, отразил очень любопытную точку зрения, на которую мы не смогли не отреагировать и решили организовать отдельную публикацию. Правда, с некоторыми оговорками... Но обо всем по порядку.

Более 5 лет Кирилл Гришанин и его студия специализируется на заказной разработке для стартапов. За это время, по его словам, через его студию прошло больше сотни запросов и, он решил как-то подытожить этот опыт в довольно резкой и категоричной форме.

В своем сообщении автор обращается, собственно, к самим стартаперам:

Кирилл Гришанин
Партнер WB—Tech

Итак, у вас есть идея стартапа или, может быть, вы уже начали её реализовывать. Но если вы не гуру разработки, не написали ни строчки кода и не понимаете основ разработки ПО, то неизбежно встаёт вопрос — кто будет отвечать за техническую часть проекта?

Один из самых ключевых вопросов для подавляющего числа новых бизнес-проектов, не так ли? И вот какие три основные модели он приводит далее, нанизывая на них различные вариации и аргументы:

1 вариант

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

2 вариант

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

1. с учетом того, что у вас небольшой опыт (а точнее — никакой) в разработке, есть огромная вероятность, что вы возьмете на работу просиживальщика штанов. На что вы будете ориентироваться при выборе кандидата? Как будете контролировать его работу?

   Как-то на просторах Фейсбука я встретил человека, который оценивал работу своих программистов... по количествам строк кода, которые те писали в день. А когда я попросил посмотреть продукт и заглянул в его внутренности, у меня чуть кровь из глаз не пошла! Тем программистам впору было бы пойти в копирайтеры с оплатой за символы. Или, что уж там, они вполне могли конкурировать с Толстым за раздувательство текстов. :)

2. допустим, вам улыбнулась удача, и ваш нанятый в офис разработчик оказался добросовестным и толковым парнем (или не парнем). Но и тут есть риски!

3. Хороший программист не думает о UX, потому что это не его работа. А еще он немного иначе воспринимает мир, чем обычные юзеры, на которых, как правило, ориентирован сервис. Часто в пример ставят craigs list и reddit, как продукты, явно без UX проектировки. Стоит учесть, что я не знаю примеров, кроме craigs list. А reddit — это тусовка гиков, где обычный новый или случайно зашедший пользователь просто офигевает от неудобства.

4. Хороший программист просто делает фичи. Как правило, он не думает о том, как продукт будет жить в реальном мире с его ограничениями. В итоге продукт не получится адекватным реальности. Безусловно, что любая первая версия, кем бы она ни была сделана, не будет на 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.

Его история не менее интересна. Последние шесть лет он провел в Черногории, где создал сервис для онлайн-бронирования автомобилей, а теперь решил расширить свой бизнес, открыв офис в России.

Итак, вот какой историй Кирилл поделился с нами:

Кирилл Антошин
CEO RentaCarFor.Me

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

Нового разработчика нашёл почти случайно. Я искал плагин на Вордпресс для формы контактов. Нашёл очень красивое и функциональное решение, посмотрел кто автор. Им оказался русский парень. Я написал ему, посмотрел другие его плагины. Все они были простыми, но с хорошим UI и имели высокие оценки клиентов за стабильность работы. Я спросил, знает ли он php и может ли помочь мне исправить баги. Полгода он фиксил баги, а потом переписал 80% кода на Ruby on Rails.

Итак, у нас есть:

1. мнение Кирилла Гришанина, который всецело уверен, что заниматься сайтами стартаперов должны внешние команды;

2. история Константина Бочарского, который разработал сайт собственного стартапа своими силами, самостоятельно научившись программированию;

3. опыт Кирилла Антошина, который нашел разработчика-фрилансера, спасшего в итоге весь проект.

Что думаете, коллеги? Какой из трех вариантов более жизнеспособен? Согласны ли вы с позицией Кирилла Гришанина? Знаете ли вы о других успешных моделях и кейсах?

Пишите в комментариях, давайте обсудим!