[讨论]软件流跟踪矩阵

老生

本人现所带的银行项目（07年开始）进行到现在已经第三阶段了，随着银行业务不断的深入，以及团队成员的不段变更，发现项目越来越难管理了，一段时间以来发现下面类似的场景：

        场景1：

              来了新的需求或者需求变更，需要花大量时间去分析现有各模块中与需求有关联的代码（编写代码的组员已撤离）；

        场景2：

              团队成员不断的变更，新进的组员无法短时间内进入开发状态，客户这边一般提的需求都需很快速的进行响应；

     为寻求此类场景的解决办法，一段时间都在思考是不是可以建立一个类似需求跟踪矩阵的文档，将软件各功能点的流程给管理起来，暂且叫此文档为软件流跟踪矩阵，到现在还未想出更准确的命名。：）

     软件流跟踪矩阵，顾名思义，肯定是要在文档中能直观的体现出软件各功能点的流程，那关于功能点流程的粒度如何把握倒成了一个问题，还有如何在文档中体现也是值得考虑的问题。发此帖征求下各位大佬们的建议，到时文档可共享下给各位。

    一、所体现功能点流程的粒度：

          1、功能点所涉及的数据表及操作方式（CRUD）
          2、调用其它功能点的外部接口
          （暂只想到这些，希望能起到抛砖引玉的作用，）

    二、文档中体现的方式：

          征求建议ING。。。


上一篇：PM能做什么
下一篇：如何管理多交付的项目的质量？

思步

mark一下。回头聊聊我的看法，不过，从看了这个帖子后，第一感觉是：项目管理策略有待于改善，这点从楼主说的场景1和场景2即可看出。

老生

恩，楼上所说的管理策略有问题是肯定的。。。

其实,看到场景一、场景二所描述的问题都与团队成员变更有关。。。

当然，前期没怎么重视文档的质量也是造成现在局面的原因之一，其，大家都清楚，项目真正开发起来，哪会有这么多时间去关注文档的质量，只是应付下银行的CMMI规范而已。。。

今天,在项目例会上对此也特别的进行了讨论,先看看大家觉得应该从哪几方面入手解决此问题,到时候再汇总下提出解决方案。。。

思步

今天又重复看了几次楼主提到的这个case，结合我自己的一些经历与感触，将我的想法简单说一下吧：


1、如果你是真正意义上的项目经理，建议你从“进度、成本、质量”这三个维度入手，先理一下你现在的项目整体情况。如果你熟悉EV（挣值）的话，其实通过图就可以很好的看出进度与成本之间的情况；至于质量，通过规范的产品实现标准，以及严格的测试（要特别重视测试），就可以把握好。
另外，如果你是严格意义上的PM，建议公司给你配备一技术经理，让技术经理去把握技术架构与代码实现上的事。你一定要特别注重“沟通”与“第一手用户需求的掌控”。

2、场景1中，用需求跟踪矩阵可以将需求与功能点关联起来，而与功能相关的代码实现，由相关技术负责人来把握。至于你说的“编写代码的组员已撤离”的问题，那是你们工作的规范没建立好，缺少详细设计文档，还有，工作交接太有问题了。
场景2中，新成员无法在短时间内进入状态，这是正常现象，可以先让其从简单的入手，由老员工指导（这可能会影响老员工的进度，所以，在安排项目计划时，一定要注意这点。正如“人月”中说的：增加人手，并不一定加快进度，也许这之间的沟通就占据了N多的时间）。

总结：出现这样的问题，就是忽视了文档的重要性，特别是需求（用户、产品）与设计（概要、详细）文档；还有，你没有定位好自己在项目中的位置，在项目中，你是“将军”，不要纠缠在“一线的厮杀中”，要统筹全局。在人员的配置上，你需要这些人手：需求、设计、测试，至于代码级的实现人员，相信通过正规教育及培训出来的人员，都可以胜任。

就说这么些吧，希望有借鉴作用。

老生

感谢管理员的一些建议，其对于你所说的几点，给予一定的说明，希望能继续深入探讨下去：

关于第一点：
    从严格意义上来说，我是项目经理、技术经理又是开发人员，至于为什么会出现这样的情况，就不多解释了，解释也没什么用。从项目定位上来看，现在的项目属于延伸性开发阶段，即客户已买断人/月，活多的时候累死，活少的时候闲死的这种。

关于第二点：
    前期项目是现在的项目总监带的，项目质量（代码+文档）就不多评论了。
   
我的总结：
    从管理员的回复中能看出如何在项目管理中细化工作，从而避免出现类似的问题，非常受用。但也忽视了每一个项目的现状和资源，当然这也与我没在帖中项目具体情况说明有关。
    其我自己一直对项目经理的职能定位是：项目经理不完全是要在管理上到位，把问题扼杀在萌芽状态，但也要在出现问题时，在现有资源的情况下去解决问题。

解决方案：
    经过这几天的思考，将从以下几个步骤解决帖中所提到的场景和问题：

          1、组织组员和客户讨论需体现软件流的一些要素

     2、定义详细设计文档和软件流跟踪矩阵文档模板

        2.1、所体现软件流的要素目前暂只想到那几点，更多的将在项目组讨论后再给予确定

        2.2、软件流跟踪矩阵文档里将整理详细设计说明书中所涉及的功能点并索引文档章节，并记录功能流中一些重要的元素（可作为需求及需求变更分析的参考文档，也可为新进组员提供指导性自我学习的文档）

     3、下阶段的主要工作是重写详细设计说明书（已向客户争取一定的时间去分析原有的代码并编写文档）

PS：
   欢迎各位大佬们继续深入展开讨论。。

[ 本帖最后由 老生 于 2008-10-23 21:22 编辑 ]

iamredeye

看来一定程度的文档还是有价值的，而不仅仅是为了应付CMMI。

还有就是，我个人觉得跟踪矩阵之类的东西都是听起来道理简单，用起来不太可行的手段。

另外人员流动太频繁恐怕是要解决的根本问题；文档只不过是头痛医头，脚痛医脚罢了。

坚持很美

路过的帮顶

年华似流水

以我的经验来看，楼主的想法是可以执行的~

橙子女

顶不错 支持下

雨落青屿念雁羽

以我的经验来看，楼主的想法是可以执行的~

鹿言

不错 支持一个了