Знакомство

В одном телеграм-чате по стартапам я познакомился с человеком из команды стартапа доставки.

Стартап искал себе технаря, в команде уже были все кроме CTO (Chief Technology Officer, по-нашему технический директор). Я с большим удовольствием взялся помогать, так как:

1. У меня большой опыт в разработке, 15 лет работаю программистом
2. Проектировал и создавал коммерческие сервисы с нуля
3. Сделал 1 стартап, написал ядро кода в другом, сделал несколько MVP, в общем уже есть опыт быстрого создания реального продукта
4. Мне нравится получать отдачу от того что я делаю, стартап для этого идеален

Поэтому я предложил присоединиться к команде и сделать MVP, и меня взяли в команду.

Что сейчас

Идея сервиса — служба курьерской доставки.

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

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

Показатели хорошие, нужно расти дальше и масштабироваться.

Что нужно сделать

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

Требуется:

• Заказывать доставку
• Оплачивать доставку
• Информировать курьеров о заказах
• Вести статус выполнения заказа

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

Набор приложений

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

Значит делаем:

1. Мобильное приложение для заказчиков
2. Мобильное приложение для курьеров
3. Админку для операторов
4. Админку для сотрудников компании

Сокращаем MVP

По правилу Парето, 20% усилий дают 80% результата, применяя это к приложениям можно сказать что только 20% задуманной функциональности будут действительно важны.

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

Берём техзадание на MVP и проходим по нему.

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

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

• Можно не делать — не делаем.

• Можно сделать позже — делаем позже (после MVP).

• Можно упростить — заменяем на упрощённый вариант.

Мы оставили только самое необходимое.

Объём работы который нужно сделать в MVP сократился в несколько раз.

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

Выбор стека

Почему не NoCode

Выбирая стек, я задумался, не сделать ли всё на NoCode конструкторе приложений.

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

Но отказался от этой мысли.

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

Во-вторых приложение на конструкторе обычно служит только для проверки идеи, так как конструкторы недостаточно мощны и гибки по сравнению с кодом. Проверяем идею, если она работает то переписываем на код. Но в нашем случае сама идея уже проверена, нужно строить “продакшен” версию MVP. Мы не проверяем “можем ли мы сделать доставку”, мы уже сделали доставку, нужно совершенствовать и развивать.

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

Стек

Для того чтобы не застрять с разработкой, и не скатиться в баловство с технологиями, я беру только те инструменты которые уже отлично знаю:

• Laravel (PHP)
• Docker
• MySQL
• Ubuntu

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

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

Я бывал. Поэтому уверен что это важный пункт: брать только изученное. Сводим риски к минимуму.

Мобильное приложение

Мобильное приложение нужно как для заказчиков так и для курьеров.

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

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

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

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

Какую технологию выбрать?

Андроид и iOS “нативные” приложения можно сделать, но это долго и дорого. Не подходит для MVP.

Flutter и прочие кросплатформенные фреймворки тоже не подойдут, так как я с ними не работал. Неизвестно сколько времени это займёт, и не упрусь ли я в ограничения площадок App Store и Google Play.

Поэтому выбрал делать веб-версию приложения, чтобы можно было открыть страничку адаптированную под мобилки и работать с ней как с приложением. С этим я точно справлюсь.

Осталось найти подходящий UI фреймворк для быстрого написания мобильного приложения. Поспрашивал и мне посоветовали Quasar — как выяснилось, современный и довольно удобный UI фреймворк сделанный на основе фреймворка Vue 3.

Дальше я засел за приложение, и благодаря документации, ютуб-урокам по квазару, помощи гугла и помощи телеграм чата по квазару, стал делать мобильное приложение.

Апишка

Наш фронтенд реализован в виде SPA приложения, поэтому для общения с сервером нам требуется апишка.

В Laravel апишка уже встроена, поэтому сразу её и используем. Прописываем нужные роуты, и информация начинает поступать в приложение.

Для авторизации подключаем пакет Laravel Sanctum, он сделан специально для нашего случая — для быстрого подключения авторизации в апишку SPA приложений.

Админ-панель

Для операторов и сотрудников нам потребуется админ-панель.

Предположительно она будет меняться гораздо чаще чем продукт для пользователя, поэтому нам нужна максимальная скорость разработки. Также нам не сильно важен внешний вид и удобство, по причине того что это внутренний инструмент.

