Почему ПМ часто проигрывают аналитикам, а те в свою очередь часто пасуют перед тестерами?

Знакома ли вам такая картина описанная в названии статьи и задумывались ли вы над ответом на этот вопрос. Как ни странно один и тот же ответ может подходить для двух этих различных случаев. И там и там выигрывает тот кто правильно понимает и работает с требованиями. Но если копнуть глубже, то обнаруживается что смысл заложенный в ответ в обеих случаях очень сильно отличается.

Разбираем первый случай Для начала рассмотрим структуру требования, как такового. Ссылки что такое требование Если коротко, то у нас получается две составляющие требования. Часть которая относится к управлению. И часть которая описывает собственно содержание. Итого мы имеем управленческие атрибуты и описание сути. К управленческим атрибутам относится автор, критичность, сложность и стоимость реализации, сроки реализации и т. д..

Теперь представим что ПМ и аналитик пришли на встречу с заказчиком на каком-то из этапов заключения договора. Им предстоит торговаться по срокам и суммам. У них готов хорошо написанный аналитиком документ. Но при этом пм знаком с ним только поверхностно. И особо в структуризацию и детализацию требования не вникал. Типа – “не царское это дело”… И сталкивается с классической ситуацией: На встрече выясняется, как это бывает практически во всех случаях, что для разработки не хватает либо времени либо денег, а то одновременно и того и другого.

ПМ тут же начинает “жать на все педали” чтобы “продавить документ” и выторговать общую запланированную сумму… Не трудно догадаться, что ждёт наших разработчиков на этом пути… Но тут может вмешаться аналитик с предложением пройтись по документу и определиться, а все ли описанное в документе на самом деле так “необходимо-надобно” заказчику? Очень часто оказывается что Заказчик действительно может пойти на уступки, НО!… не по деньгам, а с реализацией одного или нескольких требований. Таким образом, аналитик становится ведущим звеном в переговорах, а ПМ, на котором вроде бы должна лежать такая обязанность, – оказывается в тени. И, если не делает соответствующих выводов, то очень скоро ПМ-ство может перейти к аналитику. Так часто и вырастают ПМ-ы из аналитиков.

В практике автора был вообще курьёзный случай, когда ПМ, нежелающий работать с требованиями, оказался не в состоянии составить план работ по проекту. Так этот ПМ легко прощал аналитику что “до сих пор нет финальной версии ТЗ”, но того что нет диаграммы Ганта по задачам проекта просить никак не мог. И аналитику приходилось выполнять работу ПМ-а.

В результате проект сдали а тендер за следующий аналогичный проект ПМ проиграл, другому ПМ из конкурирующей компании. Этим ПМ-ом оказался его бывший аналитик, к тому времени перекупленный конкурентами. Вот наглядный пример к чему приводит нежелание работать с требованиями в части менеджмента.

Теперь другая ситуация. От заказчика приходит категорическое требование: реализовать “возможность множественного выбора значений из справочников разрабатываемой системы”. ДевЛид и ПМ в шоке: Требование режет на корню простую архитектуру заложенную в основу разрабатываемой и в разы увеличивает бюджет проекта. Ситуацию спасает только переговоры с участием аналитика, в результате которых обнаруживается что множественный выбор нужен всего лишь для формирования логического условия на выборку данных в аналитике. А во всех остальных случаях в реальной работе множественный выбор оказывается даже вредным и совершенно не нужным заказчику. В итоге бюджет увеличивается “на копейки”.

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

Оба этих случая относятся к начальным фазам проекта, когда разрабатываемой системы или ещё нет вообще или она находится в зачаточном состоянии.

Но по мере развития проекта появляются рабочие варианты системы и ее начинают активно тестировать. И вот тут наш всеобщий любимец, красавец-мачо аналитик – почему-то оказывается в тени у тестера, а то и терпит конфуз от неготовности ответить на его вопросы.

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

Теперь ещё раз вернёмся к структуре требования и рассмотрим его глубже.

Требование – это некое полезное свойство системы, которое должно быть реализовано по ходу разработки.

Задумаемся, насколько точно это определение: Ведь на ранних стадиях проекта и самой системы ещё нет – как можно говорить о ее свойствах? Только в качестве каких-то умозрительных представлений или описаний.

Потому и Википедия даёт более “осторожное” определение: Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.

Очевидно, что аналитик на начальных стадиях проекта имеет дело именно с описаниями, и имеет свойства системы только в своих умозрительных представлениях.

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

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

Здесь как раз и проявляется слабость требований в привычном для аналитика смысле: Системные свойства в описаниях и умозрительных представлениях (и только). В противовес реальным свойствам “живой”, пусть и через пень-колоду, но уже реально работающей системы.

Вот и получается, что аналитик “балуется игрушками”, а тестер – занимается реальным делом с реальными вещами…

Автору вообще известен случай, когда одна очень известная и богатая компания, разработчик очень известного программного продукта, решила (в придачу к отделу тестирования) обзавестись ещё и отделом аналитики.

Кончилось всё тем, что “маститого гуру”, заведующего такими трудами созданного аналитического отдела, – с треском уволили, а сам отдел расформировали по отделам тестирования и сопровождения.

У заинтересовавшегося читателя может возникнуть законный вопрос: Ну, а если коротко, то о чем это и зачем это? Всё очень просто: как правило, когда на проекте ПМ оказывается “слабаком”, а аналитик – “проходимцем”, то их в первую очередь подозревают в недобросовестности. А на самом деле – причина в не-грамотности. Ребята, если вы узнали себя где-то в заметке – пройдите “ликбез” по управлению требованиям, но только настоящий ликбез. И станете незаменимыми для команды killer-members в современной жесточайшей конкуренции за ИТ-проекты.

Автор Юрий Чернявский, Lead Analyst в ReqnDoc