«Юзер платить не за красивий код, а за вирішення його проблеми», або Чому бізнесорієнтованість розробника важлива
Привіт! Я Руслан Газанфаров, Android-розробник в продуктовій компанії Universe, яка спеціалізується на створенні утиліт для iOS та Android-застосунків. Більше як рік тому я доєднався до команди, щоб перезапустити перший експериментальний застосунок на нову для компанії операційну систему, і вже через 9 місяців у нас було понад два мільйони завантажень.
У цьому «блозі-рефлексії» я ділюся своїм досвідом і трансформацією підходів до створення продукту та ролі розробника в бізнесі. Текст буде корисний технічним спеціалістам, які хочуть працювати в бізнес-орієнтованих компаніях, які інколи жертвують «якісним» кодом, а також тим спеціалістам, хто хоче зрозуміти цей майндсет, а не створювати «фічі для фічей».
Досвід у розробці та повернення до базових принципів
На початку літа 2022 року я знаходився у Львові, працював більше ніж півтора роки над застосунком Yakaboo і відповідав за Back-end та Android складові продукту. У нас були круті результати: за три місяці застосунок виріс майже у 100 разів. Проте я починав дивитися в майбутнє і думав, що може мене здивувати після шести років кар’єри розробника, адже побачив я достатньо:
- роздуті ідеї стартапів, для яких ми писали застосунки в аутсорсі, і які в 95% випадках закривалися через пів року;
- CRM-платформи, яким чомусь різко захотілося створити мобільну версію продукту, але ними ніхто не користувався;
- застосунки для водіїв таксі та кур’єрів доставки;
- купу різних тематичних застосунків, з яких до сьогодні працює 10%.
Рефлексуючи про свій досвід, зловив себе на думці, що індустрія мобільної розробки відійшла далеко від тих принципів, які були закладені у перших версіях App Store та Google Play. А саме:
- Знайти базову потребу, яка є у великої кількості людей.
- Зробити застосунок, який цю проблему вирішить.
- Заробити грошей від вдячних користувачів, які більше не мають цього «головного болю».
Тому я взяв за основу ці базові принципи та розпочав пошуки нового місця роботи. За кілька тижнів співбесід я потрапив в теперішню команду і на момент отримання оферу мені здавалося: «Ну що там писати такого в цих застосунках для сканування документів, це ж просто робота з камерою та файлами, так?»
«Треба тестувати». Про культуру компанії навіть у розробці
Коли я долучився до команди, застосунок на Android вже існував. У вас може виникнути питання: «Чому в продуктовій компанії, яка є лідером в ніші сканерів на iOS, продукт на Android писали на аутстафі?». Все дуже просто — основне гасло в команді «треба тестувати». А тестувати, як правило, треба дешево і швидко, тому я у спадок отримав застосунок, який вже окупився і мав зведену unit-економіку.
З часом я зрозумів, що такий підхід дозволяє команді швидко ухвалювати рішення, базуючись на даних, та не витрачати зайві ресурси (час команди розробки та маркетингу) та фінанси в моменті. Тобто доречність моєї присутності в команді була вирішена ще до моєї появи, а ключовою задачею на випробувальний термін було перезапустити застосунок.
На цьому моменті я одразу оцінив відмінність підходу до запуску продукту від того, що я бачив останні 6 років. Спочатку була перевірена гіпотеза необхідності його існування, а вже потім створювалась окрема команда для його розвитку, а не навпаки. А той аргумент, що застосунок, як мені здавалося, був написаний не за останніми тенденціями в розробці, був нівельований іншим фактом: на той момент застосунком вже користувалися понад 200 000 людей, а якась частка з них вже платила. Адже користувач голосує грошима не за красивий код, який написав розробник, а за те, які потреби вирішує продукт.
Зрозуміти культуру компанії мені допомогло перебування в тісному контакті з командою. Тоді чи не вперше з початку пандемії я зустрів людей, які приходять в офіс не тому, що треба, а тому, що в офісі кайфово. Так мої кілька днів в Києві перетворилися на тиждень. Не міг відмовити собі в задоволенні провести ще кілька літніх сонячних днів на Подолі за рефакторингом код-бази та переведенням застосунку на актуальніші бібліотеки та інструменти.
Робота зі старими звичками
Після кількох років в аутсорсі, де, здавалося, усе найновітніше та свіженьке несуть в продукт для затягування процесу розробки та підтримки рівня захвату розробника, мені довелося добряче попрацювати над старими звичками.
Тож переписував я не тільки шар логіки застосунку, пов’язаної з бізнесом, а також все, що стосувалося бази даних та нетворкінгу — їх я переніс в окремі модулі. Трішки переробив навігацію, оновив бібліотеки, базово пробігся по всіх екранах та доклав максимум зусиль, щоб працювати над нововведеннями було приємно.
Результат, на який пішло трішки більше як три тижні з тестуванням, мав не тільки гарне відображення в крашлітиці, але і приємні покращення метрик в аналітиці. Але те, що мені, на перший погляд, здавалося маленьким застосунком, зовсім не виявилося легкою роботою.
Продукт за кількістю функціональностей та екранів здається невеличким, а кількість користувачів, які потенційно можуть бути його аудиторією, є мільйонною. Кожним екраном та кнопкою користуються десятки тисяч юзерів по всьому світу на такій кількості різних девайсів, що відвалитися може будь-що і будь-де.
Після ретельного тестування почалася велика кількість релізів, пов’язаних з основним підходом компанії. Що ми тільки не тестували:
- розпізнавання рамок документа на екрані камери;
- десяток ABC та АВСD тестів на екранах продажу;
- автоматичний фільтр документа, який прибирав ефект зімʼятого паперу та висвітлював текст;
- додаткове кешування документів, бо як виявилось, ОреnCV неймовірно вибагливий фреймворк навіть для останніх флагманів;
- світлу тему додатка, яка виявилась важливішою для користувачів Android, ніж iOS;
- купу дрібних поліпшень «життя» користувачів, про які вони розповіли нам під час досліджень.
Найцікавішим для мене виявився той факт, що більшість продуктових тестів, які за описом, здавалося, будуть успішними — фейлилися. 80% тестів у нашому сканері не принесли статистично значущих результатів, як фінансових, так і продуктових. Для себе відмітив ще одну річ: успішний продукт не можна побудувати, не опираючись на дані про його фактичне використання, та не генеруючи десятки гіпотез на місяць.
Навіть геніальна, на перший погляд, ідея, після втілення в продукті може не скласти іспит даними. Тому обов’язково треба тестувати, і бажано робити це швидко, іноді нехтуючи тим чи іншим принципом SOLID, не звернувши ретельної уваги на архітектуру, та пропускаючи десь стороною Domain Driven Design з Clean Architecture і всіма іншими модними методологіями у світі розробки.
Бо швидше за все код, написаний сьогодні в динамічному продукті, через місяць треба буде утилізувати, обмінявши його на важливі знання та дані.
Поради для бізнес-орієнтованих розробників
Тож якщо ви так само як і я вирішили попрацювати в data-driven команді, яка працює над продуктом для мільйонної аудиторії, або хочете стати більш бізнесорієнтованим розробником, то маю для вас невеличкий To-do лист:
- Прокачати навички стратегічного мислення. Це дозволить мати повне розуміння бізнес-процесів, а не вирішувати тільки конкретну проблему певною технологією.
- Познайомитися ближче з базовими метриками продукту та unit-економікою, навчитись розпізнавати LTV, CPI, CAC, MRR, ARR, ARPPU, ROI, ROMI.
- Вивчити фундамент A/B тестування, а саме як після проведеного тесту команда буде оцінювати його успіх або провал та як потім реалізувати тест в продукті — це додатковий плюс.
- Дивитись більше на продукт як користувач, а не розробник.
- Навчіться думати не класними фічами, а користувацькими потребами та «болями».
А моєю задачею на наступні кілька років буде знаходити баланс між усіма новітніми інструментами у світі розробки, при цьому оперувати ними ближче до рівня контрольованого хаоса, іноді імпровізуючи, а іноді працюючи чітко по нотах. Коли все це сходиться разом — виходить прекрасна музика.
Найкращі коментарі пропустити