"Успех – не ключ к счастью. Счастье – это ключ к успеху. Если вы любите то, что вы делаете, вы будете иметь успех" - Герман Каин

"Если хочешь идти быстро – иди один. Если хочешь идти далеко – идите вместе" - африканская пословица.

Введение

Это вторая статья, из серии запланированных статей:

1. Стартап первый, или как я входил в it. - история, которая отвечает на вопрос почему собственно я пришел в it и какой путь мне пришлось пройти.

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

3. Архитектура приложения стартапа, взгляд с высоты птичьего полета. - обобщенный разбор принятых решений.

4. Архитектура приложения стартапа, domain-layer.

5. Архитектура приложения стартапа, app-layer. Часть 1.

6. Архитектура приложения стартапа, app-layer. Часть 2.

7. Архитектура приложения стартапа, Фронтэнд.

8. Процесс разработки, на примере реализации UseCase.

План

• Начинаем работу над стартапом и получаем проблему.

  • Начало

  • Работа над ядром

  • Заинтересованные лица

  • Результаты работы, у нас проблемы

• Решаем проблему

  • ищем помощь в стороне

  • clean architecture, ddd

  • переходим с Python, JS на TypeScript

  • работаем над своей архитектурой

• Что это нам дало, и чего это нам стоило?

  • продукту

  • команде разработки

  • разработчикам

• Итоги

  • темп работы

  • независимость

  • bus factor

  • страх

Начинаем работу над стартапом и получаем проблему

Начало

Февраль, 2020

Как было написано в предыдущей статье, как только идея стартапа более менее оформилась, мы подготовили презентацию и пошли в организацию контролирующую сферу строительства Государственный архитектурно-строительный контроль (ГАСК). Провели презентацию и их заинтересовала наша идея. Они спросили про наши хотелки:

1. Определить одну-две строительств, где мы можем тестировать свои наработки в процессе разработки.

2. Организовать встречу со всеми участниками этих строительств.

Встреча была организована. В процессе встречи, мы рассказали свои цели, что мы хотим, почему хотим, что это даст. Мы их информировали, что нам понадобится немного времени, чтобы разработать ядро системы. Когда руководитель ГАСК спросил сколько времени нужно, я сказал что нужен месяц.

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

Договорились, что по окончанию работы над ядром мы сообщим об этом и после должна была начаться совместная работа над внедрением инструментов.

Работа над ядром

У меня было видение каким должно быть наше приложение, не в смысле как оно должно выглядеть, или как будет работать. А что за проблему она хочет решать и как она это будет делать. Для того чтобы начинать внедрять инструменты по сфере строительства, необходимо было разработать довольно большой функционал. Около 20-30 сценариев использования, а может и больше. Это и было ядром приложения, которое нам необходимо было разработать.

Стек технологии.

• Бекэнд - python + django + viewflow.

• Фронтэнд - js + react.

• Общение через rest

Мы начали. Примерно через два месяца работы, поняли что выбрали не правильный архитектурный стиль. Дело в том, что все сценарии использования были построены на основе нотации описания бизнес процессов BPMN. Почему бизнес-процессы?

• потому что я довольно много изучал про описание работы организации через бизнес процессы. Помните, я хотел в первом бизнесе перейти на бизнес-процессы;

• потому что был неплохой фреймворк;

• потому что не знал, что это плохое решение.

Итого, увидев ошибку мы выбросили примерно 60% написанного кода и продолжили работу. Работа над ядром в общем заняло четыре месяца, была проделана довольно большая работа в бешенном темпе на износ. Но мы это сделали.

Заинтересованные лица (ГАСК)

Сотрудники ГАСК в течении первого месяца звонили почти каждую неделю. Интересовались как идут дела, не нужна ли какая нибудь помощь по предметной части, нормативные документы например. Второй, третий месяц звонки были уже через каждые две недели. По истечении третьего месяца, позвонил уже руководитель ГАСК-а. Я и сам думал, что надо сходить, объяснить что за заминка произошла и передоговориться по срокам. Но он позвонил первый. Сходил, объяснил, передоговорился. Ему не понравились новые сроки, 2-4 недели. Я уверил, что 4 недели это с запасом, скорее всего 2 недели. Причины для такого обещания были, после отказа от бизнес процессов работа шла споро. Но в итоге, еле успели за 4 недели.

