Инженерный подход к культуре ошибок: что это такое и как сформировать ее в команде

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Функционал пошел частями, так как был под разными задачами. Проблемы тут нет, но обе задачи на этапе планирования должны были быть положены в один спринт, иметь зависимость и маркироваться в релиз. Это было не сделано. Ошибка № 1, которая запустила череду промахов. Лид и проджект некорректно провели планирование.
• Вся команда участвовала в планировании, но неактивно, никто не заметил странностей и не поставил под сомнение действия лида и проджекта. На этапе ревью вопросов также не возникло. Ошибка № 2: команда выключена из планирования и понимания целостности релиза, фичи.
• Разработчик видел задачу, с четким описанием и заголовком UI only, но также не увидел проблем и несостыковок. И просто хорошо выполнил свою часть работы. Ошибка № 3: у разработчика нет понимания, какой фича должна уходить в релиз, нет понимания ценности для пользователя.
• На тестировании инженер проверил только то, что входило в описание задачи. Ошибка № 4. У тестировщика также нет общего представления о готовности фичи к релизу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Попросите человека, не имеющего отношение к команде, собрать ответы и предоставить обобщенные результаты. Их можно переформулировать без искажения смысла и представить в виде сухих фактов. Если вопрос очень деликатный, рассмотрите привлечение внешнего специалиста или анонимную обратную связь через HR-отдел.
2. Включите в опрос несколько вопросов с предсказуемыми или случайными ответами (например, «Какая погода вам больше нравится?»), чтобы затруднить анализ стиля ответов.
3. Используйте вопросы с готовыми вариантами ответов, без свободных для заполнения форм.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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