skillsetter.io
2.99K subscribers
326 photos
1 video
258 links
Про кар'єру в IT, запуск і зростання продуктів.
Download Telegram
⚡️ Правильна відповідь: «Протестувати гіпотези»

Так ви зможете визначити проблеми, які заважають продукту зростати, та зрозуміти, як можна вирішити ситуацію — наприклад, краще дослідити аудиторію та переналаштувати рекламу, щоб вона працювала ефективніше.

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

Якщо припинити вкладати прибуток у зростання, це, звісно, дозволить отримувати чистий прибуток спочатку. Але в перспективі — невигідно.

Якщо відкласти масштабування до кращих часів, то можна скоротити витрати ресурсів, але проблему негативної юніт-економіки це не вирішить. До того ж, компанія може бути успішною, навіть якщо не приносить прибуток — наприклад, протягом кількох років працював Amazon.
Початок року — саме час ставити цілі. Здавалося б, можна просто записати все в Trello, обговорити з командою — і готово.

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

Сьогодні ділимося з вами інструкцією з OKR — ефективного методу постановки цілей, який допомагає синхронізувати роботу над проектом та контролювати реалізацію завдань 🤌

🔹 Визначте O (мету, критерії її досягнення) та KR (метрики для оцінки результату);
🔹 Поставте таргет — цільові значення;
🔹 Виявіть проблеми;
🔹 Виберіть потрібні фічі;
🔹 Оцініть ресурси.

У статті ми розібрали OKR на прикладі кейсу та поділилися шаблоном, який допоможе структурувати всі критерії та метрики.
🧠 Задачка: формулюємо user stories

Сьогодні четвер — а значить, час для нового завдання.

Уявіть, що ви працюєте над аппкою для обробки фотографій. Ви отримали вимоги до сервісу від продакт-оунера. Щоб передати їх розробникам, потрібно сформулювати user stories. Так команда розумітиме контекст та цінність завдань.9

User story – це короткий опис завдання. Вона описується з точки зору користувача у форматі: як [роль], я хочу [дія], щоб [ціль].

Наприклад: як продакт, я хочу ставити таски у форматі карток, щоб структурувати роботу команди.

#task | @skillsetter
⚡️ Правильна відповідь

Нам не підходить user story про ретушера. Вона сформульована абстрактно: доступ до функціонала – це базовий параметр програми. Така user story не допоможе в розробці фічі.

User stories про фотографа, ілюстратора та блогера відображають потреби та цілі користувачів. Тож їх можна передати команді.
🧠 Задачка: визначаємо перший страйк

Сьогодні розбираємося з aha-моментом і першим страйком.

Aha-moment це коли користувач розуміє, що продукт для нього цінний. У користувачів кожного товару свій шлях до aha-moment. Один із кроків на цьому шляху — перший страйк. Це ключова взаємодія із продуктом.

Наприклад, перший кол у Google Meet, перша картка з таскою у Trello або перша переглянута серія на Netflix.

Уявіть, що ви запустили продукт — додаток для медитацій. Щоб знайти Aha-moment, потрібно визначити перший страйк — ключову дію.

#task | @skillsetter
Яким може бути перший страйк вашого сервісу?
Anonymous Poll
15%
Реєстрація в аппці
7%
Онбординг
73%
Перше заняття
5%
Перший пройдений курс
⚡️Правильна вiдповiдь: «Перше заняття»

✔️ Саме під час нього користувач уперше «приміряє» продукт на себе.

✖️ Реєстрація в додатку — це не перший страйк, тому що під час неї користувач ще не знайомий з головною функцією продукту.

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

✖️ Перший курс занять — це сукупність ключових дій, але не перший страйк.
🧠 Задачка: ділимо фічу на user stories

Іноді процес розробки фіч буває об'ємним, складним і займає кілька спринтів. У такому разі фічу ділять на кілька кейсів використання — user stories. Потім кожна така user story ділиться на таски.

Наприклад, фічу «додати функцію оплати в продукт» можна розділити на stories за способами оплати: готівкою, карткою та електронними платежами. Після цього для кожної story поставити таски: спроектувати, розробити, протестувати, додати в продукт.

Уявіть, що в продукті потрібно оновити інтерфейс аналітики в особистому кабінеті. Які таски ви поставите команді розробки?

#task | @skillsetter
⚡️ Відповідь на задачку

🔘 Спроектувати новий інтерфейс — найчастіше розробка фічі починається з проектування.

🔘 Написати код нового інтерфейсу — це головний етап розробки.

🔘 Протестувати новий інтерфейс — без цього є ризик зарелізити фічу з багами.

Інші варіанти неправильні:

⚪️ Доопрацювати наявний інтерфейс — ви вже вирішили, що створюватимете новий, тому на це можна не витрачати час.

⚪️ Підготувати рекламну кампанію для оновленого інтерфейсу — цим займаються маркетологи, тому команді розробки таке таски ставити не потрібно.
Можливості вашого дева на парт-таймі: 🪤
Btw, скоро у нас стартує демокурс з аналізу ринку. Будемо вчитися будувати CJM і розбиратися, як в одному продукті втілити запити ринку, інтереси бізнесу (і можливості девiв).
🧠 Задачка: виставляємо естімейти

Естімейт — це оцінка ресурсiв, який необхідний на роботу. Рано чи пізно кожен айтішник стикається з цим: деви оцінюють тривалість розробки, QA — час на тестування, дизи — час підготовки дизайну інтерфейсу.

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

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

#task | @skillsetter
⚡️ Правильна вiдповiдь

◻️ Деталізувати вимоги до фіч
Якщо детально описувати всі юзер-сторі та юзкейси, команда не буде плутатися у вимогах до фіч.

◻️ Розділити фічі на юзер-сторі поменше
Що більші таски — то складніше їх оцінювати. Якщо розбити фічу на частини, команді буде легше оцінити час на реалізацію.

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

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

✖️ Встановити чіткі терміни роботи над проєктом
Якщо на розробку фічей реально потрібно більше часу, то команда просто в принципі не встигне до дедлайну. Замість обмеження часу краще попрацювати над точністю естімейтів.
Іноді правильно оцінити таски заважають когнітивнi спотворення — помилки мислення, які з'являються через те, що мозок намагається спростити процес обробки інформації. Тому ми часто ухвалюємо рішення на основі забобонів, неправильних інтерпретацій і минулого досвіду.

Існує багато когнітивних спотворень, але сьогодні ми обговоримо тільки ті, які стоять на шляху до точних естiмейтів.

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

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

Ефект Даннінга-Крюгера
Це схильність людей неправильно оцінювати свої здібності. З одного боку ми схильні переоцінювати свої знання і навички, недооцінювати недоліки. З іншого — експерти з глибокими знаннями у своїй галузі часто принижують власні здібності.
Робочий настрій після понеділкового статус-репорту be like