Допущения и ограничения в жизни менеджера
Качественно сделанные допущения и ограничения спасут вас также, как этот забор
Менеджер должен тащить. Давать срок и попадать в него, как обещал. Если менеджер не тащит — это плохой менеджер. Это очевидно. А что, если менеджер тащит, но не туда? Или по ТЗ тащит туда, но заказчик недоволен? А если менеджер выгорает от того, что к нему каждый день прибегает заказчик с нереальными и плохо описанными задачами, а потом убегает и жалуется руководству, что менеджер отказывается оценивать работы в таком виде?
Эта статья будет про то, как можно помочь вашим заказчикам лучше формулировать требования, а не посылать их нафиг при виде некачественных постановок и быть (а не выглядеть) тем, кто тащит куда нужно и помогает, а не делает вид.
Только пара самых простых инструментов. Если вы их уже используете — замечательно. Если нет — попробуйте использовать и ваши шрамы затянутся заказчики скоро начнут вас любить, считать надежным исполнителем и отдавать всю новую работу только вам (нравится это вам или нет, решайте сами))).
Это очередная статья из цикла статей и постов в моем ТГ канале о жизни менеджеров и необходимых им софтскиллах. Это то, чего обычно руководителям не рассказывают на курсах, но что вам понадобится с самого первого дня его работы. Если тема для вас интересная, подписывайтесь на мой ТГ »Морковка спереди, морковка сзади» и читайте другие мои статьи тут, на Харбе)
И да — эта статья для любых исполнителей, к которым приходят с мутными задачами их заказчики. По моему опыту, использование этих инструментов здорово упрощает жизнь исполнителя и значительно улучшает отношения с заказчиками.
Управление ожиданиями начинается с постановки задачи от заказчика. А заказчик, как правило, сам особо не понимает, что ему нужно. Он видит цель где-то впереди, но очень смутно: глаза умные, а объяснить толком ничего не может.
Здесь у вас, как у исполнителя, есть несколько вариантов, что делать:
Работать по формальному процессу. Вы можете отказаться от оценки, ссылаясь на то, что по таким требованиям сделать ничего нельзя:»Сделайте нормальную постановку, ФТ, ТЗ и тд и тогда приходите». Это справедливо, если вам не платят за рвение, если расти вам в компании неинтересно, и вы работаете строго по процессу, принятому у вас в компании. Это самый базовый путь.
Недостаток этого подхода в том, что заказчик понимает: вы совершенно не желаете ему помогать, а отбиваетесь по формальному признаку.В противоположность первому варианту, можно, наоборот, принимать любую работу от заказчика в любой постановке в стиле »эх, прорвемся! » и делать все, лишь бы быть на хорошем счету. Такой подход вначале нравится всем заказчикам, но он же потом вас и хоронит: сделать все обещанное как правило, невозможно, а в финале заказчики получат не то, чего они хотели (так всегда бывает при работе по непойми каким требованиям), и вы же окажетесь виноваты.
Третий путь — промежуточный. Не браться за работу, но и не отказываться, задавая вопросы »а как это должно быть сделано? » Это компромиссный вариант, но и при таком подходе вы занимаете пассивную роль, предлагая заказчику самому решить его проблему. А он часто решить ее не в силах, потому что он и сам фиг знает, что именно надо сделать.
Вот тут и приходит на помощь магия допущений и ограничений. Этот та самая волшебная палочка, которая позволяет превращать ХЗ в ТЗ, при этом:
Формируя у заказчика понимание того, что вы реально ему хотите помочь , а не формально отбрить.
Формируя ожидания того, что что заказчик получит и не получит на выходе.
Прикрывает вас от возможных претензий в будущем от того же заказчика, который не сможет сказать, что он имел ввиду совсем другое.
И позволяет вам не говорить то самое всеми нелюбимое «НЕТ», а быть проактивным, позитивным и вообще: дарить, свет, добро, любовь и все такое).
Допущения и ограничения.
Допущения и ограничения — этоотличный инструмент «достраивания» полученных вами требований под себя. Это доски и гвозди в руках РП, с помощью которых он может построить хороший забор, ограждая понятный и оцениваемый фронт работ от неизвестной и рискованной области, в которую лучше не лезть.
Допущения — это инструмент для того, чтобы определить то, что делать надо.
Ограничения — это инструмент для того, чтобы определить то, что делать НЕ надо.
Допущения, это когда:
Вам сказали запустить проект, требующий внутренних процедур на 3 месяца за 2 недели, и вы не шлете заказчика нафиг с такими требованиями, а делаете допущение, что все департаменты рассмотрят его за 2 недели (если рассмотрят — так чего не сделать?).
Вам сказали реализовать проект, но команду выделить забыли, и вы делаете допущение, что ресурсные менеджеры к нужной вам дате выделят необходимых специалистов с нужной квалификацией. Ну или что будет выделен бюджет ХХХ и срок на поиск внешнего подрядчика, который все сделает «под ключ».
Вам поставили задачу в формате «сделай также, как тогда, но с рюшками и отчетностью, а вы пишете в допущениях требования к процессу, требования к рюшам и к составу отчетности.
Ограничения, это когда:
Вам сказали сделать бизнес процесс, как вы уже делали, но без деталей, и вы пишете, что процесс будет аналогичным, за исключением интеграции со сторонними сервисами, которые может захотеть заказчик (хотели е побыстрее).
От вас хотят эквайринг с приемом платежей на сайте, и вы занудно указываете, что эквайринг будет с одним банком (имя), не включая обмены для сберпей, яндекс пей и так далее (потому что это отдельные работы).
Все, что вы делать не хотите, что видите в рисках, но в допущениях не написали или там этого недостаточно, можно усилить в ограничениях.
Далее вы с указанными допущениями и ограничениями идете к тех лидам, ответственным за оценку разработки и просите оценить. Если им чего-то неясно — генерируете дополнительные допущения или поясняете объем на основании уже сделанных допущений.
Далее готовите оценку и сроки (добавляете риски, ваши запасы) и передаете оценку вместе со списком допущений и ограничений вашему Заказчику.
Как только Заказчик утверждает такую оценку — объем согласован, и вы молодец.
Важно1: ваши допущения и ограничения не должны противоречить постановке от заказчика, они могут лишь детализировать ее.
Важно2: все ограничения и допущения надо делать не словами, а письменно. Заказчик позже должен будет подтвердить, что его такой подход устраивает.
И на выходе из этого процесса мы:
сформировали четкий и понятный объем из непойми чего;
помогли заказчику;
зафиксировали договоренности письменно;
сформировали у заказчика ожидания о том, чего он получит и чего не получит.
Отличное начало для работы, чего еще желать?! :)
Как использовать инструмент не нужно.
Не надо писать допущения и ограничения на всякую ерунду, врубая вашу паранойю. Допущения должны писаться только на существенные риски и проблемы. Как их определить, например, можно почитать в статье «Риски в жизни РП». Каждое допущение и ограничение должно быть обосновано тем, что без него стоимость и срок работ вырастают кратно, и именно поэтому вы его и пишете (иначе проще было бы накинуть его в стоимость).
Не надо писать много допущений (я бы сказал, более 10–15). Если получается слишком много, стоит вернуться к заказчику и все-таки задать необходимые вопросы. Возможно, заказчик согласится выделить бюджет на проработку ТЗ.
Мораль.
Допущения и предположения позволяют вам:
не говорить заказчику НЕТ;
быстро реагировать на входящие требования бизнеса, сокращая time-to-market;
действовать с позиции can do attitude вместо унылого подхода »объясните мне, почему я это должен делать» или «это невозможно! »;
Формировать правильные ожидания от реализации с самого начала работы.
Я считаю, что любому айтишнику стоит помнить: информационные технологии не ценны сами по себе, IT сокращает косты основного бизнеса и главная задача IT все же — это помогать бизнесу работать эффективнее, а не учить его жить.
Фраза »это невозможно! » не приближает вас к победе, в отличие от фразы »да, это можно сделать при таких-то условиях».
Поэтому мой совет и мой подход всегда это:»би позитив, донт би негатив», ну или на русском: «будьте гативными, а негативными не будьте!» и используйте допущения и ограничения, чтобы помогать вашему бизнесу.
