XXXX项目管理目标（某项目实施后基于软件工程的总结）

        （注：此文作于2007年，算是个缅怀，或者是个吐槽。所有注都是本次发表新加的。原文中的省略号就是原文，并非删减。）

目录

一、序

二、态度问题

三、问题点

3.1 项目过程管理的问题

3.2 配置管理的问题

3.3 资源管理的问题

3.4 软件设计和编码的问题

3.5 交流和协作问题

3.6 其他问题

四、目标

4.1 明确项目管理机制

4.2 明确小组负责人的责任

4.3 明确使用版本控制进行配置管理

4.4 资源管理问题

4.5 设计和编码问题

4.6 交流和协作问题

4.7 其他问题

---

一、序

        XXXX项目已经完成YF上线及……，这个项目是……对……具有重大的意义，在……的正确领导下……全体同志……艰苦奋斗……不怕牺牲……深入贯彻……三个……八X八X……，取得……重大成就……获得……经济效益……社会效益……精神文明和经济建设双丰收（热烈鼓掌）！
        在项目开发和施工过程中也暴露出的一些管理和技术上的问题，考虑到未来的产品升级和全省推广，这些问题会对工作的顺利进行带来更大的影响，我们认为有必要加强项目管理、改进管理手段、规范开发过程。

二、态度问题

        态度决定一切
        ——米卢蒂若维奇（唯一带领中国国家男子足球队进入世界杯决赛圈的主教练）

        本文不打算讨论长征胜利的伟大意义，也不打算讨论女排精神曾经在社会生活中发挥的巨大作用，更不打算讨论高速增长的GDP与全球能源危机的关系。本文仅讨论XXXX项目目前存在的问题和期望的目标以及探讨一些达成目标所涉及的技术。
        注意，本文不打算谈论任何我们已经获得的成就和已经付出的汗水，本文只讨论存在的问题，如果讨论问题让你觉得不快，那么是你打开了错误的文件，请关闭本文件然后删除（技巧：删除文件时按住Ctrl键将不经过回收站而直接删除）。
        尽管本文谈论的都是问题，但没有人应当被指责。平心而论（微软拼音输入法推荐这个词，也许微软错了……），我们做得不算够好，但也不算够糟。至少我们看到周围很多项目做得比我们糟糕，也有一些做得比我们好。我们还要考虑政治因素，以我们的企业性质，我们受到比别人更多的政治因素的影响，在难以改变的政治环境之下，也许我们还有提高的空间。
        无论如何，承认问题是解决问题的第一步。

三、问题点

3.1 项目过程管理的问题

        1.    项目进度不清楚，有最终上线日期，但缺少（可验证的）阶段目标。
        2.    任务缺乏有效安排，工作强度在0%（完全空闲）和400%（不吃饭不睡觉也无法按时完成）的范围内波动。
        3.    争吵不足。缺乏设计阶段的讨论和评审使设计缺陷在整合阶段才发现，难以纠正。
        4.    缺乏有效文档。文档不是为了后续工作，而是为了应付客户（客户喜欢被糊弄？这是个政治问题）。
        5.    一个子系统对接口做了变更，没能有效地通知到其他子系统。

3.2 配置管理的问题

        1.    CVS成了摆设，有些人什么也不放。
        2.    CVS成了垃圾堆，有些人把什么都往上放。
        3.    源代码没有受控，多人共享一个拷贝，并不以CVS为准。
        4.    新写的代码在不同服务器同步数据时被错误覆盖，只能重写。（有人郁闷得想自杀）

3.3 资源管理的问题

        1.    关键表数据被误清除，而且无法知道是谁做的，只能重新运行程序。
        2.    系统中的垃圾越来越多，没人认领，又不敢删除。
        3.    因空间不足有些人擅自删除了别人的东西。
        4.    怀疑关键程序被随意运行。
        5.    怀疑关键进程被手工终止。
        6.    开放建表权限时随意建表，不要的不删除。
        7.    限制建表权限时建表过程过于繁琐。

3.4 软件设计和编码的问题

        1.    编码不规范，编程风格从58年到99年不等，缺少命名规则。
        2.    手工工作太多，缺乏辅助程序。当你要分别去查多张表的时候，你就需要一个辅助程序，比如一个视图或存储过程。
        3.    系统缺少总体设计，在很大程度上仍沿延续了旧系统的各自独立的设计方法。比如一批、二批这样的划分。
        4.    前后台脱节，前台总是依据数据模型开发，错了，前台要依据业务模型。
        5.    先实现子系统，然后才讨论系统的整合。可预见的后果。
        6.    测试不足，缺乏管理，测试过于随意。

