В наших блогах на Хабре и Мегамозге мы много пишем о построении облачного сервиса 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). Дизайнер Грег Линдли часто цитировал для команды один ключевой пассаж из этой работы:
«Весьма полезно формулировать свои мысли не в виде утверждений, а в виде вопросов. Это помогает находиться в состоянии диалога, а не защиты. Если определенная точка зрения на проблему еще на сложилась, можно зафиксировать ее в текущем виде и продолжить работу над ней на следующем обсуждении».
Для того чтобы стимулировать группу к конструктивному диалогу в ходе обсуждений в группе Кристенсена коллеги обычно просили людей в своих предложениях упоминать что-нибудь позитивное об обсуждаемом дизайнерском или программном решении. «Мне импонирует ваш подход к этой части задачи, не могли бы вы просветить меня, как вы будете применять его к другой части?», — например.
То есть нужно различать понятие критики и критицизма. Ривс дает четкие различия между двумя явлениями:
- критика подразумевает вопросы – критицизм проецирует суждения;
- критицизм ищет ошибки – критика выявляет возможности;
- одно из них содержит переходы на личности – второе подразумевает объективность;
- критика конкретна — критицизм часто неопределен;
- критика созидает — критицизм разрушает;
- критика альтруистична — критицизм эгоцентричен ;
- критицизм бьет по работнику – критика совершенствует сам проект.
Основная цель «разбора полетов» — вдохновлять команду и искать новые решения. Поэтому акцент в предложениях аудитории должен быть сделан на наводящих вопросах, фактическом материале исследования. Их цель – помочь усовершенствовать проект, вместе разобраться с проблемой, вместо того чтобы нападать на докладчика.
Кроме того, Кристенсен упоминает еще одно важное правило, которое действовало на встречах его группы.
Никаких гаджетов
Невозможно сосредоточиться на решении проблем, обсуждении идей или росте профессионального уровня команды, если вы постоянно проверяете сообщения на телефоне или обновления в социальных сетях.
Есть лишь два исключения из этого правила: когда модератор использует лэптоп, чтобы делать пометки, или докладчик в процессе своей презентации. Всем остальным следует на время уйти в оффлайн.
Напоследок, Кристенсен приводит список вопросов об организации таких «часов критики», ответы на которые помогут сделать встречи более продуктивными:
- Можете ли вы представить план проекта, над которым вы работаете?
- Насколько четко распределены роли на ваших сессиях?
- Справился ли со своей работой модератор, удалось ли ему управлять дискуссией?
- Смогли ли докладчики ясно и доступно изложить суть своей задачи, проблемы, идеи?
- Дошло ли это объяснение до аудитории, хотя бы в общих чертах, чтобы люди могли формулировать конкретные вопросы?
- В какой форме звучали предложения, были ли они конструктивными?
- Удалось ли прийти к общему мнению по поводу какого-либо конкретного решения, проблемы, отдельного процесса?
И не стоит забывать, что сессии по «разбору полетов» — это командное дело, а не шоу одного человека. Подобные мероприятия могут быть полезными только в том случае, когда интересы участников совпадают. Если все они хотят улучшить продукт и найти решение сложных задач, то такие встречи могут быть крайне полезными.
А как процесс получения обратной связи от коллег устроен в вашей компании?
Автор: 1cloud.ru
