缺乏竞争力的（相对）高收入群体

缺乏竞争力的（相对）高收入群体

我现在是程序员，一个小开发组长，过去是产品经理。到新公司新岗位一段时间后，感觉这个工种在企业内的处境有问题。程序员的相对高薪和可替代性，使其在整个公司面临竞争压力，不得不找人为企业管理的低效买单时，非常脆弱。

高薪和可替代性，和公司低效的工作模式有关。

低效的工作模型

我的新公司是个挺大的上市公司下的一个子公司，这个公司对待程序员的方法很常见——和相当多公司一样不可理喻：一方面，雇佣大量程序员，并给高薪，至少比产品经理和其它文员高；另一方面，在做产品决定时忽略程序员。

这就导致一个我说出来明显有问题的管理现象：少数低薪员工决定大量高薪员工的工作。一个一个月一万出头的产品经理，给出符合他薪水的工作成果——不咋样的需求分析和产品原型，决定十几个月薪两万的程序员接下来一两个月，甚至更长时间的工作内容。

现在我所在的公司就处于这种糟糕的模型中，产品水平很符合他们的薪水——很次，甚至不和开发坐在一起工作；开发不了解产品需求，不知道一个功能多重要。开发一个公司内部系统，都很难和业务部门的同事说上话，只能通过没有用的中间管理层了解需求。

这是一个非常糟糕的模型，这个模型否定了程序员作为最后产品的施工者，在产品设计中的作用。这倒是很符合「码农」、「搬砖」的形容：只需要埋头实现设计，不需要想别的。除了建筑设计看上去比产品设计专业、成熟多了，要求也低——毕竟是卖方市场。

妨碍开发效率

首先，这降低了开发的效率。程序开发有相当多的细节，很难有产品能把一切细节设计好，只剩实现。开发不了解产品设计逻辑，面对产品未考虑到位的地方就无法自己做符合设计逻辑的决定（如果有设计逻辑的话）。这个模式下，开发人员越多、项目越大，耗费在沟通上的成本越大，大到形成GL体系。

让产品脱离需求

第二，这让开发出来的产品脱离需求。「产品经理」是一个没有办法的岗位，最好没有这个岗位。「产品」是连接需求和施工的纽带，一个理想的产品经理，应该可以把需求抽象出来，在用更有效的方式表达在产品设计上，但现实是大多数公司的产品经理可能在他短暂而无用的职业生涯中一句话都没有和基层业务说过。向下不了解程序开发，向上不了解业务需求，没有接受过系统训练，自学一周 Axure 上岗，这样的产品居然横在开发和需求之间，指挥开发工作。

阻碍程序员职业生涯发展，难以培养人才，制造不可维系的人力环境

第三，这妨碍程序员的职业生涯发展。有关程序员的年龄歧视很多，已经不是传言了。这不是针对程序员，而是程序员的薪水相对比较高，人口还大，所以公司觉得人力支出多时就喜欢拿程序员开刀。这种情况还经常发生在基层金融从业者身上，程序员和基层金融人有个共性，就是缺乏实际业务经验（难以领导业务），技能和业务的耦合度低（即插即用），高薪（相对）。一个在就业市场上受欢迎的程序员，要不是技术超群，能突破公司重要的技术瓶颈，要不是很懂某一个行业，做出来的程序能更贴近行业需求。

对程序员的年龄歧视，本质是认为这个工种的经验没有价值。那不是废话吗？大多数公司的业务根本不存在技术瓶颈，只有对业务的理解有高低，但这些公司根本不让程序员参与产品设计，不让程序员参与业务决定，那程序员就不可能了解业务。在经济发展，互联网膨胀的环境下，程序粗糙点问题不大，但这几年，国内经济不景气，看上去也不太可能在短期内复苏。规模增长停滞的市场下，要提高竞争优势必须精细经营业务，不了解公司、业务的程序员，难以做出适应竞争激烈的市场的程序。

不谈社会责任，虽然它很重要。从公司角度，不应该把希望都放在从外部挖懂业务的高级程序员身上。这种「职业经理人」的模式已经被发达国家证明是低效的了。如果公司内部不能提供职业晋升空间，公司与员工的利益冲突会增大，恶化代理困境（Agency Problem），职业经理人可不管公司的长期利益，只要在自己的聘期内捞到好处、撇清责任、跑路，就好，毫无忠诚感可言。

但忠诚感是公司和员工两边的事情。

