Привет, Хабр! Меня зовут Мария Киселева, я тимлид команды разработки мобильных приложений для KvadraOS. Мы с командой создаем и развиваем функционал таких приложений планшета KVADRA_T, как Заметки, Сообщения, Файлы, Галерея, Контакты, используя современные технологии и архитектурные подходы.

В своей команде я развиваю здоровую культуру отношения к ошибкам. Проблемы не становятся нашей слабостью, а часто трансформируются в ценный опыт. В статье поделюсь, зачем эта культура ошибок нужна и чем грозит ее отсутствие. Расскажу, как руководитель может помочь команде научиться принимать ошибки, извлекать из них максимальную пользу и не бояться творить и рисковать в разумных пределах. 

Описала свой подход в виде блок-схемы, а для удобного представления данных об ошибке использовала data-класс из Kotlin.

Что такое культура ошибок

Культура ошибок — это то, как в компании на всех уровнях реагируют на ошибки разного масштаба, как с ними работают и какую роль отводят в рабочем процессе. Ее можно рассматривать как комплекс мер и практик, благодаря которым из негативных ситуаций извлекается максимальная польза, а эффекты и последствия решаются быстро.

Как правило, в каждой компании есть негласные порядки работы с ошибками. Результат культуры ошибок или ее полного отсутствия — то, как сотрудник реагирует на совершенную ошибку, какие действия предпринимает, какой реакции ожидает от руководителя и какой итог получает. 

Сразу после окончания университета я работала на оборонном предприятии, пронизанном духом советских времен, с довольно неповоротливой системой управления и сложностями с внедрением современных подходов. Там встречались классические вызовы на ковер в кабинет директора, сотрясающие стены монологи и публичные «порки». 

Чтобы знать, как руководство воспринимает ошибки, не обязательно было их совершать — достаточно было пройти мимо отдельных кабинетов. Как правило, многие люди старались не высовываться, держать мнение при себе, механически делали привычные операции, а при возникновении проблем предпочитали их замалчивать. Это было мое первое место работы, и я посчитала такую ситуацию нормой. 

Впоследствии я поняла, что просто эта компания — яркое проявление отсутствия здоровой культуры ошибок.

Признаки отсутствия культуры принятия ошибок

Выделю несколько маркеров отсутствия культуры ошибок.

Если вы хорошо знакомы с теорией, смело переходите к практике →

Уверенность в том, что ошибка — то, чего нужно избегать всеми возможными способами, что это пятно на репутации и повод усомниться в твоей компетенции. Ведь хорошо продуманная система, идеально настроенные процессы по определению не должны приводить к ошибкам. Большее внимание уделяется подготовительным этапам работы, описанию и обдумыванию теорий, анализу возможных исходов. После столкновения с проблемами не проводится корректировка и пересмотр первоначальных идей. 

Причины такого отношения к ошибкам во многом объясняются теорией «когнитивного диссонанса», которому подвержен в той или иной степени каждый человек. Более подробно об этом можно прочитать в книге Мэтью Сайеда «Принцип “черного ящика”», а также в книге «Теория когнитивного диссонанса» Леона Фестингера.

Каждый промах вызывает резкую и бурную реакцию, пропорциональную его негативным последствиям. Терять время, деньги и клиентов неприятно, но далеко не всегда фатально для стабильной компании. При этом редко кто считает убытки от демотивированной и неэффективной команды. 

На одном месте работы мой начальник любил драматично вздыхать, давить и нагнетать обстановку так, что ощущение собственной никчемности не отпускало несколько дней после устранения проблемы. Работоспособность снижалась в разы, а идти на работу не было никакого желания. Приличная часть рабочего времени могла проходить за командными «нытингами» у кулера.

Поиски виноватых и коллективные разборы ситуаций в обвинительном ключе. Что еще хуже, определение одного виновного и игнорирование участия команды. 

«Публичные эмоциональные разборки и тем более поиски одного виновного — однозначно плохо. Думаю, что большинство людей, попав в такую ситуацию, будут просто увольняться», — уверен лид команды разработки.

Может показаться, что такое возможно только в организациях, застрявших в прошлом. Но, к сожалению, подобное встречается и в современных IT- и не только компаниях разного масштаба.

«Я пришел на проект в IT-подразделение крупной компании, работал 4 месяца под руководством человека, с отличными техническими навыками, софт-скилами и знанием проекта. В команде было всего 8 человек, которые отвечали сразу за все слои — от мобильной части до BSP, сроки были очень сжатые, работа была напряженной. Лид всегда был в курсе работы, параллельно общался с китайцами и пытался тащить по факту нереалистичный проект. Более высокое руководство изначально недооценило масштабы и трудозатраты, нарисовало очень красивые сроки, которые невозможно было выполнить, и релиз постоянно переносился. 

Перед демо для заказчиков лид ушел в плановый отпуск, а на демо возникли проблемы в компоненте, разработку которого забрал не себя другой руководитель, но виноватым сделали моего лида. Не описав причин и не вводя в курс дел, мне предложили занять его должность. После демо было несколько звонков на лидов и команду, на одном из которых в весьма резкой и жесткой форме провал демо свалили на нашего лида и сказали, что мы его меняем, так как он явно не справился. При попытке лида отстоять свою позицию и описать факты начался переход на личности и грубую лексику. У всех присутствующих было полное непонимание ситуации и шок. 

В итоге через несколько месяцев лид ушел. Стало очевидно, что с таким подходом высшего руководства проект обречен, да и атмосфера в команде сильно пострадала. Поэтому спустя недолгое время я тоже принял решение покинуть компанию», — рассказывает ведущий системный архитектор.

