UNO - Мобільний застосунок для служби таксі та доставки

Це дуже цікавий кейс, він про комплексну розробку двох мобільних застосунків, обліково-адміністративної системи та системи ефіру для служби таксі й доставки. Я спочатку розповім про сам застосунок, про процес розробки, а наприкінці статті опишу деякі виклики, особливості та нетипові завдання в процесі уточнення вимог проєктування архітектури. Звісно, багато надзвичайно цікавих моментів змушений опустити з огляду на NDA. Цей проєкт вкрай не шаблонний, такий проєкт не зробити ні за готовим керівництвом, ні за стандартним підручником аля "Вігерс Бітт. Розробка вимог до ПЗ". Ні, ця співпраця мала масу особливостей, гідних одного з найскладніших наших кейс-проєктів. Але як і завжди, ми цих складнощів очікували й були готові як до складних стратегічних рішень, так і до оперативних і тактичних імпровізацій.

Оскільки ми спеціалізуємося на розробці систем для автоматизації обслуговування клієнтів - розробка адміністративного програмного забезпечення та мобільного застосунку для служби таксі й доставки в єдиному застосунку одразу здалася нам цікавим проєктом і, звісно, викликом, особливо з огляду на бурхливу конкуренцію та уявну перенасиченість цього ринку технічними рішеннями на тлі пандемії та масового зростання попиту на доставку на початку 2021. Багато років ми спілкувалися, зокрема, з клієнтами, які планували замовити розробку онлайн сервісу для таксі, був навіть досвід розробки не складних типових рішень із цієї області, але нічого надприродного. А в середині 2021 року до нас звернулася група інвесторів із нетиповим і складним проєктом саме у сфері таксі. На той момент, у сумі з описаним досвідом у предметній області, ми вже мали досвід великих (не таксі) проєктів з картографічними сервісами та GPS навігацією, колцентрами, впровадженням системи оплати, був також досвід роботи з даними в реальному часі та складними наборами схем даних. Виходячи з цього ми розуміли, що повністю усвідомлюємо, як організувати команду під проєкт, задизайнити, спроєктувати систему і запрограмувати її.

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

Першою важливою особливістю цього проєкту виявилося те, що стан дизайн-макетів був розсинхронізований із поточним станом технічного завдання. Тому було важливо провести повне порівняння ТЗ і дизайну для виявлення невідповідностей, таких на момент старту було багато, тому ми одразу підключили дизайнера.

Наш дизайнер домальовував нові макети та вносив зміни в існуючі. Макети додатково опрацьовувалися за сценаріями використання інтерфейсу. Ми знаходили нові способи скоротити зайві інтерфейси або додати нові, якщо це справді необхідно і неможливо перевикористати вже існуючі. Таким чином ми виробили деякі поліморфні патерни візуального відображення індивідуально саме для цього проєкту, для цієї предметної області.

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

1. Так, був складений документ з 38 правками

2. І було написано завдання на Дизайн другого застосунку, що включало близько 40 унікальних сторінок!

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

Увесь дизайн був зроблений у програмі Figma - найсучасніший застосунок для веб дизайну.

Спочатку від минулої команди розробки нам дісталася схема, яка показувала логіку переходу між сторінками. Що для початкового розуміння проєкту було корисно. Але надалі вона не використовувалася, оскільки не була правильною і потребувала переробки.

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

У ході проєктування архітектор документував основні технічні рішення з використанням стандартного підходу документування. Схеми “сутність-зв'язок” з використанням чотирьох основних поінтів - точок зору:

1. Логіка. Опис основних сценаріїв і змін в інтерфейсах при зв'язку з об'єктами предметної області доставки пасажирів і легких вантажів.
2. Фізика. Були задокументовані деякі ключові особливості проєкту з точки зору необхідних обсягів пам'яті, особливостей розгортання, особливостей масштабування, вимог до швидкості доставки нових версій і так далі.
3. Статика. Опис діаграми зв'язків і типів станів. Опис моделі предметної області у вигляді взаємозалежних класів у безчасовому зрізі, опис можливих станів і формату даних та списку можливих дій з множинами. Створення бази даних і моделей даних.
4. Динаміка. Це опис алгоритму головних процесів і подій, які виникають у часі, та їх прямий зв'язок із моделлю предметної області., Уявіть собі місто, у якому безліч доріг, адрес, автомобілів і мото-техніки. Люди за певною адресою потребують транспорту для поїздок і доставки. І все це відбувається в реальному часі та пов'язане з масою тонкощів при комунікації, особливо коли не використовується живий оператор. Усі ці сутності - це екземпляри статичних моделей, що мають свій життєвий цикл. Опис поведінки та зміни об'єктів у часі, опис послідовності алгоритму, виклику динамічних методів моделі предметної області - ось, що було описано в цьому поінті.

Командою була продумана схема даних, виходячи з технічного завдання в програмі Workbench. Її приблизний розмір можна зрозуміти за картинкою нижче. Але вона ще розширилася б за рахунок технічних таблиць.

Окремо опрацьовували схему найважливіших бізнес процесів (реєстрація замовника, реєстрація виконавця, оформлення замовлення, виконання замовлення на стороні замовника і на стороні виконавця). Оскільки при детальному розгляді алгоритму завжди виникають питання реалізації.

Xтобы оцінити розмір проєкту та повноту вимог - його Технічне завдання було більше 150 сторінок (77 сторінок, чистого тексту без картинок!)