Допущения и ограничения в жизни менеджера

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

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

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

Это очередная статья из цикла статей и постов в моем ТГ канале о жизни менеджеров и необходимых им софтскиллах. Это то, чего обычно руководителям не рассказывают на курсах, но что вам понадобится с самого первого дня его работы. Если тема для вас интересная, подписывайтесь намой ТГ «Морковка спереди, морковка сзади» и читайте другие мои статьи тут, на Харбе).

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

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

Здесь у вас, как у исполнителя, есть несколько вариантов, что делать:

1. Работать по формальному процессу. Вы можете отказаться от оценки, ссылаясь на то, что по таким требованиям сделать ничего нельзя: «Сделайте нормальную постановку, ФТ, ТЗ и тд и тогда приходите». Это справедливо, если вам не платят за рвение, если расти вам в компании неинтересно, и вы р аботаете строго по процессу, принятому у вас в компании. Это самый базовый путь.
   Недостаток этого подхода в том, что заказчик понимает: вы совершенно не желаете ему помогать, а отбиваетесь по формальному признаку.

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

3. Третий путь — промежуточный. Не браться за работу, но и не отказываться, задавая вопросы «а как это должно быть сделано?» Это компромиссный вариант, но и при таком подходе вы занимаете пассивную роль, предлагая заказчику самому решить его проблему. А он часто решить ее не в силах, потому что он и сам фиг знает, что именно надо сделать.

Вот тут и приходит на помощь магия допущений и ограничений. Этот та самая волшебная палочка, которая позволяет превращать ХЗ в ТЗ, при этом:

• Формируя у заказчика понимание того, что вы реально ему хотите помочь, а не формально отбрить.

• Формируя ожидания того, что что заказчик  получит и не получит на выходе.

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

• И позволяет вам не говорить то самое всеми нелюбимое «НЕТ», а быть проактивным, позитивным и вообще: дарить, свет, добро, любовь и все такое).

Допущения и ограничения.

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

Допущения — это инструмент для того, чтобы определить то, что делать надо.

Ограничения — это инструмент для того, чтобы определить то, что делать НЕ надо.

Допущения, это когда:

• Вам сказали запустить проект, требующий внутренних процедур на 3 месяца за 2 недели, и вы не шлете заказчика нафиг с такими требованиями, а делаете допущение, что все департаменты рассмотрят его за 2 недели (если рассмотрят — так чего не сделать?).

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

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

Ограничения, это когда:

• Вам сказали сделать бизнес процесс, как вы уже делали, но без деталей, и вы пишете, что процесс будет аналогичным, за исключением интеграции со сторонними сервисами, которые может захотеть заказчик (хотели е побыстрее).

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

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

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

Далее готовите оценку и сроки (добавляете риски, ваши запасы) и передаете оценку вместе со списком допущений и ограничений вашему Заказчику.

Как только Заказчик утверждает такую оценку — объем согласован, и вы молодец.

Важно1: ваши допущения и ограничения не должны противоречить постановке от заказчика, они могут лишь детализировать ее.

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

И на выходе из этого процесса мы:

• сформировали четкий и понятный объем из непойми чего;

• помогли заказчику;

• зафиксировали договоренности письменно;

• сформировали у заказчика ожидания о том, чего он получит и чего не получит.

Отличное начало для работы, чего еще желать?! 🙂

Как использовать инструмент не нужно.

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

Не надо писать много допущений (я бы сказал, более 10–15). Если получается слишком много, стоит вернуться к заказчику и все-таки задать необходимые вопросы. Возможно, заказчик согласится выделить бюджет на проработку ТЗ.

Мораль.

Допущения и предположения позволяют вам:

• не говорить заказчику НЕТ;

• быстро реагировать на входящие требования бизнеса, сокращая time-to-market;

• действовать с позиции can do attitude вместо унылого подхода «объясните мне, почему я это должен делать» или «это невозможно!»;

• Формировать правильные ожидания от реализации с самого начала работы.

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

Фраза «это невозможно!» не приближает вас к победе, в отличие от фразы «да, это можно сделать при таких-то условиях».

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