这两天我在很多产品群都看到了同一张图，是一个公司的技术部给他们的产品经理做的规章制度。
说实话，作为一个产品经理，同时也是曾经的程序员，有点无法理解这种脑残行为。
不是说出发点不对，而是方式方法简直是有毛病。
用极尽苛刻的要求再加上现金处罚，对产品经理提出了几乎不可能全部做到的要求。
看了这些要求，有必要为产品经理们说几句公道话！
可能有的读者还没见过这个「规章制度」，先带你们看一下这份神奇的公告。
这份专门针对产品经理的公告，其开头有两个关键词值得注意，分别是「一致」和「公正」。
结合后面的具体规定，实际上体现了大量的不一致和不公证。
至于为什么，我之后会讲。
然后，公告从沟通、文档质量、工作进度三个大方面，给产品经理提出了要求，并规定了处罚金额。
先看关于沟通的规定。
其中第一条，对基础性业务不能掌握的罚款 200 元，这里的「不能掌握」，并没有严格的定义。
什么叫「不能掌握」，如何认定？谁来认定？
如果没有明确定义，这会成为一个空头规定，且会成为某些人的嘴上大刀。
第二条，关于沟通中的避重就轻，不针对问题提出解释。
这种情况确实有，很多产品经理在没有思考清楚的情况下，或者针对沟通过程中出现的临时性问题没有确切答案时，无法回答的情况实际存在。
同样，对「避重就轻」的认定怎么做？谁来认定？
对于这条规定，其实不光针对产品经理，反过来对技术也同样适用。
在需求沟通或者 PRD 评审过程中，很多做技术的同学习惯性用自己的思维与产品经理沟通，直接讲技术逻辑和实现限制，这对非技术背景出身的产品经理其实非常不友好。
并且，当产品经理不理解技术概念和具体逻辑时，有一部分做技术的同学其实也无法非常贴切的解释其中的逻辑。
如果这么看，这条规定是相互的。
第三条，对领导和同事提出的问题要及时回复，这里的「及时回复」又该如何定义呢？
是一小时？半天？24 小时？
没有明确定义，这就不是一个合格的规定，换句话说，这个需求就不成立。
很多产品经理是上午开 PRD 评审会，结束后和设计师核对交互和视觉设计。
下午老板又找过去布置新任务，接着运营或业务又过来提新需求，晚上还要忙着写文档，再加班准备明天的方案。
在这种节奏下，应对多个沟通方而形成的「不及时」，无法认定为工作不合格或者不积极主动。
接下来，是关于文档质量的部分。
第一条，对名词和控件乱用，对文档逻辑不清晰以及功能描述不准确的认定，每次罚款 100 到 500 不等，也是这些规定里罚金比较高的一种。
不过，想问下这个技术部的同学，你们的代码注释都写好了吗？变量取名都规范吗？有用拼音吗？程序逻辑解耦了吗？可复用性高吗？有没有按照公司的代码规范来？
说这个，不是吹毛求疵。产品经理有做得不到位的地方，是需要改进，而且需要重点关注，交付合格的且高质量的文档。
但同时也想问一句，是否存在没有 bug 的系统？是否存在没有逻辑错误的代码？
如果做不到，那就请允许非完美状态的存在。
如果一切都可以用文档解决，那还要沟通做什么？
理想终归是好的，谁都知道什么叫标准化、什么是高质量，但放在客观现实中，有几个团队以及个人做到了？
是大家不想做到么？并不是，而是个体差异以及事物本身的复杂性，一定会出现个体局限性。
如果哪个公司的技术部敢说自己系统里没有一处命名不规范、没有一处逻辑不合理、没有一个地方存在隐藏 bug，我大写的服！
第二条，关于提交素材和文档的一致性，我觉得有点过于矫情了。
为什么这么说？
很多时候，PRD 和视觉设计稿往往存在一个时间差，PRD 评审完后进入视觉设计，为了不影响开发进度，技术会先拿到 PRD 进入开发，等视觉稿出来后再交给前端做页面开发。
交互和视觉设计过程中，难免对原型或者文案做出修改，此时肯定是个原始 PRD 不一致的，为了确保交付质量更高的产品，我们要允许这种时间差带来的差异性存在。
一味的要求一并提交的一致性，那研发进度显然会放慢。
包括在开发过程中，都会随时面临需求的变更，有的来自老板、有的来自用户、有的来自更好的方案。
尤其是老板需求，这种变化作为产品或者技术，又如何拒绝呢？是不是也触犯了这条规定？
这也是为什么很多公司都把「拥抱变化」放在企业价值观里的原因，没有绝对的确定性。
当然，说这些不是给产品经理开脱什么，没做好就是没做好，有则改之无则加勉，但这种规定的推出，并不能解决根本问题。
对于第三点，说白了就是让有问必答，不同阶段的产品经理对知其然和知其所以然的能力不一样，不能一概而论。
对于执行层的 PM，有些需求和决策是直接来自于上层，按他们的认知，很多东西无法理解，按他们的能力，就是做好执行推动工作。
实话实说，用老板的要求去对待一个基层执行者，这个要求是不对等的。
同样，期望是很好的，产品经理们也应该往这个方向去努力，但也要给人留下努力和成长的空间。
如果这么规定，估计没几个产品经理能在这家公司干满几天。
或者，可以请这家公司的技术部同学去产品岗轮岗几天，体验一下就知道了。
非一线者，无话语权！
对于第三部分关于工作进度的内容，我就不想多说了，前两条纯粹是为了满足领导需求。
说实话，就算领导时时刻刻保持对项目进度的绝对掌控，项目就能做好了？
对于第 3 小点，终于看到了一个相对合理的规定，一切以用户价值为依归，对产品经理也是一种鞭策。
最后一部分，是处罚形式，他们采用交警贴条的方式，而且可以申诉。
不过，如果受到两次及以上罚款，即属于严重违反规定，应予以劝退或辞退。
这种手法执行下去，那公司的产品经理估计每一个能幸免下来。
或者说，这是一种变相裁员？
如果按照这个规定，只要在 PRD 评审会上你有一个需求没有讲清楚，加上 PRD 里有一段文案和原型图或者视觉稿不一样，你就会被劝退或开除。
更别说没及时与领导同步需求以及那些可笑的主观认定了。
看完这些，再回到之前的问题，你觉得这是一种「一致」和「公正」么？
不言自明。
有人说，这篇公告最大的亮点在于落款，技术部。
产品和技术存在天然的张力，各自的视角和立场不一样，观点自然也有出入，在产品研发流程中，本来是一种很正常的现象。
有些公司和团队能很好处理这种问题，有的则会演变成一场斗争或者闹剧，很大程度上，这考验的是管理者的能力。
如果以为出了这些制度就万事大吉了，那可真就想简单了。
本是同根生，相煎何太急。
如果你觉得形单影只、力量有限，欢迎各路产品经理们加入我们的组织！
·················END·················
你好，我是唐韧！前非著名程序员，现不知名产品人。写过代码、做过产品、出过一本书，在创业公司厮杀过，也在大厂服役过，如今是一个自由职业者。用产品视角观察世界，用产品思维解决难题，在这里记录自己想表达的一切！
