如何平衡自我能力和产品需求?

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

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

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

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:需求是做不完的,人力是有限的,时间是紧张的,我们如何在有限的人力和时间里面,规划适当的产品策略,作出较为正确的决策,不妨从多个方面去提升效率。

 

本文作者 @舒季  。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部