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