Результаты работы

Начало июня 2020 года.

Когда работа над ядром была закончена, я пошел в ГАСК. Хотел договориться о собрании, где мы покажем над чем мы все это время работали и наметить следующие шаги. При встрече с руководителем, сразу было подмечено холодность. Понятно, доверие потеряно. На просьбу организовать встречу, мне отказали сославшись на занятость в связи с приездом со столицы кого то из чиновников (уже не помню кто, но кто то точно приезжал. Так что отказ был обоснованный). В этой же встрече мне сказали, что со столицы внедряют новую программу E-Qurylys и как будто бы инструменты в которых нуждался ГАСК в нем уже есть.

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

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

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

Решаем проблемы

Пока ждали, когда пройдет приезд чиновника из столицы думали над нашими проблемами и что с ними делать. Итого какие у нас были проблемы:

Плохая архитектура в бэкенде. Помните выше обсуждалось, что должны были успеть за две недели и еле успели за четыре. Основная причина в том, что мы сделали так, что сценарии использования напрямую влияли друг на друга. Когда первые сценарии разрабатывались, то все норм. Каждая последующая могла влиять на предыдущую. Это привело к тому, что разрабатывая сценарии использования мы могли получить другой неработающий сценарий использования. Обычно узнавали про это не сразу. Тестов нет. Почему нет тестов? Потому что нет времени на тесты. Все это осложняло поиск причины поломки. Сам был свидетелем, как разработка сценария использования занимало 4 часа, а последующий поиск и исправление ошибки занимало два дня.

Когда узнали про это, стало понятно, что в будущем надо развязать сценарии использования друг от друга. Но в тот момент на это не было времени. И наверняка это было не единственное слабое место в архитектуре. А слабая архитектура, это прямая дорога к новым срывам сроков в будущем.

Плохой UX во фронтэнде. В приложении было довольно много функциональности, но они были так не очевидны. Я смотрел на всю эту запутанную взаимосвязь действии и думал: “Если мне сложно в этом разобраться, то как в этом разберется конечный пользователь?”

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

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

Если резюмировать, источник проблем - команда не имеет хороший, практический опыт реализации таких больших и сложных систем.

Что делать?

Есть две пути:

• продолжаем по намеченному пути развивая продукт дальше.Плюсы: Наконец-то начнем внедрять функционал.Минусы: Проблемы разработки не разрешены, что влечет риски. Конечно проблемы можно решать параллельно внедрению функционала. Но их так много, и они настолько фундаментальны, что есть большое сомнение в том что мы сможем быстро, качественно развивать продукт.

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

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

Командой решали, что делать. Настроения были за то, чтобы продолжать. Я разрывался на части.

Первая хотела продолжить. Еще одной причиной было то, что я как раз закончил читать книгу “Бережливый стартап” и там говорилось, что надо как можно быстрее выпускать продукт и получать ответы на свои гипотезы.

Вторая - перфекционизм, хотела вернуться и все переделать. Я всегда любил делать работу хорошо. Настолько хорошо, насколько мог. Качество для меня не пустое слово.

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

Ищем помощь в стороне.

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

Обязанности технического директора:

• просмотреть текущее состояние кода;

• принять решение как дальше будет вестись разработка;

• вести разработку.

Начали. Первые дни было более менее, мы созванивались, он отвечал на наши вопросы, задавал много вопросов мне как владельцу продукта. Но позднее он начал пропадать. Бывало ребята по нескольку дней не могли созвониться. Сидели и ничего не делали, потому что непонятно что делать. И я не могу ничего сделать, ведь теперь к разработке я не имел отношения. Я тоже звонил, тоже безуспешно. Иногда он появлялся конечно, что то сдвигалось с места, а потом опять.

Надежды не оправдались. Между прочим его компетентность мне понравилась. Когда он скинул задание ребятам, сама постановка задачи была такой, что давался на уровне архитектурного или алгоритмического решения. Ребятам пришлось бы понять как основной алгоритм, как это все задумано, так и конечно же реализовать его. Жаль, что наш стартап его не заинтересовал.

Решили искать другого. Нашли кандидата, но и там долгая обратная связь. Мы даже не прошли стадию создания договоренности. Что получили?

