ДжазТим — надежный технологический партнер

Agile разработка ПО на Java

Консалтинг на сложном востребованном проекте в сфере электронной коммерции

Описание проекта

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

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

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

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

Как результат:

  • в настоящее время появились крупные заказчики;
  • сократилось время разработки;
  • повысилось качество продукта;
  • гармонизирована команда разработчиков.

Особенности проекта

Исходные вызовы:

Технологические сложности: система имела большой codebase с нетривиальной, запутанной архитектурой и смешанными слоями кода, что делало её сложно поддерживаемой. Unit-тесты практически отсутствовали, в Definition of Done их не было, как и требований к уровню покрытия кода. Проверка качества продукта осуществлялась несистемно и только с помощью мануального тестирования. Компоненты системы были не изолированы, из-за высокого уровня связанности при малейших изменениях кода возникали баги. Продукт очень сложно поддавался масштабированию и внедрению новых функций.

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

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

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

Формат консультирования:

Инструменты консалтинга:

  1. Личное консультирование в формате 1:1 с владельцами компании.
  2. Медиация конфликта между фаундерами.
  3. Привлечение менеджера для внедрения улучшений (постановки и управления процессами бизнес-анализа, поставки, тестирования).
  4. Дополнительное привлечение отдельно выделенного менеджера для управления процессом работы с техническим долгом. Это было необходимо по причине очень большого количества технических долгов и объема необходимой для их устранения работы.
  5. Регулярное включение в проект Дмитрия (фаундер ДжазТим) для анализа эффективности проведённых улучшений.

Подходы консалтинга: в процессе консультирования Дмитрий применил триаду своего опыта:

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

Этапы консалтинга:

  • 1 этап — медиация конфликта между фаундерами и установление общего видения ситуации на проекте: Дмитрий выступал в качестве медиатора — независимой стороны, способствующей достижению единого мнения между владельцами продукта, имеющими разные точки зрения. Собственники осознавали необходимость улучшения процессов, но предлагаемые ими варианты не помогали устранить источник проблемы. Каждый из них был опытным специалистом, отстаивающим свою точку зрения, поэтому им было очень сложно достичь общего видения и совместно выбрать стратегию управления.
  • 2 этап — реорганизация процессов:
  • Дмитрий качественно трансформировал процесс бизнес-анализа. Вместо схематичной, сжатой и неполной постановки задач, понятной только сотрудникам с большим опытом на проекте, было принято решение ввести унифицированный стандарт, прозрачный для всей команды. Это позволило интегрировать команды разработки и тестирования, обеспечить более чёткую приёмку, значительно улучшить синхронизацию с конечным заказчиком по желаемому результату.
  • Контроль качества должен стать важнейшей частью жизненного цикла проекта. До того, как заказчики обратились за услугой консультирования, тестирование системы осуществлялось ситуативно, роль тестировщика выполняли разработчики и один из владельцев продукта. Дмитрий проанализировал текущие проблемы с качеством и нестабильностью продукта и предложил заказчикам расширить команду специалистами по ручному и автоматизированному тестированию.
  • Для борьбы с постоянными задержками релизов было решено пересмотреть процесс эстимирования задач, с тем чтобы все участники команды могли реалистично понимать текущий статус. Кроме более четкой декомпозиции трудозатрат на виды работы (BA, проектирование, разработка, автоматизированное и ручное тестирование, баг-фиксинг и др.) была введена унифицированная таблица возможных рисков. По каждому риску для задачи выставлялась вероятность наступления, что влияло на изначальную эстимацию. Также, для каждого вида работ был создан список критериев выполнения задачи (Definition of Done), необходимый для организации системной приёмки. Команда разработки постепенно получала практические навыки в эстимировании. Нарабатывая опыт, инженеры с каждым разом ещё точнее и реалистичнее оценивали необходимые трудозататы на реализацию конкретной задачи. Все эти меры позволили получить реалистичные эстимации, которые обеспечили планирование поставок без задержек.
  • 3 этап — работа с техническим долгом: в процессе улучшений были проработаны следующие технические долги:
  1. Внедрение CI/CD для осуществления автоматической сборки, регулярной проверки качества и автоматизации поставки продукта.
  2. Создание фреймворка для blackbox-тестирования приложения, с помощью которого команда смогла начать создание автоматизированных backend тестов. Без данного фреймворка инженеры не имели возможности создавать Unit-тесты ввиду большого codebase, с нетривиальной запутанной архитектурой и смешанными слоями кода. Тесты запускаются как часть регулярных сборок проекта (по расписанию и по требованию), обеспечивают стабильную работу продукта при внесении изменений.
  3. Полноценное и регулярное покрытие всего важного функционала системы GUI-автотестами. Для быстрого написания и поддержки с минимальными затратами большого количества GUI-автотестов был создан фреймворк, с помощью которого база UI-автотестов была увеличена с нуля до нескольких сотен за короткий промежуток времени (несколько месяцев).
  • 4 этап — внедрение лучших практик разработки и порождение ценностной культуры: по согласованию с собственниками бизнеса было решено усилить роль инженеров на проекте и увеличить степень самоорганизации команды. Для этого использовали лучшие подходы методологии Scrum.
  • Ежедневные стендапы повысили уровень синхронизации географически распределенной команды.
  • Демо нового функционала перед всей командой способствовали достижению общего понимания актуальных статусов на проекте.
  • На регулярных ретроспективах оперативно решались возникающие недопонимания и проблемы. Постоянно поднималась тема важности реалистичного подхода к разработке: команда должна была быть честной в эстимировании задач, оценке своих сил. Мнение всех участников проекта было выслушано, владельцы продукта начали учитывать и обрабатывать предложения и замечания инженеров.
  • Налажена системная передача знаний внутри команды — установлена практика регулярного проведения лекций и митапов по технологической или доменной экспертизе. Всё это способствовало улучшению психологического климата и преодолению выученной беспомощности инженеров. Они стали более самостоятельны и не боялись проявлять инициативу.
  • В команде установилась здоровая психологическая атмосфера, участники проекта стали более искренними и начали доверять друг другу. Благодаря постоянному инициированию общения была введена практика общих обсуждений актуальных проблем, вопросов. Когда все участники проекта были честны и не скрывали возникших сложностей, удавалось найти наиболее оптимальные решения, избежать большого количества рисков и конфликтов.

