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

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

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

Итак, сама история. (снимаю улыбку и пытаюсь быть серьезным).
Суть проблемы в потере доверия со стороны стейкхолдеров, в первую очередь представителей SACSA. Затянувшееся развитие и задержки вызвали это недоверие.
Подытожим, какие проблемы выявились в ходе анализа:

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

Когда ядро ​​нашей системы было готово, мы столкнулись с другой проблемой — сложным интерфейсом для конечного пользователя. В таких случаях говорят «Интерфейс не интуитивно понятен».
Как видите, наболевших моментов очень много. Каждый из них вносил свою лепту в срыв сроков, и все эти проблемы можно было охватить одним утверждением: «команда не имеет должного практического опыта в реализации такой большой и сложной системы». С другой стороны, эти ошибки и недочеты могли бы помочь в приобретении практического опыта, верно?
При разработке MVP (Minimum Viable Product) мы не ставили цель иметь идеальную систему — это стандартная практика для MVP. . Мы разработали ядро, которое работало и годилось для расширения его функциональности (в рамках целей MVP). Мы могли бы продолжать работать с текущей системой. В тот раз внутри меня начали бороться два намерения.
С одной стороны, я хотел продолжить работу с имеющимся кодом. Это позволит быстрее достигать поставленных целей и внедрять новые функциональные возможности. Но у нас было понимание, что поддерживать высокий темп работы будет сложно.
С другой стороны, хотелось отступить и решить некоторые вопросы. Это означало приостановить процесс достижения целей продукта. Я не мог перестать спрашивать себя, а что, если начать разработку продукта с нуля.
Как команда мы решили, что изменить в текущем состоянии продукта, чтобы продолжить рост. В ходе обсуждения возникла идея нанять опытного разработчика с почасовой оплатой. Он/она может помочь, когда дело доходит до вопросов, на которые трудно ответить. Позже эта идея была расширена за счет технического директора с частичной занятостью. Да, это была неплохая идея потренироваться.

Было принято решение поискать этого специалиста на Хабре — площадке, где тусуются айтишники и прочие гики. После некоторого изучения темы выложил вакансию на Хабр-карьера с указанием требований. 4 кандидата выразили заинтересованность. 3 из них связались с нами — мы провели интервью по скайпу. Наш выбор пал на самого дорогого кандидата. По результатам собеседования он был целеустремленным и вызывал доверие своей квалификацией. Этот кандидат занимал должность технического директора. Вся власть в разработке перешла к нему.
Кандидат редко был доступен для контакта: иногда выход на связь с ним через мессенджера, вызывавший ожидание, занимал несколько дней. Наши ожидания не оправдались. Тогда мы решили поискать другого кандидата. Нашли, но опять возникла проблема с подключением — не удалось пройти этап предварительного согласования, не говоря уже о сотрудничестве. Вот результаты наших отчаянных попыток нанять опытного специалиста:

  • В ходе собеседования можно было найти специалистов, внушающих доверие;
  • Кандидаты не чувствовали ответственности и не стремились получить результат для стартапа;
  • Если этот кандидат занимает должность технического директора, то от него зависит 100% работы. 4 разработчика сидят целыми днями, ничего не делая и одно и то же день за днем;
  • Были кандидаты, выразившие искренний интерес к нашему проекту и желание работать, но не прошедшие предварительный отбор из-за недостаточного, на наш взгляд, опыта;
  • Потерял больше месяца и добился чуть больше, чем ничего;
  • Скорее всего, мы сможем найти такого кандидата, отвечающего нашим требованиям по опыту, который будет заниматься реализацией продуктовых задач. Но время на хедхантинг и вероятность такого варианта пугали;
  • В ходе интервью мы узнали много нового и полезного для проекта. Таким образом, интервью можно рассматривать как источник знаний.
  • разработать фронтенд-ядро;

Пусть и без результата, но с новыми знаниями и опытом, мы решили изменить нашу стратегию. Мы договорились сфокусироваться на самых болезненных моментах нашей работы: на пользовательском интерфейсе и параллельно работать над фронтенд-ядром (фронтенд — это программа на вашем ПК или другими словами то, что вы могли видеть). Для этого нам нужно было нанять опытного фронтенд-разработчика и отдать эту часть работы на аутсорсинг. Задачи для кандидата:

  • улучшить пользовательский интерфейс;
  • разрабатывать ядро ​​вместе с нашими разработчиками, делясь опытом и знаниями;
  • по окончании работы наши разработчики должны знать, как действовать дальше.
  • ядро не должно быть напрямую связано с текущим дизайном и пользовательским интерфейсом;

