程序员产品经理打架真相

❶ 干货！程序员需要掌握的几种图

随着互联网寒冬的的到来，程序员就业环境越来越严峻，这就要求我们必须要不断提高自己，来应对高压的工作环境。下面介绍的这几种图是我在工作中经常使用的，所谓的图，都是为了辅助思考的，辅助开发的，比文字描述的更清晰，更有逻辑。
前些年，网上有一个口号喊得很响： “人人都是产品经理” 。这就要求我们需要学习认图、画图的技巧，能从需求文档里快速的抽象出我们想要的东西。最近，网上曝出的程序员和产品经理之间的矛盾，大都是需求不清晰产生的，作为程序员的我们如果掌握的产品经理所必须的技能，那我们以后就可以吊打产品经理了，哈哈哈哈。。。

流程图 是对过程、算法、流程的一种图像表示，在技术设计、交流及商业简报等领域有广泛的应用。

计算机语言只是一种工具。光学习语言的规则还不够，最重要的是学会针对各种类型的问题，拟定出有效的解决方法和步骤即算法。有了正确而有效的算法，可以利用任何一种计算机高级语言编写程序，使计算机进行工作。因此，设计算法是程序设计的核心。

对同一个问题，可以有不同的解题方法和步骤。

例如，求1+2+3+…+100，可以先进行1+2，再加3，再加4，一直加到100，也可采取100+(1+99)+(2+98)+…+(49+51)+50＝100+50+49×100＝5050。

还可以有其它的方法。当然，方法有优劣之分。有的方法只需进行很少的步骤，而有些方法则需要较多的步骤。一般说，希望采用方法简单，运算步骤少的方法。因此，为了有效地进行解题，不仅需要保证算法正确，还要考虑算法的质量，选择合适的算法。

一个计算问题的解决过程通常包含下面几步:

传统流程图

用图表示的算法就是流程图。流程图是用一些图框来表示各种类型的操作，在框内写出各个步骤，然后用带箭头的线把它们连接起来，以表示执行的先后顺序。用图形表示算法，直观形象，易于理解。

美国国家标准化协会ANSI曾规定了一些常用的流程图符号，为世界各国程序工作者普遍采用。最常用的流程图符号见图。

流程图不仅可以指导编写程序，而且可以在调试程序中用来检查程序的正确性。如果框图是正确的而结果不对，则按照框图逐步检查程序是很容易发现其错误的。流程图还能作为程序说明书的一部分提供给别人，以便帮助别人理解你编写程序的思路和结构。

PS：墙裂推荐大家使用ProcessOn，画流程图的神器！！！

心智图 （Mind Map），又称 脑图 、 心智地图 、 脑力激荡图 、 思维导图 、 灵感触发图 、 概念地图 、 树状图 、 树枝图 或 思维地图 ，是一种图像式思维的工具以及一种利用图像式思考辅助工具来表达思维的工具。

心智图是由英国的托尼·博赞（托尼·布詹）于1970年代提出的一种辅助思考工具。心智图通过在平面上的一个主题出发画出相关联的对象，像一个心脏及其周边的血管图，故称为“心智图”。由于这种表现方式比单纯的文本更加接近人思考时的空间性想象，所以越来越为大家用于创造性思维过程中。

ps:我一般都是用的网络脑图，在线的比较方便

拓扑学（TOPOLOGY）是一种研究与大小、距离无关的几何图形特性的方法。 网络拓扑是由网络节点设备和通信介质构成的网络结构图。

拓扑学是数学中一个重要的、基础的分支。起初它是几何学的一支，研究几何图形在连续变形下保持不变的性质(所谓连续变形，形象地说就是允许伸缩和扭曲等变形，但不许割断和粘合) 拓扑图用于计算机网络示意，也就是不考虑计算机实际的位置，只表示网络中每台计算机以及网络设备之间的相互关系。

节点，节点就是网络单元。网络单元是网络系统中的各种数据处理设备、数据通信控制设备和数据终端设备。

链路，链路是两个节点间的连线。链路分“物理链路”和“逻辑链路”两种，前者是指实际存在的通信连线，后者是指在逻辑上起作用的网络通路。链路容量是指每个链路在单位时间内可接纳的最大信息量。

通路，通路是从发出信息的节点到接收信息的节点之间的一串节点和链路。

