Всем привет. Статья будет о стартапе. Но не спешите морщиться. Статья будет о внутреннем стартапе – внутри материнской компании. Такие еще иногда называют спиноффами. Как можно догадаться из названия, я предлагаю почитать о том, с каким энтузиазмом я совершал ошибку за ошибкой в попытке создать внутренний стартап и что из этого вышло. Очень надеюсь на то, что кого-то предостерегу от подобного рода ошибок.

Предыстория

У меня всегда было много идей. Где и кем бы я не работал. Первую строчку кода я написал в 1990 году, еще в школе. Где-то в 1996 году я придумал что-то вроде Яндекс.Маркета (как потом оказалось), чуть позже – вариатор (такую конусообразную шестерню для КПП автомобиля), потом были уже более практичные вещи – большинству из нас приходят идеи, только мы по-разному ими распоряжаемся. Я свои аккуратно записывал, детально прописывая требования (благо, было много практики работы бизнес-аналитиком). Одну даже запатентовал. Теперь только не понимаю, зачем :). К 2011 году я успел поработать не только аналитиком, программистом, руководителем ИТ-проектов и коммерческим директором ИТ-компании, но и директором по развитию крупной строительной компании, построить два торговых центра и побыть генеральным директором компании в области транспортной логистики. В общем, опыта – вагон. Но связи с ИТ не терял никогда. Наоборот – в каждой отрасли видишь, как можно было бы при помощи ИТ придать ей мощный импульс в развитии. В результате, в 2011 году мне предложили вернуться в ИТ, предоставив солидный бюджет (чуть больше 10 миллионов рублей), карт-бланш в формировании команды. Нюансом было интересное ограничение на тематику – сделать продукт, которому бы подходило название «Информационный город» и в котором активно использовались бы QR-коды. Ну и который, конечно же, в результате окупил бы себя и начал зарабатывать прибыль.

Идеальные условия!?

Согласитесь, сделанное мне предложение является пределом мечтаний для многих хабровчан – хороший бюджет, доля, карт-бланш, офис, свобода выбора команды – о таком можно было только мечтать! Я в тот момент думал примерно так же и, засучив рукава, бросился писать концепцию продукта и обдумывать его реализацию.

Суть виртуального города

Результатом стала следующая концепция. Далее – цитата из документа:

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

Наша среда будет сочетать в себе лучшие качества Wikipedia, социальных сетей и мобильных технологий. Ключевой принцип – интеграция социальной среды, построенной по принципу социальных сетей с предметной инфраструктурой, построенной по принципу Wikipedia.

Такая интеграция, вкупе с использованием мобильных технологий, принципа «дополненная реальность», структурных рейтингов и игровых элементов, с большой долей вероятности, должна принести успех.

Для создания прототипа идея будет спроецирована на жизнь города с самыми важными аспектами его жизни, элементами «дополненной реальности» и организацией эффективной связи с исполнительными органами власти.

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

Начало – выбор платформы

Несмотря на то, что мы работали внутри большой компании, команду нужно было, по понятным причинам, набирать с нуля. По моей логике, платформу для реализации должен был определить техлид проекта – он должен был выбрать ту, которая больше других подходит. Тогда мне казалось, что не важно, какую платформу выбирать – если руки растут из нужного места, то результат нужно качества будет в нужные сроки. Как я ошибался! Да, техлидом сделали очень грамотного и ответственного специалиста, имеющего отличный послужной список и опыт работы с Java. То, что опыт был прежде всего промышленной, а не веб-разработки, мне тогда казалось несущественным – ведь человек-то толковый и адекватный + в команду наберем специалистов с нужным опытом.

В результате, вместо того, чтобы для пилота выбрать какую-нибудь CMF, на которой можно было бы быстро сделать прототип и проверить его, мы, ослепленные моей уверенностью в успехе, начали сразу делать на Java большую систему. По процессу подозрительно напоминающую промышленную разработку. Поскольку производительность команды и качество разработки оставляли желать лучшего, а намеченные сроки хотелось соблюсти, то численность команды неуклонно росла и к концу 2011 года уже составляла 8 человек, включая 3 мобильных разработчиков (я не придумал ничего лучше, чем сразу сделать и мобильные версии на трех платформах).

Первые признаки провала

Концепция менялась на глазах и время от времени со стороны девелоперов раздавались предложения прекратить это безумие и как-то упростить концепт. А для начала хорошо бы самим понять, что и для кого мы делаем. Но это уже было не так-то просто. В результате у меня, скорее всего, в целях самоиндульгирования, родилась идея – все стандартные стартапы простые, как три копейки, они решают только одну проблему. Наш же решает сразу кучу проблем, но все вместе, а не поодиночке. Виртуальный город должен быть городом, а не песочницей. Потому нужно продолжать пилить продукт.