Успех — заслуга руководителя, неудача — результат подчиненного. Если ты делаешь хорошую работу, результат присваивается всей команде. Руководитель рассказывает о нем как об общем или даже личном успехе. Неуспех уже так не разделяется, и руководитель не готов брать ответственность за неудачу на себя. 

Устранение проблемы и наказания волнуют больше, чем причины, которые привели к проблеме. Сам факт наказания очень важен, и ему уделяют много внимания. На моем первом месте работы больше тратили время на поиск виновных и проведение воспитательных бесед. При этом анализ причин и фиксация выводов оставались что называется out of scope. 

Проблемой делятся с другими, чтобы обсудить промах человека, а не чтобы перенять опыт и сделать выводы. Командные ретро становятся лобным местом, а не поводом для обучения на ошибках и улучшения работы команды.  

Ошибка — характеристика человека, а не его действий. В таком случае при разборе проблем переходят на личности. Если ты ошибся, ты плохой человек и специалист. 

Возможно, какие-то из описанных пунктов даже вам знакомы. Теперь — к чему может привести следование таким принципам: 

• У сотрудников формируется страх совершить ошибку — даже мелкую, вне зависимости от должности.

• Страх убивает инициативу и творчество, создает излишнюю осторожность и консервативность. Человек в страхе может делать только понятные и проверенные действия, которые точно не сделают еще хуже. В итоге ты можешь видеть новый способ решения привычной задачи, который может сэкономить время и даже вывести продукт на более высокий уровень, но, если есть риски, страх перевесит желание пробовать новое и заставит действовать как раньше. Работает — не трогай. 

• Страх всегда влияет на доверие. Коллеги меньше делятся опытом, стремятся приукрасить или замолчать проблемы, меньше участвуют в обсуждениях. 

• Страх мешает заявить о проблеме максимально быстро. Человек может сто раз подумать, прокрутить в голове последствия и так и не решиться сказать об ошибке, ожидая, что ее либо не заметят, либо она ни на что не повлияет. Хотя часто раннее обнаружение проблемы и своевременное принятие мер может значительно снизить ущерб или даже его предотвратить.

Одна из должностных обязанностей на предприятии у меня была ведение табеля учета рабочего времени. Вести его надо было руками, заполнять ручкой таблицу, напечатанную на листах А2, проставляя отработанное время с кодами по каждому сотруднику. В случае ошибки таблицу нужно было исправлять, ставить подпись или делать отдельный корректирующий документ. 

Один раз при заполнении табеля я перепутала коды и не проставила человеку отпуск, причем понимание пришло уже по дороге на сдачу этого документа. Вносить правку было страшно, потому что это вызывает вздохи и комментарии, совершенно несоразмерные проблеме. Решила оставить как есть, в надежде, что оно как-то само там разрешится. Но, конечно, сотрудник заметил подозрительную сумму отпускных и пошел разбираться. Эффект нагнал и меня: негативных высказываний и взглядов стало больше, потому что коллега был сильно недоволен. Тогда я не рассуждала о культуре ошибок и принимала существующие порядки как норму, но для себя решила выявлять проблемы сразу — так дешевле.

• Может появится нежелание расти и брать больше ответственности, решать задачи сложнее. Чем шире и сложнее круг задач, тем ошибки могут быть серьезнее. 

• Общая демотивация и напряжение в команде.

По данным моего небольшого опроса, большинство коллег не видят себя в такой компании и будут стремиться на выход.

Признаки здоровой культуры ошибок 

Теперь — какое в идеале должно быть отношение к ошибкам, если вы хотите поддерживать здоровую и продуктивную атмосферу в команде.

Из промахов не делают катастрофы, их вес и влияние не преувеличивают. Ошибка — часть рабочего процесса, один из этапов достижения успеха, а не шаг назад. Мне очень понравилась одна мысль: «Если написанный код запускается и работает как надо с первого раза, это подозрительно». Ошибаются все, и это нормально. Провалы — это зоны роста, а не ограничения. К ошибкам относятся как к опыту, который при должном применении позволяет двигаться дальше.

На заводах Toyota вдоль конвейеров располагается сигнальная система (шнур) — Andon (с япон. — лампочка). С ее помощью каждый оператор должен сообщить руководителю о возникшей проблеме или любом отклонении от процесса. Делается это для того, чтобы приостановить работу и не передавать брак на следующий этап. Руководитель реагирует на сигнал, анализирует проблему, вносит корректировки, и работа продолжается дальше. Никаких разбирательств, главная цель — остановить процесс ради улучшения качества продукта.

Существуют поддержка и помощь со стороны команды и руководителя, проблемы обсуждаются открыто и без осуждения. При таком подходе люди испытывают меньше давления и стресса, готовы к экспериментам и внедрению новых идей, чувствуют больше свободы в действиях, а в командах формируются более доверительные отношения и спокойная атмосфера.  

При этом открытое обсуждение ошибок проходит на разных уровнях компании. Здорово, если топ-менеджмент не замалчивает проблемы, а рассказывает о них на общих встречах компании, показывая тем самым отношение к ним. Здесь и про признание ошибки, и про присвоение даже негативного опыта, умение с ним работать, а также про желание своим примеров помочь другим.

На одной из встреч с руководителями YADRO топ-менеджмент спокойно, открыто и просто рассказали об ошибке в одном подразделении, которая стоила компании не критичных, но крупных денег. Генеральный директор поделился причинами, реакцией, выводами и комплексом мер, которые собираются принять. 

