程序员讨厌大公司开会

⑴ OA573网购项目组主要工作内容是什么

项目组管理2008-02-04 13:23 1. 你们的项目组使用源代码管理工具了么？
应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
2. 你们的项目组使用缺陷管理系统了么？
应该用。ClearQuest太复杂，我的推荐是BugZilla。
3. 你们的测试组还在用Word写测试用例么？
不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
4. 你们的项目组有没有建立一个门户网站？
要有一个门户网站，用来放Contact Info、Baselined Schele、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。
5. 你们的项目组用了你能买到最好的工具么？
应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。
6. 你们的程序员工作在安静的环境里么？
需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。
7. 你们的员工每个人都有一部电话么？
需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。
8. 你们每个人都知道出了问题应该找谁么？
应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。
9. 你遇到过有人说“我以为…”么？
要消灭“我以为”。Never assume anything。
10. 你们的项目组中所有的人都坐在一起么？
需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。
11. 你们的进度表是否反映最新开发进展情况？
应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schele，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
12. 你们的工作量是先由每个人自己估算的么？
应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。
13. 你们的开发人员从项目一开始就加班么？
不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。
14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？
不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。
15. 值得再多花一些时间，从95%做到100%好
值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
16. 登记新缺陷时，是否写清了重现步骤？
要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。
17. 写新代码前会把已知缺陷解决么？
要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
18. 你们对缺陷的轻重缓急有事先的约定么？
必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。
19. 你们对意见不一的缺陷有三国会议么？
必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。
20. 所有的缺陷都是由登记的人最后关闭的么？
Bug应该由Opener关闭。Dev不能私自关闭Bug。
21. 你们的程序员厌恶修改老的代码么？
厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。
22. 你们项目组有Team Morale Activity么？
每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。
23. 你们项目组有自己的Logo么？
要有自己的Logo。至少应该有自己的Codename。
24. 你们的员工有印有公司Logo的T-Shirt么？
要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。
25. 总经理至少每月参加次项目组会议
要的。要让team member觉得高层关注这个项目。
26. 你们是给每个Dev开一个分支么？
反对。Branch的管理以及Merge的工作量太大，而且容易出错。
27. 有人长期不Check-In代码么？
不可以。对大部分项目来说，最多两三天就应该Check-In。
28. 在Check-In代码时都填写注释了么？
要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。
29. 有没有设定每天Check-In的最后期限？
要的，要明确Check-In Deadline。否则会Build Break。
30. 你们能把所有源码一下子编译成安装文件吗？
要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。
31. 你们的项目组做每日编译么？
当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。
32. 你们公司有没有积累一个项目风险列表？
要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。
33. 设计越简单越好
越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。
34. 尽量利用现有的产品、技术、代码
千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。
35. 你们会隔一段时间就停下来夯实代码么？
要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。
36. 你们的项目组每个人都写Daily Report么？
要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。
37. 你们的项目经理会发出Weekly Report么？
要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。
38. 你们项目组是否至少每周全体开会一次？
要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。
39. 你们项目组的会议、讨论都有记录么？
会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。
40. 其他部门知道你们项目组在干什么么？
要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。
41. 通过Email进行所有正式沟通
Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。
42. 为项目组建立多个Mailing Group
如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。
43. 每个人都知道哪里可以找到全部的文档么？
应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。
44. 你做决定、做变化时，告诉大家原因了么？
要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。
45. Stay agile and expect change
要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。
46. 你们有没有专职的软件测试人员？
要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。
47. 你们的测试有一份总的计划来规定做什么和怎么做么？
这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。
48. 你是先写Test Case然后再测试的么？
应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。
49. 你是否会为各种输入组合创建测试用例？
不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。
50. 你们的程序员能看到测试用例么？
要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。
51. 你们是否随便抓一些人来做易用性测试？
要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。
52. 你对自动测试的期望正确么？
别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。
53. 你们的性能测试是等所有功能都开发完才做的么？
不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。
54. 你注意到测试中的杀虫剂效应了么？
虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。
55. 你们项目组中有人能说出产品的当前整体质量情况么？
要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。
56. 你们有单元测试么？
单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。
57. 你们的程序员是写完代码就扔过墙的么？
大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。
58. 你们的程序中所有的函数都有输入检查么？
不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。
59. 产品有统一的错误处理机制和报错界面么？
要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的
Application Block。
60. 你们有统一的代码书写规范么？
要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。
61. 你们的每个人都了解项目的商业意义么？
要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。
62. 产品各部分的界面和操作习惯一致么？
要这样。要让用户觉得整个程序好像是一个人写出来的那样。
63. 有可以作为宣传亮点的Cool Feature么？
要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。
64. 尽可能缩短产品的启动时间
要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。
65. 不要过于注重内在品质而忽视了第一眼的外在印象
程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。
66. 你们根据详细产品功能说明书做开发么？
要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。
67. 开始开发和测试之前每个人都仔细审阅功能设计么？
要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧”
68. 所有人都始终想着The Whole Image么？
要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。
69. Dev工作的划分是单纯纵向或横向的么？
不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。
70. 你们的程序员写程序设计说明文档么？
要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。
71. 你在招人面试时让他写一段程序么？
要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。
72. 你们有没有技术交流讲座？
要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。
73. 你们的程序员都能专注于一件事情么？
要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。
74. 你们的程序员会夸大完成某项工作所需要的时间么？
会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。
75. 尽量不要用Virtual Heads
最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。

