程序员必备技能-科学砍需求

关键词: MVP 最小可实现产品 砍需求

做为码农在电商圈、O2O、互金行业和产品需求纠缠了多年，作过一些好的产品需求，也作过不少失败的产品需求，好的产品需求即便不成也何尝不是一种探索尝试，结果应该是让人有所收获的。好的产品逻辑清晰，产品价值明确，有效的解决了一部分问题，经的起团队各方的挑战。反之产品经理需求没想好，边界条件没想清楚，最后需求被砍，不光程序员时间白白浪费，配套的设计资源、测试资源甚至运营资源都要打水漂。砍需求若是没有一套可参考的标准，双方“讨价还价”可能就显得失去了正义的立场。

我会持续分享一些知识整理，若是文章对您有帮助记得点赞鼓励一下哦😁~，也能够经过邮件方式联系我

文章列表： juejin.im/user/5bc8b9…

邮箱地址: 595506910@qq.com

目录

• MVP
• 找出问题
  • 问题一：需求不清
  • 问题二：倒排的项目
  • 问题三：互相看不上
• 研发如何思考最小可行性产品方案
  • 1.owner意识
  • 2.找到最小可行的产品需求
    • 需求的层次
    • 可行性
  • 3.对项目进度、项目质量负责
  • 4.总结复盘
  • 5.对本身负责
    • 信息对齐
    • 原则对齐
    • 利益对齐
• 结束语

MVP

MVP就是一种科学砍需求的方法。咱们先看一下什么是MVP。 MVP（minimum viable product，最小化可行产品） 概念最先由硅谷创业家Eric Rise提出，刊载于哈弗商业评论，并有出版物《精益创业》-书中提出了“精益创业”（Lean Startup）的理念，其核心思想是，开发产品时先作出一个简单的原型——最小化可行产品（Minimum Viable Product, MVP）， 快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以知足产品部署的要求并可以检验有关客户与产品交互的关键假设。而后经过测试并收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。

MVP的目的——更快的接触客户 按照常规的开发方式，从调研、到设计、到开发再到推向市场，会是一个漫长的过程，并且很难有人会保证成功率。但当换一种方式，以MVP进行小样调研，快速进入市场、接触客户并获得反馈。透过反馈不断修改原型，并进行不断地的迭代开发，极大减小了试错成本。

MVP很是适合互联网产品，下面我分析一下常见的问题产品需求，如何制定一套MVP砍需求的方法来应对。

找出问题

若是PM有如下情节的可能会引发程序员的不适，牙根直发麻，手指骨节痒，想揍他一顿

1. 先作出来看看吧
2. 我就要这种效果，怎么实现是你的问题
3. 这应该很简单吧，不就是XXX，而后XXX吗
4. 这个需求，先这样这样，再那样那样，用XX技术很快就搞定了
5. 你就说能不能作吧
6. 我有一个绝妙的idea，什么都准备好了，就差一个写代码的了
7. 这个需求老大已经赞成了，你照着作就是了

以上情节只要出现3条及以上，程序员不打你PM，那你真的很幸运。

经典案例：

这个案例完美的承包了上面所说的7中情节，出现打架状况实属正常。面对这种极品PM，我想不出更好的反击方式。

问题一：需求不清

首先产品经理应当把需求讲清楚，经过需求评审会让与会者清晰的了解需求是什么，需求从哪里来，对现有业务有什么影响，预期收益是什么； 让技术及测试对产品方案有详细的了解，以便后续开发更高效，没有谁愿意在后续的编写测试用例及开发阶段再去反复沟通确认，毕竟那是很是低效的作法，固然，特殊状况除外； 让与会者清晰的知道本身在整个方案落地过程当中处于什么位置，职责是什么，须要作什么，准备什么，提供什么帮助，对各自负责部分的实现难度及排期有必定的心理预期； 评估产品方案的技术难度及实现周期，一期实现，仍是分期实现，投入产出比怎么样？毕竟互联网产品讲究小步快跑，快速验证迭代，怎么样权衡产品设计（用户体验），技术成本以及商业利益是产品经理主要工做之一。

