软件开发项目管理：第一次深入思考 - 公爵书房

2月

本文最后更新于2023年09月02日，已经过了31天没有更新，若内容或图片失效，请留言反馈

前言

整理资料，偶然发现自己十多年前写的一篇总结，当时参加工作三年，第一次做项目经理，带了第一个项目，感想颇多，所以写了这么一篇东西，满满的、认认真真的“青涩”。

简单整理一下，做一下“脱敏”，基本上原汁原味贴出来，重温一下自己的“青葱”岁月。项目名称就叫“A项目”吧，第一个嘛。这是一个软件开发项目，受客户方委托为其通信网关设备开发软件部分，包括通信协议互联互通和人机接口。

关于项目管理的思考

通过A项目的实践，越来越认识到项目管理工作在一个软件开发过程中的重要性。在A项目的实施过程中，的确学习到和感悟到了许多自认为有用的东西，想法还不是很成熟，记录下来以备忘。

我总是想把自己学习到的某一方面的东西纳入一个体系，于是，在这段工作实践中我的头脑里逐渐形成了下面的模型，它描述了目前我对项目管理工作的理解。

这个模型由四部分组成：产品的风险和质量、开发流程、管理制度、团队建设。其中“产品的风险和质量”是项目管理最核心的东西，其它部分都是围绕这个核心，为核心服务的，它们对这个核心所起的作用，也是由外到内逐步增强的。

产品的风险和质量

在产品开发过程中，始终会面对两个关键的问题，一是产品的风险，二是产品的质量。这里所说的产品的风险，主要是指技术风险，在A项目中，通信协议与其他厂家设备互联互通是开发过程中最大的技术风险。虽然我们采取了很多技术手段和努力很好地解决了这个风险，但在项目实施过程中，也充分暴露出了我们团队的产品意识不强的弱点。

多数技术人员都是喜欢解决开发过程的技术难题和实现基本功能，这些工作对于他们才是具有挑战性的工作，才能激发他们的工作热情，而对于繁杂的保证产品质量的工作，明显不够重视、缺乏耐心，也就是说产品的质量意识不强。在A项目中，我估计如果只实现基本功能大概只需要30％的工作，而要做到功能完善、性能稳定，又多付出了70％的努力。打个比方，前面30％的工作是伐木工人的工作，后面70％是木匠的工作，通过伐木工人的工作，可以得到一块好的毛坯，但此时毛坯的价值还主要是原材料的价值，通过后面木匠的70％的工作后，毛坯变成了精美的器具，此时材料的价值和人的价值得到了最大的体现。

在项目的后期，我时常问自己：一群高手真的能做出好的产品吗？客户方的一位资深QA的看法是“未必”。他说在以前一个项目中可以说高手云集，但后来那个项目却做得很糟。可见，如果没有一个好的开发流程做保障，或者不去遵循产品开发过程的一些规律，即使是高手，在项目中所起的作用也是有限的。

开发流程

客户方的开发流程管理应该说是比较成功的，虽然它还有一些缺陷，还有一些值得推敲的地方。说它成功是因为：首先，客户方的开发流程管理没有流于形式，而是真正贯彻到了产品开发过程中去了；其次，在A项目的开发过程中，的确看到了这套机制的效果，真正指导了我们的工作并保证了非常好的产品质量。我的一些理解如下：

