Project Management Academy

Як давати негативний фідбек
⠀
Одне з найскладніших в роботі менеджера - давати негативний фідбек.
⠀
З позитивним все легко і просто, адже хвалити людей завжди приємно. А критикувати якось не комільфо, таких розмов хочеться уникнути. Мовляв, звідки взагалі у мене право говорити людині як ій жити?
⠀
Зазвичай фідбек дають на зустрічах 1-1. Щоб співробітник прислухався, треба доносити проблему максимально точно: ти не вклався в оцінку -> посунулись терміни -> замовник незадоволений. Якщо говорити загальними фразами і напівнатяками, є великий шанс, що тебе не почують.
⠀
З іншого боку, важливо не зачепити почуття людини. Щоб працівнику не здалося, що його вичитують як школяра за невиконану домашку 🤓.
⠀
Є різні техніки, які допомагають впоратися з цим балансом, наприклад, Burger 🍔 або BOFF.
⠀
Мені сподобалися принципи, які використовує Нетфлікс, тому що вони короткі і прості. Всього 2 поради для тих, хто дає фідбек і 2 для приймаючої сторони:
⠀
1. Прагни допомогти. Критикуй з щирим бажанням зробити світ кращим.
2. Пропонуй конкретні кроки. Пояснюй, що саме людина зробила не так, який був негативний ефект і як його можна було уникнути.
3. Будь вдячний за зворотній зв'язок. Коли чуєш негатив, твоя природна реакція - почати виправдовуватися і захищатися. Її треба побороти і згадати про пункт 1.
4. Не всі поради обов'язково правильні і такі що треба 10000% фолловити. Деякі з них можуть бути не актуальні і тільки тобі вирішувати до яких прислухатися.

Тривалість спринта
⠀
Коли стартуєш новий проект, потрібно домовитися якою буде довжина спринта. Її рідко змінюють по ходу проекту, тому рішення, воістину, історичне.
⠀
Скільки ж вибрати? Скрам пропонує будь-який термін, аж до 1 місяця. Радять все ж сильно не затягувати, щоб якомога частіше показувати користувачам нові фічі і отримувати фідбек.
⠀
Зазвичай спринти роблять кратним тижням, щоб починати і закінчувати в один і той же день. Виходять такі варіанти:
⠀
- 1 тиждень;
- 2 тижні;
- 3 тижні;
- 4 тижні;
⠀
Вибираючи тривалість, спирайтеся на кількість кроків в definition of done. Чим їх менше, тим швидше команда може випускати завдання, і тим менша довжина спринту потрібна.
⠀
Наприклад, у нас зараз мобільний проект без бекенда, тому наш спринт всього 7 днів.
⠀
А в проектах, де є бекенд і фронтенд зазвичай вибирають 2 тижні. Це найпопулярніший варіант, який ви знайдете у двох команд з трьох. Стільки досить, щоб встигнути випустити значуще оновлення, і одночасно не скотитися в вотерфолл.

Приклад оцінки фічі
Уявіть, що ведете проект а-ля месенджер.Замовник надсилає вам такий лист:
📨Хочу фічу, щоб можна було відправляти фото в чат. Скільки буде коштувати?
Давайте розберемось, що робити.
Якщо на проекті є BA, просимо його розписати юзкейси. Якщо немає - пишемо самі, приблизно так:
📌 отримати доступ до галереї;
📌 вибрати фото + превью перед відправкою;
📌 завантажити фото в чат;
📌 подивитися відправлене фото;
Беремо ці юзкейси і йдемо затверджувати їх з замовником.
І обговорюємо інші кейси, які можна придумати для цієї фічі - відправка відео, стиснення, історія, редагування перед відправкою і т.п. Чим більше назбираємо зараз, тим менше шанс почути на приймання "ой, а де стиснення? Я думав, це мається на увазі ...".
⠀
Щоб не роздувати Скоуп, пропонуємо всі необов'язкові кейси зробити потім, у фазі 2. Раптом фіча взагалі не зайде?
⠀
На цьому етапі корисно дивитися, як аналогічні фічі працюють у конкурентів 👀.
⠀
Коли кейси затверджені, йдемо до команди оцінювати. Збираємо всіх zoom і розповідаємо про фічу.
⠀
Mobile developers дивляться на вимоги і кажуть, що на розробку потрібно 80 годин. Бекенд просить 40. Дизайнеру знадобиться 40 на створення екранів. В сумі 160.
⠀
Закладаємо 30% на тестування, 20% на стабілізацію, 10% на комунікації + 10% на себе. Зверху накидаємо 10% ризиків і отримуємо 140 годин.
⠀
За Рейт 40 в годину виходить $ 12,000. Але це ще не все.
⠀
Фотографії потрібно десь зберігати, для цього знадобиться окремий сервер.
Замовник каже, що фічею буде користуватися кожен п'ятий користувач, завантажуючи десь 100МБ фоток на місяць.
⠀
Наостанок, прикинемо таймлайн 📅.
Бекенд може почати першим, паралельно будемо малювати дизайн. За оцінкою команди це тиждень, але додамо 3 дня на обговорення, затвердження макетів і ризики.
Мобайл тіма просила 2 тижні, але з тестуванням і стабілізацією, розробка займе всі три.
Після першого тижня обов'язково зробимо демо, щоб уникнути сюрпризів перед релізом. Закладаємо день на делівері і ще 2 на ризики.
У підсумку отримуємо 5 тижнів.
Оцінка готова.Ставимо в копію Sales manager (Account manager) і відправляємо замовникові.

Результати ретро в беклог

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

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

Прикольно іноді зайти в ретро річної давності і розчулитися з того, як молоді ми були і які прості речі нас беспокоіли. За таким замітки добре видно як матереет проект і команда.