⚡️ Правильна відповідь

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

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

🧠 Задачка: визначаємо перший страйк

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

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

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

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

#task | @skillsetter

⚡️Правильна в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