搜索 | 会员
软件外包项目管理指引
来源: 博客园   作者:MeteorSeed  日期:2020/9/14  类别:软件项目  主题:综合  编辑:西贝文
如果不去亲身经历几个外包项目,读者是难以想象这种“焦油坑”的恐怖。外包项目因为规模较大,涉众较多,在管理上往往更为复杂

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

1 项目中常见的问题

常见问题

现象

范围

需求难以冻结,处于“变更-修改-测试-变更”的死循环中。

质量

文档质量问题,如:关键文档缺失,没有能按照统一要求编写文档;文档内容前后不一致,有歧义,预期读者无法理解,文档版本与代码版本不同步等。

编码质量问题,如:不遵守编码规范,可读性差难以维护魔数泛滥,关键代码无注释,代码检查出现大量警告,滥用语法导致性能瓶颈等。

系统质量问题,如:不写验证,安全漏洞,异常频发,内存泄漏,日志缺失,不支持大量用户,运行缓慢等。

成本

前期成本估算误差较大,缺乏足够依据。

后期没有对成本进行量化分析。

进度

项目经常延期或者是匆匆上线。

 

外包项目中凸显的一些问题

现象

解决方法

前期准备不足

需求质量问题,如:遗漏需求,需求不明确,需求描述前后不一致,需求存在歧义等。

开发环境问题,如:配置管理、开发、测试、Bug跟踪、项目管理等环境搭建无法满足工作需要。

流程问题,如:是否已经建立了周知的工作流程,是否已经具备了相应的范本、检查标准和公约。

尽快梳理需求,搭建环境,建立项目所需的最基本的生存环境。

制定计划时,充分考虑到这种情况,识别潜在风险,预留足够的风险储备。

人际关系复杂

干系人数量庞大,其需求各有不同,可能存在需求之间的冲突。

涉及多个供应商、提供商,项目进行中会有开发团队之间的矛盾冲突。

在人员混编团队中,会发生外部人员难以管理甚至罢工的可能。

必须明确掌握核心干系人的职位、职责和角色,加强沟通,做好干系人关系维护。

遇到问题要协调多方负责人协调解决,不要带感情色彩。

资源问题凸显

人员储备不足,开发用机器配置较低编译缓慢等。

外部人员能力参差不齐,且难以管理。

人员离职频繁,资源严重不足。

尽量参与到人员招聘中,对能力不达标的在职人员进行培训,尽量不要劝退。

磨刀不误砍柴工,必要时,申请合理的硬件资源。

在进度计划里安排单点技术的交叉培训,以应对该人员离职时的冲击。

PM没有足够权利

受制于多个上级领导,对甲方决策无力抗争,对项目组内的甲方人员难以管理。

和领导搞好关系,加强沟通,自己权限外的找负责人解决。

地域和文化差异

封闭开发时的伙食问题,如:上海人不爱吃辣的,回民不吃猪肉等,这些问题他们都会找PM。

沟通问题,不同地区语言文化差异,尤其是远程会议时,可能会在理解上有阻滞。

及时和甲方沟通团队成员的合理诉求,要敢于维护团队的利益。

认识到理解上有疑惑时,及时沟通,不要碍于面子不去张口。

加班

加班导致离职。

加班导致士气低下。

加班导致消极怠工。

加班导致代码质量低下,Bug频发。

加班会导致疾病甚至过劳死。

合理的安排赶工,对不合理的要求说“不”。

尽量为加班程序员争取利益。

身先士卒。

合理安排计划,预览风险储备,尽量做到在节假日不加班。

需要PM参与设计和开发

PM想要扮演架构师和程序员的角色。

优先完成关键路径任务,利用碎片时间参与其他非关键任务。

  

