划分功能优先级，制定迭代规划
文章讲述了进行产品功能迭代规划的重要性，强调了通过优先级排序和阶段性目标设定来优化资源使用、降低风险，并确保用户需求得到满足。文中介绍了几种确定功能优先级的方法，如KANO模型、四象限法则、需求减法以及基于目标用户需求的决策方法。
为什么要做迭代规划？
一般来说，小功能我们没有什么疑义，不做规划问题也不大。大功能就不一样了，那么一大块内容，且不说开发能不能在规定的版本周期内做完。我们在做的时候都会感到隐隐的不安，万一不被用户所接受，岂不是白费了时间；万一做错了，后期改的成本会更大。做好迭代规划，先把最主要、不复杂的功能点做上去，后面再看用户的反馈调整规划，这样我们既能更好的实现功能，又能提高效率，节约成本。
总的来说，规划功能的迭代计划的目的：
- 新功能先试跑一下，不要因为一些决策上的失误，造成很大的很难弥补的损失。
- 已有功能分步进行迭代，兼顾大部分用户的需求，不要一次性占用太多的资源，使得系统发展不平衡。
这是我亲身经历的案例。传统诊所因为就诊量太大，需要叫号功能。调研用户时提出的需求是这样的：
- 患者在前台登记后拿号。
- 患者预约后可以自助取号，缴纳挂号费，和医院一样。
- 医生叫号时大厅屏幕上能看到，患者去就诊。
需求都很常见，但对于我们来说，这些功能的实现还需要和硬件进行对接，这比纯软件的成本又高了很多。我们就先做了第1和3点功能，第二点功能可以先由第1点功能代替。等功能上线了，一些叫着要功能的用户却没有用，为什么？叫号屏幕还需要花钱买，虽然也不贵，两三千块钱，有的诊所也不愿意花。只能说明实际需要远没有叫的那么着急。如果我们当时把自助取号也做上，实际用的人估计只有1-2个吧，因为那个机器更贵，要八九千。那我们的损失就大了。
怎么做规划呢？先给功能排个优先级吧。
如何确定功能优先级？
KANO模型
排优先级很简单，把功能点标个1，2，3，4。可是，怎么定义1，2，3，4呢？有几种模型可以参考一下。
该模型将需求分为三种：基本型需求，期望型需求和兴奋型需求。
基本型需求：必须满足的基础功能，如果不满足，用户根本无法使用。比如上面的登记后取号。如果没有号码，后面都没法叫号了。
期望型需求：用户能够明确提出的希望有的需求，能满足最好，不能满足的话也可以用替代方案来解决。比如叫号时患者不仅可以在大厅的大屏上看到呼叫情况，还能在每个诊室门口看到当前诊室的就诊情况。
兴奋型需求：就是用户也不知道，但有了用户很惊喜的需求，这种需求就要靠我们来想了。比如说用户没有提出需要在微信上通知患者排队情况，我们做了，用户会觉得很好用。
我们基于前面提到的因素将需求划分，基本型需求的优先级应当排在第一位，期望型需求排在第二位，而兴奋型需求则排在最后。当然并不是前期全做基本需求，做完在做期望型和兴奋型需求，因为基本需求是常见的，竞品大都会有的，同质化下难有竞争力，可以每个版本中加入适当的期望和兴奋型需求，参看7:2:1的比例进行版本的需求规划。
四象限法则
时间管理四象限法我们都不陌生，功能优先级排列也同样适用。以重要性为横坐标，紧急性为纵坐标，建立一个四维象限。第一象限为重要且紧急，第二象限为紧急不重要，第三象限为不重要也不紧急，第四象限为重要不紧急。
重要且紧急：类似KANO模型里面的基础型功能，是必须要满足的，在第一次上线时就必须具备，如果不做，产品是一个不能使用的残缺品。
重要但不紧急：类似KANO模型里面的期望型功能，是需要做的，但不是第一次上线就必须要做，可以放到后面积累了一定用户需求量后再做。
不重要也不紧急：可有可无的功能就放弃吧，既然做了不能改善用户的使用情况，也不能增加用户的期望值，就不要浪费精力了。
不重要却紧急：个别用户的个性化需求，因为不能普适，没有那么重要，但那个用户是我们的重点用户，如果不做，可能会导致丢单，或者造成一些其他的损失。
优先级排列起来就是：第一象限>第四象限>第二象限>第三象限。有的人会在第四象限和第二象限的优先级上面纠结，到底哪个更重要呢？我认为是第四个，因为我更关注时间，时间不紧急的情况下，功能都可以慢慢实现。而紧急情况下，不做功能可能会引起直接的损失，这损失还不大好弥补。比如说丢单了，后面用户再来的可能性就很小了。我们认为的不重要，对于用户来说，可能是很重要且很紧急的。
需求减法
我们都做过这个测试题，在纸上写下你认为最重要的事情，比如健康，快乐，美貌，然后一项项的划去，最后留下的才是你真正的最重要的事情。
产品也是这样，我们列了一大堆的功能清单，如果让你一项项的划去，你会按什么样的顺序划？先按场景流程把功能点分下类，每个分类里面把最不重要的划掉，最后剩1-2个最重要的。
比如叫号功能，一开始我列出了这些功能点：
- 给号时间：现场登记给号，预约给号
- 给号方式：工作人员给，患者自助取号
- 叫号操作方式：护士呼叫，医生呼叫，自动呼叫
- 显示方式：显示呼叫过的患者，显示当前患者和候诊患者
根据用户需求的强烈程度，以及实现的难易程度，我把2中的“自助取号”划掉了，然后把3中的“自动呼叫”划掉，再把4中的“显示当前患者和候诊患者”划掉，剩下的就是计划最先要做的。后面再把划掉的一点点加上。
有时候，少即是多，有舍才有得。从产品定位出发，定义边界，把握核心，从众多需求中删减，只做最少、最有价值的事儿。
目标用户需求优先
产品本身是有目标用户的，没有人人都喜欢的产品，在资源有限的情况下，主要做大量用户都需要的功能。我们在调研过程中，可以对所需的功能做个数量统计，大量用户都需要的功能我们就优先做，提的少的就适当延后，甚至不做。
比如2个用户提出需要自助取号的功能，20个用户提出只需要工作人员给号，那我们就优先做后面的。
有时候不是靠一种方法就能制定出优先级来的，我们可以用一种方法定完后，再用另一种方法，换个角度来看，看看之前排的优先级有没有考虑不周的情况。
我们常用的是：目标用户需求优先法和需求减法相结合。提的用户多的，我们就先做。我们会维护用户需求表，统计每个功能点提及的数量，数据还是比较有说服力的。等做出来功能后，我们会通知对应的用户，跟进他们的使用情况，这样至少能保证做出来的功能有人用，有人反馈意见。对于我们后面的规划调整也是有帮助的。
如何做功能迭代规划？
根据上面的优先级划分，我们已经能将需求按照1，2，3，4排列下来，是不是就按这样的顺序做下来呢？不全是，还要看每个阶段的功能目标。
分解功能目标
不同时段的产品，其功能目标是不一样的。怎么看产品是处于哪个阶段呢？
- 种子期：验证用户反馈。一般功能刚开始做，心里也没底，不知道做出来后认可度怎么样，处于验证调整阶段。
- 成长期：完善产品功能。已经证实了用户的需求，切入点是正确的，需要做的更加的深入，使得功能更加完善，更具有竞争力。
- 成熟期：维持现有功能，增加小亮点。市面上的功能都做的大同小异，需要提高性能，维护现有功能的使用流畅度，再做些小亮点，以维持现有用户体量。
- 衰退期：寻找新的增长点。用户使用功能的数量逐渐在减少，很多产品停止更新。可以逐渐放弃迭代，寻找其他的增长点。
产品不一定会按照这个顺序来发展，可能刚处于种子期就进入了衰退期，扼杀在摇篮里面。有时候产品处于哪个阶段，也不能清晰的被认识到，导致计划不正确，错失了发展的良机。常常关注用户使用量的情况，竞品的迭代速度，可以估摸到处于哪个阶段，确定对应的版本功能。
确定版本功能
不同的阶段的版本计划是不一样的，比如：
在种子期
目标是为了做验证，所以一般采取mvp的模式，用尽可能少的功能实现用户需求。主要做基础型功能，不得不做的功能，用需求减法减完后最小的闭环。
还是以上面的叫号为例：登记给号–>护士呼叫–>大厅屏幕显示及语音播报。这是第一步必须要做的，做完后验证下这个需求是不是真的像用户所说的需要。如果做完后根本没人用，那后面就不要再迭代了，如果用户使用量不断在增加，我们会进入下一步。
在成长期
需要产品不仅能运行起来，还需要吸引更多用户使用，要稳定，安全的运行，这时候需要做大量基础型功能和期望型需求，以及部分兴奋型需求功能。
我们会继续完善用户使用频率高的功能：预约后给号，医生呼叫。细节上增加调整呼叫顺序等功能。当这些功能做上去后，常见的场景已经覆盖全了，功能已经处于一个比较完善的阶段了。等竞品也往这块发力，竞争变得激烈后，需要规划成熟期的计划了。
在成熟期
为了稳定现有用户，可以继续做些期望型需求，提高兴奋型需求的比例，获得更多的用户。同时注意一些非典型用户的个性化需求，可以实现差异化定制。这时候一定要注意成本，如果性价比太低，还不如不做。
这个阶段，我们会考虑做每个诊室门口挂一个显示屏，显示当前就诊患者，候诊患者，候诊人数等等，还会做界面的定制显示之类的个性化需求。
在衰退期
当用户的需求量开始呈现减少趋势时，我们可以做一些兴奋型功能来刺激一下，看是否还有逆转的希望。如果减少趋势不可逆转，我们就放弃这个吧，转变方向，找其他的增长点。
比如说后面传统型诊所越来越少，新型诊所越来越多，患者都预约后就诊，诊所不会人满为患，叫号就越来越不被需要了。我们就会逐渐放弃维护，转向做其他符合新型诊所的需求。
需求评审确定可行性
产品想了很多，也从优先级开始，结合着产品周期进行了层层的筛选，最终交给开发一份我们认为需要做的功能清单。开发看完后，可能会说，有的做不了啊。做不了的原因可能是这样的：
- 开发周期太短，来不及。一般公司都会定一个版本更新周期，比如1个月，有的可能就半个月，为的是让用户感知到我们在定期更新系统。如果在这个周期内不能完成功能，我们就需要再简化一下，比如说删掉一些细节点，牺牲掉一些用户体验上的功能。后面再补回来。
- 对原功能改动过大。产品不写代码，不知道代码是怎么实现的，有时候我们觉得改动不大，可能开发觉得改动很大。让他们评估一下，在不影响功能目标的情况下，可以先做改动小的点，再做改动大的点。
- 现有程序框架无法支持。产品能想出来的功能，做不了的很少，但受限于现有的程序框架，可能确实无法实现。如果是兴奋型功能，可以选择不做，如果是基础型功能，就得换个解决方案了。
总结
做好功能的迭代规划，能减少一些决策失误，减少纠错成本，提高开发利用率。
- 可以用KANO法，四象限法，需求减法，目标用户需求优先法来划分功能的优先级。
- 用分解功能目标，确定功能版本，评估可行性三部曲来规划功能迭代计划。
功能的版本计划已经规划好了。下面就要开始具体的设计功能了，交付一份可读性强的需求文档，来按计划实现功能。请看下一章节的功能设计。
没有回复内容