История одного провала: как я запускал криптовалютный проект, почему провалился и какие уроки вынес. Части 4 и 5.

Часть 4. Как собирал команду
Я решил запустить стартап с разработки социальной сети. Хотел сделать MVP и привлечь первых пользователей-инвесторов. Затем получить инвестиции в проект и на эти деньги создать цербера. Дальше раскрутить машину: привлечь управляющих, добавить проекты. Сейчас я понимаю, что начинать с разработки социальной сети было стратегической ошибкой. Но тогда идея казалось хорошей.

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



Я слышал байку, что найти хорошего СТО сложнее, чем жену. Второе не проверял. С первым согласен.



В итоге мне повезло: мы списались друг с другом на форуме. Питерская компания OKTEND запускала стажерскую программу и нуждалась в реальном проекте. Руководитель компании Алексей Резвов превращал талантливых падаванов программирования в джедаев своего дела. Я запускал стартап без бюджета. Мы подходили друг другу, как мед к пармезану. Поэтому договорились разделить будущую компанию пополам и приступили к работе.

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



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



Таким образом, вместо одного CTO я получил отряд боеспособных программистов. Вместе со мной было двенадцать человек: двое backend-разработчиков, двое frontend, по одному на blockchain, mobile, devops. Два опытных куратора контролировали качество разработки и помогали советами. CTO контролировал общий процесс. Еще был аналитик, который переводил мои требования в технические задачи, и руководитель проектов, который координировал весь процесс.

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



Как разрабатывали социальную сеть
Мы работали удаленно. Основная часть команды находилась в России, несколько ребят были из СНГ. Удаленное взаимодействие создавало сложности, но плюсов было больше. Самый важный из них — возможность работать с мотивированными людьми, а не париться насчет географии. Интернет действительно великая штука, тут не поспоришь. Тем не менее, трудности ждали. Нас было много, и мы были в тельняшках. Дело пахло управленческим хаосом.

Однако, тут сказался опыт Алексея. Он сформировал четкую и понятную структуру взаимодействия. Команду разделили на блоки, каждый блок отвечал за свое направление. Руководитель проектов, которого я вскоре заменил, контролировал общий процесс. Трижды в неделю мы собирались в Discord на короткие совещания. Там координировали направление разработки. Время встреч было строгое: 20-00 во вторник и четверг, 17-00 в субботу. Продолжительность 20 минут. Эти встречи держали команду в тонусе и позволяли оперативно решать проблемы. Таким образом, двенадцать незнакомых людей через семь дней показали первые результаты. А еще через пять недель работали как единое целое.



Из софта мы использовали связку Google Drive + YouTrack + Telegram + GitHub. Мотивация выбора — их простота и бесплатность.



Команду добавили в единый чат, который использовали до конца проекта. Там шло основное общение. Иногда оно уходило в личную переписку или на непродолжительные Discord-конференции. Дополнительных каналов не было. И это оказалось хорошим решением: вся информация хранилась в одном месте, ее легко было искать, никто не путался. Задачи мониторили через YouTrack, код заливали в GitHub. А остальные данные держали на облаке в Google.

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

Изначально на разработку MVP мы закладывали четыре месяца. Но немного задержались и уложились в пять. Обычно проектные менеджеры умножают срок реализации на три, чтобы получить реальные цифры. Даже не знаю: это они пессимисты, или мы — счастливчики. В любом случае наше опоздание было в рамках погрешности. Так что здесь все получилось окей.



***
Полный текст истории можно сразу прочитать здесь. Или дождаться, пока я опубликую ее на смартлабе. Также напоминаю про мой telegram-канал, в котором публикую собственные статьи про инвестиции и управление проектами. Жду в гости!