Як правильно критикувати розробників і дизайнерів: 4 ради від працівника Facebook



У наших блогах Хабре і Мегамозку ми багато пишемо про побудову хмарного сервісу 1cloud, досвід по роботі з інфраструктурою різних компаній і перспективних підходів до управління ІТ-проектами. Ми вже обговорювали тему того, які завдання варто давати розробникам на співбесідах, а сьогодні мова піде про те, як правильно критикувати програмістів і дизайнерів.

Продакт-дизайнер Facebook Таннер Крістенсен в блозі на Medium рассказаляк в найбільшій світовій соцмережі побудований процес «розбору польотів» і отримання зворотного зв'язку від колег-розробників або дизайнерів в ході проекту. Ми представляємо вашій увазі головні думки цього матеріалу.

За словами Крістенсена, коли він тільки влаштувався на роботу в Facebook, його насторожували існували там щотижневі двогодинні наради, цілком присвячені критиці тих або інших рішень або дій в ході проекту. Дизайнеру здавалося, що такі зустрічі — це марна трата часу. Попередній досвід підказував йому, що процес критичного обговорення часто зводиться до двох речей:

  • ніхто не розкриває карти про своїх поточних розробках, тому що боїться чужої думки;
  • ніхто не розуміє цілей таких заходів, тому всі зазвичай закінчується просторікуванням і взаємними нападками.
Однак у Facebook все було влаштовано інакше. Ніхто не просував свої інтереси і не лаяв колег даремно. Адекватної критики було набагато більше.

Крістенсен каже, що інженери і дизайнери соцмережі застосовували методи, взяті з книги Джареда Спула «Moving from Critical Review to Critique». Такий підхід виявився дуже ефективним. І ось як проходили розбори польотів за описаною схемою.

Розподіл ролей



На думку Крістенсена, перше, що варто запам'ятати, — у кожного на «годині критики» повинна бути своя чітка роль. Зазвичай таких ролей три: доповідач, аудиторія, модератор.

Функції доповідача:

  • коротко і ємко пояснити суть проблеми чи ідеї, над якою працює команда;
  • представити розробку або конкретне рішення, які вони обрали.
Суть не в тому, щоб робити якісну презентацію з картинками або обґрунтувати витрачені зусилля. Кожному виступаючому дається 15-30 хвилин, протягом яких вони викладають сам процес розробки.

Аудиторія складається з будь-якого, кому не було відведено спеціальне під час виступ. Їх завдання:

  • вникати в проблему;
  • задавати якомога більше питань.
Питання – це їх головна зброя. З їх допомогою можна направляти дискусію у потрібне русло або розкрити нові аспекти проблеми.

Грамотно сформульоване питання на подібних заходах – це практично половина успіху. Він може бути набагато корисніше спроб тут же знайти підходящий відповідь. Питання повинні тримати в тонусі команду виступаючих. Якщо вони будуть досить уважними, то зможуть отримати масу корисної інформації.

Робота модератора полягає в тому, щоб:

  • заздалегідь розробити план для заходу (хто, що, коли, навіщо);
  • стежити за тим, щоб учасники говорили по суті теми;
  • вести записи критичних зауважень;
  • постійно запитувати доповідачів про наступні кроки команди за рішенням проблеми, і протоколювати відповіді.
Взагалі ж, основна функція модератора – тримати всіх учасників в рамках відведених ролей. Це означає, що аудиторія ставить питання, доповідачі пояснюють свої рішення або виклики, з якими вони зіткнулися в роботі. Не навпаки.

У команді Крістенсена зазвичай був постійний модератор. Якщо у вас немає підходящої кандидатури (менеджер по продукту або програмний менеджер) можна вибрати одну людину з аудиторії. Нічого страшного, якщо кожен раз це буде новий модератор.

Всі учасники обговорення повинні бути «в темі»



