软件项目中的决策分析

Every day we make a lot of decisions. I always wonder why, in so much companies, there is so little process to make them. We often make these decisions on our own, without any formal process, often without awareness. Worse yet, we do not document these decisions, their context nor their consequences. Then, a few months later, no one remembers why we choose a solution that might be absurd today in another context. This lack of decision management is very painful for your business.

每天我们都会做出很多决定。 我总是想知道为什么在这么多的公司中,制造它们的过程很少。 我们通常会自行决定,没有任何正式程序,而且往往没有意识。 更糟糕的是,我们没有记录这些决定,其背景或后果。 然后,几个月后,没人记得我们为什么选择今天在另一种情况下可能荒唐的解决方案。 缺乏决策管理对您的企业非常痛苦。

“You are free to choose, but you are not free to alter the consequences of your decisions.”

“您可以自由选择,但不能随意改变决策的后果。”

― Ezra Taft Benson

―以斯拉·塔夫脱·本森

In this article, I give you a framework for making better decisions by identifying the context and the consequences. But you will learn that it is not enough to make the right decision, because the context is constantly changing. The key aspect of decision management is to record all of these decisions in a decision log book. It allows the team to understand how they got there and effectively iterate over the previously chosen solutions to create a strong software product.

在本文中,我为您提供了一个框架,可以通过识别上下文和后果来做出更好的决策。 但是您会发现仅仅做出正确的决定是不够的,因为上下文在不断变化。 决策管理的关键方面是将所有这些决策记录在决策日志中。 它使团队可以了解他们是如何到达那里的,并可以有效地迭代先前选择的解决方案以创建强大的软件产品。

什么决定? (What is a decision?)

A decision is the act of defining a solution for a given problem, in a current context.

决策是在当前上下文中为给定问题定义解决方案的动作。

There are a lot of decisions to be made when developing software. In fact, everything you do in software development comes down to a decision: how to meet a customer need, how to meet our business objective, choosing a UX over another, choose one feature over another, how to fix a bug, pick a language, pick a framework, pick a database technology, … Some of them can have a huge impact on the future.

开发软件时,需要做出很多决定。 实际上,您在软件开发中所做的一切都取决于一个决定:如何满足客户需求,如何满足我们的业务目标,选择UX而不是UX,选择功能而不是其他功能,如何修复错误,选择语言,选择框架,选择数据库技术,…其中一些可能对未来产生巨大影响。

In software engineering, problems often arise from customer needs collected in the feedback loop. Customers tend to ask for new features, but understanding the issue behind the feature request is very important to ensure that you get a correct answer. It’s the “Why?”. The first decision is whether or not to try to meet these needs. The framework below is not intended to be a prioritization framework, prefer RICE or Cost of Delay..

在软件工程中,问题通常是由反馈循环中收集的客户需求引起的。 客户倾向于要求新功能,但是了解功能要求背后的问题对于确保获得正确答案非常重要。 这就是“为什么?”。 第一个决定是是否尝试满足这些需求。 以下框架并非旨在成为优先级排序框架,而希望使用RICE或延迟成本 ..

When a need is prioritized, you have to choose the best way to meet it. This often leads to a new feature or an improvement to an existing one. It’s the “What?”

优先考虑需求时,您必须选择满足需求的最佳方法。 这通常会导致新功能或对现有功能的改进。 这是“什么?”

Then, before you develop this feature in your software, you need to decide how to implement it (define the software architecture that is the most efficient). It’s the “How?”

然后,在软件中开发此功能之前,需要确定如何实现此功能(定义最有效的软件体系结构)。 这是“如何?”

Some decisions in software engineering : Why, What & How
软件工程中的一些决策:为什么,什么和如何

The “Why?”, “What?” and the “How?” are decisions to be made over time to create good software. These decisions, and others, are often made conscienceless. This leads to bad future decisions. When you don’t understand why things are the way they are, it’s hard to try and change them. If you have a feature, but don’t know its original purpose. Will you delete it? Will you try to modify it? How do you improve it if you don’t know what it aims to solve? There are the same issues with the technical decision. If you don’t know why a feature is developed this way, are you going to refactor it? Are you going to change the underlying technologies (language, database, deployment target)?

