Содержание
  1. Бизнес-вызовы
  2. Основные проблемы на проекте
  3. Результаты комплексной работы
  4. Формат проведения консалтинга
  5. Подходы и решения
  6. Этапы работы
  7. Стратегия консультирования
  8. Достижения
    компании-заказчика
  9. Отзыв заказчика

Медиация взаимоотношений между фаундерами компании и масштабирование сложного востребованного продукта в сфере электронной коммерции

Срок реализации проекта: 2 года
Смотреть другие кейсы

Бизнес-вызовы

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

Ситуация на проекте

  1. Технологические сложности. Система имела большой codebase с нетривиальной, запутанной архитектурой и смешанными слоями кода, что делало её сложно поддерживаемой. Unit-тесты практически отсутствовали, в Definition of Done их не было, как и требований к уровню покрытия кода. Проверка качества продукта осуществлялась несистемно и только с помощью мануального тестирования. Компоненты системы были не изолированы, из-за высокого уровня связанности при малейших изменениях кода возникали баги. Продукт очень сложно поддавался масштабированию и внедрению новых функций.
  2. Проблемы с поставками. Не внедрены принципы непрерывной интеграции и поставки (CI/CD), сборка продукта и обновление серверов осуществлялись вручную, что негативно сказывалось на скорости поставки продукта. Еще одной причиной проблем с поставками были нереалистичные эстимации. Инженерам ставились жёсткие дедлайны, на которые они соглашались, хотя изначально было понятно, что задача не может быть выполнена в поставленный срок. Также на проекте не было практики декомпозиции задач и оценки рисков, что не позволяло реалистично оценивать требуемые трудозатраты на решение задач.
  3. Выученная беспомощность и высокая токсичность в команде. Постоянные срывы релизов вызывали недовольство владельцев бизнеса и конечных заказчиков, в ответ на оказываемое давление в команде возникали нервозность и стресс. Ситуация усложнялась отсутствием проактивности, технического лидерства у инженеров и накопленным на протяжении многих лет техническим долгом. Инициативам по внедрению новых инженерных практик, приносящим пользу проекту в долгосрочной перспективе, не уделялось должного внимания, из-за чего у разработчиков вырабатывалась выученная беспомощность.
  4. Стохастичность, несистемность в процессах управления. Не выстроены процессы бизнес-анализа, тестирования и поставки. На проекте не было чёткого подхода к эстимированию и оценке рисков, фаундеры были сфокусированы на достижении краткосрочных бизнес-целей.

Основные проблемы на проекте

  1. Немасштабируемый, трудно поддерживаемый продукт с большим codebase и запутанной архитектурой.
  2. Нерегулярные поставки.
  3. Токсичность и напряжённая атмосфера в команде.
  4. Не выстроены процессы управления.

Результаты комплексной работы

согласие сторон достигнуто
согласие сторон достигнуто
собственники достигли единого мнения относительно развития продукта и бизнеса
технические долги проработаны
технические долги проработаны
их устранению стали уделять время на протяжении каждого спринта
налажен процесс релизов
налажен процесс релизов
благодаря внедрению CI/CD процесс сборки и поставки продукта автоматизирован
увеличен доход
увеличен доход
компания перешла на бизнес-модель T&M и увеличила свой доход от продаж

Формат проведения консалтинга

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

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

Подходы и решения