На контрасте с опытом работы в других компаниях меня поразила честность и открытость, с которой подавалась информация. Да, это ошибка, но мы не делаем из этого трагедии и знаем, как ее исправить. Когда руководство открыто заявляет о промахах в компании, дает строгую оценку своей работе и объясняет, почему именно так, автоматически формируется доверие и понимание, как можно решать похожие ситуации у себя в командах. 

При анализе проблемы учитывается роль каждого члена команды и его вероятный вклад в негативный результат. Изучение проблемы привязано к процессу и предполагает комплексный подход, учитывает всех участников и связи между ними, а не вину конкретного человека.

Однажды мы отправили в релиз UI без бизнес-логики. Кнопку добавили, а действие нет. Несмотря на большую команду и несколько этапов тестирования, узнали мы об этом уже после релиза. На первый взгляд, все просто: убийца — дворецкий виноват тестировщик — плохо проверил, дело закрыто, расходимся. Вывод — надо лучше тестировать. Так размышлять быстро и удобно, но бесполезно.

Какая картина получается при детальном рассмотрении:

• Функционал пошел частями, так как был под разными задачами. Проблемы тут нет, но обе задачи на этапе планирования должны были быть положены в один спринт, иметь зависимость и маркироваться в релиз. Это было не сделано. Ошибка №1, которая запустила череду промахов. Лид и проджект некорректно провели планирование.

• Вся команда участвовала в планировании, но неактивно, никто не заметил странностей и не поставил под сомнение действия лида и проджекта. На этапе ревью вопросов также не возникло. Ошибка №2: команда выключена из планирования и понимания целостности релиза, фичи.

• Разработчик видел задачу, с четким описанием и заголовком UI only, но также не увидел проблем и несостыковок. И просто хорошо выполнил свою часть работы. Ошибка № 3: у разработчика нет понимания, какой фича должна уходить в релиз, нет понимания ценности для пользователя.

• На тестировании инженер проверил только то, что входило в описание задачи. Ошибка № 4.  У тестировщика также нет общего представления о готовности фичи к релизу. 

Получился прекрасный командный скрининг. В итоге у нас совершенно другой набор причин, где тестировщик не становится «козлом отпущения», и куча пунктов, которые можно проработать. Лично меня эта проблема даже порадовала, столько открытий сразу!

В первую очередь человек — тот, кто решает проблемы, а не тот, кто их создает. Это просто нужно рассматривать как догму, в таком случае и отношение к ошибкам изменится.

Перейдем от теории к практике, и рассмотрим, что поможет построить здоровую культуру отношения к ошибкам.

Как сформировать здоровую культуру ошибок в команде 

В идеальной картине мира культура ошибок формируется руководством на уровне компании, транслируется в команды и поддерживается каждым сотрудником. 

К сожалению, бывает, что «наверху» этому не уделяют внимания или придерживаются других ценностей. Если компания достаточно крупная и от топ-руководителей до сотрудника приличное количество ступеней, линейный руководитель может формировать культуру ошибок на уровне команды. Даже если общего курса на это в компании нет. Но важно учитывать, что соприкосновения с другими командами, где такой культуры нет, могут быть весьма конфликтными. Защита и поддержка атмосферы внутри вашей команды будет отнимать силы и время. Стоит ли оно того? Зависит от большого количества факторов, но я считаю, что да.

Если компания маленькая и шансов повлиять на руководство нет, варианта только два: либо играть по правилам, либо искать более подходящее по ценностям место. Тут каждый решает сам, насколько этот фактор для него определяющий. 

Теперь представим, что непреодолимых препятствий внедрять культуру ошибок нет. Что делать? Посмотрим на это глазами руководителя. 

Примечание: Как внедрить культуру ошибок снизу вверх (например, если руководитель не видит в этом необходимости), я рассказала в бонусной части. Советы подойдут как рядовому сотруднику, так и руководителю, который стремится продвинуть изменения на уровни выше.

Сложно требовать от команды конструктивных обсуждений в стрессовых ситуациях и умения легче относиться к ошибкам, если сам начинаешь истерить и рвать свои и чужие волосы. Поэтому первыми шагами для руководителя должна быть работа над собой: понимание культуры ошибок, следование ей в любых ситуациях и принятие возможного дискомфорта, связанного с ней (например, придется открыто говорить о своих ошибках). И только после этого можно распространять культуру на команду. Несоответствие поведения руководителя тому, что он транслирует сотрудникам, всегда очень заметно. 

Итак, как руководитель может помочь команде чувствовать себя свободнее, не бояться вызовов и идти на риски:

• развивать необходимые навыки — например, навык давать обратную связь — у себя и коллег,

• формировать и поддерживать атмосферу в команде,

• показать пример.

Разберем эти пункты подробнее.

Помогите команде научиться давать и принимать обратную связь

Обсуждение ошибок — это работа с обратной связью. Важно не только корректно ее давать (сообщать о проблеме/ошибке), но и принимать — не воспринимать критику на свой счет. От этих умений может зависеть скорость решения проблемы, полученный результат и общее отношение команды или сотрудника к ситуации. Если люди не могут сформулировать полезный и ясный фидбэк и при этом остро реагируют на любые дельные замечания, внедрить культуру ошибок будет сложно.

Особенно усердно навык стоит развивать руководителю. Важно научится давать обратную связь вовремя, опираясь на факты, детально и понятно, приходя к зафиксированным договоренностям. Не просто указать на ошибку, а подробно описать, что не так. При этом оценивать только действия человека, а не его самого. 

