Я взял на себя роль руководителя технического департамента в динамично развивающейся компании, отвечая за разработку и поддержку программными продуктами в рамках нашего бизнеса. Несмотря на то, что команда не была большой, успех компании полностью зависел от разработки, качества и общей эффективности технической команды.
По прибытии, через короткое время, я заметил следующую ситуацию: команды были полностью заняты, в повторяющихся циклах, то решая проблемы в проектах дорожной карты, то решая проблемы связанные с частыми инциденты, при этом пытаясь оптимизировать продукты… но без существенного успеха. Старшие разработчики часто разрывались между разрешением инцидентов и проектами, в которых отсутствовала четкая формализация, что приводило к постоянным переделкам.
Последствия сказывались на всей компании: снижение доступности продуктов и качества сервиса (SLA – Service Level Agreement), инциденты с длительным временем решения и бурное недовольство со стороны бизнеса. На бизнес-проекты также негативно повлиял фокус на инцидентах, что вызвало дополнительное недовольство.
Этот цикл напоминал тупик, где отдельные задачи выполнялись, но преобладала общая неудовлетворенность, плохо отражающаяся на результатах компании.
Развивающийся технологический ландшафт требовал от команд изучения новых тенденций и внедрения новейших, оптимизированных, безопасных и стабильных решений, чего не происходило.
В результате общая удовлетворенность команд разработчиков оставалась низкой.
Вы можете сказать – "это нормальная ситуация во многих компаниях", "в чем конкретно проблема", или, может быть, проблема в "слишком много задач или проектов"…
Я бы сказал, что да – это считается «нормальным» во многих компаниях, и я бы сказал «нет» – это ненормальная ситуация в компании, которая хочет быть успешной!
Проблема не была связана с количеством проектов или задач. Но если задачи и проекты оставлены без контроля, это тоже может привести к подобным кризисам.
Для понимания проблемы в целом я постоянно общался с людьми моей команды и с бизнес коллегами. Многие из них считали эту ситуацию нормальным. При обсуждении таких проблем, как инциденты, длительные сроки разработки, неудовлетворенность бизнесом или отсутствие внедрения новых технологий, ответы варьировались от «у нас сейчас нет на это времени» до обвинений других в том, что «мы не можем выполнить работу вовремя, потому что нам что-то не было предоставлено» или «другой отдел или команда не понимают наших проблем, поэтому у нас так много инцидентов». Еще одна частая жалоба касалась совещаний (meetings); Совещаний было много и не было определенного формата ни по времени, ни по структуре – что мешало сосредоточиться на работе и приводило к разрозненным усилиям, напрямую влияя на результаты.
Любой, кто читает эту книгу, вероятно, встречал в своей жизни подобные ситуации.
Теперь давайте рассмотрим, что я сделал, и результаты, которые за этим последовали.
Мои цели, поставленные генеральным директором, заключались в том, чтобы в первую очередь сосредоточиться на повышении вовлеченности технических команд, оптимизации разработки проектов дорожной карты, минимизации инцидентов и повышении стабильности SLA.
Основываясь на своем предыдущем опыте, при решении критических вопросов или запуске новых инициатив я провел тщательную оценку масштаба – чтобы понять нашу текущую ситуацию!
Чтобы получить всестороннее понимание и принять целостную перспективу, я инициировал серию встреч со всеми заинтересованными сторонами, как со стороны бизнеса, так и техническими коллегами. Для предоставления более подробной информации:
– С техническими командами: Взаимодействие включало в себя глубокое погружение в рабочий процесс, анализ ошибок, частоту развертывания, выбор архитектуры, использование инструментов и многое другое. В процессе обсуждения мы не ограничивались ключевым техническим персоналом, но охватывали всю команду. Встречи были либо командными, либо в формате индивидуальных встреч для обсуждения критических случаев.
– С бизнес коллегами: Мы изучили их процессы, собрали их ожидания от технической команды, поняли их стратегию, цели и все нюансы, связанные с этими целями.
После нескольких раундов встреч и обмена информацией я составил карту: «Анализ текущей ситуации» – это мы назвали пункт «А», а цели обозначили как пункт назначения «Б».
Затем началась роль «штурмана» – прокладывание курса из точки «А» в точку «Б».
– Если проблема заключалась в качестве продуктов, был создан специальный рабочий процесс для повышения качества.
– Если проблема заключалась в реализации проекта, то по одному из проектов был инициирован последующий процесс для тщательного изучения реального функционирования проектного процесса.
И так было сделано по каждому процессу который не давал нужные результаты.
Затем был разработан план действий, направленный на решение выявленных проблем и улучшение ситуации в целом. Этот план получил консенсус как от команды, так и от бизнес-отделов, чтобы начать его реализацию.
Важно понимать, что решение любой проблемы требует системного взгляда на весь процесс. Одних только технических улучшений недостаточно без учета требований проекта, тестирования или стратегии запуска.
Вот действия, которые мы инициировали:
– Фокус на качестве продукта: это включало в себя повышение качества продуктов, устранение инцидентов, улучшение SLA, внедрение новых технологий и повышение вовлеченности команды:
Анализ первопричин инцидентов: ключевые сотрудники уделяют первоочередное внимание пониманию основных причин инцидентов, уделяя время обсуждениям, анализу журналов и планируют действия для тестирования в контролируемых средах. В случае происшествия были предприняты совместные усилия по сбору всей необходимой информации для тщательного исследования.
Исследование новых технологий: каждый руководитель команд назначал человека (либо работник по собственной инициативе), который будет тратить определенное время, к примеру – половину рабочего дня каждую неделю, на научно-исследовательские и опытно-конструкторские работы, связанные с нашим технологическим стеком. Это было включено в регулярный график, а результаты были представлены командам и оценены на предмет применимости.
Решение проблемы перегруженности собраниями: чтобы смягчить последствия чрезмерных совещаний, особенно при выполнении длительных задач, было введено такое понятие как «день без совещаний», первоначально на экспериментальной основе, а затем принятый на постоянной основе из-за его эффективности. В данные дни (их было 2 в неделю – Вторник и Пятница), совещания между бизнес и техническими командами не происходили, за исключением критических ситуаций.
– Усовершенствования дорожной карты: для повышения эффективности были внесены улучшения как в проектные, так и в технические процессы внесения исправлений (Project Management, Change Management):
Создание единой дорожной карты: объединенная бизнес и техническая дорожная карта предоставила четкое представление обо всех проектах, приоритетах и ресурсах, оптимизируя управление проектами и изменениями.
Уточненные правила запуска проекта: Преждевременное начало проекта было ограничено за счет тщательного первоначального анализа спецификаций и доведению до ясности требований, что привело к лучшему распределению ресурсов и минимизации доработок.
Руководящими принципами для всей компании были:
– Неизменная приверженность качеству: Качество остается нашей первостепенной задачей и не подлежит обсуждению и никакие компромиссы с качеством неуместны.
– Непрерывное обучение и технологический прогресс: быть в курсе новых технологий вовлекая всех сотрудников организации.
– Единая дорожная карта: Проекты не делятся на бизнес- и технические, все усилия по достижению совершенства продуктов консолидированы.
– Ясность перед началом: Четкое понимание ожиданий гарантируют, что проекты не будут тянуться, а будут реализованы в срок и с надлежащим качеством.
Данные подходы, являющиеся частью нашего более широкого видения, ценностей и стратегии, будут обсуждаться в последующих главах.
Мониторинг реализации этих процессов осуществлялся в течение трех месяцев, что подчеркивало важность сохранения фокуса на ключевых элементах, не отвлекаясь на другие приоритеты. Этот фокус является важнейшим аспектом ИТ-лидерства, требующим сотрудничества с заинтересованными сторонами бизнеса, чтобы подчеркнуть важность быстрого решения критических проблем для обеспечения будущих преимуществ от разработанных решений и улучшенных процессов.
Вот основные результаты и выводы (по направлениям):
Улучшение качества:
– Системный подход к устранению инцидентов, включая изменения архитектуры, и улучшение коммуникации между техническими и ИТ-командами привели к значительному снижению инцидентов уже через 3 месяца.
– Внедрение дополнительных метрик в мониторинг для выявления предупреждений на ранней стадии помогло предотвратить некоторые инциденты и улучшить контроль над работой решений в целом.
– Усовершенствования в продуктах и архитектуре были использованы для повышения качества новых продуктов уже с момента запуска.
Вовлечение всех работников:
– Поощрение непрерывного обучения и освоения новых технологий повысило вовлеченность и удовлетворенность сотрудников.
– Сотрудники посвящали часть рабочего времени обучению, что приводило к повышению мотивации по мере того, как они становились свидетелями личностного и профессионального роста.
Усовершенствование дорожной карты:
– Первоначальные трудности в реализации дорожной карты были преодолены путем изменения подхода к спецификациям, гарантируя, что работа начинается только тогда, когда требования будут полностью определены и поняты как бизнес, так и техническими командами.
– Итеративные совещания и обсуждения привели к четкому соглашению о распределении ресурсов, что привело к более эффективному планированию и сокращению задержек.
