На связи Deventica. С 2008 года мы занимаемся разработкой комплексных сервисов и мобильных приложений, помогаем строить команды разработки и совершенствовать уже существующие продукты. За 15 лет наша команда смогла поработать с самыми разными из них - от небольших социально-ориентированных стартапов до крупнейших медиасервисов, логистических платформ и финтеха.
В этой статье поделимся наиболее распространенными проблемами, которые оказывают негативное влияние на жизненный цикл продукта, но при этом имеют не всегда очевидные причины. Кейсы, которые мы рассмотрим, являются результатами многолетних наблюдений. Все имена выдуманы, а совпадения - случайны.
Тип 1: Препятствия, связанные с командной работой
В первую очередь проявляются в том, что команда не может работать слаженно и эффективно. Например:
- Требуется много времени и ресурсов, чтобы погрузить сотрудника в проект.
- Невозможно найти подходящего человека или это занимает много времени.
- Сотрудник старшего уровня занимается слишком примитивными задачами и наоборот - начинающему специалисту постоянно ставят сложные задачи.
Рассмотрим ситуацию, в которой это сказалось на скорости вывода новой функциональности на рынок.
Кейс: Финтех-платформа испытывала сложности с наймом и онбордингом
Давайте познакомимся с Иваном. Он занимает должность менеджера проекта на динамично развивающейся финтех-платформе. В связи с растущим пулом задач, его команде понадобился новый веб-разработчик, в то время как один из текущих специалистов принял решение покинуть команду. Иван обратился за помощью к техлиду, Александру, с просьбой провести интервью кандидатам от подрядчика. Александр согласился, но ни один из представленных кандидатов не удовлетворил требованиям компании. В связи с этим, Иван заинтересовался причинами такого исхода.
Типичные сценарии
- Поиск нового сотрудника на рынке в среднем занимает больше месяца (подходит 1 из 10-15). В то время как открыто большее число позиций. Как правило, процесс отбора не согласован между отделами подбора и специалистами, проводящими технические интервью.
- Новые сотрудники тяжело вливаются в проект по совокупности причин, что приводит к частым ротациям среди новичков.
Скрытые проблемы
Несмотря на кажущиеся очевидными причины, зачастую именно невидимые проблемы создают больше всего сложностей. Например, в нашей ситуации помимо явных причин, можно выделить и несколько неявных:
- Некорректно функционирующий процесс онбординга (в т.ч. отсутствие материалов для плавного погружения в проект),
- Ключевые специалисты или ЛПР перегружены работой (здесь, кстати, много своих неявных причин, но чаще всего встречаются проблемы с делегированием),
- В процессе отбора кандидатов есть избыточные шаги либо имеются некорректные требования к позиции (например, часть требований можно исключить за счет корректного процесса онбординга либо обучения),
- Технические интервьюеры плохо подготовлены,
- Слишком большая цепочка принятия решений, принятие решений растянуто во времени.
Варианты решения
Иван совместно с Александром смогли исправить положение с помощью следующих шагов:
- Провели ревью требований к позиции и обновили описание вакансии,
- Синхронизировались между собой, согласовав единый алгоритм оценки технической экспертизы кандидата (что позволило исключить разночтения на стороне технических собеседующих и избежать поиска “единорога”).
- Разделили онбординг для разных подразделений/квалификаций сотрудников, проработав недостающие материалы.
Поиск - не всегда означает работу по отбору кандидатов. Нередко, часть этой работы - это этап, когда новичок погружается в проект. Поэтому важно, чтобы каждый этап поиска - от составления требований до завершения онбординга был синхронизирован с остальными, ответственные исполнители были также погружены в контекст конкретного подбора, а также ориентированы на решение конкретной бизнес-задачи, связанной с тем или иным поиском.
Тип 2: Препятствия в процессах разработки ПО
Эта разновидность отличается своей локализацией - в отличие от остальных типов, эти сосредотачиваются вокруг процессов разработки программного обеспечения и оказывают серьезное влияние на различные характеристики продукта (отказоустойчивость, масштабируемость, сопровождаемость и т.п.). К данному типу можно отнести следующие ситуации:
- База устаревшего кода растет, нет времени работать с ней.
- Продукт непредсказуемо ведет себя на production окружении, что не воспроизводится на других окружениях либо возникают ситуации, в которых система ведёт себя непредсказуемо.
- Релизные сборки и прочие артефакты не предоставляются вовремя. В том числе, это относится к различным сборкам демо-комплексов для стендов на различных мероприятиях.
Рассмотрим ситуацию, в которой это сказалось на взаимоотношениях между партнерами компании, что могло повлечь потерю инвестиций.
Кейс: Рост устаревшей кодовой базы в медицинском стартапе
Познакомимся с Ольгой - основателем медицинского стартапа. Недавно, она нашла бизнес-партнера, одним из условий которого стало добавление новой функциональности в продукт. Команда Ольги всеми силами пытается выполнить пожелание нового партнёра, но менеджер проекта начинает замечать, что время вывода функциональности в релиз постоянно увеличивается. Партнёр Ольги расстроен из-за срывающихся сроков, и она ищет решение возникшей проблемы.
Типичные сценарии
- База устаревшего кода растёт, у команды нет времени на рефакторинг.
- Ошибки влияют на разработку новых модулей и не могут быть исправлены без рефакторинга.
- Дедлайны срываются вследствие неточных оценок, вызванных наличием большой базы легаси кода.
- Руководители высшего звена слишком привязаны к процессу разработки и не имеют достаточно времени на выполнение своих бизнес-задач и выстраивание процессов разработки.
Скрытые проблемы
В данной ситуации можно выделить несколько неявных проблем:
- Ведущий инженер перегружен или его нет,
- Слабая приоритизация задач или проектный менеджмент,
- Интенсивный релизный цикл,
- Команда разработки перегружена или выгорела,
- Быстро меняющиеся или неясные требования, инфраструктурные проблемы,
- Отсутствие необходимых специалистов, их участки закрывают собой ЛПР и теряют возможность фокусироваться на потребностях бизнеса.
Варианты решения
В приведенном примере, Ольга провела глубокое исследование и приняла несколько решений:
- Команды разработки и менеджмента начинают делиться обратной связью, чтобы обнаруживать проблемы как можно раньше,
- Выделить время на работу с техдолгом,
- Сформировать дорожную карту по найму недостающих специалистов и согласовать требуемый бюджет.
- Вынести все инфраструктурные проблемы на более высокий уровень обсуждения.
Данный тип проблем достаточно объёмный, поэтому важно выявить все скрытые детали и спланировать такую дорожную карту изменений, которая поможет качественно изменить сложившуюся картину.
Тип 3: Препятствия в управлении
В управлении проектом/продуктом можно встретить самые разные недочёты:
- Неправильное применение методологии: встречи занимают слишком много времени или сотрудники не вовлечены. Низкая результативность совещаний.
- Проблемы с развитием продукта: бесполезные метрики, которые невозможно использовать при принятии решений, низкая конверсия.
- Ошибки планирования: оценки неточные, что сказывается на плане работ и срыве дедлайнов.
Данный тип обширен и может так или иначе влиять на связанные процессы, поэтому стройность процессов управления принципиально важна для практически любого проекта/продукта.
Кейс: Проблемы с менеджментом у платформы маркетинга
Познакомимся с Алексом. Алекс - менеджер продукта, его цель - сделать продукт популярнее. Он рассматривает разные варианты получить больше статистики по использованию приложения. Однако, у приложения, с которым он работает, нет никакого набора инструментов для предоставления подобной информации. Команда разработки не может добавить новую метрику для сбора статистики и необходимо как найти способ исправить это, так и скорректировать бэклог.
Типичные сценарии
- Применение бесполезные продуктовых метрик в прошлом.
- Неточная оценка на реализацию сбора статистики, что сказывается на приоритизации этой задачи.
Скрытые проблемы
Нередко для достижения успеха необходимо проявлять гибкость. Формат “так было - не будем менять” может как помочь сохранить стабильность, так и полностью её утратить. Примерами скрытых проблем для данного типа могут служить следующие:
- Слабая компетенция у менеджера продукта,
- Некорректная дорожная карта,
- Плохая техническая документация,
- Ошибки, связанные с планирование работ.
Варианты решения
Аналитика - очень важная часть сопровождения и развития программного обеспечения. Но, чтобы её применение приносило результат и давало необходимую почву для размышлений и экспериментов, необходимо грамотно проектировать данную подсистему и выбирать решения, которые позволят собирать и анализировать накапливаемую статистику. В противном случае, метрики могут оказаться некорректными, бесполезными или искажать реальную картину. Поэтому, чтобы решить проблему, Алекс рассматривает следующие варианты:
- Поделиться целями и роадмапом с командой, чтобы объединить всех их единым понимаем.
- Провести груминг задач и приоритизировать критически важные, в т.ч., если они относятся к техдолгу.
- Вовлечь команду в работу над роадмапом. Поддерживать культуру инноваций, экспериментов и обратной связи.
- Запланировать внедрение недостающих инструментов (в т.ч. инструментов аналитики).
Приведенные ситуации - примеры, с которыми сталкиваются многие стартапы или уже закрепившиеся на рынке продукты. Нередко за очевидными проблемами скрываются не самые очевидные причины, которых может быть гораздо больше, чем в приведенных примерах. Помимо этого, они могут пересекаться между собой и искажать восприятие тех проблем, которые действительно существуют. Например, может казаться, что если все необходимые инструменты предоставлены, а процессы разработки “выше всяких похвал”, то дальше развитие продукта пойдёт само собой. Но, это не так и нужно явно различать все процессы, задействованные в производстве продукта и стремиться всегда заглянуть чуть глубже, чтобы работать именно с причиной проблемы, а не ее следствием.
Опыт инженеров Deventica позволяет на ранних этапах идентифицировать и предлагать наиболее эффективные варианты устранения различных проблем и узких мест. Наша ценность - люди. Мы верим, что за каждой задачей стоит человек, который отвечает за ее реализацию, которому важны те или иные показатели (скорость вывода на рынок, производительность системы, бюджет и др.), поэтому стремимся стать партнерами в их решении, выходя за рамки выполнения конкретных задач. Примеры можно найти среди наших кейсов:
- выстраивание QA процессов на проекте, где CEO и CTO стали заложниками процессов разработки, что в итоге помогло освободить их время и сосредоточиться на развитии линейки продуктов;
- участие в запуске новых продуктов в рамках крупнейшего медиапроекта;
- построение процессов разработки в рамках финтех-стартапов и др.
Желаем успешного завершения 2023! Вернемся со следующими статьями в Новом, 2024 году!