Как быстро проверить этот навык в команде? Попросить каждого дать обратную связь на какого-нибудь коллегу, с которым сотрудник больше всего работал за прошедший год/месяц/неделю. Кто-то уходит думать и возвращается с подробный ответом, кто-то выдает через 15 минут качественный и полезный ответ, кто-то формулирует слишком абстрактно или вообще затрудняется с ответом. Так вы получите список людей, кому стоит помочь с развитием навыка, а кто уже хорошо прокачался. Кстати, такое упражнение можно проводить с определенной периодичностью (например, в ежеквартальные 1:1), чтобы следить за ростом этого навыка.

Что почитать 

→ «Радикальная прямота», Ким Скотт. Книга помогла мне изменить отношение к корректирующей обратной связи и выработать стратегию в донесении ее коллегам. Для меня она про честный и прямой диалог, цель которого — совместный поиск причин и решений, а не отчитывание сотрудника. 

→ «Мама, я тимлид! Практические советы по руководству IT-командой», Марины Перескоковой. В ней, на мой взгляд, глубоко раскрывается роль руководителя в формировании отношений внутри команды. 

Делитесь с командой своими ошибками и показывайте, как с ними работать

Если руководитель разбирает только ошибки команды и никогда не озвучивает свои, любые теории, как было бы здорово с культурой ошибок, останутся только красивой теорией. Белое пальто придется снять и показать грязные рукава. Руководитель — тоже человек, и команда должна это видеть. Когда руководитель спокойно рассказывает о проблемах, в какой-то момент это становится нормой для всех. 

За свой менеджерский опыт я успела совершить приличное количество ошибок разного калибра и урона. Конечно, не о всех я докладываю команде, но самые показательные и интересные кейсы стараюсь выносить на ретро или дейли.

Например, моей команде нужно было сделать редизайн платформенного приложения Контакты. Дизайн современный, код древний, часть функционала новая и плохо ложилась на существующие реализации. Было два варианта: писать в той парадигме, что есть, или накрутить на имеющуюся базу новые части на современном стеке (Koltin + Compose внутри Java + XML). Я приняла решение идти вторым путем. В итоге к релизу мы откатывали все реализованное.

Потратили много времени, разработчику нужны новые глаза, а тестировщику — курс валерьянки. Подробнее о нашем приключении можно прочитать в этой статье. Эту историю мы обсуждали в разных командах с упором на «как не надо делать и, пожалуйста, не повторяйте». И да, это была и моя ошибка (техническое решение согласовала именно я), и ошибка команды. Мы разобрали ситуацию и сделали выводы — катастрофы не случилось. Когда подъехал свежий дизайн, мы начали писать все с нуля, уже точно зная, что это будет не дольше и сделать хуже уже вряд ли возможно. При всех неприятных моментах это был хороший опыт.

Признавать свои ошибки сложно, особенно перед командой и теми, кто пострадал. Но, видя, что мир не рушится, многое можно исправить, опыт и доверие в команде растут, а команда готова выслушать и поддержать, становится чуточку проще.

Проговорите право на ошибку и наделите им сотрудника

Важно прямо и достаточно подробно обозначать варианты развития событий, если что-то пойдет не так. Какая будет реакция и отношение, к кому можно будет обратиться за помощью. Просто сказать, что такое возможно, мы об этом знаем и учитываем. 

Это можно делать на личных встречах как общий посыл отношения к результатам человека или в момент постановки задачи, особенно если она более высокого уровня сложности. Может показаться, что это все актуально только для младших специалистов, ведь старшие должны работать идеально — «они ж сеньоры», у них больше опыта. Но я бы не ориентировалась на должности, а смотрела на реакцию и поведение человека. Если у опытного специалиста вьетнамские флешбеки с прошлой работы, с ним тоже стоит проговорить право на ошибку. 

Иногда, чтобы люди не делали ошибок, нужно просто разрешить им их делать. Главное — не превратить спокойную рабочую атмосферу в равнодушие и нездоровый пофигизм. Об этом далее будет отдельная глава. 

Конечно, чем опытнее человек, тем проще он относится к новым вызовам — как правило, у него быстро появляется какой-то план в голове. Но положительный эффект такого «права на ошибку» отмечают многие. 

В опросе я также предложила коллегам поделиться мыслями, как повлияет на работу над сложной задачей разговор на тему «план Б». Когда руководитель при обсуждении задачи проговаривает варианты развития событий, если что пойдет не так, и сообщает, кому прийти за помощью в таком случае. Из ответов получилось собрать такое облако тегов:

Поскольку я сторонник индивидуального подхода, стоит отметить, что не 100% опрошенных чувствуют уменьшение стресса. Есть коллеги, для кого проговаривание таких условий, наоборот, создает некомфортные условия  — они ищут какой-то подвох. Поэтому стоит ориентироваться на каждого человека отдельно, чтобы не нанести добро там, где это не требуется.

Обсуждайте проблемы без эмоций, как часть рабочего процесса

Если ошибка серьезная и обнаружилась только что, резко выключить эмоции и обсуждать только детали очень сложно. Но, к сожалению, добавление экспрессии и образной лексики никак не поможет решить проблему — только навредит отношениям в команде. А вот умение руководителя сбросить градус — свой и задетых сторон, выстроить конструктивное обсуждение, позволит ускорить решение проблемы, минимизировать потери и сохранить хорошие отношения.

Опять же, от того, как руководитель будет реагировать и в каком ключе вести диалог, будет зависеть поведение команды в похожих ситуациях. Здесь не обойтись без личного примера: важно показать, как можно решать проблемы, демонстрируя разные варианты развития событий и их эффект коллегам.

