Преобразование нужд ваших клиентов в успешные проекты

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

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

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

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

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

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

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

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

10 ловушек, связанных с требованиями

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

• Непонимание того, что на самом деле является требованием.
• Недостаточная вовлеченность клиента.
• Образные и амбициозные требования.
• Требования не расставлены по приоритетам.
• Функциональность, которая не пригодна никому.
• Ступор, приводящий к тратам времени и денег.
• Расползание границ проекта.
• Неадекватный процесс изменения требований.
• Недостаточный анализ влияния изменений.
• Неадекватное управление версиями требований.

Общение на языке клиента

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

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