为什么数智索项目交付如此“丝滑”浅谈项目和敏捷

2023年过去3个月了，在2023年中，数智索交付了许多重点项目以及难度系数大和时间紧迫的项目，其中包括建筑领域常见的IBMS智能化集成管理平台、以及目前正在风口上的储能EMS系统平台、光伏和风力电厂运维管理平台也包括机场空侧领域的空侧运行管理平台，那么在项目交付中，数智索是如何保障项目顺利交付，如何让每个项目交付质量得到保障，以下是数智索项目交付推崇的一套方法论，今天就将这一项目交付的心得分享给各位！

一、什么是项目？

究竟什么是项目？每个人都在使用这个词，但它对不同的人有不同的含义，这是一个需要达成共识的问题。随着项目驱动组织创造的价值越来越多，每个人都需要对什么是项目和项目管理达成共识。

项目是包括一系列旨在生成可交付成果（产品、服务、事件）的计划活动的集合。这些活动可以是宏大的战略举措、微小的改变计划的任何形式，共同点是都有时间限制的。它们有明确的开始和结束。同时项目需要以资本和人力资源的形式进行投资，旨在创造预定形式的价值、影响和收益。每个项目都有独特的元素，由此带来的是：每个项目都包含一些之前从未做过的内容。

二、什么是敏捷？

什么是敏捷？敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

什么又是敏捷软件开发？敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。

什么又是Scrum、Kanban、FDD、极限编程、水晶、精益？他们都是符合敏捷价值观和原则的模式。甚至你也可以基于敏捷价值观和原则创造一套模式。

三、敏捷的优点有哪些？

一、快速交付价值。

敏捷是基于价值驱动交付，项目团队要频繁的且尽快的给客户交付可以使用的产品，并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值。

二、更低的风险。

敏捷提倡优先交付高价值、高风险的需求，然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。这样的好处是把最高风险的需求在项目的初期就开始做，可以最早发现该产品是否可行（通常只要1~4周）。如果因为市场、技术或者其它原因失败了，可以及时停止该项目，降低项目风险。即使这个项目失败了，这个失败的代价相对来说小一些。

三、拥抱变化。

在迭代开发的后期也接受变更。因为市场在变化，用户的期望和要求在变化，客户的需求也会随着这些因素的变化而变化，只有及时响应这些变化，并尽快予以实施，才能帮助客户在瞬息万变的市场中保证竞争力和吸引力。而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。

四、更好的质量。

敏捷提倡高频率的交付有价值的产品。每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关，因为在这几个会议中会频繁讨论遇到的问题/解决方案，验收标准，完成的定义等等。同时，也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈，这样团队可以及时予以调整，以确保质量。

五、持续改进。

敏捷提倡不断调整和优化，并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方，进而在下个迭代中改进、调整和优化。这是整个团队成员不断学习，不断提升自己经验、技能的一个很好的机会。另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。

六、更高的客户满意度。

敏捷提倡尽早和频繁的为客户交付有价值的产品，以确保更高的质量，更高的成功率，为客户尽早带来商业投资回报率的机会。

七、更大的灵活性。

敏捷基于价值驱动，它的项目范围是可以灵活调整的，这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等。另外，敏捷提倡频率与团队和客户沟通交流，并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等。还有，验收标准，完成的定义都可以根据实际情况进行调整。

八、更高的团队满意度。

敏捷提倡仆人式的领导，敏捷教练需要给团队工作上的指导、帮助和支持，扫除团队成员工作上遇到的问题和障碍。重视并尊重团队成员的想法和意见，授权团队并引导团队成员自组织和自管理。更重要的是，团队成员可以决定要做什么、怎么做、什么时候做，并自己监控和管理工作进展，对结果负责；团队成员可以一起讨论并确认工作协议，确保考虑并接纳每个人的意见；

四、敏捷的缺点有哪些？

尽管敏捷带来了很多改善，在此需要重点申明的是它并不适合所有人和所有情况。因此了解敏捷的缺点显得尤为重要，方便在根据具体情况进行裁剪时提供依据。

一、很难进行准确的资源规划。

由于团队不是一开始就知道产品最终的形态，而是在过程中探索用户需求，不断地做增量和迭代逐渐知道终极形态，这样会为前期的规划工作带来巨大的挑战。

二、很难准确的定义“轻量的”或必要的文档

敏捷提倡轻量或必要的文档，一定要根据项目实际情况定义何为轻量或必要。防止最后项目交付时才发现文档几乎为0.

三、很难把握整体产品的一致性

当团队在不同的周期内对各个组件进行开发时，整体的输出会变得非常凌乱，而不是一个内部紧密的整体。

四、很难预测有限的终点

没有明确的产品终极形态，就自然没有限定的终点。因此对外的敏捷项目在合同类型的选择上需要慎之又慎。

五、我们应该如何选择？

敏捷在国内的落地过程中存在着种种障碍，这些障碍的因素包括：不一样的教育方式、东西方文化差异、组织内犯错很大程度不被允许、外包泛滥。但是这并不代表敏捷思想本身存在问题。

通过自组织、跨职能团队运营适合他们自身环境的实践进行演进得出适当的解决方案。这个是敏捷的核心思想之一。这也就意味着敏捷并没有固定的规章制度和流程，团队要依据自身环境的实践演进出适合自身的敏捷项目管理方法。

但是切记不要掉入“ALL IN”的陷阱！组织内实施敏捷需要一定的土壤、意识、团队素质能力的具备。同时需要兼顾项目的实际情况，包括：项目的跨职能性、临时性、独特性、不确定性、变更性。以及团队自身的成熟度，包括：技术成熟度、知识成熟度、依赖环境成熟度。综合以上因素科学性的得出项目的实施方法。