⑵ 程序员要开会吗

程序员开会。一天大概开会3个小时,其余9个小时是写代码,也就是说每天在公司的时间是12个小时。

⑶ 程序员该去大公司还是小公司

• 进大公司还是小公司各有利弊，这个真的很难一刀切。还是要因人而异，因情况而异，个人建议程序员选择大公司。大公司小公司优缺点比较如下：

1. 通常情况下，大公司的优点是：
   

平台好，各种资源多，学习培训体系完善，牛人多，说出去也有面子，工作环境好;

稳定，有健全的福利待遇，而且公司经过N年的积累沉淀已经发展成熟，有安全感;

有秩序，制度规范流程清晰，明确了每个人的责任，也最大限度上保护了每个人的权益。

缺点是：

因为结构太完整了，多你一个不多，少你一个不少。

因为你就像一颗螺丝钉，你的成长是有局限的，而且一个萝卜一个坑，上升也会有困难。

2. 小公司的优点是：

每个人都很重要，而且你可能身兼数职，能量能得到最大限度的发挥。

离老板近，开会培训的经常都是老板，如果老板格局高够有魄力，也能学到很多东西。

跟公司一起成长，如果公司成了，你就成了元老，有原始股，发达了，像阿里巴巴的十八罗汉。

缺点是：

风险高，不稳定，说倒闭就倒闭了。

工作时间巨长，基本上没有私人生活。

没秩序，混乱，搞得不好你会发现有效的工作时间三分之二都不到，时间都去哪了?

⑷ 程序员可以直接在家办公吗

这种情况是存在的。有如下两种情况：
1 程序员是单干的，也就是一个人完成整个项目，这时不需要与其他人合作交流，而家里又有完整环境时，可以在家工作。
2 通过线上联系，如即时聊天工具，邮件，电话等，可以与其他项目组成员很好的沟通，而家里有完整的工作环境时，可以在家工作。

要在家工作，必须满足以下几点要求：
1 项目可以独立完成，或在家可以与项目组成员无障碍交流。
2 家里有完善的开发环境，或者可以远程使用外界环境。
3 公司允许在家开发，或者没有公司，自己就是老板。
其中第三点是最难的，由于在家工作存在，不利于交流，容易降低公司凝聚力，对于机密性数据容易产生泄密，对员工工作状态无法及时了解等缺陷，所以大多数情况下，都是在公司进行开发的。在家办公的好处有很多，主要有以下几点。

时间自由。程序员的工作大多是“计件”而不是“计时”，而且不少程序员都是夜猫子，晚上的工作效率最高，但大多数公司都没法提供昼伏夜出的考勤制度，所以在家工作的效率往往比在公司要高。

形式自由。程序员大多是热爱自由、厌恶约束的人，穿T恤衫牛仔裤上班、边听音乐边写程序只是小意思，不少人还喜欢看文档时把脚翘起来，想问题时头朝天身体后仰，中午趴在桌上睡个觉，这样做在公司会被看做“缺乏体统”，在家则绝对没有问题。

省去了繁文缛节。毫无意义的会议是大多数程序员讨厌的，与业务部门的交流通常也很令人心烦，而在家办公时这些都由自己主动掌握，心情大大舒畅。

省去了上下班的劳顿。据统计我国一线城市白领平均花在上下班路上的时间超过30分钟，而且公共交通往往拥挤不堪、上下班奔波劳心劳神，严重影响心情继而影响工作效率。

