На рис. 22-2 показаны некоторые заинтересованные в проекте лица, взаимодействующие с группой разработки ПО, и вклад, который они вносят в процесс конструирования требований проекта. Объясните всем, кто имеет дело с проектом, какую информацию и другое содействие, необходимое для успеха проекта, вы хотите получить от них, Согласуйте форму и содержание основ взаимодействия между разработчиками и теми, кто занимается другими вопросами, связанными с продуктом, — спецификацией требований к ПО или документацией рыночных требований. Слишком часто при написании важных документов автор отражает только собственную точку зрения, не учитывая того, какая же полная информация необходима читателям этих документов.
Вы, конечно, можете поинтересоваться у других организаций, что они хотят получить от группы разработчиков для облегчения работы. Какая информация о технической осуществимости поможет отделу маркетинга лучше планировать концепции продуктов? Какие отчеты по статусу исполнения требований дадут менеджерам ясное представление о развитии проекта? Какое взаимодействие с отделом разработки систем позволит верно судить о том, что системные требования правильно распределены между программной и аппаратной подсистемами? Активно стремитесь строить взаимоотношения сотрудничества между разработчиками и другими заинтересованными в проекте сторонами.
Рис. 22-2. Связанное с требованиями взаимодействие между разработчиками ПО и другими лицами, заинтересованными в проекте
Когда группа разработчиков ПО изменяет свои процессы работы с требованиями, их взаимодействие с другими заинтересованными в проекте сторонами также изменяется. Люди не любят, когда их принуждают выходить за пределы их зоны комфорта, поэтому будьте готовы к некоторому сопротивлению вашим начинаниям. Узнайте причины сопротивления, чтобы иметь возможность как понимать, так и гасить его. Часто оно вызвано страхом перед неизвестным. Чтобы уменьшить боязнь, сообщите логическое обоснование совершенствования технологических процессов работы с требованиями и намерения своим коллегам из других отделов. Объясните преимущества, которые они получат от нововведений. Добиваясь сотрудничества, вначале озвучьте свою точку зрения: «Вот проблемы, которые все мы прочувствовали. Мы считаем, что изменение в работе помогут решить эти проблемы. Вот что мы планируем сделать, вот какую помощь мы надеемся получить от вас, и вот как наша общая работа поможет всем нам». Вот какое ее противление вы можете испытать.
· Процесс управления изменениями можно рассматривать как барьер, воздвигаемый разработчиками, чтобы затруднить изменения. В действительности процесс управления изменениями — это структура, а не барьер. Он позволяет хорошо информированным людям принимать отличные бизнес-решения. Команда разработчиков ПО отвечает за то, чтобы процесс внесения изменений действительно работал. Если новые процессы не принесут лучших результатов, люди найдут способы их обойти — и, наверное, это правильно.
· Некоторые разработчики считают документирование и проверку требований пустой волокитой, не дающей им заниматься «настоящей» работой — написанием кода. Если вы сможете объяснить, насколько дорого обходится переписывание кода, пока команда пытается понять, что должна делать система, разработчики и менеджеры будут больше ценить необходимость хороших требований.
· Если расходы на поддержку пользователей не связаны с процессом разработки, у команды разработчиков может и не быть стимула менять стиль работы — ведь они не страдают от последствий плохого качества продукта.
· Если одна из целей совершенствования технологических процессов — уменьшение стоимости поддержки продукта отличающегося высоким качеством, менеджер, отвечающий за поддержку продукта, может почувствовать угрозу. Кому же хочется ослабления империи?
· Занятые клиенты иногда заявляют, что у них нет времени работать над требованиями. Напомните им о предыдущих проектах, результатом которых стало создание плохо работающих систем, а также о высокой стоимости удовлетворения потребностей клиентов после выхода продуктов.
Когда людей просят изменить методы работы, их естественная реакция: «А что мне с этого будет?». Однако такие изменения не всегда приводят к поразительным и немедленным результатам для всех, кого процесс затрагивает. Более важный вопрос, кстати, на который любой, кто отвечает за совершенствование процесса, должен уметь отвечать убедительно: «Что нам с этого будет?» Любое изменение процессов должно предлагать перспективу ясных преимуществ команде, работающей над проектом, организации-разработчику, компании, клиентам или всему миру. Часто убедить людей принять эти изменения можно, обещая исправление известных существующих в настоящее время недостатков, ведущих к нежелательным бизнес-результатам.