软件外包项目管理指引

　　若是不去亲身经历几个外包项目，读者是不可思议这种“焦油坑”的恐怖。外包项目由于规模较大，涉众较多，在管理上每每更为复杂。本文，阐述外包项目的特色以及笔者的管理经验，但愿能便帮助读者管理好外包项目。

1 项目中常见的问题

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

 

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

　　

2 项目管理经验总结

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