2 项目管理经验总结

  • 促成一致意见 多数外包团队看中的是程序员编码能力,而不是合作的能力。PM需要做两件事情:第一,确保讨论不要被一个人或一种言论所支配,当然共识的除外;第二,帮助不敢发言的人或说不清楚的人表达他们的意见。PM大多时候需要促成团队的一致意见,如对编码规范,周知的项目组约定等。促成一致意见需要轻度的领导,高压政策下的一致意见,不能反映出团队的意愿。PM在促成一致意见时最重要的是保持中立。需要知道,集体的决策比从集体中的个体独立做出选择更具有风险倾向。如果将这种决策模式应用与软件项目,很可能会看到这样的结果:更复杂的结构和算法、过度的质量、过度的扩展性考虑、范围浅变等。这是因为开发者并不会考虑项目的整体维度,而只会关心编码。因此,对于PM促成一致意见,不等同于从众或折中,有些时候单独的做出决策才是对的。因此,并非所有决策都倾向与群体决策,群体决策会产生一种负面影响,即——个人贡献和能力将降到最低。作为PM应该,清楚这种负面影响,并为团队营造一种鼓励和支持“创新”的大环境。不要让团队中形成小的团体对立,这样,任何人的出头行为都很招致小团体成员的怨恨。这种现象在外包团队更为明显,因为可能源自不同公司,会不同时间入职。不要让这种风气在团队中成为主流。另外,不要轻易的折中,因为折中往往会失去亮点。

  • 明确优先级 PM必须面对现时,项目是技术和经济结合的产物,受制于多方制约,需要综合分析这些制约因素和用户诉求,制定合理的优先级。

  • 为团队争取好的办公环境 外包团队的工作环境通常比较恶劣。IT业公认的:更安静、更宽松的工作空间对提高编程效率有作用。如果能够让团队整体在一个独立区域办公应该是极好的了。但我们也得面对现时,外包团队不会有很好的待遇,因为,至少作为PM我们应该争取不要让团队分散,因为那会提高沟通成本,和沟通中的噪音。另外,被分出去的开发者会感到孤立,进而与其他人员疏远,长期下去不利于团结成员间的协作。

  • 让开发人员少受打扰 编程是一种耗费脑力的持续活动,开发者不喜欢被打扰,愿因很简单,打断思路会影响编码。所以,很多时候大家会听到程序员抱怨说“我不是网管”。在外包团队中,打扰就不那么简单了。程序员与关键用户的比例是极其悬殊的,开发者会经常被打扰,解答各种无聊问题,甚至和甲方闹矛盾。这不是个好现象。PM需要做两件事情:第一,明确角色职责,并让甲方人员清楚,有问题了该找谁,不要一个问题在团队中踢皮球;第二,明确向甲方表示,投诉直接找PM,走投诉流程,别单独去和开发者理论,如果矛盾激化,之后很难处理。

  • 管理牛仔 无疑的,牛仔程序员是能力很强的,但却缺乏团队合作概念。牛仔程序员如果放任不管,那么他往往会写出别人难以理解的代码。他们特立独行,不愿与人合作,并且喜欢在代码中烙印自己的风格。虽然程序员们都有强烈的性格倾向,但牛仔显然更加突出,他们往往不是那种喜欢与人交往的类型。牛仔程序员具有以下特点:他们反对任何形式的标准、约束和规范,不喜欢受他人的监控,也不喜欢和他人协同开发。追求创造性多过考虑软件可用性、可靠性和成本。外包团队中,不要去尝试改变牛仔程序员,这不是短期能做到的。牛仔对团队是否有益,取决于PM。好的实践是:第一,将整个工作分解,把相对独立的、具有挑战性的工作分配给牛仔。这些工作应该尽可能独立,与其他工作之间只存在简单的接口,不需要与其他人员频繁的沟通;第二,对他们的工作进行监督,不能忽略这些牛仔的存在;第三,不要用领导的口气当众压制牛仔,因为他们往往固执己见且自负,最好在私下约谈。


德仔网尊重行业规范,每篇文章都注明有明确的作者和来源;德仔网的原创文章,请转载时务必注明文章作者和来源:德仔网;
头条那些事
大家在关注
我们的推荐
也许感兴趣的
干货