星型结构的优点是结构简单、建网容易、控制相对简单。其缺点是属集中控制，主节点负载过重，可靠性低，通信线路利用率低。

总线结构的优点是信道利用率较高，结构简单，价格相对便宜。缺点是同一时刻只能有两个网络节点相互通信，网络延伸距离有限，网络容纳节点数有限。在总线上只要有一个点出现连接问题，会影响整个网络的正常运行。目前在局域网中多采用此种结构。

环型结构的优点是一次通信信息在网中传输的最大传输延迟是固定的；每个网上节点只与其他两个节点有物理链路直接互连，因此，传输控制机制较为简单，实时性强。缺点是一个节点出现故障可能会终止全网运行，因此可靠性较差。

树型结构实际上是星型结构的一种变形，它将原来用单独链路直接连接的节点通过多级处理主机进行分级连接。

这种结构与星型结构相比降低了通信线路的成本，但增加了网络复杂性。网络中除最低层节点及其连线外，任一节点或连线的故障均影响其所在支路网络的正常工作。

UML是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。

功能模型， 从用户的角度展示系统的功能，包括用例图。

对象模型， 采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类别图。

动态模型， 展现系统的内部行为。包括序列图，活动图，状态图。

实体关系图，简记E-R图是指以实体、关系、属性三个基本概念概括数据的基本结构，从而描述静态数据结构的概念模式。

❷ 产品经理如何避免被程序员殴打

首先，从做人方面 产品经理还是要以身作则，虽然从职能上就已经决定了程序员和产品经理肯定是有一定矛盾在，不管是谁都是能够相互体谅的。在我做程序员之前，我做过一段时间监理，对于刚刚毕业的毕业生来说，施工队肯定是看不起我这样的小孩的。所以在指出问题 或者 想要检查的要求时，或多或少，他们都会有点反感。这个时候除去交流的技巧外，还要注意要尽可能参与其中，比如你要检查楼顶的设备是否安装完善，但22层的大楼，电梯也没有，这个时候，你就应该和他们一起一楼一楼的爬，只有你参与进来，也付出汗水，其他人才不会说什么。也不敢说什么。产品经理也是如此，对于软件产品的开发，不仅仅只是发号司令，我觉得更应该参与的整个环节中去；
另外，就我本身程序员的身份，我觉得程序员最苦恼的问题，无疑就是需求不明确或者不合理。这个时候产品经理不仅仅要服务好需求方，也应该为后续可能出现的情况做评估，减少需求改动并合理的拒绝一些不能接受的需求。

❸ 产品经理与程序员矛盾的本质是什么

产品的功能、质量、发布时间和需要投入的资源这四者不能都是封闭条件，否则可能无解。需要投入的资源和发布时间一般是大老板定的，所以产品经理、开发经理和质量经理只能在“砍功能”、“降低质量要求”和“程序员加班加到死”这三个选择上相爱相杀了。根源是：高层放卫星玩大跃进，那下面只好群众斗群众了。佛曰：与人斗其乐无穷。对于程序员来说，很多时候问题是 PM 不能证明自己存在的价值。PM 要证明自己的价值有几种可能性：

1、色的产品记录，自己的名字就是个品牌，程序员知道跟着你做事能成功。

2、假会导致产品方向混乱项目失控，这很容易证明为什么你需要存在。

3、通过程序员可以理解的方式把道理讲明白，让程序员信服为什么你管理产品的方法是对的，以及为什么程序员自身不可能做得跟你一样好。

可能还有别的方法让一个 PM 证明自己存在的价值，但如果证明不了的话程序员就会把 PM 看作纯粹的 overhead（额外负担）。PM 对产品团队带来的价值和负担是不可能客观测量的，别人的主观评价是什么就是什么。如果程序员对 PM 的主观评价是负担大于价值，那这个 PM 就没有存在的意义了。核心原因是——好的产品经理永远缺货。当然，优秀的程序员哥哥也缺。既然都缺货。产品经理是决定公司效率高低的关键，产品经理在一个成熟的公司成熟的团队意味着灵魂和中枢，程序员哥哥不过代表着执行力和能力的边界（想不明白就瞅瞅乔帮主马化腾周鸿祎）：1个不知天高地厚的产品经理，2个不经过思考的决策，他的工作量也许只增加了3倍，但他赋予程序员却是10-1000倍的工作量。