“为什么?”,“什么?” 以及“如何?” 是随着时间的流逝而创建优质软件的决策。 这些决定以及其他决定常常是无知的。 这导致未来的错误决策。 当您不了解事物为何如此时,很难尝试更改它们。 如果您具有功能,但不知道其原始目的。 你会删除吗? 您会尝试修改它吗? 如果您不知道要解决的目标,该如何改进? 技术决定也存在相同的问题。 如果您不知道为什么以这种方式开发功能,是否要重构它? 您是否要更改基础技术(语言,数据库,部署目标)?

That’s why we need a clear decision management framework: to make good decisions today and tomorrow.

这就是为什么我们需要一个清晰的决策管理框架:在今天和明天做出好的决策。

确定您的背景和约束 (Identify your context and constraints)

To make a good decision, you must have a good understanding of your context and constraints. The context is mainly your resources, your timing and the impact you want to have. This is the expectation you have for future solutions.

要做出正确的决定,您必须对自己的背景和约束有很好的了解。 上下文主要是您的资源,时间和想要产生的影响。 这是您对未来解决方案的期望。

For example, you don’t build a product the same with a single trainee developer in a week or with a full team of developers in a month. You don’t build an email platform for 100 users like you build an email platform for millions of users.

例如,您不会在一个星期内与一个受训者开发人员或一个月内与一个完整的开发人员团队一起构建相同的产品。 您没有为100个用户构建电子邮件平台,就像为数百万用户构建电子邮件平台一样。

Before making a decision, you need to identify and address these constraints, although these constraints may change in the future.

在做出决定之前,您需要确定并解决这些约束,尽管这些约束将来可能会更改。

确定至少两个解决方案 (Identify at least two solutions)

Once you have identified the problem and the current constraints, you need to find solutions. I highly recommend finding at least two or more potential solutions to avoid the law of the instruments of cognitive bias.

一旦确定了问题和当前的限制,就需要找到解决方案。 我强烈建议您至少找到两个或两个以上潜在的解决方案,以避开认知偏见工具的规律 。

If all you have is a hammer, everything looks like a nail.

如果您只有锤子,那么一切看起来都像钉子。

Abraham Maslow, The Psychology of Science

亚伯拉罕·马斯洛( Abraham Maslow),《科学心理学》

This means that if you only know one way to do things, you’ll do it that way even if it’s not the right one. That is why you should have at least two solutions to make sure that you are not choosing the solution you are most familiar with but the best one to match the constraints.

这意味着,如果您只知道一种做事方法,即使不是正确的方法,也将以这种方式做事。 这就是为什么您应该至少有两个解决方案,以确保您没有选择最熟悉的解决方案,而是选择与约束相匹配的最佳解决方案。

When you have your potential solution, identify the potential consequences and limitations of each. For example, doing it quickly means it can increase technical debt, or this technology works up to a million requests per day.

当您拥有潜在的解决方案时,请确定每种解决方案的潜在后果和局限性。 例如,快速执行意味着增加技术负担,或者该技术每天处理多达一百万个请求。

做出决定 (Act your decision)

When you have identified the problem, the constraints and some potential solutions with their consequences. Now is the time to decide. Identify the decision makers and create a 15 minute meeting with all of then and make your choice. Congratulations, you have made a decision. Last but not least, write a new record in the decision log. Because the consequences of today’s decision will be the context for future decisions.

当您确定了问题,约束和可能的解决方案及其后果之后。 现在是决定的时候了。 确定决策者,并与所有人召开15分钟的会议,然后做出选择。 恭喜,您已做出决定。 最后但并非最不重要的一点是,在决策日志中写入一条新记录。 因为今天决策的结果将成为未来决策的背景。

什么是决策日志? (What is a decision log book?)

The decision log is a file in which you record every decision you make. As I said in a previous article about technical documentation, the decision log book is a key documentation file to help future engineers understand how software was built.