В ходе работы над одним приложением изменения в компоненте нашей команды усложнили работу смежной. Руководитель смежной команды отреагировал очень эмоционально. При этом быстрое и выгодное для них решение сильно ухудшало работу нескольких команд разработки. Проблему нужно было решить максимально спокойно, так как мы хотели сохранить хорошие отношения со смежной командой. А еще — быстро. 

Задача для лида рабочая, но с массой нюансов — потребовалось взять небольшую паузу для продумывания шагов. В итоге спокойная реакция на эмоциональность и искренняя заинтересованность в проблеме всех успокоила. Мы проговорили пути решения, первичные шаги и сроки. Обсуждали только четкий план и детали, без разбирательств и выяснения отношений. Лично мне в этой ситуации помогли понимание истоков такой эмоциональной реакции, фокусировка на решении и важности сохранить хорошие отношения. Результатом была очень довольна: мы нашли общий язык, решили проблему и продолжили вместе работать без негативного «осадка».

Относитесь к ошибкам с юмором, где это уместно

Иногда ошибки бывают очень смешными. Не вижу ничего плохо в том, чтобы от души посмеяться всей командой над какой-нибудь забавной мелочью, а потом пойти и исправить ее. Такие истории превращаются в командные байки и сплачивают коллектив. 

Как-то, когда я работала в команде приложения мобильного банка, меня подвел русский язык, а именно — окончания. Нужно было брать текущий месяц и ставить его в правильном падеже (в апреле, марте и т.п.). Задачу решила весьма просто и быстро (с кем не бывает): убирала последнюю букву и прибавляла к строке окончание -е. Вроде все проверили, но не до конца. Проблема вскрылась на проде в марте, когда на баннере засияло слово маре, вместо марте. Ошибка некрасивая, на виду у всех клиентов — стыдоба, но мне было дико смешно. Коллеги поддержали. Ошибку поправила быстро, выводов сделала много, запомнила на всю жизнь, при этом с позитивной окраской.

Работайте с атмосферой в команде после неудач

Проблемы нередко оставляют неприятный осадок, который может сказаться на мотивации отдельного человека или всей команды. Не стоит оставлять это без внимания и ждать, когда все само нормализуется. Этот момент безусловно настанет, но может либо затянуться, либо отложиться где-то глубоко и всплыть в похожой ситуации, усложнив ее. 

Что можно попробовать:

• Предложите команде обсудить проблему на ретро, синке с другими командами или дейли. Чем больше мы говорим о проблеме, тем меньший негатив она вызывает — с каждым разом обсуждать ее будет все проще.

• Предложите написать статью или организовать небольшой knowledge sharing, делая упор на пользу, которую команда получила в результате этой ошибки.

• Соберитесь на мероприятие по случаю провала и поделитесь мнениями в свободном формате.

Компания Spotify проводит командные встречи fail-fika (fika с шведского — «посидеть за чашечкой кофе и поболтать»). На них сотрудники празднуют неудачи, проводят ретроспективу, чтобы увидеть возможности и извлечь уроки из того, что получилось не очень хорошо.

Когда люди начинают более свободно обсуждать проблемы и признавать ошибки, важно подмечать такие моменты и благодарить, особенно полезно это делать публично. Чтобы не только человек получил положительный опыт, но и вся команда.

Бывает, сообщать публично о проблемах могут не все и не сразу. На первых этапах можно дать команде возможность писать о них анонимно. Это поможет получать необходимую информацию даже от людей, которые привыкли держать свое мнение при себе. Среди инструментов, которые можно использовать для создания анонимных опросов, выделю Google Forms, Yandex Forms, Survio , Formdesigner. 

Анонимность проще организовать для больших команд, но для маленькой из 3-4 человек потребуется особый подход. Вот несколько практических решений для сохранения анонимности:

• Попросите человека, не имеющего отношение к команде, собрать ответы и предоставить обобщенные результаты. Их можно переформулировать без искажения смысла и представить в виде сухих фактов. Если вопрос очень деликатный, рассмотрите привлечение внешнего специалиста или анонимную обратную связь через HR-отдел.

• Включите в опрос несколько вопросов с предсказуемыми или случайными ответами (например, «Какая погода вам больше нравится?»), чтобы затруднить анализ стиля ответов.

• Используйте вопросы с готовыми вариантами ответов, без свободных для заполнения форм.

Небольшое отступление про руководителей и отношение к ошибкам подчиненных

Я уже не раз вспоминала свой опыт на оборонном предприятии. Общая атмосфера там не очень вдохновляла на откровенные разговоры про ошибки, но мне повезло с руководителем. Несмотря на общий фон, у него были свои ценности и принципы — про людей и здоровое восприятие рабочего процесса. Несколько его мыслей очень сильно врезались мне в память и впоследствии стали основой для меня как начинающего руководителя:

• Если сотрудник совершил ошибку, это также моя ответственность как руководителя — результат моих решений. Даже если кажется, что проблема — итог работы твоего сотрудника, так не бывает, постарайся копнуть глубже. 

• В 99% проблем в жизни часто виноваты мы сами и должны брать на себя ответственность за их решение. Даже если все выглядит как сумма внешних факторов и действий других людей, почти всегда можно найти связь со своими решениями. Это утверждение может казаться жестким и несправедливым, но оно сильно упрощает отношение ко всем возникающим сложностям. Ты не тратишь время на сетования и поиски виноватых, а сразу переходишь к решению проблемы.

Во многом поэтому в командной работе не может быть одного виноватого. Даже если сотрудник оказался некомпетентным, возникают вопросы: кто его нанял, как была организована проверка его навыков на старте и так далее. 

Как относиться к ошибкам проще: лайфхак для технарей и не только

