Ошибки, которые нас учат: как мы делились неудачами и извлекали уроки
Привет! Меня зовут Фаиль, и я работаю руководителем проектов. До всем известных событий моя команда была частью всемирно известного сервис-провайдера, и мы совместно делали бизнес, обслуживая ИТ-инфраструктуру наших зарубежных заказчиков и занимались проектной деятельностью.
Сейчас работаем над тем же самым, но уже преимущественно на отечественного клиента. Культура ведения бизнеса и выстраивание зрелых процессов в своей работе при этом остались те, которым научились и к которым привыкли, работая на импорт.
Немного предисловия
Каждый день мы читаем success stories, слышим от коллег и знакомых об их феноменальных успехах, смотрим на их фантастические достижения по проектам. Да мы и сами в одно время вели своеобразный реестр побед команды и хвалились успехами на коммселлах (это одна из регулярных церемоний из Lean-технологий для формирования культуры непрерывного совершенствования команды).
И как-то так получилось, что в обществе сформировалось негласное табу на разговоры о неудачах. Вспомните вечер встреч выпускников, где каждый ваш одноклассник, важно надув щеки, повествует, какой он крутой бизнесмен, какая у него дорогая машина, а у одноклассниц в инстаграме — сплошь фотки с лакшери-отдыха и дорогих Spa-салонов.
Безусловно, делиться успехами полезно, но жизнь многогранна и состоит не только из удачных моментов, но и из неудачных тоже. Вы сейчас, наверное, подумали, что я говорю шаблонами, но я на полном серьезе считаю, что негативный опыт гораздо полезнее позитивного, ведь, когда мы рефлексируем, мы познаем себя и совершенствуемся, поэтому неудачи и делают нас сильнее.
Факапы — не приговор
Ни для кого не секрет, что ковидные времена переформатировали подход к работе многих ИТ-компаний, и айтишники-интроверты, вкусив все прелести удаленки, вообще перестали приезжать в офисы, лицезрея своих коллег только через глазки лаптопов.
И вот однажды я узнал про мероприятие под названием Fuckup Nights.
Это глобальное движение предпринимателей и стартаперов, возникшее в 2012 году в Мексике, которые захотели изменить отношение к провалам в бизнесе, потому что приторно-сладкие истории успеха нам страшно надоели. Ведь не ошибается лишь тот, кто ничего не делает!
На каждом мероприятии сотни гостей слушают предпринимателей или менеджеров, которые рассказывают о своём самом ярком бизнес-провале.
Мне показалось это достаточно интересным, и я даже посмотрел несколько видеороликов о том, как это мероприятие проходит в реале. И я подумал, , а почему бы не организовать нечто подобное у себя в команде?
Как мы решили бороться с системой
Айтишников очень часто приходится собирать вместе, чтобы выработать и согласовать проектный подход или какое-то решение, обсудить проблемы, риски и т.д. Хотя в основе своей люди этой профессии — интроверты, но на практике очень часто любят вступать в полемику друг с другом на профессиональные темы.
Мероприятия такого формата отлично помогают собраться всем оффлайн и даже могут являться некоторым элементом командообразования, что в дальнейшем только способствует совместной работе. Так вот: мы решили уединиться в одной из больших переговорок в пятницу к концу рабочего дня, принесли чай, печенье и, конечно же, пиццу. И начали обсуждать факапы.
Сначала я заметил некоторое недоверие или сомнение в глазах слушателей, но через 15–20 минут пошли первые комментарии: «Да, ну и дела. Надо было тогда поступить вот так-то и так-то». Коллеги начали подхватывать дискуссию, пошла здоровая полемика, и стало понятно, что формат — зашел.
Прозвучавшие истории из моей практики
… которые остались со мной не только как воспоминания о факапах, но и как отличные уроки на будущее.
Однажды мне пришлось участвовать в проекте, который был связан с интеграцией нового ПО для крупного заказчика. Задача выглядела относительно простой: заказчику нужно было объединить разные системы в единое решение, чтобы повысить эффективность работы. Казалось, ничего сложного — классический проект с четкими целями и ограниченными сроками. Но на одном из этапов я допустил ключевую ошибку: не проверил совместимость некоторых модулей. В итоге, уже в процессе реализации выяснилось, что одно из звеньев просто «отваливается», и цепочка не работает. Мы потратили несколько дней на поиски проблемы, и это стоило нервов всей команде.
Что я вынес из этой ситуации? Никогда не игнорировать начальный этап тестирования и не полагаться только на уверения поставщиков ПО. Даже если сроки поджимают, лучше потратить время на дополнительную проверку, чем потом экстренно чинить «сломанную» систему.
Однажды мы апгрейдили инфраструктуру заказчика и решили переиспользовать старые имена серверов на новом железе. Я работал ночами в то время, и в полной запаре забыл про это. Итог: собственноручно вывел из эксплуатации два продакшн-сервера безопасности, дав команду дата-центру в Англии вытащить их из стоек и уничтожить. Их вытащили, но, слава богу, уничтожить еще не успели.
Что я вынес из этой ситуации? Лучше не переиспользовать уникальные имена конфигурационных единиц и быть очень внимательным при составлении запросов на серьезные инфраструктурные изменения — особенно, если они необратимы.
Прозвучавшие истории из практики коллег
… которые прекрасно показывают, что никто не застрахован от ошибок — даже самые опытные сениоры.
Один из наших ИТ-архитекторов поделился историей, которая произошла на этапе внедрения облачного решения для внутренней инфраструктуры заказчика. Он решил внедрить новую технологию, о которой недавно узнал на одной из конференций. Казалось, что это будет идеальное решение: современное, гибкое и с большим потенциалом для масштабирования.
Однако он не учел одной важной детали — уровень зрелости инфраструктуры заказчика. Технология оказалась слишком сложной для внедрения в текущих условиях. В результате проект затянулся, бюджеты увеличились, и в итоге заказчик отказался от этой идеи.
· Вывод: новое — не всегда лучшее. Перед тем, как внедрять что-то инновационное, важно убедиться, что команда и заказчик готовы к изменениям, а также, что новые решения действительно решают текущие задачи.
Еще один коллега рассказал историю про то, как по ошибке разлил заказчику везде клиентскую операционную систему, запихнув в коллекцию SCCM вообще все серверы и компьютеры в организации.
Вывод: следить за своей внимательностью — наше все. Лучше применять 4-eyes-principle везде, где только это возможно при серьезных изменениях.
Эти истории — не просто анекдоты из жизни команды. Они показывают, как важно делиться неудачами, учиться друг у друга и помнить: ошибки — не конец, а начало пути к лучшим результатам.
Как я собирал обратную связь
Уже спустя пару дней после мероприятия я решил собрать обратную связь. Оказалось, что всем без исключения понравился такой формат, и команда нашла его очень полезным. Вот основные выводы:
Ты учишься смотреть на негативный опыт «по-другому» и перестаешь стесняться о нём говорить.
Понимаешь, что ты не один в этом мире «косячник» — рядом с тобой работают такие же люди, как и ты.
Коллеги готовы выслушать и дать дельный совет, а обмен негативным опытом помогает всем избежать подобных ситуаций в будущем.
В заключение
Эксперимент с обсуждением неудач под кодовым названием Fuckup Nights стал для нашей команды настоящим открытием. Вместо привычных отчетов о достижениях мы научились говорить о сложностях и видеть их ценность. Такие встречи помогают снять напряжение, сплотить коллектив и, самое главное, извлечь уроки, которые делают нас сильнее как профессионалов и как людей.
Неудачи — это не повод для стыда, а возможность для роста. Главное — уметь их анализировать и превращать в опыт. Как сказал один из участников нашей встречи: «Ошибаться — это нормально. Главное — делать это с умом».
Теперь мы планируем проводить такие мероприятия регулярно, чтобы вместе расти, учиться и поддерживать друг друга. Ведь настоящий профессионализм проявляется не только в успехах, но и в том, как ты справляешься с трудностями.