❹ 为什么程序员分分钟想砍死产品经理

产品经理是不懂技术的，所以需求方面也不知道工作量有多大，自然在工作中问题会很多，而且产品经理常改需求，这是让程序员不能忍受的。但也没有什么办法，有时候这个需求也是来自老板的。

❺ 有多少人程序员真的接触到高并发，用户量大的系统

一场程序员与产品经理的血案，让我们重新反思，产品经理与设计师，开发工程师到底应该如何配合如何有效的合作，从而达到共赢的状态?珍爱生命，来读读@JingDesign 的这篇文章。 血案!程序员杀害产品经理? 2014年注定是一个不太平的年份，当我们还在纠结于设计师与程序员之间一像素的恩怨情仇，为马航MH370至今还未被找到，亚航另一架飞机又坠入大海而扼腕叹息的时候，今天下午快下班的时候，一则让我们更有切身体会的血案开始在各大设计开发与产品经理群中传开，据传，深圳某办公园区某间公司的五个程序员杀了两个产品经理，图文并茂，血淋淋的案发现场让我们不禁唏嘘和感到惋惜 ( 最新消息为离职员工与老板的劳资纠纷，请以网络新闻为准，如描述有偏差，还请见谅 )。网上一下子炸开了锅，针对产品经理，开发与设计师之间的吐槽此起彼伏。静电的同事–一位产品经理甚至自嘲道，老板，以后要给所有员工买份人身保险，哦不，产品经理要买十份!还有人插嘴：“看见没，以后不要给开发搞那么复杂的需求知道不?要不被xx了可太不值了!” 人人都是PM?产品经理的前世今生 相信很多读者都读过静电的这篇《一像素的恩怨情仇!程序员与设计师的那些事儿》，缘起一像素，开发人员觉得改产品里一像素的错位没有必要，设计师认为如果不改，会影响产品的整个体验，于是问题就来了，一场比电影还要精彩无数倍的故事就这么开始并且无休无止的进行下去了。其实静电忘记说了一个角色，就是产品经理。这到底是一个什么角色呢?咱们先把时间往前调，回到大概2000年左右，那是国内互联网刚刚起步走向繁荣的几年，各种网站及互联网产品层出不穷。但那个时候，还没有真正意义上的产品经理，有的只是刚刚接触这个行业没多久的开发人员和“做网页”的。记得04-05年左右，当时静电所在的公司，没人知道产品经理会是怎样一个角色，大家都凭着某些默契在工作，做网页的做网页，做开发的做开发，搞销售的搞销售，谁有需求谁提，谁来执行。直到06-07年，在做设计的我第一次开始接触产品经理这个职位，那个时候的产品经理多半是在某一行业资历较深的人员担当，相当于半个部门经理。接着，产品经理越来越多的出现在每个人的视野中，不管是初入职场的新人，甚至是设计师和开发工程师，很多人都会在自己职业发展的某个时刻华丽变身为产品经理。可是这个介于设计与开发之间的角色，却改变了每个人的工作方式。每天都跟产品经理与开发打交道的设计师朋友，相信大家一定不会陌生。 我们来看看产品经理的职能： 项目管理35% 个人能力(领导及个人亲和力等)15% 业务能力(业务管理技能)20% 技术能力(技术能力对于产品经理是必备的技能，技术能力让产品经理更好的理解产品的性能和特点，更好的进行产品的团队管理)15% 产品经理的职能中，有很大一部分职能是协调沟通及处理冲突。15% 看过产品经理的职业技能，很多朋友可能要倒吸一口冷气了，如此多的隐性及复合能力让产品经理看起来真的不是那么容易当，这简直就是全才有木有?但不管我们愿不愿意，这个职位在我们的工作中越来越常见。有的没的，经理这么高大上的职位，再加上那本《人人都是产品经理》，又让多少人蠢蠢欲动的做起了产品梦?画个原型图，就是产品经理?也许不是，但我们必须接受，这确实是个不可或缺的角色。静电认为，产品经理在是程序员和设计师中间不可或缺的一座桥梁，或者说是润滑剂，产品经理为产品质量负责，也为各个职位之间加入润滑剂，让整部机器良好运转。 什么仇——程序猿与射鸡师的烦恼 言归正传，说完了产品经理的职责，我们来聊一聊时不时就会出现在我们周围的产品经理与开发，甚至设计师的那些事儿。这三者之间到底真的有这么大的仇，以至于要拔刀相向，兵戎相见?对于设计师与开发工程师，产品经理很多时候扮演的是这种，还有这种角色。 这几张图一定会是大部分射鸡师与程序猿在工作中最真实的写照。所以，我们必须来聊下，程序猿与射鸡师的苦恼(深仇大恨?)，静电总结下，大概就是下面这几类： 催催催：十点提的需求十一点就要，完全没有思考的时间，更别提保证质量了，做完后又要被产品吐槽做的烂没用心。 改改改：今天提的需求明天就来个180°大转弯，写的代码全部白费，做的设计被无数次推翻 指指指：悄悄的问一下各位射鸡师与程序员，你们的屏幕被戳过多少次了?是不是很想摔桌子来一句you can you up! 接着分析各位射鸡师与开发为什么会如此烦恼，原因一定有很多，但静电认为一个最重要的问题就是：在整个工作流程中，你处在流程的最下游，看图： 相信大部分的公司都遵循着这样的工作流程，在没有pm的时代，流程短一些，矛盾相对较少，但由于产品经理的介入，流程变长，产品经理整理与推动需求并由设计师与程序员执行。想想自己在工作中是否很晚才知道上边的决策，产品与其他部门讨论完成了，扔给你照着做就可以的方案，后知后觉，喂，就是说你的!怨念值+1 另外一点，流程变长必然存在目标传达不清的情况，程序员不知道为什么要这么做。大家是否玩过一个游戏：一排人站好，从左边第一个人开始传达一个词语，只能描述或身体表演，下一个人依次描述直到最后一个人，90%的情况下，最后一个人得到的词与答案完全不同。信息的准确度在传达过程中一步步的流失，歪曲，最终产品成为一个四不像。怨念值+1 再者，处在流程下游的开发者无法掌握时间与整体进度。突击工作，成了救火队员，却不知道自己在忙什么，成就感缺失严重。怨念值+1 最后，在加上产品经理的不专业(比如不懂技术与设计的难处，随意修改;没有项目管理经验，执行混乱)，设计师与程序员怨念值几乎爆表。 怨念值爆表的结果大家懂的。执行者要么敷衍了事，要么拒绝完成，抵触情绪严重，态度恶劣也就不难理解了。 说的更直白一点，在下游就出现很严重的问题就是，你丧失了很多的主动权，设计师与程序员大部分时候只是过程执行者，缺乏对过程的掌控以及参与的乐趣，别人说什么就做什么，这样的工作，你会有乐趣吗? 什么怨–产品经理的苦逼与憋屈 用执行者来描述大多数产品经理的身份，相信一定会有很多人赞同。抛开上面5条产品经理必备的素质，更多的人甚至从一毕业就踏上了产品经理的岗位，以最终成为一名优秀的产品经理为目标而努力，静电不置可否。但有一点毋庸置疑的是，处在这个阶段的产品经理大部分为了积累经验值，必然会经历许许多多的磨练，打怪升级以取得进步。无怪乎今天下午看到产品经理血案的时候，群里很多小伙伴的反应居然有那么一点点奇妙(这个是不对的，大家一定要冷静~)。产品经理并不像我们想的那么风光，他们必然会在执行及推动整个项目的过程中跌无数个跟头，被领导，开发和设计师吐槽无数次却毫无怨言(真的吗?)，只不过他们大部分时候情商较高，不会表现出来。看看产品经理苦逼在哪里? 1. 大部分产品经理只是产品的推动者和执行者，很多时候他们无力改变一些固有的现状和决策。 2. 相比设计师，产品经理更应是个杂家，但打怪升级的过程并不会那么顺利切相对漫长，他们需要了解和学习的内容包括但不限于设计，管理，代码，用户体验，市场行情等等等等等等。面对设计师的设计稿还好，指点下江山尚可;但开发工程师会用那高深莫测的技术专业术语让产品经理如同听天书，加上之前的各种怨念，项目执行不下去或者最终效果缩水太大，被用户骂老版骂设计骂开发骂。 3. 老板说要改需求，刚让技术做的项目要推翻，只好厚着脸皮求改，可想而知，免不了又要被骂，诶。 4. 沟通方式不当，态度欠佳加剧开发与产品经理之间的矛盾。 产品经理与程序员——和平共处没那么难 什么仇什么怨?让原本可以避免的悲剧在我们身边以这样的方式发生?本文无意吐槽处在流程中的任意一方，也无意为处在流程中下游的开发人员辩护，但通过以上的分析，相信大家都会或多或少的明白些什么?那我们究竟要如何做才能让事情变的大家都满意呢?在此静电提几点自己的拙见。 开发者与设计师： 与其抱怨或者付诸暴力，不如思考如何通过改进流程与提升自身来改善现有的状况。 1. 停止抱怨，主动沟通，由被动执行变为主动参与项目中，了解项目进行的最终目的及计划，只有站的更高，才能看的更远。不愿沟通，不想沟通，不屑沟通，过于自我的观念存在于很多程序员与设计师的固有意识中，这其实是大部分技术人员的短板所在，也是禁锢很多人发展的一大障碍。 2. 自我增值：不管是程序员还是设计师，都应该留出自己思考与整理思维的时间，通过一系列的自身努力提升自己。 3. 扩宽眼界：程序猿如果还只是埋头于代码，两耳不闻窗外事，那就是真out了，优秀的程序员会非常有兴趣了解并尊重其他同事的工作，比如问问产品经理为什么要进行这个需求，玩一玩用户体验绝佳的网页或app，提升自己的审美，你会发现这一定很有趣。 4. 心理疏导：如今看来，加上这么一条还是很有必要的。如此紧密配合的职位之间必然会发生各种的小矛盾，没关系，大家坐下来一起聊聊，相互沟通与理解，相信没有什么事是大到血溅办公室这种地步的，各个boss，领导们，这个靠你们啦! 友情提醒，这么做必然是违法的哦，不管你再怎么不喜欢给你安排工作的产品经理。 产品经理： 1. 懂点代码，懂点用户体验，懂点审美，你会发现，沟通会如此顺畅，你和程序员与设计师居然可以聊到一起了。 2. 你身边的同事是与你一起同甘共苦并让事情迈向成功的好伙伴，不要冷落他们，适当的时候，邀请他们参与并加入你的讨论会议吧。 3. 善待你们身边的设计师与程序猿，尊重他们的工作成功，即使要指点江山神马的，起码来的温柔点。比如亲王马伯庸就是一个特别温柔的甲方 4. 成为程序猿与设计师之间的润滑剂，他们会感谢你的。 5. 你所经历的一切一定会成为职业生涯中宝贵的财富。 6. 中国人兽最近推出的产品经理高危专属人身保险一定会适合大家，我不告诉你是朋友的朋友的朋友的卖保险的大姨妈告诉我的。 最后为惨剧中离开人世的同行们默哀，什么爱恨纠葛，什么仇什么怨? 生命诚可贵，让这些都随风去吧~ 《产品经理是条狗》歌词送给大家，愿大家都能在工作中找的自己的价值所在。收听地址： 我睡得比猫晚起得比鸡还早/工作在拼体力武器得用大脑/ 左手的PRD右手的产品稿/什么才是你想要我每天在烦恼/ 邮件又来催催催/产品开发累累累/你们永远对对对 我是产品狗我要大声说/产品经理是条狗/ oh狗狗狗GOGOGO/ 除了海贼只剩魔兽女神在梦里游(OHNO!)/ 产品经理是条狗/oh狗狗狗GOGOGO/ 屌丝不哭撸个够也不会放弃加油 如果我的产品让你快乐请摸摸我的头 如果我的产品让你快乐快拍拍你的手 他说加个链接你说搞个按钮/70后的需求90后又没够 实在众口难调想的我快疯掉/这里省掉两万字别再逼我咆哮