Ошибки можно рассматривать как задачи, возникшие в ходе решения другой задачи. Только, как правило, с экстремально короткими сроками выполнения и большим потоком информации, в которую ты входишь с не самым высоким уровнем мотивации и возможным давлением со всех сторон.

По своему складу мышления мне привычно сильно упрощать комплексные понятия, концентрироваться на общих чертах, а детали рассматривать как дополнения. Если проводить аналогию с разработкой, то мне нравится выделять у всего схожего интерфейсы и абстрактные классы, а все частные случаи считать деталями реализации. Например, какой data-класс можно выделить у ошибки:

 class Error {
  // что нужно было сделать
  var task
  // что пошло не так
  var errorDetails
  //какие возможные последствия уже есть или последуют и кто может пострадать
  var effect
  //причины ошибки
  var reasons
  //плюшки от решения сложившейся ситуации
  var benefits
  //выводы
  var experience
 //список улучшений, которые можно сделать, чтобы минимизировать повторение ошибки
  var actionItems
 }

Например, я неверно оценила сроки выполнения целого скоупа задач, входящих в MVP для приложения Сообщения — ошиблась ни много ни мало на целых два релиза. Никто не пострадал, но ситуация по многим аспектам неприятная. Как бы выглядела реализация интерфейса для данного случая:

class BadEstimationForMVPMessaging {
  
  var task = эстимация MVP для приложения Сообщения. Необходимо оценить все задачи, распределить по спринтам и релизам, учесть загрузку команды и выдать предполагаемую дату релиза
  
  var errorDetails = ошибка в эстимации на два релиза (два месяца разработки команды из трех человек)
  
  var  effects = listOf(
  - релиз переносился два раза
  - демотивация команды
  - вопросы с продуктовой стороны
  )
  
  var reasons = listOf(
  - часть задач были сильно недооценены
  - не учтены зависимости, которые, конечно, вылезли только в конце
  - не заложен запас по времени
  )
  
  var  benefits = listOf(
  - хороший пример, который можно разобрать
  - прокачан навык работы с ожиданиями
  - ощутили дух стартапа с командой, решая внезапные блокеры перед релизом, и радовались запуску приложения
  )

  var experience = listOf( 
  - детальнее искать зависимости на этапе подготовки к эстимации
  - закладывать запас по времени в 2-3 релиза
  - на задачи с неизвестными апишками и стеком увеличивать коэффициент Пи*
  )
  
  var actionItems = listOf(
  - составить чек-лист для подготовки к запуску новых приложений, на который можно ориентироваться всем командам
  - обсудить с командой процесс выявления зависимостей
  )
 
}

class OneWayTickets {
  
  var task =
  купить билеты из Нижнего Новгорода до Москвы и обратно
  
  
  var  errorDetails =
   оба билета куплены из Нижнего Новгорода до Москвы
  
  
  var effects = listOf(
  - заплатила комиссию за поздний возврат билетов
  - стонущий ребенок
  - много вопросов к себе
  - до ближайшего поезда в Нижний Новгород около двух часов
  - домой вернулись после полуночи, что никак не входило в планы
  )
  
  var reasons = listOf(
  - зачем-то сильно торопилась при покупке билетов
  - не проверила накануне и не попросила кого-то проверить вместе со мной
  - стойкая уверенность, что тут я точно ничего не перепутаю
  )
  
  var benefits = listOf(
  - поезд шел поздно и был полупустым
  - получила полезные знания о себе
  )
  
  var experience = listOf(
  - покупать билеты в спокойной обстановке, не занимаясь параллельно чем-то другим
  - проверять несколько раз
  )

  var actionItems = listOf(
  - составить памятку, пока не войдет в привычку
  - договориться с мужем, что он проверяет билеты за несколько дней перед поездкой
  )
}

Описание ошибки таким образом превращает ее из нечто пугающего и расплывчатого во вполне понятную структуру и комплекс мер, который помогает упорядочить мысли и снизить неопределенность. Проблема становится чем-то формальным и механическим, тем, что нужно решить и описать, без лишнего самокопания.  

Алгоритм «программы» разбора ошибок 

Теперь добавим методы, которые помогут нам заполнить необходимые поля и создать стройную и понятную структуру из хаоса входящей информации. А также опишем алгоритм для нашей «программы» разбора ошибок. Почему программы? Потому что у нее нет эмоций, а только набор четких инструкций. Конечно, совсем убрать естественную реакцию на проблему не получится, но это и не наша цель. Главное — постараться изменить восприятие проблемы, сместить фокус в сторону поиска решения и сосредоточиться на выполнении действий, направленных на устранение последствий.

Представим, что блоки алгоритма — это методы, которые помогают нам заполнять поля класса Error.

→ Работа начинается с осознания ошибки и первых действий. Здесь часто приходит поверхностное понимание последствий ошибки, и запускаются первые эмоциональные реакции — от страха и паники до злости и отчаяния. 

→ Отдельным шагом я вынесла проживание эмоций, так как считаю это важным. Желательно не игнорировать этот этап. Чем качественнее и быстрее он пройдет, тем эффективнее и проще будет движение дальше, весь фокус внимания будет уже на действиях, а не на эмоциях. На этом этапе начинает работать культура ошибок и влиять на действия человека: как скоро он сообщит о проблеме и насколько полную и честную информацию предоставит. 

Работа с эмоциями — это отдельная и очень индивидуальная тема, которой посвящено уже немало книг и статей. В этой статье останавливаться на этом я не буду. 

