Говорит: Нурболат Амангалиев
В предыдущем посте писали, как заработали себе проблем, теперь будем писать, как пытаемся решить эти проблемы. Сначала разберём проблемы процесса разработки и решения архитектурных вопросов.
Дисклеймер:
Все описываемые события в данном посте являются реальными и были пережиты нашей командой. Любое совпадение с похожими событиями других команд считайте случайностью:).
Ну, а если серьезнее, то суть данного дисклеймера в том, что далее будет много текста в формате рассказа о том, как мы пытаемся решить наши проблемы и стать более профессиональными разработчиками. В следующем абзаце приведу краткую суть всего поста, а вы уж сами решите стоит ли вам потратить 20 минут драгоценного времени вашей жизни, чтобы прочитать сказ о наших приключениях.
В общем чтобы решить наши проблемы, мы решили что самый простой и быстрый путь это привлечь опытного специалиста на позицию технического директора. Не получилось. Потом решили отдать разработку ядра на оутсорс, оказалось что мы полные профаны (лузеры, лохи, …) и в этом деле. Но в тоже время мы узнали что можно сильно улучшить наш продукт. Все таки наши действия кроме болезненных опытов давали и новые знания. А если можно улучшить, то почему бы и не улучшить подумали мы, и начали работать над новой архитектурой. В принципе все, думаю дальше можно не читать.
Собственно рассказ. (Так, убираю улыбку с лица и настраиваюсь на серьезный лад).
Суть проблемы в потере доверия со стороны Заинтересованных лиц, в первую очередь работников Государственного архитектурно-строительного контроля. Недоверие появилось из-за долгой разработки и срывов сроков.
Итак, какие проблемы обнажились при анализе:
- ошибки проектирования архитектуры приложения;
- неэффективная постановка процесса разработки;
- начало работы с новой технологией, с которой команда не имела опыта работы;
- излишнее усложнение кода, в попытке предусмотреть лёгкое масштабирование в другие приложения.
Когда ядро нашей системы было готово, выявилась следующая проблема — сложный интерфейс для конечного пользователя. В таких случаях говорят: «Интерфейс не является интуитивно понятным».
Как видно, проблем много. Каждая из них внесла свой вклад в срыв сроков, и эти проблемы можно объединить под одним предложением: «Команда не имеет хороший практический опыт реализации таких больших и сложных систем». С другой стороны, через ошибки мы приобретаем практический опыт, не так ли?
При разработке MVP (минимальный жизнеспособный продукт) мы и не ставили цель разработать идеальную систему — это нормальная практика для MVP. Мы разработали ядро, которое работало, которое поддавалось расширению функциональности (в рамках достижения целей MVP). Можно было продолжать работать с текущей системой. Внутри меня начали бороться два желания.
С одной стороны, я хотел продолжить разработку на основе существующего кода. Это позволяло бы нам быстрее достигать поставленных целей и внедрять новый функционал. Но было понимание, что работать, сохраняя высокий темп, будет трудно.
С другой стороны, хотелось сделать шаг назад и решить возникшие проблемы. То есть, поставить паузу на достижении целей продукта. Я себя спрашивал: «А не начать ли разработку продукта с нуля?».
Командно решали, что необходимо изменить в текущем состоянии проекта, чтобы продолжить развиваться. В ходе обсуждения родилась мысль о найме опытного разработчика на почасовую оплату. К нему можно было бы обращаться с вопросами, на которые сложно найти ответ. А позже расширили мысль, можно будет “поставить” кандидата на роль технического директора с графиком “неполный рабочий день”. Да, это была определённо хорошая мысль — взяли это в работу.
Искать специалиста решили на Хабре — площадке, где «тусуются» it-шники и не только. Поизучав тему, выложил вакансию на Хабр-карьере описав требования. Откликнулись четыре кандидата. Трое из них вышли на связь — вместе с командой провели интервью через Скайп. Выбор пал на самого дорогого из кандидатов. По результатам интервью он наиболее подходил для решения наших проблем в разработке и вызывал доверие своей компетентностью. Кандидат фактически встал на должность технического директора. Власть по разработке полностью перешла к нему.
Кандидат выходил на связь редко: ребята иногда по нескольку дней не могли «достучаться» по мессенджеру и работа простаивала. Наша надежда на решение проблем не оправдалась. Тогда решили поискать другого кандидата. Нашли, но и там была проблема со связью — мы не смогли пройти даже стадию заключения предварительных договоренностей, не говоря о начале совместной работы. Итого, по результатам попыток привлечения опытных специалистов имеем следующее:
- На предложение откликается довольно много людей;
- Можно найти специалистов, которые в процессе интервью вызывают доверие;
- Кандидаты не чувствовали ответственности, не были нацелены на получение результатов для стартапа;
- Если ставить на позицию технического директора, то наша работа будет на 100% зависеть от технического директора. Четыре разработчика сидят и целый день практически ничего ценного не создают, и так день за днем;
- Были кандидаты, которые искренне заинтересовались нашим проектом в процессе интервью и показывали желание поработать, но они отсеивались из-за недостаточного на наш взгляд опыта;
- Потеряли больше месяца и достигли чуть большего, чем ничего;
- Скорее всего, можно найти такого кандидата, который устроит по опыту и вольётся в реализацию целей продукта. Но пугало количество времени, которое может уйти на поиск и вероятность такого варианта событий;
- В процессе интервью с кандидатами узнали много нового и полезного для проекта. Можно считать эти интервью новым источником знаний;
Не получив результата, но забрав знания и опыт, мы решили поменять стратегию. С командой пришли к решению, что надо сконцентрироваться на самых больных участках нашей работы. Решили сконцентрироваться на пользовательском интерфейсе, а параллельно заняться ядром фронтэнда (фронтэнд — программа которая работает у вас в компьютере, или другими словами то что вы видите). Для этого нанять опытного фронтэнд-разработчика и отдать работу на аутсорс, т.е подряд. Задачи, которые кандидат должен был решить:
- разработать ядро фронтэнда;
- улучшить пользовательский интерфейс;
- разрабатывать ядро вместе с нашими разработчиками передавая опыт и знания;
- в конце работы, наши разработчики должны уметь продолжить работу сами.
Заказ оформили на Хабр-фриланс. Отобрали пять кандидатов. Провели вместе с командой собеседования. Выбор был сложным, остановились на подрядчике, который дал хороший обзор нашего текущего состояния и указал над чем надо работать. Определили цели — разработка ядра. Определились с бюджетом — 40 000 рублей РФ. Определились со сроками — 10 дней. Погнали. С самого начала работа шла быстро: подрядчик определил задачи, которыми будет заниматься и как будет вовлекать наших разработчиков. После начала работ мы дополнили требования новыми пунктами:
- ядро не должно быть явно привязано к текущему дизайну и пользовательскому интерфейсу;
- ядро должно поддерживать разработку и подключение мобильной версии приложения.
Обозначив новые требования, поинтересовались — как это будет реализовываться? Подрядчик давал хорошие и понятные ответы — правда это привело к удорожанию разработки до 60 000 рублей. Мне сильно понравился такой формат работы. Решили повторить такой же формат работы и в бэкэнде (бэкэнд — программа которая работает на сервере, откуда грузятся данные). Здесь хотелось бы отметить, что далее наша работа пошла в двух параллельных независимых потоках. Как протекал второй поток можете узнать в разделе “Поток бэкэнда” данного поста.
Продолжим с фронтендом
Через недельку у меня образовались проблемы — оказалось, налоговая служба арестовала мои счета.
Сейчас я строю дом: весной провозил с Российской Федерации стройматериалы для шумоизоляции. Налоговая решила, что я провозил их для перепродажи, хотя стоимость товаров была смешной для коммерческих целей и при пересечении границы указывалась цель перевозки. Вероятно, сыграло роль наличие ИП — налоговая решила, что тут надо разобраться и получить подтверждение личного использования или забрать в бюджет причитающиеся налоги. Пришлось бегать, собирать бумаги, фоткать дом, что строительство действительно ведется, а материалы использованы в этой стройке. Заняло дней десять, может и побольше.
Как только были арестованы счета, я связался с подрядчиком и объяснил ситуацию. Решили приостановить работы, пока возникшие проблемы на решатся. Тут выяснилось недопонимание. Подрядчик в прошлом нашем разговоре имел в виду, что дополнительный функционал прибавит к стандартной оплате 60 000 рублей. Я же рассчитывал, что 60 000 рублей — это общая стоимость работы. По итогу, мы оказались должны 98 000 рублей. Неприятно — налицо создание договоренностей с двойным толкованием. По устному отчёту от исполнителя — работы осталось на два дня. Образовалась финансовая задолженность и мы решили приостановить работу.
Когда вопросы в налоговой решились — связались с подрядчиком и погасили долг. Договорились со следующего дня продолжить. И тут всё поменялось: подрядчик не выходил на связь, а когда выходил, то давал обещания, но опять исчезал. При очередном разговоре он, ссылаясь на сложности, попросил аванс. Размер аванса практически закрывал сделку — это были 15% из оставшихся 20% к выплате. Немного подумав, понимая риск на который иду, я всё таки перевел деньги. После этого подрядчик пару раз выходил на связь. А потом пропал полностью. Всё это заняло примерно десять дней после того, как я решил вопросы с налоговой.
Пришло понимание, что меня обманули. В ходе осознания, спросил у фронтендщик, сколько работы было сделано. Когда сказали, что в репозитории около 20% от общего объема — я был в шоке.
Подрядчик в начале разработал код, который обращается к ядру (периферийный код) — с ним наши ребята начали разрабатывать элементы интерфейса. Далее он единолично занимался разработкой ядра. Оказалось, что код не закидывался на репозитории. Скорее всего, потому что код не был готов и был в процессе разработки. Поэтому в конце оказалось, что по периферии имеем 80% кода, по ядру 0% кода — в общем 20% кода. М-да, очень обидно, однако. А так хорошо всё начиналось (конечно же в моем воображаемом мире:).
Какой же я лох! Почему я так наивен? Когда я научусь контролировать работы? Это первая болезненная реакция. После этого, анализ.
Начнём с результатов:
- Оплачено 94% работ - 92 000 рублей из 98 000.
- Получено 20% кода, от запланированного, притом самого важного 0%.
Негусто, явно дебит с кредитом не в нашу пользу.
Опыт и знания, которые получили:
- необходимо составлять ТЗ или хотя бы разделять всю работу на этапы и письменно закреплять. К этим этапам привязывать сроки и размер оплаты. Работая так сможем контролировать процесс разработки;
- нужно выстраивать работу с подрядчиком прозрачно для всей команды, включая финансовую сторону. Мы выбирали сотрудников командой, общие параметры задания тоже выдавали командой, но отношения по финансовой части перешли в личную переписку между подрядчиком и мной. Групповая переписка между подрядчиком и командой велась только по технической части. Я не знал, какой код кандидат закидывает нам. Команда не знала, сколько мы платим за работу. Соответственно, мы не могли знать, что код, который получили в репозитории и количество денег, которое было оплачено, не соответствуют друг другу;
- дополнительные требования нужно дополнять вместе с командой, чтобы все были в курсе договорённостей. Закреплять условия нужно письменно, с уточнением финансовой части проекта и сроков;
- из положительного, фронтэнд-разработчики получили много новых знаний по архитектуре приложения. Многие проблемы обнажились и хотя мы не получили исчерпывающей картины будущего ядра, основные контуры для наших фронтэндщиков стали понятны;
Все нормальные люди работают по принципам изложенным выше, но только не мы:). Потратив такие деньги, потратив столько времени и получив такой опыт, а также получив новые знания по архитектуре, мы решили дальше разрабатывать ядро фронтэнда сами.
Поток бэкэнда.
Далее будут описываться действия которые происходили в потоке бэкэнда параллельно с фронтэндом. Бэкенде также мы решили привлечь разработчика со стороны. Нужен архитектор, который будет нам помогать разрабатывать архитектуру. Основной функционал мы хотели реализовать сами, архитектор должен был только разрабатывать архитектуру и давать нам задания, возможно будет разрабатывать самые критичные части.
В Хабр-фрилансе дали ещё одно объявление — откликнулось также много кандидатов. Отобрал двух из них, с хорошим опытом работы в крупных компаниях. С одним провёл переписку по мессенджеру и стало понятно, что кандидат не подходит по финансовой стороне предложения. Провели интервью со вторым кандидатом. Также неудача. Но интервью с ним получилось интересным: кандидат задавал много направляющих вопросов. Вопросы, которые давали пищу для ума и направляли наши мысли в нужном направлении. В конце разговора посоветовал почитать книгу «Чистая архитектура» Роберта Мартина.
Даже не начав читать данную книгу по результатам данного интервью было видно, где можно проработать и улучшить архитектуру нашего приложения. Правда, реализация новой архитектуры перечёркивает всю нашу работу, которая была проделана с февраля. Это означало, что придётся выкинуть 100% существующего кода. Конечно, что-то оттуда будет использоваться, но оно ничтожно мало. Настолько серьезно перестраивалась архитектура.
Было принято решение начать разработку продукта по новой архитектуре. Почему же было принято такое решение? Давайте проведём анализ:
Плюсы, если начнем разработку новой архитектуры:
- Разрабатывая новую архитектуру получим опыт практической реализации теоретических знаний, которые мы получаем из приобретенных книг.
- Полученный практический опыт по реализации новой архитектуры откроет двери для других знаний и опыта в будущем.
- Произойдет стабилизация сроков развития продукта. Ведь основная цель «правильной» архитектуры — это поддержание постоянной скорости разработки.
- Наша команда сильно улучшит профессиональные знания и опыт, это в свою очередь станет хорошим фундаментом для достижений стратегических целей в долгосрочной перспективе.
Минусы, если начнем разработку новой архитектуры:
- Нет гарантии, что построенная архитектура будет удачной. Но понятно, что эта архитектура будет на порядок лучше, чем текущая.
- Есть вероятность, что в будущем когда мы пройдем этап разработки MVP и начнем работу над основным функционалом, архитектура поменяется еще раз, и потраченные ресурсы не оправдают полученных выгод;
- Сильно задержим достижение целей продукта, добровольно возвращаясь на нулевую позицию.
- Возможно, не хватит финансовых ресурсов на достижение целей MVP.
И плюсы, и минусы равнозначные — особенно с учетом последнего отрицательного пункта. Но мой перфекционизм делает выбор очевидным — будем разрабатывать новую архитектуру. Чтобы добавить толику объективности приведу основную мысль которая движет мной:
Мы работаем над цифровизацией стрительной отрасли. Всем понятно, что данная отрасль довольно сложна и масштабна. Начиная работать над данным продуктом понимали что перед нами стоит задача гораздо серьезнее чем разработка странички сайта или крупного интернет магазина. Именно масштабность решаемой задачи и задает серьезность к подходу архитектурных вопросов. У меня есть полная уверенность в обоснованности траты ресурсов и времени для разработки новой архитектуры. Уверен, что при других обстоятельствах, мог довольно объективно принять и другое решение, например поработать над оптимизацией текущего решения.
Вовлечь команду в разработку нового ядра было несложно — команда сама видела обоснованность такого решения и согласилась с предложением без вопросов. По итогу, в середине сентября 2020 года, уже в течение месяца работаем над новой архитектурой.
Эту историю можно исследовать с разных сторон, наверняка в будущих постах буду возвращаться к этому этапу развития стартапа. Например, на данном этапе у меня как основателя стартапа, происходили скачки личностного роста.
На этом обзор того, что мы делали для решения проблем разработки, заканчивается. Я в написании поста разрывался между двумя крайностями, не растягивать свою историю лишними подробностями и в то же время дать информацию что и как происходило с стартапом и командой и что влияло на наши решения. Надеюсь, хоть сколько нибудь это мне удалось.
Дальше все обзоры по данной тематике будут идти в реальном времени.