Знакома ли вам картина, описанная в названии статьи, и задумывались ли вы над ответом на этот вопрос? Как ни странно, для этих двух разных случаев может подойти один и тот же ответ. В обоих случаях побеждает тот, кто правильно понимает требования и работает с ними.
Но если копнуть глубже, то обнаружишь, что смысл, заложенный в ответе, в обоих случаях очень разный.
Давайте рассмотрим первый случай.
Для начала давайте посмотрим на структуру требования как таковую.
Ссылки Что такое требование Короче говоря, у нас есть два компонента требования.
Та часть, которая связана с управлением.
И та часть, которая описывает фактическое содержание.
Итого имеем атрибуты управления и описание сути.
Атрибуты управления включают автора, критичность, сложность и стоимость реализации, время реализации и т. д. Теперь представим, что ПМ и аналитик пришли на встречу с заказчиком на каком-то этапе заключения договора.
Им придется договариваться об условиях и суммах.
У них есть документ, хорошо написанный аналитиком.
Но в то же время я знаю его лишь поверхностно.
И я особо не вникал в структурирование и детализацию требований.
Мол, «это не королевское дело»… И он сталкивается с классической ситуацией: На встрече выясняется, как бывает почти во всех случаях, что на разработку не хватает ни времени, ни денег, а то и того и другого.
в то же время.
Премьер-министр тут же начинает «давить на все педали», чтобы «протолкнуть документ» и оговорить общую запланированную сумму.
Нетрудно догадаться, что ждет наших разработчиков на этом пути.
Но тут может вмешаться аналитик с предложение просмотреть документ и решить, все ли описанное есть в документе, неужели это так «нужно и нужно» заказчику? Очень часто оказывается, что Заказчик действительно может пойти на уступки, НО!.
не ради денег, а с выполнением одного или нескольких требований.
Таким образом, ведущим звеном переговоров становится аналитик, а премьер-министр, на котором якобы должна быть такая ответственность, оказывается в тени.
И, если не сделает соответствующих выводов, то очень скоро премьер-министр может перейти к аналитику.
Именно так часто из аналитиков вырастают ПМ.
В практике автора был вообще курьезный случай, когда ПМ, не желая работать с требованиями, не смог составить план работы проекта.
Так что этот премьер-министр легко простил аналитику, что «финального варианта технического задания до сих пор нет», но не мог спросить о том, что для задач проекта нет диаграммы Ганта.
И аналитик должен был выполнять работу премьер-министра.
В результате проект был передан, и премьер-министр проиграл тендер на следующий аналогичный проект другому проекту из конкурирующей компании.
Этим премьером оказался его бывший аналитик, которого к тому времени перекупили конкуренты.
Вот наглядный пример того, к чему приводит нежелание работать с требованиями руководства.
Сейчас ситуация другая.
От заказчика исходит категорическое требование: реализовать «возможность множественного выбора значений из справочников разрабатываемой системы».
DevLead и PM в шоке: требование подрывает простую архитектуру, лежащую в основе разрабатываемой, и значительно увеличивает бюджет проекта.
Ситуацию спасают только переговоры с участием аналитика, в результате которых обнаруживается, что множественный выбор нужен только для формирования логического условия выборки данных в аналитике.
А во всех остальных случаях в реальной работе множественный выбор оказывается даже вредным и совершенно ненужным для заказчика.
В результате бюджет увеличивается на копейки.
И в этом случае одна из ключевых функций ПМ: торг с заказчиком относительно реализуемых требований, теряется им и в итоге перехватывается аналитиком.
Два-три таких случая и премьер-министр может распрощаться со своей должностью.
Оба эти случая относятся к начальным этапам проекта, когда разрабатываемая система либо еще не существует вообще, либо находится в зачаточном состоянии.
Но по мере развития проекта появляются рабочие версии системы и ее начинают активно тестировать.
И тут наш всеобщий любимец красавец-мачо-аналитик почему-то оказывается в тени тестировщика, а то и конфузится от своей неготовности отвечать на его вопросы.
Более того, выявляется скрытое противоречие в требованиях, зафиксированных аналитиком и одобренных заказчиком на ранних этапах разработки, не говоря уже о неполноте этих требований.
И все чаще аналитик выглядит как болтун, упускающий противоречие требований или их неполноту.
Примат экспертизы относительно возможностей системы неуклонно смещается к тестировщику, а аналитик со своими аналитическими документами все больше становится похож на бесполезного пустослова.
Теперь еще раз вернемся к структуре требования и посмотрим на нее глубже.
Требование — это полезное свойство системы, которое необходимо реализовать во время разработки.
Давайте задумаемся, насколько точно это определение: Ведь на ранних стадиях проекта самой системы еще не существует – как можно говорить о ее свойствах? Лишь как какие-то умозрительные идеи или описания.
Вот почему Википедия дает более «осторожное» определение: Требования к программному обеспечению — это набор утверждений относительно атрибутов, свойств или качеств программной системы, которую необходимо реализовать.
Очевидно, что аналитик на начальных этапах проекта занимается именно описаниями, а свойства системы имеет лишь в своих умозрительных представлениях.
Соответственно, все остальные участники проекта также будут разрабатывать собственный (тоже умозрительные) идеи, основанные на одном и том же описании, сформированном аналитиком (причем у каждого свои, не всегда и не полностью соответствующие представлениям других участников).
Это рассуждение может показаться казуистикой.
Но только до тех пор, пока мы не перейдем к этапам проекта, где система уже готова или почти готова, когда вместе с самой системой появляются и настоящий его свойства, с которыми, собственно, и работает тестер.
Именно здесь проявляется слабость требований в привычном для аналитика смысле: свойства системы в описаниях и умозрительных представлениях (и не более того).
В противовес настоящий свойства "живые", пусть и через пень-колоду, но уже действительно работающая система.
Вот и получается, что аналитик «играется игрушками», а тестировщик делает настоящее дело с реальными вещами… Автору вообще известен случай, когда одна очень известная и богатая компания, разработчик очень известного программного продукта, решила (помимо отдела тестирования) обзавестись отделом аналитики.
Закончилось все тем, что «почтенный гуру», руководитель аналитического отдела, созданного для таких работ, был с треском уволен, а сам отдел расформирован на отделы тестирования и поддержки.
У заинтересованного читателя может возникнуть закономерный вопрос: Ну, короче, о чем это и За что Этот? Все очень просто: как правило, когда ПМ оказывается «слабым» на проекте, а аналитик — «жуликом», то их в первую очередь подозревают в нечестности.
Но на самом деле причина в безграмотности.
Ребята, если узнали себя где-то в заметке, пройдите образовательный курс по управлению требованиями, но только настоящий образовательная программа.
И вы станете незаменимым членом команды-киллеров в сегодняшней жесткой конкуренции за IT-проекты.
Автор Юрий Чернявский, ведущий аналитик ReqnDoc Теги: #hr #Анализ и системное проектирование #аналитика #pm
-
Понимание Работы Разработчика Android
19 Oct, 24 -
Серия Dell Studio 1558-B74P43
19 Oct, 24 -
Фламанский
19 Oct, 24 -
Открытая Научная Фантастика
19 Oct, 24 -
3D-Печатное Огнестрельное Оружие? Почти…
19 Oct, 24 -
«Багхантер Профессионал»
19 Oct, 24 -
Версия 1.0.9
19 Oct, 24