决策日志是一个文件,您可以在其中记录所做的每个决策。 正如我在上一篇有关技术文档的文章中所说的那样 ,决策日志是一个关键的文档文件,可以帮助未来的工程师了解软件的构建方式。

如何记录决策? (How to log decisions?)

Create a file with this information:

使用以下信息创建文件:

  • What is the initial problem最初的问题是什么
  • When did you act the decision你什么时候决定的
  • Who decides on this solution谁决定这个解决方案
  • The current context and constraints during the decision决策过程中的当前背景和约束
  • The acted solution, its consequences and why it was chosen实际解决方案,其后果以及选择该解决方案的原因
  • All the rejected solutions, their consequences and why they were rejected.所有被拒绝的解决方案,它们的后果以及为什么被拒绝。
This is a example of decision log records
这是决策日志记录的示例

你错了,没关系! (You were wrong, that’s okay!)

This framework allows you to make better decisions. But sometimes we can still get it wrong, or the context change and the previous solution no longer works. Good news, it's 100% normal and it’s easy to fix.

该框架使您可以做出更好的决策。 但是有时我们仍然会出错,或者上下文更改和以前的解决方案不再起作用。 好消息,这是100%正常且易于修复。

Find your previous decision record, duplicate it, add to context the reasons why this first solution didn’t work. Repeat the process with the new context and previously evicted solutions. Remember to challenge these potential solutions with new ones. You will find another solution that better suited to the new context.

查找您先前的决策记录,将其复制,并在上下文中添加第一个解决方案无效的原因。 使用新的上下文和先前收回的解决方案重复此过程。 记住要用新的方法挑战这些潜在的方法。 您将找到另一个更适合新环境的解决方案。

阅读上一个决策日志 (Read the previous decision log book)

The decision log book is a very valuable document. It explains the context to every decision you’ve made so far. Whenever you have to make a new choice, try to understand the previous one that leads to the current situation. Some of them may have known limitations that don’t match the current context, and you need to do it again. Maybe a previously evicted solution will better match new context.

决策日志是非常有价值的文件。 它解释了到目前为止您做出的每个决定的背景。 每当您必须做出新的选择时,请尝试理解导致当前情况的前一个选择。 其中一些可能具有与当前上下文不匹配的已知限制,因此您需要再次进行。 也许以前淘汰的解决方案将更好地适应新的环境。

当您无法选择最佳解决方案时该怎么办? (What to do when you cannot choose the best solution ?)

I highly recommend limiting the time to find potential solutions to avoid over-engineering. Depending on the decision, it may take a few minutes (for example during backlog grooming or technical architecture meeting) or a couple of days for the high consequence decisions.

我强烈建议您限制寻找潜在解决方案的时间,以避免过度设计。 根据决策,可能需要几分钟(例如在积压整理或技术体系结构会议期间)或几天才能做出高结果决策。

Sometimes you can’t find enough solutions in the allotted time. When this happens, the solution to your problem is quite simple: there is no solution yet. This will drastically reduce the bad choice you make. Because not being able to choose a sufficiently good solution leads to identifying a risk earlier and being able to manage it before failing.

有时您无法在指定的时间内找到足够的解决方案。 发生这种情况时,解决问题的方法非常简单:目前还没有解决方案。 这将大大减少您做出的错误选择。 因为无法选择足够好的解决方案会导致更早地识别风险并能够在失败之前进行管理。

To overcome it, identify a solution to find a solution