А что же инвестор [он же – руководство материнской компании] ?

Мы ежемесячно собирались, я с энтузиазмом отчитывался о проделанной работы и демонстрировал промежуточные результаты. На все попытки как-то подвергнуть сомнению правильность выбранного подхода – делаем продукт, не поднимая головы, в течение года без какого бы то ни было подтверждения концепта со стороны – мной с негодованием отметались. Основной мотив, который я приводил в качестве довода – мы делаем сложный продукт, который будет иметь для пользователя ценность только при своей полной готовности – в противном случае, нас ждет неудача. Увы, мой напор и моя убедительность месяц за месяцем делали свое дело. Но зарплату (иногда даже премии) нам исправно платили и количество денег все уменьшалось и уменьшалось.

Мы его сделали!

Тем не менее, в апреле 2012 года мы сделали первую публичную (как выяснилось – и последнюю) версию проекта. О чем дружественные нам блогеры дружественно и очень доброжелательно поведали всему интернету. Была проведена целая кампания, результаты которой можно увидеть, набрав в Яндексе «iСity – мы его сделали». Мы были полны энтузиазма и готовились выдерживать чудовищные нагрузки от наплыва огромного количества желающих сделать свой вклад в виртуальный город, начать описывать объекты, выкладывать фотографии и новости, комментировать чужие новости, зарабатывать рейтинги и т.п. Как можно догадаться, наши ожидания, мягко говоря, не оправдались. В качестве пилота мы собирались обкатать концепт на Самаре, допилить продукт и уже потом открыть его на всю Россию.

QR-коды

Здесь нужно сделать небольшое отступление. Одно из ключевых мест в проекте занимал QR-код. Надо сказать, что на тот момент этот инструмент еще не получил такого широкого представления и мы хотели сделать Самару первым в России (а может и в мире) городом, где каждое здание было бы оснащено QR-кодом, ссылка с которого ведет на wiki-подобную страничку iCity, где можно было бы как получить исчерпывающую информацию о самом объекте, так и загрузить туда свои комментарии, отзывы и фотографии. Я этот концепт до сих пор считаю хорошим и к такому сервису пока никто даже близко не подобрался. В итоге все упиралось в согласование с городской администрацией Самары положения, которое регламентирует использование QR-кодов наравне с табличками с адресами. Мы подготовили соответствующее постановление, делали презентации перед ответственными лицами. В общем, в Самаре, спустя два с половиной года от передачи нашего варианта постановления главы города, до сих пор нет нормативных актов, регулирующих размещение QR-кодов в адресном пространстве и на объектах ЖКХ.

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

Пивот

По результатам первых двух месяцев работы ресурса выяснилось, что наиболее востребован ресурс у людей, которые хотят обратить внимание городской администрации на те или иные недостатки города – оставляли на картах сигналы, снабжали их фотографиями. И ожидали, что в ответ будут реальные действия администрации. Мы работали над тем, чтоб интегрировать эту часть нашей систем с аналогичной системой самарской администрации, но эта работа продвигалась очень медленно и пользователи, устав ждать, уходили. Однако, это привело к том, что нам предложили, на базе iCity сделать систему работы с обращениями граждан в другом крупном муниципалитете. С учетом тающих бюджетов, предложение было очень своевременным и мы бросили все силы на то, чтобы убрать от iCity все лишнее и оставить только то, что отвечает за коммуникации граждан с исполнительными органами власти и исполнительных органов власти с гражданами. Результатом стала система «Открытый город» для Тольятти. В ней, конечно, почти ничего не осталось от iCity – мы учли множество пожеланий наших тольяттинских коллег и заточили продукт под требования муниципалитета. Был интерес и из других регионов.

Вот что бы вы на моем месте сделали? Ну правильно – быстро переориентировать команду, а самому быстро ехать с презентациями по городам и весям РФ, предлагаю хороший продукт, продавая и внедряя его всем желающим. Очевидный же пивот! Но я тут совершил очередную ошибку – жалко было потраченных на iCity усилий и мы бросились его допиливать, считая, что юзеры к нам не ходят по причине того, что ресурс работает медленно и, временами, нестабильно.

Win The Market

Да. Все перевернулось после того, как я съездил в Москву на это мероприятие. Это было что-то вроде холодного отрезвляющего душа. После возвращения я бросился читать Бланка и Дорфа. Как же нужно было бы это сделать еще в 2011 году! Все мои ошибки стали настолько очевидными, что стало невыносимо досадно за так неэффективно потраченные бюджеты и людей, которые шли за тобой и сильно рискуют прийти к разбитому корыту.