问题二：倒排的项目

“这个需求是XX领导主抓的，属于公司战略性的项目”

• 一般听到这句话，心里是狂躁的，尼玛又拿老板压迫劳动人民。
• 首先要认可一般状况下高层眼界比较开阔，未必全部的事情是全部人都理解才能开始作。
• 试错机会，若是项目最终失败了，最重要的是收获告终果，但风险我要提早讲出来。
• 跟本身的上级沟通项目细节，让老板帮你背书工做。
• 若是一个公司所有都是这种需求，要么就是这家公司处在特殊时期，要么就赶忙闪人吧

问题三：互相看不上

程序员和产品经理之间的矛盾，主要缘由无非就在两方常常有矛盾出现，而矛盾出现显然是由于双方一边是需求提供方，一边是需求实现方。一般发生的状况是，产品经理不懂技术规则乱下需求，而程序员自恃技术在手，不尊重产品经理的创做用心，双方天然互看不爽，都以为对方没资格跟本身合做。另外一方面，须要投入的资源和发布时间是固定的，因此产品经理和程序员只能在“砍功能”、“下降质量要求”和“程序员加班加到死”这三个选择上“相爱相杀”了。

研发如何思考最小可行性产品方案

link

1.owner意识

无论你负责整个产品，仍是某个方向，甚至一个小活动，你都必须把本身当作这个事的owner，为结果负责。 关心本身的产品，是否对公司有价值，是否对用户有价值、是否对合做方有价值。

2.找到最小可行的产品需求

就拿陌陌APP来作一个分析

需求的层次

• 核心功能：陌生人之间的社交
• 基本功能：短视频、直播、游戏、交友；经过人群聚类解决宅男宅女、缺乏生活社交的一群人的社交问题
• 用户指望功能：陌生男女由陌生到熟悉的过程
• 超出预期的功能：留言档（陌生人也能够留言）,留言档只能够看最近的8条状态（保护了我本身的信息，却勾起了陌生人想要跟我交流的想法，留存了老用户，勾引来了新用户，而且还激励了活跃度）消息的读取状态（能够清晰的明白，咱们发出的消息，对方有没有阅读了，凸显了咱们发出消息的目的性）, 隐身（关闭咱们的距离，可是却可让别人看到我是隐身状态，给我一个保护，给陌生人一个期待）
• 潜在功能：社交+ 电商、游戏、O2O 这个就比较多了，这里不就列举了

核心功能和基本功能就是这款APP的最小产品需求部分

可行性

产品的可行性，须要从三方面考虑：技术可行性、经济可行性和社会可行性。

• 技术可行性：竞争对手功能比较，研究同行业有多少相似产品，有哪些功能、功能异同点。经过竞品分析能够了解对方技术特色、产品特色、发展空间、市场行情、用户喜好程度及咱们的突破点等信息。 易用性及用户使用门槛，产品的易用性，用户群体分析，产品是否会有使用难度。

• 经济可行性：人力成本，产品从调研、分析、设计、开发、测试、运维等须要多少人力，多少人月，每一个人月平均成本是多少。市场开拓、广告、运营成本，产品投放市场后的推广、营销方式，须要的推广、营销成本，广告成本等。

• 社会可行性：道德方面、法律方面、社会方面，社会影响力，经过产品的推广，产品将会给公司带来哪些社会效益，增长多少社会影响力。

最后才是找出产品需求和可行性的交集部分。小的产品需求要考虑的层面和这里所讲的可能差异比较大，这里只是抛砖引玉的梳理一下思路。

3.对项目进度、项目质量负责

上图是一个MVP的周期，有没有以为似曾相识，没错MVP和敏捷开发有殊途同归的做用。

向进度落后的项目中增长人手，只会使进度更加落后。——《人月神话》