• кандидаты есть и даже компетентные;

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

• поиск того кто нам нужен, может затянуться на неопределенный срок. При этом нет гарантий, что это случится.

• сами интервью с кандидатами были для нас полезными. По вопросам кандидатов и нашим встречным вопросам узнаешь много нового.

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

В хабр-фриланс закинули описание своих хотелок:

• Необходимо разработать и реализовать ядро фронтэнда веб-приложения.

• Необходимо проектирование и разработка UI/UX веб приложения.

• Необходимо разработать контракт между бэкэндом и фронтэндом.

• Необходимо при выполнении работ активно привлекать команду (2 человека во фронтэнде) и распределять задачи между ними.

• Необходимо чтобы команда могла самостоятельно продолжить работу над стартапом после окончания сотрудничества.

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

Бюджет работы 40 тыс. рублей. Начали. После начала работы, я дополнил требования новыми пунктами:

• ядро не должно быть привязано к текущему дизайну;

• ядро не должно быть привязано к одному типу приложения, и поддерживать возможность разработки мобильной версии приложения.

Это привело удорожанию до 60 000 рублей РФ. Мы задавали вопросы, как будут реализовываться наши новые требования и получили понятные внятные ответы. Подрядчик каждый день выходил на связь, давал отчеты над чем работал, сколько примерно осталось.

Мне сильно понравилось формат работы, и я решил сделать то же самое и в бэкенде. Про бэкенд будет в соответствующем разделе, а здесь продолжим про фронтэнд.

Ближе к концу работы у меня случились проблемы. Оказалось, что налоговая служба арестовала мои счета. Начал разбираться. Налоговая решила, что я должен заплатить дополнительные налоги (я провозил через границу с РФ материалы в связи со строительством дома). Пришлось объясняться, заняло около 10 дней.

Когда все это началось, объяснил это подрядчику, сказал что можно будет продолжать, я гарантирую, что он получит свои деньги. Подрядчик, предпочел приостановить работы, так как и так у меня образовалась задолженность. Тут же выявилась другая проблема. Когда мы дополнили новые требования, я предполагал что работа увеличилась до 60 000 рублей, а подрядчик говорил что это увеличивает стоимость на 60 000 рублей. Переговоры не привели к результату, пришлось согласиться.

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

Перевел… и тишина. Подрядчик пропал.

Пришло понимание, меня кинули. Узнал у фронтэнда, сколько работы было сделано. Сказали около 20%. Был ли я в шоке? Несомненно.

Какой я лох! Почему так так случилось? Почему я так наивен? Это первая реакция. Давайте сделаем анализ, как я дожил до жизни такой:

• Отсутствие опыта работы с подрядчиками. В первом бизнесе мы были подрядчиками, и мы практически 99% работы выполняли сами. Опыта работы с подрядчиками у меня мало. Тем более если учесть, что я работал как простой работник.

• В моем опыте, был подобный случай. Но видать стоимость потери была маленькой, и урок не был усвоен. Опыт работы с подрядчиками при строительстве дома говорит мне, что этот навык мне сложно прокачивать. Там хоть и не было таких случаев, но опыт показывает что я слишком мягок с подрядчиками. Это не всегда плохо, часто это дает хорошие результаты. Но все же...

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

• Подрядчик скорее всего вначале работу выполнял, потом увидев как все у нас поставлено понял что можно и не делать. Но это догадки.

В итоге, оплачено 94% денег, 92 000 рублей из 98 000. Получено 20% кода и бесценный опыт).

Бекэнд. Как мы помним, мне понравился формат работы с подрядчиком. И не забывайте, что на этот момент я еще не получил вышеописанный опыт. Потоки идут параллельно.

Еще одно объявление в хабр-фриланс. Много откликов. Два интервью. С первым пролет по финансовой стороне. Со вторым было интереснее. Кандидат задавал много вопросов. Вопросы наводящие. Почему было сделано так? А что будет если в будущем захотите эдак? Что нужно, чтобы это можно сделать быстро?

