软件外包项目管理实务

 

笔者过去曾经与一流的北京.NET好手及台湾Architect共创梦幻团队，来成就企业主的跨国信息系统，这期间考验了团队每个成员的沟通能力、弹性程度、设计能力、实作能力及测试能力，透过同步设计（Co-Design）外包模式的运行，让团队每个人均能大展长才。为达到此目的，项目管理由过去对简单的同组织单一项目管理，逐渐发展成跨组织跨公司多项目的管理方式，本文将针对软件外包之项目管理分享实务经验及相关的运作策略。

从项目管理转型为项目领导

对于跨不同文化组织的项目管理，首要重视的是项目管理的整体性。这与传统项目经理的管理模式相差甚远，后者通常以自己组织与文化利益为基础考虑。这种强调以架构为中心的项目管理模式主要以联合作业（Joint-Force）方式来进行，团队的成员对联合作业都有基本的专业素养及能力，以团队的整体成功为目标，当发生影响到整体目标时，通常以此整体目标为导向，而非以个人或公司的部分利益为主的项目领导模式运作将主导一切。

传统的项目管理，项目经理习惯按照项目管理的硬技术排定所有的流程及事情，项目成员按照项目经理制定程序执行事情，常常造成沟通不良、弹性不够的团队，最后资源不足，草草收场或政策性结案。以架构为中心的项目管理强调不断顾全整体、协调、反馈、I&I、规划的过程，根据团队的资源，协作出最佳的效果。可以想象，所有的团队成员或许单看每个人都不是最优秀的，但是整体运作结果却是非常理想的。在上述的项目管理的本质，我们会发现有下列几个基本特质：

项目成员不再局限在公司内部，而是来自不同团队之外部资源共同跨国组成。

项目成员对项目执行均有一定基本程度的了解，而能够透过每次的互动定义出团队每个迭代的目标。

项目成员均有规划的能力，对执行计划的规划擅长以不同的构面运用不同的价值角度思考。

项目团队的所由成员均为主动型成员，而非一般主动与被同型混和团队。

软件外包首重架构规划

为了解决上述的环境变化所造成的影响，项目管理模式本着顺应变化的原则及思考本质，以架构为中心之联合作业的项目管理（Architecture-Centric Joint-Force Project Management）应运而生。在介绍其特色之前，先对架构及项目做个概略说明，用以表达Boundary。在架构思维上，以系统架构（Systems Architecture）为最大化。一个系统，又称一个信息，又称一个知识，上帝所创造的世界万物是一个系统，太阳系是一个系统，一粒沙子也是一个系统。依此观点，组成沙子的结构与行为合一产生沙子的系统架构，而架构不再局限软件架构、硬件架构，更扩展到企业架构、知识架构、思考架构应用上，这是一个很有趣的现象。过去架构师对架构从无法表述到可以利用许多工具方法自由地表述，如企业架构师可以利用架构框架方法来描述架构。

软件外包实务管理特色

1. 以架构为中心的项目管理

好的项目管理必须要有好的项目管理架构。项目管理架构的终极目标，是要创造高质量的系统，以架构为中心的专案管理也是一个I&I的过程，其运作方式如下图所示。完成该程序一次，表示完成一个Iteration，是用于产品或项目规划。从图中您可以发现，所有的软件创作过程均须回到Architecture Design团队，项目经理在运作排定时程的方式，需要有两种策略，一为项目开发团队按照软件开发程序执行事情的先后顺序，二为架构团队依照“定时不定量”原则于每次固定时间发布（Release）目前架构描述版本。从图（见下页）中，您可以发现架构会掌握系统的全貌来调和出符合各种观点的系统。



再来针对Mid-Course Corrections来做说明，一辆汽车若进维修厂维修时，常常会检查汽车零件是否需要更换，微调让团队运作更顺利，同理，一个团队“找对的人上车、请不对的人下车”也是一件很自然的过程，而Mid-Course Correction就是这个作用。在每次的Iteration结束前，团队必定从中学习到很多经验，而这些经验也将做为下个Iteration的基础，因此调整团队让其于下个Iteration运作中更顺畅是一个宝贵的经验过程。而每次的经验累积后就变成企业经营的智慧，能够帮助企业成长，避免未来犯错。



2. 重视规划艺术。

