У меня вызывает опаску как раз "управление требованиями" без корректного видения. У студента может сложиться впечатление, что "управлять требованиями" можно и без чёткого понимания того, что именно разрабатывается.
Кстати, такой подход тоже можно использовать в качестве учебной задачи - дать студентам самостоятельно "додумать" концепцию, а потом предъявить им свою, заранее подготовленную. И проанализировать ошибки и их причины - такие "разборы полётов", по моему опыту, в обучении очень эффективны. Собственные ошибки запоминаются надолго, намного дольше, чем правильно выполненные задания.
не успеваю охватить и собрать все накопившееся за время моего отсутствия,
и управлять развитием "детективных сюжетов",
уже боюсь дальше напрягать своими задержками общественность,
поэтому выкладываю задумки по частям, и как есть, в черновом варианте.
по нашему стендовому проекту
"Разработка заказного ПО для торговца пластиковыми карточками".
Краткое описание деятельности Заказчика:
Крупнооптовая закупка скрэтч-карт от крупного провайдера услуг в Столице
и мелкооптовая ПЕРЕпродажа мелким реализаторам карточек из провинциальных городов.
Финансовые потоки между Провайдером и Фирмой просты и прозрачны, уже автоматизированы в бухгалтерском ПО.
Между Фирмой и реализаторами существуют 2 вида денежных потоков:
- БНР, тоже автоматизированный в бухгалтерском ПО и
- рассчёт наличными, особо больное место в бизнесе, ведётся на грани нарушения законодательства,
крайне нуждается в реинжиринге, правильном учёте и автоматизации.
--!! Управленческий учёт отсутствует, сведение отчёта по какому-либо из Реализаторов
- всегда проблема, решение которой не обходится без скандала.
Роли у Заказчика:
- ТОП. Хозяин бизнеса, Раздражителен, скандален, даже временами хамлив.
Скрывает особенности своих бизнес-процессов, поскольку имеет с ними ряд серъёзных проблем.
Реально - под видом разработки и внедрения заказного ПО хочет провести реинжиринг своего бизнеса.
Финансовый директор. имеет только громкое название.
На самом деле, главная его обязанность -
ездить по провинциальным городам и "трусить должников".
Бухгалтер.
Добросовестно сводит балланс по безналичным рассчётам и отбивается всеми способами
от попыток нагрузить её учётом движения наличных средств и карточек.
Разрабатываемую систему рассматривает как инструмент агрессии в свою сторону.
Менеджеры. По совместительству - кладовщики-учётчики карт и налички.
Ведут реальный учёт вручную, издёрганы скандалами при сведении отчётов по должникам.
Ждут-не-дождутся наведения порядка и автоматизации в своей работе.
Финансовый и бизнес-аналитик. Появляется намного позже.
Занимается построением полноценного управленческого учёта
на основе уже реализованной в нашем ПО функциональности и своих дополнительных хотелок.
Одна из них - возможность принимать от Провайдера и учитывать номера использованных скретч-карт.
Счастливая находка для эффективного обнаружения фактов задержки Реализаторами средств от уже проданных карт.
Роли у Разработчика:
- Менеджер требований(RM). В полном смысле должнен быть "держателем" самих требований и работы с ними.
Пребывает в полной уверенности, что 80% работы с требованиями не несут в себе проблем касательно их сути,
Требования либо уже понятны, либо работа с ними требует только поверхностного понимания сути
при большой важности глубокого понимания контекста в проекте.
из оставшихся 20% надеется часть спихнуть на энергичного и начитанного (а главное - низкооплачиваемого) помощника,
а что останется из уж совсем трудного - пригласит (на сэкономленные средства) стороннего эксперта-аналитика.
Ленивый прагматик до мозка костей.
- Младший менеджер требований(jRM).
Имеет большой теоретический багаж, опыт работы c CASE-средствами, энергичен и работоспособен.
При недостатке опыта в работе с требованиями и отсутствии "груза ответственности за конечный результат",
активно и добросовестно берётся за любую посильную черновую работу.
- Сеньёр эксперт по требованиям(SRX).
Прекрасно знает предметную область вообще, на высоком уровне понимает и формулирует требования по-сути.
Требует от остальных такого же высокого уровня понимания, если не находит - тут же берётся дотягивать.
Находится вне организационного контекста нашего (стендового) проекта, многие трудности и провалы не то что не хочет
воспринимать, но даже и не догадывается об их существовании.
Имеет опыт по своим прошлым и текущим проектам, которым охотно делится (за соответствующую немалую плату).
За конечный результат проекта (стендового) не отвечает вообще, отвечает за высокий профессионализм и точность своих
консультаций по выделенным вопросам.
Это пока только моё представление по стендовому проекту.
Дальше обещаюсь изложить своё понимание ролей в проекте, учредителем которого является Galogen, как инициатор темы.
Здесь мне уже не получится быть в роли ленивого и полуграмотного по части понимания "физической сути" требований :-)
Просмотр сообщений
