累成狗的反思

公司给不给加薪，工作有没有价值，从经济学角度看，看我给公司创造多少纯利润。

甲方看有没有价值在于，能不能按需高质量交付需求，并且所需要的PO最少。

那么问题来了，随着乙方丢失话语权，从自己评估PO，到甲方说了算，开发人员就成了夹缝中的小草。

如果做全栈开发，再加上一些自动化死的代码提交量指标，所以更加悲剧。

有同学留言为什么描述的这么悲剧，其实只是特例，不针对所有项目，只是一个借鉴：

一个全栈工程师，代码量会非常少，你搭建环境没有代码量，写脚本tfs上没代码量，解决用户问题tfs上也没代码量，如果是二次开发，读懂源码需要的时间远大于开发时间。

另外就是现在PO的问题，拿个具体例子来说：

一个A需求，A 业务对象的CURD，UI不算，纯后台给你16H，是不是很高。

领导想法很简单CRUD分分钟的工作，你说有比较多的细节然后评估到24H，然后你需要用两个4*4的义务加班去填补。

• 表设计7~10
• 写接口–全场景覆盖
• 数据迁移
• 历史数据搬迁
• 环境搭建部署

因为现在的SE不做细节评估，风险控制，质量把关。

PL也是常说的一句话，我认为，我理解比较简单，然后上线一堆问题。

开发跳过设计，测试跳过设计，想到哪里开发到哪里，想到哪里测试到哪里。

第一次上线每个环境都是通宵，每个环境都能验收出新问题。

罗列下这个被任务简单的CRUD。

这还是其中20%的工作，罗列不开，还包含A下挂多个B，B本身下又挂多类子对象，涉及到文件处理，安全控制，业务校验等等。

第三个问题就是在于人了，其实大部分像我们这样的程序员不属于高手，资质太平庸了。

有些很流弊的程序员，无论脑力还是手速是真的强，遇到过脑思维速度，并发处理问题等能力，手速都比我高30%左右的。

一个需求几十个场景，不用笔瞬间理清，然后再大脑划出模板，可以完成相对较为完善的开发，然后进行高效调试，场景几乎全覆盖。

十来个工程没有任何资料，从另一家公司接手，同样是读源码一个月，一年都不会忘的，一样把系统逻辑反向推导的清清楚楚，不需要做任何笔记，只是拿笔简单的画画草稿。

像LHL这样的，真新羡慕。

除了客观问题，主观上天赋决定天花板，真的和BATH大厂的牛人差距太大，薪资差距那么大也是应该的。

反过来，对于大众程序猿，这种问题如何处理？

需要话语权，和沟通。

反思这个问题核心不是说明问题本身多糟糕，而是要如何改变？

如果我们去做SE，又如何确保这种需求的合理性，可实施性，和可靠性。

而非拍脑袋决定，一句我觉得，然后就是各种线上场景遗漏。

• 设计重于实施，如果场景罗列清楚了，基本开发完了80%。
• 有的员工拿着3000+的工资，不能把外包全部当大牛。

世界上的事情，除了0到1是摸索出来的，那叫技术。

对于非研发类程序员这种非技术的工作来说，是成而做。

很多东西计算好了，可以做成，编码只是纯工作量了。

不会让你去研发一个别人没实现过的东西，核心是用那个方法实现更好，怎么才能覆盖全场景。

其实这是现象，如果能先设计，把所有要做的东西设计好，有得谈还不错。

如果本质问题是经济问题，商务人员去处理的，这个种问题作为借鉴就好了，该干嘛干嘛去吧，做不完就义务加班吧。

如果是其他供应商做PM的，可以借鉴下，打造团队确实不容易，不是为了做没，而是做大，做强。

另外就是了解人员构成，有些人天赋很强，产出效能确认很强，但是平均水平不高，所有要做合理的安排和实践规划。

虽然外包的我们相对技术差，但是每日的代码产量不能用手速*时间去计算，核心必须以产品交付质量为核心。

往死里义务加班都达不到预期目标，不能一直换人来证明人不行。