本文于2019年7月24日完成，发布在个人博客网站上。
考虑个人博客因某种原因无法修复，于是在博客园安家，之前发布的文章逐步搬迁过来。
笔记而已，没有逻辑。
贵与慢，一方面是事实，另一方面是偏见。
流程IT，流程，方法，模板，工具，IT。先有流程，后有IT。
流程，用来沉淀知识，固化经验，把能力建设到组织上，降低对人的依赖。
相对于现实工作中遇到的问题，流程首先会相对滞后；然后IT作为流程自动化的解决方案，自然是更加滞后。因此，IT的方案偏保守，这是正常现象。
IT部门，作为企业的成本和费用中心，支撑企业发展，存在感相对比较低。相比于产品交付团队，IT的交付在项目关系，项目资源，人员素质，交付能力，交付要求等方面均有较大的差异。
在软件公司，差异会更明显。IT部门，论做软件，能力不如产品研发团队强；论做业务，对公司发展，理解没有业务团队强。于是存在感自然很低，时不时还要被周边的产品团队鄙视，投诉。
企业的IT部门，要支撑企业高速发展，然而能力有限，资源有限，时间有限，挑战很多。在有限的资源条件下，必须聚焦精力，交付有价值，高质量的产品，有所为有所不为，否则贪多反而嚼不烂，周边的体验会更差。
业务是否重要，需求是否有价值，并不是一个很好决断的问题。在大企业内部，技术因素可能并不是关键点，政治因素需要考虑更多。因此健全RAT/RMT组织，拉通需求的相关方一起参与，IT组织内部排序后决定需求优先级和交付计划，照顾各方利益，显得尤为重要。
1）对于非重要的业务，相关需求，放缓交付节奏。
2）对于重要的业务，相关需求，集中优质资源，保证效果。
企业IT部门，作为成本和费用中心，不直接产生收益，如何将自己的工作产出变现，是一个难以回避的议题。
IT支撑业务的发展，IT部门与产品部门的边界如何划分。对于一个IT部门和产品部门都要参与的商业解决方案，哪些特性在IT部门做，哪些在产品部门做，谁来评判，如何评判，评判的准则和依据是什么。无论是否存在解决方案团队，前述几个问题都不好回答，需要综合各方因素，平衡各方利益，满足各自诉求。
解决方案团队除了具备需求，架构，设计，运营的职能，还作为IT团队和产品团队的沟通桥梁，承担协调，拉通的职能。
IT部门基于项目来运作，现有的特点：
1）自有人员承接项目管理和方案设计工作。开发，验证，维护等工作外包给外部团队或者供应商团队。
2）项目验收后，自有人员很快投入新项目，而开发交付团队随之迁移进新项目，只保留必要的资源做维护工作。
容易出现的现象：
1）自有人员对实际使用的技术缺乏理解。技能模型演变为项目管理型和业务方案设计型，由于缺乏技术氛围，技术类架构师难以生存，组织内部无法培养难以培养，只能依赖空降来补充新鲜血液。
2）项目上线后，无法维持一定的交付人力，导致新需求，优化类，性能类问题等无法支撑。
3）自有人员热衷于做新项目，在已有项目上的关注度下降，投入不足。
4）交付团队热衷于参与新项目的交付。
5）已上线的项目，由于人员不稳定，交付质量，交付能力每况愈下，导致项目要么被束之高阁，无人敢动，成为定时炸弹，要么被新项目替换，开始一个新的轮回。
于是给人留下的印象是，IT部门对业务的理解总是慢半拍，不断在重复造轮子，花费公司的资源，拿公司员工来练手。
基于产品的思维可以解决上述问题吗？值得思考。