之前我们讲到了商业目标和用户体验之间的平衡《如何平衡商业目标和用户体验？》，这属于产品和用户之间爱恨纠葛，现在来探讨下一个“平衡问题”，产品开发人员团队内的一些自我平衡问题。

一个产品团队的人力、需求优先级、技术成熟度、成本预算等多方面问题都会与时间节点进行冲突，时间节点是产品永远绕不开的话题，产品不可能在有限的时间和人力里面去开发无限的功能，产品也不可能不受时间控制，准备完全充分了再上线（如果足够成熟有钱，倒也不是没有这个可能性）。

产品始终会向前推进，在一轮一轮的需求评审中，每个矛盾点大都会化解，最后达到一个平衡。需求评审中，产品和开发人员都会相互妥协，产品妥协于时间，开发妥协于饭碗（误）。

这就促使产品经理在整理需求，制定下一个版本计划时，需要有对团队人力和能力的足够认知，划分优先级，能有决策力并且能够说服团队，规划产品井然有序上线，并不能一口吃成一个胖子。

1. 优先级 | 当我们在谈论优先级的时候我们究竟在谈论什么？

大多数时候，接手一个产品，就会发现它不可能是一个完美的产品，基础功能缺失，核心体验亟待提升。即使是较为成熟的产品，也会存在一些历史遗留问题和新的商业探索方向各种优先级问题。

1.1 各种各样的需求

以下简单列举了一些需求的分类，

外部需求：需要配合其他部门的时间节点上线，掌握权可能不在自己的手里；

基础需求：包括：历史遗漏问题，bug修复，客户端和服务端的技术优化，基础功能完善等；

运营需求：往往和产品本身体验是绑定在一起，并非割裂；

体验升级：提升用户体验，功能再优化；

全新需求：商业新探索和产品新方向。

当然以上的需求只是简单列举了一下，还可能有更多更复杂的需求，如何功耗需求等等。透过需求的表象看本质，评估对自身的影响和优先级，也不是所有的需求都需要接，或者是马上着手做，这个就看如何和其他部门协调了。

1.2 验证需求真伪

如果该需求无法验证真伪，无法判断是否是优先，那么就要采取2种手段，方式一内部讨论和评审，没有人比整个团队的成员更加了解自己的产品了，讨论往往会达成一些共识；方式二联合用户研究小组进行定性或定量研究，有助于内部的思考。

所以当我们在讨论优先级的时候，就是在决定产品的未来，将远的未来，只谈长远宏观或只谈现状，都是没有意义的。

1.3 判断需求优先级

优先级的排序和下版本需求规划，就是在做决策的过程，而如何科学地做决策？

可采用的方式是，从几个维度对该需求进行打分，得到总分进行排序。打分的算法不一定是对外的，是帮助自己做判断和思考的，打分也必然是一个相对主观的过程，而这个主观的考量依靠的是自身对产品的了解程度，经验，以及市场敏锐度。所以也会由于自己的判断失误，让团队耗费了大量的时间去开发，最后数据并不一定乐观。

2. 敏捷开发 | 到底什么才算是敏捷？

“快速试错，快速迭代”是这个时代的特征，所以很多团队引进了一个敏捷开发的概念，敏捷开发主要以提升项目周期为核心，使团队结构责任更清晰，项目进度更具有把控性，团队配合更紧密，工具升级提升效率，以下将分别探讨。

2.1 团队结构敏捷

团队结构是否可以更敏捷性，一定程度上取决于公司自身架构，简单来说分为两种：一种是职能部门的架构，一种是模块分组的架构。

模块分组最简单的标准配置是：产品经理+ 交互设计+视觉设计+客户端+服务端+测试，模块分组的结构一般说来在快速响应上会强于职能部门，基本上就是专人专用，多数的评审只需要经过模块组内部，虽然效率提升了，但可能会有一定的局限，模块之间始终会存在一些耦合的情况，另外交互和视觉设计的评审，也需要设计部门进行评审，所以大部分的公司还是以职能部门为划分。但是需要注意的是灵活性，例如设计部门可以评审把控交互和设计大方向，但是不必在一些细节上纠结。

2.2 进度把控敏捷

产品经理需要随时把控项目进度，通常在评审结束后，所有的需求都会拆分为stories。通过在线协作工具（例如：TAPD），可以实现创建Story、变更状态、时间预估、快速编辑信息、分派人员等。快速明确团队成员每人每天的工作量，实现进度的把控。