Про задачи, роли и позиции

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

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

Роль - это объединение нескольких задач в один пакет. Есть более-менее интуитивные роли - тот же тестировщик. Есть совершенно по-разному интерпретируемые - например, аналитик. Идеальных рецептов тут нет - главное, чтобы внутри команды все с отношениями роль-задача были согласны.

И третий уровень - позиция. Конкретная должность под конкретного человека.

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

• Нельзя разделять одну задачу между двумя ролями. Если договорились, что аналитик пишет ТЗ, то не надо ожидать, что для каких-то фич это ТЗ будет писать разработчик (тимлид, архитектор). Если это повторяется, то лучше разделить задачу на две и выдать носителям ролей.

• Нельзя разделять одну роль между двумя позициями. Если вы договорились, что у вас аналитик и ТЗ пишет, и согласованием занимается, то тот, кому эта роль досталась, и должен это делать. Опять же, если постоянно согласование достаётся другому человеку - нужно либо перебросить задачу на другую роль, либо роль согласующего выделить другому.

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

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

Про нетерпимость к неопределённости

Был у меня коллега. Проджект. Хороший, опытный, умеющий добиваться результата - до всех дойдёт, распланирует, когда надо - допинает.

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

— Вот план на квартал. Три фичи.

— Не, ты скажи, какая когда будет.

— Вот относительные приоритеты, делать будем в таком порядке. Но точные даты будут только после ресёрча. Не страшно: по зависимостям никого не держим; по метрикам - всё просчитано, неделя туда или сюда именно здесь погоды не сделает.

— Не, ну даты-то какие?

— Точные даты я тебе могу назвать, но они ж из головы будут.

— Пусть так, но пусть будут.

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

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

Кто-то в ней плавает как рыба в воде - где-то данными, где-то вопросами, где-то просто допущениями собирая для себя и для других точки опоры.

Кому-то это некомфортно - но зато если им эти точки опоры дать, они разгонятся и принесут результат.

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

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

Подбирался я к этой теме долго. От общего понимания, что разным людям по-разному даются разные задачи; через разделение задач на нацеленные на развитие и на операционную работу; через явное разделение команд на Run и Change.

Окончательно паззл сложился во время менторинга, когда я услышал похожие истории сразу от нескольких менти. Работа понятна, реализуема, но - не идёт. Слишком много операционки. Или наоборот, все хотят делать по науке, но недостаточно быстро.

И тогда я стал задавать прямой вопрос - а какой стиль работы в целом ближе? На развитие или на получение результата здесь и сейчас?

Потому что действительно это два разных майндсета - Run и Change. И давать людям с одним майндсетом задачи, органически более близкие другому - разок-другой можно, но в долгую и результат будет не лучшим, и человек выгорит очень быстро.

Людей с майндсетом Run:

• драйвит быстрый результат;

• не беспокоит необходимость возвращаться к одному и тому же предмету несколько раз;

• а вот подход "лучше день потерять, зато потом за час долететь" вызывает раздражение.

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

А майндсет Change:

• драйвит картина чего-то большого и красивого - но впереди;

• не любит возвращаться к уже сделанному, предпочтёт более сложную реализацию на перспективу;

• предпочтёт потратить побольше времени на подготовку.

Тут задачи уже другие: выстраивание процессов, инфраструктурные проекты, доделывание продукта после MVP.

Разумеется, шкала тут не дискретная, но всё же совсем универсалов я практически не видел - все явно склонялись либо к одному, либо к другому концу.

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