先从软件开发过程与传统工业生产过程的区别说起。如上图所示的V字模型，在它的每一个环节都要输出满足质量要求的文档（或代码）。从这个流程上看，它是很机械的一个东西，看上去像传统工业的生产流程，但其实并不是。传统工业和软件业的差别很大，在传统工业中，机器的重要性占80％，人的重要性只能占20％；而在软件开发中，人的重要性占80％，机器的重要性只能占20％。所以，我想这个V字模型的实施，应该是主要在“人”的身上，也就是说，软件开发过程的管理主要是对人的管理。
淡化个人对项目的影响，靠制度去保证项目。在A项目的实施过程中，我越来越感到个人对这个项目的影响越来越小，这包括两个方面，一是人员变动对整个项目的影响变小，二是个人水平对整个项目的影响变小。因为在项目开发工程中，我们非常强调知识共享和集体的监督，也就是说自己做的一部分工作，要得到大家的认可，如设计文档的审阅评审，代码走读，重要的技术方案大家讨论决定，各个模块的接口要由各个模块的负责人共同约定，这样即有效避免了个人对技术的“垄断”，同时也减少个人的错误留在项目中的机会。
通过统计的办法，去量化开发过程。我觉得软件产品和传统工业产品另一个区别是：软件产品逻辑密集。一个几万行代码的产品，实际就是几万个逻辑的集中体现。所以对于一个大型的项目，达到代码或逻辑的完全正确、系统的最优化是不可能的。在A项目中，每个阶段都有质量目标，这个质量目标有下限和上限，只有发现的问题数落在在这个范围内，就认为是可以接受的，就可以进入下一个阶段了。不同软件产品的技术实现方法、应用环境、开发队伍的成熟程度，都在很大程度上影响产品质量，所以还需要针对不同情况，根据经验调整质量目标。在A项目中，由于存在与其他厂家设备的互通问题、外部接口过多问题，所以在最后的系统测试阶段就适当地调高了质量目标，最后的测试结果表明，这种调整是合理的。
在这个项目实施过程中，我也体会到了实行这些规范的开发流程需要很高的成本，如输出文档、代码的评审，需要很多人力和时间，客观上使项目开发周期延长，建立产品质量数据库需要一个积累的过程，所以有些做法不一定适合规模小的公司。但是，CMM的过程管理可以看作是一个完整的过程，也可以看作是一个个具体的手段，这样就可以在项目中逐渐应用这些手段。

在A项目中，我们的一些工作方法取得了很好的效果：

我们的开发流程总体上符合V字模型，但考虑到成本、质量、时间这个三角关系，我们是做了一些变通的。如A项目一期的工作，由于主要是追求速度，所以就没有严格按质量目标去操作，这是合理的；二期主要是追求质量，所以质量目标实现的比较好。在开发过程中，以过程去保证质量，而不是以测试去保证质量的思想，落实的也比较理想。
充分的需求分析工作使整个项目站在了一个比较坚实的起点上。首先，在这个阶段解决了大部分的技术风险，即使是没有解决的风险，在后期也是基本可控的。后来的工作表明，这个阶段出现的问题，如其他厂商设备的信令机制没有分析清楚，最后代码的调整比较大、比较频繁，使设计阶段、编码阶段和测试阶段的一些工作变得没有意义。其次，实现了一些原型，虽然这些原型最后是要丢弃的，但它大大降低了整个项目的风险。而我之前所参与的项目，没有一个明显的需求分析阶段，准备工作明显不足，在项目实施过程中很多时候纠缠于技术攻关、调整框架、修改BUG，浪费了很多时间和精力，得不偿失。
周例会制度贯彻的比较好。在周例会上，一是总结上周的工作情况，对于工作中出现的问题，制定解决办法，对于好的经验，及时推广；二是制定本周的工作计划，明确下达任务、指定负责人、确定期限，及时调配资源，分析在下一步工作中有可能遇到的问题；三是讨论重要的技术问题，对于涉及项目组间的一些重要问题，或难度比较大的技术问题，大家共同讨论决定，对于规模比较大的项目，会遇见很多这样的问题。
问题跟踪机制比较严格。对文档、代码的修改，尤其是后期系统测试阶段对代码进行修改，需要提详细的问题单，指定问题修改人，修改后要有项目经理或系统工程师确认并签字，这样做有效地控制了问题，最大限度地避免了由于修改问题而带来更多问题的情况发生，有效防止了项目的失控。
在项目实施过程中，我们的团队很明显地感觉到来自于产品部门和质量部门的压力。产品部门希望又快又好地拿出产品，质量部门关心的是在各个开发阶段是否达到了质量目标，我想我们研发部门本能地会想省一点力气吧。各部门的出发角度不同，就造成了一种牵制关系，使研发部门又要提高效率，又要兼顾质量，我觉得对整个产品的效果还是比较好的。