而说到在家办公的缺点，大多数人则只能想到“沟通不利”，这确实是个非常严重的问题。如果程序员的工作内容只是提交代码，那么在家工作应当算相当好的选择， 可惜工作是一项复杂的劳动，沟通是其中必不可少的内容。面对面的沟通，无论是效率还是质量，都胜过远程沟通，加之工作中许多协调配合的事情远程交流是很难 弄清楚的，所以许多容许程序员在家办公的公司也会定期召开碰头会，遇到重大项目就更是如此

⑸ 程序员开会迟到，在工作群里道歉后还被劝退！网友：拿N+1再走

开会是我们在职场中经常遇到的，公司领导只有在宣布某些事情的时候，才会把员工聚在一起说明事况。因此可以说会议上出现的事情都比较重要，关系到公司的发展和方向。

可是有一位程序员比较迷糊，在公司组织开会哗模的时候，竟然迟到了：

这位程序员抱怨：自己因为一个重要会议迟到了30分钟，事前也没有明确说明会议时间，碰巧董事长和公司高管都在会议，自己已经给出了积极道歉态度，而且事后也在工作群里道歉了，可是还是被公司通知劝退，要自己马上安排做交接工作！

有网友给出解释：错就错在事后你还去群里放大你的错误，本来一件小事，被你放大重提了，老板要是不开你，怎么在普通员工面前立威？会上强调一下前面的会有多重要，然后轻描淡写道个歉，这样的后果可能会比你在群里道歉的效果好得多，因为老板睁一只眼闭一只眼就过去了。

还有网友建议：这种公司待不下去了，因为这些很有可能是同事或者上级的套路，故意不告诉你开会时间，所以你应该是被整了。而且老板和你想的东西不一样，他们只看员工有没有能力，要是能力不够或者能力一般，估计也不会要你，直接拿嫌芦袜N+1走人吧，这样还能得到一些补偿！

无论做什么事情，迟到永远是不好的行为，因为迟到不仅会影响个人的信誉，还会影响团队的进度，所以我们要养成不迟到的习惯，不要等到时候造成苦果再后悔！

欢迎刚入门的Java小白朋友们加入Java之家：79979,2590

里面提供免费的Java的学习资料（里面芹激有企业级技术、日常练习案例等多个知识点的资料，每晚我还会

在群内直播上课）

⑹ 做为一个程序员你为什么离开大厂呢原因有哪些

程序员的岗位生命周期与自己的自学能力、岗位等级和细分行业都是有较为立即的关联，尽管在大型厂有较大的上涨室内空间，并且会获取越来越多的网络资源支撑点，可是能不能在程序员岗位走得更长远通常或是因人有所不同的。从程序员岗位的特性看来，往往程序员岗位的岗位生命周期相对性较为短，一个主要的因素是程序员岗位的压力非常大，尤其是运用级程序员岗位，不但压力非常大，并且自己的上涨的空间也相对来说非常小，常常要应对许多可重复性的研发每日任务，这也会造成程序员的工艺管理体系慢慢老旧，进而被领域所取代。因此，从这种视角看来，从业产品研发级岗位会在一定水平上增加自己的岗位生命周期。

假如效益低迷加工厂会对技术人员开展裁掉，就算确实想做到退休几乎可以说天方夜谈，因此在企业都还没破产倒闭以前，多学习培训更多的专业技能为未来换工作奠定扎实的基本。程序员无论到什么高新科技产品研发企业、生产厂、网络科技公司，或是中央企业、国营企业全是较为吃香的专业，月收益过万没有问题。关键是对技术专业英雄熟练度、技术性是不是高超及其把握的关键技术比较多有较大的关系。

⑺ 现在领导有事没事就要求下班时间开会总结怎么拒绝

张工是一名程序员，在一家互联网公司上班，最近部门来了一位新领导，总喜欢在快下班的时候开会，而且一开就是一两个小时，有重要事开会还说得过去，可有的会议始终是太无聊了，张工始终想不明白为何新领导喜欢这样。之前的领导是有事才开会，现在这位领导，有事没事都开会，而且还是在快下班的时间开会。

为什么领导喜欢在快下班的时候开会？我们不妨从下面几个角度分析：

有的领导白天工作时间被其他重要事情、会议等安排得满满的，很少有时间和员工交流，要和员工交流，就不得不安排到最后了，而这时快下班了，难免会占用员工一些时间。

小编曾遇到这样的一位领导，下班时间到了，不管有事没事他就是不回家，继续在公司工作2-3小时，因为回家也没什么事，也是工作，还不如在公司加班，还可以避免下班高峰期。

领导总喜欢快下班时开会，作为下属，也只能学会适应了，要是实在不能接受，只能考虑另选高就了。

