前言
在软件项目中，我们会将功能分解为很多个任务，在执行过程中会存在一个误区，技术人员往往关注的是任务，一切以完成任务为中心，就出现违背以用户为中心和敏捷开发的思想。
功能和任务它们有着紧密联系，又有着根本区别。
联系是任务是为了实现功能而分解出来的具体活动，功能才是用户关注的，功能的优先级才体现了用户对这个功能的关注程度；而任务是技术人员关心的，举个例子比如有个任务是水平切分数据库表，这个用户连是什么意思都不清楚，他又怎么会关心呢？那这个任务也许对用户有意义，也许对用户的影响微乎其微。
两种不同的思路最终会影响项目中的决策，采取不同的策略，它的结局是不一样的。以任务为中心的决策思路可能会导致这样的后果：由于做计划中存在不确定性，因此项目的时间往往是非常紧张的，很有可能不能按照项目计划进行，那门以任务为中心的决策会根据技术的方便程度、技术人员的兴趣爱好来选取任务，可能那些对用户价值不大的任务优先开发，到项目快结束的时候发现，一些对用户最核心的功能早期没有得到足够重视，投入的资源不够，最后要么降低质量要求赶工，要么是个半成品，而项目要么延期，要么强行交付，最终用户满意度可想而知！这就是不以用户为中心的后果。
项目实例
下面举一个我们项目中实际遇到的例子。我们开发的一个消息系统，主要核心需求有两个，分别是应用提醒和通知提醒，介绍如下：
- 应用提醒。是项目最核心的需求，为各应用提供消息提醒功能。
- 通知提醒。是项目次重要的需求，提供通知类的消息提醒功能。
下面是两种不同的思想导致的决策结果。
以任务为中心的决策结果
经过我们的分解，分为如下三个主要任务：
1.应用提醒设计和开发。一个人领取该任务开发，该功能技术实现困难、风险非常大，而且工作量较多。
2.通知提醒设计和开发。一个人领取该任务开发，该功能实现相对简单些，技术风险一般，工作量相对少一些。
3.数据分表方案设计和实现。该任务是根据需求分解出的一个技术任务，主要是对消息的数据表进行拆分，以解决数据量过大导致表查询效率下降的问题，系统上线初期的意义并不是很大，并且对用户的使用体验上没有太大提升，但是有技术难度和风险，因此有一个人领取该任务，并且所有技术人员都愿意去尝试该任务，因为能够学习到更多的新技术，技术能够有提升的空间，所有技术人员对此都比较感兴趣。
当项目进行了1天之后，负责应用提醒设计和开发的技术人员提出，他那边的风险过大，根本无法按时完成任务，项目风险会非常大，后来我们的经过反思，觉得这样做下去项目问题会很大，最终的结果可能是这样的： 上述任务2和3的任务都按时完成了，实现任务3的技术人员觉得这下实践了一下新技术，感觉很开心，很有成就感，而负责1的工程师可能只实现了一个半成品，还有部分功能没有实现，有些功能实现得很粗糙，质量不高，最终项目无法按计划上线，给用户的承诺无法兑现，用户满意度下降，公司可能会损失一些用户，总之结果是成就了技术学习，失去了客户满意。
以功能为中心的决策结果
那么我们到底错在哪里呢？到底应该怎么正确的决策呢？下面是我们的一个分析过程。
1.确定需求优和任务先级
确定需求优先级一般是由产品所有者根据需求重要程度定的，一般可以通过定性分析达到，通过最重要的两个维度来分析就可以，分别是：用户价值和用户使用频率。任务的优先级要根据所属于需求来定，需求优先级高则任务的优先级也高。使用这种方法，本案例的分析结果如下：
经过分析我们可以得出优先级顺序：
1.应用提醒设计和开发。该任务优先最高，保证该任务优先完成。
2.通知提醒设计和开发。该任务优先级中。本项目应该完成。
3.数据分表方案设计和实现。该任务优先级低。项目时间不够可以不进行。
2.集中资源于优先级最高的需求。
对于优先级最高的需求，项目要足够重视，几种优势资源在核心需求上，充分降低核心需求实现的风险，确保用户能够尽快使用核心功能；项目结束的时候要尽量实现更多的可用的功能，而不是半成品，半成品对用户毫无价值。
3.最终分析结果。
经过分析后，我们调整了策略，最终调整的策略是：
1.应用提醒设计和开发。将原来执行任务3的工程师调整过来执行该任务，确保该任务能够按时完成，同时降低了技术难度，去除了一些对用户影响微小的技术任务。
2.通知提醒设计和开发。按原计划进行，应该问题不大。
3.数据分表方案设计和实现。暂不开始该任务，若项目提前完成，时间足够可以执行该项任务。
4.实际结果。
该项目还在进行中，经过调整之后，大家一致同意该意见，而且大家的信心也倍增。可以预见的是用户的核心需求应用提醒肯定能够高质量的按时交互给用户，通知提醒也应该问题不大。在用户满意的前提下我们尽量做得更好一点，何乐而不为！
总结：
我们公司也在提倡以用户为中心的思想，很多公司都有着顾客就是上帝，全心全意为客户服务，口号谁都会说。说一套做一套的人比比皆是，就像很多官员一样白天在大会小会上强调廉洁奉公，晚上在家大包小包收礼一样，到底怎么样还要看怎么做。所以我们在真正做具体事情的时候还要对照和自查一下，你的行为和决策思路是否真的以用户为中心。敏捷开发思想能够很贴切地符合以用户为中心，因此我强烈推行敏捷开发。