RM(Gevorg) to \
\JRM(Galogen):
По-секрету от Заказчика и коллег по разработке честно признаЮсь Вам,
что я уже НЕ в состоянии это всё держать под контролем.
Что там РаКвест? Вы можете в ём как-то форумное обсуждение разместить и оттрассировать пОсты и требования?
Gevorg(в роли ПМ проекта по сбору метод-материала для студенотов) to
Galogen(в роли учредителя проекта):
вот ещё пример студентам:
ошибка в менеджменте требований:
RM(Gevorg) НЕ замечает общую КОНЦЕПТУАЛЬНУЮ проблему,
пытается подменить её частной задачей трассировки и решить её с помощью РаКвест.
А проблема в том, что RM(Gevorg) до сих пор ещё не вооружён КОНЦЕПТУАЛЬНОЙ_МОДЕЛЬЮ и регламентом процесса по управлению требованиями.
Он не просто не в состоянии "разложить по полочкам" очень быстро накопившийся материал,
у него нет САМИХ полочек, у него даже нет ещё отчётливого понимания, какими они должны быть.
Отсюда и робкий вопрос подчинённому вместо уверенного отдавания распоряжения,
отсюда и судорожные попытки "закрыть дыру" своими средствами.
Правильные действия в этом случае - идти "наверх",
не к подчинённому, а руководству:
/ProcessRequirementBoss(Galogen):
RM(Gevorg) to /
Проект разработки ПО уже давно стартонул,
работы по сбору и анализу требований уже ведутся полным ходом,
самИх требований ещё совсем мало,
а по ним уже накопилась куча материала,
ещё немного - и работа над сбором и анализом требований превратится в хаотический и безрезультатный процесс.
В работе над требованиями полный произвол и неопределённость:
- кто за что отвечает,
- кто что и как делает,
- что и в каком виде подаётся в качестве исходного материала, что является результатом и как его оформлять на каждом из шагов?
Срочно нужно всё упорядочивать:
- рисовать диаграммы моделей процесса управления требованиями в нашем случае,
- писать по ним инструкции и регламент и
- ставить этот процесс на рельсы.
Иначе - утонем в, на самом деле, умных дебатах о "физической сути" каждого из требований.
Управление требованиями