Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Welcome changes без нервового тиску. Про роботу з «правками», зворотнім зв’язком, фідбеком

Привіт!

Я Катя і я ПМ. За свій досвід зустрічала різні ситуації та емоції з приводу роботи з «правками», зворотнім зв’язком, фідбеком. Частково моє резюме на тему нижче.

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

Доволі часто чула це словосполучення «welcome changes» (на курсі для PMP , обрала за порадою dou.ua/forums/topic/35772 ), і періодично аж дьоргає. Це, звичайно, про емоції. Коли включаю мозок і аналізую свій досвід можу виділити 2 ключові аспекти, налаштувавши які можна витиснути максимум користі від роботи зі змінами, зворотнім зв’язком. Вони:

  • якість
  • кількість
  • своєчасність

Якість.

Це про форму та структуру. На приклад, якщо фідбек сипеться в слак 1000+ окремими повідомленнями або простирадлом баги в суміш з ідеями. І ще краще якщо декільком членам команди одночасно. Що маємо: збитий фокус та метушню. Вирішується доволі просто і частіше ітеративно можна довести до цукерки. Починати вам все ручками і активною комунікацією (дзвінками, аргументацією і пропозицією оптимізації роботи, побудовою shared vision — див. детальніше тут). Далі навчати ваших стейкхолдерів, потенційно вводити форми для зворотнього зв’язку, можна одразу в вашу трекінг систему. Так, це може привести до затримок, але найважливіше все одно вам будуть писати в DM, вам залишиться тільки тримати баланс та не «закривати рота» зворотньому зв’язку, тримати приємну «гучність». І важливо тут позитивне підкріплення, тобто показати що налаштована процедура дає передбачуваний результат — вибудовувати очікування та зустрічати їх своєчасними поставками опрацьованого зворотнього зв’язку. Іншими словами, реалізовувати запити стекхолдерів, звичайно якщо вони дійсно в пріорітеті.

Кількість.

Ми часткого подивились на цей аспект в «якості» і зрозуміло що робити коли фідбеку багато — структурувати, групувати, пріорітезувати і оце все. Але що робити якщо зворотнього зв’язку немає? Можна звичайно порадіти, думаючи що все ок і як очікувалось. Але...ні. Скоріш за все це питання часу, його нестачі і прилетить весь спектр фідбеку в найнеприємніший момент. Ще варіант що нічого не зрозуміло. Наприклад, ви працюєте з нетехнічним замовником і йому/їй просто не виходить поставити той ваш застосунок і вин/вона не питає бо не хоче відволікати команду. Іншими словами, є складність в процесі і ваша задача її мінімізувати. Інструкції і тп — то все на ваш розсуд. Але комунікація і тісна робота із замовником, стейкхолдерами то маст. Тобто провести зустріч, розмову в месенджері (взалежності від досвіду співпраці), провести «за руку». NB: частково вирішується демо сесіями і тп. І обов’язково аргументувати важливість зворотнього зв‘язку і коли ви його чекаєте, чому саме тоді буде найкорисніше і що ви будете робити якщо не отримаєте в терміни, чому погано для продукту отримати в інший час, тп. От ми підійшли до своєчасності.

Своєчасність.

Залежить від фази продукту в якій ви зараз.

Якщо ви на фестивалі он-сайт (або софт-лонч продукту), де працює ваша система то зворотній зв’язок можна і варто приймати 24/7. Бо ви якраз в самому топі користі. Але не слід забувати про обробку. Втілювати всі запити від ваших користувачів вам скоріш за все не вистачить часу. Тому беремо найчастіші скарги/побажання, вибираємо з них easy-win (мінімум витрат максимум цінності) та тестуємо в полі. Інші складаємо в беклог для подальшого більш глибокого аналізу.

Інша ситуація, коли ви віддали систему ключовим стейкхолдерам і чекали на зворотній звязок протягом узгоджених термінів, але вони змогли надати його тільки тоді коли команда вже в іншому контексті (модуль) та замовнику обов’язково дуже болить і пече. Умовно, подивився додаток в день перед пітчем потенційним клієнтам і все не то. Як бути? Я не буду тут давати оцінку вашій роботі. Але привітаю, спрацював ризик погано проговорених=почутих залежностей, не зустрітих очікувань. Тут, по-перше, повернути всіх учасників до спільного бачення, пояснити чому так сталось, включити емпатію і далі час перегляду беклогу. Також не забути синхронізувати по часових та бюджетних очікуваннях; перемикання контекстів на ходу — це удар по витратах (часових в першу чергу), команда не гумова і все встигнути не може бути реалістичною метою, обіцяти героїзм замовнику не варто. Також не забудьте включити цю ситуацію в перелік тем-кандидатів для ретроспективи.

Dont’s

  • Не спілкуйтесь з стейкхолдерами посиланнями на гугл-форми чи інші інструменти для організації збору зворотнього зв’язку.
  • Не приймайте зворотній зв’язок 24/7, не впевнившись в справжності намірів. Так ви можете накликати бардак, купу задач в прогресі, постійне перемикання контекстів, які в свою чергу ведуть до дизморалі та «прогуляних» таймланів.
  • Не приймайте зворотній зв’язок не проаналізувавши поточний фокус команди/фазу розробки
  • Не приймайте зворотній зв’язок не опрацювавши його хоча б мінімально. Ви не копі-пейстей зі слаку/імейлу в jira. Думай(те)

DO:

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

Сподобалось що прочитали, запрошую читати ще — короткі історії та корисні «шпаргалки» тут : життєво про проєктний менеджмент

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі