软件项目管理（CMMI成熟度）实践——之决策分析（3）

        续《软件项目管理（CMMI成熟度）实践——之决策分析（1）》、《软件项目管理（CMMI成熟度）实践——之决策分析（2）》，后记。

        关于前端开发技术架构决策分析的活动已经结束了，按理说不应该这么快来写总结，但是，的确发生了很大的变故。因此在此写写后续发生的事情吧。

        我很高兴，项目组开发人员在通过长时间热烈的讨论、研究后，终于通过决策分析方法选择引入JavaEE技术架构，并把Cordys产品放在后台。我感觉到我的压力骤减，主要原因如下：

        （1）受Cordys产品限制、制约，大幅减少；

        （2）采购Cordys产品厂商现场技术支持服务紧迫性降低，能避开公司人员划拨动荡期；

        （3）采购合作伙伴人员相对容易多了，因为JavaEE开发人员，人力市场上很多，而基于Cordys平台的很少见；

        （4）通过公司协调，新加入项目组开发人员，不受技术限制，能很快投入到工作中；

        （5）项目组成员沟通也顺畅多了。

        也许是高兴太早了。

        今天，在跟踪项目进度和计划安排过程中，感觉部分人员对需求理解不全面，存在核心顶层设计不清晰的问题，进度滞后。因此，紧急召集设计人员开会讨论。会议纪要中结论内容摘录如下：

        （1）设计人员对支撑流程可视化快速开发办的公能力平台的需求范围、内容、目标等基本信息比较清晰，细节可能需要沟通；

        （2）系统部署、使用范围为省公司+13地市；

        （3）要求系统按松耦合方式设计，支持数据适配、组件化、服务化；

        （4）要求系统能提供运维支撑，例如：服务监控、接口监控等；

        （5）要求系统能管理应用集群，支持在线部署、启停应用，某处故障不影响全局，保障系统稳定性。

        ……

        突然发现，基于开源JavaEE技术架构，系统运维、应用集群管理等平台能力，都需要自行设计和开发，这个工作量将是巨大的，还存在很大的风险。如果不设计这方面内容，那么系统将处在裸奔状态，故障时只能重启服务，还不可控。这是不可能的。而这些能力却是Cordys产品自带的原生能力。

        怎么办？

        改设计方案，重新回到Cordys平台上（因为没有第二套可行的方案），再加HTML的技术架构。

        最后，设计人员终于认可去年年末的0.77版的技术方案（请参考方案原型《云计算统一办公运营平台服务能力设计方案》，以及2013年的博文《使用云技术升级改造现有应用系统的思考》）。

        出现这种情况，是好事，不实施哪里知道方案可行性，只是这条路，弯弯又漫长。

        总结以下三点原因：

        （1）我对需求宣讲不清，遗漏重点了，比如0.77版方案中（150多页），有大篇幅Cordys平台产品的特性没有讲清楚，反而对于这些特性，用户、客户都了解。也想当然认为设计人员都了解了；

        （2）缺乏培训，设计人员对产品、相关技术标准认知不统一，例如SaaS模型的定义（参考《 在IT系统中使用多租户技术提供人员跨部门及虚拟团队的解决方案（草稿）》）。

        （3）最关键的一点：缺乏稳定的开发团队，特别是在信息技术快速发展的今天，松散、临时组建的团队，缺乏沟通上下文环境，沟通成本、时间成本、返工成本的产生，是必然的。

        可惜，能有多少人认识到这一点啊，说不定还可能认为我给大家挖坑呢。殊不知，我也刚刚发现，我也掉坑里了。感慨郁闷！

        项目管理，就是这么回事，每次遇到的情况都不一样。