Работа с заинтересованными лицами
Содержание
Цель
На этой странице предполагается провести классификацию лиц, заинтересованных в разработке ПО, а привести рекомендации по их выявлению и работе с ними. Создать
- checklist, на основании которого можно было бы получить список лиц реального проекта не придумыванием и выявлением, а удалением пунктов
- опорный план, на основании которого можно было бы организовать процесс взаимодействия с заинтересованными лицами.
Введение
Цель программного проекта, как и любого другого - удовлетворение заинтересованных лиц. Между тем, работе с ними обычно уделяется недостаточное внимание. Люди концентрируются на различных артефактах, и не всегда упоминают, что любые артефакты - лишь средство удовлетворения заинтересованных лиц. Это справедливо даже в том случае, когда что-то создаётся "just for fun": автор артефакта - такое же заинтересованное лицо, как и все остальные.
Впрочем, большая часть проектов - по крайней мере, в области программного обеспечения - имеют целью создание артефактов.
Учитывая, что видов ПО и пользователей ПО не так много, представляется вполне возможным создать классификатор заинтересованных лиц для каждого вида ПО.
Учитывая, что работающих практик разработки ПО также ограниченное количество, представляется возможным составить опорный план работы с заинтересованными лицами и их интересами (возможно, детализируемый далее до отдельных бизнес-процессов, алгоритмов, диаграмм состояний).
Так как количество видов ПО и практик велико, первоначальный автор рассчитывает на активное участие сообщества в написании данной статьи.
Классификация программных продуктов и их заинтересованных лиц
Программные продукты можно классифицировать
* по тиражируемости
* заказное
* внешней разработки
* внутренней разработки
* ограниченно тиражируемое ("корпоративного" уровня)
* тиражируемое ("коробочное")
* по доле внешнего сервиса (доработки, обновления баз)
* со значительной долей внешнего сервиса
* без значительной роли внешнего сервиса
* по ориентированности
* инфраструктурное решение
* бизнес-решение
* информационно-образовательное
* развлекательное.
Ограниченно тиражируемое, со значительным уровнем внешнего сервиса, бизнес-решение
Заинтересованные лица
* Компания-разработчик
* Инвестор - интересы в скорейшем возврате инвестированных денег с одной стороны, и постоянном доходе в будущем - с другой
* Команда 1 - в зависимости от личностей и командных традиций, интересы в скорейшей разработке "на результат", как можно более долгой разработке "потому что нравится процесс" или чтобы сохранить работу, как можно более качественных артефактах "чтобы потом было легко поддерживать" или чтобы "забыть как страшный сон", или не слишком качественных артефактах, чтобы поддерживая их, сохранять работу; баланс существующих и новых технологий; баланс повторного использования и разработки заново
* Команда n
* Компания-дистрибьютор
* Инвестор - аналогично
* Продавцы - как можно большие объёмы продаж сейчас с одной стороны, и высокие объёмы продаж в течение длительного времени - с другой (востребованность, наличие ярких продающих факторов, качество при длительной работе)
* Инженеры пресейла - возможность как можно легче продемонстрировать возможности и привлекательность продукта кастомизаторам и интеграторам
* Компания-кастомизатор
* Инвестор - аналогично
* Команда 1 - аналогично команде разработчиков, кроме того - наличие у продукта средств разработки и отладки, руководства разработчика, простота и комментированность предназначенного для кастомизации кода, большое количество заготовок для повторного использования (в т.ч. с учётом отраслевой специфики)
* Команда n
* Компания-интегратор
* Компания, оказывающая тех. поддержку
* Компания-заказчик
* Владелец решения
* Бизнес-подразделение 1
* Руководитель
* Исполнитель - роль 1
* Исполнитель - роль n
* Бизнес-подразделение n
Бизнес-подразделение 1...Бизнес-подразделение n
Здесь можно раскрыть типичную структуру компании (руководство, финансы, бухгалтерия, отдел продаж, производство, логистика, управление партнёрскими цепочками, IT, безопасность).
Роли производителей - типичные для отдела, возможно - по отраслям (возможно - по отрасли бизнеса; очень пригодилась бы информация из различного рода референтных моделей, руководств по бизнес-архитектуре, best pactices).
Классификация практик разработки ПО и работа с заинтересованными лицами в их рамках
* По степени доверия * Процессы, подразумевающие высокое доверие и вовлечение Заказчика * Процессы, подразумевающие низкое доверие и вовлечение Заказчика * По степени изменчивости требований и обязательств их учёта * FOSS * Поставка As Is * SLA * Прямое управление приоритетами компании-разработчика
Процессы, подразумевающие низкое доверие и вовлечение Заказчика, SLA
Для ограниченно тиражируемого ПО, со значительным уровнем внешнего сервиса, бизнес-решение
Заявки, их трассировка с другими артефактами со строгим учётом времени и отчётами Заказчику об изменении статуса
Деление на инциденты, проблемы и запросы доработки
Устранение инцидентов менеджером клиента
Деление проблем на проблемы ПО и проблемы инсталляции
Оперативное устранение проблем ПО, "дежурная команда"
Бесплатная доработка, доработка частично или полностью за счёт Заказчика
Дилемма между устранением проблем и развитием продукта
Работа с проблемными Заказчиками
Ссылки
* [1]
* Разработка требований к программному обеспечению. Карл И. Вигерс
* работы с требованиями к программному обеспечению. Унифицированный подход. Леффингуэлл, Уидриг
