Від розробника до фаундера. Як я повернувся в IT після першого невдалого стартапу та наважився створити новий
Привіт, спільното!
Мене звуть Роман. Маю багато років досвіду як розробник та Team Lead. Робив навіть спроби створити власну аутсорс/аутстаф-компанію, як і стартап, але через перші помилки та несприятливі обставини все пішло не так, як хотілось.
Взагалі мій кар’єрний шлях починався до карантинних років і був ок, враховуючи попит на розробників. Плюс бажання викладатись на роботі, розв’язувати складні технічні завдання — все це давало дуже позитивні відгуки зі сторони клієнтів, з якими співпрацювала компанія. Всі мої відпустки й вихідні проходили за книжками, конференціями, курсами.
Згодом був період у чотири роки створення свого бізнесу, який провалився. Повернутись, тобто знову знайти роботу, було дуже важко. Адже очікування були високими, технології не стояли на місці — поки інші спеціалісти їх вивчали і здобували досвід, мені доводилось розв’язувати питання з офісом, ноутбуками, бухгалтерією, кавою. Та ще рядом речей, які нічого не дають і якими б краще ніколи не займатись.
Технічні співбесіди проходили дуже погано, адже досвід більше не відповідав дійсності. Я навіть пробував думати про кар’єру PM, але після першої такої співбесіди зробив висновок, що то не моя конкуренція. З резюме довелось видалити будь-які згадки про бізнес і щось придумати про break. А з початком війни все стало в рази гірше.
Я вирішив поставитись до задачі максимально серйозно: розділив знання на категорії та агрегував все, що знав, у документи.
Перше, що мене трохи «заспокоїло» — це те, що все знати і пам’ятати неможливо. Друге — мені простіше показати та виконати завдання, ніж пояснювати і говорити. Я почав акцентуватись на вакансіях, де передбачались тестові, та виконував їх максимально якісно.
В деяких моментах були питання, які просто потребували відсутнього у мене досвіду (hands on) у розв’язанні тих чи інших архітектурних задач, де від кандата очікувалось здійснення міграції чи рефакторинг (тут все ок). На жаль, були і питання, неактуальні в реальній роботі; іноді — нерозуміння співбесідником глибини того, що він сам запитує. А також були випадки, коли просто була думка інтерв’юера і неправильна.
Що таке Supo
Загалом хотів з вами поділитись історією про новий стартап, який я розробляю вже декілька років. Він починався, як Pet-проєкт для навчання. Сфера — кур’єрська доставка страв та напоїв із закладів харчування на кшталт двох конкурентів (іспанського та естонського), що наразі панують в Україні.
Одразу забіжу наперед та уточню, щоб очікування відповідали реальності: застосунок функціонує нормально, але наразі замовити щось неможливо. Оскільки ми все ще у процесі залучення бізнесів до співпраці. Документи, маркетинг і все таке.
Чому я обрав саме цей тип застосунку та сферу, розповім трохи згодом, десь приблизно через рік. Адже там є нестандартна ідея розвитку, але всьому свій час.
Наразі мобільна версія містить одночасно три акаунти, які користувач може змінити в будь-який момент: клієнт, бізнес та кур’єр. Щоб приймати замовлення чи доставляти їх, необхідно пройти процес реєстрації та модерації службою підтримки:
Які технології
Java MySQL Spring
Так вийшло, що з часів студентських років я потрапив у світ Java
. Тому коли постало питання стеку, не побачив причин змінювати на NodeJS
чи Go
. Десь я бачив аргументи в стилі, що у Java Spring
імена класів дуже довгі і BeanPostProcessors
вже всіх «задовбали». Але як можна взагалі таке брати до уваги? «У NodeJS Express
легше створити Rest API». Чи ті люди мали досвід з Spring Boot RestController
? Щодо того, що у Go
«Threads management простіший», а код можна написати тільки одним способом. Ну по-перше, це просто досвід, бажано необхідний для обох мов. А по-друге — я вже згодом писав на Go
і це твердження хибне.
Я ще довго вагався, бо не дуже полюбляю SpringDataJPA
, але коли побачив, що є SpringDataJDBC
, все стало на свої місця. Мене повністю влаштовує відсутність «автоматичного» кешу і до вподоби custom SQL на пів екрану в коді, де я можу в будь-який момент підправити те, що мені потрібно.
Dart Flutter
З Flutter
також не було «особливо вибору», оскільки Dart
для мене дуже схожий на Java. А принцип побудови інтерфейсу Layouts майже ідентичний до Java Swing
, з яким у мене також був немалий досвід. Коли постало питання вибору, Google ще не звільняв людей з Flutter-направлення, community дуже добре розвивалось, все виглядало перспективно. Тоді писали, що React Native трохи відстає за Performance, але я не перевіряв. Згодом знову писали, що вже навпаки (не дивно). Але я б і не сказав, що така конкуренція — це щось нездорове. Швидше зворотнє, адже змушує обидві технології розвиватись. Загалом мова Dart дуже полюбилась і хотілось би, щоб Java
рухалась в цьому напрямі (Kotlin
не пробував).
AWS
З Cloud Provider обрав той самий шлях найменшого супротиву. До війни я дуже активно готувався на сертифікацію AWS Certified Solutions Architect і вже обирав день екзамену, аж раптом о шостій ранку пролунав дзвінок першої повітряної тривоги. Сертифікацію довелось відкласти назавжди, а AWS виявився в нагоді. Із дуже важливих факторів — 12 місяців Free Tier, а також отримав лист «AWS Ukraine» з пропозицією в додаткових $300 на розвиток стартапу. Форма була дуже проста і я вирішив to give it a try. І таки так — все було, як обіцяли.
Чому так довго
Загалом приймати перші замовлення планувалось приблизно рік назад. Базова версія застосунку була готова і здавалось, що реліз зовсім близько.
1. Flutter State management
Якщо коротко, State Management довелось переписувати три рази. Найімовірніше, ця проблема не мала б бути чимось дивним для Senior Mobile-розробників. Я ж явно недооцінював перспективу. Тобто при натисканні кнопки, наприклад, мав би перемальовуватись тільки відповідний елемент замість всього components tree
. Але останнє мене зовсім не хвилювало. Аж доки я не помітив, що такий процес тягне за собою всі server api
, дані яких необхідні для віджетів. Негативний вплив на performance дуже серйозний і було очевидно, що довго такий сервіс не протягнув би.
2. Синхронізація дій користувача / UX
І це також, мабуть, стосується відсутності досвіду розробки під Mobile. Але тут на противагу це вже стосувалось б прямого враження користувача про застосунок. Проблема полягає в тому, що користувач може здійснити декілька дій одночасно. Перша з яких може закінчитись неуспішно. В результаті ми матимемо неочікувану поведінку на екрані мобільного застосунку та inconsistent state в базі даних. Тобто ситуацію, яка б не мала трапитись. Наприклад, користувач двічі натискає «здійснити замовлення», а потім ще й кнопку «назад».
3. Адмінка
Актуальність адмінки виявилась у вигляді служби підтримки для клієнтів і ще дуже багатьох, необхідних для забезпечення різних флоу мобільного застосунку, функцій. Повноцінний дизайн не розроблявся, а будувався із готових UI Kit компонентів мобільної версії. Вийшов окремий повноцінний продукт.
4. OTP login
Використання FirebaseAuth
реалізувалось за години, але головної болі згодом було дуже багато. Процес Captcha здійснює декілька редіректів і працює не з першого разу. Загалом я розумію, чому цей алгоритм такий, і що відбувається, але по факту це перше враження користувача про застосунок. І навіть коли все працювало ок, я чув відгуки від друзів, що «застосунок глючний». І це було дуже сумно, адже до фактичного функціоналу люди так і не доходили.
Якось сервіс взагалі перестав працювати на місяць в Україні, і Google Support «офіційно» заявили, що нам (розробникам) потрібно розглянути інші варіанти. В результаті так і відбулось, і все переробилось на AWS Lambda
. Це дуже дорого в порівнянні з «безплатним» FirebaseAuth, але я подумав, що «перше враження» важливіше.
5. Реєстрація на Google Play і Apple Store
Із хороших новин було те, що проблематика цього процесу передбачалась. На це пішло в загальному десь місяць: скриншоти, документи, офіційне підтвердження Id, фотографії обличчя, вибір аудиторії, версії, permissions і ще купа запитань, думати про які дуже не хотілось.
6. Оплата карткою
У мене був досвід старту проектів з нуля (переважно він тільки такий і був). Коли отримував документацію на розробку, перше, на що я звертав увагу — залежність від інших сервісів, тобто 3rd integration
. З цим завжди були проблеми. Будучи Team Lead, в таких випадках я передавав «звичайну» розробку команді. А з замовником ініціював процес інтеграції на максимально ранній стадії, щоб запевнитись: «це працює» до того, як «все готово», а інтеграція не виходить або неможлива. Бувало, клієнти, часто необізнані в цій сфері, піддавались впливу Sales Team компаній, які продавали щось взагалі не те, що там мало б бути. Як результат очікування — реліз, а в реальності — провал.
В Україні дуже багато платіжних систем. В моєму випадку проблематика це:
- таке враження, що вони підлаштовані під інтернет-магазини, тому API не таке як потрібно, а ще відсутній необхідний SDK.
- ситуація ще більш ускладнилась, оскільки використовувати Native SDK дуже не хотілось, адже це виглядало потенційною чорною дірою у
time consuming
.
Сумарно процес триває вже дев’ять місяців. На початку літа вдалось домовитись про розробку і інтеграцію FlutterSDK. Серед усіх фіч вона забрала найбільше часу на тестування і мала найбільше багів. Довелось дуже багато переписувати Order Flow
і очікується, що протягом найближчих місяця-двох ця фіча все ж буде доступна у prod.
Що найважче
Спочатку я думав зазначити тут слово дисципліна
, але це не зовсім так. Адже вона передбачає планування, графік і якісь зусилля для відповідності йому. Під час війни це неможливо: світло, тривоги, новини. Але є ще і побутові ситуації, які також легко можуть витягнути з контексту. А вмикатись назад нелегко. Необхідно постійно адаптуватись під обставини, тобто йдеться про напругу 24/7 . З цим потрібно навчитись жити.
Слова, які найкраще підходять під цей опис — комбінація із систематичного, послідовного, постійного результату.
Нести відповідальність і думати одразу за три частини загальної системи: Mobile, UX і сервер. Flow можна змінювати як на етапі дизайну, так і на етапі розробки, коли щось не дуже ок лягає. Таким чином все може трансформуватись on the go, але фічу вдається зробити за день-два одразу, а не за місяць. Сам час розробки був би приблизно однаковий, але справа в тому, що треба звільнити мозок і сфокусуватись на наступних задачах. І здавалось би, так — в певній мірі це прискорює розробку, але самопочуття після такої роботи — максимальна виснаженість.
Що далі
Стосовно функціоналу найближчим часом планується ще дві основні фічі:
- відгуки на заклади і сортування за рейтингом (зараз тільки за віддаленістю);
- можливість редагування замовлення після його розміщення. Тут флоу ще взагалі не продуманий, але з відгуків конкурентів це має бути актуальним.
Далі вебверсія застосунку плюс SEO, що також дозволить зробити сервіс популярнішим, наскільки це можливо. Тому крім Flutter доведеться вчити ще React, але мені не звикати. Тут одразу win-win: це передостаннє в todo list, в чому було бажання розібратись. А також це може бути основою, якщо Google продовжить свій journey халатного ставлення до Flutter і доведеться переходити на React Native.
Всім дякую за увагу.
Якщо у когось будуть запитання — радий відповісти, і, звичайно буду дуже вдячний за будь-які відгуки до застосунку.
18 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів