Фидбэк от других участников команды является компасом, по которому каждый определяет, куда двигаться дальше. Согласно Патрику Ленсиони, один из пяти пороков команды — нетребовательность друг к другу. Этот порок достаточно сложно «вылечить». Но при этом он может оказаться губительным.
Что же такое нетребовательность?
В первую очередь, это отсутствие обратной связи от участников команды друг другу. Например, когда Вася делает фигню, а Петя никогда не скажет ему об этом. Почему не скажет? Потому что «это не мое дело»/«не хочу портить отношения»/«Вася обидится». В итоге Петя обсуждает в курилке с другими, какой Вася плохой. Вася же в счастливом неведении продолжает делать фигню. В то время как внутри команды тихо расползается токсичный туман сплетен, лицемерия и интриг.
Но дело не только в токсичной атмосфере, которая начинает складываться в команде. Если участники команд, а в особенности scrum-команд, не научатся и не будут постоянно давать обратную связь друг другу, то команда не только не сможет развиваться, но начнет деградировать.
Обратимся к более общим примерам из жизни.
Человек — сложная система, которая не может функционировать без обратной связи. Возьмем пример уровня физиологии: когда мы обжигаемся о плиту или наслаждаемся сладкими фруктами — мы получаем обратную связь от окружающей среды, которая говорит нам о том, что нужно есть больше бананов и меньше трогать раскаленные предметы. В очень упрощенной форме такая обратная связь — механизм эволюционного развития.
Возьмем другой пример
Когда человека помещают в камеру депривации (флоатинг) — полностью закрытый резервуар, заполненный жидким соляным раствором температуры человеческого тела, в который не проникают свет, звуки и запахи — он плавает там в невесомости и без каких-либо внешних раздражителей для органов чувств. Через некоторое время начинаются галлюцинации: когда обратная связь от окружающей реальности отсутствует, мозг начинает создавать «реальность» сам.
По аналогии с нашим мозгом, люди в организациях, не получая обратной связи, начинают жить в своей собственной, созданной ими же реальности. Представьте ситуацию: вы — разработчик, проработали месяц, реализовали большую фичу и выкатили на продакшн. Ваш код прошел какое-то ревью — с рядом правок, но в целом не то чтобы плохо. Однако никто из команды не дал вам обратную связь.
В какой реальности вы будете жить?
Будете считать, что вы гуру разработки, быстро завершили задачу и у вас крутой код?
Решите, что все пропало, потому что фичу можно было сделать за неделю вместо месяца, и вас скоро уволят?
Подумаете, что про вас просто все забыли и в команде ваша работа никому не нужна?
Почему же фидбэк участников команды друг другу так важен, особенно если вы работаете по Scrum?
Обратная связь — механизм эволюции команды. Получая фидбэк, каждый из участников понимает, что он делает хорошо и что нужно продолжать делать, а что из его действий мешает команде и как это нужно изменить. Обратная связь — это то, что позволяет корректировать работу, учиться новому и меняться. И не надо думать, что «Вася не дурак, сам поймет, что накосячил». Не поймет, а создаст в голове свою реальность со своими выводами, которые необязательно будут совпадать с вашими.
В scrum-командах нет начальника, который в классической системе управления дает фидбэк (к слову говоря, совершенно субъективный) своим сотрудникам. Эту функцию берет на себя вся команда. Каждый раз, сомневаясь в том, давать или не давать коллеге обратную связь, подумайте: если не вы, то кто?
Если обратная связь внутри команды отсутствует, то каждый из ее участников начинает жить в своей реальности, строя гипотезы о том, что он делает хорошо, а что не очень. Не давая обратной связи друг другу, вы поощряете тех, кто ленится и плодит баги, косячить дальше и демотивируете тех, кто старается, отсутствием одобрения и простого человеческого спасибо.
Обратная связь — непростая штука. Ее сложно давать, а еще сложнее — принимать
Впрочем, если придерживаться трех ключевых правил, скорее всего, она будет положительно воспринята собеседником.
Правило №1
В основе обратной связи должны быть факты. Не эмоции или отношение к человеку, а конкретика — что именно в работе пошло не так. Не «Вася! Ты чудак на букву М, сорвал нам весь проект! Что ты вообще делаешь у нас в команде?!». А «Вася, если бы встреча с подрядчиками была организована раньше, то мы бы успели завершить проект в срок».
Правило №2
Давайте обратную связь, исходя из положительных намерений: это может быть желание помочь человеку; подсветить какие-то проблемные аспекты; улучшить процессы работы, которые влияют на всю команду. Если вы даете обратную связь, чтобы доказать свою правоту, показать, какой вы умный или сказать заветное для всех «я же говорил» — скорее всего, у собеседника включится защитная реакция, ваши замечания не будут восприняты, а превратятся в бестолковый спор. Сравните: «Вася! Я же тебе говорил не включать этот пункт в договор с подрядчиками! Зачем ты это сделал?» и «Вася, кажется, у нас проблемы с подрядчиками из-за этого пункта договора: давай вместе подумаем, что сделать, чтобы исправить ситуацию и чтобы она не повторилась в будущем».
Правило №3
Следите за своим эмоциональным состоянием. Оно говорит за нас гораздо больше слов. Если мы опираемся на объективные и понятные собеседнику факты, но при этом злимся на него, испытываем неприязнь или раздражение, то человек в первую очередь воспримет наши эмоции и закроется. Злость и раздражение — эмоции агрессии. А если мы чувствуем агрессию по отношению к себе, первая реакция — защита или нападение в ответ. Но ни то, ни другое не способствует эффективному восприятию обратной связи. Эмоции легко считываются собеседником, поэтому не пытайтесь их скрыть — это не сработает. Лучше подождите чуть-чуть, походите, посмотрите в окно, попрыгайте со скакалкой, выпейте воды, успокойтесь, выпишите основные тезисы беседы на листочек — и тогда давайте обратную связь. Слова, сказанные сквозь зубы, с раздражением или на повышенных тонах будут восприняты гораздо хуже сказанных в спокойном, доброжелательном состоянии, с вниманием и улыбкой.
Кроме рекомендаций о том, как давать обратную связь, есть пара советов, как ее принимать
- Дышите и слушайте. Записывайте, что вам говорят: с одной стороны, это здорово снижает уровень напряжения, а с другой — помогает зафиксировать все услышанное, чтобы потом обдумать в спокойной обстановке.
- Не спорьте и не оправдывайтесь. Обратная связь — это не обвинение и не критика, а просто повод задуматься. Маячок, что что-то пошло не так. Если в том, что вам говорят, есть непонятные моменты или вы с чем-то не согласны — задайте уточняющие вопросы.
- В конце поблагодарите того, кто дал обратную связь. Ведь, скорее всего, человек исходил из хороших намерений и желания помочь вам, обратить внимание на что-то важное. И ему, возможно, было даже тяжелее решиться и дать обратную связь, чем вам — принять ее.
- Обдумайте сказанное и выберите, что из этого взять для себя — с чем вы согласны и что можете скорректировать в своей работе. Вы не обязаны соглашаться со всем, что вам сказали. Но это точно повод задуматься, что в системе что-то пошло не так.
Культура обратной связи не создается за один день
Нельзя просто прийти к команде и сказать, что с понедельника ребята должны стать требовательными друг к другу. Задача Scrum Master в данном контексте:
- Показать команде, почему и на сколько важно давать друг другу обратную связь.
- Научить команду давать фидбэк друг другу экологично: без эмоций и негатива, не переходя на личности, с намерением помочь участнику и самой команде стать лучше.
- Создавать безопасное пространство для обратной связи, стимулировать и поощрять ее.
Чтобы преодолеть порок нетребовательности, команде нужно пройти большой путь, но любой путь начинается с первого шага. Поэтому в следующий раз, когда заметите, что Вася делает что-то не то, и захотите смолчать, подумайте — а кто, если не вы?
Комментарии (14)
PMVyatkin
08.11.2019 11:04Я слышал про Kenneth Rubin и, внезапно, даже прочитал. Scrum Guide он не противоречит, просто разжевывает гайд в начале и дополняет как команда может работать в разных организациях и при разных условиях. И да, там есть прямо глава с названием «Managers», где рассказывается о том, как можно работать с руководством за пределами скрам (emacsway, которые никуда не делись, в скрамгайде они включены в группу 'stakeholders', но в этой группе не только менеджмент).
Так вот, согласно этой книге, у команд все еще могут быть классические менеджеры — Head of QA, Head of BA, CTO, CEO, CFO, CIO etc. Роли этих менеджеров примерно следующие — формирование команды, постановка целей, определение границ работы команды и смена участников команды. Менеджер и правда может уволить или выдать бонус (если он гендир, например). Но в этом он опирается в первую очередь на мнение скрам-команды и это явно написано в книге — там даже есть пример с Фредом, который плохо работает в команде и СНАЧАЛА команда разработки работает с ним, потом СМ (как часть уже скрам-команды), и только потом они идут к менеджеру вне скрам-команды — см. скриншот из книги ниже. Скрамгайду на мой взгляд это совсем не противоречит. А вот такого, что бы менеджер кого то оценивал сам, без ОС команды разработки — это явный антипаттерн.
chilicoder
08.11.2019 12:42+1А вот такого, что бы менеджер кого то оценивал сам, без ОС команды разработки — это явный антипаттерн
В традиционном подходе оценивать сотрудника без опоры на мнение его пиров также не приветствуется.
команд все еще могут быть классические менеджеры
как их может не быть?)
Вы представьте. Работает скрам-команда. Колбасит тикеты. Закрывает спринты. А кому это все нужно? Кто сформировал команду и зачем? Кто смотрит на результаты спринтов и проверяет их вклад в выполнение бизнес целей? Кто проверяет, что они разрабатывают с нужной скоростью или скорость маловата. Или что продукт вообще не выполняет тех целей, которые предполагалось? Кто кладет айтемы в бэклог? Кто ответственен за успех продукта?
Команду в целом не предлагать) Они ответственны за оценку айтемов в бэклоге и за то, чтобы позакрывать тикеты. Product ownerа также не предлагать. От не управляет продуктом, он управляет только бэклогом.
PMVyatkin
08.11.2019 13:05>> команд все еще могут быть классические менеджеры
>> как их может не быть?)
Возможно все, например — стартап. Собрался я с Васей и Колей сделать лучшую в мире блокчейн-платформу, Вася привел свою девушку, Коля привел своего брата. Из инвестиций у нас — собственные ноуты и коворкинг, оплаченный из денег на завтраки, Idea по студенческой лицензии. Работаем just for fun до первых инвестиций, менеджеров не будет. Но это, конечно, утрированно сильно )))
В идеальном случае, должно быть так — стейкхолдеры объясняют РО свою стратегию развития организации\возврата инвестиций, и РО обеспечивает эту стратегию через управление бэклогом.
Иначе говоря, критерии успешности продукта — задают стейкхолдеры, за достижение этих критериев — отвечает РО (естественно, через правильное наполнение беклога). И эти критерии могут быть и прибыль, и лидерство на рынке, и РОИ, и просто вывод продукта на рынок, и укрепление HR-бренда, да что угодно.
Пример — у вас есть 1 млрд рублей и вы хотите сделать новую игру. Поздравляю, вы стейкхолдер — и теперь вам можно нанять скрам-команду. Вы находите РО, который хорошо шарит в рынке игр, понимает что в тренде, какие есть каналы продвижения и т.д. и т.п. Вы формируете ему цели, например сделать отдачу от инвестиций 5% в течении этого года и он приступает — наполняет беклог тем, что может этой цели достигнуть (и тут важно сказать что РО разделяет ваше видение, если вы например говорите что хотите фентези игру, РО может сказать вам что нынче в моде танки и не согласиться работать с вами, т.к. считает цели недостижимыми при таких условиях). Команда разработки же превращает элементы беклога — в инкримент, который потом можно зарелизить и вывести на рынок (и тут то РО проверит, был он прав предполагая что на этом можно получить денег или нет).
makisseleva
08.11.2019 16:59Следите за своим эмоциональным состоянием. Оно говорит за нас гораздо больше слов. Если мы опираемся на объективные и понятные собеседнику факты, но при этом злимся на него, испытываем неприязнь или раздражение, то человек в первую очередь воспримет наши эмоции и закроется. Злость и раздражение — эмоции агрессии
Лайфхак: если хочется сказать сотруднику какую-то гадость, я иду к кулеру, выпиваю стакан воды, возвращаюсь на рабочее место и после этого способна дать нормальную обратную связь)
chilicoder
В рамках фидбэка
Это неверно. У скрам-команды, конечно, же есть начальник. Который отвечает за оценку команды в целом и отдельных сотрудников, нанимает/увольняет/отправляет на обучение, отвечает за результаты работы команды.
Начальник команды — это тот ради кого и внедряется Scrum. Два главных отличия от традиционного подхода:
1) не нужно каждому выдавать задачи, сами разбируться
2) можно быстро оценить прогресс в проекте (т.е. вовремя заметить и исправить ошибки, сделанные на этапе планирования)
Подробное описание роли менеджера скрам-команды читайте в Essential Scrum by K.Rubin. Chapter 13 Managers.
emacsway
Про Ken Schwaber и Jeff Sutherland — я слышал. Про K.Rubin — не слышал. Не могли бы Вы подсказать, на какой именно странице "The official Scrum Guide" идет речь о роли менеджера?
chilicoder
это слабый аргумент в дискуссии.
У меня к вам встречный вопрос. На какой странице там идет речь о том, что менеджеры не нужны? И если вы не нашли там слово manager и решили, что они не нужны, нужен ли такой вывод для CTO,CEO, VP of Product, HR etc? Про зарплату там также ничего не написано.
emacsway
Нужны ли эти роли в Scrum-команде и требуется ли их участие именно в Scrum-процессе? «This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together… The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.» — «The official Scrum Guide».
Таким образом, участие перечисленных Вами ролей в Scrum-процессе не требуется, поскольку официальный документ однозначно говорит, что Scrum состоит только из тех ролей, которые содержит документ.
Но, поскольку Scrum — это фреймворк, а не финальная методология, то Вы вольны строить на его основе свои собственные процессы (только они не будут при этом изменять сам Scrum): «Rather, it is a framework within which you can employ various processes and techniques.» — «The official Scrum Guide»
«The Development Team is responsible for all estimates.» — «The official Scrum Guide»
«The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.» — «The official Scrum Guide». А вообще, в Agile заказчик принимает на себя часть финансовой ответственности за право влиять на процесс разработки.
Scrum внедряется ради получения заказчиком бизнес-выгод, предоставляемых Agile-разработкой, которая заключается в техническом обеспечении итеративной разработки, таким образом, чтобы будущие проектные решения опирались на feedback от практической эксплуатации реализации проектных решений предыдущих итераций. Это открывает возможность эффективного управления бизнес-рисками.
А роль «начальника» в Agile-разработке закреплена в 4-м принципе Agile Manifesto: «Business people and developers must work together daily throughout the project.» А также в «The official Scrum Guide»: «Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.»
chilicoder
Вы приписали мне позицию, которую я не выражал и доблестно бросились ее опровергать. Повторяя иногда мои же тезисы.
Иронично) Себе то вы право рассказывать про скрам оставили.
emacsway
Если помните, то я просто спросил у вас номер страницы «The official Scrum Guide», которая подтверждает Ваши слова. Вы написали кучу слов, но так и не ответили на первоначальный вопрос.
Если только Вы — Ken Schwaber, Jeff Sutherland, или, на худой конец, Kent Beck (по вопросам Agile, учитывая что Scrum — это Agile, надеюсь, что хоть это не стало для Вас сюрпризом).
И вы, конечно же, не поленились процитировать эти мои слова перед своей репликой.
P.S.: Тот факт, что Вы перешли от аргументации по сути к обсуждению субъекта диалога, говорит намного больше, чем само содержание Вашего ответа. И это, как бы, не совсем профессионально.
P.S.S.: Когда выбираете литературу, то, если это не первоисточник (и), то старайтесь, хотя бы, чтобы ее рецензировал первоисточник, как, например, книги автора Henrik Kniberg. Я не хочу сказать, что вы прочитали плохую книгу, в конце-концов, Mike Cohn и Ron Jeffries обладают весомым авторитетом в Agile. Может быть, вы просто не так поняли автора. Я не знаю, и это не есть предмет обсуждения. Есть только один документ, который устанавливает, что в Scrum должно быть.
chilicoder
Вы именно приписали. Я не утверждал, что менеджер входит в Scrum-команду. Поэтому вашего доблестного разоблачения не требовалось. В котором вы, к тому же, допустили ряд ошибок. Например, перепутали оценку эффективности работы команды и оценку командой трудозатрат на элементы Backlog.
Сново очень иронично. Как раз эти два человека написали вступительные слова к книге Essential Scrum, которую вы не читали и об авторе которой вы не слышали. Что, по вашим словам, является ключевым аргументом.
Кстати о Ron Jeffries. У него есть пост о менеджерах в котором он также подчеркивает, что если в компании есть менеджеры (т.е. в подавляющем большинстве компаний), то они дают задания и несут обязанность исправлять вещи, которые идут не так. А scrum позволяет выявить эти ошибки быстрее. В своем первоначальном комментарии я писал об этом же.
https://ronjeffries.com/articles/018-01ff/agile-manager/
emacsway
Вы: Это неверно. У скрам-команды, конечно, же есть начальник… Подробное описание роли менеджера скрам-команды (род. падеж) читайте в...
Всякое может быть. Если Вы процитируете, о каких именно моих словах идет речь — мне будет понятней. Пока что я не могу обнаружить, чтобы я что-то Вам приписал.
P.S.: Если Вы хотите поговорить не по предмету обсужения, то я предлагаю не флеймить здесь, а продолжить в привате.
chilicoder
Как вы видите, я использовал предлог "у", который в русском языке имеет смысл, отличный от предлога "в".
Попробуйте в связи с этим переосмыслить мой изначальный комментарий и если у вас будут возражения, дополнения, комментарии, начните новый тред. Эта ветка уже потеряла смысл.
emacsway
Ваше возражение было против предлога «В» оригинальной цитаты автора. Именно он стал причиной вашего диалога с автором в стиле RTFM. Дальше вы использовали попеременно предлог «у» и родительный падеж. Но даже если Вы по случайности не заметили предлог «В» оригинальной цитаты автора, которую оспорили, то есть разница между «менеджером Scrum-команды» и «менеджером(-ами) участников Scrum-команды». В последнем случае менеджер находится вне Scrum-процесса. В первом случае — объектом отношений является сама команда, соответственно, менеджер, в таком случае, является участником Scrum-процесса, и вы даже описали его обязанности и ответственность по отношению к команде:
Вы даже попросили меня оспорить это: