未来的组织的关键职能，就是让一群Smart Creatives聚在一起，快速地感知客户需求，愉快地、充满创造力地开发产品、提供服务。 —《How Google Works》

关于产品和开发之间的关系，网上有很多描述，因为工作职能的不同，大多数都是“势不两立”、“水火不容”、“杀了一个产品替程序员祭天”等这种类似的论述。今年下半年我开始负责两个产品的产品工作，最开始的时候感觉和开发合作的还是很愉快，但是最近一个月，每次开需求评审会的时候我明显能感觉到和开发之间的关系已经开始发生了微妙的变化，是朝着持续恶化的方向在发展，每次开完会我都要坐下来想想，为什么产品和开发一定要对立呢？

开发方式的不同是产品经理和项目经理是否需要分开的依据之一

我是做硬件产品出身的，硬件产品的项目开发方式一般是瀑布式，一个项目从需求调研到批量上市周期一般以年为单位，产品的生命周期一般也是3-5年。而软件项目的开发方式一般为敏捷式，像现在我参与的两个项目，迭代周期都是一个月，一个月内完成从需求、UI、开发、测试、上线。为什么两种项目的开发方式会不一样，也许从工程师的桌面干净程度不同就能看出些端倪，有机会了专门写篇文章聊聊。

瀑布式开发的项目开发周期较长，需求一旦确定很少会去更改，如果需求要更改就需要走变更评审流程，通过后再来个变更申请、验证、下发过程，慢的十天半个月就过去了，所以瀑布式开发的项目，产品经理和项目经理有时候是一个人，在需求调研评审阶段负责产品经理的工作，立项后负责项目经理的工作，在项目开发过程中也会不断接收市场的反馈、竞争者对手的信息等， 收集产品的下个版本需求。
与之相对应的敏捷式开发，一个项目周期很短，有一个月的有半个月的，它的特点就是短时间内发布一个版本去验证产品是否符合市场预期并为下发版本的需求提供依据。假如产品经理和项目经理是同一个人，开发周期这么短，产品需要的功能和开发想做的功能之间的差异就会被模糊化，比如“平台日志”这个功能，从开发的角度来说直接展示出来就可以了，因为这样对于开发来说开发最简单，客户有问题了直接看日志就可以，后续售后问题也少。但从产品的角度来说日志的内容要进行优化让客户能看懂，或者不展示给用户；而如果产品经理和项目经理分开，产品经理负责需求，项目经理负责组织开发，各司其职，需求、实现方法等放到桌面上大家一起讨论，这样做出的决策更利于产品朝着一个更有力量、更有活力的方向去发展。
而产品经理、项目经理的职责不同也就造成了“两股势力”必然会存在“势不两立”的可能。

工作量和工期是不一样的

工作量是完成一个功能、项目所需要的总工时，估工时除了考虑功能本身的工作量还要考虑到这个功能的前因后果，也就是实现这个功能之前的其他功能是不是有影响，之后规划的功能是不是有影响。工时的预估要考虑的因素较多，包括开发团队的生产率，权重，产品元素的难度系数，复用率等，简单的来说可以以人为依据来估算，我自己的估工时的经验是这样的，工程师会分为助理工程师、工程师、主力工程师、技术专家这几个级别，同样一个功能，助理工程师需要1个月，工程师需要15天，主力和技术专家需要7天。而估工时一般是以工程师或者主力工程师的能力去估算的，取决于当前项目团队成员是以工程师为主还是主力工程师为主。而一般一个项目团队的工程师配比不会特别的畸形，用这种方法估算出来的工时跟实际需要的工时不会有质上的一个差异，一般情况下也是大家都能接受的。这个时间都是项目经理来预估的。
工期是当前这个版本的周期，包括开始时间和结束时间，这个时间取决于当前这个功能的紧急程度或者项目本身设定的开发周期，一般是产品经理来定的。
如果项目上线时间以工作量为主，有可能工期就要延长；如果项目上线时间以工期为主，有可能就会遇到项目资源不够的情况，于是两者的冲突就出现了。

项目的资源永远都是不够用的

当工作量能满足工期要求的时候，大家都是其乐融融的，当工期较紧工作量又大时，冲突就出现了，而大多数情况下都是第二种情况，因为跟“没有BUG的程序是不存在的”一样，没有一个项目的资源是够用的。
项目资源包括人、设备、空间、时间等，我参与过的项目中，资源最充足的是《疫情防控平台》，6个主力工程师用一周时间开发出来并上线运行。这个项目资源充足么？当时的疫情隔离时间是14天，用了7天时间开发就意味着只有剩下的7天可以用这个平台，对于业务来说肯定是不够用的，但是一周的开发时间已经是极限了，也是我参与过的项目中开发时间最短的。资源永远不够用，那项目是如何保证正常交付呢？因为资源都是协调出来的，人不够可以协调其他项目组、其他部门的，设备不够可以买，预算不够就增加，当然这些并不是一味的蛮干，是要项目经理或者职能经理去带领大家讨论、评估、决策的。
比如当前一个功能的上线时间因为某些因素已经确定，估算的工作量又很大，这肯定是有冲突的，那职能经理就带领大家讨论下实现的方法、实现的方式有没有更好的办法，评估再协调几个工程师进项目组能解决问题，做出决策并执行。

态度决定一切

当出现冲突的时候，人的第一反应一定是反抗，产品和开发之间关系的恶化我觉得就是从“一定要按时上线”、“这都是什么xx需求”、“这个功能我做不了”开始的。
最近看了李尚龙的《你的努力，要配得上你的野心》，里面有两个小章节挺触动我的，一个是“远离批评家人格”，另一个是“高手都是反本能的”。作家在写文章的时候都有修饰的成分在里面，但是基本的道理还是通的。
我上家公司有个小伙，刚从学校毕业，我们叫他小蒋，他的口头禅是“你说的不对”、“胡扯”，真的是像书里写的那样，跟他讨论任何技术问题开头一定是这两句，甚至我怀疑他到底有没有思考，慢慢的我就尽量避免去跟他讨论问题，任何问题，因为真的很累，带给我的是满满的负能量，好像我做什么都是不对的，哪怕有一次真的争论赢了也是费了好大好大的力气。所以我们即要远离批评家人格，自己也不要去成为一个“批评家”。
我参与的两个项目，项目Ａ的项目经理，在遇到一个新需求的时候，第一反应永远是这个需要我要怎么去实现，需要用什么技术实现怎样的功能，有没有更好的方法，实现的功能有没有是不是可以比需求里面要求的更好。所以我非常乐意和这个项目团队开需求评审会，因为给我的所有的反馈都是积极的、正能量的，大家对于这个项目是认可的并且都想要把它给做好，我从中也能学到很多很多技术上的知识。而项目B的每次需求评审会就刚好相反，得到的反馈都是“这个功能要做前面的就要改好多东西”、“我做不了不要找我”，虽然都是大家争论到最后的气话，但是明显能感觉出来，项目团队面对需求的第一反应是实现这个功能很困难而不是这个功能要怎么去实现。
认真对待每一件小事，当下可能无法给你反馈，日积月累就会带来不一样的结果，一夜暴富的很多，但没有每夜暴富的，如果有，请你告诉我，我要去学习。
态度决定一切。
“一群Smart Creatives聚在一起，快速地感知客户需求，愉快地、充满创造力地开发产品、提供服务。”与君共勉！