Мы больше не живем в мире фабрик и заводов, когда от человека можно было требовать четко выполнять свою работу и не ошибаться. В современном мире необходимо, чтобы человек решал нетиповые задачи. А это означает, что он будет ошибаться. С другой стороны, мы не можем быть полностью толерантны к ошибкам, ведь для компании нужен конкретный результат в конкретные сроки.
Из этой статьи вы узнаете, как добиться того, чтобы люди учились на своих ошибках и не повторяли их в будущем, а также — как соблюсти баланс между требовательностью к результату и открытостью к экспериментированию.
Не все эксперименты одинаково полезны. Даже если они приводят к успеху. Несмотря на картинку, у нас серьезная статья. Источник изображения: https://www.dreamworks.com/movies/kung-fu-panda
Это кринж, когда в 21-м веке в школе учат выходить в туалет по поднятой руке, не возражать учителю и верить тому, что написано в учебнике. Не потому, что это плохо само по себе, а потому, что те заводы, на которые нужны такие люди, остались в где-то глубине прошлого века.
В 21-м веке у нас большая неопределенность, и мы хотим учить детей через эксперименты. Мы хотим, чтобы дети сначала в школе, а потом в университете не доверяли тому, что написано в толстой книге из 50-х, а попробовали и убедились на своем опыте.
В свое время мне доставило удовольствие высчитывать объем кубической гранецентрированной упаковки мячиков. Увы, с эффективностью компании это не связано. Источник изображения: https://bit.ly/3AVE7sE
Культура подчинения приводит к тому, что люди боятся ставить эксперименты и делать ошибки. Потому что «ошибки делают некомпетентные сотрудники», и за эти ошибки их будут потом штрафовать, лишать премии и, возможно, даже увольнять. Человек не может позволить себе потерять лицо, поэтому действует самым надежным способом. Но не самым эффективным.
Тем не менее, говорить, что эксперименты и ошибки, это однозначно хорошо, тоже не стоит. Ошибки сотрудника — это потери для компании: меньше денег, больше недовольных клиентов, пишущих жалобы, и недополученная выгода.
На диаграмме случайная выборка людей из результатов нашего исследования команд. Названия мы придумали специально для статьи, за ними нет скрытого смысла. Источник изображения: https://kiteproject.ru/
Рабочий, который не готов меняться и боится ошибаться — это как раз тот человек, который получается в результате применения системы образования. Содержать такого человека в IT-команде дорого. Это вечный джун.
Энциклопедисты — это люди, которые боятся ошибаться, но готовы менять свои представления, если получают новые знания. Именно они знают, какие есть best practices. Если такие люди доминируют в команде, то команда будет двигаться медленно, но надежно. При проектировании атомных станций — самое то!
Самый опасный квадрант — это Шизофазист. Именно такие люди предлагают попробовать новую технологию, которая оказывается сырой, имеющей плохо документированный API и разработчиков, которые уверены, что никакого бага тут нет, несмотря на все ваши попытки убедить их в том, что он есть. Такому человеку интересно пробовать новое — это ценно. К несчастью, такой человек редко думает о том, что его эксперимент стоит $450 на разработчика за каждый потерянный час.
Когда вы дочитали до этого места, подумайте, находитесь ли вы в последнем квадранте. Я надеюсь, что да: у вас готовность ставить эксперименты соседствует с готовностью изменить свое мнение после этих экспериментов. Иначе бы вас не сделали тимлидом.
В США сейчас нарастает мнение, что Agile не работает. Agile, конечно, работает, но не для всех. Agile предполагает, что все люди в команде находятся в квадранте «Тимлид», а это зачастую не так. Если у вас такая команда, в которой люди готовы экспериментировать и совершать ошибки, а потом учится на них, то у вас Agile пройдет как по книжкам. Теперь давайте посмотрим, что делать в реальном случае.
Маленькие дети учатся именно так. А вот взрослых тяготит собственный опыт. Источник изображения: https://kiteproject.ru/
Цикл Деминга-Шухарта внедрения инноваций, OODA-цикл принятия решений, HADI-цикл проверки гипотез и еще множество других аналогичных циклов строятся по одному и тому же принципу: сначала человек что-то планирует, потом выполняет, а потом смотрит, что у него получилось. После чего делает выводы, разрабатывает улучшения и снова повторяет.
На этапе планирования команда должна выбрать баги для фикса и фичи для разработки, опираясь на обратную связь от заказчика, приоритезацию бэклога и на свое внутреннее представление о должном и правильном. На этапе выполнения команда вjobывает и смотрит на диаграмму сгорания, смотрит и вjobывает. По возможности не нарушая восьмой принцип Agile про переработки.
На этапе обзора спринта команда смотрит, что у нее получилось, и выясняет, что думают все стейкхолдеры об этом. Стейкхолдеры у нас уже обученные, поэтому говорят не матом, а сразу User Stories, самые продвинутые – Job Stories. В конце команда на ретроспективе решает, как ей улучшить свою работу: то, что пошло хорошо, нужно закрепить, а что пошло плохо — ликвидировать.
Это хорошая схема, и если команда идет по ней, то от спринта к спринту пишется лучший код, принимаются лучшие решения, общение со стейкхолдерами протекает все быстрее, радостней и продуктивнее, графики эффективности идут вверх, диаграммы сгорания — вниз, улыбающихся смайликов становится все больше и даже офисный фикус, чувствуя всеобщий заряд позитива, тянется вверх и вширь.
Те штуки, которые помогают жить, но мешают учиться новому, называются ментальными моделями. В средневековье их было не принято менять. Некоторые люди все еще живут в Средневековье. Источник изображения: https://kiteproject.ru/
К несчастью, эта схема не работает. Точнее, она не работает так, как описано в книгах и так, как я только что описал. Потому что людям мешает уже собранный опыт, их ментальные модели. «Так не принято», «Это просто месяц плохой», «Это просто заказчик понял все не так», «Это просто коронавирусный год», «Это просто Меркурий в пятом доме» — практически любая трудность представляется локальной и не повторяющейся.
Людям проще проигнорировать свой командный провал или объявить его крайне редким. Раньше считалось, что сотрудники должны приходить на работу в 9.00 и уходить в 17.00. Хьюлетт и Паккард сломали эту ментальную модель: оказывается, если дать сотрудникам возможность приходить и уходить в удобное для них время, то они работают лучше! Собственно, Agile почти полностью состоит из утверждений, не совпадающих с ментальными моделями типичного представителя корпоративного мира из 90-х. Команда не должна перерабатывать? Маркетологи и разработчики в одной команде? Команда сама выбирает, что делать? Да вы что, сумасшедших таблеток объелись?!
Мир, если бы люди учились сразу и не повторяли ошибок. Источник изображения: Уже не найти 
...
Собственно, если персонаж, который предполагает злоупотребление таблетками, будет работать по этому циклу, то он увидит, что люди работают лучше, если их не микроменеджить. Что люди реже повторяют ошибки, если дать им самим дойти до осознания этой ошибки. Но будет ли этому человеку легко прийти к выводу, что самоорганизующаяся кросс-функциональная команда работает лучше и не нуждается в менеджере? Скорее всего, от такого вывода человек будет убегать. «Если менеджер не нужен, то зачем тогда я? Если я все не контролирую, то какой же я менеджер?»
Не надо пытаться эффективнее делать то, что не надо делать вообще. Вообще, это моя цитата, но что-то такое есть у Элона Маска. Источник изображения: https://codeysart.com.au/
Что может сделать с этим тимлид? Если ваши коллеги не хотят работать эффективно, то нужно искать новую команду, а лучше — новую компанию. А вот если люди готовы работать эффективнее, то вы можете им в этом помочь.
И нет, цель компании — это не деньги зарабатывать. И у Майкрософта, и у шавермочной на углу есть цель зарабатывать деньги, но это не то, что отличает одну компанию от другой. Цель компании — зарабатывать деньги, осуществляя определенную деятельность при определенных ограничениях.
Люди редко понимают, какие долгосрочные последствия имеют их решения. Источник изображения позаимствован из фильма V for Vendetta: https://www.warnerbros.com/movies/v-vendetta
У меня были случаи, когда желание тимлида побыстрее уйти в отпуск привело к возникновению конкурента, который в итоге превзошел наш проект. Был случай, когда тестировщик поругался с девушкой, что привело к тому, что в ядре оказался critical bug. Был случай, когда желание побыстрее уйти на Новый Год привело к принятию быстрого решения на переговорах, что привело к потере нескольких миллионов долларов. Люди редко думают, как их небольшое быстрое решение приведет к большой катастрофе через год.
Один из моих любимых примеров: новый техлид обучает команду писать хороший код. И его способ вызывает раздражение у многих участников. Дело в том, что в ходе ревью техлид исправляет ошибки коллег, показывает им, как лучше написать, объясняет, почему именно так, а потом… возвращает все назад. Коллеги возмущаются: «Зачем он это делает?! Все уже было в порядке, мы теряем время, мы теряем эффективность!» Да, теряют, в краткосрочной перспективе. Зато получают опыт.
Если у вас люди спрашивают: «А что с этим багом делать?», «А что с этим заказчиком делать?», «А у нас база упала — что делать?», то первая реакция: «А ты как думаешь, что делать?» В большинстве случаев человек сам знает, что делать.
Есть еще один волшебный вопрос: «Что мешает это сделать прямо сейчас?» Человек отвечает, что ничего, и вы разводите руками. Это роль тимлида: вы спросили, что человек хочет сделать, что ему мешает это сделать, а потом киваете. И он, вдохновленный, уходит делать, а вы вдохновленный идете пить пиво. Или выполнять рекомендации из пункта про эффективность.
У вас когда-нибудь так было, что вы делали одну и ту же ошибку несколько раз? У меня было. Самому стыдно. Источник изображения: https://stock.adobe.com/ru/264987140
Даже в бирюзовой Agile-команде работают простые люди. А людям сложно сказать: «Я ошибся». Даже если их за это не будут харассить, самооценке все равно будет больно. Поэтому принцип обучения для тимлида требует баланса: с одной стороны, нельзя обесценивать ошибку и делать вид, что она ничего не стоит. С другой — нужно сделать так, чтобы человек сделал выводы и изменил свое поведение. Это сложно.
Также не стоит стесняться расставаться с сотрудниками. Джек Уэлч говорил, что если вы держите у себя сотрудника, который не может расти и плохо работает, а вам это не нравится — то это наказание и для вас, и для сотрудника. Отпустите его. Может быть, он найдет хорошее место, где ему будет комфортно работать. Не превращайте работу сотрудника в ад.
Когда вы обвиняете коллег, они начинают защищаться: «Это не моя зона ответственности», «Мне слишком поздно переслали данные», «В сервер ударила молния». И начинается игра в горячую картошку, когда каждый перекидывает друг другу ответственность до тех пор, пока все окончательно не запутаются и просто не забьют на это. Не надо так.
Не обвиняйте людей, потому что если вы хоть как-то начнете обвинять людей, они тут же начнут оправдываться. Когда они оправдываются, включается та самая ментальная модель — «Это не моя вина», «Я здесь ни при чем».
Проводите ретроспективы, для этого они и придуманы. Но… не всегда их проводят правильно. Я полагаю, что одна из лучших инвестиций в свое образование — это чтение книги Норма Керта «Ретроспектива Проекта». Она не про Agile, но мысли там правильные.
Письмо Принцессе Селестии — хороший способ зафиксировать новый опыт. Впрочем, это слишком ванильно. Можно написать письмо Раммштайн. Источник изображения: https://mylittlepony.hasbro.com/
Если команда не учится на ошибках — это потери, а не Agile / Teal / Holo. Ошибка — это инвестиция компании в развитие сотрудника, которую сотрудник возвращает тем, что в будущем принимает лучшие решения. Если люди не знают цену ошибке, они не будут стремиться ни к предвидению, ни к обучению. Не экранируйте людей от опыта!
Самая лучшая инвестиция — в свое психологическое здоровье. Вторая лучшая — в свое образование. Акции Газпрома и Биткоин идут потом, несмотря на кликбейты от банков. Проще всего фокусироваться на том, чтобы менять других людей и фокусироваться на третьей и четвертой колонках. А эффективнее всего — фокусироваться на второй!
habr.com
Из этой статьи вы узнаете, как добиться того, чтобы люди учились на своих ошибках и не повторяли их в будущем, а также — как соблюсти баланс между требовательностью к результату и открытостью к экспериментированию.
一 Ошибки — это хорошо или плохо?
Всю историю человечества считалось, что ошибки — это плохо, а последние 200 лет — что очень плохо. Должны ли мы сейчас поверить вдохновляющим раскраскам личностного роста, что нам нужно найти свой внутренний голос, расправить крылья, выпустить на свободу художника, экспериментировать и совершать ошибки? И да, и нет.Это кринж, когда в 21-м веке в школе учат выходить в туалет по поднятой руке, не возражать учителю и верить тому, что написано в учебнике. Не потому, что это плохо само по себе, а потому, что те заводы, на которые нужны такие люди, остались в где-то глубине прошлого века.
В 21-м веке у нас большая неопределенность, и мы хотим учить детей через эксперименты. Мы хотим, чтобы дети сначала в школе, а потом в университете не доверяли тому, что написано в толстой книге из 50-х, а попробовали и убедились на своем опыте.
«Сколько мячиков поместится в школьный автобус, который везет настройщик пианино из Чикаго, объезжая круглые канализационные люки?» — такие вопросы задавали в Google до тех пор, пока не поняли их бесполезность. Так почему это все еще продолжают делать многие HR-ы? Может быть, потому что с детства привыкли копировать чужие мысли и у них нет даже желания придумать что-то свое. Что-то, что будет работать именно для их компании лучше всего?
Культура подчинения приводит к тому, что люди боятся ставить эксперименты и делать ошибки. Потому что «ошибки делают некомпетентные сотрудники», и за эти ошибки их будут потом штрафовать, лишать премии и, возможно, даже увольнять. Человек не может позволить себе потерять лицо, поэтому действует самым надежным способом. Но не самым эффективным.
Тем не менее, говорить, что эксперименты и ошибки, это однозначно хорошо, тоже не стоит. Ошибки сотрудника — это потери для компании: меньше денег, больше недовольных клиентов, пишущих жалобы, и недополученная выгода.
Этой формулой может пользоваться инновационная компания. Нельзя позволять людям ставить эксперимент, который может уничтожить всю компанию. Нужно, чтобы люди, перед тем как что-то проверять, сначала выяснили, какие есть best practices. И нужно, чтобы люди были готовы учиться на своих ошибках.
Рабочий, который не готов меняться и боится ошибаться — это как раз тот человек, который получается в результате применения системы образования. Содержать такого человека в IT-команде дорого. Это вечный джун.
Энциклопедисты — это люди, которые боятся ошибаться, но готовы менять свои представления, если получают новые знания. Именно они знают, какие есть best practices. Если такие люди доминируют в команде, то команда будет двигаться медленно, но надежно. При проектировании атомных станций — самое то!
Самый опасный квадрант — это Шизофазист. Именно такие люди предлагают попробовать новую технологию, которая оказывается сырой, имеющей плохо документированный API и разработчиков, которые уверены, что никакого бага тут нет, несмотря на все ваши попытки убедить их в том, что он есть. Такому человеку интересно пробовать новое — это ценно. К несчастью, такой человек редко думает о том, что его эксперимент стоит $450 на разработчика за каждый потерянный час.
Когда вы дочитали до этого места, подумайте, находитесь ли вы в последнем квадранте. Я надеюсь, что да: у вас готовность ставить эксперименты соседствует с готовностью изменить свое мнение после этих экспериментов. Иначе бы вас не сделали тимлидом.
В США сейчас нарастает мнение, что Agile не работает. Agile, конечно, работает, но не для всех. Agile предполагает, что все люди в команде находятся в квадранте «Тимлид», а это зачастую не так. Если у вас такая команда, в которой люди готовы экспериментировать и совершать ошибки, а потом учится на них, то у вас Agile пройдет как по книжкам. Теперь давайте посмотрим, что делать в реальном случае.
二 Как мы учимся, и почему это не работает?
Цикл Деминга-Шухарта внедрения инноваций, OODA-цикл принятия решений, HADI-цикл проверки гипотез и еще множество других аналогичных циклов строятся по одному и тому же принципу: сначала человек что-то планирует, потом выполняет, а потом смотрит, что у него получилось. После чего делает выводы, разрабатывает улучшения и снова повторяет.
На этапе планирования команда должна выбрать баги для фикса и фичи для разработки, опираясь на обратную связь от заказчика, приоритезацию бэклога и на свое внутреннее представление о должном и правильном. На этапе выполнения команда вjobывает и смотрит на диаграмму сгорания, смотрит и вjobывает. По возможности не нарушая восьмой принцип Agile про переработки.
На этапе обзора спринта команда смотрит, что у нее получилось, и выясняет, что думают все стейкхолдеры об этом. Стейкхолдеры у нас уже обученные, поэтому говорят не матом, а сразу User Stories, самые продвинутые – Job Stories. В конце команда на ретроспективе решает, как ей улучшить свою работу: то, что пошло хорошо, нужно закрепить, а что пошло плохо — ликвидировать.
Это хорошая схема, и если команда идет по ней, то от спринта к спринту пишется лучший код, принимаются лучшие решения, общение со стейкхолдерами протекает все быстрее, радостней и продуктивнее, графики эффективности идут вверх, диаграммы сгорания — вниз, улыбающихся смайликов становится все больше и даже офисный фикус, чувствуя всеобщий заряд позитива, тянется вверх и вширь.
К несчастью, эта схема не работает. Точнее, она не работает так, как описано в книгах и так, как я только что описал. Потому что людям мешает уже собранный опыт, их ментальные модели. «Так не принято», «Это просто месяц плохой», «Это просто заказчик понял все не так», «Это просто коронавирусный год», «Это просто Меркурий в пятом доме» — практически любая трудность представляется локальной и не повторяющейся.
Людям проще проигнорировать свой командный провал или объявить его крайне редким. Раньше считалось, что сотрудники должны приходить на работу в 9.00 и уходить в 17.00. Хьюлетт и Паккард сломали эту ментальную модель: оказывается, если дать сотрудникам возможность приходить и уходить в удобное для них время, то они работают лучше! Собственно, Agile почти полностью состоит из утверждений, не совпадающих с ментальными моделями типичного представителя корпоративного мира из 90-х. Команда не должна перерабатывать? Маркетологи и разработчики в одной команде? Команда сама выбирает, что делать? Да вы что, сумасшедших таблеток объелись?!
...Собственно, если персонаж, который предполагает злоупотребление таблетками, будет работать по этому циклу, то он увидит, что люди работают лучше, если их не микроменеджить. Что люди реже повторяют ошибки, если дать им самим дойти до осознания этой ошибки. Но будет ли этому человеку легко прийти к выводу, что самоорганизующаяся кросс-функциональная команда работает лучше и не нуждается в менеджере? Скорее всего, от такого вывода человек будет убегать. «Если менеджер не нужен, то зачем тогда я? Если я все не контролирую, то какой же я менеджер?»
Ментальные модели мешают команде найти лучшее из доступных решений. Давайте посмотрим, что может сделать тимлид с этим своими силами!
三 Принцип Эффективности
Что самое главное в команде? Если задать такой вопрос, то можно получить множество ответов, что важны общие цели, гармония и доверие. В целом, да… Но нет. В команде самое важное — это эффективность. Команда создается не для того, чтобы генеральный директор мог хвастаться тем, что у него в компании есть команды, а чтобы работа работалась эффективнее.Если люди в команде не стремятся работать еще эффективнее, то у них не будет даже желания преодолевать свои ментальные модели. И под эффективностью мы подразумеваем именно эффективность доставки ценности, а не рабочую суету, если кому-то такое пришло в голову…
Что может сделать с этим тимлид? Если ваши коллеги не хотят работать эффективно, то нужно искать новую команду, а лучше — новую компанию. А вот если люди готовы работать эффективнее, то вы можете им в этом помочь.
Что вы можете сделать самостоятельно
Уделять внимание планированию и риск-менеджменту. Вместо того, чтобы в пятницу вечером доделывать что-то за джуном, распределите эти задачи на ваших коллег, а сами займитесь стратегией: а что будет, если у заказчика что-то сломается? Мы запланировали ресурсы на это? А что будет, если на нас сразу упадет три контракта вместо двух, к которым мы привыкли? У нас есть на это ресурсы?Что вам стоит начать или прекратить делать 1:1
Есть два замечательных вопроса:- Знает ли ваш сотрудник цели компании?
- Почему у компании цели для команды именно такие?
И нет, цель компании — это не деньги зарабатывать. И у Майкрософта, и у шавермочной на углу есть цель зарабатывать деньги, но это не то, что отличает одну компанию от другой. Цель компании — зарабатывать деньги, осуществляя определенную деятельность при определенных ограничениях.
Что можно сделать вместе с командой
Вместе с командой можно поставить адекватные цели для команды. Не навязанные сверху, а свои. Это позволит людям понять, что им нужно делать быстрее / выше / сильнее. То ли хороший код писать, чтобы сэкономить ресурсы на поддержке. То ли уменьшать time-to-market, чтобы обогнать конкурентов. То ли создавать больше фич для Бога Фич. Когда люди поймут, какие цели стоят перед командой, они смогут понять, как их достигать эффективнее.四 Принцип Ответственности
Есть популярное мнение, что тимлид должен защищать команду. В целом, да, защищать команду от постоянно меняющихся целей и требований. Но не от опыта.
У меня были случаи, когда желание тимлида побыстрее уйти в отпуск привело к возникновению конкурента, который в итоге превзошел наш проект. Был случай, когда тестировщик поругался с девушкой, что привело к тому, что в ядре оказался critical bug. Был случай, когда желание побыстрее уйти на Новый Год привело к принятию быстрого решения на переговорах, что привело к потере нескольких миллионов долларов. Люди редко думают, как их небольшое быстрое решение приведет к большой катастрофе через год.
Именно здесь мы сталкиваемся с обучением Шизофазиста, который любит экспериментировать, но не любит менять свои ментальные модели. Принцип не означает, что нужно свалить всю ответственность на человека, который предложил инновацию — так не будет никаких инноваций. Это значит, что необходимо включить человека в процесс ликвидации последствий эксперимента.
Что вы можете сделать самостоятельно
Не делать задачи за коллег, а помогать им научиться выполнять их. А как иногда хочется сделать иначе! Вы — опытный человек и думаете: «Господи, я это сделаю за 15 минут, а на объяснение коллеге уйдет 30 минут. Потом он еще сделает неправильно и придется переделывать». Хочется сделать самому. Не надо.Один из моих любимых примеров: новый техлид обучает команду писать хороший код. И его способ вызывает раздражение у многих участников. Дело в том, что в ходе ревью техлид исправляет ошибки коллег, показывает им, как лучше написать, объясняет, почему именно так, а потом… возвращает все назад. Коллеги возмущаются: «Зачем он это делает?! Все уже было в порядке, мы теряем время, мы теряем эффективность!» Да, теряют, в краткосрочной перспективе. Зато получают опыт.
Что вам стоит начать или прекратить делать 1:1
Не говорить коллеге, что делать, а спросить, что он или она предполагает нужным сделать.В результате выяснилось, что не нужно быть разработчиком, чтобы сделать сайт на Тильде. А этого вполне хватает.
Если у вас люди спрашивают: «А что с этим багом делать?», «А что с этим заказчиком делать?», «А у нас база упала — что делать?», то первая реакция: «А ты как думаешь, что делать?» В большинстве случаев человек сам знает, что делать.
Есть еще один волшебный вопрос: «Что мешает это сделать прямо сейчас?» Человек отвечает, что ничего, и вы разводите руками. Это роль тимлида: вы спросили, что человек хочет сделать, что ему мешает это сделать, а потом киваете. И он, вдохновленный, уходит делать, а вы вдохновленный идете пить пиво. Или выполнять рекомендации из пункта про эффективность.
Что можно сделать вместе с командой
Поощрять участников команды помогать друг другу. Может создаться впечатление, что если человек профокапился, то пусть сам с этим и разбирается. Так вот — нет. В эффективной команде люди помогают друг другу. И ваша задача организовать совместную работу, если она не организовывается без вас.五 Принцип Обучения (желательно с первого раза)
Даже в бирюзовой Agile-команде работают простые люди. А людям сложно сказать: «Я ошибся». Даже если их за это не будут харассить, самооценке все равно будет больно. Поэтому принцип обучения для тимлида требует баланса: с одной стороны, нельзя обесценивать ошибку и делать вид, что она ничего не стоит. С другой — нужно сделать так, чтобы человек сделал выводы и изменил свое поведение. Это сложно.
Что вы можете сделать самостоятельно
Показывать пример и признавать свои ошибки. Людям страшно терять лицо, но руководителю терять лицо еще страшнее — он же руководитель! Нужно себя пересилить и признать — да, я совершил ошибку. Показать пример того, как признать ошибку, как сделал выводы и как изменить свое поведение.Что вам стоит начать или прекратить делать 1:1
Начать говорить о том, что вас расстраивает. Люди берегут чувства других людей. Терпят опоздания, срывы сроков и низкое качество, а потом взрываются и высказывают сотруднику такую обратную связь, что он или она идет плакать в туалет. Да, стоит уважительно относиться к чувствам других людей. Нет, не стоит скрывать от них ваше отношение.Также не стоит стесняться расставаться с сотрудниками. Джек Уэлч говорил, что если вы держите у себя сотрудника, который не может расти и плохо работает, а вам это не нравится — то это наказание и для вас, и для сотрудника. Отпустите его. Может быть, он найдет хорошее место, где ему будет комфортно работать. Не превращайте работу сотрудника в ад.
Что можно сделать вместе с командой
Не обвинять коллег и убедиться, что они не обвиняют друг друга. Обвинения лучше всего разрушают обучаемость.Когда вы обвиняете коллег, они начинают защищаться: «Это не моя зона ответственности», «Мне слишком поздно переслали данные», «В сервер ударила молния». И начинается игра в горячую картошку, когда каждый перекидывает друг другу ответственность до тех пор, пока все окончательно не запутаются и просто не забьют на это. Не надо так.
Не обвиняйте людей, потому что если вы хоть как-то начнете обвинять людей, они тут же начнут оправдываться. Когда они оправдываются, включается та самая ментальная модель — «Это не моя вина», «Я здесь ни при чем».
Проводите ретроспективы, для этого они и придуманы. Но… не всегда их проводят правильно. Я полагаю, что одна из лучших инвестиций в свое образование — это чтение книги Норма Керта «Ретроспектива Проекта». Она не про Agile, но мысли там правильные.
六 Outro
Компании существуют для того, чтобы эффективно зарабатывать деньги при определенных ограничениях. Компании не существуют для того, чтобы сотрудники учились на ошибках. Поэтому важно не допускать те ошибки, которые можно легко предвидеть.
Если команда не учится на ошибках — это потери, а не Agile / Teal / Holo. Ошибка — это инвестиция компании в развитие сотрудника, которую сотрудник возвращает тем, что в будущем принимает лучшие решения. Если люди не знают цену ошибке, они не будут стремиться ни к предвидению, ни к обучению. Не экранируйте людей от опыта!
七 У вас все получится!
Трудно поверить, что команда может работать без авралов, люди могут брать на себя задачи и выполнять их в срок, приходить не с проблемами, а с предложениями решений. Хотя… Может, кто-то из вас уже живет в таком мире — напишите об этом в комментариях, поддержите коллег. В этой таблице тезисно то, что было в статье:
Самая лучшая инвестиция — в свое психологическое здоровье. Вторая лучшая — в свое образование. Акции Газпрома и Биткоин идут потом, несмотря на кликбейты от банков. Проще всего фокусироваться на том, чтобы менять других людей и фокусироваться на третьей и четвертой колонках. А эффективнее всего — фокусироваться на второй!
Как команде учиться на своих ошибках?
Мы больше не живем в мире фабрик и заводов, когда от человека можно было требовать четко выполнять свою работу и не ошибаться. В современном мире необходимо, чтобы человек решал нетиповые задачи. А...
habr.com