上一部分（点击查看）我们围绕着书中表述：产品应该是有价值的、可用的、可行的，这三个方面简单说了一下“探索定义产品的流程”和简单介绍“敏捷办法”。这一章，我们将点出“探索定义产品”中的重要细节和开发中问题，还有敏捷方法与瀑布式方法的详细介绍。
我们之前提到的探索产品的方向需要有以下几个工作：
1）需求调研 2）市场调研 3）产品人物角色。
一、首先需求调研大家都懂，我们会自己提出需求，也会从上司或者同事得到需求，还会从用户调研中获取用户的需求。但这个时候，产品经理心里一定要清楚，我们只是获取需求，而并不是一味的被需求“教导”。
我们来分析一下从各个角色提出的需求都各自带有什么特点：
1）boss/老板：上司和老板提出的需求，一定是符合老板心中的商业目标和长远规划的，他不会考虑此时适不适合做，能不能做。
2）运营/销售：运营、销售提出的需求，大部分是来自消费者的需求，而消费者的需求往往是他的个人想法，不能代表全部，还有一部分可能是为了完成某种kpi指标，比如说要把某一个商品放在首页，频发的增加广告等。
3）用户：用户需求对我们来说是最重要的需求，但是大部分用户都会“撒谎”，因为用户往往是最迷茫的一个，他不清楚自己针对产品，最希望得到的是什么？甚至很难凭空想象出你的产品是什么样的。而且用户想什么，跟做什么往往是不一样的。举个例子：用户在商场买一双鞋，她吐槽这双鞋，这里不好，那里不好，但是她却一直拿着那双鞋，这说明不是鞋子不好，可能就是太贵了。
二、市场调研有跟需求分析相似的地方，这里我们着重说市场分析的方法之：用户研讨会
用户研讨会既可以获取用户需求，也可以侧面反映市场接受情况。用户既是市场。但是用户研讨很难讨论出成功的产品，因为：
1）用户不知道自己的想法是不是可行的，多数用户对技术一无所知。
2）用户不知道自己想要什么，在没见到真实产品之前，用户很难凭空想象自己想要什么。
3）人群聚集的时候很容易冲动，互相影响，很难获取到每个人的想法，取而代之的是那些善于表达者的一家之言。
这些问题告诉我们，一个好的产品经理，不但要熟悉组织技巧，随机应变，还得掌握产品领域的知识，擅长引导话题，产品经理在听取各种“用户”需求的时候，要挖掘他们内心真实的渴望。要记住，我们才是产品的主导者，我们只是听取用户的意见，或者说分析用户的言语和行为，来挖掘意见。
三、在我们探索定义产品的过程中，还有重要的一个工作：设计产品（用户体验设计），问题来了，我们该在什么时候设计产品呢？
作者认为，用户体验设计应该在开发之前完成，且和需求调研同步进行，理由如下：
1）用户体验设计和需求调研是互相影响的。
2）我们要清楚一点，一旦产品进入开发阶段，在修改设计是很难的，且代价沉重。
3）交互设计验证要使用“高保真原型”，原型可以随意修改，在进入开发阶段可以丢弃。但是程序不行。
4）用户体验设计远没有开发耗时。 （但至少需要一两周的时间）
在敏捷方法里有一个名词叫“第零次迭代”，产品经理和设计师利用这个时间完成产品设计工作，之后在交付于开发人员开发。
四、完成了产品探索阶段和交互体验设计阶段，我们已经确定了“基本产品”。什么是基本产品？
作者认为产品团队应该放弃老的产品设计方式，比如，不在企图定义最终产品，转而定义只满足基本要求（价值、可用、可行）的基本产品。一旦基本产品定义完成，不可增加，也不可删减，如果可以删减或者增加，那说明你定义的不是“基本产品”。
五、如何设计基本产品：
1）产品与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的基本功能要求，以及良好的用户体验和吸引力。
2）邀请一位开发人员，帮助设计原型，检验原型，指出设计上的误区。
3）基本产品验证测试。
六、这里又出现一个问题：如何验证基本产品：
1）可行性测试：首先要确认在现有的技术条件下，能否成功开发出产品。邀请构架师和开发人员深度参与技术调研。提前评估技术风险，远比损失了时间和资金后发现问题要好。
2）可用性测试：交互设计师与产品经理合作设计的产品要让不同的用户都明白如何使用，最重要的是邀请真实用户验证产品的可用性。
3）价值测试：同样邀请真实用户进行测试，但与可用性测试不同的是：前者重在观察用户如何设法完成必要的操作。后者是观察用户是否喜欢这些功能，是否满意功能的具体实现方式。
七、验证基本产品的重要工具是“高保真原型”，但是目前很多公司还是拒绝这样做，原因是太麻烦了浪费时间。这种观念是错误的，原因有三点：
1）相比于过去，当下制作高保真原型的工具很多，成本不高，耗时也短，我们没有必要去选择差的。
2）如果产品团队在低保真原型的基础上开发产品，最终产品质量可想而知。
3）高保真原型可以提前测试，如果等到产品做完在测试，发现问题后，修改的难度和成本会越来越高。
八、如何进行原型测试：
1）物色测试用户 2）准备测试（测试内容）3）测试环境 4）测试原型 5）更新（修改）原型
我们捡最重要的一点：测试原型（技巧、方法）
1）测试前不要跟测试者寒暄过多，简单交流几句，开始测试。
2）我们必须让测试者明白，这只是原型，初步的产品创意，不是正式产品。
3）尽量让测试者保持平和的情绪，不要让他进入吹毛求疵的状态，测试的重点是看测试者能否轻松完成测试功能，以及他们是否喜欢产品的功能。
4）测试时尽量保持安静，不要给测试者提示。
5）测试通常有三个结果，第一、测试者没有提示的情况下顺利完成测试。第二、测试者遇到麻烦、经过反复尝试，最终完成测试，第三、测试者放弃，在测试者提出放弃时，我们可以鼓励他们继续尝试，如果不接受，那说明他们真的放弃了。
6）鼓励言语，侧面“提示”用户继续。
7）从用户的言语和表情中获取有用信息。
通过以上的步骤，我们完成了“基本产品“的定义，这时候再去给开发人员开发，开发出1.0版本。这个时候才能说真正的做出了一个产品，产品出来，肯定后续需要改进。那到底什么是改进产品？如何去改进呢？
十、往往大部分公司产品发布后，马上紧锣密鼓的设计下一版本的需求和功能，这样产品团队就像一个功能加工厂，说白了，就只会一味的给产品添加新的功能。我们不妨思考一下，公司改进产品的目的究竟是什么？
提高指标（赚钱），没错，公司改进产品的最终目的就是这个，大部分产品经理改进产品的目的都是：想让我的产品更酷，花样更多，功能最炫，这样的产品经理只考虑了自己，并没有站在公司和用户的角度上思考问题。
产品发布后，会有各种数据指标给产品经理参考，好的产品经理一定非常关注这些数据，因为这些数据能告诉我们如何去改进产品，有可能影响指标的是用户体验，是性能，而不是功能的多少。
说到改进产品就不得不提产品的更新迭代，作者这里提到”平滑部署“很重要，因为我们不得不承认，用户不喜欢改变，不喜欢更新。
十一、平滑部署的措施：
1）通过公告、群发邮件等提前告诉用户。
2）加倍做好测试工作，确保更新的版本是没有问题的。
3）并行部署（同时运营新、旧两个版本）增量部署（一步一步来，别一口气吞胖子）
4）不要频繁更新迭代。
十二、快速相应阶段和开发余量
1）产品发布后不等于大获全胜，仍然要保持高度警惕，这时候需要延长一周到两周的项目周期作为快速相应阶段，这段时间的主要工作是快速相应、处理产品发布后的用户反馈意见，和bug。
2）随着产品不断的”壮大“，可能原来的代码，和表设计，不足以继续支撑目前高标准、高性能的功能，和庞大的用户。因此作为产品经理，这一块也是我们需要未雨绸缪的地方，作者建议，当到达每个里程碑阶段的时候，在项目周期多余出百分之20的时间，让开发人员自行调整，去重构代码，提高性能。
十三、敏捷方法（十大秘诀）：
1、产品经理是产品负责人、它代表了客户需求，产品经理需要跟开发团队保持密切的联系，督促开发进程，及时解决问题。敏捷办法里对产品负责人的要求更多。
2、敏捷方法不等于省略产品规划。只是在敏捷方法里规划周期应该适度缩短，反复迭代。采用轻量级的机会评估方法代替冗长的市场需求文档。
3、产品经理和设计师的工作进度应该比开发团队领先一到两个迭代周期，确保你们有足够的时间攻克难题，千万不能一边设计一边开发。
4、在敏捷环境里，设计师必须加快速度，采用迅速制作原型方法适应敏捷环境。
5、产品经理的主要任务是定义有价值的、可用的产品原型和用户故事（场景）代替厚厚的产品需求文档和功能说名文档，让用户可以先测试原型。
6、让开发人员自主划分迭代周期，开发团队必须考虑到产品的质量、性能、扩展性，所以应该让他们自行决定如何划分迭代周期。
7、产品经理和设计师必须出席每天的晨会，设计师向开发人员和测试人员展示产品功能，开发人员互相展示完成的代码，让产品和测试过目。
8、除非达到产品经理的需求，否则不要轻易发布新版本。
9、每次迭代完成后，产品经理应该向团队展示产品现状，让大家看到工作成果，同时加深大家对产品的理解，增强团队信心。
10、敏捷培训
十四、瀑布式开发方法（扬长避短）
优点：
1）瀑布式开发方法流程具有可预测性，因而深受管理层欢迎。只要能准确理解需求和技术，而且需求不再变更，开发团队就能为大规模的、复杂的项目制定精确的开发计划。
2）每个阶段结束时都会提交书面材料，这些材料从一定程度上增强人们对项目的信心。
缺点：
1）最严重的问题：产品经理必须等到产品软件开发的尾声，才能看到可以运行的软件。
2）在瀑布式开发过程中，任何对前期决策的修改都会打乱开发计划，大量工作要从头来过，不仅浪费资金，还耗费经历。
3）瀑布式方法严重依赖文档和流程，在这方面开销很大。产品经理必须确保每个环节都准确无误。过于理想化。
网友评论