❻ 下面这张图 谁是程序员 谁是产品经理

你好。
请问你的图呢？
我在网站上看到的，一般是产品经理带动着程序员，牵动着程序员在走，所以产品经理都是会走在前端，且会大步往前走的。

❼ 产品经理和程序员,如何避免矛盾

产品实现是你的目的，为了这个目的不必太讲究。

做了一阵子之后我有了自己对于与程序员相处的方法论，对这句话并不苟同，我还是倾向于把事做好的同时也能把话说好，虽然我现在也能深刻的领会到当时leader的核心意思是产品本身是第一位的。

接下来我就阐述下自己的一些心得：

• 产品经理与程序员最大的矛盾在于——改需求。这牵涉两个问题，一个是如何尽量地做足前期工作，尽量把需求细化，需求做的足够扎实就会大大减少改需求的次数，这是产品本职工作，不属于沟通问题；另一个问题就涉及如何沟通了，就是需求无论如何确实要改。这个时候有一点很重要就是努力与程序员（或者开发经理）达成共识，比如“我们的目的是要做最好的xxAPP”、“这个功能对于我们的目的来说是必不可少的”等，然后再来谈详细的需求点，程序员也就会逐步认可改需求这件事情。（还有一点很重要的就是，如果无论如何也达不成一致，也有必要反思这个需求是否真的有改的必要？）