Мы можем не заморачиваться и сделать простую админ-панель на платном шаблоне Laravel Nova.

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

При этом в Nova как я помнил по опыту прошлых проектов не было поддержки мобильной вёрстки.

Что делать?

Не хотелось делать адаптацию админ-панели под мобилки самому, поэтому я поискал готовую админ-панель для Laravel с поддержкой мобильной вёрстки и нашёл BackPack.

Но когда рассказал об этом в чате разработчиков, выяснилось что в новой 4й версии Laravel Nova которая вышла в апреле 2022 уже добавили поддержку мобильной вёрстки. А значит нам и BackPack не нужен, можно всё сделать на Nova — и для сотрудников, и для операторов.

Бэкенд

Для бэкенда и основной бизнес-логики приложения я выбрал Laravel.

В пользу этого выбора:

• У меня есть опыт разработки на Laravel более двух лет
• Стабильный фреймворк с удобным синтаксисом и структурой
• Развитое сообщество
• Развитая инфраструктура — библиотеки, пакеты, инструменты
• Возможность писать чистый код

Выбор сервера

У меня есть собственные проекты на арендованных серверах VPS (Virtual Private Server), поэтому выбрать было несложно.

Хостер

На хостере SimpleCloud у меня есть сервер, на котором я разворачиваю всяческие пет-проекты. На нём и разместил демо-версию приложения.

Когда приложение “дозрело”, то мы купили сервер на хостере IHC для продакшен-версии приложения. В отличие от SimpleCloud, на IHC можно апгрейдить сервер гораздо сильнее, да и соотношение цена-мощность для более мощных серверов там получше. Поэтому сразу выбрал IHC с прицелом на рост.

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

Параметры сервера — железо

Параметры для старта:

CPU (процессор) — 4 ядра

RAM (оперативная память) — 8 ГБ

HDD (диск) — 150 ГБ

Цена 1950 рублей в месяц

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

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

Серверный софт

Ubuntu 22.04 — свежая стабильная версия стандартной серверной системы Ubuntu, с поддержкой до 2027 года.

Docker — для удобства установки на сервер и локально на машину разработчика

MySQL 5.7

PHP 8.0

Nginx

План действий

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

Чтобы не утонуть в деталях и дойти до цели, нам нужен план.

Карта в Mind42

Я пользуюсь бесплатным инструментом Mind42 для создания Mind Map (карты знаний).

Позволяет упорядочить информацию и не держать её в голове.

Для меня такая карта служит одновременно и структурированным ТЗ и трекером прогресса по задаче. Всё в одном месте.

Сначала в свободном виде описываем самое важное что должно быть реализовано, чтобы не упустить из виду.

Выписываем решения по технологиям.

Планируем итерации. На скриншоте зелёными галочками отмечено то что уже сделано на текущий момент.

Подробно декомпозируем задачу в итерации. Необходимо чтобы ничего не забыть и не делать лишнего.

Вот пример полностью расписанной первой итерации.

Начинаем с важного

Важный принцип, который повышает шансы на успех — расположить шаги в правильном порядке.

Начинаем с самого важного. Далее каждый шаг всё менее важный, по убыванию. Заканчиваем наименее важным.

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

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

Это совершенно неправильно.

Что важнее всего в доставке? Создать заказ на доставку.

Именно этот шаг и необходимо сделать первым.

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

Никакой. Приложение доставки без заказа доставки будет бесполезным.

Также на экране доставки самый сложный интерфейс, это ещё одна причина делать его первым.

Поэтому первым шагом делаем заказ доставки.

Почему начинаем с важного

1. Лучше архитектура

Порядок выполнения влияет на архитектуру кода. Более поздний код подстраивается под уже существующий.

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

2. Жертвуем неважным если потребуется

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

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

3. Отменяем неактуальное

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

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

Так не делается

Некоторые разработчики могут возразить, что “так не делается”. Нельзя, мол, создать заказ без авторизации. Или без создания таблиц в БД. И так далее.

В таком случае сразу вопрос — верно ли это? Может быть это возможно, вы просто не хотите или не привыкли так делать? Или просто не пробовали?

Если бы вам дали такое задание, вы смогли бы придумать решение? Или это действительно невозможно в принципе?

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

План готов, приступаем к работе!

Продолжение следует