Как менеджерам научиться ставить задачи разработчикам

Когда речь заходит о разработке, менеджеры и управленцы сразу вспоминают накопившийся массив задач, которые ждут своей очереди, непредсказуемые сроки их реализации, имеющие свойство постоянно меняться, натянутые отношения с IT-отделом, который использует систему «свой-чужой», и множество других проблем, тормозящих развитие бизнеса. Чтобы решить все эти проблемы, необходимо научиться грамотно ставить задачи и общаться с разработчиками. О том, как менеджеры должны ставить задачи, чтобы они были выполнены в срок и в соответствии с заданием, рассказывает Николай Хлебинский, СЕО и сооснователь платформы Retail Rocket.

Содержание:

• Постановка задач: почему это сложно и как научиться делать правильно
• Генерируйте идею правильно
• Описывайте задачу максимально подробно
• Оценивайте каждую задачу
• Приоритезируйте задачи
• Сначала создавайте MVP
• Увеличивайте продуктивность команды разработки
• Станьте своим
• Чек-лист: как научиться ставить задачи разработчикам

Постановка задач: почему это сложно и как научиться делать правильно

Постановка задач — это боль многих менеджеров. Кажется, что написал задачу, скинул разработчику — и дело сделано. Но на деле всё не так. Задача либо задерживается, либо выполнена не так, как ожидали. Почему? Потому что менеджеры и разработчики говорят на разных языках.

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

Частая ошибка — слишком общие формулировки. Например: «Добавить фильтр к списку заказов». Для менеджера всё понятно, а разработчик в замешательстве: какие поля фильтровать? В каком формате? Сортировка нужна? Сколько времени есть? Чем больше вопросов остаётся без ответа, тем выше шанс получить не тот результат.

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

Почему важно научиться ставить задачи? Чтобы избежать срывов, стресса и переделок. Конкретная задача экономит время: сразу понятно, что делать и как. У разработчиков нет «лишних» вопросов, нет места для неверных интерпретаций. Они могут сосредоточиться на работе, а не на попытках разобраться в абстракциях.

Умение ставить задачи — это навык, который сразу делает проект управляемым. Задачи выполняются в срок, разработчики не перерабатывают, качество продукта растёт. И самое главное — уходит хаос, снижаются нервы. Команда работает слаженно, потому что все понимают, что и зачем они делают.

Генерируйте идею правильно

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

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

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

У нас в Retail Rocket идею может сгенерировать любой член команды, и она заносится на определенную доску в Trello. В своей работе мы используем идеологию Канбан и для каждого процесса в компании, для каждого отдела, есть своя доска. Идеи по продукту записываются в определенный столбец, но чтобы это сделать, менеджер (или любой сотрудник) должен сформулировать ее краткое описание. То есть не просто «ограничить количество символов в отзывах» или «добавить кнопку быстрого заказа», а внятное описание, из которого будет понятно, зачем нужна новая функция и чем она будет полезна.

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

Поэтому первое правило: Задача может быть внесена в идеи, только если человек готов сформулировать её краткое описание.

Описывайте задачу максимально подробно

После этого в дело вступает продакт-менеджер – это отдельная роль, которая занимается управлением продуктом. Задача этой роли – сбор требований и подготовка этих требований к передаче в разработку. То есть постановщик идеи не общается с разработкой напрямую.

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

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

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

Третье правило: product-менеджер должен сформировать список тех, кто будет тестировать фичу и определять ее эффективность.

Это значит, что во-первых, идея не может идти в разработку, пока не определен список тех, кто будет отвечать за ее проверку, после того, как она выйдет из IT-отдела. И во-вторых, пока не будут четко определены критерии эффективности.

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

Оценивайте каждую задачу

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

Четвертое правило: каждая задача должна быть оценена в деньгах

Приведем пример. Существуют триггерный сценарий – письмо о «брошенной корзине», которое интернет-магазин отправляет пользователям, которые добавили товар в корзину, но не оформили заказ. Один из клиентов попросил отправлять повторное письмо в случае, если цена на один из товаров в корзине снизилась. Чтобы посчитать стоимость этой задачи, менеджер продукта пришел с запросом к аналитикам и попросил посчитать, на какое количество товаров снижается цена за неделю на 5% и более. Аналитики посчитали, что около 10% товаров, оставленных в корзине, в сегменте fashion за неделю снижают цену на 5% и более. Это означает, что мы можем увеличить количество отправок писем о брошенной корзине на 10% и, соответственно, получить на 10% больше заказов. Таким образом за неделю мы получили оценку задачи в деньгах.

И все эти процессы происходят пока без участия разработчиков, т.е. мы не отрываем их от текущих задач.

Приоритезируйте задачи

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

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

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

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