程序员和金融人的工作产出都不直接影响公司业绩。程序员工种是一种「元工作」，是关于其他工作的工作，是制造工具的工作。没有基层产生消费的那层活动支撑，程序员的工作无法产生经济价值。「管理」工作也一样不产生直接价值，但一般不是管理层来为低效埋单。

从企业角度，如何解决？

虽然这是个企业的管理问题，但这里不谈太高的解决方案，只谈IT部门有可能能做到的。IT部门的主要工作是系统的开发，系统开发有三个元素必不可少：需求、数据库、开发。

开发介入需求分析，承担更多产品设计的责任

我刚进公司时，听到几位开发同事讨论项目里一个产品没说明的功能要怎么做。这几位开发讨论出来的结果居然是随便做，反正是产品的错。说得好像改需求时和自己没关系一样。你不会希望自己的开发人员都是这种心态，但你也不应该指望靠他们自己提升觉悟，如果他们可以自己提升觉悟，那部门经理应该立刻辞职。

恕我直言，寄提高业务的希望于靠基层员工自己努力的管理层，都应该立刻辞职谢罪。

这一步最困难，业务部门可能不愿意配合，上级领导可能不与IT部门直接对话，但是这一步对IT部门的表现影响重大，IT部门应该主动与业务部门沟通，协助业务部门抽象需求。

重视数据库设计

数据库是业务、管理的抽象，系统是数据的输入输出，大多数公司里，系统的数据库都是由开发部门设计的（至少是由他们建库的），数据库不应该由不了解需求的人设计！即使在同一个公司同一条业务线里，一般也是一个系统一个数据库，很少会共用，但公司的经营是一个整体，要提供公司整体的经营效率需要各个子单元紧密配合，至少不互拖后腿。

前几年行业内总说的「业财一体化」，就是指业务和财务数据打通。领导一般去看财务出的报告判断业务经营情况，但产生价值的地方终究还是业务部门。

运气好，财务系统和业务系统的数据库凑巧是同一个人设计的，那这些系统至少在业务逻辑上差别可能没那么大，数据打通会比较容易，但如果是不同项目组各做各的，那可能最后不同数据库里的实体抽象都对不上。我上一家公司就有这个问题，财务系统里的组织架构和业务实际使用的组织架构完全对不上，为了多个系统的打通耗费大量资源，说花一年一百多万请了一个微软的架构师来搞，我去这个项目组见识过，基本都在清理数据，我入职时已经搞了两年，在我离职时还没做好。

数据库、业务行为（需求）、系统开发，三个主体连接紧密，要提高整体的效率需要三者的逻辑统一，这件事IT部门是有希望主导的，开发和数据库设计已经在开发部门手里了，部门经理最好不要让不同项目的开发因为数据库设计上的矛盾内耗，毕竟到最后系统做不出来，都是IT部门的错。

提高需求方的反馈频率（在不指望需求方能力提升的前提下）

理想的情况：需求方完全明白自己需要什么，给出详尽的产品设计，开发部门闷头做。

这可能吗？

做面向客户的产品时，很多公司会采用内部试用、公开试用等方式搜集用户反馈，调整需求。做公司内部产品就简单些，直接让需求方和开发共同设计产品，让需求方了解开发方向和进度。一般需求方的事前提的需求比较粗，拿到手里用时挑三拣四。最好开发这里能够非常快的出基础功能（也就是增删查改）齐全的demo，然后按照更新的需求进一步开发。

不考虑高并发和分布式，CRUD 的输入输出模型还是比较简单的。

输入，是表达业务行为的 SQL 语句，输出是接口，但用户不认接口，所以输出要到 UI 界面。那就是三块：SQL 语句、API、UI 界面。

不考虑任何条件判断、数据验证、UI 界面美化，我觉得 SQL -\> API -\> 最低可用的 UI demo，这三步的开发应该要缩短到一两天内一个功能模块的程度，才能支撑适应不断更新的需求。

开发框架的选择并没有统一标准，是各方面权衡。企业服务最主流的开发框架之一是 Spring + MyBatis + 某前端框架，这个框架不符合上面提出的开发模式。开发者会花费大量时间在把设计翻译成代码上，换来的好处是程序员好招，技术支持多。

如果想在没有设计者的情况下写好程序，还能适应变化的需求，请不要做梦。因此这里做框架选择不考虑架构设计变化频繁的状况，只假设程序内的主体相对稳定（数据库稳定）。那么能最快把 SQL 翻译成 demo ，并且具备优化界面和业务逻辑能力的框架，会是比较好的选择。
————————————————
原文链接：https://blog.csdn.net/u013468378/article/details/103718767