В том интервью мы узнали, что есть предметная часть приложения. И хорошо бы явно понимать что это предметная часть. И хорошо бы вынести его отдельно от фреймворка. Как сущности, так и логику. Он не взялся за работу, но в конце интервью он посоветовал прочитать книгу “Чистая архитектура” дядюшки Боба, пообещав что нам станет понятно про что он говорил. К сожалению не нашел его профиль в откликах на объявление. Но я так благодарен за то, что он потратил столько времени на интервью и показал нам путь.

По итогам интервью даже не начав читать рекомендованную книгу было понятно где можно проработать и улучшить нашу архитектуру. Решили прочитать книгу. И потом решить что делать дальше.

А время уже август месяц.

clean architecture, ddd

Читая книгу чувствовал, опять поднимается вопрос. Что делать? Продолжить разработку с тем что есть, или поработать с архитектурой?

Помню как все мое естество желало поработать с архитектурой. А мой ум явно говорил: “Нурболат, какой толк что ты читаешь книги типа “Бережливого стартапа”, если ты не следуешь знаниям вычитанных с этих книг?”. И он был прав. Но я не послушал его.

Я склонил команду к проработке архитектуры. Шаг назад длиной в пару месяцев. Зато у нас будет лучше архитектура. А полученные знания при реализации новой архитектуры позволят встретиться и решать проблемы следующего уровня. Команда была не против. Правда это означало, что весь код бекэнда тоже придется выкидывать, все 100%. Ну и что, зато у нас будет “Чистая архитектура”).

Читая книгу, параллельно читал статьи по этой же теме, и несколько раз встречал термин ddd “Domain Driven Design”. Почитал статьи и по нему. Заказал книги по ddd. Синюю и красную. Как раз когда дочитали книги “Чистая архитектура”, “Чистый код”, пришли и эти книги. Начали читать их. Параллельно знакомились с понятиями cqrs, event sourcing и изучали их тоже. Обсуждали изученное. Искали библиотеки по этим темам. Знакомились с ними. В какой то момент начали писать код и прикидывать как это может выглядеть. И тут Нурболат (я) опять все сломал…

Переходим с python, js на TypeScript

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

1. привлечение опытных специалистов;

2. самостоятельно учить специалистов, а далее подбрасывать их в жернова команд;

Про первый пункт я уже писал, давайте поговорим про вторую.

В том что я хочу  быть полезным для страны вы уже знаете. Давайте скажем, что я возложил на себя миссию: “Хочу быть полезным для своей страны, и сделать ее лучше”. Была и другая миссия: “Хочу поднять it культуру в нашем городе”.

Для этого я в будущем планирую набирать желающих стать программистами и обучать их. Моих текущих знаний уже хватит, чтобы нормально подготовить их для разработки в командах. Это могут быть кто угодно, школьники, студенты, безработные и т.д. Что я получу? Удовлетворение:

• делясь знаниями;

• помогая другим людям без опыта, стать специалистами;

• давая возможность устроиться на работу в одном из своих стартапов (я еще не говорил, что у меня есть и другие идеи?);

• решая кадровые вопросы в своих стартапах;

Сплошные профиты.

Цена: конечно надо будет тратить временные и ментальные ресурсы. Но мне почему то кажется, что это не будет проблемой.

Ну так вот. В одном из раздумий ко мне пришло осознание, что надо выбрать язык на котором я буду учить. Если гипотетически представить, что придет школьник. То он самой собой не знает что такое фронтэнд и бекэнд. А я не знаю, к чему у него предрасположенность. Если я буду учить условно питону, то теоретически будут выходить много бекэндеров и ноль фронтэндеров. Что уже проблема. Тогда мне надо учить js и давать уроки в нем. Но бекэнд сидит на…, постой, а если мы на бэкенде перейдем на js. А еще лучше на TypeScript перейдет и фронтэнд и бэкенд. Тогда я буду учить студентов на этом языке. Походу учебы студенты сами будут выбирать специализацию. А команды будут получать готовый полуфабрикат. Эврика!

Дальнейшие размышления дали следующие бонусы:

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

• единый язык во фронэнде и бэкенде в теории улучшит взаимодействие внутри команды. Между фронтэндом и бекэндом будут больше тем для обсуждения;

• единый язык теоретически позволяет сильно уменьшить Bus Factor;

Цена:

• придется опять выкинуть весь код, теперь даже во фронтэнде. В итоге у нас будет абсолютно 0 строчек кода. И это результат работы с февраля по ноябрь;

