Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - Михаил Курбасов

Страницы: 1
1
Коллеги, не подскажете, где можно почитать более-менее связно про специфику управления требованиями для портфеля проектов, основанных на общей технологической платформе?

Поясню. Компания разрабатывает некий фреймворк (платформу, прототип, программный шаблон), который используется в нескольких прикладных проектах. Фреймворк удобен тем, что содержит в готовом виде некоторые "часто запрашиваемые фичи" из определенной предметной области. Поэтому реализация прикладного проекта выглядит так: берем фреймворк, докручиваем/модифицируем его под конкретного функционального заказчика, и вуаля.

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

Можно выделить очень много вопросов, которые хотелось бы решать, приведу только примеры. 1. В прикладном проекте заявлено требование заказчика - сделать Х. Кто будет реализовывать это требование - команда фреймворка (с тем, чтобы Х вошло в функции платформы) или команда прикладного проекта? 2. Со стороны прикладного проекта П1 заявлено пожелание модифицировать фичу платформы Y. На какие характеристики прикладных систем в проектах П2, П3 и т.д. это может повлиять? 3. Во фреймворке есть фича Z, а в прикладном проекте мы ее докручиваем до Z*. Правильно иметь в прикладном проекте формулировку требований Z* или Z*-Z? Ну и т.п.
 
Изобретать велосипеды мы сами мастаки, но все равно буду признателен и за частные отзывы. Но вопрос вообще про то, не знает ли кто, где можно ознакомиться с мнением великих по данной теме.

2
Тема навеяна сообщением Виталия Григораша о выпуске им журнала для аналитиков с подборкой на тему "Изменения требований".

Во вступлении автор пишет что-то вроде того, что "пишем много чейндж-реквестов, и не всем понятно, зачем". Ну, это, очевидно, юмор, а я хотел спросить серьезно.

У тех из вас, у кого поставлен процесс управления изменениями - вам всегда ли понятно, для чего пишутся чейндж-реквесты, ведется анализ влияния? Сталкиваетесь ли вы с ситуациями, когда вы в ходе проекта зафиксировали некий чейндж-реквест, провели анализ влияния, вывели, что "чтобы это реализовать, надо всю систему переписать заново, и стоить это будет мильон баксов" - а заказчик вам на это выражает что-то типа "а мне пофиг, я без этой хотелки акты все равно не подпишу". Ну, я утрирую, конечно, но проблема в том - всегда ли имеет смысл осложнять себе жизнь дополнительными оформлениями-расчетами, если делать это изменение вы все равно будете (по политическим причинам, например)?

Как обстоит с этим дело у вас в проектах?

3
Хотелось бы послушать мнение уважаемого сообщества, как можно понять, что аналитик профессионально вырос? Что сейчас он "аналитит" гораздо лучше, чем, например, год назад? По каким критериям, м.б. метрикам, это можно было бы понять, на ваш взгляд?

Другая сторона вопроса - если такие критерии можно сформулировать, можно ли их установить в качестве ориентира для роста аналитиков?

4
Коллеги, вопрос к сообществу состоит в следующем:
Какими методами проверки качества требований вы пользуетесь на практике?

Теоретические вопросы качества требований вполне хорошо изложены в литературе, в т.ч. краткая выжимка по теме качества есть и на данном сайте: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=341.0

Однако теория - теорией, а что в жизни? Вот приходит некий аналитик и говорит: "Я провел обследование заказчика и написал ТЗ". Как вы на практике решаете вопрос, как понять, это хорошее ТЗ или не очень?

Предвижу такой вариант ответов - дать кому-нибудь прочитать и согласовать (заказчику, техническому менеджеру, ведущему разработчику, привлеченному эксперту). Для тех, кто так делает, сразу два дополнительных вопроса:
а) как вы учитываете/боретесь с возможным субъективизмом согласующего?
б) как вы учитываете/боретесь с возможной незаинтересованностью согласующего (как бы он ни читал, ответственность-то все равно на аналитике)?

Или, может, еще что-то используете?

5
Собеседуя массу кандидатов на позицию аналитика, обратил внимание, что мало кто из кандидатов изучал какую-либо литературу по специальности (бизнес-анализ, системный анализ). Ориентировочная оценка - не более 10-20% приходящих. Собственно, вопрос: почему так?

Собирается, допустим, программист устроиться на новую работу: узнает из вакансии, что на новой работе нужно знание, предположим, C#. Даже если человек в данный момент не знает C#, большинство делают вполне очевидную вещь: идут в магазин, покупают книжку по данной технологии и начинают ее изучать, ну, хотя бы чтобы термины понимать. Почему у аналитиков все по-другому, и вопрос о профессиональной литературе вызывает глухое недоумение (типа "а вы на Луну летали?" - "нет, а зачем...")

P.S. Обратил внимание, на самом деле, не я, а наш рекрутер, который взял у меня книжку Леффингуэлла и пошел читать, "чтобы разговаривать с кандидатами на одном языке". Учитывая вышеописанное, ну-ну...

Страницы: 1