Как превратить нужды клиента в успешные проекты

Все проекты в сфере информационных технологий движутся за счет бизнес-требований. Для руководителя сложность представляет перевод данных бизнес-требований в конечный продукт, который будет удовлетворять всем нуждам бизнеса.

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

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

Если все это приведет к суду, то вам стоит ожидать хлопот и материальных потерь, особенно если у вас нет верной страховки ИТ-руководителя для защиты вашего бизнеса. Кроме избегания судов, просто ради дела вам стоит выполнять свою работу должным образом с первого раза для того, чтобы избежать последующей переработки и изменений требований.

Хорошее управление проектом приравнивается к хорошему управлению рисками

Так как же руководителю проектов перевести клиентские нужды в систему, которая разрешает его бизнес-проблемы? Ответом будет хорошее управление проектами. Компании со слабо развитыми методами управления проектов имеют больше шансов попасть в суд, чем те, которые используют формальные процессы управления. Хорошо продуманные процессы управления значительно снижают риски проекта.

Согласно экспертам, одним из критически важных шагов в управлении ИТ-проектами является определение видения и масштаба проектов. Для каждого проекта вам стоит четко определить в письменной форме:

• Бизнес-требования. Все детальные требования должны быть основаны на четко определенных нуждах бизнеса. Руководители проектов собирают бизнес-требования у высшего руководства клиентов, спонсоров, проектного эксперта, руководства проекта, отдела маркетинга или кого-нибудь еще, кто имеет четкое понимание нужд и ценности, которую это предоставит компании клиента и ее потребителям.
• Видение решения. Долгосрочное видение новой системы предоставит контекст для принятия решений на протяжении разработки товара. Выражение видения не должно включать в себя детальные функциональные требования или информацию о плане проекта.
• Масштаб и ограничения.Важно определить принцип предложенного решения и область, а также то, что не будет включено в продукт. Пояснение масштаба проекта и его ограничения устанавливает реалистичные ожидания различных участников, а также некоторый кодекс, по которому команда может оценивать предлагаемые функции и изменения требований.
• Бизнес-контекст.Любые проблемы бизнеса, связанные с проектом, должны быть пояснены и обобщены в контексте. В него могут входить основные категории клиентов, предположения, которые были заложены в принцип проекта и приоритеты руководства относительно проекта

Для снижения уровня риска управления мудро будет следовать установленному процессу инициации и управления ИТ-проектом.

10 ловушек относительно требований, которые стоит избегать

Успешные проекты по разработке ПО выполняются на основе хорошо понятых требований. Тем не менее, очень часто руководители технических проектов попадают в ловушки, которые ограничивают их в эффективном сборе, записи и управлении требованиями проекта. Несколько симптомов указывают на то, что вы на пути к "ловушке" при сборе требований:

• Непонимание того, чем является требование.
• Недостаточная вовлеченность клиента.
• Общие или неопределенные требования.
• Отсутствие приоритетов у требований .
• Никем не используемая функциональность.
• Запутанность при анализе.
• Увеличение масштаба .
• Неадекватный процесс изменения требований.
• Недостаточный анализ влияния изменений.
• Неадекватное управление версиями требований.

Говорите на языке клиента

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

Если это произойдет, то ваша команда может несколько месяцев проработать над проектом до того, когда данное непонимание станет явным. В таких случаях руководители сталкиваются с увеличением масштаба. Внезапно исполнение нужд клиента потребует больше времени и средств. На данном этапе вы встретите огромный риск управления потому, что некоторые клиенты просто перестанут вам платить и наймут адвоката.

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