⑻ 经常听到某大互联网公司校招程序员开出十几K的薪水，或者是某产品经理薪水又从十几K冲向20K ，反而

其实薪资分配这个问题，在互联网行业和传统行业大体一致，基本遵循供求规律。

产品经理大致像传统行业的项目高管，靠战略思维、行业经验和对产品的理解把控项目方向，是舵手，拿高薪没有争议。至于程序员，在idea向产品的转化过程中，起着极为重要的作用，这个职位的门槛要比其他岗位更高，属于高技术工种，往往要经过长时间的严酷训练之后，才能出师上岗。青鸟、达内之类培训班出身的程序员，起薪十几K好像很难。就算这些培训班，也往往要脱产上课，日以继夜苦学半年才能毕业。

我并不认为运营的重要性不高。张亮大大在《从零开始做运营》里表达过类似的意思，再优秀的产品也需要运营引导，不要指望自体运营这回事。问题就在于运营的岗位门槛要低一些，这个职位的候选人可以来自各个专业、各种岗位，候选人数量跟程序员不是一个级别。当然了，好的运营对产品成功的重要性不言而喻，不应被低估，运营高手工资也不见得比程序员哥哥低。

至于毕业就十几K的程序员，其实并没有题主想的那么多。基本都集中在北邮等几所编程黄埔军校级的学校，也基本只有BATH和独角兽级的公司才能开出这样的薪水。也正因为每年校招这些行业巨头先首批挖走了大量优秀毕业生，才使剩下的人也跟着水涨船高。

无论如何，作为一个做过传统行业运营的人，我支持把运营的薪资水平提上来。

最后，楼下中国平安保险重庆市江北支公司的朋友，你和你的同事为什么把乱码发遍了整个社区？ 来自职Q用户：梨花与虎🏅🏆
大概是因为442法则，定位40%，产品40%，运营技术只占20%，选品，产品质量，供应链，推广费用，老客户这些都很重要。
写过代码现在是产品经理，这个问题确实存在，我尝试分享下，不一定靠谱，我不想讨论钱，我想讨论生活态度。
1.工程师每天对着电脑的时间比对着人的时间多的多，而产品经理每天要跟各种人扯淡。大部分工程师很讨厌开会，喜欢戴上耳机安安静静的写代码，代码提交那一刻的满足感比什么都好。时间长了你会发现工程师越来越少和人沟通，沟通的也大部分是工程师。而产品经理要跟运营，商务，法务，财务，老板，设计师等等各种角色沟通。要不断切换频道，说的好听点叫沟通技巧，不好听的叫见人说人话，见鬼说鬼话。所以第一点如果形成一个正反馈的循环就会导致工程师生活中大部分时间都和电脑，手机在一起。
2.我所认识的很多程序员都是985，211学校毕业的，男生居多，很多人做工程师并不是因为热爱，而是因为工程师是一份相对来说可以靠手艺吃饭并且收益不菲的职业。很多人家境并不很好，他们一开始工作就背负着房，车，女友三座大山，唯有努力工作获取主管信任，加薪升职。反观有一些家境不错，纯属热爱这份工作的工程师会过的更滋润，除了写代码外有自己的爱好，会参加各种活动等等，不可否认钱有时候会影响一个人的心态，虽然这里已经给定条件说是薪资一样，但是一个是老家有三个还在上学的弟弟妹妹，一个是老爸老妈经常出国旅游的家庭，生活状态还是差很多。钱会制约一个人的视野和判断力，导致做很多决策时只看眼前。比如下班了大家说一起出去吃饭，但是有些人可能会想公司有饭票，不去浪费了，还是你们去吧。看上去节省了十几块，但损失了跟人交流的机会。这一点其实工程师和产品经理都适用。但是因为第一条影响，薪资相同的人对钱和生活的态度也会不同。
3.每个人都有自己的生活，你说酷酷的生活带来的幸福感就比解决一个技术难题的幸福感高吗？那也不一定。过什么样的生活取决你的生活态度，你可以选择下班了继续看文档或打两局dota，也可以找同事去酒吧喝两杯。你可以选择开会时继续远程debug，也可以选择跟业务和产品经理吵一吵，发出自己的声音。最怕你不满现状，又不愿意改变，life is like a box of chocolate,you never know what you're gonna get。
所以产品经理、产品运营和工程师生活态度上的差异是受个人和工作环境的影响，但是选择什么样的生活方式并无对错，只要你自己开心就可以。
来自职Q用户：匿名用户