Код працює, продукт – ні: яку проблему ігнорують продуктові команди і як її розв’язати

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

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

Із цих причин мені близький продуктово-орієнтований підхід (product-oriented mobile engineering). Для мене він став не просто новою етикеткою для ролі інженера, а практичним способом організувати роботу мобільної команди. У цій колонці я хочу показати, що саме ховається за цим терміном, чим продуктово-орієнтована мобільна розробка відрізняється від традиційної і чому вона, з мого досвіду, допомагає там, де класичний підхід часто не спрацьовує: у створенні реальної користі для користувача.

Хто такий product-oriented engineer

Для мене продуктово-орієнтований інженер (product-oriented engineer) – це насамперед інший спосіб мислення, а не окрема посада.

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

Проблемою виникає тоді, коли така команда робить технічне рішення самоціллю, а не засобом досягнення мети. Коли питання «чи достатньо красиво ми це реалізували?» стає раніше ніж «чи розв’язуває реальну проблему користувача?».

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

Важливо: я не вважаю, що один тип інженера «кращий» за інший – командам потрібні обидва. Але в мобільному середовищі, де в користувача коротка увага, а фідбек з’являється швидко, саме продуктово-орієнтоване мислення допомагає не просто випускати функції, а будувати продукт, який вчиться. Саме так працюють найсильніші команди: вони разом дивляться записи інтерв’ю з користувачами, аналізують поведінкові дані, напряму говорять із користувачами і вже потім ухвалюють рішення про зміни.

Як я реалізую продуктово-орієнтований підхід на практиці

У своїй роботі я із часом звів продуктово-орієнтований підхід до трьох простих питань:

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

Я починаю не з екранів, а з користувача

Я люблю починати з такого тесту: коли команда запускає нову ініціативу, вона в першу чергу думає про API, SDK, архітектуру й екрани чи про конкретного користувача в конкретний момент, який намагається виконати певну дію?

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

Саме через це мені близький підхід Working Backwards від Amazon: спочатку уяви бажаний досвід, а вже потім переходь до реалізації. Він полягає в таких запитаннях: яку проблему вирішує ця функція? Для кого вона? Як зрозуміти, чи вона справді працює? Лише коли є чіткі відповіді на ці питання, варто переходити до SDK і технічних деталей.

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

Висновок тут простий: якщо команда не може коротко й чітко пояснити, яку поведінку вона хоче змінити й навіщо, процес майже напевно йде не з того кінця.

Що змінюється, коли ви дивитесь на продукт очима користувача

Ще один важливий момент, який я зрозумів у мобільних продуктах: написання коду – це лише частина роботи. Часто розробник взагалі не бачить, як користувач взаємодіє з продуктом і, як результат, починає оптимізовувати власні припущення, а не реальні проблеми.

Через це я вважаю критично важливим, щоб розробники були там, де користувача можна побачити напряму: на інтерв’ю, на юзабіліті-тестах, у зверненнях до підтримки, у відгуках в App Store і Google Play, у записах сесій, у порівнянні з конкурентами. Для мене це не «додаткова опція», а частина нормальної продуктової роботи.

Якось я працював над проєктом, у якому в мобільному застосунку був цілком логічний процес реєстрації – зрозуміла послідовність кроків, обґрунтовані поля, продуманий сценарій. Але в записі фідбек-сесій стало видно, що користувачі масово зупиняються на довгій формі, яку потрібно заповнити з маленького екрана, що було просто незручно. Проблема була не в коді – він працював бездоганно, але от створити хороший досвід він не міг. Після аналізу ситуації ми вирішили скоротити кількість полів, перенести частину інформації на пізніший етап і додати автозаповнення там, де можливо. Результат – значно менша кількість незавершених реєстрацій і вищі оцінки від користувачів.

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

Чому дані мають бути основою рішень

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

Звісно, інтуїції є місце в розробці, але прийняття рішень не має обмежуватися нею. Продуктове мислення працює там, де команда домовляється, який саме результат важливий для неї: активація, утримання користувача, час до першої користі, стабільність, ANR і так далі. Лише коли це сформульовано, команда знатиме, на що звертати увагу й що ставити в пріоритет у подальших ітераціях. На практиці це часто має такий вигляд: інженер пропонує зміну і формулює її не як «це зробить код чистішим», а як «це зменшить відтік у ключовому сценарії» або «це скоротить час до першої корисної дії». Я бачив, як ця проста зміна парадигми змінювала й дискусію навколо продукту, і його результативність.