可见项目进度管理是多么的重要。需求过多形成开发周期过长，必定要果断的分阶段。

你们都嗑过瓜子，嗑瓜子，由于是嗑一个，吃一个，反馈的周期很短，差很少两秒钟瓜子就能到嘴里了，因此不以为累。而工做学习的反馈周期就很长了，你不知道你学的这个东西何时才有提升，何时才能派上用途。

作一件事情，反馈的周期越短，越有可能上手。而一件大事情，咱们也能够把它拆分红一个个小事情，而后给予每个小事情一个短周期的反馈，这样咱们作起来难度就小多了。

咱们的在校学习，由于距离实践太遥远，因此反馈周期太长，致使咱们疲乏，不肯意迷茫的学习，凭着自律性去学习，致使学霸不多、学渣不少。

判断好优先级、性价比、重要紧急程度，在项目初期打下一个基础，明确能作的部分和可能的风险，才有可能完成整个项目。

4.总结复盘

技术人员在团队中的价值除了技术层面还有综合能力方面的价值，尤为是软素质。能较好的完成任务，还要解决好各个环节的异常问题，只有技术是远远不够的。

最核心的是自驱力，是一我的内在的东西。 咱们说一我的是不意愿成长，一我的是否是自律，指的就是他的自驱力，自驱力是一我的成长的源动力，自驱力好的人后面发展的潜力也会比较好。

总结复盘的能力，项目上线后要及时关注数据，要和以前定下的指标去对应。对项目中产生的问题要及时的总结经验，复盘的目的是从以前的经历（多是成功的经历，也多是失败的经历）中总结可供指导后续工做的经验。一我的的能力就是这我的过去全部成功经历的总和。总结复盘的方式也多种多样，但万变不离其宗，主要仍是围绕下面几个内容：目标回顾、进展评估、缘由分析、经验总结。

5.对本身负责

一个产品设计的价值 = 所有TPU价值的加和，参与产品设计环节、体现自我价值。

砍需求不免会遇到各类分歧，如何应对呢？ 我总结有下面三个层次：

信息对齐

信息对称是一门很大的学问题，经济学家米尔利斯和维克里因研究这一理论而获诺贝尔奖。这是工做中最基本的部分，掌握更多的信息能够增长我的在职场中的价值壁垒，从而赢得更多的话语权。 要想保持本身的优点起码要作到如下3点：

• 1.对本身的工做内容或者说业务很熟悉；
• 2.善于总结全部的工做过程当中的每一步;
• 3.善于向过来人去请教经验.

原则对齐

若是不能经过信息对齐解决问题，那么就要考虑一下原则部分，公司使命、产品价值等等， 你们的目标应该都是想作出一款好的产品，只要基于这个原则去探讨问题就容易找到答案。

利益对齐

产品作得好了，你们都有功劳，该晋升的晋升，该分钱分钱，该团建团建。你们都知道跟你作事不吃亏，时间长了，靠谱的人会愿意持续跟你配合，你的口碑和职场信-誉也就创建起来了。 最好的方式是让参与的人有共同的利益，这事成了，你们都获利，而不仅是单纯的部门之间工做配合或者帮忙而已。 但若是总想着利用别人，占点便宜，也许一时能够，长久都是不奏效的。

结束语

本文从MVP方面进行了一次拓展式的思考，砍需求不是目的，作成好产品，体现我的价值，使本身的职场路径能更加稳健才是我想和你们探讨的问题。

固然，MVP也并不适用于任什么时候候。MVP模式的问题在于，它并不老是开发颠覆性技术的最好办法。若是乔布斯发布的是最小可用的 iPhone，咱们是否是会得出结论说你们更喜欢键盘？若是 Tesla（电动车）制造的是最小可用汽车，还有没有人去开它？由于与 web 服务不一样，就好像不可能有人会花几万块买一辆最小可用的车同样，硬件不是免费的，并且不能快速方便更新。固然，这不是＂最小可用＂理念自己的问题，只是有些市场不合适。产品到底能够作到多好或者作到什么程度最好？答案或许永远也找不到。这种模式也不必定就是作大事情的最好方式。有些产品是小调，有的则是交响曲，而有时候你仍是要先让音乐演奏起来。

