«Успех — не ключ к счастью.Теги: #Разработка стартапов #Читальный зал #архитектура #стартап #история стартапов #история стартаповСчастье — ключ к успеху.
Если вы любите то, что делаете, вы добьетесь успеха» — Герман Кейн «Если хочешь идти быстро, иди один.
Если хочешь пойти далеко, иди вместе» — африканская пословица.
Введение
Это вторая статья из серии запланированных статей:
- Первый стартап, или как я в него пришел.
- история, которая отвечает на вопрос Почему Собственно, я к этому пришел и какой путь мне пришлось пройти.
- Второй стартап, или Как мы стали программистами - история этой статьи рассказывает о пути нашей команды в разработке продукта и о том, как нам пришлось повышать свои навыки.
Команда неопытная, как написано в первой статье.
Путь команды неоднозначен.
Эта статья рассказывает историю только до момента публикации, а результаты истории будут в следующих статьях в виде обсуждения архитектуры.
- Архитектура стартап-приложения, вид с высоты птичьего полета .
- обобщенный анализ принятых решений.
- Архитектура запускаемого приложения, уровень домена.
- Архитектура запускаемого приложения, уровень приложения.
Часть 1.
- Архитектура запускаемого приложения, уровень приложения.
Часть 2.
- Архитектура стартап-приложений, Frontend.
- Процесс разработки на примере реализации UseCase.
План
- Начинаем работать над стартапом и получаем проблему.
- Начинать
- Работаем над ядром
- Заинтересованные лица
- Итоги работы, у нас проблемы
- Решение проблемы
- ищу помощи на стороне
- чистая архитектура, ддд
- переход с Python, JS на TypeScript
- работаем над нашей архитектурой
- Что это нам дало и чего нам это стоило?
- продукт
- Команда разработчиков
- Разработчики
- Полученные результаты
- темп работы
- независимость
- коэффициент автобуса
- страх
Начинаем работать над стартапом и получаем проблему
Начинать
февраль, 2020 г.Как было написано в предыдущей статье, как только идея стартапа более-менее сформировалась, мы подготовили презентацию и отправились в организацию, контролирующую строительную сферу, — Государственный архитектурно-строительный контроль (ГАСК).
Мы сделали презентацию, и наша идея заинтересовала их.
Спросили о наших пожеланиях:
Встреча была организована.
- Определите одну или две строительные площадки, где мы сможем протестировать наши разработки в процессе разработки.
- Организовать встречу со всеми участниками этих строек.
В ходе встречи мы рассказали наши цели, чего мы хотим, почему мы этого хотим, что это даст. Мы сообщили им, что нам понадобится немного времени, чтобы разработать ядро системы.
Когда руководитель ГАСК спросил, сколько времени нужно, я сказал, что нужен месяц.
На самом деле я знал, что одного месяца нам не хватит на разработку ядра.Мы договорились, что по завершении работы над ядром сообщим об этом и тогда должна начаться совместная работа по внедрению инструментов.По моим прикидкам, это заняло около двух месяцев.
Но желание произвести приятное впечатление было настолько велико, что я поддался этому желанию и объявил этот срок.
Работаем над ядром
У меня было видение того, каким должно быть наше приложение, а не в смысле того, как оно должно выглядеть или как оно будет работать.Какую проблему она хочет решить и как она это сделает? Для того, чтобы начать внедрять инструменты в строительной отрасли, необходимо было разработать довольно много функционала.
Примерно 20-30 вариантов использования, а может и больше.
Это было ядром приложения, которое нам нужно было разработать.
Стек технологий.
Мы начали.
- Бэкенд — python + django + viewflow.
- Фронтенд — js+react.
- Общение через отдых
Примерно через два месяца работы мы поняли, что выбрали неправильный архитектурный стиль.
Дело в том, что все варианты использования были построены на основе нотации описания бизнес-процессов BPMN. Почему бизнес-процессы?
В общей сложности, когда мы увидели ошибку, мы выбросили около 60% написанного кода и продолжили работу.
- потому что я довольно много изучал описание работы организации через бизнес-процессы.
Помните, в своем первом бизнесе я хотел перейти на бизнес-процессы;
- потому что это была хорошая основа;
- потому что я не знал, что это было плохое решение.
Всего работа над ядром заняла четыре месяца; довольно много работы было выполнено в бешеном темпе до полного износа.
Но мы сделали это.
Заинтересованные стороны (ГАСК)
В течение первого месяца сотрудники ГАСК звонили почти каждую неделю.Их интересовало, как обстоят дела, нужна ли им помощь по теме, нормативным документам, например.
Второй и третий месяц звонки были каждые две недели.
По прошествии третьего месяца позвонил руководитель ГАСК.
Я сам подумал, что надо пойти объяснить, в чем случилась икота, и договориться о сроках.
Но он позвонил первым.
Я съездил, объяснил, договорился.
Ему не понравились новые сроки, 2-4 недели.
Я заверил, что 4 недели — это запас, скорее всего 2 недели.
Для такого обещания были причины; после отказа от бизнес-процессов работа пошла гладко.
Но в итоге мы едва успели за 4 недели.
Результаты работы
Начало июня 2020. Когда работа над ядром была завершена, я пошёл в ГАСК.Мне хотелось организовать встречу, где мы бы показали, над чем работали все это время, и наметили дальнейшие шаги.
При встрече с менеджером сразу была замечена холодность.
Понятно, что доверие потеряно.
На мою просьбу организовать встречу мне отказали, сославшись на то, что я занят в связи с приездом одного из чиновников из столицы (не помню кто, но кто-то точно приходил.
Так что отказ был обоснованным) .
На той же встрече мне сказали, что из столицы внедряется новая программа E-Qurylys и как будто инструменты, необходимые САСК, уже есть.
Позиции нашего стартапа сильно ослабли; раньше, если мы были стартапом с инновационным решением, то теперь мы — догоняющий стартап, который постоянно срывает сроки.
Такая холодность и конкурент меня конечно не порадовали.
В последующие дни, недели, месяцы во мне снова поселилась тревога.
Я точно помню эти моменты визита.
Оно приходит без предупреждения, его очень сложно отогнать, оно не позволяет сконцентрироваться и истощает всю энергию.
В результате – пустота в груди и каша депрессивных мыслей в голове.
Хорошо, что это происходило периодически.
Автор: E-Qurylys. Еще до начала работы над стартапом я знал и слышал, что средства выделены и такая программа разрабатывается.
Если это означает, что мне следует отказаться от своей идеи, то, конечно, нет. Но это было вначале, и в тот момент я понял, что мы безнадежно отстали.
Конкуренты уже разработали инструменты и внедряют их, а мы еще даже не начали.
Мы решаем проблемы
Пока мы ждали приезда столичного чиновника, мы думали о своих проблемах и о том, что с ними делать.Итак, какие проблемы у нас возникли: Плохая архитектура серверной части.
Помните, выше говорилось, что мы должны были сделать это за две недели, а еле успели за четыре.
Основная причина в том, что мы позаботились о том, чтобы варианты использования напрямую влияли друг на друга.
Когда были разработаны первые сценарии, все было хорошо.
Каждый последующий мог влиять на предыдущий.
Это привело к тому, что при разработке вариантов использования мы могли получить еще один вариант использования, который не сработал.
Обычно об этом узнавали не сразу.
Тестов нет. Почему нет тестов? Потому что нет времени на тесты.
Все это усложнило поиск причины поломки.
Я сам был свидетелем того, как разработка варианта использования заняла 4 часа, а последующий поиск и исправление ошибки — два дня.
Когда мы узнали об этом, стало ясно, что в будущем нам нужно отделить варианты использования друг от друга.
Но в тот момент на это не было времени.
И это, наверное, было не единственное слабое место в архитектуре.
А слабая архитектура — это прямая дорога к новым сорванным срокам в будущем.
Плохой UX на фронтенде.
Функционалов в приложении было довольно много, но они были не столь очевидны.
Я посмотрел на всю эту запутанную взаимосвязь действий и подумал: «Если мне это сложно понять, то как это поймет конечный пользовательЭ» Слабый процесс разработки.
Вернее, его почти не существовало.
Я просто решил, что нужно сделать (использовать сценарии), мы обсудили, как это должно работать.
А потом на ежедневном собрании давал задание, если у кого-то предыдущее задание было выполнено.
Это было не так уж и хардкорно, но все равно близко.
Изучение и внедрение новых технологий, таких как отдых, конечно, тоже отнимали свою долю времени и добавляли свой вклад в сложность развития.
Подводя итог, источник проблем в том, что у команды нет хорошего практического опыта внедрения таких больших и сложных систем.
Что делать? Есть два способа:
Конечно, мы не думали, что наш MVP должен быть супернадежным и качественным.
- Продолжаем идти намеченным путем, развивая продукт дальше.
Плюсы: Наконец-то приступим к реализации функционала.
Минусы: Не решены проблемы развития, что влечет за собой риски.
Конечно, проблемы можно решать параллельно с реализацией функционала.
Но их так много, и они настолько принципиальны, что возникает большое сомнение, что мы сможем быстро и эффективно разработать продукт.
- мы приостанавливаем внедрение продукта и решаем проблемы разработки.
Плюсы: решив основные проблемы, можно ожидать, что разработка продукта пойдет быстрее.
Минусы: продукт не развивается, рынок захватывается конкурентом, нет гарантии, что мы сможем решить свои проблемы самостоятельно.
Стратегия была той же самой; после сбора финансирования предполагалось, что мы привлечем опытных программистов и была вероятность, что приложение будет переписано.
Но все равно хотелось хоть какого-то качества, а то, что у нас было, мне не очень нравилось.
Команда решила, что делать.
Настроение было в пользу продолжения.
Я был разорван на части.
Первый хотел продолжить.
Другая причина заключалась в том, что я только что закончил читать книгу «Бережливый стартап», и там говорилось, что нужно как можно быстрее выпустить продукт и получить ответы на свои гипотезы.
Второе — перфекционизм, хотелось вернуться и все переделать.
Мне всегда нравилось делать хорошую работу.
Как можно лучше.
Качество для меня не пустое слово.
Один из членов команды высказал мысль, что было бы хорошо, если бы мы нашли кого-то опытного, с кем можно было бы посоветоваться в сложных ситуациях.
Так сказать, внештатный консультант. Это была хорошая идея.
За пару дней я развил идею.
Кандидат также может занять должность технического директора.
В общем, идея была в том, чтобы привлечь опытного разработчика с двумя вариантами работы, внештатным консультантом или техническим директором.
При этом второй вариант мне уже понравился больше.
В конце концов мы решили, что будет лучше, если мы приостановим работу над продуктом и найдём консультанта/технического директора.
Он рассмотрит нашу архитектуру.
Поговорив с ним, мы решим, что и как лучше делать дальше.
Конечно, я был полон решимости начать работу с продуктом максимум через пару месяцев.
Мы ищем помощи на стороне.
В хабре карьеры он сообщил, что стартап ищет специалиста на должность консультанта.
Ответили несколько человек.
Было несколько звонков.
Выбор пал на самый дорогой; он согласился работать техническим директором.
Для этого предполагалось, что он будет работать в интенсивном режиме (4 часа в день) около двух недель.
И потом два-три дня в неделю по два часа в день.
Ему перешли все полномочия по разработке, и я наконец смог полностью сосредоточиться на делах владельца продукта.
Обязанности технического директора:
Давайте начнем.
- просмотреть текущий статус кода;
- решить, как будет идти развитие дальше;
- вести разработку.
Первые дни прошли более-менее, мы созванивались, он отвечал на наши вопросы, задавал много вопросов мне как владельцу товара.
Но позже он начал пропадать.
Иногда ребята по нескольку дней не могли поговорить по телефону.
Мы сидели и ничего не делали, потому что было непонятно, что делать.
И я ничего не могу сделать, потому что теперь я не имею никакого отношения к разработке.
Я тоже звонил, тоже безуспешно.
Иногда он появлялся, конечно, что-то двигалось, а потом еще раз.
Надежды не оправдались.
Кстати, мне понравилась его компетентность.
Когда он отправил задание ребятам, сама формулировка задачи была такова, что она давалась на уровне архитектурного или алгоритмического решения.
Ребятам предстояло понять и основной алгоритм, как это все задумано, и, конечно же, реализовать его.
Жаль, что его не заинтересовал наш стартап.
Мы решили искать другого.
Мы нашли кандидата, но была еще и длинная обратная связь.
Мы даже не прошли этап создания соглашения.
Что ты получил?
Итак, наш опыт показал, что здесь есть много рисков.
- есть кандидаты и даже компетентные;
- поиск, собеседование, отбор, заключение договоров, начало работы – это достаточно длительный и дорогостоящий процесс.
Хуже того, так как мы ждали, что придет опытный специалист и решит наши проблемы, то сами ничего сделать не могли.
Фактически за это время, а это чуть больше месяца, мы ничего не сделали самостоятельно.
Ребята пришли и просто посидели.
Ну не совсем так, конечно, что-то читали, видео смотрели.
Но все равно мы не могли написать код, потому что было непонятно, что писать, куда идти.
- Поиск того, кто нам нужен, может затянуться на неопределенный срок.
Однако нет никаких гарантий, что это произойдет.
- Для нас были полезны интервью с самими кандидатами.
Вы узнаете много нового о вопросах кандидатов и наших встречных вопросах.
Нам нужно изменить тактику.
Опять обсуждение с командой.
Мы решили, что давайте сосредоточимся на архитектуре интерфейса и UX. Для этого мы привлечем опытного специалиста и предложим ему объем работ. Он разработает для нас базовую архитектуру фронтенд-приложения.
Они добавили описание своих пожеланий на Хабр-фриланс:
Откликалось довольно много людей.
- Необходимо разработать и реализовать ядро фронтенда веб-приложения.
- Требуется проектирование и разработка веб-приложения UI/UX.
- Необходимо разработать контракт между бэкендом и фронтендом.
- При выполнении работ необходимо активно задействовать команду (2 человека во фронтенде) и распределять задачи между ними.
- Необходимо, чтобы команда могла самостоятельно продолжить работу над стартапом после окончания сотрудничества.
Мы выбрали одного, он дал лучший отзыв о том, что не так в нашем коде и над чем нам нужно поработать.
Я еще раз изложил наши условия.
Он сказал, что будет работать над архитектурой один, это будет гораздо быстрее.
Ребятам будет предоставлена работа над компонентами.
В конце он покажет вам, как все связать воедино.
Бюджет работы 40 тысяч рублей.
Давайте начнем.
После начала работы я дополнил требования новыми пунктами:
Это привело к увеличению цены до 60 000 российских рублей.
- ядро не должно быть привязано к текущему дизайну;
- ядро не должно быть привязано к одному типу приложений и должно поддерживать возможность разработки мобильной версии приложения.
Мы задали вопросы о том, как будут реализованы наши новые требования, и получили четкие, доходчивые ответы.
Подрядчик каждый день выходил на связь, давал отчеты о том, над чем работает, и примерно, сколько осталось.
Мне очень понравился формат работы, и я решил сделать то же самое в бэкенде.
О бэкенде мы поговорим в соответствующем разделе, а здесь продолжим о фронтенде.
Под конец работы у меня возникли проблемы.
Оказалось, что налоговая служба арестовала мои счета.
Я начал в этом разбираться.
Налоговая решила, что я должен заплатить дополнительные налоги (перевозил материалы через границу с РФ в связи со строительством дома).
Пришлось объясняться, это заняло около 10 дней.
Когда все это началось, я объяснил это подрядчику, сказал, что мы можем продолжать, я гарантирую, что он получит свои деньги.
Подрядчик решил приостановить работу, так как у меня уже была задолженность.
Сразу возникла еще одна проблема.
Когда мы добавили новые требования, я предполагал, что работа увеличится до 60 000 рублей, но подрядчик сказал, что это увеличило стоимость на 60 000 рублей.
Переговоры не привели к результату, мне пришлось согласиться.
После того, как я решил задачи, мы продолжили.
Под конец подрядчик сказал, что у него проблемы и попросил деньги вперед. Я подозревал, что это означало, что я практически заплачу всю сумму.
Но я его отключил.
Тем не менее, он постоянно выходил на связь, отвечал на все наши вопросы, и даже через бэкенд мы получали ответы на вопросы.
Плюс желание быть полезным людям.
Перевел.
и тишина.
Подрядчик исчез.
Пришло понимание, меня бросили.
Я узнал из фронтенда, какой объем работы был проделан.
Сказали около 20%.
Был ли я шокирован? Без сомнения.
Какой я лох! Почему это случилось? Почему я такой наивный? Это первая реакция.
Давайте проанализируем, как я жил, чтобы так жить:
В итоге было выплачено 94% денег, 92 000 рублей из 98 000. Было получено 20% кода и бесценный опыт).
- Отсутствие опыта работы с подрядчиками.
В нашем первом бизнесе мы были подрядчиками и почти 99% работы выполняли сами.
У меня небольшой опыт работы с подрядчиками.
Особенно учитывая, что я работал простым рабочим.
- По моему опыту был похожий случай.
Но, видимо, цена потери была невелика, и урок не был усвоен.
Мой опыт работы с подрядчиками при строительстве дома подсказывает мне, что мне сложно развить этот навык.
Хотя таких случаев не было, опыт показывает, что я слишком мягок с подрядчиками.
Это не всегда плохо; это часто дает хорошие результаты.
Но все равно.
- Работа была организована неправильно.
Я спросил ребят, получают ли они все необходимое, сам не проверял, что они получают. Оказалось, что подрядчик выполнил все необходимое для загрузки ребят. Потом ушел делать остальное и не стал выкладывать в репозитории.
Ребята не знают об общем состоянии работы.
Я не знаю, что и сколько кидают в репозитории.
В конце будет сюрприз.
- Работу, скорее всего, сначала выполнил подрядчик, а потом, когда увидел, как все настроено, понял, что не надо этого делать.
Но это догадки.
Бэкэнд. Как мы помним, мне понравился формат работы с подрядчиком.
И не забывайте, что на данный момент я еще не получил вышеуказанного опыта.
Потоки идут параллельно.
Очередное объявление на Хабре — фриланс.
Много ответов.
Два интервью.
С первым полетом по финансовой части.
Второе было интереснее.
Кандидат задал много вопросов.
Наводящие вопросы.
Почему это было сделано именно так? Что произойдет, если вы захотите сделать это в будущем? Что нужно, чтобы сделать это быстро? В том интервью мы узнали, что в приложении есть предметная часть.
И хорошо бы четко понимать, что это предметная часть.
И было бы неплохо вынести его отдельно от фреймворка.
И суть, и логика.
На работу он не согласился, но в конце интервью посоветовал нам прочитать книгу дяди Боба «Чистая архитектура», пообещав, что мы поймем, о чем он говорит. К сожалению, в откликах на объявление я не нашел его профиля.
Но я так благодарен, что он потратил так много времени на то, чтобы взять у нас интервью и показать нам путь.
По итогам собеседования, даже не начав читать рекомендованную книгу, стало понятно, над чем можно поработать и улучшить нашу архитектуру.
Мы решили прочитать книгу.
А потом решить, что делать дальше.
А это уже август месяц.
чистая архитектура, ддд
Читая книгу, я почувствовал, что этот вопрос поднимается снова.Что делать? Стоит ли продолжать разработку с тем, что есть, или работать с архитектурой? Я помню, как всем моим существом хотелось работать с архитектурой.
И мой разум ясно говорил: «Нурболат, какой смысл читать книги типа «Бережливый стартап», если ты не следуешь тем знаниям, которые читаешь из этих книгЭ» И он был прав.
Но я его не послушал.
Я убедил команду поработать над архитектурой.
Шаг назад на пару месяцев.
Но у нас будет лучшая архитектура.
А знания, полученные при внедрении новой архитектуры, позволят нам встречаться и решать проблемы на новом уровне.
Команда не возражала.
Правда, это означало, что весь бэкенд-код тоже придется выкинуть, весь 100%.
Ну и что, а у нас будет «Чистая архитектура»).
Читая книгу, я одновременно читал статьи на ту же тему и несколько раз сталкивался с термином ddd «Domain Driven Design».
Я тоже читал статьи об этом.
Заказал книги на ддд. Синий и красный.
Как только мы закончили читать книги «Чистая архитектура» и «Чистый код», пришли эти книги.
Мы начали их читать.
Заодно мы познакомились с понятиями cqrs, event source и изучили их тоже.
Мы обсудили то, что узнали.
Мы искали библиотеки по этим темам.
Мы познакомились с ними.
В какой-то момент мы начали писать код и придумывать, как он может выглядеть.
И тут Нурболат (я) снова все сломал.
Переход с Python, JS на TypeScript
В моей голове много мыслей на разных уровнях.На уровне руководителя компании, или на уровне Product Owner я понимал, что передо мной стоит задача насытить команду новыми разработчиками в тот период, когда стартап вступит в стадию роста.
На самом деле у меня уже давно было решение, как бы я решил этот вопрос:
О первом пункте я уже писал, поговорим о втором.
- привлечение опытных специалистов;
- самостоятельно обучать специалистов, а затем бросать их в жернова команд;
Вы уже знаете, что я хочу быть полезным для страны.
Допустим, я доверил себе миссию: «Я хочу быть полезным для своей страны и сделать ее лучше».
Была еще одна миссия: «Я хочу поднять культуру в нашем городе».
Для этого в будущем я планирую набирать людей, желающих стать программистами, и обучать их.
Моих текущих знаний уже достаточно, чтобы правильно подготовить их к разработке в командах.
Это может быть кто угодно, школьники, студенты, безработные и т. д. Что я получу? Удовлетворение:
Солидная прибыль.
- делиться знаниями;
- помогать другим людям без опыта стать специалистами;
- предоставив мне возможность устроиться на работу в один из моих стартапов (я упоминал, что у меня есть другие идеи?);
- решение кадровых вопросов в своих стартапах;
Цена: конечно, вам придется потратить время и умственные ресурсы.
Но мне почему-то кажется, что это не будет проблемой.
Так.
В одной из моих мыслей ко мне пришло осознание того, что мне нужно выбрать язык, на котором я буду учиться.
Если гипотетически представить, что придет школьник.
Тогда он сам не знает, что такое фронтенд и бэкенд. И я не знаю, какая у него предрасположенность.
Если я преподаю Python условно, то теоретически будет много бэкендеров и ноль фронтендеров.
Это уже проблема.
Затем мне нужно выучить js и давать уроки по нему.
Но серверная часть основана на.
подожди, а что, если мы переключимся на js на серверной части? А еще лучше: и интерфейс, и серверная часть перейдут на TypeScript. Потом я буду обучать студентов на этом языке.
Во время обучения студенты сами выбирают специализацию.
А команды получат готовый полуфабрикат. Эврика! Дальнейшее размышление дало следующие бонусы:
Цена:
- TypeScript — статически типизированный язык, что является явным плюсом при разработке сложных продуктов.
По крайней мере, так говорят заслуживающие доверия статьи;
- единый язык во фронтенде и бэкенде теоретически улучшит взаимодействие внутри команды.
Будет больше тем для обсуждения между интерфейсом и сервером;
- единый язык теоретически позволяет значительно снизить Bus Factor;
Хм.
- Придется снова выкидывать весь код, теперь даже во фронтенде.
В результате у нас будет ровно 0 строк кода.
И это результат работы с февраля по ноябрь;
- вам придется выучить новый язык, а у членов команды практически не было опыта работы со статически типизированным языком;
Но открывающиеся перспективы подсказали мне, что я должен сделать именно это.
Он подошел к команде и выступил, попутно объясняя причины такого решения.
Один из бэкендеров сказал, что если перейдем, то лучше будет использовать Java. Этот язык является стандартом в разработке предприятий.
Да, он был прав.
Но это решение не соответствовало моим стратегическим планам, описанным выше.
Итак, я протолкнул решение, что теперь и фронтенд, и бэкенд будут разрабатываться в ts. Поэтому мы сделали еще один шаг назад от продажи продукта.
Но правда, я утешал себя тем, что это задержит начало работы над продуктом всего на пару месяцев, а бонусы были очень жирными.
Мы начали изучать TypeScript. Бэкендеры, которые не были знакомы с JavaScript, начали учиться на нем, в том числе и я.
По мере продвижения мы исследовали инфраструктуру NestJS в серверной части.
В его документации указано, что архитектура была вдохновлена Angular. И я снова нажал на переднюю часть, чтобы переключиться на нее.
Фронтенд-разработчик воспротивился этому решению.
Но как ему конкурировать с адской смесью в виде разработчика, архитектора, владельца продукта, директора и основателя компании в одном лице.
Вот что я сказал: «Я не знаю, будет ли переход иметь реальный эффект. Но если эти два фреймворка будут иметь хотя бы частично одинаковые архитектурные решения, то таким переходом мы теоретически снизим когнитивную нагрузку на full-stack разработчиков.
Это облегчит учебу и переключение контекстов в работе в будущем».
Видишь, сколько умных слов иногда нужно сначала выучить, а потом пересказать, чтобы все было по-твоему.
Короче говоря, фронтенд-разработчик согласился и начал изучать Angular. Всю эту подготовку и обучение мы проделали аккурат перед Новым годом, так уж получилось.
Мы работаем над архитектурой
С начала 2021 года мы начали потихоньку разбираться и развивать нашу архитектуру, согласно тому, чему научились.Это действо, в виде сваривания в одном бульоне таких ингредиентов, как чистая архитектура, ddd, источник событий, cqrs и всего, что им сопутствует, оказалось не такой уж простой задачей.
Особенно если учесть, что сложный рецепт приготовления читали четыре неокрепших ума, и каждый имел свое представление о том, как приготовить это блюдо.
И тут добавляется, что огонь, на котором мы готовим, был не простой газовой горелкой как раньше (python+js), а открытым огнем, с которым надо уметь работать (тс).
Начиная со следующих постов, я поделюсь тем, что произошло.
Я прошу читателей быть снисходительными, если вы почувствуете запах полученного бульона.
Я думал, что разработка архитектуры займет два-три месяца.
Но я как всегда ошибся в своих предположениях.
Развитие архитектуры продолжается и сегодня.
Да, мы пробовали и пытаемся протестировать параллельную архитектуру на реальных примерах использования.
Но мы часто переосмысливаем то, что получили, и делаем рефакторинг.
Но кажется, свет в конце туннеля уже виден, хотя работы еще много.
Я уверен, что опытные программисты за несколько недель сделают то, что мы делаем за семь месяцев.
Но до этого нам еще далеко).
Сейчас, конечно, стратегия развития продукта изменилась.
Я не собираюсь реализовывать ядро приложения, как в начале нашего пути.
Вместо этого мы будем внедрять функции по одной, позволяя пользователям опробовать их и собирая отзывы.
Мое видение того, каким будет приложение в будущем, не изменилось.
Но мы подойдем к этому эмпирически и итеративно.
Что это нам дало и чего нам это стоило?
Продукт
Дало: Продукт получил более осознанную и опытную команду разработчиков.В будущем это позволит достигать продуктовых целей гораздо быстрее и лучше.
Стоимость: продукт многим пожертвовал.
- Опыт, который можно получить, внедряя инструменты и анализируя, насколько они востребованы и движется ли продукт в правильном направлении.
- Рынок, потенциальные клиенты, возможность начать зарабатывать.
Продукту еще предстоит пройти этот путь.
- Исчерпали бюджет, поставив под угрозу весь стартап.
Команда разработчиков
Дало: Команда разработчиков получила очень хорошие бонусы:
- улучшилась общая экспертиза команды в хард-скиллах, что было проверено в реальных условиях при разработке архитектуры;
- переход на общий язык в команде обеспечивает лучшую сплоченность и гибкость внутри команды;
- существуют, по крайней мере, на зачаточном этапе, попытки перейти к разработке процессов;
- Улучшилось внутрикомандное взаимодействие.
Нам нужно было как-то найти общий язык, договориться о том, как решать спорные вопросы и т. д. Если развивать тему, то в начале работы должности архитектора не было.
Предполагалось, что решения будут приниматься коллективно, иногда мы даже голосовали.
Решения были настолько разными, что кодовая база напоминала плохой салат, и то, что получилось, мне очень не понравилось.
Попытки прийти к чему-то общему путем обсуждения не привели к результатам.
В конце концов я принял решение, что теперь я архитектор, и окончательное решение за мной.
Задача разработчика теперь — объяснить архитектору, почему его решение лучше.
Если ему это удастся, то он примет это.
Если нет, то идите и подумайте, что и как объяснить архитектору, чтобы он понял, что он не прав, или принять вариант архитектора.
- Оно того стоило: Но это ничего не стоило, команда разработчиков была в шоколаде.
Но теперь ему нужно вернуть продукт.
Разработчику
Дало: Если команда разработчиков в шоколаде, то разработчик как основная единица команды плавает в золоте:Оно того стоило: чем-то все равно пришлось пожертвовать.
- Я хорошо поработал над повышением уровня своих профессиональных навыков;
- Я хорошо поработал над улучшением своих мягких навыков;
- в результате его будут лучше ценить на рынке труда;
- Мне приходилось много преподавать и учиться;
- часто идут на компромисс с теми, кто склонен думать и вести себя неправильно;
Полученные результаты
Темп работы
Когда мы только начинали, в феврале 2020 года, у нас был шестидневный график работы.В таком режиме мы работали четыре месяца.
В конце этого периода я почувствовал, что если буду продолжать так работать, это грозит выгоранием.
И мы замедлили ход. Мы перешли на пятидневную рабочую неделю и достаточно гибкий график дня.
И мы работаем в таком темпе уже год, и все хорошо.
Итак, дедлайны и переутомление – это зло, которое в конечном итоге не приведет к добру.
Правда в том, что вы сами это знаете.
Независимость
Я вижу комментарии о том, что на этапе mvp нужно сконцентрироваться на получении ответов на вопрос: «Есть ли у продукта потенциал на рынкеЭ» И вы правы, это правда.Я приведу только свои аргументы.
Можно считать это глупостью, самоуверенностью и другими эпитетами.
Но я уверен, что наш продукт нужен рынку.
Меня беспокоит вопрос: «Смогу ли я продать свое видение людям, от которых будет зависеть жизнь продуктаЭ» И это бросает вызов моим навыкам как провидца и владельца продукта.
Скажем так, у меня это не получится.
Но у меня много идей для других стартапов.
И все эти идеи натолкнутся на одну проблему – проблему развития.
Другими словами, это означает, что мои идеи зависят от способности команды разработчиков их реализовать.
Год назад команде понадобился кто-то со стороны, чтобы помочь нам в разработке.
Мы попробовали этот путь, он мне не понравился из-за неопределенности.
Если бы я имел в виду специалиста, которому можно было бы доверить должность технического директора, я бы пригласил его в команду и доверился ему.
Но такого человека не было, и было непонятно, когда мы сможем его найти и сможем ли найти.
Последующее принятое решение и весь путь, который мы прошли, в принципе убрали все эти зависимости.
Теперь наша команда независима, потому что все компетенции внутри команды.
Это не значит, что мы теперь профессионалы и технический директор нам не нужен.
Это значит, что мы можем продолжать работать над продуктом сами, одновременно повышая свою компетенцию.
И те, кто пришел
-
Обслуживание Компьютеров
19 Oct, 24 -
Приглашаем Вас На Geekfest Night 26 Июля.
19 Oct, 24 -
Окамл. Типы Данных
19 Oct, 24 -
Zoho Creator 3 И Торговая Площадка
19 Oct, 24
