Разработка ПО
Менеджмент
Для компаний
Для стартапов
Архитектура ПО
У середині 2020 року до нас звернувся представник інвестора - візіонер проєкту “Гараж”. На зустрічі, на якій були присутні технічні спеціалісти і консультанти, ми обговорили основну концепцію проєкту. Це було в рамках безкоштовної консультації. Якщо коротко, у застосунку Гараж ми допомагаємо водієві знайти потрібне СТО, а власники станцій або мереж технічного обслуговування отримують трафік клієнтів. У цій статті ми поділимося секретом - як можна заощадити замовнику застосунку близько 60 000 доларів завдяки грамотному проєктуванню архітектури і використанню спеціальної технології для розробки мобільного застосунку. Також будуть висвітлені деякі деталі, які нам дозволено розкривати. Ці деталі допоможуть Вам краще зрозуміти - що таке розробка застосунків і як створити власний застосунок для бізнесу.
Оглавление
Отже, “Гараж” - це 2 застосунки для двох типів користувачів - для водіїв і для співробітників станції технічного обслуговування або мережі таких станцій.
З одного боку, застосунок для водіїв - на ньому відображається карта, на якій позначені всі СТО в місті. Власник авто може швидко знайти відповідні послуги для свого авто. Для цього він додає свої автомобілі, обирає деякі характеристики і послуги, що його цікавлять, після чого записується в календарі на зручний доступний час. Йому будуть надіслані сповіщення, щоб він не пропустив візит на обслуговування. На карті буде побудований найближчий маршрут до СТО з урахуванням трафіку.
З іншого боку, це застосунок-облікова система, у якій адміністратор СТО може вносити дані про своє СТО, вводити свої послуги, виставляти графік роботи, дивитися календар, у якому записані клієнти на певний час, бачити статистику успішності своїх точок СТО, складати свою унікальну карту послуг і призначати ціни на них.
За проєктом складалися звіти щодо кожного завдання. Загалом за проєктом було виконано 600 різних завдань, багато з яких самі по собі являють собою мікро-ТЗ. Якщо Ви плануєте замовити в нас проєкт - ми можемо показати Вам приклад такого звіту (звичайно, деякі дані стерті з огляду на комерційну таємницю).
Дизайн
Дизайн проєкту був виконаний спеціалістом на стороні замовника. Це був сучасний, естетичний дизайн. Але оскільки до компетенції дизайнера зазвичай не входить проєктування дизайну з технічної точки зору, надалі нами були запропоновані деякі зміни, які краще поєднували картинку з технічною частиною проєкту.
Мобільні застосунки
Мобільний застосунок планувався як на iOS, так і на Android. Важливо розуміти, що класичний спосіб розробки мобільних застосунків - так званий “нейтивний” або “рідний”. Він передбачає, що Ви будете використовувати окремого спеціаліста з мови Java на андроїд і мови Swift або Objective C для iOS. Це надійний і перевірений спосіб, однак він досить дорогий, особливо якщо у Вас складний клієнт-серверний застосунок з великою кількістю екранів, нетиповою схемою даних і складними операціями пошуку даних.
Нами був запропонований альтернативний метод розробки - гібридний. Це коли Ви розробляєте один застосунок одразу для платформи iOS і Android. По суті, Ви створюєте вебзастосунок, який запускається в такому ж вигляді, як рідний. Зовні відрізнити ці застосунки практично неможливо, вони однаково завантажуються в сторы і маркети, однаково встановлюються на робочий стіл з іконкою.
Але, звичайно, є нюанси. По-перше, є деякі функції, які досить складно портувати на гібридний застосунок. А якщо застосунок робить недосвідчений спеціаліст і без підтримки досвідченого проєктувальника - застосунок буде глючити. Можуть бути не дуже помітні “гальма”, затримки при торканні інтерфейсу - від 300мс до 1000. А можуть бути повні відмови у функціонуванні деяких віртуальних елементів. Нашій команді вдалося портувати всі необхідні вбудовані функції для обох операційних систем, обійти всі труднощі і створити інтерфейси, які працюють рівно на такій самій швидкості, як і класичні мобільні застосунки, ніхто не відрізнить його від нейтивного. При цьому, завдяки грамотній архітектурі і ухваленню ключових технічних рішень, ми змогли не просто зробити повністю функціонуючий застосунок, а й зробити його в рази дешевшим, ніж розробка окремих апів. За нашими підрахунками, ми заощадили клієнту від 60 до 80 тисяч доларів (залежно від того, за яким рейтом рахувати).
Не будемо лукавити, усе це вийшло не легко. Це був серйозний виклик, складна робота, іноді - безсонні ночі. Було безліч нюансів і проблем. І перші версії застосунку мали різні не дуже приємні грубості. Однак проєкт розроблявся протягом 4.5 місяців (для такого застосунку це дуже короткий строк) і вже на 3-й місяць було
На момент здачі застосунку все працювало строго за ТЗ, і в нас навіть знайшовся час виконати додаткові оплачувані роботи, а також додати в проєкт приємні і зручні функції - бонуси, про які на етапі складання ТЗ ніхто не подумав.
Детально про функціональність застосунків
Реєстрація - користувач міг отримати доступ до карт після вибору мови, верифікації телефонного номера і згоди з правилами сервісу.
Карта - була обрана й інтегрована карта Google Maps. Не найдешевше рішення, у статті про застосунок Інтернет-місто ми розповідали про нюанси вибору карт. Але ми потребували деяких функцій гугл карт, які було легше купити й оплатити за тарифом, ніж писати заново на основі безкоштовних карт.
Пошук СТО - водій міг з легкістю обрати певні побажання до СТО, після чого на карті будуть відображені всі відповідні. Також можна переглядати у форматі списку, який сортувався за відстанню до СТО.
Розрахунок відстаней - одна з дуже корисних функцій гугл карт. Завдяки спеціальному гугл сервісу ми розраховували відстані до різних точок. І не пряму геодезичну відстань, а відстань з урахуванням усіх ламаних ліній, утворених дорогами. Тут були деякі нюанси оптимізації, які також заощадили бюджет, необхідний за тарифами гугл карт.
Відмальовування маршруту - для водія важливо, щоб застосунок працював у режимі навігатора і привів його прямо до СТО. Для цього потрібно не тільки відмалювати лінії на карті. Але й визначити місцезнаходження водія, а також постійно його актуалізувати в міру руху. З цим є деякі проблеми в мобільних мережах, особливо у карти гугл. Іноді геолокація може визначитися неточно, ви могли помічати такі лаги в сервісах таксі, коли машина в застосунку раптом опиняється зверху багатоповерхівки. З цим нам довелося воювати.
Запис за календарем - після вибору певного СТО здійснюється бронювання. Логіка бронювання - це завжди непростий алгоритм майже в будь-якому застосунку. Не будемо і не можемо вдаватися в деталі.
Додавання авто - водії можуть додавати фото і базові дані свого авто (ВІН, модель тощо). Усе це необхідно як для пошуку актуальних СТО, так і для рекомендації найбільш відповідного.
Профіль - у водія є своя сторінка, де він може бачити всі дані про свої машини, кредитні картки (їх можна додати кілька), платежі, майбутні записи та історію всього, що відбувалося в застосунку.
Нагадування - водій має отримувати сповіщення про те, що скоро час його запису. І це має відбуватися навіть якщо сам застосунок вимкнений. Досягти такого ефекту можна, використовуючи пуш-сповіщення. Для цього був інтегрований спеціальний сервіс, який їх розсилає. Ми порекомендували сервіс з хорошими тарифами і великим набором безкоштовних пушів на місяць.
Інтеграція платіжних систем - для оплати послуг ми розглядали різні сервіси платежів. Для завдань цього проєкту відповідним виявився сервіс Fondy. Ми впровадили його за схемою Б - це розширена і нетривіальна схема, яка передбачає впровадження через АПІ, а не стандартні прості форми\кнопки.
Інтеграція омніканального інструмента - для того щоб можна було проводити з клієнтом різні маркетингові активності - потрібно вміти розсилати йому сповіщення в зручні для нього мережі або месенджери. Для цього ми порадили й інтегрували спеціальний сервіс, який уміє це робити. Це також заощадило бюджет на розробку, оскільки можна безкоштовно впроваджувати кожен месенджер або мережу самостійно. Але це буде не безкоштовно в плані часу, який витратять програмісти на розробку і відлагодження. У цьому проєкті воно того не вартувало. Однак ми описували розробку маркетингової платформи Social Jet, і там актуально було працювати з АПІ кожної соціальної мережі і месенджера. На кожен проєкт ухвалюються індивідуальні рішення, універсальних не існує, це важливо розуміти при розробці власного проєкту. Технічні рішення ухвалює системний архітектор, управлінські рішення ухвалює менеджер проєкту, рішення щодо вимог проєкту допомагає ухвалювати бізнес-аналітик.
Адміністративна панель
Більша частина цього розділу не може бути описана нами з огляду на договір про нерозголошення. Скажемо коротко, що це панель зі статистикою, аналітикою, елементами CRM (системи управління взаємовідносинами з клієнтами), календарним планом, даними оплат, інформацією про клієнтів і їхні авто, історією операцій з певним авто, а також різні функції, необхідні для системного адміністрування свого СТО. Звичайно, в адмінці можна додавати різну інформацію про СТО, розписувати прайси, додавати фотографії в галерею СТО та інше.
Проєктування архітектури
Усі деталі під НДА
Написання ТЗ
Для проєкту було розроблено професійне технічне завдання нашим бізнес-аналітиком. Усі деталі під НДА.
Організація командної роботи
Менеджмент цього проєкту не був тривіальним. Особливістю проєкту було те, що частина команди була повністю під нашим контролем, частина команди була під нашим командуванням, але поза штатом, частина команди була нам по суті непідконтрольна, але ми щільно з ними взаємодіяли (наприклад, з візіонером, сисадміном, дизайнером). Наш сертифікований менеджер проєкту з перших днів змоделював процеси в рамках проєкту, управляв дедлайнами, контролював основні етапи здачі певних функцій, відмальовував необхідні діаграми (наприклад WBS) і, виходячи з ієрархічно-залежних функцій, тримав строки всіх фаз під повним контролем.
Складнощі і виклики
Звичайно, найсерйозніші складнощі і виклики були, як і завжди, в архітектурних рішеннях, а точніше в різноманітних технічних конфліктах підсистем. Зокрема, були особливі танці навколо навантажень і досить дорогого трафіку в картографічні гугл-сервіси. Один неправильний рух - і проєкт почне витрачати більше грошей на своє функціонування, ніж заробляти.
Було виділено досить мало часу на ТЗ, та й взагалі на весь проєкт. Строки проєкту були обмежені деякими маркетинговими стратегіями і дедлайнами.
На проєкт був виділений відносно обмежений бюджет (менше 50 000 доларів). Це скромний бюджет для проєкту такого калібру, але з огляду на те, що архітектора (і за сумісництвом засновника нашої компанії) запросили в дольову участь як партнера ТОВ - було вирішено взятися за проєкт.
Проєкт був стартапом - це означало, що в нього немає чіткої і вираженої бізнес-моделі. У проєктах такого плану ще складніше будувати архітектурні гіпотези і ухвалювати архітектурні (ключові) рішення.
Періодично в проєкті змінювалися плани. Не ключовим чином, але в рамках обмежених строків і бюджету був необхідний крайній професіоналізм менеджменту, щоб усе встигнути і ніде не прорахуватися.
Був ряд складнощів з тонкощами налаштування інтегрованих сервісів. Зокрема, на рівні технічної підтримки сервісів (одвічна проблема)
Про складнощі інтеграції карт уже було написано вище, але можна підсумувати, що карти були суттєвим технічним головним болем у цьому проєкті, особливо з огляду на те, що будь-які дії з нею платні, а дій користувачі здійснюють дуже багато. Тому багато архітектурних розрахунків були виконані оптимізаційно - саме з метою економії коштів різними способами кешуючи дані і розробляючи нересурсозатратні алгоритми.
Окрема історія - це проходження гайдлайнів. Іншими словами, проходження перевірки при реєстрації застосунку в сторах. Для андроїда ці гайдлайни були виконані досить просто. А для iOS було безліч проблем. Починаючи з того, що платформа не хотіла приймати наші кошти за оплату акаунта розробника (без нього неможливо залити застосунок). І закінчуючи величезним списком вимог, які необхідно внести в застосунок для того, щоб його схвалили. Це тягнулося довгий час і знадобилася консультація та допомога iOS спеціаліста.
Цей проєкт показує, що нам не страшно довірити завдання будь-якої складності, навіть якщо це дуже нетиповий проєкт. Хоча Гараж і не був найскладнішим нашим проєктом технічно, він містив величезну кількість нюансів як з точки зору проєктування, розробки, так і з точки зору управління людьми на проєкті.
