В компании несколько команд, я работаю в одной из них. Я хочу, чтобы чужая команда реализовала фичу, нужную мне. Известно, что у команды есть основной заказчик и его запросы они всегда ставят в приоритет, а моя задача скорее всего влетит в бэклог на два месяца. Как ускорить прохождение моей задачи?
Конечно, подобные ситуации должны быть исключением, а не правилом. Для этого нужно делать предварительную работу. Дело в том, что когда тебе что-то нужно от людей, ты по умолчанию приходишь со слабой позиции. В слабой позиции нельзя находиться долго. Если ты ходишь по домам и разносишь бесплатные билеты на концерт, в первый раз тебе с удовольствием откроют двери и поговорят. Даже возьмут твои билеты. Но когда увидят их оборотную сторону (она всегда есть), могут больше дверь и не открыть.
Допустим, предварительная работа не была проведена. Возможно, ты внезапно оказался в незнакомом окружении. Поэтому к вопросу нужно подойти аккуратно и в несколько шагов.
№ 1. Разведка
Ключ к любым переговорам – осознание пожеланий другой стороны.
Со стороны проекта ты выглядишь как stakeholder (возможно, пока ещё не оформившийся до конца). При первом же разговоре с менеджером проекта тебя осознанно или неосознанно впишут в Power-Interest matrix. Нужно ещё до разговора честно ответить себе, в каком квадрате ты (Apathetics, Defenders, Latents или Promoters). Затем нужно понять, в каком квадрате тебе нужно оказаться.
Нужно представлять, чем занимается команда. Лучше всего - это понять её как функцию в математическом смысле – какие n переменных она принимает на вход и какие m переменных она выдаёт на выход. Такие детали, как занятия конкретных членов команды ни к чему, они даже будут мешать в дальнейших переговорах.
Хорошо, если после разговора с представителем команды стало понятно, как они расставляют приоритеты. Например, они могут подходить к вопросу демократично (голосованием на планированиях) или авторитарно (жёсткий пул задач от одного человека, который нужно выполнить во что бы то ни стало).
Отлично, если стало понятно, чем обусловлены приоритеты. Например, многие команды и даже организации скажут тебе спасибо, если твой запрос к ним оформлен по их стандарту. Бывает, что на этот стандарт у них завязаны KPI. Сделав предварительную работу, ты снимаешь с них много головной боли по оформлению требований и улучшаешь их KPI. Поэтому для них довольно легко взять задачу в работу. Также бывает, что твоя задача для этой команды даёт отрицательный ROI. Например, команда решает вопрос многомиллионных ежедневных убытков прямо сейчас и у них действительно все задачи критичные. Странно давить на них в этой ситуации, лучше дать людям спокойно поработать и потушить пожар.
Однако чаще всего людям просто не хочется брать “ещё одну некритичную задачу” от Apathetics. Поэтому переходим к следующему пункту.
№ 2. Поставить цель себе
В любом деле важно очень чётко понимать, что ты хочешь. Здесь мы хотим повлиять на чужой проект. Говорить людям прямо так довольно странно.
Поэтому формулировки, с которыми задача будет передаваться исполнителям, имеют критическое значение. Иначе получится не совсем то, что хочешь.
Конкретно в этом вопросе нужно ещё до похода с просьбой оформить задачу по такой форме: “делайте A, потом B, у вас получится результат C, это для вашей команды выйдет в такую-то пользу”.
№ 3. Поставить задачу команде
Ещё до постановки задачи стоит подготовить меры контроля, смотри пункт № 4.
Как правило, точка приложения силы гораздо важнее силы. Нужно только правильно выбрать точку. Она находится в картине мира команды. Так как ты приходишь со слабой позиции (тебе что-то нужно), кроме манипуляций с картиной мира команды, пути нет. Картину мира можно поменять в их головах или снаружи. Как правило, первое гораздо проще и безопаснее.
Смена картины мира изнутри
Для этого нужно указать, какие риски человек не учёл. Они могут быть в прошлом или будущем. Например, “с этой фичей в прошлом вы могли бы решать проблемы быстрее” или “эта фича вам пригодится в будущем, когда поступит требование государства”. Качество разведки из пункта №1 здесь играет критическую роль.
Иногда люди могут делегировать свою картину мира тебе. Принимать делегирование нужно с умом. Например, минимальная допустимая детализация – ролевая. Это значит, нельзя принимать “Алексей из нашей команды займётся этим”. Можно принимать “разработчик из нашей команды займётся этим”. Распределением задач должен заниматься непосредственный руководитель команды. Если он начинает распределять задачи не по ролям, а по людям, это снижает его уровень как руководителя. Алексею тоже будет неприятно оказаться в ситуации с двумя руководителями. Более подробно про уровни руководителя можно посмотреть здесь.
Смена картины мира снаружи
Очевидный путь – эскалация проблемы наверх. Обычно люди рассчитывают на то, что приоритеты бизнеса изменятся глобально и твоя задача попадёт в топ по приоритетам. Так делать можно, но только в крайних случаях и с большой осторожностью. Иначе результат может иметь противоположный эффект. Можно пожаловаться президенту, что в магазинах нет черных ручек и получить закон о запрете ручек и замене их на карандаши. Тема эскалации богатая и заслуживает отдельного поста.
Путь, требующий больше усилий – смена процессов или организации команд. Например, некоторые компании именно поэтому решают адаптировать матричную структуру. Некоторые вводят очень короткие итерации. Всё зависит от контекста вашей компании, что-то может сработать, а что-то нет. Главное, на что нужно ориентироваться в этом процессе – это не идти в сторону economies of scale (так было в нулевых), а идти в сторону economies of speed (так стало в cloud-эру). Например, вся суть движения DevOps – это превращение economies of scale (отдельный отдел Ops) в economies of speed (когда разработчик с может написать c нуля и задеплоить сам сервис за полдня). Стартапы и живут только за этот счёт. Первый коммит и деплой у них появляется за 20 минут, а в больших компаниях за 20 дней. Если сравнить скорость, 20 дней * 24 часа * 60 минут / 20 минут = 1440. Разница на три порядка.
№ 4. Контроль
Желательно не работать в режиме опроса исполнителей, это плохо масштабируется. Лучше заводить роадмапы с с оценками, на которые все согласны, и позволять исполнителям их обновлять самим.
Долгосрочные роадмапы должны быть публичны и доступны всем. Эти роадмапы должны быть порезаны на этапы с чёткими критериями окончания этапов. Тогда твоя роль сводится к тому, что ты оповещаешь заинтересованных людей о неожиданных поворотах роадмапах, а также всячески поддерживаешь интерес к теме (например, проводишь исследования и публикуешь результаты). Иначе она заглохнет.
Дополнительно, стоит лично проверять всё, что несложно проверить. Некоторые считают, что если всё проверять, то в их окружение будет считать их “колючим ёжиком”. Это не так. По мере проверок и обнаружения проблем человек приучает окружение, что ошибки, небрежность или плутовство с ним не пройдут. Тогда окружение само усвоит этот стиль, прежде чем его информировать, само превратится в “ёжиков” — требовательных и внимательных. И не будет его больше подводить.
Тогда можно для обученного окружения спрятать иголки и проявлять больше доверчивости, перенеся контроль из настоящего в будущего. Перестать быть “ёжиком”. Зато окружение станет “ёжиками” по отношению к окружающей среде. С такой командой легко работать добросовестно и сложно – спустя рукава.
Последнее не стоит путать с микроменеджментом. Здесь суть в том, что проверки можно делать без участия исполнителей, и только в ключевых местах. То есть это вообще не тратит время впустую, в отличии от микроменеджмента.