Історія одного провалу: як я запускав кріптовалютний проект, чому провалився і які уроки виніс. Частини 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 ми закладаличотири місяці. Але трохи затрималися і вклалися в п'ять. Зазвичай проектні менеджери множать термін реалізації на три, щоб отримати реальні цифри. Навіть не знаю: це вони песимісти, або ми - щасливчики. У будь-якому випадку наше запізнення було в рамках похибки. Так що тут все вийшло окей.

***
Повний текст історії можна прочитати негайно тут.Або зачекайте, поки я опублікую його на SmartLab. Я також нагадую вам про свій телеграмський канал, в якому я публікую власні статті про інвестиції та управління проектами. Чекаю візиту!