document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #11415 from geekpi/new

Browse Source 
translated
This commit is contained in:
geekpi 2018-11-30 09:04:14 +08:00 committed by GitHub
commit 4aa811d624
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 40 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
sources/talk/20180208 Gathering project requirements using the Open Decision Framework.md
View File

@ -1,43 +0,0 @@
translating---geekpi
Gathering project requirements using the Open Decision Framework
======
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/suitcase_container_bag.png?itok=q40lKCBY)
It's no secret that clear, concise, and measurable requirements lead to more successful projects. A study about large scale projects by [McKinsey & Company in conjunction with the University of Oxford][1] revealed that "on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted." The research also showed that some of the causes for this failure were "fuzzy business objectives, out-of-sync stakeholders, and excessive rework."
Business analysts often find themselves constructing these requirements through ongoing conversations. To do this, they must engage multiple stakeholders and ensure that engaged participants provide clear business objectives. This leads to less rework and more projects with a higher rate of success.
And they can do it in an open and inclusive way.
### A framework for success
One tool for increasing project success rate is the [Open Decision Framework][2]. The Open Decision Framework is an resource that can help users make more effective decisions in organizations that embrace [open principles][3]. The framework stresses three primary principles: being transparent, being inclusive, and being customer-centric.
**Transparent**. Many times, developers and product designers assume they know how stakeholders use a particular tool or piece of software. But these assumptions are often incorrect and lead to misconceptions about what stakeholders actually need. Practicing transparency when having discussions with developers and business owners is imperative. Development teams need to see not only the "sunny day" scenario but also the challenges that stakeholders face with certain tools or processes. Ask questions such as: "What steps must be done manually?" and "Is this tool performing as you expect?" This provides a shared understanding of the problem and a common baseline for discussion.
**Inclusive**. It is vitally important for business analysts to look at body language and visual cues when gathering requirements. If someone is sitting with arms crossed or rolling their eyes, then it's a clear indication that they do not feel heard. A BA must encourage open communication by reaching out to those that don't feel heard and giving them the opportunity to be heard. Prior to starting the session, lay down ground rules that make the place safe for all to speak their opinions and to share their thoughts. Listen to the feedback provided and respond politely when feedback is offered. Diverse opinions and collaborative problem solving will bring exciting ideas to the session.
**Customer-centric**. The first step to being customer-centric is to recognize the customer. Who is benefiting from this change, update, or development? Early in the project, conduct a stakeholder mapping to help determine the key stakeholders, their roles in the project, and the ways they fit into the big picture. Involving the right customers and assuring that their needs are met will lead to more successful requirements being identified, more realistic (real-life) tests being conducted, and, ultimately, a successful delivery.
When your requirement sessions are transparent, inclusive, and customer-centric, you'll gather better requirements. And when you use the [Open Decision Framework][4] for running those sessions, participants feel more involved and empowered, and they deliver more accurate and complete requirements. In other words:
**Transparent + Inclusive + Customer-Centric = Better Requirements = Successful Projects**
--------------------------------------------------------------------------------
via: https://opensource.com/open-organization/18/2/constructing-project-requirements
作者：[Tracy Buckner][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/tracyb
[1]:http://calleam.com/WTPF/?page_id=1445
[2]:https://opensource.com/open-organization/resources/open-decision-framework
[3]:https://opensource.com/open-organization/resources/open-org-definition
[4]:https://opensource.com/open-organization/16/6/introducing-open-decision-framework

40
translated/talk/20180208 Gathering project requirements using the Open Decision Framework.md Normal file
View File

@ -0,0 +1,40 @@
使用开放决策框架收集项目需求
======
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/suitcase_container_bag.png?itok=q40lKCBY)
众所周知，明确、简洁和可衡量的需求会带来更多成功的项目。一项关于[麦肯锡与牛津大学][1]的大型项目的研究表明：“平均而言，大型 IT 项目超出预算 45％，时间每推移 7％，价值就比预期低 56％ “。该研究还表明，造成这种失败的一些原因是“模糊的业务目标，不同步的利益相关者以及过度的返工”。
业务分析师经常发现自己通过持续对话来构建这些需求。为此，他们必须吸引多个利益相关方，并确保参与者提供明确的业务目标。这样可以减少返工，提高更多项目的成功率。
他们可以用开放和包容的方式做到这一点。
### 成功的框架
提高项目成功率的一个工具是[开放决策框架][2]。开放决策框架是一种资源，可以帮助用户在拥抱[开放原则][3]的组织中做出更有效的决策。该框架强调三个主要原则：透明、包容、以客户为中心。
**透明**。很多时候，开发人员和产品设计人员都认为他们知道利益相关者如何使用特定工具或软件。但这些假设往往是不正确的，并导致对利益相关者实际需求的误解。开发人员和企业主讨论时实行透明势在必行。开发团队不仅需要了解一些好的情景，还需要了解利益相关方面对某些工具或流程所面临的挑战。提出诸如以下问题：“必须手动完成哪些步骤？”以及“这个工具是否按预期运行？”这提供了对问题的共同理解和讨论的基准。
**包容**。对于业务分析师来说，在收集需求时观察肢体语言和视觉暗示非常重要。如果有人双臂交叉或睁着眼睛坐着，那么这清楚地表明他们感觉没被聆听。业务分析师必须鼓励那些不被聆听的人公开交流，并给他们机会被聆听。在开始会议之前，制定基本规则，使所有人都能发表意见并分享他们的想法。聆听提供的反馈，并在收到反馈时礼貌地回复。多样化的意见和协作解决问题将为会议带来令人兴奋的想法。
**以顾客为中心**。以客户为中心的第一步是识别客户。谁从这种变化、更新或开发中受益？在项目早期，进行利益相关者映射，以帮助确定关键利益相关者，他们在项目中的角色以及他们适应大局的方式。让合适的客户参与并确保满足他们的需求将会确定更成功的要求，进行更现实（现实）的测试，并最终成功交付。
当你的需求会议透明、包容和以客户为中心时，你将收集更好的需求。当你使用[开放决策框架][4]来进行会议时，参与者会感觉有更多参与与授权，他们会提供更准确和完整的需求。换一种说法：
**透明+包容+以客户为中心=更好的需求=成功的项目**
--------------------------------------------------------------------------------
via: https://opensource.com/open-organization/18/2/constructing-project-requirements
作者：[Tracy Buckner][a]
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/tracyb
[1]:http://calleam.com/WTPF/?page_id=1445
[2]:https://opensource.com/open-organization/resources/open-decision-framework
[3]:https://opensource.com/open-organization/resources/open-org-definition
[4]:https://opensource.com/open-organization/16/6/introducing-open-decision-framework