Моя порада тут проста: кожна суттєва зміна має бути прив’язана до гіпотези. Не абстрактно, а буквально – що саме має покращитися, за яким сигналом ми це побачимо і якою буде ціна помилки, якщо гіпотеза не підтвердиться.

Чому розробка не повинна бути лише виконанням тікетів

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

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

Тому для мене продуктово-орієнтована розробка – це коли мобільний інженер не просто «бере задачу», а бере участь у формулюванні рішення. Він може допомогти розкласти нечітку проблему (наприклад, слабкий онбординг) на гіпотези, запропонувати кілька варіантів перевірки, подумати про інструментування, подивитися на результат і разом із командою запропонувати наступну ітерацію.

Продакт-менеджер при цьому не зникає і не втрачає своєї ролі. Але відповідальність за результат стає більш спільною. І з мого досвіду саме в цей момент цикл навчання в продукті починає прискорюватися.

Перешкоди на шляху до продуктово-орієнтованої розробки

Дуже часто я помічав, що команди, які мають навички, необхідні для продуктово-орієнтованої розробки, не можуть зробити цей перехід. Основна проблема – звички й те, як важко їх змінити.

Дискомфорт від невизначеності й технічний перфекціонізм

Я часто бачив, як команди чекають на ідеальний PRD: усі сценарії описані, усі екрани затверджені, на всі питання знайдені відповіді. Цей підхід працює, адже він дає відчуття контролю, але в мобільному продукті реальність часто змінюється швидше, ніж команда встигає написати остаточний документ.

Тому я все більше схиляюся до коротких PR/FAQ-документів замість громіздких специфікацій. Якщо команда може стисло зафіксувати проблему, обіцянку користувачу, критерій успіху, основні ризики й наступні кроки, цього зазвичай достатньо, щоби почати перевірку. З мого досвіду один-два тижні на MVP майже завжди дають більше користі, ніж квартал, витрачений на «фінальне» рішення, яке до релізу вже частково застаріває.

Обмежений доступ до користувачів і реального фідбеку

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

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

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

Плутанина між активністю і результатом

Одна з найнебезпечніших пасток – плутати» ми щось випустили» з «ми щось покращили». У мобільних командах це трапляється постійно: випускається багато змін, релізи виходять, список задач рухається, але ніхто не може впевнено сказати, що саме змінилося в поведінці користувача.

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

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

Надмірна прив’язаність до «ідеальних» рішень

Ще одна знайома багатьом пастка, яку я вже згадував – закоханість у «правильну» архітектуру. У мобільній розробці це часто призводить до довгого рефакторингу, повної зміни SDK або масштабного редизайну, через який реліз відкладається на довгі місяці. Безперечно, код стане чистішим, але час втрачено, а команда все одно не знає, чи стало від цього краще користувачам.

З мого досвіду. значно краще працюють невеликі ставки із чіткою користю для навчання. Я питаю себе й команду: «Яка найменша зміна допоможе підтвердити або спростувати гіпотезу?», «Що ми свідомо не будемо робити зараз і чому?» «Де проходить межа між необхідною технічною якістю і зайвим перфекціонізмом?»

Ще одна корисна практика – резервувати 10–15% загального часу розробки на рефакторинг. Продуктове мислення не означає, що потрібно забувати про якість коду. Воно лише означає, що технічна якість має служити продукту, а не бути самоціллю.

Яким я бачу продуктово-орієнтованого мобільного інженера

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

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

Agile, Lean, MVP, A/B-тестування – усе це добре працює в мобільній розробці, якщо використовувати їх за призначенням. Я не раз переконувався, що процес має захищати експерименти, а не душити їх. Щойно церемонії стають важливішими за навчання, команда знову повертається до формального виконання задач без реального результату.

Один приклад із практики

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

У чому була проблема