Собрав ключевых людей команды я донес суть новой концепции (четкая сегментация – город для спорта, город для гостей, город для развлечений, открытый город и т.п.). Мы приняли решение заморозить разработку iCity в текущем виде и сосредоточиться на одном из новых порталов по новой концепции. Даже сделали дизайн главных страниц. Но потом стало понятно, что денег не хватит даже на один портал.

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

Что сейчас?

Крутится в открытом доступе на слабеньком компе для того, чтобы время от времени показывать потенциальным клиентам, какую крутую штуку мы в свое время сделали, даже с тремя мобильными приложениями. А для нашей команды, которая, в большинстве своем, уже разбежалась по другим проектам (как в рамках материнской компании, так и за ее пределами), iCity останется в памяти, как отличный пример того, как не нужно делать проекты.

Пишем кровью:

1. Сразу большой бюджет – это плохо. Это дает возможность не видеть правды значительно дольше, чем можно было бы. Единственное, чем можно было бы оправдать большой бюджет – это наличием знающих и авторитетных (которых нельзя было бы продавить или убедить в откровенно непрофессиональной позиции) менторов. У нас их не было.
2. Платформа разработки – это очень важно. Неправильно выбранная платформа обязательно приведет или к сорванным срокам, или к завышенным бюджетам или к недопустимому качеству. А скорее всего, приведет ко всему сразу + будет служить источником серьезной демотивации команды.
3. Для команды проекта губительно нахождение в одном офисе с остальными сотрудниками. Сделать стартап в режиме наемного работника в среде благополучного офиса крайне сложно. Если сотрудники знают, что они в любом случае получат зарплату, то какой смысл задерживаться после 6? Вокруг полно других проектов, которые время от времени обсуждаются в офисе. В крайнем случае, переведут на другой проект. В результате низкий КПД и вовлеченность.
4. Нужно сделать так, чтобы члены команды меньше чувствовали себя наемными работниками и больше – членами команды, которая делает одно большое дело. Ни в коем случае не брать в команду людей, которые не верят в идею проекта, каким бы профессиональным этот сотрудник не был и как бы дальше в материнской компании его не собирались использовать.
5. Давайте возможность своим людям учиться и ездить на разного рода семинары и тренинги. Польза от переформатирования мозгов куда выше потраченных денег и рисков того, что сотрудников переманят. Застой в головах – это прямой риск для стартапа.
6. Губительно руководителю проекта поручать задачи, не связанные с проектом [соблазн велик – человек на зарплате, квалификация хорошая, может еще пару проектов взять легко]. Если команда видит, что их руководитель занимается вопросами, не связанными с проектом, значит проект не так уж и важен, раз можно на нем не фокусироваться. В результате теряется фокус у руководителя, ослабляется контроль работ команды, падает мотивация команды.
7. Недопустимо делать ответственным за внутренний стартап человека, который не знаком с Lean Startup. Каким бы грамотным не был специалист и сколько бы промышленных или заказных проектов не было за его плечами – если не знает принципов создания стартапов и/или не имеет опыта работы в них, не нужно ему доверять проект. И уж тем более, если он при этом обладает способностью убеждать и вести за собой. Убедит и уведет за собой. Только вряд ли это будет успех.
8. Если лидер стартапа – человек идейный, который регулярно генерирует новые идеи и стремится приложить их к проекту, то рядом с ним непременно нужно ставить в пару прагматика, который не даст развалить проект новыми идеями и пропустит в бэклог только то немногое, что действительно достойно быть там. А еще лучше – будет вычеркивать из бэклога все лишнее, оставляя только самое важное. И, при этом, он должен быть устойчив к пламенным речам лидера проекта – только прагматизм.
9. Если пивот стучится в двери проекта, его ни в коем случае нельзя игнорировать. И руководители материнской компании должны тщательно отслеживать реакцию рынка на новый продукт – команда иногда не в состоянии увидеть предпосылки для пивота. Или сделать вид, что не увидела. Потому что есть зарплата и видимая стабильность. А хочется делать не то, что нужно, а то, что интересно.
10. Руководителям материнской компании, которая хочет сделать внутренний стартап, очень полезно будет прочитать про Lean Startup и базовые принципы создания таких вещей. Иначе вас либо ждут долгие дискуссии с руководителем проекта (с которым вы будете говорить на разных языках), либо вы просто не сможете распознать рисков, которые подстерегают ваш проект и ваши инвестиции.

Автор: meranged

Источник