Ошибки, которые нас учат: как мы делились неудачами и извлекали уроки

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

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

Немного предисловия

Каждый день мы читаем success stories, слышим от коллег и знакомых об их феноменальных успехах, смотрим на их фантастические достижения по проектам. Да мы и сами в одно время вели своеобразный реестр побед команды и хвалились успехами на коммселлах (это одна из регулярных церемоний из Lean-технологий для формирования культуры непрерывного совершенствования команды).

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

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

Факапы – не приговор

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

И вот однажды я узнал про мероприятие под названием Fuckup Nights.

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

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

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

Как мы решили бороться с системой

Айтишников очень часто приходится собирать вместе, чтобы выработать и согласовать проектный подход или какое-то решение, обсудить проблемы, риски и т.д. Хотя в основе своей люди этой профессии – интроверты, но на практике очень часто любят вступать в полемику друг с другом на профессиональные темы.

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

Сначала я заметил некоторое недоверие или сомнение в глазах слушателей, но через 15-20 минут пошли первые комментарии: «Да, ну и дела. Надо было тогда поступить вот так-то и так-то». Коллеги начали подхватывать дискуссию, пошла здоровая полемика, и стало понятно, что формат – зашел.

Прозвучавшие истории из моей практики

… которые остались со мной не только как воспоминания о факапах, но и как отличные уроки на будущее.

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

Что я вынес из этой ситуации? Никогда не игнорировать начальный этап тестирования и не полагаться только на уверения поставщиков ПО. Даже если сроки поджимают, лучше потратить время на дополнительную проверку, чем потом экстренно чинить «сломанную» систему.

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

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

Прозвучавшие истории из практики коллег

… которые прекрасно показывают, что никто не застрахован от ошибок – даже самые опытные сениоры.

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

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

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

2. Еще один коллега рассказал историю про то, как по ошибке разлил заказчику везде клиентскую операционную систему, запихнув в коллекцию SCCM вообще все серверы и компьютеры в организации.

   Вывод: следить за своей внимательностью – наше все. Лучше применять 4-eyes-principle везде, где только это возможно при серьезных изменениях.

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

Как я собирал обратную связь

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

1. Ты учишься смотреть на негативный опыт «по-другому» и перестаешь стесняться о нём говорить.

2. Понимаешь, что ты не один в этом мире «косячник» — рядом с тобой работают такие же люди, как и ты.

3. Коллеги готовы выслушать и дать дельный совет, а обмен негативным опытом помогает всем избежать подобных ситуаций в будущем.

В заключение

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

Неудачи – это не повод для стыда, а возможность для роста. Главное – уметь их анализировать и превращать в опыт. Как сказал один из участников нашей встречи: «Ошибаться – это нормально. Главное – делать это с умом».

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