Принципово важливо проговорювати обговорювану проблему, намагатися знайти для неї правильне формулювання, ще до початку обговорення. Необхідно визначити контекст задачі, її актуальність. Тільки в цьому випадку можна отримати якісну зворотний зв'язок. Сформулювати задачу можна приблизно так:

  • я демонструю роботу (не важливо, на якій стадії вона знаходиться);
  • за такою-то проблеми;
  • це важливо з причини;
  • хочу отримати від вас зворотній зв'язок або допомогу в її коригування.
Доповідачу важливо дати зрозуміти аудиторії, що він зацікавлений в пропозиціях по суті проблеми, а не в загальних моментах, не критики як такої. Наприклад: «Я не хочу обговорювати естетичну сторону проекту, як це буде виглядати. Мені цікаві ваші пропозиції по конкретній задачі: як домогтися зв'язкового, цілісного враження при використанні анімацій».

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

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

Зворотний зв'язок, а не шалена критика



Важливо зрозуміти різницю між корисними пропозиціями та марною критикою. Для того щоб відчути відмінність, знайти правильний формат для критики, коллеи Крістенсена з Facebook провели багато годин вивчаючи ще одного автора на цю тему – Джуді Рівса (Writing Alone, Writing Together; A Guide for Writers and Writing Groups). Дизайнер Грег Ліндлі часто цитував для команди один ключовий пасаж з цієї роботи:

«Вельми корисно формулювати свої думки не у вигляді тверджень, а у вигляді питань. Це допомагає перебувати в стані діалогу, а не захисту. Якщо певна точка зору на проблему ще на склалася, можна зафіксувати її в поточному вигляді і продовжити роботу над нею на наступному обговоренні».
Для того щоб стимулювати групу до конструктивного діалогу в ході обговорень в групі Крістенсена колеги зазвичай просили людей у своїх пропозиціях згадувати щось позитивне про обговорюваному дизайнерському або програмному рішенні. «Мені імпонує ваш підхід до цієї частини завдання, не могли б ви розтлумачити мені, як ви будете застосовувати його до іншої частини?», — наприклад.

Тобто потрібно розрізняти поняття критики і критицизму. Рівс дає чіткі відмінності між двома явищами:

  • критика передбачає запитання – критицизм проектує судження;
  • критицизм шукає помилки – критика виявляє можливості;
  • одне з них містить переходи на особистості – друге передбачає об'єктивність;
  • конкретна критика — критицизм часто невизначений;
  • критика творить — критицизм руйнує;
  • критика альтруистична — критицизм егоцентрична ;
  • критицизм б'є по працівнику – критика вдосконалює сам проект.
Основна мета «розбору польотів» — надихати команду і шукати нові рішення. Тому акцент у пропозиціях аудиторії повинен бути зроблений на навідних питаннях, фактичному матеріалі дослідження. Їх мета – допомогти вдосконалити проект, разом розібратися з проблемою, замість того, щоб нападати на доповідача.

Крім того, Крістенсен згадує ще одне важливе правило, яке діяло на зустрічах групи.

Жодних гаджетів

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

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

Наостанок, Крістенсен наводить список питань про організацію таких «годин критики», відповіді на які допоможуть зробити зустрічі продуктивнішими:

  1. чи Можете ви уявити план проекту, над яким ви працюєте?
  2. Наскільки чітко розподілені ролі на ваших сесіях?
  3. Впорався зі своєю роботою модератор, чи вдалося йому керувати дискусією?
  4. Змогли доповідачі ясно і доступно викласти суть своєї задачі, проблеми, ідеї?
  5. Дійшло це пояснення до аудиторії, хоча б у загальних рисах, щоб люди могли формулювати конкретні питання?
  6. У якій формі звучали пропозиції, вони були конструктивними?
  7. Вдалося прийти до спільної думки з приводу якого-небудь конкретного рішення, проблеми, окремого процесу?


І не варто забувати, що сесії з «розбору польотів» — це командне справу, а не шоу однієї людини. Подібні заходи можуть бути корисними лише в тому випадку, коли інтереси учасників збігаються. Якщо всі вони хочуть поліпшити продукт і знайти рішення складних завдань, то такі зустрічі можуть бути дуже корисними.

А як процес отримання зворотного зв'язку від колег влаштований у вашій компанії?

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.