(В оригинале Balance stakeholders' interests with technical requirements)

Когда мы говорим о проектировании программного обеспечения, нам прежде всего приходят в голову мысли о классических технических вещах, таких как разбиение системы на модули, определение интерфейсов, распределение ответственностей, применение паттернов проектирования и оптимизации производительности. Проектировщикам также нужно принимать во внимание безопасность, удобство использования, техподдержку, управление версиями и возможность внедрения. Однако все эти технические и процессуальные вещи должны быть в равновесии с потребностями участников и их выгодой. Подход «потребности и выгода участников» в анализе требований является одним из лучших вариантов для гарантирования полноты спецификаций для разрабатываемого ПО.

Анализ выгод участников, как в самом процессе разработки ПО, так и в организации, разрабатывающей ПО, позволяет выявить основные приоритеты, управлять которыми и должен проектировщик, как в краткосрочной, так и в долгосрочной перспективе.

Рассмотрим, например, отдел разработки компании, предлагающей на рынке сервис разработки программного обеспечения. Компания, вероятно, имеет свои определенные приоритеты, такие как выполнение контрактных обязательств, получение дохода, получение рекомендаций от заказчиков, снижение расходов и создание ценностных активов. Эти приоритеты накладываются на приоритеты отдела, такие как обеспечение функциональности и качества разрабатываемого программного обеспечения, продуктивности команды разработчиков, стабильности и проверяемости основных процессов, а также адаптируемости и долговечности программного продукта.

И работа проектировщика заключается не только в том, чтобы спроектировать функциональное и качественное ПО, а также в нахождении равновесия между этими приоритетами всех вовлеченных сторон: снижением расходов со стороны директора фирмы, удобством администрирования со стороны операторов, легкостью сопровождения со стороны команды поддержки и лучшими практиками в области проектирования.

Проектировщик может осознанно нарушить баланс в пользу одного из приоритетов в краткосрочном периоде, однако в долгосрочной перспективе лучше поддерживать равновесие для того, чтобы работа была сделана хорошо. Баланс также должен быть в соответствии с контекстом – нужно учитывать такие факторы как ожидаемое время жизни программного обеспечения, критичность его для фирмы, а также технологическую и финансовую культуру организации.

Подводя итог: проектирование программного обеспечения – это не только лишь техническая работа, а и нахождение баланса между техническими требованиями и бизнес-интересами вовлеченных в проект сторон.

Автор оригинала: Randy Stafford