一次成功的项目管理实践

        月初参加公司给安排的项目管理课程。做软件的嘛，做方案的嘛，早晚要接触到项目管理。想必听听对工作有用。没想到今天第一次从中受益，并非是当项目经理，而是作为项目成员给自己加分。记的项目管理第一节课，老师就说，项目管理绝不仅及是用在软件开发，或者工程管理。生活中无处不是项目，买个房买个车，出去玩一趟都是项目管理实践的机会。现在想起来说得太对了！
        事情从上周说起。周四上午10点我接到Leader给的任务，负责编写一个小模块，用于加载配置数据。需要开发的只是一个类，其中有一个主要的方法load()负责用磁盘上的配置数据在内存中构建一个结构化的数据对象。本来Leader已经基本作好了的一个版本，只是现在由于需求变化，需要改变配置数据的格式和内存对象的构造规则。因此我基本上要重新写load()中的逻辑来符合新的需求，并且要考虑为以后需求变更提供一些可扩展性。配置数据放在一个三层XML中。我需要读取，解析，然后放到一个对应的三层的Map结构中，就是一个Map套Map一共三层的多叉树。我管每个Common叫“不定式”，三层一共三个一元不定式，三个一元两两配对形成三个二元不定式，三个一元同时叠加形成一个三元不定式。一共7个不定式需要在各级循环逻辑中处理。看来这个XML的确比较复杂，更麻烦的是受外界条件限制不能为它定义Schema。
         按照通常的软件开发习惯，首先分析边界条件。比如什么情况Common覆盖Special，什么情况补充Special。 然后写测试用的XML，包括一些测试边界的数据。最后把逻辑流程写到纸上，并标识测试的观察点和异常情况。由于考虑扩展性和最大程度减少数据冗余，逻辑做得比较麻烦。先要把所有Special的数据加载成对象，然后用Common数据来根据情况修改所覆盖Special数据。经过两个小时，设计做好了。用大脑模拟运行几次，没有问题，去和Leader讨论。Leader听我讲了思路，首先对我的设计表示认可，认为能想到的各种情况都考虑到了。但同时他也提出顾虑，主要是这个逻辑写起来会很麻烦，费时间，其次以后别人阅读不容易理解，而且后期超出对目前弹性范围的需求变更的修改会比较困难。讨论了一阵子，发现也没什么更好的办法，因此决定先做做看。这时已经是周四下午4点多了。
        既然设计已经通过认可，我开始着手写逻辑。解析XML是使用JDOM和XPath。开始写发现这个东西比较烦，层层嵌套，层层拆分。代码编写进度比较慢，稍不留神就迷失在嵌套的从林中。到了晚上9点下班，已经处理完一个一元不定式。回家继续努力，到半夜快2点的时候，终于把这个load()写完了。
       第二天早晨，强打着精神来到公司，继续对这个类其他方法编码。到了中午开发部分一切已经搞定，开始测试。由于前期设计工作作得充分，测试并没有太痛苦。因为逻辑做得完善，所以自己思路还是很清楚的。通过第一轮测试发现Common和Special的优先关系都反了。通过Debug跟踪代码发现自己对xPath的//理解有错误，于是反复修改测试。到下午4点半一切搞定，所有测试数据和边界条件都符合设计。上交代码和测试数据，下班回家。离开公司前Leader让我手机一直开机，发现问题随时需要我修改。但我对自己的作业是信心十足的。实际也证明，一个周末我的手机一直安安静静。
       这周一早晨来到公司，第一件事情就是问Leader，我那部分与其他部分合的怎么样。Leader很心疼的看着我说，上周我交的代码很不错，但现在需求变更，需要把配置数据再增加一层。当时感觉自己一阵眩晕。三层已经让自己很困扰了，好不容易解决又弄出个第四层来。三层的时候最复杂情况是遍历三层原数据再累加遍历三层构造一半儿的多叉树对象，一共是6层循环。现在源数据加到第四层，逻辑就是8层循环，代码量也会相应大很多。此外的变更是以前Common用于填充所有叶子，现在改成只填写存在的叶子，因此要增加判断逻辑。更要命的是必须尽快做完，顶多给2天时间。因为我的模块需要被其他业务Pipeline调用，而目前其他业务模块基本都做完了，就等着我们这块完成之后做单元测试。Leader看我为难的样子给我出了个主意，把我以前的设计方案推倒，重新设计配置文件的格式，并且重新构建数据模型。颠倒数据装载顺序，先读取不定式，然后读取相对special的数据，但这种方式依赖每个XML元素中子元素的顺序。按他的建议，我前期做的工作除了让自己对这各模块的业务熟悉之外，其他工作基本都要被抛弃，而且新的思路对增加了XML文件中数据有序的约束，降低了灵活性。好处是如果以后别人读我的代码或修改我的代码会比较容易，而且总体使用时间会比继续按我第一版的时间少。的确他说的有一定道理，降低扩展性，减少初期开发时间，如果没有更多需求变更的确这种方案比较经济。这时我必须做一个决定：继续 在我第一版基础上修改，或是推倒重新做第二版。
        正在为难的时候想起了项目管理课程中讨论过的一个话题：是否完全依照客户意愿在项目进行期修改需求会直接影响项目验收效果。往往通过讨价还价尽量减少需求变更会对验收有利。分析当前的情况，包括了两种变更：业务需求变更和数据结构／算法变更。前一种变更看来是无法免除的，因为这本来就是个潜在变更，而我做是前期我们做需求分析时没有考虑到。第二种变更完全是客户（也就是我的Leader）应对第一种需求的一种策略，目的无非是解决第一个需求。我推想，如果我能把第一个需求解决，他也不会非要求我再按照他的设计重新开发，但风险是我必须按期完成对需求变更导致的开发。寻思良久，我还是决定铤而走险，用一天时间继续按第一版方案修改。如果到明天早晨我不能交付代码，那我就彻底放弃第一版进而开发第二版，并且必须在后天早晨之前完成。后面的事情可想而知，从上午一直工作到半夜，疯狂的工作，舍弃一切没必要的代码，比如调试部分及必要的注释。第二天早晨再到公司虽然晚了一些（早晨实在困的起不来），但心情轻松了许多，而且顺利的通过了他的测试。虽然我告诉他我没有按他的要求完成变更的第二部分，但已经完成了第一部分。如果他坚持认为必须完成第二部分，我会在第二天早晨提交给他第二版。他想了想，似乎也意识到相比之下重要的是尽快交付这个模块，于是对我的工作表示认可。我不但提前完成了任务，还可以让自己后面几天轻松的等着别人的进度。
       这是我第一次在工作中有意识的利用项目管理的知识，和从中尝到甜头。和以往抱着不加思索的满足客户需求的态度相比，适当的策略及技巧在满足客户需求的同时让自己更多的获利，对客户和自己双方达到共赢。看来项目经理的课程远不仅对做“项目经理”这一职务有用，而且为参加项目的成员相互协作提供方法指导。