软件外包项目管理指引

Posted 2020-09-24 MeteorSeed

　　如果不去亲身经历几个外包项目，读者是难以想象这种“焦油坑”的恐怖。外包项目因为规模较大，涉众较多，在管理上往往更为复杂。本文，阐述外包项目的特点以及笔者的管理经验，希望能便帮助读者管理好外包项目。

1 项目中常见的问题

常见问题	现象
范围	需求难以冻结，处于“变更-修改-测试-变更”的死循环中。
质量	文档质量问题，如：关键文档缺失，没有能按照统一要求编写文档；文档内容前后不一致，有歧义，预期读者无法理解，文档版本与代码版本不同步等。 编码质量问题，如：不遵守编码规范，可读性差难以维护魔数泛滥，关键代码无注释，代码检查出现大量警告，滥用语法导致性能瓶颈等。 系统质量问题，如：不写验证，安全漏洞，异常频发，内存泄漏，日志缺失，不支持大量用户，运行缓慢等。
成本	前期成本估算误差较大，缺乏足够依据。 后期没有对成本进行量化分析。
进度	项目经常延期或者是匆匆上线。

 

外包项目中凸显的一些问题	现象	解决方法
前期准备不足	需求质量问题，如：遗漏需求，需求不明确，需求描述前后不一致，需求存在歧义等。 开发环境问题，如：配置管理、开发、测试、Bug跟踪、项目管理等环境搭建无法满足工作需要。 流程问题，如：是否已经建立了周知的工作流程，是否已经具备了相应的范本、检查标准和公约。	尽快梳理需求，搭建环境，建立项目所需的最基本的生存环境。 制定计划时，充分考虑到这种情况，识别潜在风险，预留足够的风险储备。
人际关系复杂	干系人数量庞大，其需求各有不同，可能存在需求之间的冲突。 涉及多个供应商、提供商，项目进行中会有开发团队之间的矛盾冲突。 在人员混编团队中，会发生外部人员难以管理甚至罢工的可能。	必须明确掌握核心干系人的职位、职责和角色，加强沟通，做好干系人关系维护。 遇到问题要协调多方负责人协调解决，不要带感情色彩。
资源问题凸显	人员储备不足，开发用机器配置较低编译缓慢等。 外部人员能力参差不齐，且难以管理。 人员离职频繁，资源严重不足。	尽量参与到人员招聘中，对能力不达标的在职人员进行培训，尽量不要劝退。 磨刀不误砍柴工，必要时，申请合理的硬件资源。 在进度计划里安排单点技术的交叉培训，以应对该人员离职时的冲击。
PM没有足够权利	受制于多个上级领导，对甲方决策无力抗争，对项目组内的甲方人员难以管理。	和领导搞好关系，加强沟通，自己权限外的找负责人解决。
地域和文化差异	封闭开发时的伙食问题，如：上海人不爱吃辣的，回民不吃猪肉等，这些问题他们都会找PM。 沟通问题，不同地区语言文化差异，尤其是远程会议时，可能会在理解上有阻滞。	及时和甲方沟通团队成员的合理诉求，要敢于维护团队的利益。 认识到理解上有疑惑时，及时沟通，不要碍于面子不去张口。
加班	加班导致离职。 加班导致士气低下。 加班导致消极怠工。 加班导致代码质量低下，Bug频发。 加班会导致疾病甚至过劳死。	合理的安排赶工，对不合理的要求说“不”。 尽量为加班程序员争取利益。 身先士卒。 合理安排计划，预览风险储备，尽量做到在节假日不加班。
需要PM参与设计和开发	PM想要扮演架构师和程序员的角色。	优先完成关键路径任务，利用碎片时间参与其他非关键任务。

　　

2 项目管理经验总结

• 促成一致意见 多数外包团队看中的是程序员编码能力，而不是合作的能力。PM需要做两件事情：第一，确保讨论不要被一个人或一种言论所支配，当然共识的除外；第二，帮助不敢发言的人或说不清楚的人表达他们的意见。PM大多时候需要促成团队的一致意见，如对编码规范，周知的项目组约定等。促成一致意见需要轻度的领导，高压政策下的一致意见，不能反映出团队的意愿。PM在促成一致意见时最重要的是保持中立。需要知道，集体的决策比从集体中的个体独立做出选择更具有风险倾向。如果将这种决策模式应用与软件项目，很可能会看到这样的结果：更复杂的结构和算法、过度的质量、过度的扩展性考虑、范围浅变等。这是因为开发者并不会考虑项目的整体维度，而只会关心编码。因此，对于PM促成一致意见，不等同于从众或折中，有些时候单独的做出决策才是对的。因此，并非所有决策都倾向与群体决策，群体决策会产生一种负面影响，即——个人贡献和能力将降到最低。作为PM应该，清楚这种负面影响，并为团队营造一种鼓励和支持“创新”的大环境。不要让团队中形成小的团体对立，这样，任何人的出头行为都很招致小团体成员的怨恨。这种现象在外包团队更为明显，因为可能源自不同公司，会不同时间入职。不要让这种风气在团队中成为主流。另外，不要轻易的折中，因为折中往往会失去亮点。
• 明确优先级 PM必须面对现时，项目是技术和经济结合的产物，受制于多方制约，需要综合分析这些制约因素和用户诉求，制定合理的优先级。
• 为团队争取好的办公环境 外包团队的工作环境通常比较恶劣。IT业公认的：更安静、更宽松的工作空间对提高编程效率有作用。如果能够让团队整体在一个独立区域办公应该是极好的了。但我们也得面对现时，外包团队不会有很好的待遇，因为，至少作为PM我们应该争取不要让团队分散，因为那会提高沟通成本，和沟通中的噪音。另外，被分出去的开发者会感到孤立，进而与其他人员疏远，长期下去不利于团结成员间的协作。
• 让开发人员少受打扰 编程是一种耗费脑力的持续活动，开发者不喜欢被打扰，愿因很简单，打断思路会影响编码。所以，很多时候大家会听到程序员抱怨说“我不是网管”。在外包团队中，打扰就不那么简单了。程序员与关键用户的比例是极其悬殊的，开发者会经常被打扰，解答各种无聊问题，甚至和甲方闹矛盾。这不是个好现象。PM需要做两件事情：第一，明确角色职责，并让甲方人员清楚，有问题了该找谁，不要一个问题在团队中踢皮球；第二，明确向甲方表示，投诉直接找PM，走投诉流程，别单独去和开发者理论，如果矛盾激化，之后很难处理。
• 管理牛仔 无疑的，牛仔程序员是能力很强的，但却缺乏团队合作概念。牛仔程序员如果放任不管，那么他往往会写出别人难以理解的代码。他们特立独行，不愿与人合作，并且喜欢在代码中烙印自己的风格。虽然程序员们都有强烈的性格倾向，但牛仔显然更加突出，他们往往不是那种喜欢与人交往的类型。牛仔程序员具有以下特点：他们反对任何形式的标准、约束和规范，不喜欢受他人的监控，也不喜欢和他人协同开发。追求创造性多过考虑软件可用性、可靠性和成本。外包团队中，不要去尝试改变牛仔程序员，这不是短期能做到的。牛仔对团队是否有益，取决于PM。好的实践是：第一，将整个工作分解，把相对独立的、具有挑战性的工作分配给牛仔。这些工作应该尽可能独立，与其他工作之间只存在简单的接口，不需要与其他人员频繁的沟通；第二，对他们的工作进行监督，不能忽略这些牛仔的存在；第三，不要用领导的口气当众压制牛仔，因为他们往往固执己见且自负，最好在私下约谈。