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
1704233956
► Less Testing： 减少测试，或者不重视测试。听到一个很搞笑的故事，某位技术同学写完代码做单元测试，第一次没过，百思不得其解，于是再测一次看看，结果过了，再测，又过了。于是，就认为第一次是幻觉。
1704233957
1704233958
► Skip Error Handling： 不考虑异常情况，直接假设用户都是正常使用（当然，在业务方认可时确实可以这样做）。举一个最简单的例子，输入框没有做安全上限的长度控制，用户可以通过输入过长的内容来直接使网站挂掉。
1704233959
1704233960
► Descope： 偷摸减需求，只做主流程，不做分支流程。不用举例，真的会有，验收时产品经理发现了还好，但只验收主要场景是发现不了的。
1704233961
1704233962
► Less Review： 减少设计评审、代码Review等。强技术的确可以少评审，但会动用Secret Toolbox的同学往往并不是很厉害的人。
1704233963
1704233964
► No Autotest： 不提供测试自动化。工欲善其事，必先利其器，一直不磨刀，整体效率就一直上不去。
1704233965
1704233966
如果对技术缺少敬畏，就会在不知不觉中背上沉重的技术债务。一次交付最终完成，当你看到需求都已满足，心里甚至还会暗爽：就是要逼吧，你看，逼一逼都做出来了，下次继续……但这种理想状况不会持续太久，总有一天你会发现，整个技术团队越来越不愿意承诺，即使承诺也越来越难履行，效率好像越来越低。要么任务经常延期，要么出活越来越少。这些现象表明，用来填坑的时间越来越多。
1704233967
1704233968
直到有一天，技术Leader面露难色地找到你，说：
1704233969
1704233970
“兄弟，业务发展太快了，技术架构跟不上，要重构了。”
1704233971
1704233972
“啊，要多久？”
1704233973
1704233974
“两个月，一大半的兄弟都要参与。”
1704233975
[
上一页 ]
[ :1.704233926e+09 ]
[
下一页 ]