Комментарии 23
У заинтересовавшегося читателя может возникнуть законный вопрос: а кто такой ПМ? ;)
пройдите «ликбез» по управлению требованиям, но только настоящий ликбез
Куда идти?
туда, где расскажут, из чего состоит требование )))
Вот уж не ожидал, что мои примеры обострённых ситуаций приведут критиков вместе с читателями куда угодно, только не к основной идее:
Прежде, чем погружаться в "высшую математику" — вспомните школьную арифметику, иногда помогает.
Требование состоит из "двух больших частей":
- менеджерская(управленческая)
- смысловая(что именно должно быть реализовано)
И если с первой ещё более-менее понятно, то по части второй часто забывают, что:
для менеджера это, всего лишь, название для идентификации
( в смысл которого он часто даже не вникает)
для аналитика — детальное описание,
(которое каждый читатель воспринимает в меру структурированности и формализованности собственного мышления)
- а для тестера — это уже конкретное, однозначно осязаемое свойство реальной системы.
Однозначно — статью надо переделывать:
то ли примеры не удачные, то ли весь подход к изложению нужно менять.
Для начала — попробую учесть критику и поправить примеры.
А можно поподробнее решение (предполагаемое) и выход из ситуации?
ПМ станет как-аналитик? — не чересчур ли?
Аналитик будет тестить? тоже так себе.
Как решать?
Ну может аналитик будет держать проект на пульсе и допиливать требования? Или другие варианты?
ПМ станет как-аналитик? — не чересчур ли?
Аналитик будет тестить? тоже так себе.
Как решать?
Ну может аналитик будет держать проект на пульсе и допиливать требования? Или другие варианты?
Ну, вообще-то лучшие аналитики, каких я встречал на практике, тестировали прекрасно. А лучшие QA по пониманию тонкостей проекта часто тянули на аналитика. Так что это как раз естественное развитие событий.
ПМ станет как аналитик?
Может это у меня какое-то не-полное представление, только по мелким проектам, но сколько сейчас наблюдаю динамичных успешных проектов — все "экономят" на аналитиках и аналитическую работу так и взваливают на ПМ-ов.
Так что ПМ не "станет" как аналитик, а, уже массово становится.
Хотя, повторяю, это мой локальный опыт, и здесь я его просто выставил на проверку насколько он отражает реалии в большом масштабе.
про "допиливать" требований — так полностью в 10-ку.
реально допиливать приходится постоянно, на протяжении всего проета,
вот только в последнее время в каждом случае эта "участь" выпадает разным ролям.
Предлагаемые решения и выходы из ситуации — это уже темы следующих заметок, и достаточно обширных.
А пока — в статье предложено обратить внимание на ма-а-а-а-а-а-ленькую такую особенность требований, которую стоит понять и держать в памяти, чтобы было легче в "ситуации" даже не попадать.
Автору вообще известен случай, когда одна очень известная и богатая компания, разработчик очень известного программного продукта, решила (в придачу к отделу тестирования) обзавестись ещё и отделом аналитики.
Кончилось всё тем, что «маститого гуру», заведующего такими трудами созданного аналитического отдела, — с треском уволили, а сам отдел расформировали по отделам тестирования и сопровождения.
С 2009 по 2011-й год я по запросу CTO выстроил отдел системных аналитиков в Лаборатории Касперского с 10 до 35 человек, потом мою должность сократили, а отдел переподчинили руководителю пула из более чем 200 тестировщиков, где уже была успешная практика управления отпусками, а большее было и не нужно.
Так что видимо речь о моём кейсе, но я с удовольствием дополню его от первого лица.
1. «маститого гуру» — в 2009-м году я не был маститым гуру, а просто был неплохим аналитиком уровня middle, но который:
а) регулярно писал в блог свои заметки про разработку (2005-2004) и потом про анализ и проектирование (2005-2008)
б) я имел опыт управления программами нескольких ИТ-конференций, помогал с их запуском в россии — РИТ, ClientSide, HighLoad
в) я имел несколько выступлений на этих конференциях
г) у меня был опыт работы не только аналитиком, но и архитектором
д) у меня был очень хороший английский
е) я прошёл входной тест на Customer Requirements на Brainbench лучше всех кандидатов, да и вообще в России
ж) активно интересовался вопросами управления, читал литературу по нему, проходил подготовку (например, тренинг по конфликтологии на зимней психологической школе СПбГУ)
Так что маститым гуру я тогда (да и сейчас) себя не считаю, несмотря на то, что ПОСЛЕ выхода из Каспера вместе с Сергеем Нужненко создал Школу системного анализа, которая существует уже 10 лет и обучила 1000 человек и был основным автором федерального профстандарта системного аналитика.
Мой текущий блог по ИТ-анализу, где можно оценить мою маститость сейчас.
То, что я проработал в компании 2 года менеджером среднего звена, не имея вообще никакого опыта в управлении (даже тим-лидом, не то что руководителем группы) — это само по себе неплохое достижение, кмк.
2. Теперь про самое интересное — «с треском уволили, а сам отдел расформировали по отделам тестирования и сопровождения».
У меня были годовые цели — на 2009-й год — довести численность отдела с 10 до 25 человек, на 2010-й год — довести численность отдела до 35 человек.
Я благополучно воспользовался отраслевыми связями, накопленными на форуме UML2.ru и за 2 неполных года нанял достаточно крутых специалистов, многие из которых до сих пор (спустя 10 лет) работают в Каспере.
Будучи сторонником демократичного стиля управления и децентрализации управления, я очень много полномочий отдал руководителям групп, которые создал в отделе.
Изначально меня хотели нанять не просто руководителем отдела, а ещё и главным аналитиком, чтобы я работал в проектах. Но увидев цели по найму (это в среднем по +2 человека в месяца), я отказался от идеи участия в проектах, ограничился только наймом людей и выстраиванием процессов.
И получилось что в начале 2011-года моя работа по собственно комплектации отдела закончилось, у меня не было работы в департаменте и компании, а зарплата как руководителя была очень недетской.
В компании в это время в связи с временным приходом американского инвестора решили в кои-то веки пересчитать расходы, в том числе пересмотреть нормы на менеджмент (и правильно сделали).
Более того, возникла анекдотическая ситуация, что американский CFO, сидя в самолете с CTO, спросил последнего — «у вас ведь там в департаменте 30 аналитиков, они же бумажки пишут? если мы вместо них 30 разработчиков наймем — мы же быстрее разрабатывать будем»? CTO этот «запрос» передал мне. Я прошёлся по каждому из своих руководителей проектов, задал простой вопрос — «насколько сдвинется твой проект, если с него сейчас снять аналитика?». На основе ответов ПМ-ов посчитал ROI аналитиков, получил цифры от 150 до 600%, отдал CTO.
Поэтому когда CTO и HR пришли закрывать отдел, уволили ТОЛЬКО меня, все остальные ребята остались на своих местах-проектах и продолжили приносить пользу.
Я никогда за должность не держался и делать корпоративную карьеру не собирался, платить мне и получать бешеную зп менеджера было не рационально.
Так что закончилась моя проектная работа по построению системно-аналитической компетенции в компании, а не необходимость в компетенции вообще :)
В чём был треск, я не вижу. Я ушёл изучать управление продуктами и предпринимательство. Индустрия получила ШСА, Product Camp Russia, профстандарты.
Так что ваши эти «маститый гуру» и «с треском уволили» — это всё для красного словца.
NB: если что, этот поток на Хабре, в который вы пишете, тоже создавал я :)
Вау, это тот случай, когда комментарий ценнее всей статьи!
Да, взгляд с другой стороны просто шикарен…
В качестве спеца и основателя потока (и потому что автор, похоже, отсутствует) могли бы Вы дать пару рекомендаций на те ситуации, которые описал автор статьи? Что делать ПМ-у чтобы быть «на уровне»? Или явно делить зоны ответственности? Что делать (вопросу лет двести)?
В качестве спеца и основателя потока (и потому что автор, похоже, отсутствует) могли бы Вы дать пару рекомендаций на те ситуации, которые описал автор статьи? Что делать ПМ-у чтобы быть «на уровне»? Или явно делить зоны ответственности? Что делать (вопросу лет двести)?
Спасибо за оценку
по поводу рекомендаций — у автора хороший заход, но в середине текста он почему-то начинает скакать по оценкам и ситуациям, имеющим непонятную природу, так что внятно прокомментировать сложно, но я попробую:
я почти никогда не встречал, чтобы ПМы «пасовали» перед аналитиками. обычно или ПМы были сами бывшие аналитики и хорошо понимали, чего хотеть от аналитика и как выстраивать с ним отношения либо сознательно занимались не-аналитической работой, которой в проекте тоже может быть много, а с аналитиком выстраивали здоровые отношения, т.к. понимали, что они работают друг на друга
какую не-аналитическую работу я имею в виду:
— выстраивание отношений с заказчиками и контрагентами, управление их ожиданиями
— формирование и мотивация команды
— выстраивание отношений и обязательств со смежными командами
— организация работ, контроль их исполнения, формирование отчётности
— управление рисками
— управление финансами
и т.д.
поверьте, в общем случае это громадный объём работ и я как аналитик всегда был счастлив, чтобы её делал кто-то другой, не я
как аналитик я был сильно заинтересован в том, чтобы у ПМа была достаточная информация для УПРАВЛЕНИЯ требованиями, т.к. я глубоко убеждён, что если на проекте роли ПМа и аналитика разделены по людям, то первый должен заниматься УПРАВЛЕНИЕМ требованиями, а второй — их разработкой. поэтому я обычно все вопросы про приоритеты, сроки и бюджеты по требованиям отдавал ПМу, а ему для ответов на эти вопросы конечно приходилось погружаться в мои требования, а мне — ему их представлять. это не rocket sсience, просто сотрудничество. откуда тут берётся конкуренция, которую рисует автор — мне непонятно, она вредна
поэтому с ситуациями типа этой не сталкивался:
ПМ ведёт торговлю на реестре, причём с приоритетами и оценками по частям, а не общей суммой.
Реестр требований — это основа для планирования, оценки, контрактации и сдачи работ. Если ПМ этого не понимает, то это дикость конечно, но если он в целом толковый, можно ему оперативно объяснить, что это один из основных его инструментов управления.
вопрос правильный, но переговоры про ценность и приоритеты должен вести ПМ, как человек, знающий ещё и стоимость, сроки и риски по каждому требованию/блоку, а не только требования. тут явное нарушение ролей.
по поводу рекомендаций — у автора хороший заход, но в середине текста он почему-то начинает скакать по оценкам и ситуациям, имеющим непонятную природу, так что внятно прокомментировать сложно, но я попробую:
я почти никогда не встречал, чтобы ПМы «пасовали» перед аналитиками. обычно или ПМы были сами бывшие аналитики и хорошо понимали, чего хотеть от аналитика и как выстраивать с ним отношения либо сознательно занимались не-аналитической работой, которой в проекте тоже может быть много, а с аналитиком выстраивали здоровые отношения, т.к. понимали, что они работают друг на друга
какую не-аналитическую работу я имею в виду:
— выстраивание отношений с заказчиками и контрагентами, управление их ожиданиями
— формирование и мотивация команды
— выстраивание отношений и обязательств со смежными командами
— организация работ, контроль их исполнения, формирование отчётности
— управление рисками
— управление финансами
и т.д.
поверьте, в общем случае это громадный объём работ и я как аналитик всегда был счастлив, чтобы её делал кто-то другой, не я
как аналитик я был сильно заинтересован в том, чтобы у ПМа была достаточная информация для УПРАВЛЕНИЯ требованиями, т.к. я глубоко убеждён, что если на проекте роли ПМа и аналитика разделены по людям, то первый должен заниматься УПРАВЛЕНИЕМ требованиями, а второй — их разработкой. поэтому я обычно все вопросы про приоритеты, сроки и бюджеты по требованиям отдавал ПМу, а ему для ответов на эти вопросы конечно приходилось погружаться в мои требования, а мне — ему их представлять. это не rocket sсience, просто сотрудничество. откуда тут берётся конкуренция, которую рисует автор — мне непонятно, она вредна
поэтому с ситуациями типа этой не сталкивался:
«пм знаком с ним только поверхностно. И особо в структуризацию и детализацию требования не вникал. Типа — «не царское это дело»… И сталкивается с классической ситуацией: На встрече выясняется, как это бывает практически во всех случаях, что для разработки не хватает либо времени либо денег, а то одновременно и того и другого.
ПМ тут же начинает «жать на все педали» чтобы «продавить документ» и выторговать общую запланированную сумму…»
ПМ ведёт торговлю на реестре, причём с приоритетами и оценками по частям, а не общей суммой.
Реестр требований — это основа для планирования, оценки, контрактации и сдачи работ. Если ПМ этого не понимает, то это дикость конечно, но если он в целом толковый, можно ему оперативно объяснить, что это один из основных его инструментов управления.
Но тут может вмешаться аналитик с предложением пройтись по документу и определиться, а все ли описанное в документе на самом деле так «необходимо-надобно» заказчику?
вопрос правильный, но переговоры про ценность и приоритеты должен вести ПМ, как человек, знающий ещё и стоимость, сроки и риски по каждому требованию/блоку, а не только требования. тут явное нарушение ролей.
В результате проект сдали а тендер за следующий аналогичный проект ПМ проиграл, другому ПМ из конкурирующей компании. Этим ПМ-ом оказался его бывший аналитик, к тому времени перекупленный конкурентами. Вот наглядный пример к чему приводит нежелание работать с требованиями в части менеджмента.
вот этот кейс вообще непонятно про что. про неэтичное поведение аналитика? как нормальный профессионал, который заботится о своей репутации на рынке, может на такое пойти? и при чём тут работа с требованиями, если просто человек с экспертизой слился по разным причинам и использовал её не в интересах исходного нанимателя?
это кейс про управление экспертизой и мотивацией, а не про требования
От заказчика приходит категорическое требование: реализовать «возможность множественного выбора значений из справочников разрабатываемой системы». ДевЛид и ПМ в шоке: Требование режет на корню простую архитектуру заложенную в основу разрабатываемой и в разы увеличивает бюджет проекта.
Ситуацию спасает только переговоры с участием аналитика, в результате которых обнаруживается что множественный выбор нужен всего лишь для формирования логического условия на выборку данных в аналитике.
А во всех остальных случаях в реальной работе множественный выбор оказывается даже вредным и совершенно не нужным заказчику. В итоге бюджет увеличивается «на копейки».
И в этом случае одна из ключевых функций ПМ-а: торговаться с заказчиком по части реализуемых требований, — им теряется и оказывается перехваченной аналитиком.
непонятно, при чём тут торговля за реализуемость. по классике инженерии требования вот такое «требование заказчика», как «возможность множественного выбора значений из справочников разрабатываемой системы» — это нифига не требование, а попытка навязать конкретную функцию. обычная задача аналитика — разобраться в том, зачем эта идея у заказчика возникла, какую проблему на самом деле он пытается решить, перевести его в хотелку на 1-2 уровня выше — настоящих потребностей бизнеса и его задач. это обычная аналитическая задача.
Пока не разобрались, зачем — торговаться рано, незачем. Как только разобрались — ПМ помогает торговаться. Но тут конечно многое ещё зависит от того, что продаём — человекочасы разработчиков, свою платформу, что-то ещё? — от этого сильно меняется переговорная позиция
Но по мере развития проекта появляются рабочие варианты системы и ее начинают активно тестировать. И вот тут наш всеобщий любимец, красавец-мачо аналитик — почему-то оказывается в тени у тестера, а то и терпит конфуз от неготовности ответить на его вопросы.
Мало того, обнаруживается скрытая противоречивость требований, зафиксированных аналитиком и утвержденных заказчиком на ранних стадиях разработки, не говоря уже о не-полноте этих требований. И все чаще аналитик выглядит ротозеем, пропустившим противоречие требований или их не полноту.
непонятно, почему вдруг такие красочные категоричные эпитеты из крайности в крайность — то мачо, то ротозей-пустослов.
аналитик обязан аккуратно перемещаться по логическим уровням проектирования:
— уровень потребностей заинтересованных лиц
— уровень требований надсистемы
— уровень требований к системе
— уровень требований к подсистеме
на каждом уровне происходит умножение в среднем на X 5-10 требования, поэтому если он сразу сунется в детали, то там и погибнет в аналитическом параличе
я давно, ещё в том же 2010-м году рекомендовал выстраивать сотрудничество между аналитиком и тестером, привлекать тестеров для рецензирования требований ДО старта проекта: sqadays.com/ru/talk/12354
у аналитика и тестера разные направленности мышления — позитивное и негативное, поэтому они друг друга дополняют
надеяться, что аналитик в одиночку каким-то чудом одним кулём и каскадом разработает полный комплект полных непротиворечивых требований без обратной связи — это утопия
опять же этим ролям нужно выстраивать взаимодополняющий тандем, а не конкурировать, кто из них умнее
для софтверных проектов, чтобы не возиться с 3-4 уровнями требованиями, придумали специальные инструменты-техники, как оставаться на уровне смысла и сути — user stories + use cases
Первенство по экспертизе относительно возможностей системы неуклонно переходит к тестеру, а аналитик, со своими аналитическими документами, — все больше становиться похожим на бесполезного пустослова.
непонятно, о какой экспертизе о возможностях системы идёт речь, если, например:
а) о разработке требований для выбора готового решения, например, CRM. пока решение не выбрано, как может тестировщик знать его лучше? да даже если и выбрано, откуда уверенность, что он знает все возможные решения?
б) о разработке требований к новой системе. никакой системы ещё нет. в чём может быть экспертом тестировщик? в типовых багах требований? да. в типовых необработанных ситуациях — да. но не в системе же, которой ещё нет.
если мы говорим о проектах внедрения и/или доработки платформы под клиента, с которой команда работает давно, то да, экспертиза тестировщика по деталям может больше, но и она же может мешать ему обсуждать с заказчиком и пользователями их задачи и цели, а не фичи и функции, в общем случаем не дающие увидеть за деревьями леса.
кроме того, я настойчиво рекомендую в таких проектах аналитику участвовать не только в первичном обследовании и контрактации, но и во внедрении, тогда у него точно будет сопоставимое количество экспертизы — но опять же, не столько в тонкостях поведения функций, а в особенностях их применения для конкретных задач пользователей и клиентов
в некоторых компаниях, занимающихся внедрением, функции аналитика и тестировщика объединяют в одном человеке и это работает хорошо
Искренне удивлён, почему Денис воспринял описанную мною ситуацию в свой адрес.
Как он мог узнать себя, если его описание полностью не соответствует ситуации в статье?
Специально для того, чтобы снять с себя обвинения Дениса, уточняю:
это — НЕ про Дениса, уже хотя-бы потому, что описанный случай произошел НЕ в то время, которое указывает Денис, и НЕ в Москве.
Да и не про меня, уже хотя-бы потому, что я — НЕ "маститый гуру" )))))))))
Убедительная просьба к читателям: если ещё кто-то вдруг "узнал себя" в этом примере — прежде чем публично обвинять в клевете, — напишите в личку )))
Задумаемся, насколько точно это определение: Ведь на ранних стадиях проекта и самой системы ещё нет — как можно говорить о ее свойствах? Только в качестве каких-то умозрительных представлений или описаний.
…
Соответственно, у всех остальных участников проекта тоже будут формироваться свои собственные (тоже умозрительные) представления, на основе одного и того же описания, сформированного аналитиком (причем, у каждого — своё, далеко не всегда и далеко не полностью согласованное с представлениями остальных участников).
…
Здесь как раз и проявляется слабость требований в привычном для аналитика смысле: Системные свойства в описаниях и умозрительных представлениях (и только). В противовес реальным свойствам "живой", пусть и через пень-колоду, но уже реально работающей системы.
Вот и получается, что аналитик "балуется игрушками", а тестер — занимается реальным делом с реальными вещами…
Мне кажется автор впадает в заблуждение или непонимание, считая требования аналитика к системе умозрительными, а работающую систему "живой" и более "реальной". Типа реально это то, что можно пощупать, а то что в головах, это все "придумки" и "умозрительные представления". Простите но "умозрительные представления" это требования заказчика оформленные в виде требований к системе, которая должна быть создана. Любая реальная работа начинается именно с таких "умозрительных представлений". Чтобы сделать шкаф, вы, или кто-то, придумывает его сначала в голове.
Другая проблема, чтобы эти требования были ясно изложены, и чтобы не возникало непонимания или искаженного толкования, это уже другая проблема аналитика. Возможно требующая отдельного обсуждения с участниками проекта.
Насчет проблем тестеров и тестирования. Требования к системе это уже по сути основа для написания тестов для еще не созданной системы! И правильнее как раз, еще до начала разработки, подключить тестера для написания тестов которые и будут проверять то, что система соответсвует вышеперечисленным требованиям. Это можно делать и параллельно с разработкой, но в этом случае возможна ситуация, когда тестер найдет какие-то несоответствия или противоречия, которые не заметил аналитик, и требования придется менять, включая разработку. Есть практика написания тестов до разработки, TDD, возможно тут как раз ей самое место.
Вообще ощущение, что автор работает в организации или проекте где нету такого понятия как командная работа, а есть атмосфера, где каждый конкурирует с каждым за звание быть самым умным и успешным. Это очень нездоровая атмосфера, которая в пределе может привести к краху организации или проекта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему ПМ часто проигрывают аналитикам, а те в свою очередь часто пасуют перед тестерами?