• придется учить новый язык, причем члены команды не имели или имели маленький опыт работы с языком со статической типизацией;

 Мда. Но открывающиеся перспективы говорили мне, что надо поступать именно так.

Пришел в команду, сказал, объяснив по ходу причины решения. Один из бекэндеров сказал, что если переходим, то лучше в Java. Этот язык является эталоном в энтерпрайз разработке. Да, он был прав. Но это решение не увязывалось с моими выше описанными стратегическими планами. Так что, я продавил решение, что теперь и фронтэнд и бекэнд будет разрабатываться в ts. Так мы сделали еще один шаг назад от реализации продукта. Но правда я себя утешал, что это отсрочит начало работы над продуктом всего лишь на пару месяцев, а бонусы очень уж жирные.

Мы начали изучать TypeScript. Бекэндеры не знакомые с JavaScript начали изучение с него, в том числе и я. По ходу изучения, мы изучили фреймворк NestJS в бэкенде. В его документации было написано, что вдохновением при разработке архитектуры было Angular. И я опять же продавил, чтобы и фронтэнд переходил на нее. Фронтэнд разработчик сопротивлялся этому решению. Но куда ему тягаться с адской смесью в виде разработчика, архитектора, владельца продукта, директора и учредителя компании в одном лице. Я так и сказал: “Я не знаю, будет ли действительный эффект от перехода. Но если в этих двух фреймворках хотя бы частично будут одинаковые архитектурные решения, то мы этим переходом теоретически уменьшим когнитивную нагрузку для fullstack разработчиков. Это в будущем упростит изучение и переключение контекстов в работе.” Видите сколько умных слов иногда надо сначала выучить, а потом еще и пересказать, чтобы все было по твоему. Короче, фронтэнд разработчик согласился и начал изучать Angular.

Все это обучение и изучение мы делали ровно до Нового Года, так получилось.

Работаем над архитектурой

С начала 2021 года, мы начали потихоньку прикидывать и разрабатывать нашу архитектуру, согласно того что мы изучили.

Это действо, в виде сварения в виде одного бульона таких ингредиентов как clean architecture, ddd, event sourcing, cqrs и все что сопутствует им оказалось не такой легкой задачей. Особенно учитывая, что сложный рецепт приготовления прочитали четыре неокрепших ума, и у каждого было свое представление о приготовлении этого блюда. А еще сюда добавляется, что огонь на котором мы готовим было не простая газовая горелка как раньше (python + js), а открытый костер с которым надо уметь работать (ts). Начиная со следующих постов буду делиться тем, что получилось. Прошу читателей быть снисходительными, если вы почувствуете запах в полученном бульоне.

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

Теперь конечно стратегия развития продукта изменилась. Я не собираюсь как в начале нашего пути выполнять реализацию ядра приложения. Вместо этого мы будем внедрять функционал по очереди давая пользователям опробовать и собирая обратную связь. Мое видение каким будет в будущем приложение не изменилось. Но мы будем идти к нему эмпирически и итеративно.

Что это нам дало, и чего это нам стоило?

Продукту

Дало: Продукт получил более осознанную и опытную команду разработки . Это в перспективе даст возможность намного быстрее и качественнее достигать целей продукта.

Стоило: Продукт многим пожертвовал.

• Опытом который можно было бы получить внедряя инструменты и анализируя насколько это востребовано и в правильном ли пути движется продукт.

• Рынком, потенциальными клиентами, возможностью начать зарабатывать. Этот путь продукту только предстоит пройти.

• Исчерпал бюджет, поставив под угрозу весь стартап.

Команде разработки

Дало: Команда разработки получила очень хорошие бонусы:

• улучшилась общая экспертиза команды в хард скиллах, которая была проверена в реальных условиях при разработке архитектуры;

• переход на единый язык во всей команде предоставляет лучшее сцепление и гибкость внутри команды;

• есть хотя бы в зачаточном состоянии попытки переходить в процессную разработку;

