Из багов и неопределённости к прозрачному процессу разработки, релизу MVP и первых оплат: как я подключился к существующему проекту, навёл порядок, и привёл к финансовым результатам

🔍🤠 Меня часто привлекают когда предыдущие разработчики наделали делов, и не справились с тем, чтобы довести до конца. В итоге не понятно насколько реально готов проект, сроки уже поджимают, половина якобы "готового" функционала частично не работает, в общем полная беда. С появлением ИИ и "вайб-кодеров" эта проблема стала ещё масштабнее.

В этом кейсе я подробно разобрал один из таких случаев.

Создать Telegram-бота, через которого пользователи смогут использовать разные нейросети такие как ChatGPT, Midjorney, Nano Banana, и множество других, для работы с текстом, изображениями, звуком и видео. Получать оплату от пользователей через ЮКассу и Telegram-звёзды. Создать Telegram Web Application: мини приложение, которое будет открываться в боте, и значительная часть функционала нейросетей будет управляться и настраиваться через него.

Когда я присоединился к проекту, он уже был готов примерно на 35%.

Но что это была за готовность?

Вайбкодеры с фриланса нагенерировали кучу дубликатов кода, запутались в них, создали адские полотна кода где было всё вперемешку: и логика, и маршруты, и вспомогательные функции.

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

Объявленые сроки неоднократно сорваны, огромное количество багов, толком ничего не работает, в проекте полный хаос, нет понимания что осталось сделать и сколько всего багов.

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

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

Результат после сотрудничества со мной: успешно реализован MVP, продукт вышел на рынок, получает платежи от пользователей.

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

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

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

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

И вот что я сделал:

В первую очередь я внедрил и настроил таск-трекер, чтобы перед глазами чётко видно было какие задачи в работе, кто их делает, когда приступил, какие задачи готовы, какие ещё в планах.

Благодаря таск-трекеру стало удобнее работать, так как в подробностях у задачи можно в редакторе написать полноценное техническое задание с декомпозицией на подзадачи:

Также в каждой карточке задачи можно было переписываться в realtime-чате, таким образом вопросы разных задач не перемешивались в хаос, и не терялись, как было до этого в Telegram-чате.

Я подключил QA-инженера (тестировщика) и делегировал ему создание карты пользовательского пути по макетам.

Карта представляет из себя mind-map из визуального отображения всех возможных маршрутов пользователя внутри бота а также в mini-app (TWA). Иерархия была следующая: “модуль”, “1 конкретный пункт меню”, “1 конкретная функция”.

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

Находя баги тестировщик заводил их не только в mind-map, но и в таск-трекер, за счёт этого команда сразу узнавала о найденных проблемах, и разработчики могли брать их в работу.

Я обнаружил, что предыдущие разработчики генерировали код при помощи ИИ, не сильно вникая в то, как это всё работает:

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

Код дублировался: вместо переиспользования одних и тех же кусков кода в похожих ситуациях, каждый раз там была “реализация этого функционала” заново.

И иной раз функционал между версиями одного и того же компонента отличался, оно и не удивительно – несогласованность данных, нарушение фундаментальнго принципа DRY - don’t repeat yourself.

Рассказать Вам

Объясню на простом примере: скажем есть у вас в мобильном приложении кнопка.

Обычная такая кнопка, на ей иногда “ОК” написано, иногда “Далее”, или ещё что-то. Кнопка по UX/UI дизайну и макетам проекта используется в десятках если не сотнях страниц.

Теперь представьте, что нам нужно поменять цвет этой кнопки:

Когда код дублируется – придётся вносить изменения отдельно в каждый случай, где кнопка используется в проекте. Легко упустить несколько таких кнопок, и тогда изменение применится не на всех страницах. Кроме того код сильно засоряется, так как везде где должна быть кнопка, находится весь код логики кнопки.

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

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

Далее продолжаю историю "Как я привёл продукт к точке Б"

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

Зачем вообще тратить на это время, спросите Вы?

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

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

В процессе я выписывал какие были проблемы, как было, и как стало после рефакторинга.

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

Ознакомил с ними команду и контролировал исполнение

Таблица-срез ситуации за каждый день. Благодаря ей видно сколько обнаруживается новых ошибок, и как команда ведёт над ними работу.

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

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

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

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

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

На себя брал самые сложные и ответственные задачи, чтобы точно было всё чётко.

За время разработки я:

Когда срочно нужен дизайн, и нет времени ждать дизайнера, быстрее применить свои навыки в дизайне.

Отрисовал дизайн страницы баланса в стиле проекта, и после утверждения реализовал её.

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

Казалось бы – что такого в том, что я нарисовал эти незаурядные интерфейсы?

Сэкономлены дни time-to-market в ожидании пока дизайнеру распишут задание, дизайнер освободится от своих дел и сможет взять задачу, потом когда он её завершит – там не был доступен в моменте дизайнер в тот момент.

Да, я не только fullstack-разработчик, но ещё и дизайнер.

И это помогло сразу сделать продакшен-вариант, тут же его согласовать и разработать.

Кстати дизайн для своих сайтов, и дизайн своих кейсов тоже делаю лично я.

Я Андрей Рик, ИТ-волшебник: senior fullstack разработчик, а также AI-driven, то есть использующий ИИ для ускорения работы, с пониманием каждой строчки кода, который сгенерировал ИИ.

Максимум информации обо мне можно прочитать на моём сайте.

🎥 Моя видео-визитка:

Длится всего 5 минут - познакомимся получше?