不知道大家有没有想过这个问题： 技术人员的价值是什么？ 在跟许多技术人员交流的时候，发现大家很少关注自己在做的事情是不是有价值，他们通常更在意自己的工作有没有成就感，成就感一般体现在有没有使用更炫的技术，功能逻辑设计得够不够复杂，业务方对自己是不是满意。
是不是总觉得哪里不对劲，却又说不出什么地方不对劲？下面我们看一个发生在我公司里的真实案例。
01
做一个“听话”的程序员有错吗？
我所在的公司是一家大型综合电商平台，一天，我收到了一封来自采购部助理--陈莉的邮件，邮件里热情洋溢地表扬了我们部门的程序员--孙强。邮件大意是，孙强连续几天加班帮助她开发了一个紧急需求，功能上线后效果非常好，体现了IT部跟业务部紧密协作的团队精神，陈莉还打算把这个案例提报到公司层面，给孙强进行表彰。
下属执行力强，得到业务方的认可，我这个直属领导，内心自然是高兴的，于是我决定在团队内给孙强一个即时奖励，也不多，500块现金。我找到陈莉，让她跟我详细说说事情的经过。
陈莉是去年的应届毕业生，进入公司后担任采购助理，采购助理的工作就是协助采购经理把商品录入到系统里，填写商品详细信息、价格、库存等，通过审核后在前台显示，顾客才能够买买买。
陈莉对我说，孙强帮她把商品批量导入的功能，改成了一个一个上传，满足了业务的要求，让她的工作得到了领导的认可。
我隐隐感觉到哪里不对了，让陈莉接着说。
陈莉解释到，哦，是这样的，我每天要上传200个商品，用之前批量上传的功能，2小时左右就处理完了，领导觉得我很闲。。。。
于是，我就让孙强把这个功能改成一个个传，现在每天从早忙到晚。。。
这时，我露出了尴尬而不失礼貌的微笑，对陈莉说，这件事先不要汇报到公司层面了，这是我们应该做的。。。 哦不，我们做得还不够。。。不是，总之，这件事先这样吧。
我找到孙强，问他，业务方提的需求你有想过合不合理吗？
孙强说，她说很急我就先做了，业务方提的需求能不做吗？
我跟很多人说这个案例的时候，大家的反馈是，这种事情怎么可能发生？这个开发人员接到需求问都不问的吗？我的第一反应也是不能理解，一个只知道被动接受需求的程序员，加上一个刚毕业的采购助理，就发生了这样一个极端案例。
这件事情对我的触动很大，让我陷入了思考，技术人员让业务方满意，是对的吗？孙强执行力很强，很“听话”，陈莉对他也很满意。表面上，技术满足了业务方的要求，实际上给公司造成了很大的资源浪费，原本两小时就能完成的工作，现在却要花一天，难道技术人员对这件事情不负有责任吗？
02
重新思考：技术人员的价值是什么？
技术人员如果只停留在“听”业务方的话，是不够的，就像孙强的案例那样，一昧的“听话”，没有独立思考，往往会带来非常荒谬的结果，对公司造成损失。技术人员必须去挖掘业务需求背后的真实诉求，从问题出发，给业务方一个更好的解决方案。
就拿陈莉的例子来说，孙强如果了解了陈莉的痛点：太闲，那么可以开发一个商品价格爬虫系统，让陈莉做商品比价分析报告，给采购经理提供决策建议，让陈莉的业务能力有所提升，这才是技术人员应该做的事，对业务方有益，也对公司有价值。
03
技术人员要思考业务，成为最懂业务的技术专家
技术人员有系统性思维，要帮助业务方去思考业务，用系统的方式更有效地解决业务中遇到的问题，做到技术与业务的深度融合，成为最懂技术的业务专家。如何能够成为业务专家？以下是几个行之有效的方法。
• 维护产品需求池，排列优先级。通过用户访谈、用户意见反馈、业务人员提交的需求、同行的竞品分析报告等，进行需求的分类汇总，分析哪一类需求是有共性的问题、被用户诟病最多的问题，结合内部讨论来制定需求的优先级，发布上线后，观察数据反馈，分析再优化，形成闭环。
• 成为产品的深度用户，深度思考者。如果你的用户是公司内部同事，轮岗是一个比较好的方式，比如一些互联网公司都有不成文的规定，技术骨干每个月必须到业务部门轮岗，跟业务部同事一起来使用系统，强制自己换位思考，这种方式对技术人员培养业务感也是有帮助的。
如雷军都是自家产品的首席体验官，据说雷军在小米创业初期，有一抽屉的手机，随便挑出一只，就能从硬件到操作系统，逐一点评，如数家珍。
• 参加产业论坛，洞悉产业发展趋势。了解行业发展动向，一般技术人员往往更愿意参加技术论坛，然而对于技术管理者来说，参加产业论坛是非常重要的，比如近年来电子商务行业提的比较多是的社区团购、前置仓的概念，那么对于管理者来说就是要去思考从系统上如何打通线上和线下，并且能够给公司提出技术发展路线，布局社区电商。
04
推动需求治理，做对公司最有价值的事情
建立以价值为导向的需求治理机制，其目的是把有限的开发资源，投入到更有价值的项目上，该机制分成几个部分：
建立需求管理闭环。以价值为导向的需求治理机制，是在提交需求环节。在这个环节要阐述该需求的价值预估，即这个需求将给业务带来什么样的价值，这些价值要能够量化、能够追踪。比如，一个结算系统需求，价值是：提升客户对账效率20%，上线后会来验证效果，看看是否达到预期。
整个闭环，分成：提交需求、排期开发、上线运营、需求调整，4个环节。
在提交需求环节，需求提报方要给出可量化的价值预估。
在排期开发环节，开发团队将需求池里的需求按价值大小进行PK，价值高的需求会排在前面，优先安排开发资源 。
上线运营环节，对该需求的价值进行验证，验证的结果将影响需求提出方的信用等级，信用等级将用于需求PK阶段，作为加减分项。
需求调整环节，也将价值做相应的调整，形成新的需求，反复迭代，形成流程的闭环。
05
本文小结
技术人员不能满足于“听”业务方的话，让业务方“满意”，技术人员要成为最懂业务的技术专家，用系统性思维帮助业务方更有效的解决业务问题，把技术资源投入到公司最有价值的项目上，让技术成为公司的核心资产，帮助公司建立壁垒，驱动业务的快速发展，在激烈的市场竞争中胜出！