Начав консультации с личного общения с заказчиком, Дмитрий развивал работу с компанией в нескольких направлениях.

  1. Медиация конфликта между фаундерами и установление общего видения проекта в руководстве;
  2. Реорганизация процессов;
  3. Работа с техническими долгами;
  4. Внедрение лучших практик разработки и порождение ценностной культуры в команде.
  1. 1 этап:
    Медиация конфликта между фаундерами и установление общего видения ситуации на проекте

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

    Значительную роль в установлении доверия сыграл высокий уровень эмпатии со стороны Дмитрия. Изначально в сотрудничестве между ним и фаундерами было много общего: обе стороны имели опыт руководства собственной ИТ-компанией, инвестирования и вывода на рынок высокотехнологичного коммерческого продукта, а также использования услуг стороннего консультанта. Совокупный бэкграунд в данных направлениях позволил Дмитрию чётко определить, какие страхи и сомнения испытывает каждый собственник. Понимая их боли и опасения, он настраивал фаундеров на долгую, продуктивную работу, объяснял, почему невозможно стабилизировать ситуацию на проекте за 1-2 месяца. Ему было важно показать, что в команде отсутствует культура работы с техническими долгами, что на проекте накопилось очень много технических проблем.

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

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

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

  2. 2 этап:
    Реорганизация процессов
    • Дмитрий качественно трансформировал процесс бизнес-анализа. Вместо схематичной, сжатой и неполной постановки задач, понятной только сотрудникам с большим опытом на проекте, было принято решение ввести унифицированный стандарт, прозрачный для всей команды. Это позволило интегрировать команды разработки и тестирования, обеспечить более чёткую приёмку, значительно улучшить синхронизацию с конечным заказчиком по желаемому результату, использовать постановку для создания тест-кейсов, являющихся базой для ручного и автоматизированного тестирования. Также данный подход снизил издержки на поддержку и сопровождение продукта.
    • Контроль качества должен был стать важнейшей частью жизненного цикла проекта. До того, как заказчики обратились за услугой консультирования,  тестирование системы осуществлялось ситуативно, роль тестировщика выполняли разработчики и один из владельцев продукта. Дмитрий проанализировал текущие проблемы с качеством и нестабильностью продукта и предложил заказчикам расширить команду специалистами по ручному и автоматизированному тестированию. Менеджер, привлеченный Дмитрием для управления внедрением улучшений на проекте, взял на себя задачу по выстраиванию процесса тестирования.
    • Для борьбы с постоянными задержками релизов было решено пересмотреть процесс эстимирования задач, чтобы все участники команды могли реалистично понимать текущий статус. Кроме более четкой декомпозиции трудозатрат на виды работы (BA, проектирование, разработка, автоматизированное и ручное тестирование, баг-фиксинг и др.) была введена унифицированная таблица возможных рисков. По каждому риску для задачи выставлялась вероятность наступления, что влияло на изначальную эстимацию. Также, для каждого вида работ был создан список критериев выполнения задачи (Definition of Done), необходимый для организации системной приёмки. Команда разработки постепенно получала практические навыки в эстимировании. Нарабатывая опыт, инженеры с каждым разом ещё точнее и реалистичнее оценивали необходимые трудозататы на реализацию конкретной задачи. Все эти меры позволили получить реалистичные эстимации, которые обеспечили планирование поставок без задержек.
  3. 3 этап:
    Работа с техническим долгом

    Огромный объём технического долга критически усложнил постоянную работу с ним на протяжении каждого спринта. На первых порах было необходимо заработать доверие команды и небольшими итеративными изменениями продемонстрировать возможность проработки долга даже в условиях постоянной занятости разработчиков коммерческими задачами. 

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

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

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

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

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

Стратегия консультирования

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

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

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

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

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

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

Использовал навыки организации процессов поставки продуктов для системной работы по улучшению процессов разработки (бизнес-анализа, тестирования, постановки и эстимирования задач). 

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

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

Достижения компании-заказчика, которых удалось добиться в результате сотрудничества

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

Отзыв заказчика

Отзыв клиента на консалтинг

«Мы обратились к Дмитрию, чтобы ускорить развитие нашего продукта и выйти из технологического кризиса. На проекте были сложности с планированием поставок, оценкой задач и рисков. Релизы срывались и проходили с задержками. Мы хотели быстрее решить вопрос нестабильности релизов, масштабировать продукт и внедрить эффективные технологические подходы.
Изначально мы не осознавали масштаба проблем на проекте. После нескольких встреч с Дмитрием начали понимать, что нужно настраиваться на игру в долгую. Некоторые процессы нужно было поставить с нуля. Уже спустя несколько месяцев с начала консультирования на проекте активно велись работы по внедрению автотестов и CI/CD. В процессе мы постоянно получали небольшие результаты и это мотивировало к работе над сложными задачами. После введения Scrum и общения с Дмитрием разработчики начали активнее высказывать свое мнение, начали писать Unit-тесты и давать более точную оценку своим задачам. В целом, процессы, затраты, продуктивность команды и результаты ее работы стали более предсказуемыми.
Мы доверили Дмитрию многое, при этом всегда сохранялось ощущение, что всё под контролем и решение наших проблем доверено профессионалу. Во время консультаций он подробно объяснял пользу разных инструментов и практик, аргументировал каждое решение. Рекомендуем Дмитрия как внимательного консультанта, который бережет и уважает созданное вами.»

Отзыв клиента на консалтинг
Founder продукта (название компании под NDA)
rect
Получите БЕСПЛАТНЫЙ чек-лист «Как понять, что ваш проект в опасности?»
photo

Приветствую! Меня зовут Дмитрий Горячко. Специально для вас я подготовил чек-лист, который поможет определить, в опасности ли ваш проект, и предоставит чёткое количественное измерение сложности ситуации.

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

Также чек-лист содержит большое количество практических советов. Это поможет вам самостоятельно продвигаться по решению проблем.