计划总是赶不上变化，但是若没有计划，一定应付不了变化，所以计划的艺术油然而生。试想，一个一直在练习计划的团队，组出各式各样的情境来应变实际执行的状况，让项目计划虽然有风险（Risk），但是可以掌握的，这是一件多么美好的事情！因此，项目规划不在于主计划多么完美，而在于您所准备的备胎计划是否灵活充足，以及计划是否可被百分之百地执行。计划通常分为两种，一种为Top-Down Plan，由项目经理制定目标与方向，一种为Bottom-Up Estimation，由Group Leader估算实际达成所需时程及资源，来共同研拟出可执行的计划。

以架构为中心的规划方式强调Backward Planning及Dynamic Planning，其掌握的精神即为利用动态规划过程，不断修正计划，让计划的结果与实际执行结果一致，这是一个整合的过程，把计划做UPDATE整合到原计划中，并在且Revision History记录演变的过程，达到计划与变化均能兼顾的目的。

3. 不同的团队文化结合

只要对团队产出物有所贡献的均视为Project Stakeholders，然而，项目管理者在组立团队时需要把白领与蓝领分开。兵法有云：兵分两路，因为常常白领有许多噪声会影响项目的因素，但并未做决策，并不代表蓝领团队需要受到直接冲击。成熟的项目团队知道所有Issues只要尚未决策一律按照原定计划执行，把这些通常会来自不同的文化团队成员组立的过程中，团队纪律是不可或缺的一环，也是一个关键的成功因素。

4. 塑造敌人来营造团队士气

异质型的项目团队在假设敌人时，若假设错误，将会造成项目问题，但若假设正确，将会获得令人意想不到的效果。笔者过去曾执行一个异质系统整合项目，其经验是，我们假设变动的需求是我们的敌人，同时也允许需求是可变动的。除此之外，都是我们的资源。在这样的假设下，我们发现一件有趣的过程，客户也一起参与变成我们的Worker，一起来把新旧系统做串接及测试。

5. 先整合后分工

在台湾，很多人习惯先分工再整合：每件工作拿过来就先做分工。这是很危险的，因为在不了解全貌的状况下冒然分工，未来可能会发生很大的误差。以架构为中心会解决这个问题，您会发现所有的资料都会汇集到架构师及项目经理那里。双方同时用不同的观点为项目质量、时程、成本、风险等因素把关，强化项目成功的机会。

6. 决策小组的执行力及重要性

异质团队的项目管理有个很重要的窍门，及成立决策中心做决策，因为观点不同，所以需要决策中心。笔者过去的经验是将客户、项目经理、Program Manager、Chief Architect组成决策小组，有投票权及否决权，然后Group Leader / Stakeholder有辩驳权及说明权，透过有效的运作决策机制，来决定项目的共同方向及执行效率，这个经验可以分享给各位，不过决策中心一把尚方宝剑，只有在解决不了的问题才会到决策中心（团队智慧能解决的问题就解决了，不需进决策中心），通常会由项目经理不定时的召开决策会议。

7. 签订合同时会决定未来的格局发展

最后，追本溯源，一个项目的成功于否在签约时就可以决定未来的格局发展，尤其是针对异质性整合系统，它需要甲、乙双方均投入资源，共同成就，而在拟约过程就应该考虑双方的责任义务，免得造成不必要的误解及变成项目执行的绊脚石，因此团队若能在签约前，以架构为中心执行POC（Proof of Concept），制作雏型（Prototype），将会对签约有很大的保证，是个降低风险的方法。

结语

成功的软件外包项目管理实务需要以领导、授权、培育及学习的成熟态度来引领团队，并配以架构为中心的项目管理技术来落实，更重要的是好的外包项目管理不是着重在解决问题，而是完全以预防问题为项目领导方向，因此于合同拟定阶段到最后实现及运行整个过程，依照先整合后分工，重视规划艺术，擅长异质团队文化结合，塑造团队战斗气息，并利用决策小组共同做出决策等策略来共创外包合作团队，来达到项目目标。

作者简介：

宋敏如，近十年项目管理经验，项目特性多为异质系统整合项目、MIS系统及嵌入式系统整合方案，外包实作经验多为跨国合作或跨地方区域合作模式，专精于同步设计的外包团队运作模式管理及以架构为中心之项目管理。