Готовь бэклог летом, а разработку зимой. 5 простых правил работы с клиентским бэклогом в заказной разработке

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

Привет, VC!

Рынок заказной разработки в последние годы стал очень конкурентым. Появилось много молодых и активных игроков, которые «отбирают работу у ветеранов». Многим приходиться мимикрировать и адаптироваться под новые реалии. У нас в Hawking Bros исторически сложилось так, что тот подход, который мы заложили в проектное управление и клиентский сервис, остается актуальным и сегодня.

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

По статистике, отсутствие проактивности продакшена – одна из самых частых причин смены подрядчика. Кто-то решает эту проблему дополнительными аккаунт-менеджерами, кто-то частыми встречами, но если это не несет пользы клиенту, то декорации долго не простоят и все равно рухнут.

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

Я очень люблю посещать отраслевые выставки и общаться с представителями различных бизнесов. Это помогает мне понимать истинные потребности экономики в данный момент, общие проблемы и задачи, а также находить новые идеи для развития клиентских проектов.

Например, мы посетили Кооперационную биржу, где за различными круглыми столами был один и тот же вайб: «дайте людей, помогите купить оборудование и вы не узнаете нашу экономику».

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

На днях коллеги из компании IT-pelag выпустили исследование о спросе на аутстафф-специалистов в 3 квартале 2023 года. Из него следует, что спрос на системных- и бизнес- аналитиков продолжает расти.

Я считаю, что это, в том числе, обусловлено процессным клише: «бизнес анализ – системный анализ – разработка». Среди прочих причин: отсутствие продуктовой экспертизы на стороне заказчика, дефицит продуктовых кадров в целом, отложенный спрос, перегрев экономики, сезонные факторы. Мы в Hawking Bros решили отойти от подхода, когда для проектной аналитики в 80% случаев используются стандартные интервью и опросы. Далее я приведу 2 кейса, которые подсветят, почему это верно.

Кейс № 1: понять причины низких продаж интернет-магазина автозапчастей, имеющего развитую сеть офлайн-точек.

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

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

Кейс № 2: построить новый экспресс-CJM (за 5-7 дней) для модного ритейла, с учетом того, что их конверсия выше средней по рынку.

Предложение аналитика: провести коридорные исследования в офисе, конкурентный анализ, проверить конверсии по товарным группам и попытаться сократить пользовательский путь.

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

Важный момент: речь идет не о разрушении всей системы управления проектом. Речь идет о пограничных случаях, когда нужно немного отступить от правил. Например, увеличить/уменьшить стандартный размер спринта. Или отказаться от диаграммы сгорания в пользу диаграммы Гантта.

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

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

Памятка для печати:

Также подписывайтесь на мой Телеграм-канал, где я делюсь эксклюзивным контентом о жизни Hawking Bros и заказной разработке, а если вы хотите позвать нас в тендер, то для этого есть почта [email protected].

Спасибо за внимание!