don't move my cheese avatar

Max Ischenko

Спочатку ДОУ, тепер Djinni. Keep going & підтримуй ЗСУ.

Проблема vs Рішення

Уявіть, що ви робите планування задач з командою.

Тиждень, спрінт, квартал–неважливо.

У вас є різні ідеї, які ви обговорюєте і визначаєте пріоритети.

На якому рівні йде це обговорення?

Варіант 1:
Спростити форму реєстрації, покращити сторінку пошука, додати можливість отримувати сповіщення на імейл.

Варіант 2:
У нас багато людей відвалюється в процесі реєстрації, ми отримуємо скарги що пошук не працює, у нас низький retention.

З мого досвіду, більшість планувань йде за варіантом 1 – обговорення на рівні задач, замість 2 – обговорення проблем.

Хтось навіть скаже, що між цими варіантами різниці немає, бо все одно планувати й виконувати команда буде задачі, а не “проблеми”.

Але різниця є і вона для мене принципова.

Варіант 1 це класична feature factory. У нас є Х задач для “планування” і Y “бюджету” у вигляді годин, грошей чи сторі пойнтів. Задача команди або ПМ: обрати найкращий пул задач з урахуванням можливих обмежень чи залежностей.

Здається чи не всі так і працюють, то в чому проблема?

Проблема в тому, що у команди немає відповідальності за результат, є лише за delivery. “Ось що ми пообіцяли зробити, ось що ми зробили, ми молодці (або ні)”.

Але бізнес ніколи не думає в розмірі задач, він вирішує проблеми. Навіть якщо ви агенція або аутсорс, ваш замовник так не думає. Йому не потрібні “задачі”, йому потрібно вирішення конкретної бізнес-проблеми.

Варіант 2 це планування зрозумілою для бізнеса мовою. Але навіть більше важливо – передача команді відповідальності за результат.

Повертаючись до прикладів на початку.

Моя проблема: поганий retention в продукті.
Як я дізнаюся що ми її вирішили: 5d retention for new sign-ups goes from 12% to 25%.

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

Що б це не було, рішення шукає команда.

Задача бізнеса: описати внятно свої проблеми, крітерії успіху (вирішення) та пріоритети. Решта за командою.

Give your team problems to solve, not things to do.

Отримуй нові пости на пошту

Pinned Comments

Це залежить від складу команди та від того, хто ще залучений у процес, окрім самої команди. В обох випадках відповідальність за результат лежить на команді, просто в першому випадку результатом є розробка того, що замовлено. У цьому процесі також можуть брати участь продакт-менеджери, маркетологи та інші зацікавлені сторони. Якщо команда одна - усе виглядає зрозуміло. Але якщо є, наприклад, команда маркетингу й команда розробки, то як визначити, хто створив і хто вирішив проблему? Можливо, змінилося джерело трафіку, яке цю проблему й спричинило. Важливо також розуміти, чи має команда потрібні інструменти та чи бачить ширший контекст, аби знаходити справжні причини проблем. Але я вважаю цілком нормальним визначати пріоритети для команди. Наприклад, зараз пріоритетом може бути боротьба з retention, і тоді команда/PO враховуватимуть це під час планування та обиратимуть завдання, які потенційно здатні виправити ситуацію.
Pavlo
August 17, 2025
Розумію що хочеш побудувати повноцінний незалежний конвеєр. В такому випадку залучати розробників треба на етап аналізу і перевірки результатів через метрики, і будувати ті самі метрики. Для цього треба їх цьому вчити і вести до цього. Якщо прибрати питання скейлабіліті, а говорити за невеличкі команди/компанії то в ідеалі кожен розробник повинен з початку займатися пошуком проблеми, аналізом, обговоренням приорітету (та бюджету), імплементацією, розробкою і перевіркою їх після цього. Як я розумію супер успішні стартапи з маленькими командами саме так і працюють.
zviryatko
August 17, 2025
Мені чомусь нагадало оцей виступ Тарантіно, може я притягнув за вуха, але там, типу, про якісну передачу ідей, а не про казати, що кому робити: https://youtu.be/nQkZO3YkXXU
Антон Поляков
August 18, 2025
Одна з моїх найулюбленіших цитат: "Закохуйтесь у проблеми, а не їх рішення". З Inspired, здається. В якийсь момент ми дозріли до цього підходу, але тут важливо бути чесним і не підганяти проблеми під ідеї.
Стас Демяник
August 18, 2025

Share your thoughts

Comments are private—unless pinned by me.