Говорит: Нурболат Амангалиев
В предыдущих постах мы сообщали, что хотим в блоге рассказывать обо всем, что происходит со стартапом, командой, людьми. Но если взять и начать писать о текущих событиях, то посты будут оторваны от истории стартапа. В этом посте начнём описывать события с того момента, когда мы начали фактически работать над проектом buildozer. А посты, которые относятся к периоду до февраля 2020 года, будут отмечаться тегом «Моменты из истории».
В феврале 2020 года мы провели презентацию перед представителями управления цифровизации по ЗКО и Государственного архитектурно-строительный контроля по ЗКО (далее ГАСК. ГАСК — государственный орган выполняющей функции контроля в сфере строительства). В презентации мы представили основную идею нашего стартапа buildozer. С управлением цифровизации мы и ранее сотрудничали и получали от них поддержку. Отдельно хотелось бы отметить с благодарностью, что ГАСК в лице руководителя ухватил суть и ценность нашей системы озвученной в ходе презентации. Мы договорились встретиться еще раз и обсудить детали сотрудничества. В ходе дальнейшего сотрудничества, ГАСК оказал нам полную поддержку и решил следующие вопросы:
- выбрал одно строительство находящееся на начальном этапе строительства;
- организовала совместное собрание с представителями компании вовлеченных в это строительство (подрядчик, проектная компания, технический надзор);
- попросил представителей компании вовлеченных в это строительство помочь нам в разработке нашей системы;
Еще до данной встречи мы обозначили, что перед тем как начать внедрение функциональности системы, нам необходимо разработать ядро системы. Руководитель ГАСК-а спросил хватит ли нам месяца, и я поддавшись искушению и не желая отказывать, согласился что месяца хватит. У меня были сомнения что успеем за месяц, мне хотелось взять два месяца. Но страх, что могу показаться некомпетентным перед руководителем ГАСК-а перевесило чашу весов к согласию (никогда не делайте так).
После разработки ядра системы, мы вместе с работниками ГАСК и другими заинтересованными лицами в сфере строительства, должны были начать дополнять ядро системы различным функционалом. Направление развития сервиса определяли бы наше видение продукта , а также заинтересованные лица — работники компаний строительной сферы. Среди них были сотрудники ГАСК, заказчик строительства, строительные подрядчики, подрядчики технического надзора.
Но мы переоценили свои силы, — через два месяца работы по разработке ядра, увидели, что выбрали неправильную реализацию работы приложения. Она была основана на бизнес-процессах. Такое решение было основано на моём опыте построения первого бизнеса, и как оказалось — это было неправильным решением. Выкинув около 60% кода, написанного за два месяца мы продолжили работу с другой архитектурой (архитектура — каркас приложения).
Всё это время, с частотой раз в две недели, со мной связывались представители ГАСК, интересовались: как у нас дела и когда мы можем что нибудь показать? В начале мая, после очередного звонка, я сходил в офис ГАСК и ещё раз переговорил с руководителем. Объяснив причину задержки я пообещал, что через две–четыре недели ядро системы будет готово и мы сможем его показать. Четыре недели ему не понравилось, я заверил, что четыре недели это самый пессимистичный сценарий.
Причины для такого обещания были. После того, как мы отказались от бизнес-процессов, работа шла быстро. Но, как оказалось, мои ожидания были слишком оптимистичны. Архитектура приложения была разработана таким образом, что каждая новая возможность, которую мы хотели внедрить в приложение, влияла на уже реализованные возможности. Проще говоря, когда мы добавляли в приложение что-то новое — могло сломаться что-нибудь существующее. И чем дальше шли, тем заметнее это было. Задача, которую можно было бы сделать за полдня, могла забрать два дня. Конечно же, в обещанные две недели мы не справились и еле уложились в четыре недели.
В начале июня я сходил руководителю ГАСК, чтобы сообщить о готовности, показать ядро системы и продолжить работу вместе с ними. Но в ходе разговора было сильное ощущение, что доверие к нам, как к надёжным партнёрам, сильно пошатнулось.
Появилась и другая проблема: в ходе разговора выяснилось, что на данный момент разрабатывается другая информационная система — e-Qurylys. И она уже вводит инструменты, в которых нуждался ГАСК.
От этого позиции нашего стартапа сильно ослабли — это было заметно по отношению к нам. Если раньше была заинтересованность и активные вопросы по ходу разработки, то теперь появился холод и недоверие. По крайней мере, я так это интерпретировал в ходе последующих встреч. Теперь мы для ГАСК-а были не инновационным стартапом, который предлагает крутое решение в сфере строительства, а догоняющей командой с туманными перспективами.
Последующие дни были очень сложными для меня. Поселившаяся тревога вытягивала всю энергию и не давала полноценно сконцентрироваться на решении проблем. А решать проблемы надо, они не исчезнут сами по себе.
Теперь нашей команде надо было решать две основные, можно сказать, глобальные проблемы нашего стартапа:
- Нестабильность процесса разработки и решение архитектурных вопросов, из-за которых мы срывали сроки.
- Определиться с позиционированием нашего продукта на рынке, в связи с выходом на рынок продукта e-Qurylys.
Было понимание, что не решив системную проблему в разработке, мы скорее всего будем опять срывать сроки и процесс разработки будет замедляться. Надо было выбирать из двух вариантов:
- Работаем дальше с тем, что уже сделали.
- Плюсы: Наконец-то начнём реализацию каких-либо фич, (функционала) вместе с участниками сферы строительства.
- Минусы: Остаются нерешёнными основные проблемы нашей работы — срывы сроков и непредсказуемые результаты работы. Если не менять архитектуру приложения, то в будущем мы упрёмся в «потолок». Если менять архитектуру вместе с реализацией фич, то это также будет сказываться на сроках реализации.
- Решаем наши проблемы в разработке;
- Плюсы: Реализуем более здоровую архитектуру, рассмотрим где и что можно улучшить в процессе разработки. Все это должно привести к более стабильным срокам разработки и качества продукта.
- Минусы: Придется начать с самого начала. Никто не гарантирует, что изменения решат наши проблемы. Разработку функционала приложения опять придётся отложить.
Что мы выбрали и как хотим решить свои глобальные проблемы? Расскажу в следующих постах.
Чтобы не пропустить ни одну из новых публикаций — подписывайтесь на наш Телеграм канал.