很多人也在吐槽说为啥这些大厂的小事动不动就上头条，但是人若反常必有刀，事出反常必有妖。之前阿里取消周报的举措，就是希望减少程序员的无效工作和形式主义，现在阿里让高光【P】成为过去，网易通知在沟通中取消“哥”、“姐”、“总”等称呼改用昵称代替（富贵、二狗等接地气昵称均已被抢注一空哈哈），是希望形成平等沟通，提高沟通效率。
说到沟通成本，花少也表示深有体会。就像之前跟过一个跨多个平台和多个团队的项目，从终端上发起请求到云端（会经过网关、规则引擎等）再到服务端（功能逻辑处理），每个端甚至端上的每个服务都是不同的团队在负责。因为这些平台已经有几年的历史，很多研发已经离职，后面接手的大部分都只知道自己的模块。当时我们每个模块开发好自己的功能进行集成联调时，就是因为一个ID无权限被网关拦截，走进了两个死胡同，第一网关层说需要在开放平台申请权限，开放平台又说这是内部的ID无需走权限；第二我们问提供这个ID的开发人员，开发人员说是运维提供的，运维人员说当初提供这个ID的人离职了，就这样陷入了一个无解的境地。花少都惊呆了，就这么一个小问题花了将近两个星期才搞定，这一票功能的开发周期本来就一个月，能把一半的开发时间花在非功能性需求之上，真的是第一次遇到。
刚才的问题最简单粗暴的方法就是每个端的开发人员做一起，打开debug进行调试，是非黑白一下子就清楚了。但是因为公司体系大了，每个公司每个部门都会有各自的工作流程，这些流程在一定程度上可以规范工作方式、提高工作效率，但同时也会增加沟通成本。虽然很多公司都在推敏捷项目管理，但还是很多团队在瀑布式中禁锢，本来几个开发拉一起干一架几个小时就能搞定的，但是因为级别跟岗位的关系（还可能存在老员工的“优越感”），项目经理只能去“请教”，“真理”在传递过程中被曲解。
吐槽完毕，我们再来吐槽下很多公司存在的问题（只是花少结合之前经常踩的坑，加上同行的吐槽总结了一下），有同感的点赞哈：
产品架构不清晰
当一个公司的产品足够多的时候，业务线的划分、功能的界限就显得尤为重要，如果处理不好就很容易出现“82定理”即花80%的时间在处理20%的功能。如果一个公司很看重商业化，会因为利益的关系，例如本身是A业务团队的业务范畴，但是让B团队承担时，沟通的成本就会很大，如果A团队不配合或者没有开放所需能力，B团队就很容易单方面凉凉，因为两个团队间缺少了平等对话的筹码。
矩阵型组织不均衡
主要分为职能型组织、平衡型矩阵、项目型组织，但是很多公司还是以职能型和项目型居多。有个现象就是如果这个项目是属于出差、驻场或者外包形式的，一般就是项目型组织即山高皇帝远项目经理是老大；如果是在公司内部进行项目的，项目经理更像是项目助理，主要负责工作动不动拉人开个会，然后记个会议纪要，话语权还是在各部门老大手里。而且一些重大项目的负责人，很多都是某个部门老大。
前几天还有项目经理跟花少吐槽说做公司内部项目真是憋屈，一点职权都没有，因为团队成员都不在自己控制范围内，导致项目计划很难把控。但是这个就是事实，花少所经历的内部项目，延期是最正常不过，因为一个研发部门会有多个项目并行，一不留神，项目经理就会听到“您的团队成员不在服务区，请稍后再拨，滴滴滴…”，PMO最贴心的服务就是催着项目经理提项目变更。
甩锅文化
出现这个文化的情况无外乎这几种情况：公司业务从增量到了存量阶段，大家没事干就喜欢把一天能做的事变成一个星期；公司发展受到了瓶颈，需要精简队伍，首先处理那些“犯错”的人员；老板喜欢搞形势主义等。如何判断自己公司的甩锅文化严不严重：动不动就开会，然后写个会议纪要，而且一定要正式邮件发出去；提个小需求，一定要按模板填写，还得走流程；一出问题就是一堆人在哪里吵架，最后把问题上升到大领导了，才能解决
“喝最烈的酒、爱最爱的人、干最想干的事”，程序员是一个很单纯的职业，因为代码骗不了人也不会骗人，也不会因为你穿着格子衫抠着脚就看不起你。很多人选择这个职业应该也是想要在世俗里做一个“自由人”，世界给我们一份清静，我们让明天没有BUG，完美
花有重开日，人无再少年 → 我是花少【少宫主花无缺】#更新不断，下期继续#走过路过记得留下关注和点赞
4914
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