行文仓促，不免以偏概全，欢迎各位斧正！

补充

---

2019-06-13 补充：

重温俞军的3条核心产品方法论

告别滴滴之际，重温俞军的3条核心产品方法论

从12条军规缩减到3条

1.PM首先是用户；
2.站在用户角度看待问题；
3.用户体验是一个完整的过程；
4.追求效果，不作没用的东西；
5.发现需求，而不是创造需求；
6.决定不作什么，每每比决定作什么更重要；
7.用户是很难被教育的，要迎合用户，而不是改变用户；
8.关注最大多数用户，在关键点上超越竞争对手，快速上线，在实践中不断改进；
9.给用户稳定的体验预期；
10.若是不肯定该怎么作，就先学别人是怎么作的；
11.把用户看成傻瓜，不要让用户思考和选择，替用户预先想好；
12.不要给用户不想要的东西，任何没用的东西对用户都是一种伤害。
复制代码

新三条

1.产品价值分析法：产品价值=(新体验-旧体验)-换用成本
2.用户样本量：用户即需求，用户是天然人的某一类需求，用户不是天然人，随着内外部场景变化会发生变化。
3.怀疑精神：自我迭代。
复制代码

O2O平-台是各类店铺管理方式的统一整合，而且创造出不一样的新方式。B端的上单管理，行业、套餐、优惠策略、服务时间等人为管理方法改为统一的流程式管理。

---

2019-06-18 补充：

工做量评估方法

为每个活动和整个工程的工做量作一个最初的评估。有不少可用的技巧用于评估工做量，包括任务分解（工做细分结构）、专家意见、类推等， 大型项目工做量评估过程：

1. 梳理产品需求和交互,接下来的工做本身作或着分工让别人去作都要可以讲清楚逻辑
2. 方法论意识：创建几种文档，涉及到的系统列表，串联业务的流程图、每一步各类状态表格，总分和细节都能覆盖到。像埋点、监控这类必要的工做应直接预留在模板中。
3. 完善产品方案：多留疑问，尽可能多的扩展问题，避免上游遗漏的需求，形成最后的工做量失控
4. 粗略工做量评估（叫‘初估’比较好一点）：必定要有一版粗略评估，PM也不能保证需求充分考虑以及不会变动和增长需求，细节都交给RD完善呢，好意思要精确的评估工做量？ 没有工做评估这一说,只有粗略工做量评估和较精确工做量评估这两种，要让PM知道本身要什么。
5. 添加意外事故时间：必定不是全部的需求评估时都有解的，这些不可控的因素会有临时变更，风险是要讲出来的。时间越长可变系数越大，人员离职、临时请假都有可能影响项目进度，这种状况是无法对外要求项目延迟的，只能本身把控好。
6. 方案产出逻辑梳理而且文档化：要确保你的评估看起来是合理的，而且准备好反击那些反对的观点。文档化全部设想。你永远不会确切地了解一项工程的全部细节，所以，文档化全部你作出的设想和评估，这一点很重要。

---

2109-06-20 补充

不可能三角

没戏，作不到，不存在的“不可能三角”

• 设计领域：好看，便宜，快速
• 项目管理：TQR，时间，质量，资源
• 投资领域：收益，风险，规模（即容量、流动性）
• 区块链领域：安全，效率（即环保，低耗能），去中心化
• 运动摄影领域：快门，光圈，感光度
• 钱多 活少 离家近
• 位高 权重 责任轻
• 要马儿跑的快，又要马儿不吃草（全部有了广告：高效率、低能耗）
• 古典的说法就是——有得必有失，鱼与熊掌不可兼得。