В процессе реализации проекта по созданию / улучшению системы мы, исполнители, часто сталкиваемся с требованиями / замечаниями к системе, которые, по нашему мнению, кажутся маловажными, не относящимися к сути описываемых системой моделей мира, личными "хотелками" тех или иных исполнителей проектных ролей. По ходу чтения курса у меня возникло несколько мыслей, как можно аргументированно отказывать в реализации таких требований. Делюсь своими рассуждениями.
Шаг 1. Делать только то, что ролевое
Системы создаются для ролей, но не для исполнителей ролей. Что это означает?
При проектировании решения, при реализации, необходимо учитывать интересы и предпочтения конкретных ролей (которые эту самую систему определили как функциональный объект), но не интересы и предпочтения исполнителей ролей, личностей.
Как отличить интересы и предпочтения роли от интересов и предпочтений личности? Нужно выделить роли, которые играет личность. Затем каждое требование / замечание к системе трассировать на роль, которую эта личность играет. Это можно делать задавая простые вопросы вида "Вам нужна эта функция как кому?", "Вам не нравится это поведение системы / внешний вид системы как кому?". Если исполнитель роли ссылается на себя как на личность или как на должность (т.е. давит авторитетом), то аргументированно отказать в выполнении требования / исправления замечания можно следующими рассуждениями:
"Смотрите, мы делаем систему не лично для Вас, Иван Петрович, не для Марка Михайловича, не для Алены Викторовны и т.д. Мы делаем систему для таких ролей как (например) оператор КЦ, сотрудник техподдержки первой линии, супервизор КЦ, диспетчер приема и обработки заявок от сотрудников и так далее. Данное требование / замечание не является релевантным к какой-либо из этих ролей. (далее стоит как-то помягче, но пока не придумал как) Исполнители ролей всегда временны, но роли - постоянны. Поэтому мы не можем удовлетворять требования исполнителей ролей, иначе для следующих исполнителей система не будет отвечать требованиям. Мы делаем систему под требования ролей."
Нужно быть очень аккуратным, чтобы не задеть чувства исполнителя роли. Конечно, исполнитель может тут же встать в ту роль, от лица которой его требования было бы релевантно. В этом случае необходимо проверить, уполномочен ли исполнитель вставать в эту роль (см. шаг 2).
Шаг 2. Проверять, играет ли личность ту роль, которая ей положена должностью
Если известно, что личность Иван Петрович является по должности супервизором КЦ, то легко предположить (из деятельностного кругозора), какие роли он должен играть в данном проекте, т.е. от лица каких ролей он вправе диктовать требования к системе. В данном случае, полагаю, это роль супервизора КЦ (мониторинг деятельности операторов КЦ), роль оператора КЦ (прием и обработка обращений клиентов). Т.е. наш Иван Петрович может нам много рассказать (сформировать требования), например, к следующему:
- как должен работать оператор КЦ в системе, какие данные о клиенте должны быть у него на экране
- какие основные функции должен выполнять оператор КЦ
- какие функции должны быть доступны супервизору КЦ, в т.ч. оперативная отчетность
- и так далее
Но если Иван Петрович начинает диктовать требования, например, о том, что должен существовать отчет по вознаграждениям операторов КЦ за выполненные операции, то стоит задуматься, входит ли данный отчет в зону его интересов, работает ли Иван Петрович с ним. Запрос на такой отчет скорее должен поступить от отдела по вознаграждениям. Совсем игнорировать упомянутое требование, конечно, нельзя, но и с ходу реализовывать его тоже не стоит. Стоит пойти к людям из отдела ответственного за вознаграждения специалистов и проверить там необходимость в данном отчете.
Два этих шага + хороший навык переговоров, убеждения позволят делать в проекте только то, что действительно важно.
Конечно, это пока только теория, рассуждения, которые я вывел из первых трех глав курса "Системное мышление 2020".
Посмотрим, насколько данная схема будет реализуема и полезна на практике :)