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

В первую очередь владелец компании должен был реалистично увидеть ситуацию на проекте и осознать причины такого положения дел: нет работы с техническим долгом, невнедрённый CI/CD, отсутствие тест-менеджмента и автоматизированных тестов и, как следствие, ценностного подхода в команде. После нескольких консультаций с Дмитрием заказчик начал осознавать важность самоорганизации команды, необходимость трансформации ценностей разработчиков и одобрил постоянную работу с техническим долгом.

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

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

1. Внедрение автоматизированного тестирования (Unit-, UI- и интеграционного тестирования).
2. Внедрение непрерывной интеграции и поставки (CI/CD).
3. Рефакторинг legacy-кода.
4. Улучшение архитектуры продукта.

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

Спустя несколько месяца с начала работы над техническими долгами удалось добиться значительных улучшений. Для автоматизированного UI-тестирования критических функций продукта был успешно применён выбранный по результатам исследования фреймворк. Инженеры начали регулярно писать UI и Unit-тесты. В Unit-тестировании использован подход Data Driven Testing, упрощающий ввод входных данных, что особенно важно для системы с большим количеством расчетных модулей.

Несмотря на высокое сопротивление команды, были внедрены непрерывная интеграция и поставка (CI/CD). Спустя 2 месяца данная практика начала приносить первые результаты: процесс создания дистрибутивов продукта стал быстрым и безопасным, что позволило существенно высвободить время и увеличить производительность команды. Постоянная работа с техническим долгом стала неотъемлемой частью спринтовых задач.

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

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

Параллельно с работой над техническим долгом был внедрён профессиональный тест-менеджмент. Под руководством выделенного проектного менеджера со стороны команды консалтинга выстроены процессы и созданы тест-планы для мануального и автоматизированного тестирования, что позволило более профессионально управлять качеством продукта.
Также было необходимо оптимизировать процессы сбора требований, формирования и постановки задач. На основании собранных командой пожеланий заказчиков создана система обработки задач (workflow). Далее был скорректирован процесс обработки требований и преобразования их в задачи. Предметная область, в которой применялся продукт, отличалась особой сложностью. Преобразование требований в конкретные задачи было действительно трудоёмким процессом, который нуждался в дополнительных исследованиях, подборе научных статей. Иногда возникала необходимость в разработке модели, на основе которой формировалось техническое задание для инженеров. Для реализации стратегии команда была пополнена новыми бизнес-аналитиками с бэкграундом в научной сфере. Также было выделено время для дополнительных научных изысканий. Такой подход позволил формировать требования более конкретно и точно. Теперь задачи для команды разработки имели критерии выполнения (Definition of Done), инженеры смогли самостоятельно проводить их декомпозицию и эстимирование.
Кроме того, была выстроена система оценки рисков. При уточнении требований по конкретному функционалу бизнес-аналитик оценивал, возможна ли в принципе поломка критически важных частей продукта. Если такая возможность присутствовала, он инициировал проведение отдельного митинга, на котором обсуждались мероприятия по обработке рисков.
Далее были приняты меры по улучшению процесса поставки. Дмитрий ввел на проекте практику регулярного планирования спринтов (отдельные митинги), груминга бэклога. В команде начал проводиться предварительный анализ, определяющий следующий срок релиза. Если ранее специалисты из-за больших неопределенностей в разработке фокусировалась на отдельных задачах, то после введения практик планирования команда была нацелена реализовать весь намеченный набор функциональностей к релизу. Эффективные подходы к планированию и внедрённые инженерные практики (CI/CD, автоматизация тестирования) положительно сказались на процессе поставки продукта: команда смогла осуществлять релизы в запланированный срок. А количество релизов за год увеличилось в два раза. При этом дальнейшее увеличение частоты уже не имело смысла, так как заказчики не были готовы обновлять ПО с более частой периодичностью.

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

1. опозданий на стендапы;
2. готовности к стендапу;
3. прогресса по написанию Unit- и UI-тестов;
4. прогресса по внедрению CI/CD;
5. ежедневное состояние отработанных за ночь тестов;
6. уделяемого разработчиками времени на работу с техническим долгом;
7. достижения целей спринта.

Цель данных инструментов — зафиксировать малейшие шаги и улучшения, чтобы команда постоянно видела прогресс. Средства визуализации наглядно показывали специалистам, в каких моментах на проекте есть проблемы, над чем необходимо работать и какие процессы должны постоянно отслеживаться. Кроме того, это способствовало контролю над соблюдением установленных правил и практик. Например, график учёта времени, затраченного на работу с техническими долгами, способствовал установлению практики постоянного написанию автотестов инженерами.
Еще один инструмент влияния, который позволил повысить культуру в команде разработки — написание документации инженерами. Смысл такой практики заключается в улучшении качества работы специалистов. Когда инженер понимал, что должен написать понятный мануал по использованию к созданной утилите, он подходил к процессу разработки более вдумчиво. Это должен был быть законченный функционал, работу которого можно изобразить несложной диаграммой и понятной последовательностью действий.
Для повышения результативности различных встреч и обсуждений у каждого инженера появилась рабочая тетрадь, в которой он должен был помечать поставленные перед ним задачи, чтобы потом самостоятельно занести их на Scrum-доску. Так все обсуждения не проходили впустую, полученные задачи и вопросы не забывались и всегда обрабатывались. Кроме того, это позволяло отследить контекст обсуждений в спорных ситуациях.
Еженедельно разработчики демонстрировали результаты проделанной за неделю работы, отвечали на вопросы, получали пожелания и замечания от команды (командное демо). После такого мероприятия каждый участник проекта понимал, как функционируют определенные части продукта. С другой стороны, каждый инженер мог поделиться удачными решениями, применёнными в процессе работы над задачей.
С появлением первых успехов команда постепенно получила веру в то, что выбраться из сложной ситуации на проекте вполне реально. Это способствовало преодолению выученной беспомощности. Инженеры начали искать пути решения проблем, а не причины, почему их невозможно решить, наконец увидели результаты своей работы и осознали, что сдвинулись с мертвой точки. Атмосфера в команде стала более доброжелательной: наладились коммуникации, владелец стал с командой на одну сторону. Увеличилась мотивация к накоплению лучших практик и появилось понимание, что усилия каждого человека действительно делают продукт лучше.