研发IT部门在围绕什么工作?
面向研发的IT部门，是给研发业务部门提供工具与IT服务的组织。工作的内容似乎多种多样，有帮业务部门解决运营问题、协调资源、技术培训与支持、完成既定的项目。。。似乎并不很geek，也不高大上。
然鹅，作为IT组织的一把手最为关心的指标是什么？总结一下，大概有下面这些：
- 成本：支付率
- 进度：项目按节点完成率
- 质量：内控、交付物完整齐备、审计
- 一些业务上的指标：比如成熟度、覆盖度、效率提升等
- 一些上级指派的指标：比如某些核心系统的访问量、在线指标数等、还有规划材料、月/季度运营材料、各应用系统指标、系统安全整改
- 一些外部资源的争取：经信委、国资委等争取的扶持项目、奖项申报等
所以，一个组织去除那些花边，真正考核的就是一个一个IT项目。这些IT项目相关的指标，是日常要反复做的，是组织的一把手最为看重的，也是这个组织最核心的指标。每周的运营会、每月的总结材料，少不了要讲的是项目上线将要或者已经取得的成效；已上线系统的关键指标，给业务带来的价值。
至于到外部争取项目、评奖评优，这都是些锦上添花的工作。真正的基础，就是排定计划的项目的各维度指标（支付、进度、质量），以及上级交办的重点工作。
项目从哪里来？
每年组织一次业务需求收集。
由于需求质量良莠不齐，所以建立了反复4轮之多的需求评审。四上四下，反复与业务沟通确认需求必要性、优先级，与IT的领导沟通确认符合规划、符合战略，与潜在供应商沟通确认可行性、预算，与财务、战规等部门确认费用，最终收敛到“业务计划”上来，形成项目清单。通过这样复杂的过程，筛选出下一年的IT项目。
这个项目清单，最后以公文形式发布，就是接下来一年的工作内容。
科学和效率？
这样的需求收集和评审的模式，会导致一些问题的产生：
- 业务需要IT资源，但是财务没有给IT足够的预算，所以业务要削减预算，或者排序后从前到后根据预算削减。
- 业务随意提需求，无法明确计算产出、效益价值，也无法仔细描述清楚需求，只是觉得需要，就提出来希望IT部门实现。所谓没有想清楚就提需求，导致项目上线后，IT部门没有成绩可写；或者上线后，反复修改代码，总也改不成业务部门需要的样子，最后项目失败。看起来，就像是资源被浪费了。
这些问题，既是形成这样四轮IT需求反复评审的因，又是果。
反正业务提出的需求都要反复评审，不报就没有预算，第一轮未报就不许追加。对于业务部门来说，但凡要有点需求，都要使劲报，大不了后面评审砍掉。这样，造成预算虚高，需求质量良莠不齐。
需求的评审，本质上是通过IT与业务两个部门反复拉锯，形成“共同决策”。这样IT部门做的，都是所谓业务部门需要的；业务部门需要的，都要反复思考，通过反复PK，在众多项目中脱颖而出，把需求描述完整清晰。IT为业务背书，要按业务计划交付；业务为IT背书，最终通过的项目都是业务紧急、优先级高的需求。这种方式，就是通过制度，提高需求通过的门槛，筛选出尽量靠谱的需求。
IT没有能考核业务的能力，业务不会对报出来的烂需求负责。业务经常质疑IT，因为没有搞XX项目，导致业务指标无法完成。往往这些理由，也比较牵强，本来就是业务自己完不成，要把责任推给IT部门。对于烂项目，IT只有自己接受投资失败的结果。如果业务需求很容易就可以通过，就会滋生大量的烂尾项目和腐败。所以，才搞了这么麻烦的审核过程。
然而，这个过程太过于琐碎，效率不高。每年搞一次，IT和业务都非常痛苦。既然大家都不愿意担则，那么，就把流程弄复杂，内卷到想当的程度，除非非常必要，否则谁也不愿意去走那么复杂的流程，把项目申请下来。
而要解决担责的问题，那已经不是工作重点了。
