项目管理中的矛盾论

“跟着毛委员，天天打胜仗！”，当我们回忆起井岗山革命斗争的那段历史，无不佩服那无与伦比的军事斗争艺术，敢于打破权威思想，坚持理论联系实际，他与党内一个又一个派来的“钦差大臣”们的争论，“土”与“洋”的争论，都非常精彩。后来写了一部哲学名著《矛盾论》系统的阐述了这一哲学思想。在和平时期的我们，如果把这一哲学思想运用到工作中，运用到软件项目管理中，是不是也能“天天打胜仗”呢？

现实中一个软件项目能够“按时、按质、按量”的完成，并且能够让客户满意是非常不容易的，为了提高软件项目的成功率，很多公司制定了一系列的流程，引入诸如”CMMI”等流程标准，不时的变动组织架构，唯一的目标就是确保项目的成功，并且一直能成功下去，“从胜利走向胜利！”。

流程制定当然是必须的，一个军队里也会有各种各样的流程守则，比如士兵训练守则，挖战壕流程，冲锋流程等等(猜想)。一个经典例子的是戚继光制定的《鸳鸯阵》，对于防守、攻击；远攻，近攻；平地、巷战等等都有天才的设计。老板、项目经理们梦寐以求的“宝典”也不外乎此类了。然而，幻想一个流程解决所有问题，起码在软件工程领域内的项目中，还很不实际。软件工程中变数太多，因素太多，最基础的工作都需要人来作出思考和判断．这就需要更多的智慧和经验。在保证基本的流程运作顺利基础上，还对“将”的要求很高。如果说流程是“兵法”的话，项目经理要懂得灵活运用，决不可以“纸上谈兵，生搬硬套”。而要学会运用“矛盾论”。

基于对<<矛盾论>>的一些粗浅认识, 结合我的一些经验, 于是我有了下面的见解。

普遍性和特殊性。

之所以单纯引入一套先进的流程不能解决问题，原因也就是事物的普遍性和特殊性。一套流程在A公司运作的好，未必就在B公司运作的好，苏联革命可以在城市中进行，在中国就必须要“农村保卫城市”。CMMI 所阐述的思想并不是针对某个特定的公司的，而是从一个最普遍意义上的软件项目考虑，把它们的共性提炼出来，得出理论上的推理。一个公司完全按照CMMI思想去制定一套流程，不一定就解决了所有的问题，很可能还会产生更多的问题。在引入CMMI的时候一定要结合公司现实，在不能洞察公司特殊性就全面实践CMMI思想，一定会出问题的。

CMMI中有“Stage”和“continue”两种描述方式，Continue是按照过程类来编排，Stage是按照成熟度来编排的，很多公司热衷于Stage方式，CMMI –3, CMMI-5的评级，当然这样有助于公司的宣传，有助于项目的竟标，然而，对于一些公司来说，这种方式并不适合，这样做反而会得不偿失，Continue方式才是合适的选择。比如有些公司的IT开发部门，他们和专业的软件公司有很大的不同，只需要专心实践有限的几个过程域即可。

对于每一个项目的开发过程来说，也要对流程进行剪裁，以适合本项目的特殊性要求。A项目中开发人员能力欠缺，我就要对设计人员提出更高的要求，B项目需求多变，我就要先做模型开发，C项目技术相对成熟，我就可略过可行性分析评估．．．

有一个提法叫”光环效应”, 成功的企业凭着耀眼的光环输出自己的管理思想, 然后众人开始热烈追捧, 无数的公司着手引入这些先进理念, 然而少有公司成功。 为什么? <<从优秀到卓越>>畅销多年了, 能够做到卓越的公司还是少之又少, 根本原因就是没有认识到本公司的特殊性, 没有切合实际, 和烧香拜佛的迷信活动并无本质区别。

那些名将在战场上可以一眼识别出战争的关键处，从而采取不同的策略。岳武穆曾曰”运用之秒,存乎一心”．可见，很多不能言传的秘诀都有它的哲学根据。

主要矛盾和次要矛盾。

通常我们对项目经理的认识是，他负责项目的定义、设计、构建、测试全过程，日常就是分配任务啊，验收任务啊，开会啊等，就像一个“当官的”。如果这种认识被固定在项目经理心中，那会产生非常消极的后果。