Заказ разместил на Хабр-фрилансе. Мы отобрали 5 кандидатов и провели интервью с командой. Выбор был непростым — мы обратились к подрядчику, который неплохо оценил наше текущее состояние и указал, над чем нужно работать. Цель была поставлена ​​— разработка ядра. Бюджет был определен — 40 000 рублей (≈570$). Срок — 10 дней. Продолжать! С самого начала ход работ был ощутим: подрядчик определил задачи, над которыми нужно работать, и степень участия наших разработчиков. После начала работ мы дополнили требования новыми пунктами:

  • ядро должно поддерживать продукт и мобильную версию приложения.
  • Оплачено 94% работ — 92 000 рублей (≈1315$) из 98 000 рублей (≈1400$).

Установив новые требования, мы задумались, как это будет реализовано. Подрядчик дал структурированные и четкие ответы. Но это привело к увеличению стоимости проекта до 60 000 рублей (≈860$). Мне очень понравился такой формат работы, и мы решили использовать тот же подход для бэкенда (бэкэнд — это программа, работающая на сервере, откуда скачиваются данные). Следует отметить, что наша дальнейшая работа шла по двум параллельным независимым направлениям. Чтобы узнать, как продвигалась вторая оптимизация, перейдите в раздел «Бэкенд-линия» этого поста.

Бэкэнд линия.

Немного, дебет и кредит не в нашу пользу.
Опыт и знания, которые мы получили:

  • 20% кода получено, а важная часть 0%.
  • необходимо установить техническое задание или хотя бы разделить весь объем на этапы и зафиксировать письменно. Привязать сроки и платежи к этим этапам. Такой способ работы позволит контролировать процесс разработки;

Все нормальные люди следуют вышеуказанным принципам, но это не про нас :). Потратив столько денег и времени, мы получили опыт и новые знания в архитектуре и поэтому решили развивать фронтенд-ядро самостоятельно.

  • необходимо структурировать работу с подрядчиком прозрачно для всей команды, включая финансовую сторону. Персонал мы подбирали совместно с командой, основные требования к задаче также давались совместно с командой, а финансовая часть перешла в личную переписку между мной и исполнителем. Командный чат с подрядчиком поддерживался только по технической части. Я не знал, какой код передал подрядчик. Команда не знала, сколько мы заплатили за работу. Следовательно, мы не могли знать, что код, который мы получили в репозитории, и уплаченные деньги не равны;
  • вместе с командой должны быть установлены дополнительные требования, чтобы все были в курсе соглашений. Условия должны быть зафиксированы в письменной форме с детализацией финансовой части проекта и сроков;
  • что было в данном случае положительного — фронтенд-разработчики получили много новых знаний в области архитектуры приложений. Выяснилось большинство проблем, и хотя у нас не было полной картины будущего ядра, но основные контуры стали ясны для наших фронтенд-специалистов.
  • Мы получим практический опыт реализации теоретических знаний, полученных из прочитанных книг;

Здесь вы найдете повествование о событиях в бэкенде, которые происходили параллельно с фронтендом. Для бэкенда мы также решили привлечь разработчика со стороны. Нам нужен был архитектор, помогающий нам в разработке архитектуры. Основной набор функций мы хотели разработать собственными силами, а архитектор должен разработать только фреймворк и дать нам задачи и, возможно, разработать самое ответственное.
Разместили еще одну вакансию на Хабр-фрилансе — кандидатов много выразил заинтересованность. Я отобрал двоих из них с немалым опытом работы в крупных компаниях. Я поболтал с одним из них, и он оказался неподходящим с финансовой точки зрения. Мы провели собеседование со вторым кандидатом. Снова неудача. Тем не менее, это было интересное интервью — этот кандидат задал много наводящих вопросов. Наводящие на размышления вопросы, дающие правильное направление нашим собственным идеям. В конце интервью он предложил прочитать книгу Роберта Мартина «Чистая архитектура».
Не читая этой книги, но в результате этого интервью мы уже увидели, что мы можем проработать и улучшить архитектуру нашего приложения. . По сути, новая архитектура сведет на нет всю нашу работу, проделанную с февраля. Это просто означало, что мы должны выбросить 100% доступного кода. Конечно, какую-то часть можно было бы использовать, но эта часть незначительна. Реструктуризация архитектуры была значительной.
Было принято решение начать разработку продукта на основе новой архитектуры. Почему мы приняли такое решение? Проведем анализ:
Преимущества разработки новой архитектуры:

ошибки в дизайне архитектуры приложения;

Недостатки разработки новой архитектуры:

  • Полученный практический опыт внедрения новой архитектуры откроет двери для новых знаний и опыта в будущем;
  • Мы добьемся стабильности в сроках роста продукта. Основная цель «правильной» архитектуры — поддержание постоянной скорости процесса разработки;
  • Наша команда значительно улучшит свои профессиональные знания и опыт, что, в свою очередь, станет хорошей базой для достижения долгосрочных стратегических целей.
  • Нет никакой гарантии, что новая архитектура будет успешной. Но уже сейчас очевидно, что эта архитектура намного лучше текущей;