• 用数据和客户来帮你增加底气。在谈论某项功能实现的时候，产品经理经常会碰见程序员消极被动不愿意做，或者质疑这么做有没有道理的时候，采取需求依据的数据和真实的客户需求是能有效推进的好办法。比如“80%的同类产品都有这个功能”、“每周都能收到几个客户对某某问题的反馈”，一般来说程序员是能够接受这种说服的。

• 试着多用询问的语气。让程序员感到他是专业的，他是能够解决这个问题的，要依仗他才能做的更好。这会无形中赋予他一种责任感（因为你把问题抛给了他，他就隐形中负有解决这个问题的责任），在传达出意愿的同时也避免了话语的生硬，让程序员感受到对其职业技能的尊重。

• 注重日常交往。日常生活中交个朋友，比如一起打球、打游戏，聊聊电影和漫画，实在是没有共同语言就经常冲他卖个萌、搅个基、撒个娇、讲个笑话。这样，大家都是朋友了，不看工作职责的那一半看交情的那一半，沟通起来也会顺畅很多。

总结：有很多时候产品的产生不完全是靠严格的流程和规章制度诞生的，也需要很多沟通的润滑。能够开开心心地把产品做出来最好，但是最终我们还是不能离开产品实现这个 标的物。

❽ 暴风影音为修复bug杀了个程序员祭天被投诉举报是真的吗