3.5 交流和协作问题

        1.    两人用不同的方法修正同一个配置，结果还是错的。
        2.    信息共享不足，有些人会开发别人已经开发过的小功能。
        3.    知识共享不足，有些人会为某个问题困挠一整天甚至好几天，另一个人知道为什么。

3.6 其他问题

        1.    法律问题：源代码的版权声明基本上都是胡写的。
        2.    没人性，让女生通宵熬夜。

四、目标

        上述所有的问题都不是孤立的，管理投入的不足……技术经验的不足……缺乏正规训练……政治问题……制度问题……态度问题……文化问题……历史问题……美中关系问题……登月计划……
        1.    企业不是搞民主的地方
        2.    要自上而下的改革
        3.    没有人的参与，一切自动化管理工具都是扯淡
        4.    历史是个包袱，改革永远面临大多数人的阻力

4.1 明确项目管理机制

        项目经理对项目进度进行管理，项目被分为可验证的几个阶段，每个阶段的完成都要有有效的验证。使用较细致的任务分解结构。项目经理管理小组负责人。
        重要设计由项目经理组织评审，重要争议应在评审会议上解决，评审结论在评审会议上做出。不能议而不决。评审会议参与人员应尽可能扩大化。评审会议之前应有若干个小型讨论会议。
        项目经理（责成各小组负责人制定小组的开发规范并汇总）制作项目开发规范。各小组的开发以项目开发规范为准，不可随意变更。项目经理监督项目开发规范的执行。
        需要一个版本控制系统管理员、UNIX管理员和一个ORACLE管理员。
        据说从CMM1级到CMM2级需要18个月加上50万美元成本，天知道是谁说的……

4.2 明确小组负责人的责任

        小组负责人对项目经理负责，安排小组工作计划，核实小组工作进度，检查小组工作产出。小组负责人应清楚地了解本小组的所有模块、设计、产出，并大致了解所有代码。
        重要设计应进行讨论、评审，形成正规文档。小组负责人应审核本小组的所有产出（包括代码、文档、数据等）。

4.3 明确使用版本控制进行配置管理

        配置管理员（SCM工程师）通过版本控制系统管理项目的所有产出，包括但不仅限于代码、可执行程序、数据库结构、数据、脚本、可执行程序、文档、会议记要、评审报告、培训材料、重要邮件。
        版本控制系统是获取项目文件的唯一方式。
        SCM工程师复负责审查版本控制系统的数据是否符合要求，存在于版本控制系统的每个文件都应有说明，不允许随意添加文件，应能正确区分当前有效的和已过期的文件。
        每个人都要理解版本控制系统里的东西才是被认可的，任何东西在提交之前都不被承认，要想理解这一点必须让每个人都使用独立的身份在独立的位置进行开发，不能共享同一个拷贝。
        VSS比CVS好用得多，但DCN接入时不能访问Windows网络，可考虑责成系统组解决这个问题（理论上不应有此限制）。
        SAMBA服务也可能提供有效的帮助。Samba是UNIX服务，可将UNIX机器加入Windows网络。
        ORACLE的版本控制可通过导出数据库脚本的方式进行，脚本可以方便地用版本控制软件比较差异。原则上PowerDesigner或VISIO文件属于设计文档，不应该用来做版本控制。（PowerDesigner我不是很懂，也许我说的不对……）。静态数据也可以通过导出脚本或SQL*Loader的导出文件进行版本控制。

4.4 资源管理问题

        必须能够正确区别用户身份。每个人拥有唯一的UNIX主机用户、ORACLE数据库用户、版本控制系统用户、其他。如果能够统一这三+X者当然是最理想的，至少微软公司的产品可以做到。
        UNIX主机用户可以使用组获得适当的权限，在自己的主目录工作，源代码来自版本控制系统。这个容易做到而且（理论上）必须做到。
        ORACLE数据库用户可以通过角色和同名获得适当的资源，也许需要编写很多管理脚本，ORACLE愚蠢不是我的错……
        版本控制系统用户一般只能有提交权，删除和添加都是受限的，销毁历史的权限只能由管理员掌握。
        不允许不设密码。密码被盗用至少要负连带责任。

4.5 设计和编码问题

        使用编码规范。
        统一命名约定。
        任何全局名称的命名必须经过评审。全局名称包括代码里的模块名、类名、全局变量名、全局函数名、数据库的表名、过程名等。
        加强设计。对设计草案进行讨论，对设计进行评审。尽可能扩大参与范围（CMM3级称之为同行评审）。
        前台参与业务。以业务需求为依据进行前台设计。
        要有起码的文档。
        改进测试。

4.6 交流和协作问题

        定期会议。了解相互的工作，提出技术问题。
        可共享的信息文档化。项目的公共库必须文档化。

4.7 其他问题

        法律问题由项目经理解决。
        加班问题由项目经理以上级解决。

（这里是结束）