Только теперь начинается работа IT-команды над задачей.

Сначала создавайте MVP

Когда доходит дело до разработки, важно первую версию фичи сделать максимально дешевой и простой в производстве, чтобы максимально быстро протестировать гипотезу. То есть создать MVP (Minimal Viable Product). На этом этапе важно проверить критерии эффективности, которые были определены при описания задачи.

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

Шестое правило: разрабатывайте полноценную версию фичи после подтверждения ее эффективности через MVP

Увеличивайте продуктивность команды разработки

Никто, кроме менеджера продукта и, возможно, генерального директора, не должен общаться с разработчиками. Они должны находиться в отдельной комнате и никто не должен к ним заходить. Это поможет в разы увеличить эффективность работы IT-отдела. Потому что человеку, чтобы сконцентрироваться даже на простой задаче, нужно потратить 15-20 минут, чтобы только приступить к выполнению. И если через 15 минут к нему подходит кто-то с вопросом (а такое случается постоянно, и чем больше компания, тем чаще), человек выходит из состояния концентрации. А значит, ему снова нужно 15-20 минут для погружения. Т.е. как минимум 30-40 минут уже потеряно впустую. И если 5-7 человек в день подойдут к разработчику с вопросом, можно считать, что за день он ничего не сделал.

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

Мы решили эту задачу выделив под IT отдельную комнату, вход в которую всем остальным сотрудникам запрещен. На двери висит отдельный замок, ключ-карта к которому есть только у самих инженеров и еще нескольких людей в компании.

Еще один важный момент: нужно построить вокруг IT-отдела «защитный купол», т.е. оберегать от любых проблем, решать все вопросы, обеспечить инфраструктуру, чтобы они не занимались ничем, кроме производства кода. Неслучайно в корпорациях, таких как Яндекс или Google, офисы полностью обустроены так, чтобы человеку можно было практически не уходить домой. Если сотрудник будет заниматься поисками чая, кофе или батарейки для мышки, он будет гораздо меньше времени тратить на свои непосредственные обязанности. Обеспечить дорогостоящих квалифицированных специалистов всем необходимым гораздо дешевле, чем тратить их время на нецелевые действия.

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

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

Станьте своим

Если хотите лучше понимать разработчиков — учитесь говорить на их языке. Не обязательно становиться программистом, достаточно освоить азы: разберитесь, что такое HTML, CSS, JavaScript. Потратьте на это 10–20 часов, и это вложение окупится сторицей.

Зачем вам это? Представьте: разработчик говорит, что надо «оптимизировать скрипт», «поправить стили», «убрать баг». Эти слова не должны звучать как заклинания из другого мира. Чем больше вы понимаете, тем проще вам оценивать задачи, ставить адекватные сроки и избегать глупых ошибок.

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

Разберитесь в JavaScript — и вы перестанете думать, что любой «поправить» занимает пять минут. Вы поймёте, что за простыми действиями скрываются сложные процессы: написать код, протестировать, интегрировать. Это не магия, а чёткий план работы, где важна каждая мелочь.

Что даёт вам этот опыт? Вы начинаете говорить на одном языке с разработчиками. Не как начальник и подчинённый, а как члены одной команды. Вы слышите и понимаете друг друга. Разработчик видит, что вы не просто «руководите», а вникаете в суть работы. Это вызывает уважение и доверие. Когда команда чувствует, что её понимают, она работает лучше и охотнее идёт на контакт.

Курсы — это не только знания. Это сигнал команде: «Я готов разбираться в вашем деле, чтобы нам всем работалось проще». Это то, что помогает сломать барьеры, наладить общение и создать крепкую рабочую связку. Поставьте себя на место разработчиков, и вы увидите, как изменится ваше общение.

Чек-лист: как научиться ставить задачи разработчикам

✅ Формулируйте идею чётко. Опишите, что нужно сделать и зачем, чтобы было ясно, какая польза от функции.

✅ Детально опишите задачу. Распишите все детали: сценарии, ошибки, интерфейс. Это упростит работу разработчиков.

✅ Назначьте тестировщиков и метрики. Определите, кто проверяет фичу и по каким критериям успеха.

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

✅ Приоритизируйте задачи. В первую очередь берите те, что принесут максимум выгоды при минимуме времени.

✅ Начинайте с MVP. Быстрая и дешёвая версия для проверки гипотезы — прежде чем делать полноценную фичу.

✅ Ограничьте доступ к разработчикам. С ними общается только продакт-менеджер, чтобы не отвлекать от кода.

✅ Создайте комфортные условия. Оборудуйте рабочее пространство, уберите всё лишнее.

✅ Учитесь основам кода. Знание HTML, CSS, JavaScript поможет лучше ставить задачи и понимать команду.