8月25日下午，风影音软件在苹果商店的下载页面更新了最新版本，出现了一段描述为“修复了闪退的bug，还杀了一个程序员祭天”。

之后这张截图在网络刷屏截图引发关注，有网友称其用语轻松，也有部分网友质疑，作为一款软件的官方说明，暴风影音类似表述有渲染暴力意味，甚至有网友晒出截图称，将对其进行举报。

❾ 什么仇什么怨，程序员设计师与产品经理的爱恨纠

哈哈哈，程序员和产品经理可以说是死对头啦。
1、频繁改需求
如果项目经理想要整死程序员，频繁改需求是最快的办法。特别是做了一半硬是改掉需求，scrum里的表现就是sprint内的非受迫需求变更，太狠了，技术同学表示不能忍。
2、拿老板和运营做挡箭牌
不说清需求价值，当技术童鞋问“为什么要做”的时候，支支吾吾，或者说“老板要的、运营要的”。最绝的就是说，这个功能老板说必须要做，那个功能老板说明天就得上……
3、扮用户
程序员会产品经理沟通的时候，比较经常就是听到，“关键字是用户不会这么觉得，如果我是用户。”
这种产品经理通常关注点会有问题，比如更多的时候讨论的是这个按钮是这么颜色，应该放在哪里，文案应该怎么写等，如果把这些问题当做核心，那难免会让人啼笑皆非。

4、口头禅——不就是xxx
有些产品经理口头禅：不就是xxx，这也引来一些程序员的反感。
比如“这个问题不就是在数据库里加个字段就可以解决了吗?你要是没时间，我给你写个SQL 语句，你执行一下吧。”结果程序员一脸懵逼。
其实，如果是在你的非专业领域里，最好少用这种“不就是XXX”这样的句型为妙。
5、不懂装懂
特别是对技术一窍不通的产品经理，会不停让程序员加班赶工。
“开发大哥，我代码写的不多，你可别骗我，这么简单的需求，明明一下午可以搞定，你跟我说一个星期?”
此时，想必程序员口袋里50米大刀已经饥渴难耐......这种产品经理叫程序员哭笑不得。
希望可以帮到你，谢谢！