Преимущества и недостатки равны, особенно с учетом последнего отрицательного момента. Но мой перфекционизм делает выбор очевидным — будем разрабатывать новую архитектуру. Чтобы добавить немного объективности, позвольте мне поделиться одной идеей, которая наводит меня на мысль:
Мы работаем над цифровизацией в строительной отрасли. Всем понятно, что эта сфера сложная и масштабная. Когда мы приступили к работе над этим продуктом, мы поняли серьезность всей задачи по сравнению с разработкой страницы сайта или большого интернет-магазина. Именно масштаб задачи определяет серьезность подхода к вопросам архитектуры. У меня есть абсолютная уверенность, что все ресурсы и время для новой архитектуры разумны. Уверен, что при других обстоятельствах я вполне объективно мог бы принять другое решение, например заняться оптимизацией текущего решения.
Вовлечь команду в разработку нового ядра было несложно — команда сочла это решение разумным и согласился без вопросов. В итоге в середине сентября 2020 мы уже месяц работаем над новой архитектурой.
Эту историю можно было бы анализировать с разных сторон и скорее всего я еще вернусь к этому этапу развития нашего стартапа в будущие посты. Например, для меня как для основателя стартапа этот этап отмечен рывком личностного роста.
На этом я заканчиваю обзор действий, которые мы предприняли для решения проблем развития. При написании этого поста я балансировал между двумя крайностями: не делать рассказ лишним и в то же время дать вам полную информацию о том, что произошло со стартапом и командой и что повлияло на наши решения. Надеюсь, мне это хоть немного удалось.
«Следующие обзоры» на эту тему будут в режиме реального времени.

  • Есть вероятность, что в будущем, когда мы пройдем стадию разработки MVP и приступим к основному функционалу, архитектура снова изменится и все наши усилия окажутся напрасными;
  • Добровольный возврат к нулям приведет к большой задержке с целевыми показателями продукта;
  • Вероятно, ресурсов для достижения целей MVP не хватит.
  • Через неделю столкнулся с проблемой — мои банковские счета оказались заблокированы налоговой инспекцией.
    Строю дом и весной привез из РФ стройматериалы для шумоизоляции. В налоговой инспекции думали, что я купил эти материалы для дальнейшей перепродажи, хотя стоимость товара была смехотворной для коммерческих целей, а цель перевозки была четко указана при переходе через границу. Очевидно, мое индивидуальное предприятие сбило с толку налоговую инспекцию, поэтому они решили провести расследование и получить доказательства личного использования или иным образом взыскать соответствующие налоговые платежи. Приходилось бегать, собирать документы, фотографировать свой дом, чтобы доказать, что он действительно строился и из этих материалов был построен этот дом. На это ушло более или менее 10 дней.
    После того, как мои счета были заморожены, я связался с подрядчиком, чтобы объяснить ситуацию. Было решено приостановить работы до решения проблем. В это время появилось непонимание. Исполнитель во время нашего последнего разговора имел в виду, что дополнительный функционал будет стоить дополнительно 60 000 рублей, я так понял, что 60 000 рублей — это общая сумма. Итого нам это обошлось в 98 000 рублей (≈1400$). Это огорчило — согласие с произвольным толкованием было очевидным. По устному отчету подрядчика до завершения работ оставалось 2 дня. Приняли решение приостановить работы из-за финансовой задолженности.
    После урегулирования налоговых вопросов мы связались с подрядчиком и погасили задолженность. Договорились продолжить на следующий день. А потом все изменилось: подрядчик «замолчал», когда в конце концов его провели, дал обещания, но снова пропал. Во время очередного звонка подрядчик с жалобой на трудности попросил предоплату. Сумма аванса почти закрыла сделку — 15% из 20%, оставшихся к оплате. После недолгих размышлений с полным пониманием всех рисков я перевел деньги. После этого подрядчик появлялся пару раз, затем исчезал. Прошло примерно 10 дней, как я решил налоговые вопросы.
    Потом загорелся свет — меня обманули. Проснувшись, я спросил фронтенд-специалистов о проделанной работе. Когда в репозитории оказалось 20%, я был в шоке.
    Подрядчик разработал код с привязкой к ядру (периферийному коду) — по нему наши ребята начали разрабатывать элементы интерфейса. Далее подрядчик занимался активной зоной в одиночку. Выяснилось, что код не сохранился в репозитории. Скорее всего потому, что код был неполным и все еще находился в разработке. Вот почему у нас получилось 80% кода для периферии и 0% для ядра, всего 20%. Я был очень разочарован, а начало было таким хорошим (ну, в моем воображаемом мире).
    Ох, какой же я неудачник! Почему я такой наивный? Когда я мог контролировать работу? Это была моя первая болезненная реакция, за которой последовал тщательный анализ.
    Итак, начнем с результатов:

Решение проблем, связанных с развитием запуска строительного