Основные проблемы на проекте
- Немасштабируемый, трудно поддерживаемый продукт с большим codebase и запутанной архитектурой.
- Нерегулярные поставки.
- Токсичность и напряжённая атмосфера в команде.
- Не выстроены процессы управления.
Заказчик намерен расширить клиентскую базу и перейти к сотрудничеству с более крупными компаниями, однако разработанный его командой продукт достиг критической точки накопления технических долгов. Систему с большим количеством функционала и модулей очень сложно масштабировать: при отсутствии автоматизированного тестирования невозможно контролировать ее стабильность. Попытки внести изменения и развить продукт приводят к задержкам релизов и возникающим на стадии продакшена багам, что негативно сказываются на репутации заказчика. Разработка и поставка проходят напряжённо и в режиме стресса для всех участников процесса. Дополнительно осложняет ситуацию то, что компанией управляют несколько совладельцев с разными точками зрения относительно развития продукта и стратегии выхода из кризиса на проекте.
На данном проекте Дмитрий проводил консультирование по нескольким осям. Ситуация требовала проработки технических сложностей, улучшения процессов, налаживания конструктивной и результативной коммуникации между совладельцами компании и стабилизации психологической обстановки. Для эффективного внедрения улучшений важно было получить доверие и содействие фаундеров и команды.
Начав консультации с личного общения с заказчиком, Дмитрий развивал работу с компанией в нескольких направлениях.
Дмитрий выступал в качестве медиатора — независимой стороны, способствующей достижению единого мнения между владельцами продукта, имеющими разные точки зрения. Собственники осознавали необходимость улучшения процессов, но предлагаемые ими варианты не помогали устранить источник проблемы. Каждый из них был опытным специалистом, бескомпромиссно отстаивающим свою точку зрения, поэтому им было очень сложно достичь общего видения и совместно выбрать стратегию управления.
Значительную роль в установлении доверия сыграл высокий уровень эмпатии со стороны Дмитрия. Изначально в сотрудничестве между ним и фаундерами было много общего: обе стороны имели опыт руководства собственной ИТ-компанией, инвестирования и вывода на рынок высокотехнологичного коммерческого продукта, а также использования услуг стороннего консультанта. Совокупный бэкграунд в данных направлениях позволил Дмитрию чётко определить, какие страхи и сомнения испытывает каждый собственник. Понимая их боли и опасения, он настраивал фаундеров на долгую, продуктивную работу, объяснял, почему невозможно стабилизировать ситуацию на проекте за 1-2 месяца. Ему было важно показать, что в команде отсутствует культура работы с техническими долгами, что на проекте накопилось очень много технических проблем.
Еще одной важной задачей стало вовлечение в особенности процессов разработки ПО коммерческого руководителя проекта, не обладающего знаниями и опытом в данной сфере. Было необходимо не только объяснить пользу внедрения инженерных практик для бизнеса, но и простым языком истолковать сложные инженерные понятия и подходы, а также постоянно напоминать, почему те или иные улучшения невозможно реализовать быстро. Дмитрий приводил реальные примеры из практики своей компании, рассказывал о похожих проблемах на проекте, с которыми ему приходилось сталкиваться. На всех этапах улучшений погружал собственника в технические нюансы продукта и в актуальные ИТ-процессы. В конечном итоге спустя год с момента первого общения, коммерческий директор компании-заказчика отлично разбирался в понятиях, касающихся разработки ПО, и мог самостоятельно инициировать улучшения на проекте (например, увеличение уровня покрытия кода автотестами).
В процессе личных консультаций с Дмитрием собственники бизнеса осознали необходимость внедрения инженерных практик и работы с техническими долгами, начали более глубоко заниматься ИТ-стороной проекта и погружаться в процесс разработки. Если изначально коммерческий директор не мог поднять тему технических долгов при общении с другими фаундерами, то сейчас собственники совместно и открыто обсуждают стратегию работы над ними.
Для достижения общего мнения Дмитрий инициировал полную честность и прозрачность в коммуникациях между фаундерами: открытые фидбеки, оповещение остальных собственников о любых принятых решениях относительно проекта (в письмах и мессенджерах).
Огромный объём технического долга критически усложнил постоянную работу с ним на протяжении каждого спринта. На первых порах было необходимо заработать доверие команды и небольшими итеративными изменениями продемонстрировать возможность проработки долга даже в условиях постоянной занятости разработчиков коммерческими задачами.
Важнейшими факторами успеха на этом этапе консультирования стали терпение и упорство. В начале сотрудничества Дмитрий подробно объяснял фаундерам и команде необходимость работы с техническими долгами, далее постепенно инициировал улучшения. Сохраняя высокий приоритет коммерческой работы, инженеры каждый день продвигались в задачах по устранению технического долга (1 час в день). Такой подход позволил не терять фокус на коммерчески важных поставках, но вместе с тем последовательно добиваться прогресса в работе над накопившимися техническими долгами.
Данная стратегия привела к тому, что у инженеров начало проявляться технологическое лидерство. Фаундеры и команда увидели, что инициируемые улучшения не несут для них угрозы, а наоборот, приносят ощутимую пользу. В процессе улучшений были проработаны следующие технические долги:
По согласованию с собственниками бизнеса, было решено усилить роль инженеров на проекте, увеличить степень самоорганизации команды. Для этого использовали лучшие подходы методологии Scrum. Ежедневные стендапы повысили уровень синхронизации географически распределенной команды. Демо нового функционала перед всей командой способствовали достижению общего понимания актуальных статусов на проекте. На регулярных ретроспективах оперативно решались возникающие недопонимания и проблемы. Постоянно поднималась тема важности реалистичного подхода к разработке: команда должна была быть честной в эстимировании задач, оценке своих сил. Мнение всех участников проекта было выслушано, владельцы продукта начали учитывать и обрабатывать предложения и замечания инженеров. Налажена системная передача знаний внутри команды — установлена практика регулярного проведения лекций и митапов по технологической или доменной экспертизе. Всё это способствовало улучшению психологического климата и преодолению выученной беспомощности инженеров. Они стали более самостоятельны и не боялись проявлять инициативу.
В команде установилась здоровая психологическая атмосфера, участники проекта стали более искренними и начали доверять друг другу. Благодаря постоянному инициированию общения была введена практика общих обсуждений актуальных проблем, вопросов. Когда все участники проекта были честны и не скрывали возникших сложностей, удавалось найти наиболее оптимальные решения, избежать большого количества рисков и конфликтов.
В процессе консультирования Дмитрий применил триаду своего опыта.
Видение Дмитрия не являлось точкой зрения только инженера, работающего с техническими долгами, или предпринимателя, сосредоточенного исключительно на бизнес-составляющей проекта. Дмитрий использовал весь свой опыт, анализировал ситуацию с разных сторон и концентрировался на глубинной сути возникшей ситуации (таких проблемах, как отсутствие лидерства и выученная беспомощность у инженеров, отказ от инвестиций в технические долги).
Поскольку ситуация на проекте была действительно сложной, одна из главных целей, на которых изначально концентрировался Дмитрий — не навредить. Важно было не ухудшить отношения между фаундерами. Поэтому он тщательно анализировал психологические аспекты проекта и деликатно, обходя острые углы, налаживал коммуникации. При этом Дмитрий не допускал политических игр, а действовал честно, что было оценено заказчиком.
Когда владельцы вверяли трансформацию процессов своей компании стороннему консультанту, они были очень насторожены. Обладая обширным управленческим опытом, Дмитрий четко понимал, почему фаундеры сомневаются. И одной из первостепенных задач на старте консультирования стало установление доверительного сотрудничества. В данной ситуации крайне важную роль играл искренний подход: необходимо было выстроить консультирование так, чтобы собственники и команда доверились Дмитрию и не допускали мыслей о провокации или обмане. Для этого он всегда подробно аргументировал и пояснял все свои действия и решения.
Менеджеры, сопровождающие консалтинг и организующие процесс улучшений, не демонстрировали команде своего превосходства, терпеливо продвигались вперёд, опираясь на собственный обширный опыт декомпозиции и эстимирования задач. Нововведения на проекте внедрялись постепенно, при этом Дмитрий постоянно обращал внимание собственников и инженеров на небольшие, но очень важные результаты, которых они достигли.
Благодаря тому, что Дмитрий трезво оценивал ситуацию на проекте и был конструктивен, ему удалось настроить команду на позитивный лад. Предсказуемость и оптимизм подпитывали силы и чувство уверенности владельцев компании и инженеров.
“Мы обратились к Дмитрию, чтобы ускорить развитие нашего продукта и выйти из технологического кризиса. На проекте были сложности с планированием поставок, оценкой задач и рисков. Релизы срывались и проходили с задержками. Мы хотели быстрее решить вопрос нестабильности релизов, масштабировать продукт и внедрить эффективные технологические подходы.
Изначально мы не осознавали масштаба проблем на проекте. После нескольких встреч с Дмитрием начали понимать, что нужно настраиваться на игру в долгую. Некоторые процессы нужно было поставить с нуля. Уже спустя несколько месяцев с начала консультирования на проекте активно велись работы по внедрению автотестов и CI/CD. В процессе мы постоянно получали небольшие результаты и это мотивировало к работе над сложными задачами. После введения Scrum и общения с Дмитрием разработчики начали активнее высказывать свое мнение, начали писать Unit-тесты и давать более точную оценку своим задачам. В целом, процессы, затраты, продуктивность команды и результаты ее работы стали более предсказуемыми.
Мы доверили Дмитрию многое, при этом всегда сохранялось ощущение, что всё под контролем и решение наших проблем доверено профессионалу. Во время консультаций он подробно объяснял пользу разных инструментов и практик, аргументировал каждое решение. Рекомендуем Дмитрия как внимательного консультанта, который бережет и уважает созданное вами.”
Приветствую! Меня зовут Дмитрий Горячко. Специально для вас я подготовил чек-лист, который поможет определить, в опасности ли ваш проект, и предоставит чёткое количественное измерение сложности ситуации.
В процессе создания документа я применил многолетний опыт управления, координирования, супервайзинга и консалтинга на более чем 100 IT-проектах. Каждый пункт чек-листа является отражением наиболее частых трудностей, которые я видел в командах разработки в своей консультационной практике.
Также чек-лист содержит большое количество практических советов. Это поможет вам самостоятельно продвигаться по решению проблем.