Результаты и достижения

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

  1. Заказчики смогли регулярно и своевременно поставлять новый функционал, тем самым развивая и масштабируя сложнейший продукт. Была исключена деградация качества на уровне продакшена. Всё это открыло возможности для укрепления компании на рынке и сотрудничества с более крупными клиентами.
  2. Благодаря внедрению эффективных практик управления процессами и эстимирования задач компания-заказчик перешла на бизнес-модель T&M и смогла увеличить доход от продаж.
  3. В команде установлен ценностный подход к разработке. Владельцы продукта начали прислушиваться к предлагаемым командой инициативам, приносящим ценность в долгосрочной перспективе, сменили приоритет с достижения краткосрочных целей на стратегический подход к развитию продукта. Также владельцы продукта начали инвестировать во внедрение необходимых инженерных практик (CI/CD, Unit testing, автоматизацию тестирования). Устранению технических долгов стали уделять время на протяжении каждого спринта, были порождены долговременные технологические исследования.
  4. Проработаны основные технические долги:
    • Благодаря внедрению CI/CD процесс сборки и поставки продукта автоматизирован, стал быстрым, прозрачным и безопасным. Это позволило наладить регулярность релизов.
    • Сложный codebase приложения покрыт Unit-тестами, благодаря чему удалось стабилизировать качество системы при внесении изменений.
    • Системное покрытие автотестами обеспечило возможность быстрого обнаружения багов при реализации нового функционала. Это обеспечило возможность своевременного развития для сохранения конкурентоспособности продукта.
  5. Повышен уровень синхронизации между членами распределенной команды и владельцами продукта. У инженеров появилась мотивация к преодолению выученной беспомощности, использованию проактивного подхода в процессе работы над задачами. Улучшен психологический климат в команде, процесс разработки проходит в спокойной обстановке без ненужного стресса и нервозности.
  6. Владельцы продукта и команда разработки стали более реалистичными в планировании, эстимировании задач и оценке рисков, что обеспечило предсказуемость работы для инженеров и позволило снизить нервозность в команде. Также применение композитной эстимации ускорило процесс внедрения инноваций и инженерных практик на проекте.
  7. Благодаря профессиональному подходу Дмитрия все необходимые изменения были приняты специалистами и фаундерами и успешно внедрены. При этом ему удалось не только сохранить команду разработки в полном составе, но и расширить ее новыми специалистами.

Скриншоты

Свяжитесь с нами, чтобы обсудить Ваш IT-проект

    Имя *

    Название компании

    Email *

    Телефон

    Чем мы можем Вам помочь? *

    * – Обязательные поля для заполнения