Тут собирается информация для полей errorDetails и effect, которые впоследствии могут дополняться данными от других участников, и формируется понимание, нужно ли подключать кого-то к обсуждению проблемы и когда.

→ Отдельно выделю роль руководителя. Его поведение и взаимодействие с сотрудником можно считать итоговым экзаменом по внедрению культуры ошибок. Когда руководителя подключают к проблеме, его задача — оказывать помощь и поддержку на всех дальнейших этапах. 

Чем может помочь руководитель:

• Помочь найти решение, предоставить ресурсы и подключить других людей, если это необходимо. Важно — не решать самому, не перекладывать всю ответственность на себя или найти другого исполнителя, а создать комфортные условия для работы над проблемой.

• Контролировать эмоции — свои и команды, снижать градус обсуждений, если он начинает расти.

• Общаться с пострадавшими и заинтересованными сторонами, если это другие руководители и смежные команды, особенно при угрозе конфликта. Выступать экраном от внешних воздействий, пока сотрудник решает проблему, и препятствовать любым попыткам давления и деструктивным разговорам.

• После решения проблемы, в формате 1:1, помочь провести анализ действий, которые привели к ошибке. Совместно сформулировать выводы и зафиксировать в виде action points, если это возможно. Дать качественную обратную связь — как корректирующую, так и положительную. Поблагодарить, называя конкретные действия, без общих понятий из разряда «молодец, все правильно сделал».

• Организовать обсуждение с командой, если это уместно и принесет пользу.

• Оценить моральное состояние сотрудника и учитывать его при работе и постановке следующих задач.

→ Собрав всю информацию, заручившись поддержкой руководителя и получив необходимые ресурсы, мы переходим к решению. Зачем столько этапов, если по факту все просто: нашел проблему — исправил? Но если цель — решить проблему эффективно, сделать так, чтобы она не повторялась, укрепить отношения в команде, стоит уделять больше внимания и времени таким ситуациям. Иначе истинные проблемы могут остаться без решения и выстреливать снова и снова. Все равно что постоянно принимать снотворное при бессоннице, вместо того чтобы наладить режим сна. 

→ Следующий этап направлен на заполнение списка reasons (причин). В большинстве случаев настоящие причины возникновения ошибки могут лежать очень глубоко и быть далеки от задач и даже предметной области. Поэтому эта часть одна из самых сложных в алгоритме. Лучше всего разобраться помогает навык задавать открытые вопросы и техника «5 почему» (5W). Подробнее о них вы можете прочитать в этой статье. 

В дополнение, чтобы не упустить множественные причины можно использовать диаграмму Исикавы («рыбья кость»). Она помогает визуализировать причины проблем по категориям, систематизирует их и позволяет учесть те варианты, которые могут быть упущены при использовании метода «5 почему» из-за линейности подхода.

→ После выявления и анализа причин необходимо сделать выводы и составить план дальнейших действий. Так мы заполняем поля benefits, experience и actionItems. Поле benefits неслучайно так названо и вынесено отдельно. Как намек на то, что результат любой работы над ошибками — это выгода в виде улучшения процессов и жизни, а не списки ущерба и виноватых. Это не самое простое упражнение, но важно найти как можно больше положительных моментов.

Чтобы выводы и решения не оставались на словах, важно их четко сформулировать и зафиксировать, назначить ответственных и определить сроки реализации. Например, часто в ходе командного ретро, когда мы обсуждаем проблемные зоны, мы составляем список задач-действий и указываем ответственного. Каждую следующую встречу проходимся по списку, закрываем выполненные и обсуждаем статус открытых.

→ Можно пойти еще дальше и поделиться полученным опытом с другими командами. Как это можно сделать:

• Подготовить краткую информацию, отражающую важные моменты и детали решения проблемы. Выложить в общедоступной базе знаний. Data-класс отлично подойдет как шаблон для такого описания.

• Рассказать о своем опыте на кросс-командном синке, ретро или провести отдельную встречу для всех заинтересованных.

• Выйти за рамки своей компании и написать, например, статью на Хабр. Или, если проблема распространенная, в результате ее решения родились новые подходы, которые значительно улучшили процессы или продукт и их можно масштабировать, можно доработать материал и отправиться на профильную конференцию.

Все эти шаги нужны для того, чтобы использовать уникальную возможность извлекать пользу из ошибок и научится чему-то новому, улучшить систему, найдя ее несовершенства. Итогом проделанной работы становится бесценный опыт, который мы записываем в переменную experience.

Как не перегнуть палку 

Любая хорошая идея может иметь негативную крайность. Для культуры ошибок это может стать слишком расслабленный подход к работе, халатное и невнимательное отношение к задачам, ощущение вседозволенности и безнаказанности — «могу делать как попало, все равно мне за это ничего не будет».

Культура ошибок — это не «можно все», а «можно ошибаться, но нельзя бездействовать и не учиться на своих ошибках». Внедрение культуры ошибок без ухода в крайности — это баланс между открытостью к промахам и сохранением ответственности. Как этого можно достичь:

Четко определите границы допустимого. Разделите ошибки на категории:

→ Допустимые: непреднамеренные промахи в новых задачах, эксперименты, ошибки из-за недостатка информации.

→ Недопустимые. Есть вещи, которые никогда нельзя делать вне зависимости от наличия культуры ошибок: нарушения этики, безопасности, повторение одних и тех же ошибок из-за халатности. Например, можно ошибиться в новом проекте, но нельзя игнорировать инструкции по технике безопасности.

В команде должно быть общее знание и понимания этих границ, и каждый сотрудник должен соблюдать их.