• улучшилось внутрикомандное взаимодействие. Приходилось как то находить точки соприкосновения, договариваться как решать спорные вопросы и т.д.
  Если развить тему, то в начале работы позиции архитектора не было. Предполагалось, что решения будут приниматься командно, иногда мы даже голосовали. Решения были настолько разными, что кодовая база напоминала плохой салат и мне сильно не нравилось то, что получалось. Попытки прийти к чему то общему через обсуждение не приводили к результату. В конце концов мной было принято решение, что теперь я архитектор, и окончательное решение за мной. Задача разработчика теперь объяснить архитектору почему его решение лучше. Если у него получится, тогда примется. Если нет, тогда иди и думай что и как надо объяснить архитектору, чтобы он понял что он не прав, или прими вариант архитектора.

• Стоило: А ничего не стоило, команда разработки в шоколаде. Но теперь ему надо отдавать должок продукту.

Разработчику

Дало: Если команда разработки в шоколаде, то разработчик как основной юнит команды в купается в золоте:

• не хило прокачал хард скиллы;

• не хило прокачал софт скиллы;

• в итоге, он лучше будет цениться на рынке труда;

Стоило: Чем то все таки пришлось пожертвовать.

• пришлось много учить и изучать;

• часто идти в компромисс с другими людьми, которые имеют склонность думать и вести себя неправильно;

Итоги

Темп работы

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

Независимость

Так и вижу комментарии, что на стадии mvp надо сконцентрироваться на получении ответов на вопрос: "Есть ли потенциал у продукта на рынке"? И вы правы, это так. Приведу только свои аргументы.

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

Допустим даже, что это мне не удастся. Но у меня много идей и для других стартапов. И все эти идеи будут упираться в одну проблему, проблему разработки. Иными словами, это означает, что мои идеи находятся в зависимости от способности команды разработки реализовывать их.

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

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

А я как владелец продукта теперь знаю, что у меня есть команда разработки которая может реализовывать видение продукта.

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

Bus Factor

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

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

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

Страх

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

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

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

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

Так что могу повторить и здесь. Любой выбор он правильный. Любой путь хороший. Вопрос в другом: “Готовы ли мы сделать свой выбор пойти по своему пути и принять ответственность за этот выбор”?

UPD:

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

Запросил обратную связь у своей команды. Что не так со статьей? Один из разработчиков сказал, что это действительно плохая статья. Претензии было два:

1. История не имеет логического конца. Читатель думает, что в конце истории будет какая то логическая развязка. Но история оборвана и оставляет читателя в недоумении.

2. Нет никакой полезной нагрузки для читателя. Читатель прочитав не узнает ничего полезного.

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

У статьи нет логического конца.

Первое. Добавил описания статьи в разделе “Введение”. Надеюсь это хоть немного поможет.

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

Для читателя, в статье нет ничего полезного.

Когда мы изучаем чужой опыт в подобных статьях, или узнаем новые знания в книгах как например “Бережливый стартап”. То очень важно понимать ответы на следующие вопросы: “Что за проблему они решают?”. Почему именно эту проблему надо решить? И только потом уже: “Как решить эту проблему?”.

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

Именно поэтому, решение с книги “Бережливый стартап” не подошло к нам. Потому что в нашем контексте была и другая проблема. Это проблема - слабая команда разработки. Книга подразумевает, что такой проблемы у стартапа нет и она акцентирована на решение другой проблемы. Именно поэтому мы и не воспользовались советами и знаниями с этой книги в свое время.

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

В статье я очень подробно постарался ответить на эти три вопроса: “Что мы делали?”, “Почему мы это делали?”, “Как это мы делали?”. А еще сделал анализ. Что это дало: продукту, команде разработки и разработчикам. А также свои личные выводы, что дало и какие инсайты были лично у меня.

При написании статьи я старался сделать его максимально полезным для читателя. Для этого я ничего не приукрашивал. И что особенно важно, ничего не скрывал. Все написано честно и открыто.

Читатель может считать наши решения и наш путь глупым. Это его право и я не оспариваю это. Но в то же время, читатель не может отказать нам, в нашем праве идти своим путем. Даже если наши решения и наш путь ему не нравится или он считает его глупым.

Но конечно же, читатель имеет право не согласиться со мной.

Опрос:

Входные параметры:

• продукт со сложной предметной областью;

• в команде разработки нет опытных программистов;

• бюджет продукта не позволяет просто набрать на рынке отличных специалистов;

• бюджет продукта не позволяет взять на постоянную работу даже одного хорошего специалиста;