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

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

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

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

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

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

1.1 各种各样的需求

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

• 外部需求：需要配合其他部门的时间节点上线，掌握权可能不在自己的手里；
• 基础需求：包括：历史遗漏问题，bug修复，客户端和服务端的技术优化，基础功能完善等；
• 运营需求：往往和产品本身体验是绑定在一起，并非割裂；
• 体验升级：提升用户体验，功能再优化；
• 全新需求：商业新探索和产品新方向。

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

1.2 验证需求真伪

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

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

1.3 判断需求优先级

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

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

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

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

2.1 团队结构敏捷

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

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

2.2 进度把控敏捷

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

另外，如果有条件的话，开发团队可以选定一个时间进行每日的站会和周会，时间不需要太长，但是可以同步进度，同步信息，分享难点。

2.3 团队配合敏捷

团队配合的紧密性在于，不需要等待每一个流程结束后，才开始新流程。

比如不一定要交互出来再做设计，设计做完，才做前端和后台，版本快完成了再转测试。所有的工作都是可以穿插交替的，交互的同时可以是设计和前端并行，每完成几个story，都可以打包转交互和设计体验，进而转测试。团队配合需要具有灵活性，灵活性仍然需要产品经理来把控。

2.4 工具敏捷

工具是第一生产力，如果公司自己有能力，应该是自己会购买或者开发完整的协作工具，把项目所有相关的信息保留在自己服务器上是最稳妥的。

如果公司团队比较小，不妨使用市面上太多的协作办公的工具，产品可用腾讯在线的文档，刚刚提到的开发进度管理可用TAPD 腾讯敏捷协作平台，交互和设计可用figma或者是蓝湖一类的工具。

这些都是实时在线，开放权限编辑，不管是需求新增或变更，设计变更，团队都可以第一时间掌握。

即使是敏捷开发，但是由于各种意外，例如估算的时间不正确，人手被抽调，技术的评估不准确，甚至是新冠使大家无法正常上班，导致延期发版也时常有发生，灵活变动、快速响应才是真的。

3. 外部力量 | 有钱能使BAT为你推磨

所谓外部力量，就是花钱购买现有的技术支持。各种技术已经相当成熟，例如剪辑，敏感词审核，直播，拍照等相当多的功能已经被网易、腾讯、阿里等集成为SDK或者API进行商业合作。

SDK和API真香

通过使用购买的SDK可以说能够使效率翻新几倍不止，使开发人员在投入新需求上投入的时间和人力大量缩减，加速新功能的上线。

另外，不要忘记对比各个平台的SDK的能力和价格，SDK的不足之处就是会被局限，预想的能力不能被SDK支持，后期开发要么需求被砍掉，要么尝试曲线救国之法，所以购买前一定要仔细阅读官方的SDK具体能力和做好风险预估。

现在大多数公司都做了开放平台提供API接口，和SDK相同，如果有一定的商业合作资源，或者是足够的预算，就可以善用SDK或API，提升产品迭代速率。

END：需求是做不完的，人力是有限的，时间是紧张的，我们如何在有限的人力和时间里面，规划适当的产品策略，作出较为正确的决策，不妨从多个方面去提升效率。

本文由 @舒季  原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议