软件项目中的决策分析_软件工程中的决策管理相关推荐

  1. 软件项目的可行性分析包括哪些方面?影响决策的关键因素又是什么?

    软件项目的可行性分析包括哪些方面?影响决策的关键因素又是什么? 答: 软件项目的可行性因素,从宏观影响角度分析,分为经济.技术.社会环境和人等4个要素:从风险影响角度分析,分为项目风险.商业风险.技术 ...

  2. 手机屏幕xy坐标软件_软件工程中的xy问题

    手机屏幕xy坐标软件 XY problem is classified as a communication problem in which the person who asks the ques ...

  3. python应聘项目经历怎么写_简历中怎么写「项目经历」最好?为什么?

    项目经理找工作时,面试官普遍看重项目经验. 一般来说,项目经验与工作经验是相辅相成的,但比起工作经验,项目经验更能表现项目经理在某个专业领域的水平.因而,技术类岗位.管理类岗位在招聘中都很注重项目经验 ...

  4. 中累计直方图_试验研究中的利器强大的直方图和箱线图

    上次小编给大家介绍了跟误差线有关的几个概念以及相关的柱状图,散点图,和小提琴图(试验数据统计中常用的 量,图,和线--再也不担心文章的统计用图了!).这些图和线都属于"比较统计学" ...

  5. c# mysql代码中写事务_代码中添加事务控制 VS(数据库存储过程+事务) 保证数据的完整性与一致性...

    [c#]代码库代码中使用事务前提:务必保证一个功能(或用例)在同一个打开的数据连接上,放到同一个事务里面操作. 首先是在D层添加一个类为了保存当前操作的这一个连接放到一个事务中执行,并事务执行打开同一 ...

  6. eof在c语言中表示什么_日语中的鍵为什么既能表示“钥匙”也能表示“锁”?...

    我们知道,日语中的「鍵(かぎ)」表示"钥匙"的意思,例如:(1)玄関(げんかん)の鍵をなくした.房门钥匙弄丢了.但同时还能表示"锁"的意思.例如:(2)納戸(な ...

  7. 模块化 组件化 工程化_软件工程中的模块和软件组件

    模块化 组件化 工程化 The module in software is a small part of the software that is responsible for performin ...

  8. jeecg项目开源的名字_开源中的名字是什么?

    jeecg项目开源的名字 社区对您意味着什么? 社区是一个重载的词,它可以表示任何东西. 社区可以意味着仅使用您产品的人. 也许是那些制造您的产品的人,或者是使用该产品的业务合作伙伴. 也许是那些在博 ...

  9. 工程中多个不同类型线程池_软件工程中不同类型的设计策略

    工程中多个不同类型线程池 As we know that the designing phase is probably the second phase in the software develo ...

最新文章

  1. python 零矩阵
  2. 终于有了属于自己的家,哈哈,很高兴~~
  3. 单例销毁_【PHP设计模式】单例模式
  4. C# 跨线程调用控件
  5. 捡到银行卡套取密码取现1万多元,犯了信用卡诈骗罪被判7个月
  6. ARC079F - Namori Grundy(构造,基环树)
  7. 前端学习(3018):vue+element今日头条管理--反馈
  8. python匹配字符串_字符串匹配算法之Kmp算法(Python实现)
  9. JMeter基础之组件的作用域与执行顺序
  10. 9.2.2、Libgdx的输入处理之事件处理
  11. 富文本 NSAttributedString
  12. bind(),live(),delegate(),on()绑定事件方式
  13. java读取配置文件方法_java 三种读取配置文件的方式
  14. oracle脱敏脚本
  15. HP 816 817墨盒计数器清零方法
  16. linux mbr 转 gpt 数据丢吗,MBR转GPT要重装系统吗?不丢失数据 MBR转GPT分区表教程...
  17. 打印端口用计算机名,如何设置打印机端口,教您设置电脑打印机端口
  18. 微信小程序真机调试手机端在无法连接电脑localhost:3000时如何调试解决办法
  19. 4月22日丨【云数据库技术沙龙】技术进化,让数据更智能
  20. java 二进制运算

热门文章

  1. 一个笼子里面关了鸡和兔子(鸡有2只脚,兔子有4只脚,没有例外)。已经知道了笼子里面脚的总数a,问笼子里面至少有多少只动物,至多有多少只动物
  2. Python爬虫入门教程 16-100 500px摄影师社区抓取摄影师数据
  3. javascript实现电话号码验证
  4. (翻译)禀赋效应(Endowment Effect)
  5. King of Glory刷金币脚本
  6. (转)MBA案例:Taxi
  7. C盘不断变大解决办法
  8. 快消供应链管理解决方案
  9. 怎么搭建自己的播客_如何开始自己的播客(逐步)
  10. 计算机故障检修的常用流程及方法,常见品牌变频空调通讯故障通用检修流程与方法...