管理制度

在这里，只提一下在我工作中遇到的一些比较不好处理的问题：

压力下传比较吃力：我觉得软件开发有一个特点，就是需要有一定的压力才能把东西做好。有些技术难题，可能加一把力，加两次班就可以搞出来；文档和代码的质量，只要再细心一点就会比较完美。如果没有压力，好多问题就可能被忽略掉或遗留下来；而压力过大会影响情绪，打消工作的积极性。我们所面临的问题主要是压力传达不下去，尤其到项目快结束的关键时期，有一种力不从心的感觉。
对于工作积极性不高或绩效不是很好的成员，缺乏有效的刺激手段；对工作积极性高或工作绩效比较好的成员，又缺乏一种有效的激励手段。
工作中如果意见不一致，如何协调也是一个问题。我想是否可以建立一种工作制度，就是一个人可以保留自己的意见，但要和大家的步调一致。

目前我所能做的只是：带头工作，为大家做一个榜样；在团队中建立良好的个人关系；不断地做思想工作，用自己的观点去影响别人。我感到这样做对责任心强的人效果比较好，而对责任心不强的人或个性比较强的人就没什么效果。至于建立一些管理制度效果是否会好，我也说不清楚，只是一些想法而已。因为我觉得“过于繁琐和严密”的制度象是一把双刃剑，可能短期取得了想要的效果，但从长期考虑却破坏了项目组的合作、团结氛围，降低工作效率。

团队建设

如果说技术问题对于一个项目负责人来说是首要任务的话，那么团队的建设就是第二个重要的工作内容。我觉得团结、积极向上的团队氛围对一个团队来说是非常珍贵的。不同性格的同事在一起，难免会产生一些磕磕绊绊。往往是工作中的一句不满、牢骚、批评或指责，说者无心听者有意，也许就影响了其他人的工作情绪。所以在一个团队中需要有人去弥合，去消除这些消极的东西。尤其在这种项目中，大家的立场不同，水平不同，这种影响就更多一些，更不好处理一些。总之，对于一个团队来说，技术难题并不可怕，可怕的是团队人心涣散、各自为政，没有积极性，没有责任感。

对于其他问题的想法

下面是一些零碎的想法，自己觉得有用，先记下来：

项目负责人的首要任务是保证整个项目的保质保量完成，所以在工作分配时上应该留出足够的时间去发现和解决开发过程中存在的一些问题，关注一些有风险的技术点，协调资源，解决与客户方出现的一些问题。
技术方面，需要对项目有一个整体把握，关注有风险的问题；对于大的项目，迅速培养技术骨干，这样对项目比较有保障，同时也为个人提供了充分展现自己的机会；合理分配资源，发挥每个人的长处，关注其短处；及时根据实际情况制定出详细的工作计划，合理分配工作量；多想一些将要发生什么问题，提早采取预防措施；少一些成见，善于接受新事物。
与客户方合作需要注意的一些问题：（1）在这种委托开发项目中，从根本上受委托方是处于劣势的，但在具体问题上，不能对方“错的对的”我们都接受，防止到最后承担不必要的责任；（2）营造坦诚、互信、互相理解的合作氛围，站在解决问题的立场上商量问题大家都比较容易接受，如果是盯着合同、规定、责任去做，事情就难办了；（3）多看到对方好的东西，对于对方的不足，主动用我们的思想去影响对方，毕竟大家在做同一个事情，事情做砸了对大家都不好；（4）注意保护自己，比如在接受项目时，在开发范围调整时，要充分考虑到困难，如果不能按时完成，应该及时反馈，沟通解决。