进入外包行业，已经是漫长而又短暂的１１年前的事情了，说其漫长，１１年是人生能够工作年限的１／４，说其短暂，是这１１年之中发生的各种项目管理的教训还历历在目。今天借此机会梳理一番，也算是给自己从业１１年的一个小的总结。 外包是一种合同发注方式，作为软件开发的承包方，我们通常是作为乙方的角色参与案件的，说的好听一些我们要提供最好的服务给客户，我们不光卖的是产品，更要卖自己的服务。可是作为乙方，这其中的辛酸只有做过每一个项目的人才能熟知。外包开发主要参与的工程是设计、制造、单元测试，前期的需求分析和后期的系统上线基本上是由客户来完成的。项目管理涉及到的知识领域比较多，按照PMBOK２００８版的概念来讲，也有９大知识领域，４２个过程组。但单纯从外包管理来说，不会完全接触到这９大知识领域，我从０６年开始接触PMBOK的管理思想，到今年取得PMP资格为止，经历了大大小小项目数十个，其中有失败的，也有成功的，每一个项目的管理过程都充满了故事，但是真正给我留下烙印的还是从２００８年的某个项目开始，那是一次例行的中间成果的检查，按照惯例我们把做好的中间产品交给了客户，没想到几天之后得到的是客户暴跳如雷，那是我从业多年以来第一次挨批，而且被批的体无完肤。后来在公司PMO室长的组织下，我们对那次“例外”做了认真的分析，并且认真的总结了问题发生的起因以及我们采取的对策。多年之后，这些经验仍然是指导我进行项目管理的方法，今天拿出来跟大家分享。 今天我不再去回顾当时事故发生的流程，上升一个层面，作为外包管理，当项目遇到了客户的严重质疑，发生信任危机的时候，作为PM应该采取什么样的方法，我想同样在国内的很多项目也适用这些方法。总的来说，当问题发生的时候，客户的态度是比较着急和严肃的，作为承包方的我们，应该站在客户的角度去考虑问题，先解决问题，再逐渐去完善自己的管理流程和工作方法，避免客户信任危机的产生。
从大的流程来讲，问题发生时的对应流程应该有以下几个步骤（按照先后顺序） （１） 发生问题的现状的确认 （２） 发生问题的原因的推测 （３） 临时对应方案的确定 （４） 临时对应方案实施 （５） 防止再次发生的方案确定（恒久对应方案的提供） 接下来再具体说明一下每一个步骤中的具体内容。 （１） 发生问题的现状的确认 客观地分析调查发生的问题是最重要的。我们往往在发生问题的时候会有些慌乱，在调查问题的时候，难免会有一些主观的因素加进去，比如“大体上是”、“我觉得可能是”等等类似的文字会出现在我们的调查报告中，这是一个大忌。
如果没有搜集一些定量的数据，单纯靠经验或者推测，往往不能得出令人信服的调查报告。 为了能够比较充分地列举问题的所在，往往会用到“５W１H”这样的方法，即：“Ｗｈｅｎ（何时）”、“Where（何地）”、“Who（参与者）”、“What（怎么做的）”、“Why（为什么那么做）”，以及“How（结果如何？）”。
如果我们能够按照上面的方法去追溯导致问题出现的原因的话，至少在后续的调查中我们得到的第一手的相对客观的数据。 （２） 发生问题的原因的推测 通常情况下，作为一个软件产品，在追溯到原因的时候，往往会有以下几种可 １） 系统或者硬件的故障 ２） 设计阶段的错误 ３） 开发或者测试工程的错误 ４） 人为的工作失误造成的 我们在这个阶段往往犯的错误是找到了问题的浅层现象，而没有去关注真正的原因所在，从另外一个方面，这个时候时间是最宝贵的，产品往往处于故障状态甚至是停止使用的状态，迅速找到问题所在是客户最关心的事情。 （３） 临时对应方案的确定
找到了第一层的问题原因之后，并且明确了“该怎么做”之后，应该着手制定临时对应方案，方案的制定要考虑的问题稍微多一些。对应方案往往还会涉及到“品质”、“成本”、“风险”、“时间”这几个因素的制约，在这种场合“品质”是最重要的，因为解决掉目前的问题是关键所在，如果这个时候还在顾虑“成本”，往往会给客户带去疲于应对的印象，从而逐渐产生信任危机。
当然，我们往往在实际制定对应方案的时候，会有多种选择，我们需要根据问题产生的背景去客观地实施一个切实可行的方案，并且去需求各种要素之间的平衡。 （４） 临时对应方案实施
拿到方案之后，实施阶段往往会涉及到许多之前参与项目的多部门人员。实施的时候需要有一个管理体制，把实施当作是一个项目来对应，协调各个部门的人员，调整实施周期，制定实施流程，明确实施规范并制定紧急对策，同时尽可能在实施过程中加入多个监测点，实时监控方案的实施状况，避免发生次生风险。 （５） 防止再次发生的方案确定（恒久对应方案的提供）
完成了以上四个步骤，可以说在应对客户方面是暂时告一段落了，但是时候还要对整个项目问题发生做一次反省，查找其中的根本原因。
从几个方面可以来关注： １） 规范 我们在项目开始的初期，是否按照客户的要求和以往类似的项目经验，制定了完整的作业规范，包括我们的设计方针、开发方针、代码规范、测试用例规范、成果物规范等等。以及这些方针是否跟客户取得了共识。 ２） 流程 往往规范类的文档是不会有大的问题的，在执行层面也就是流程上，是最容易出现问题的，没有做到１００％的ｒｅｖｉｅｗ，测试流程不规范导致漏掉了ｂｕｇ，版本管理流程不规范导致了发布的产品版本错误等等。 ３） 人的因素 人在软件开发过程中是最难管理的角色，软件开发以客户满意度至上为目标，以人为本，面对代码和设计资料，加上高强度的工作，即便是有完善的规范和完备的流程，人的因素往往作为偶发事件出现，但是往往是偶发事件会给整个项目或产品带来隐患。所以，对人的管理不能只停留在制度层面，更多的还是要给予技术人员人文关怀。 ４） 管理层因素 管理层往往会同时管理多个项目，他们往往是项目集管理者的角色，所以一旦项目进入了常规化阶段，管理者往往会忽视项目中的隐含着的不稳定因素。所以，设置PMO室是大型IT企业所必需进行的，定期地对各个项目进行跟踪并且做出相应的指导，是避免产生问题的一种常态手段。 由于篇幅制约，只能简单概括地写到这里，本人对项目管理的认知程度有限，可能有表达不清楚的地方存在，还希望同行能谅解。仅仅希望这些文字对PMP的管理之路提供一点点借鉴。希望大家都能做一位成功的职业管理人。
|