Обозначьте ответственность за исправление. Если ошибку совершил один человек, а решает ее другой сотрудник или только руководитель — это плохой расклад. Разрешая ошибаться, требуйте участия в «расхлебывании» последствий (конечно, если это в рамках возможностей сотрудника). Идеальный порядок может выглядеть так: 

• Сотрудник, допустивший ошибку, участвует в устранении ее последствий.

• Команда совместно ищет способы предотвратить повторения ошибки.

Взращивайте ответственность и показывайте вклад каждого в успех компании. Часто по структуре команда может быть очень далека от высшего руководства и глобальных целей компании. Сотрудники хорошо знают круг своих задач, но не понимают свой вклад в общий результат. От этого у них может формироваться ощущение, что их задачи никак не влияют на достижение стратегических целей и прибыль, а значит, не так уж и важно, накосячил ты или нет.

Задача руководителя — показать команде связь работы каждого с глобальными целями компании. Как, например, новая фича может повлиять на успех продукта и какие последствия будут в случае неудачи. Если у продукта есть пользователи, то тут добавляется осознание, что фича не уходит в вакуум, а попадает в руки к реальным людям. Эта часть ответственности должна быть передана и понятна каждому члену команды вне зависимости от должности. Понимание своей роли в команде, вклада в продукт и компанию формирует причастность и ответственность за свои действия, а значит, и влияет на отношение к ошибкам.

Как внедрить культуру принятия ошибок в команде, если ты сотрудник

И обещанный бонус. Не всегда руководитель видит необходимость в формировании культуры ошибок. По инерции он может не замечать, как отсутствие такой культуры демотивирует команду и влияет на ее результаты. В этом блоке мы рассмотрим, как попробовать переубедить руководителя — вышестоящего или линейного. 

Сразу скажу, что я не сторонник методики вбросить идею на общем собрании и, ждать когда ее кто-то реализует. Если хочется изменений, придется что-то делать. В моем представлении стратегия «У вас тут все плохо, надо бы сделать хорошо или хотя бы нормально» не работает нигде и никогда. Поэтому первым шагом к изменениям может стать качественно продуманный план, проработанная и оформленная идея, с понятными выгодами для команды, руководителя и в идеале для компании. Чем лучше вы подготовитесь к переговорам (а это именно они), тем выше шансы получить положительный результат.

Как подготовиться:

• Проанализировать работу команды, собрать примеры конкретный рабочих моментов, когда отсутствие культуры ошибок сильно сказалось на скорости и качестве решения задач. 

Например, Вася вовремя не сообщил об ошибке или вообще о ней не сообщил, потому что не хотел разбирательств. Проблема вскрылась сама в не самое подходящее время. Из-за этого Петя выполнял свою задачу на неделю дольше, пришлось подключить еще пару людей и потребовалось больше обсуждений. Также Петя потратил время на анализ проблемы, хотя у Васи уже была эта информация. 

• Главное в примерах — добавлять как можно больше данных об увеличенных сроках, лишних операциях и вовлечении других людей. Минусы должны быть измеримы и понятны, а выгода значима и очевидна.

• Для каждого примера стоит описать возможный вариант развития события, если бы в команде было сформировано другое отношение к ошибкам.

Например, Вася сразу же сообщил команде о проблеме, как только ее выявил. Это сэкономило бы неделю Пети, он мог бы это время потратить на важный баг, а другие ребята могли бы завершить свои задачи быстрее, так как не отвлекались на звонки, обсуждения и помощь.

• Пообщаться с коллегами, узнать их мнение и заручиться поддержкой. Мнение одного человек и всей команды или хотя бы какой-то ее части могут возыметь разный эффект. 

• Подготовиться отвечать на вопросы по теме, изучить рекомендации и теорию по культуре ошибок, поделиться ими с руководителем. Продумать возможные причины для отказа и аргументы для парирования. 

• Описать примерный план внедрения изменений, какие шаги необходимы, сколько времени и каких затрат потребует.

• Выбрать удачное время для разговора. Например, мой руководитель дал вполне четкие инструкции, когда лучше всего приходить с идеями. Я люблю прийти после выходных в понедельник, а для многих это не лучшее время для восприятия перемен.

• Нужно быть готовым, что потребуется несколько заходов и кругов обсуждения. После каждого отказа стоит сделать выводы, доработать идею и аргументы, выждать время и повторить все шаги сначала. 

Вместо заключения 

В статье я постаралась собрать свои мысли и опыт на тему, которую, на мой взгляд, можно считать основой построения взаимоотношений в команде, а также развития и достижения целей. Использую ли я все описанные практики каждый день? Однозначно нет, я тоже человек. Это большая и сложная работа прежде всего над собой, но она того стоит. 

В завершение дам еще несколько рекомендаций по литературе. Например, книгу «Как научиться оптимизму: Измените взгляд на мир и свою жизнь» Мартина Селигмана. В ней автор подробно описал выученную беспомощность и ее влияние на все аспекты жизни, в том числе на карьеру. А еще — дал хорошие инструкции, как научиться более позитивно реагировать на сложности и неудачи. 

Очень подробно и полно причины отрицания ошибок и возникновения культуры негативного отношения к ним описаны у Мэтью Сайеда — в уже упомянутой ранее книге «Принцип “черного ящика”». На примерах здравоохранения, авиации, правосудия автор разбирает влияние разных подходов на развитие системы, а главное — связь успеха и неудач. В ней вы найдете множество показательных примеров, которые заставляют задуматься и обратить внимание на важность культуры ошибок как в компании, так и жизни каждого человека. 

А пытаетесь ли вы создавать культуру ошибок в команде? Делитесь своим опытом в комментариях!