一个好的项目经理，他应该对项目有清晰的认识，知道当前的主要矛盾，并投入大部分的精力去解决，他没有固定的工作范围，他可以做任何他认为有必要做的工作。历史上，有在后方运筹帷幄决胜千里的将军，也有亲临前线冲锋陷阵的将军，将军要不要甘当士卒，冲锋陷阵，完全取决于战场上的形式，也即是当时的主要矛盾，如果士气高涨，士卒个个如狼似虎，将军完全可以安坐于中军大帐中。

对瞬息万变的战场情势能够洞若观火的，才是名将之才，同样，能够对项目每个时段主要矛盾的认识，也是项目经理必修课。有的项目客户看重的是UI，那么我就要重点监督用户界面的开发并及时拿去找客户，有的项目主要矛盾是性能，那么我就要化大的力气在优化性能上，如果某个项目客户很“刁”，那么项目经理就要找点时间多和客户搞搞关系。当然了，如果某个项目根本就不可行，而是老板为了其他政治目的立项的，那你就要为避免成为受害者而留个心眼。

我们经常犯的一个错误就是化太多的时间和精力在次要矛盾上，并不是说处理次要矛盾本身错了，而是它占有了大量的时间和资源，从而没留下足够的时间和资源来处理主要矛盾，这是一个非常频繁并引起很多争论的问题．一个典型的例子是一个项目的主要矛盾是需求变化频繁，而且客户的要求还必须做到，有些人就把大量的时间资源用到了需求管理的流程和文档资料的完备，其实如果能做到良好的设计和代码，来支持未来的变化，从而使未来处理需求变化所用的时间和资源更少，这样或许更有效的降低此项目的总成本。

在分析和系统设计的时候, 有些设计者往往花更多的时间去使用工具画图, 而留给思考的时间并不多, 本来设计师在草稿或者画板上工作最惬意, 因为你可以根据自己的思路自由的去更改, 而一旦被工具所束缚, 除了花大量的时间去学习, 却仍不容易做到准确, 而且早早的画到了Rose上, 记住人都有惰性的, 频繁的去推翻好不容易画好的图形可不容易做到。

当开发人员的代码质量不高时, 主要矛盾是代码而不是测试, 如果你一味加强测试时间,将使开发者和测试者疲于奔命, 效果却甚少改进. 一段代码, 有经验的人细细审查, 找出可以改进之处并改之, 无数潜在Bug便消失了, 试想如果指望在测试阶段发现这些问题, 要花多少力气？

静止与发展。

能够正确地找到当前的主要矛盾，是很了不起的，我强调”当前”的意思是说明主要矛盾一直在变化，解决了一个矛盾，会有下一个矛盾等待你，过几天，当前的次要矛盾就可能成为主要矛盾，一切事物都在变化．所有的变化都不应该引起你的惊讶，都需要你用智慧和技巧去应付。

需求不是静止的，设计不是静止的，代码更不是静止的，这个道理大家都懂，却少有人能从心理接受，回想一下，开发者对不断变更的设计是否很愤怒？你对客户一会一个主意是否很反感？你是否认为完成一个功能的代码就可以丢下不管了，除非出现Bug？

<<重构>>是和<<设计模式>>齐名的一部书, 很多人热衷于研究一个一个“模式”, 而对“重构”却缺少兴趣. 在我看来, <<重构>>是更重要的一部书,具有更现实的指导意义, 因为它告诉了我们一个简单的道理: 没有人一开始就能做成优良的软件设计, 根据这个设计直接写出代码, 然后一切OK. 就算<<设计模式>>作者这样的大师都没这个能力, 相反, 书里面列出的设计模式无一不是在重构的基础上, 在大量实践的基础上不断优化和思考而来的!

迭代开发的思想也来源于此, 如果事物都是静止的, 那就不用一遍又一遍的去修改或者重做你的工作了, 迭代开发让人不适应, 因为我们习惯于开过评审会议后, 长长的舒一口气, 终于可以放下了, 然而你我并不知道, 评审并不能做到全面和深入, 只有你自己心里有数, 同一个工作, 也不可能一遍又一遍的开评审会议, 我们花不起那么多时间, 更多的要依靠工作者自己的责任心和对逐步求精思想的理解。

理论与实践

“知行合一”是明代大哲学家王阳明先生提出的主张之一, 他本人也完全实践了这一思想, 作为明代最牛的人物(愚见), 王阳明是中国历史上屈指可数的几位既“立德”、“立言”又有“立功”的牛人之一。 虽然我对此的理解仍然肤浅, 的矛盾论也仅知皮毛, 不过还是觉得如果我们能够把一些哲学思想用到自己的工作实践中来, 而不纠缠于”屑小思想”的束缚, 一定能够”从胜利走向胜利”!