Я працював із застосунком для масового користувача, де під час онбордингу нових користувачів їх просили одразу надати кілька системних дозволів: на сповіщення, камеру, геолокацію та ще кілька речей. Коли ми подивилися на аналітику, проблема стала очевидною: частина людей відпадала саме на цьому етапі. Інші проходили далі, але відмовляли в доступі й пізніше стикалися з «поламаним» або просто незрозумілим досвідом, адже ключові функції не працювали так, як вони очікували.

Картина стала яснішою, коли ми підключили записи сесій і юзабіліті-тестів – користувачі не розуміли, навіщо застосунок просить ці дозволи так рано. Запити з’являлися раптово, без контексту; повернутися до цього сценарію потім було складно.

З погляду користувача онбординг виглядав нав’язливим і непрозорим. З погляду бізнесу це означало нижчу активацію і більше звернень у підтримку зі скаргами на те, що «функція не працює».

Яку мету ми собі поставили і які мали обмеження

Задача була максимально практичною: підвищити успішну активацію ключових функцій, не збільшуючи тривалість онбордингу й не створюючи додаткової нестабільності. Щоб досягти цього, ми не стали одразу перебудовувати весь онбординг – навпаки, ми спеціально звузили задачу.

Щоб не розпорошуватися, ми одразу обрали невеликий набір метрик. Основною метрикою стала активація першої ключової дії. Додатково ми дивилися на частку користувачів, які давали дозвіл на перший запит, тривалість онбордингу, частоту збоїв, ANR і помилки, пов’язані з дозволами.

Саме така рамка допомогла нам не скотитися в косметичне «покращення UI», а тримати фокус на поведінці користувача.

Як ми до цього підійшли

Ми підійшли до дозволів не як до технічної формальності платформи, а як до продуктової проблеми. Усі зміни були саме на стороні клієнта і вносилися поступово.

Просили доступ лише в той момент, коли він був справді потрібен

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

Продумали сценарій не тільки на випадок згоди, а й на випадок відмови

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

Додали аналітику в ключових точках рішення

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

Усе це ми випускали через feature flags і розгортали поступово. Тексти, таймінг і логіку повторної спроби ми коригували в кілька ітерацій уже на основі реального використання.

Який це дало результат

Такий підхід дав досить чіткий ефект:

• активація першої ключової функції зросла приблизно на 4–6% відносно базового рівня (особливо серед користувачів, які раніше відмовляли в дозволах ще під час онбордингу);
• частка наданих дозволів із першого запиту зросла приблизно на 6–8%, хоча сам запит тепер з’являвся пізніше в сценарії;
• час проходження онбордингу при цьому залишився стабільним: зміни були в межах ±1–2% від вихідного рівня;
• кількість користувачів, які потрапляли в безвихідний сценарій через те, що не дали необхідні дозволи, зменшилася приблизно на 8–12% завдяки зрозумілішим шляхам відновлення і повторним спробам;
• звернення в підтримку, пов’язані з відсутніми дозволами, знизилися приблизно на 10–15% упродовж наступного циклу релізів.

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

Чому цей підхід важливий не лише для інженера, а і для компанії

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

Якщо організація хоче, щоб команди відповідали за результат, вона має наймати й розвивати людей, яким це цікаво. Вона має оцінювати не лише обсяг виконаної роботи або «чистоту» архітектури, а і вплив на навчання і здатність працювати разом із продуктом і дизайном. Щоб цей підхід працював, компанія має вкладатися в такі базові речі:

• надійна аналітика;
• записи сесій;
• feature flags;
• інструменти для експериментів.

Ці речі допомагають перебудувати підхід до розробки й поставити в його центр продукт і користувача, а не лише чистоту коду.

І ще одна важлива річ, яку я зрозумів на практиці: продуктове мислення неможливе без автономії. Якщо будь-яка зміна проходить нескінченні узгодження і кожен експеримент вимагає місяців погоджень, жодна «правильна» культура не спрацює. Продуктово-орієнтована розробка дає результат тільки тоді, коли команда має реальні дані і працює на їхній основі.

Висновок

Мій досвід неодноразово доводив, що найсильніші мобільні продукти – не ті, де команда просто пише ідеальний код, а ті, де команда постійно перевіряє, чи змінює її робота щось для користувача.

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

І саме в цьому я сьогодні бачу головну різницю між командами, які просто випускають функції, і командами, які справді будують продукт.