Post #497

Я знаю, что дошучивать не хорошо, но вчера в пост всё не уместилось — ещё в книге Вигерса есть части, которые будут полезны для лидов или тех, кто хочет им стать. Например, страницы с 20 по 25 помогут вам аргументировать вашу полезность, если у начальства есть сомнения. Зачем вообще нужны эти аналитики?! Вот там перечислены пугалки и вероятные выгоды (см. главу про риски). В основном все пугалки сводятся к разрастанию скоупа и дороговизне исправления ошибок в коде, а не в спецификации. Проверьте, что в вашем случае это действительно так. Стр. 36-40 — обязанности заказчика. Очень интересный раздел. Можете эти пункты вставлять в договоры. Всё равно никто им не следует. Можно зачитывать вслух, чтобы вместе посмеяться с командой за пивом. Или поплакать. Я их даже приведу тут, порыдаем вместе: Обязанность №1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса.Ну допустим. Обязанность №2. Потратить столько времени, сколько необходимо на предоставление и уточнение требований.Уже рыдаю. Обязанность №3. Точно и конкретно описать требования к системе.Началась бульварная фантастика. Обязанность №4. По запросу принимать своевременные решения относительно требований.Фантастика продолжается. Обязанность №5. Уважать определенную разработчиком оценку стоимости и возможности реализации ваших требований.Я уважаю вашу оценку, но нам нужно это вчера и за 1/10 стоимости. Обязанность №6. Определять реалистичные приоритеты требований совместно с разработчиками. Говорю же — нужно вчера. Обязанность №7. Проверять требования и оценивать прототипы. Покажитефинальный дизайн. Обязанность №8. Определить критерии приемки.Вот увижу, тогда скажу — то или не то. Обязанность №9. Своевременно сообщать об изменениях требований. 😭 Обязанность №10. Уважительно относиться к процессам создания требований. См. п. 5. До этого на стр. 33-36 есть "Билль о правах заказчика" — там самое интересное Право №5. Заказчик имеет право изменить свои требования.Вот в это охотно верю. Дальше опять про культуру уважения к требованиям и про утверждение требований (стр. 40-47). Вот тут есть фраза, которую нужно отлить в граните: Оба описанных подхода игнорируют реальность, которая такова, что на ранних этапах работы над проектом нельзя знать абсолютно всех требований и со временем они неизбежно меняются. "Оба описанных" — это позиция заказчика «Ну да, я подписал эти требования, но у меня не было времени их читать. Я доверял вам, ребята, а вы меня подвели!» и аргумент менеджера «Но вы же подписали эти требования, и именно такую систему мы и создаем. Если вам нужно было что-то другое, следовало сказать об этом раньше». Слышите! Сам Вигерс нам сказал, что нельзя знать всех требований заранее! Про это же в главе 17, которая в русском переводе "Утверждение", а на английском — Validation (читайте оригинал!). Как я уже писал, там про рецензирование и проверки. Лидам актуально. Там, к слову, описана та самая "читка" — Вигер называет её "inspection" (а переводчик — "экспертизой"). И ещё есть чеклист на стр. 400, приведу его отдельно. Ну и для лидов уже наоборот — обязательна к прочтению Часть V, где про улучшение процессов и про риски. Впрочем, улучшение процессов у Вигерса дано обзорно, какой-то специфики именно в анализе тут нет, обычный проект изменений. Тут уже и сам Вигерс шутит: * не откусывайте кусок, который не сможете прожевать * получайте максимум удовольствия от малых побед (больших побед у вас будет немного) * давите мягко, но постоянно * концентрируйтесь (команда разработчиков может выполнять только одно улучшение за раз). * ищите союзников (растите их; благодарите их; награждайте их) А главный тезис, про который нужно всегда помнить: при совершенствовании процессов производительность сначала ухудшается, и только потом улучшается выше предыдущего значения (кто сказал, что она улучшится?) Ну и про риски — они у Вигерса перечислены, но в принципе все укладываются в две категории: * сделали не то, что нужно * не сделали то, что нужно Вот такое дополнение. Поздравляю, теперь вы готовы к роли лида аналитиков!