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

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

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领导主抓的，属于公司战略性的项目”

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

问题三：互相看不上

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

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

1.owner意识

不管你负责整个产品，还是某个方向，甚至一个小活动，你都必须把自己看成这个事的owner，为结果负责。
关心自己的产品，是否对公司有价值，是否对用户有价值、是否对合作方有价值。

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

就拿陌陌APP来做一个分析

需求的层次

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

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

可行性

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

• 技术可行性：竞争对手功能比较，研究同行业有多少类似产品，有哪些功能、功能异同点。通过竞品分析可以了解对方技术特点、产品特点、发展空间、市场行情、用户喜爱程度及我们的突破点等信息。　易用性及用户使用门槛，产品的易用性，用户群体分析，产品是否会有使用难度。
• 经济可行性：人力成本，产品从调研、分析、设计、开发、测试、运维等需要多少人力，多少人月，每个人月平均成本是多少。市场开拓、广告、运营成本，产品投放市场后的推广、营销方式，需要的推广、营销成本，广告成本等。
• 社会可行性：道德方面、法律方面、社会方面，社会影响力，通过产品的推广，产品将会给公司带来哪些社会效益，增加多少社会影响力。

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

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

上图是一个MVP的周期，有没有觉得似曾相识，没错MVP和敏捷开发有异曲同工的作用。

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

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

大家都嗑过瓜子，嗑瓜子，因为是嗑一个，吃一个，反馈的周期很短，差不多两秒钟瓜子就能到嘴里了，所以不觉得累。而工作学习的反馈周期就很长了，你不知道你学的这个东西什么时候才有提高，什么时候才能派上用途。

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

我们的在校学习，因为距离实践太遥远，所以反馈周期太长，导致我们疲乏，不愿意迷茫的学习，凭着自律性去学习，导致学霸很少、学渣很多。

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

4.总结复盘

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

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

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

5.对自己负责

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

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

信息对齐

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

• 1.对自己的工作内容或者说业务很熟悉；
• 2.善于总结所有的工作过程中的每一步;
• 3.善于向过来人去请教经验.

原则对齐

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

利益对齐

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

## 结束语

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

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

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