analyst.by

Белорусское сообщество бизнес и системных аналитиков

“Почему?” против “Почему нет?”

question why

Оригинальная статья: “‘Why?’ Versus ‘Why Not?’“ by Paula Bell

Я большая поклонница социальных сетей и просматриваю Facebook, LinkedIn и Twitter каждый день. Ладно, признаюсь, несколько раз в день. Однажды я обнаружила интересный статус на страничке моего мужа в сети Facebook, и он заставил меня задуматься над тем, как два простых вопроса могут приводить к таким разным результатам в зависимости от ситуации. Статус моего мужа звучал так: “Мы можем постоянно задаваться вопросом “Почему”, а можем подумать, как добиться чего-то и спросить себя “Почему нет?”.

Применительно к вашей жизни, карьере или мечтам, которые вы хотели бы воплотить в жизнь, данный статус можно интерпретировать как преодоление преград и побуждение к реализации задумок с помощью вопроса “А почему нет?”. Вопрос “Почему” в подобных ситуациях потенциально может привести к критике вашей цели или мечты. Мой муж – огромный мечтатель, и я ценю и люблю в нём это качество, потому что он полностью концентрируется на цели и всегда планирует способ её достижения. Однако если подумать об этом с точки зрения бизнес-аналитика, то я бы предпочла спросить “Почему?”, а не “Почему нет?”.

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

Важно, чтобы бизнес-аналитики, прежде чем начать сбор требований, действительно уяснили следующие моменты:

1.  Цель проекта: “Почему мы это делаем?” Удивляет то, как часто меня назначали на проекты, где ни один человек реально не понимал, почему и зачем мы разрабатываем продукт. Просто у кого-то возникла классная идея, и кто-то другой по непонятным причинам поверил в успех этого проекта. В реальности же идея не должна быть причиной для начала проекта, лишь потому, что это просто идея, а не видение или стратегическая цель для старта проекта.

2.  Заинтересованные лица (stakeholders): “Почему вы здесь и какова ваша заинтересованность в проекте?” Очень важно удостовериться в том, что вы учитываете всех игроков, понимаете их роли и обязанности. Если же есть люди, про которых вы знаете только то, что они должны быть здесь, вам следует выяснить, ПОЧЕМУ они здесь. Какую выгоду они хотят извлечь из проекта? Если ни они, ни вы этого не знаете – возникает проблема, которую нужно изучить. Каждый участник должен играть определённую роль в проекте.

3.  План по управлению требованиями: “Почему мы выбрали именно этот подход?” На этом этапе важно иметь план по сбору требований, который будет подходить данному конкретному проекту. К подобным важным вещам также можно отнести вопросы о методологии, способе ведении документации и распределении ресурсов на этапе сбора требований. Если вы не знаете, почему вы применяете тот или иной подход, вероятно, стоит его пересмотреть.

4.  Документация: “Почему вы используете данный шаблон документов?” В последнее время на этот предмет ведётся много дискуссий. Я часто слышу вопрос: “Какой шаблон использовать?”. На самом же деле постановка вопроса должна касаться не самого шаблона, а скорее того, какая информация будет иметь наибольшую ценность для потребителей. Если шаблон или сам документ не несут никакой пользы, спросите себя “А почему я его использую?” Работа бизнес-аналитика заключается не в документировании требований по шаблону, а в создании такой документации, которая будет приносить пользу для конкретного проекта.

5.  Решение: “Почему мы выбираем именно это решение?” Никто не понимает требования лучше, чем их автор.  Мы как бизнес-аналитики тесно общаемся с заказчиками и должны убедиться в том, что нужды заказчиков эффективно транслируются разработчикам и реализуются в соответствии с бизнес-целями. Требования иногда могут быть реализованы не так, как предполагалось изначально, в связи с тем, что разработчики зачастую считают, что именно их решение принесет пользу проекту. И мы обязаны убедиться в том, что решение действительно соответствует бизнес-целям, а не меняет их только лишь потому, что является эффективным решением с точки зрения разработчиков. У меня были ситуации, когда решение было выбрано преждевременно. Это привело к тому, что оно определяло новые требования, потому что перед выбором решения никто не уделил должного внимания пониманию бизнес целей. Но об этом в другой статье.

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

1. Порыв “просто сделать это” будет опираться на заведомо нереалистичные ожидания;

2. Вы не будете до конца понимать бизнес цели заказчика, так как вы не достаточно глубоко исследуете этот вопрос на этапе сбора требований;

3. Разработанное вами решение не будет являться наиболее эффективным из всех возможных.

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


Автор: Paula Bell

Оригинал статьи: http://www.batimes.com/articles/why-versus-why-not.html

Перевод подготовила: Турейко Анастасия

Обсуждение на форуме: http://analyst.by/forum/materialy-saita/pochemu-protiv-pochemu-net

 


22 Июля, 2011


Добавить комментарий
Также Вы можете войти используя: Facebook Google