1704233906
人人都是产品经理2.0：写给泛产品经理 [:1704229232]
1704233907
人人都是产品经理2.0：写给泛产品经理 7.4 研发生产时，我们做什么
1704233908
1704233909
本节说的研发生产阶段，是指立项到产品发布之间的过程。作为产品经理，在这个过程中要做些什么事情呢？图7-4是对《人人都是产品经理（纪念版）》里描述项目流程的图略做修改后的结果。
1704233910
1704233911
1704233912
1704233913
1704233914
图7-4 产品经理视角的项目流程
1704233915
1704233916
简单地讲，原型验证完成、产品委员会评审通过以后，要经历立项、需求、开发、测试、发布几大环节，然后再拿着做出来的产品找用户验证，最后做项目总结。
1704233917
1704233918
►立项环节： 即本章前半部分探讨的话题。在这个环节，产品经理要组建团队、设法获取各种资源，以及确定项目计划。在正式开干之前，一般还会开个Kick Off会议，鼓舞一下士气。
1704233919
1704233920
►需求环节： 这个环节主要做的是功能细化，也可以叫需求开发。产品经理要写PRD产品需求文档和UC用例，并和设计师配合做Demo原型。在这个过程中，可能会经历多次评审会议，还要和技术人员一起确定功能细节。以写产品需求文档为例，产品经理一般都不会遗漏主干流程的描述，但是否能把分支流程、异常处理、边界条件都写完整就不一定了。比如，一个搜索结果为空或少结果时怎么处理，会员管理列表中如果一个会员都没有，是否应该全空着，微博用户关注人数达到上限时该怎么提示，等等，都是产品经理需要掌握的基本功。
1704233921
1704233922
►开发环节： 这一环节的主角是开发工程师，他们要做代码方案的设计和评审，然后完成编码和单元测试[6] 。与此同时，产品经理已经开始下一个迭代版本的项目前期准备，这是第08章的话题。
1704233923
1704233924
►测试环节： 开发推进的同时，测试工程师要编写TC测试用例，通过TC评审，并且在系统可用的第一时间做冒烟测试[7] 。此环节中，产品经理要组织功能评审，在第一时间把新产品展示给所有的项目干系人，以确保做出来的东西是大家想要的。
1704233925
1704233926
►发布环节： 测试工作完成后，运维人员要组织发布评审，执行预发布、发布的动作，并且在发布完成后让产品经理到真实的线上环境去验证，以确保产品符合预期。
1704233927
1704233928
为了保证整个过程的顺利进行，产品经理还要把控三件事。一是文档管理： 每个环节的输入/输出文档是什么，用什么模板、工具编写，以及如何保证同步更新等。二是流程管理： 每个环节的各种评审会议，是否可以结合团队实际情况做出删减，突发需求和需求变更如何处理等。三是敏捷方法： 团队日常沟通采取什么方法，如何监控进度，以及如何改进配合模式等。
1704233929
1704233930
上述这些细化需求和跟进研发的工作，产品经理在入行的头两年会经常遇到。我在《人人都是产品经理（纪念版）》的第3章有更加详细的讲述，这里就不再展开。研发生产环节的主角是技术人员，下面主要聊聊产品经理和他们配合过程中的各种注意点。
1704233931
1704233932
7.4.1 产品经理要不要懂技术
1704233933
1704233934
产品经理到底要不要懂技术？这是一个经久不衰的问题，因为在研发生产过程中，产品经理要经常和技术人员讨论细节，如果完全不懂技术，似乎很难沟通。所以，这本质上是一个沟通的问题，标题中的“技术”换成“设计”、“运营”、“市场”等也是适用的。下面，说一下我的理解。
1704233935
1704233936
第一， 底线是可以和技术人员无障碍沟通，并不要求你会写代码。具体点说，技术人员可以直接用平时和同伴说话的方式与你交流，而不用刻意翻译。如果对话过程中经常出现听不懂甚至解释了还是不明白这类情况，很容易让彼此间失去信任，直至没法沟通。当然，和高水准的技术人员配合，会轻松很多，他们更会换位思考，尽量用通俗一点的语言进行沟通。此外，良好的沟通能力和理解能力，也可以弥补专业知识的不足。
1704233937
1704233938
第二， 多向技术伙伴请教，自学一些技术知识。如果你懂一些术语或者会说一些“黑话”，让技术人员觉得“你即使不会写代码，但也是懂的”，会拉近彼此的距离，建立一种自己人的信赖感，这在沟通、协作过程中会有很大的帮助。所以，对于技术出身的产品经理，这点确实是天生的优势，但他们要注意的是不要滥用技术，越俎代庖。一方面自身应该把更多的时间精力用在思考产品层面的事情；另一方面也不应挫伤技术人员对产品的“责任感”与“参与感”。
1704233939
1704233940
第三， 根据所负责的产品，决定要懂哪些技术，懂到什么程度。做技术驱动型的产品，比如Baidu搜索，那必须是特定方向的技术出身，否则很难胜任，而如果你要做一个导购类的App，就相对容易一些。所以，要补哪方面的“技术常识”，最好能先明确将来你要做什么产品，可能碰到哪些技术。
1704233941
1704233942
第四， 要特别关注技术方案与业务场景的关联。有些技术方案的选择会反过来影响业务，这种情况下产品经理最好能给技术人员提出建议。举几个例子：你要知道iOS的开发分客户端和服务器端，能根据业务需要建议数据更新的方案；你要能想到把一些静态素材做成配置文件以方便修改；你要能给出建议，将经常需要改动的那几个页面做成H5页面。
1704233943
1704233944
如果你现在还做不到上面说的几点，也不用担心，我见过很多文科出身的人，经过几个月的痛苦折磨之后，也上路了。文科生做产品，在研发生产阶段确实有劣势，需要有更多的加分项来弥补。推荐关注“给产品经理讲技术”（微信号：pm_teacher）这个公众号，里面的文章用浅显的语言讲解了很多产品经理最需要掌握的技术知识。
1704233945
1704233946
接下来，分别看一点开发、测试、设计、运维等方面的专业知识，用极短的篇幅帮助大家快速摆脱一窍不通的状态。
1704233947
1704233948
开发的 Secret Toolbox
1704233949
1704233950
如果你不被技术人员认可，或者把他们逼得太紧，就容易逼出一系列可怕的大招——开发的Secret Toolbox，下面给大家分享一下。
1704233951
1704233952
► Copy&Paste： 不假思索地“复用”，满足当前需求就好，不考虑逻辑的可扩展。比如，A和B现在1对1，不考虑将来有可能1对N，即使是业务上已经做出提示。
1704233953
1704233954
► Hardcode： 写死代码，不用配置文件和变量。当你发现某个参数不妥，想要多改几次试试时，会发现工作量超乎想象，而且怎么改都改不干净。
1704233955