第2部分 项目管理的过程与方法
第2章 决策，还是等待，这是个问题
项目管理是一个典型的运用各类管理知识与经验，针对项目这种人为定义的专有事物加以系统化应用的学科。早有人总结过，项目管理和工商企业管理、公共管理，以及高效能人士的七八个习惯、几顶思考帽、情境管理乃至心理学什么的，都有很多相通之处。在软件行业，项目管理和CMMI也有很多相似的地方。我们这里主要关注项目经理的决策能力。
据统计，一个人一天要做出大约2000个决策，不过大多数都是鸡毛蒜皮的小事。然而，人生却总有这样的重大时刻：高考时报志愿；向哪个备选女友求婚；买三环还是六环的房子，你总得拿个主意。项目经理在关键时刻做出的决策，很可能影响项目的成败，费用的花销，以及上线之后会不会酿成重大事故等。
有些项目经理的个性就是磨磨矶矶、犹犹豫豫、会而不议、议而不决、决而不行，那还是趁早改行吧。所以，项目经理要具备决策能力，先要有决策的性格。这个可能是天生的，也可能是后天培养的。有时我们说某人天生适合做项目经理，有些人根本不是那块料，考量的主要是这个人是不是有魄力、从小就是孩子王、小学时戴过三道杠、班级活动永远的组织者、聚餐时老抢着买单等。
天生的因素我们不谈了，那么敢于决策的性格如何后天培养呢？其实我也不知道。一般重大变故会使人坚强起来，像斯嘉丽（《飘》的主人公）那样，但这毕竟是小概率事件。不过你要是读过那些乌七八糟的成功学，多看看人物传记，有心观察一下公司里比自己牛的人，你会发现，同为人类他们可能有一些你所不具备的性格，比如承担与改变，敢于面对挑战。都说江山易改，本性难移。但有些人却能在商业环境里迅速发现自己性格上的缺陷，义无反顾地走向磨练意志这条道路，最终获取职业的真谛。这当然是要付出代价的，所以，你准备好了吗？
至于决策的专业知识，很多书籍介绍了非常好的方法论，很多优秀组织有出色的实践，可惜融合BSS项目里我们一个也没用上。基本都是拍脑袋，只是拍一个脑袋还是拍多个脑袋的区别。所以本书里关于决策我们更多讲案例，讲我自己的理解。
2.1 IT项目中的决策点
一说到决策，就像是一个挺大的话题，但作为IT项目经理，并不是所有事都需要你操心。我们从IT项目的实践概括性理一下，看看哪些事儿是要你操心的。
● 选择技术路线
或者叫版本选择？一般情况下，一家公司中标某个工程后，拿哪个产品实施、采用何种技术架构是确定的，很少有选择余地。很多年来，运营商在信息化领域，是求稳而不是求新，所以选择余地并不是很大。但现在发生了一些变化。一方面，新技术层出不穷，用户偏好在变；另一方面，你的公司技术管理不可能那么完美。这两个因素都导致工程项目经理在项目启动、执行过程中要处理技术路线选择的问题。而在某些公司，项目经理在职权上也承担了技术路线选择的责任。所以也需要工程项目经理具备技术判断能力。
首先要强调，项目经理在技术路线决策上务必弱化自己的“源出身”。如果你出身于技术狂人，情商又不是那么高，十有八九对所谓的新技术有追求，对自己的团队有不知从哪儿来的自信。所以一般会趋向于选择高复杂度，并且很炫的技术路线。而如果你基本是个外行，靠招摇撞骗进了一家公司做项目经理，很有可能避免亲自做出这些技术性很强的决策，而任由一群二把刀糊里糊涂地连技术路线还没选择，就走上一条不归路。
所以，项目经理第一个要做的就是知道有技术路线选择这回事，而不是傻乎乎地招来人就开干。然后判断公司总部发来的产品、技术特性是否与用户诉求符合，如符合则进入下一阶段。如果不行，就需要召集项目组内、外专家加以讨论、验证。不要抱怨研发部为什么把不成熟的产品发到现场，因为世界永远没有那么完美。
笔者所在公司有严格的版本命名规范。例如，某个产品研发出厂版本号是1.0，到某省落地的时候可能叫1.5，到另一省实施时可能叫1.6。要是幸运地拿到一个全国实施的项目，几个省的版本号才会是一个，但一般不会这么幸运。并且随着时间的推移，以及各省间演进速度的不同，即使这个产品只在三个省落地，产品线手里也可能会有10个以上版本，而且还不是简单向下兼容那么简单。工程项目经理判断版本间的区别主要看三点：一是数据模型，核心表结构没有大的变化可以被视为一版。二是软件技术架构，这个更复杂一些，不同的软件产品也不同，一般软件架构层次和中间件产品大版本相同即认为是同一版。三是要考虑业务因素。即使都是应用+Tuxedo+Oracle的技术架构，都是渠道佣金系统，在同一运营商的两省间业务特性也会有很大差异，务必选择与自己业务特性最相近的省份版本。但反过来说，“用最新版本落地”不一定是最佳选择。
你也可以说，实施前我们肯定与用户做过多次交流。招标项目的话，应答书里也做过技术承诺，所以按当初的技术建议书来整不就行了吗？这只能说明你幼稚。招标、前期交流的东西都是我司广告宣传部门写出来的，能信吗？如果里面承诺的东西经实践论证不可行的话，还不是你去求爷爷告奶奶地请求用户放你一马。
所以，要开会。不开会也行，你可以和技术负责人两人定。要是你俩定不下来的话，可以把范围扩大一些。要是你们项目组内没有这样的人，就满公司去找能判断的人。一般产品线总监绝对有这个能力，否则他就白当总监了。如果这个人也是半瓶子醋的话，你还有两个方法：一是运用一些高级的麦肯锡方法，头脑风暴、鱼骨图、大脑思维导图等，把一群二把刀关在屋子里半天，也可能有奇迹出来。二是把用户拉进来。如果你从事的是电信、金融等信息化比较深的行业，那里绝对有比你强很多的人。但如果你做的是餐饮、女性购物网站，那还是回家和老婆商量一下或者抛硬币吧。
归纳一下选择版本考虑的因素：
1．产品演进策略。即哪个版本是你公司确定的主流，一般是选择最新版本。例外的是，如果一个产品线在十个省都是基于小机的老版本，非要拿你这儿试验一个全云化新版。而这个项目的进度压力极大，用户对质量要求极高、对技术框架不关心，就要掂量掂量。
2．产品成熟度与团队成熟度。这个产品是已有实施案例，还是停留在PPT阶段？这个产品的研发组是一群司龄十年八年的“老”人，还是刚刚由人力资源部的女士们拉进来的“新”人。
3．用户偏好及业务模式。考虑用户对业务、技术的偏好；选择与目标用户业务模式最相似的版本。
4．竞争压力。竞争对手已经拿出压箱底的东西把用户忽悠起来了，你再拿一个毫无新意的版本去实施，只能给竞争对手留出空间。
总而言之，核心生产系统的、规模巨大的、进度压力极大的项目，禁止采用新技术。嗯，太武断了。严谨地说，是把采用新技术、新工艺的比重降到最低。若是一点新东西都不用，还做这个大项目干什么呢？在多数情况下，用户更关注系统升级给业务带来的新元素、运营投资成本的降低。如果你采用的新技术只是把代码从C改为纯Java，甚至这部分工作就要占到工程量的50%以上，而用户更关心新系统上线后能否缩短新业务投放周期。
所以，尽量拿一个已落地产品版本来用！实践是检验真理的唯一标准。
新的业务领域、竞争性较强的商务环境，一般要采用最新、最有拓展前景的版本。甚至用户要A方案，我们会拿一个更大更全的B方案去实施。
● 选择谁参与项目
主要是指技术总负责人，骨干。
一般来说你没的选。绝大多数公司资源永远是紧缺的，能给你派人就不错了。大多数项目也的确可以将就。当缺少优秀的技术负责人时，如果项目经理能有效补位，那么也可以把项目做起来。
但大项目不同。千万元级别以上的项目，没法儿补位，也补不过来。电信业务支撑系统大版本升级，需要在营业、计费、数据移植、业务需求、数据库、平台类软件、硬件集成、网络、核心算法等岗位上有独挡一面的人，甚至需要是业内、国内顶尖级专家，并且技术岗、业务岗都需要这样的人。所以为了保证人员质量，现在部分用户招标书要求提交实施人员简历。
项目经理要有能力判断，这个项目需要什么样的人参与。一个项目交到你手上，首先要了解这个项目是干吗的，然后马上在公司范围内四处寻访谁最适合干这个项目。
至于能不能要到人，就是考验你的公关能力、人品的时候了。那与项目决策有什么关系呢？因为很多项目经理在要不到合适的人时，一般选择了妥协。你不应该自怨自艾地接受现实，应该警醒，因为这是你的决策时刻。无数次实践证明，某些活只能某些人干，瞎凑合只会浪费时间和金钱，让客户彻底绝望。你要不使尽所有手段把需要的人要到；要不就和用户、老板摊牌，还是等合适的人到了再启动项目吧。当然公司越大，能人越多，可替代性也越强，地球离了谁都转。但你仍然需要坚持以上原则，因为大公司同样充满了失败的项目。
还有一个与决策相关的是，对于进入你的黑名单的人，在下一个项目启动时，无论他的直属经理以何种理由非要把他塞给你，也要毅然绝然地说“不”。不要质疑老祖宗对人类这种高级动物的精辟论断：江山易改，本性难移。有些人天生没有合作意识，天生很自我，永远搞不清自己的程序。不要他就是对他最好的惩罚。
● 选择工程实施方法
工程方法指实施阶段各种作业方法。大多数人想不到还有选择实施方法这回事，拉来人就干呗。但软件工程的过程方法并不那么固定，所以针对不同项目要区别。
首先是大的工序选择。交付类软件实施过程一般是：研发→现场部署→数据移植→配置→现场开发→联调测试→用户测试→培训→割接预演→试运行→正式上线。对于不同特性的项目，这个顺序的选择就需要调整。这时，项目特性就显得很重要了。所以我们先阐述什么是项目特性，这可以简单理解为从不同维度给项目分类。
1．根据系统使用者的不同，项目可以分为：
● 商务项目（占绝大多数）；
● 研发项目；
● 公司内部项目。
2．从实施内容上考量，项目可以分为：
● 软件开发-交付项目。即纯软，也就是平常我们所说的软件项目；
● 软硬件集成项目。和上一个类似，只是软硬件比例有差别；
● 纯实施类项目。例如Oracle、SAP、华为等大厂商的分包实施方；只是有的偏软件，有的偏硬件、网络、通信基础设施；
● 系统迁移项目。有好几种迁移方式，如数据库迁移（从低版到高版）、机房搬迁（机器搬家了，应用软件也得跟着迁移）等；
● 配合改造项目。主系统升级时，它的周边系统需要跟着改造、实施。有的有开发工作，有的纯粹就是配合别人做联调测试；
● 新需求项目。这可能是通信行业特有的，需要根据一年产生的新需求工作量核算成本；
● 维护项目。这个也有很多种，有软件代维，也有硬件、基础设施代维。
3．从时间角度，项目可以分为：
● 时间敏感项目。局方有强烈的政治诉求，敲死了上线时间点；
● 时间不敏感项目。项目的上线时间不是太死，可以协商，甚至没约束具体上线时间点。
要说项目特性，细分起来还有很多，一般来说，你待过的行业越多、越久，遇到的就会越多。
在不同项目特性下，软件工程的工序肯定不一样。有些公司的管理体系是瀑布式一刀切流程，所以软件工程的任何一个小阶段都不能少，还要指导、考核公司内所有项目施工过程。即使同一类型项目，由于甲方诉求重点、系统的成熟度不同，在不同案例中实施的策略也会有所不同。
比如，我们的同一个系统在A、B两省同时实施，会由于背景环境的不同采用不同的项目策略、工序。在A省，由于已经有了基础，原系统就是自己的，系统调研的时间可大大缩短，更多的在对新数据模型及功能差异，因而业务差异会很小，数据迁移、应用部署，以及测试、培训环境的搭建就会显得比业务需求调研还重要。相应地，对硬件设备及平台软件的到位要求就得排在第一位。而B省是新进入的省份，一穷二白，那么对新系统的业务环境、系统环境、与其他系统的接口关系的调研会花费很长时间，其技术方案在进场后要经过几轮修改才能定版。因而对硬件设备及平台软件的到位要求就不是那么急迫。对项目经理来说，由于背景的不同，采用不同的工序和方法是必须的。与项目决策有关的是，对自己公司的死板流程和无知用户的野蛮干扰不能逆来顺受，要勇于扛起反抗的大旗。
除了工序，作业方法是另一主要任务。上面谈了如何选择版本、技术路线，找什么样的人，按照什么工序进行生产。而剩下的一切可以称之为方法的事情都可以归到作业方法里。比如：
● 某个软件过程选择瀑布式还是敏捷迭代式。
● 用户交互界面是否采用原型法。
● 对老系统已存在的需求功能梳理，是以历史积累的需求说明书为准，还是采用翻老系统代码的方法。
● 采用模拟报文发生器、截取现网报文等方法进行接口程序内部测试，以提高和其他厂商对端系统正式测试时的工作效率。
● 数据移植采用何种方法。
● 是否为此项目制订特别的绩效考核或补助办法。
● 是否采用外包人员的方法。
● 如何解决异地办公问题。
……
工程方法存在于实施人员的脑海里，但成熟度高的公司会有相应的规程约束。如果你所在公司每年离职率只有1%，实打实通过了CMMI认证，申请的技术专利无数，那下面的内容就不用看了。不过大多数情况没那么完美，项目经理对此要有一定的判断能力，不能听任施工团队任意为之。
很多工程方法是在排计划时，由于进度紧张或资源不足被挤压出来的（其中少不了一些馊主意），最理想的情况是“事先”做评估和选择。大多项目管理过程不支持就“工程方法”这个事组织专门活动，一般伴随着工程进度的排定、技术方案选型、项目风险评估等活动而组织。
比如，你负责一个针对某重要客户的平台类产品入围测试项目。这类项目一般面临进度和测试指标两方面的压力。作为项目经理，把专业组人员召齐后，不仅要讨论计划、分工、产品、技术，还要讨论重点工作实施的方法。比如，在进行摸高测试时，把所有主机资源全部占用，不断寻找影响TPSS指标值的短板因素，并持续优化是一条路；而搭建最小可运行环境，得到低并发下的理想值后，成倍数地增加计算节点，以期找到影响TPSS值线性增长的规律是另一条道路。但你不可能两条路都走，因为资源和时间是有限的。
很早以前，我负责一个小固网项目，启动时可以几件事情同步去做：1．了解现网业务与目标系统差异并做本地化开发；2．数据移植。由于人力及经验上的原因，我们选择了先做第一步，这并没有问题，关键是后者开工好几个月了才被提及。事后证明，如果我们一上来同步搞数据移植，围绕移植完成的目标环境进行数据模型匹配，并作为业务差异化开发的输入，可能会更节省时间。
为了将工程方法的选择体制化，可以在公司PMO层面要求项目经理在“项目策划”这个环节对工程方法加以明确。编写周期在项目启动后1～2个月内完成。
选择工程方法最需要考虑的因素，第一是时间；第二是所持有资源；第三是目标用户接受程度。工程方法不仅包括技术手段，也包括很多其他措施，比如采用外包以弥补人力不足，建立远程虚拟小组等。
工程项目经理常把技术手段、人力因素作为自己关注的重点，而采用外包、外购服务、第三方合作、削减项目规模等“花钱”、“减小收益”的做法很少在你的脑海里出现。而这些方法在规模较大、业界领先的企业里已司空见惯。要不怎么有那么多外包公司存在呢？很多企业的项目经理难以企及这样的权力，或者其利润率及规模尚不足以支持这种做法，或者只是观念在作祟。
你不可能在项目启动的一个月内把未来的一切都预测正确。所以，工程项目组里，尤其规模较大的项目，会有一个“技术委员会”或“PMO”来帮助你做决策。在上例平台软件入围测试项目中，公司并不是所有优秀大脑都参与了这个项目，但大多数聪明人被列入这个项目的“技术委员会”。这时候，项目经理只需要判断是否需要改变，是否需要寻求这个委员会的帮助。事实上，大多数人愿意提供他们的智慧，这也是项目最终取得成功的要素之一。但项目经理并不因此轻松多少，他要在找到最聪明的人帮助自己、避免反复地变更技术手段，以及在“折腾”研发人员之间寻求平衡。
● 换掉不得不换的人
在漫长的工程实施周期里，你和一群来自五湖四海的兄弟姐妹同吃、同住，为了共同的目标同甘共苦。最后这个系统在你们手里发展壮大、成功上线，获得用户一致好评，公司向每个人回报以丰厚的红包。多年以后，再见到一起战斗过的兄弟，仍然倍感温馨，宛如见到亲人。
现实都如此美好吗？
不全是如此。事实上，每个项目给你留下的最深印象除了项目的成功与失败，就是在这个项目里结识的真朋友和那么几个你恨之入骨的人。
项目过程中你可能不得不撤换人。无论是向产品线经理要到你心目中的“大拿”；还是痛下杀手，请走那些自以为是的“大神”，都需要具备十足的魄力、决断力。那些向往项目经理职位的人，最好先读一读吴起、韩信、张居正、李云龙这些人的故事。要是对自己没啥信心的话，可以回技术岗再干几年。
还好，你不会经常面临撤换掉某些人的压力。但的确经常有项目经理犯下这方面错误。不及时清除团队中不合适的人，对真正为项目做出贡献的同事是莫大的伤害。
那么，什么人是你绝对不能容忍的呢？
先要说明，以我身经百战的经历，绝大多数国人是朴素、懂事理、以劳动换取报酬的大好青年。说年龄太小不好管理基本都是胡掰。人心不古、世风日下也是每个朝代都会有人念叨的。是否便于管理与年龄无关。所以，干掉什么人与年龄无关。
再要说明，没有绝对的坏人、懒人、笨人、不能融入团队的人。很多人是用错了位置，包括项目经理本人。
但有些人你还是不得不请他走，或调换他在组里的位置。
首先是能力因素。经验不足、智慧不够等能力上的弱项使某些人不能胜任自己在项目组里的岗位，尤其是关键岗位。这也和项目特性有关，一个4000万元的项目对关键岗人员的要求肯定和40万元的项目不一样，其身处的项目环境、面对的用户群体完全是两码事。所以能力称不称职，是相对的。但原则是不称职的人肯定要调换。
还有就是沟通合作因素。有些工作者的确难以和他人合作。他们历经风雨、不忘初心，始终以自己一贯的奇葩表现面对遇到的所有人，让你实在搞不懂他这些年是怎么在社会上生存下来的。他们有一点能力，否则你也不会在团队里见到他，但他的能力绝对称不上天才的程度，以致项目组能够容忍他。他给项目团队带来的伤害往往超过那一点点贡献。其典型表现包括：永远说不清他自己正在做什么；像个炮仗似的一点就着，其炸毁的目标是所有人，还不在乎场合；像祥林嫂似的永远在抱怨一切，你一看见他就想给他十块钱让他闭嘴。因为他的存在使所有人觉得自己进错了项目组、选错了公司、拿少了补助、生活在黑暗的中世纪、只要换个地方人人都能成为千万富翁。
例子太多了，不一而足。这里不讨论“人格分裂”的起因与治疗。随着时间的流逝，应该相信，他们都不是坏人，一切的一切只是你的包容度有多大，影响力有多深。只不过，你可能没有足够的空间和时间去包容，所以换人还是必须的。
下面谈谈方法。
最经常的做法是调换岗位。矩阵式组织结构的公司，项目组里每个成员干什么工作大多是在产品线派过来时指定的，尤其各个组的组长。但在项目组里有时需要建立跨产品线的职能组，如数据移植、方案规划、割接组织、测试等，这个组长一般由项目经理指定。某些公司有专门的工程实施部，各组成员已经按职能分组。但无论采用哪种组织方式，项目进行的前半程，一般是人员调整的最佳时机。
很神奇的一个事是某些人不愿当组长。一是要管人；二是无论这家公司怎么草根，形成一定规模后总有些管理行为，会让人觉得在浪费生命；三是即使在草根公司里，职位和薪酬也不是线性相关的。
这种情况下，我的经验是不可强求。道理很简单，一个成年人的认知与性格很难改变。而且一个技术型公司，人员成长一般有两条路，一条走向技术专家，一条走向技术管理。很多时候我们混淆两者，或者更多关注后者。这种情况下，一是可以从这个组里找一个有这方面意愿、能力稍弱的人顶上来，矬子里拨将军不可避免。二是项目经理补位。
更多的时候是主动撤换。好在一般的乙方公司官本位风气不是那么重，调一个人负责其他的工作不是那么难，但还是要有个过程。开始你可以把某些重要工作分配给其他人，然后重要会议上你不再倾听他的意见。幸运的是，项目组里永远不缺活儿干，而且每个看上去都那么不可或缺。找个机会把某项任务分给他，随后在组织机构上适当的调整。嗯，有点阴谋论的味道。其实也没那么复杂，见的人、经历的项目多了，这种调整很正常。何况，你也可能是被调整的人之一。
还有一种情况是把此人退回到产品线或职能部门。最直接的做法是通过他的直属领导，告诉他不能再回项目组了，不用犹豫。
如果此人的表现超出了公司行为准则的底线，你的做法是除了让他离开项目组，还要汇报给其直属领导、你的领导、人力资源部，建议辞退。
说了这么多好像都是负面因素？恰恰相反，这个事很积极。很多同事听说某人走了以后自掏腰包请喝酒，而真正的强人被调整到发挥其能量的岗位上来，你的权威也建立起来了，大家都舒了一口气，项目组一片春光。
● 要不要返工
大项目执行期间，你坐在办公室里，看到一个不怎么熟悉的项目组成员进来，前言不搭后语地跟你说了五分钟，最后你明白了，他们组干了半个月的东西根本没用，要重来；或者你正和用户开着会，技术负责人打电话过来，语焉不详地说：老曹，有个事要和你说一下。像这些情况基本不会是什么好事。
是的，工程期间经常遇到这种“惊喜”。我甚至已经摸到规律，什么人，在什么时间，打电话还是当面，就会有什么样的事情发生。一开始我一听这类消息就着急，后来在微信上读了好多心灵鸡汤，但觉得还是不管用。问题还得靠实力解决，喝汤不管用。
可以把这些归为技术方案或工程方法变更。需要当机立断做出决策。
工程实施期间调整技术方案和施工方法是一件很痛苦的事。就像大厦盖了二十几层发现打地基用的水泥标号不对。但几乎每个大项目都会碰上那么几次。融合BSS项目也经历过，工程进行到模拟出账的时候，才发现账务处理的主机内存设计容量不够。这是什么概念？几台IBM595内存从半配升到满配，打个狠折也要近千万，这钱谁出？
再比如：
● 运行环境选错了，小型机还是X86？别听那帮搞云化的人忽悠，技术根本不过关。
● 开发平台选错了，FrameWork，工作流引擎，代码生成器，动态表单，最后证明还是原生态的开发工具好使。
● 系统技术架构中多了个东西或少了个东西。很神奇，一般是多了的时候居多。我们为了实现业务与技术的剥离或各种事务处理的简约化、统一化，整的那些EAI、分布式代理，各种中间件，经常落入有它很烦、没它更好的境地。
● 开发进程过半的时候发现大多数新入员工编写的代码不符合早就三令五申的安全规范。
● 集中了几十号人讨论了半个月的业务梳理发现基础设想是错的。
● 应用程序到交付阶段发现数据模型组已经把初始模型改了30%。
……
每一个都是眼泪呀。
每一次你都不明白这家国际化软件企业里技术负责人难道都是吃干饭的吗？咋就没点积累、不能长点记性呢？
这时候的决策是相当痛苦的。因为你的职业生涯只有40年，工期一年多的项目也做不了几个，分给每一个重要阶段的时间多了也就两三个月，还要碰上国庆、春节、世界杯、奥运会、全英羽毛球公开赛、四大网球公开赛（嗯，我是个体育迷）……翻倒重来的话要把工期推后一个月，或者二十几号兄弟一天24小时不睡觉干上一周，或者项目组所有人在系统上线时改信天主教祈祷万能的上帝把那些重大隐患一挥手消除……
还好，我们干的不是神九上天工程，也不是生物基因重组，应用软件除了极个别领域具备较高技术含量外，更多的恰如其名“应用”，不是那么难。一群中国二流大学毕业生，具备七八年从业经验，加上坚强的求生意志，一般都会解决。当然，也要付出一定代价。关键需要及时地决策。如果你面对这种情况，犹疑、恐惧、沮丧、无助、什么也不想干、躺在被窝里读心灵鸡汤；一天三遍报告你的领导请他派个万能之人来解决问题；或者希望瞒天过海把消息控制在最小范围，拖一天是一天，基本上全公司最失败项目就要在你手里诞生了。
你应该做的是召集最得力的人，谁也不要批评，或者只批评你自己（虽然这个事跟你半毛钱关系也没有），并寻找有效的解决办法。24小时之内通知用户，把初步方案告诉他，请他一起和你想办法。这没什么神奇之处，需要的只是勇气。
● 系统上线时间点决策
人们经常问将军的司机TOM：将军有没有说战争什么时候可以结束？终于有一天，司机大声对大家说，将军昨天对我说，这时所有人的目光集中过来，将军说：TOM，你看战争什么时候能够结束？
项目经理也经常被问到：这个系统什么时候上线？我心想，我哪知道。最可笑的是那帮技术组的成员问我这个问题。难道你自己的活儿干到什么程度自己不清楚？还来问我。
系统什么时候上线的确是个大事。某些项目经理觉得自己并不是决定系统上线时间的人。因为大多数项目或受政治因素高压，要向国庆献礼，当然国庆时间一定是不让改的；或这个项目姥姥不疼舅舅不爱，谁也不知道他什么时候能干完，走一步看一步。这实在很可悲。
理想的情况是，不太理会那个政治目标时间，项目经理有计划地在几个关键节点评估、决策上线时间点，这会对项目进程起到重要影响。因为人们看到你坚毅的目光，有理有据的分析，坚定而毫不犹豫地执行因上线时间而做出的调整，大家会在心理上相信，这个时间看来是真的。固执而强大的用户，经你锲而不舍地晓之以理、动之以情，会同意你对系统上线时间的判断（当然也有可能第一时间把你干掉）。
一个很恶劣的情况是，用户由于政治因素强压下一个上线时间，乙方顶不住这个压力接受，并广而告之到项目组全体，拼命干；然后，时间点到了，上不了，推迟；然后，召集各方高层会议，换两个关键人员，再定一个时间；然后，又没实现，再改；然后，就没有然后了，整个团队士气已经一落千丈，准备收拾烂摊子吧。
所以你需要考虑几个因素：
1．不是所有活儿都干完才能上线。大规模系统工程都会对上线前核心功能、重要功能、次要功能及性能指标完成比例有约定。如果你从事的行业IT管理成熟度不高，把这个道理讲给用户听就是了。就像巴西世界杯，体育馆没完全盖好，球照样可以踢。有些小缺陷是可以容忍的。
2．用户的要求。当用户坚持己见时，多问一句“为什么”。除业务因素外，很多时候出于投资、成本、内部审计、年度工作计划的考虑，也有拍脑袋的成分。
3．客观评估你队伍的战斗力，但一般来说，很难。人类本能是一种乐观的动物，这时候你要做的就是阅读你公司的《失败案例精选100》。
4．真实了解你的项目到底干到什么程度了。不要说这是废话，有人真的不知道。
5．关于公司的自身利益。是成本耗不下去了，还是再延迟士气会低落；是要通过这个系统上线打击竞争对手，还是现在找不到足够的人手，所以希望能延上一段时间。
6．外部约束。出账账期，业务高发期，外部系统具备时间，以及3.15消费者日，5.17电信日，春节等节假日，两会封网等，都是考量因素。
综合考虑这些因素，与用户一起，在恰当的时机制订上线时间，是最合理的做法。在此过程中，项目经理的决策能力是关键因素。
● 发生重大故障时的决策
项目经理在系统出现重大故障时的快速准确决策对故障的影响非常之大。什么叫重大故障？简单说就是你的系统玩儿不转了，出现了让人无法忍受的影响。据我统计，80%的重大故障之所以从“一般”成长为“重大”，是由于处理的最佳时机没抓住，没有做出最理智的决策。纠其根源，一是由于项目经理的经验、专业水准不够，二是把自己当成“局外人”，认为这是纯技术的事。
处理重大故障的行动步骤准则如下。
1．迅速中止故障产生的影响
当故障发生时，你很可能不知道是主机，网络，还是应用出问题了。你最先得到的一般是客服投诉，或网管报警，但这都不是“影响”。影响是约1000个用户缴费后无法及时开机；全省或部分地域营业系统变慢甚至无法受理；结算给某代理商的佣金异常波动等，你首先想到的是如何中止这种影响。如果能够在5分钟内定位是哪儿出了问题，当然好。但如果不能，中止进程、重启系统、人工受理业务、启动应急系统等都是可选的办法。很多运营商准备了完备的应急业务响应流程，且经常演练，就是这个目的。
与之相对的，出现故障后组织大把的人力奔赴现场，把所有人、故障最初的几小时都花在各种可能性的分析上，而不对正在产生的影响做出处理，可能使故障影响从系统内到系统外，从几十人到几万人，从几万元到数百万元，从省闹到总部。
2．最短时间内对已造成的影响拿出解决办法
提取数据，分析影响范围；然后，迅速对受影响对象进行处理。已经停机的赶紧开机；多收的钱赶紧退回去，而少收的钱只能以后再说了；错发短信的赶紧通知客服给出解释口径，等等。
3．找到故障真正的原因
有意思的是，约有30%的故障最后也没找到真正的原因，只能说是现象。因为我们没有“掌握核心科技”，但这并不意味着找不到彻底的解决办法。就像人类对某些传染病找不到真正的起因，但照样可以生产疫苗以使人免受感染一样。
在寻找原因并解决期间，还要为受到影响的业务拿出临时解决方案。因为从发现到彻底解决会耗时几天以上。
4．实施解决方案
找到真正的原因后，不要马上实施。因为这是重大故障，要认证、实验。确保万无一失了，再找时间实施、恢复系统运行。千万记住，别为了解决现有问题带来新问题。
5．故障分析与总结
由责任者对本次故障出具详细的报告。包括故障历程、影响、故障等级判断、处理过程、故障定位、故障原因分析、改进措施等。
以上步骤，对项目经理考验最大的是发生故障的头一个小时，此时不仅要迅速判断故障性质、解决难度，做出人员安排部署，而且要做出停机、重启、版本回退、启动应急等重大决策，没有五年以上经验难有完美表现。
2.2 决策方法
归纳一下项目过程中可以使用的决策方法。
● 拍脑袋
前面讲过，无论一个事情多么重要，多么复杂，工程项目中大多数决策是拍脑袋出来，以某个人的意志为转移的，但并不意味着这样做就没有技术含量。
一般拍脑袋决策的程序为：
第一步，问自己懂不懂；
第二步，无论自己懂还是不懂，找一个你认为更懂的人，问他的意见；
第三步，告诉干活儿的人你的决定，要求他完全彻底地执行。
换个说法，就是先调研收集信息，走访，最好做点有技术含量的验证；然后是想，使劲地想；最后是拍板，坚定地拍。
比如说上线时间这个事。你作为项目经理，是掌握信息最全面的人。在综合考虑版本开发进度、测试通过率、压测指标、业务部门要求时间、避免业务忙等影响后，你心里肯定应该有一个时间窗出来了。但你不能把大家叫来，告诉他们这个时间。也不能找到用户，直接告诉他，你准备在某月某日上线。
首先，你要问自己：在这类项目里我是不是有足够的经验、能力判断上线时间。如果没有的话，你最好就前面那些若干要素一一了解，甚至还要别人帮你做一些功课。比如业务忙时，一般认为月底或月初；上午9:00～11:00，下午2:00～4:00。但不能猜，应该就这个项目具体的业务，从系统中统计过往几个月甚至一年的实际数据进行分析。通过分析，你可能发现在商业区的主营业厅，一般在午饭时间比较忙——白领们都在这个时间出来办业务。你不用反复召集大规模的会议，但需要分别找测试组、开发组、本地维护组、用户各方面负责人一一了解情况。这时你仍是掌握信息最全的人，再结合你在过往其他项目里的经验，一个重大项目的上线窗口期就被你计算出来了。带着这些功课，你就可以组织项目组内部正式或非正式的会议了。会议过程是民主的，但你要保证自己是最后拍板的人。然后，去找用户里最重要的人，双方认可的上线时间也就定下来了。
● 开会
碰到极其重要的事情，我们第一反应就是开会，这是常规套路。你也可以称之为头脑风暴。
开会必备：投影仪，必须有，那种几个人凑到一台笔记本前的感觉太不庄重；白板，笔（这个经常准备不足）；电话会议或远程视频系统，虽然无数次被证明很难用，但总比都飞到北京或某个其他现场强；最后，最重要的，能帮你的那个人，这是充分且必要条件，否则宁可不开。
是的，决策性会议最关键的因素是召开时机和能请到的人。你非要在系统刚刚发生重大故障没几天的时候，约用户谈新系统升级立项，基本上5分钟以内就会被打断：还是搞好你现在这个系统的稳定性再说吧。而关键的人，怎么说呢，在召集大规模PAAS平台升级项目的决策会时，如果公司这方面的一两个灵魂人物到不了，可以毅然决定取消会议。这个技术含量很高，来一帮打酱油的没用。而组织一个项目关键里程碑决定会时，事业部随便谁来都行，哪怕你不来，我也能把会开起来，只要最后把决定告诉你，你执行就是了。因为我有这个能力。
再讲讲会议过程控制，其要点在控制跑题和在充分分析之间找到平衡。印象较深的一次会议：我们得到一个替换其他厂商中间件平台的机会。一位高级技术经理用PPT讲述他花费一周时间收集的用户现系统分析结果，包括硬件平台配置、部署方式、技术架构、业务特性，以及过往三个月的主要故障。继而推导出我司现有产品如何介入以说服用户采购。但他不断被他的领导、研究院资深专家，以及其他同事打断，质疑数据是否准确、分析是否到位、我司产品能不能解决问题等。此时，我打断了他们：你们还记得开这个会的目的吗？这么开四个小时也完不了。听主讲者，花20分钟讲完，中间不许插话；然后讨论，不讨论行不行的问题，出于商业目的我们必须介入，只讨论如何、何时、以什么方式介入的问题，并且今天必须得出结论。
事后我批评组会的项目经理没有控制会议进程的意识。眼看所讨论范畴已不是这个会上能解决的，无组织无效率现象持续10分钟了，还闷头在那里记会议纪要！这些离题万里的内容有什么可记的？他还挺委屈：这都是公司元老，我人轻言微呀。纯粹废话，这就是没认清自己的定位，无论谁在，项目经理都要控制会议进程。
客观地说，沟通性、一般性事务、宣导性的会，比必须要得出结论性意见的会好开得多。因为但凡决策性的事务，必然涉及大把的资金、重要的用户、公司内宝贵的人力资源，也必然伴随着能否达成预期的风险。
所以，决策性会议的会前准备很重要。很多次，项目经理认为各种情况大家都很了解，老板也很清楚。要干的就是把大家召集起来，做一个决定，不会超过30分钟。比如，讨论能不能停下一个“不重要”的项目，调出人来攻坚另一个“重要”的项目。但事实经常是，开场5分钟大老板（如果不幸有他参加的话）就打断了：决定这么重要的事你们就光凭嘴说？数据呢？分析呢？项目的真实进展呢？该叫的人都叫上了吗？然后是各色人等笔记本里一通地找材料，电话会议一通地接入，而那个无辜的同事可能正在马路边吃拉面呢。最后耗费2～8个小时。所以，把你认为有可能用上的材料都准备好，但展示时不要超过三个。而真正详细讨论的只会是一个。
大多数决策会是讨论，轮流（一般做不到）发言，最后由给大老板做出结论。大多数公司里不会有这样的会议通知：今天下午15:00在106会议室召开某某项目期望值法分析决策会。当然这并不代表一些专业方法没有得到使用，只是更多的是临时起意。往往是这个团队里最聪明的人，在某个适合的时点，走到白板前，画出一个模板，引导大家回答他的问题，最后走向他设想的某个结论。最神奇的是，他自己可能也没有设想的答案，而真的是通过这套方法激发出大家的智慧。这样的会议是值得参加的。
下面几个方法是多数“聪明人”可能用到的。
● ExceI
没想到吧？你电脑里的常备工具，平凡得不能再平凡，在所谓决策分析方法里占到90%以上使用率。
关键是用图表。
1．从用户的生产系统里，或公司的生产系统里导出你需要分析决策领域的数据（随便找个维护人员就能干）；或者从互联网，以及其他外部渠道获取你需要的足够数据；最简洁地还是从其他已做过类似工作的同事那里直接索取。
2．加工提炼，提取有用的字段，形成中间数据表，一个或多个，不过最好不要超过3个，这个也可以请IT男帮你干。
3．使用中间数据表，绘成柱状图、折线图、饼图，有时候把原始数据加工计算成极简（不超过3行数据）的表也行。不过这个必须且只能自己干，因为只有你自己知道要编制哪些图，让别人干你就失去存在的价值了。
4．如果需要，继续做透视图，以防老板问你各种刁钻的问题，当然这个也要自己干。
基本上，当折线图出来时你已经知道答案了。比如分析一个核心生产系统的运行质量，以确定系统升级优化点。拿出几个同类系统，画出其在一年内的故障曲线，通过对比，这个系统的运行质量水平是否正常就一目了然了。然后进一步细分故障高发时段发生的事件，如软件版本升级、出账、数据库锁表、中间件宕机、批量业务高峰等，优化其重点，这个项目该投入重兵的地方基本上就出来了。
当然，更神奇的是你做了无数功课、带着小人得志的窃喜，在会上以自认为逻辑清晰的过程展现出来后，很可能被推翻。这也正常，这就是一山更比一山高的结果。如果一个公司里的技术专家、总监们没你强的话，你就该考虑换个地方了。原始数据还是那些，但这些人有能力在5分钟内得到与你完全不同的答案，这也是他们挣得比你多的原因。但还是要感谢你做的这些准备，以及进行了本次会议的组织，从这方面说你比他们有价值。
用于决策分析的表格也要讲究一些。第一，不能太长，保证一屏可以显示全，字体大到坐在会议室中间的人能看清（坐在最后的人看不看清无所谓）；第二，重要内容或数字用鲜艳颜色标识；第三，内容不能自相矛盾，尤其数字类的。这个是很重要的，也是最耗体力的，别把看表格的人当傻子。当你看很牛的人编制的表格时，也很容易找到漏洞，这是规律。
所以，你应该买一本《Office应用大全》，公司的办公软件培训应该积极参加，别以为只有文秘用得上这些东西，这可能影响你的职业成长之路。
● 头脑风暴
地球人都知道是什么东西。使用的诀窍是压迫每一个人提出与别人不同的想法。它不只用在一个重要事项的最终决策阶段。在项目进程的任何一个环节，关于某一个焦点问题，都可以召集必要的人，请大家轮流给出答案或建议，期间不加评论，直至团队的思路枯竭。
它的简化方式：“老王，说说你的意见”；然后：“大S，你有什么想法”；接着，用目光盯住下一个人，盯到他不得不说话。也就是请大家轮流发表意见。
难点在于观点的汇总。头脑风暴得出的原始数据，如果过程真的很民主，将是发散的。独裁者的做法是，看几秒钟白板，然后指着一个与自己意见最相近的点子（可能就是他提的）说：这就是答案。民主一点的话，会逐个进行可行性、优劣势分析，最后得出答案。高级一些的话，可以继续使用一些有技术含量的方法，将之分类、画圈、与现实比较，最后得出答案。
不可否认，这个世界是由精英领导的，从来不存在什么草民的胜利。起码在商业化公司里是这样的。我很反感开大会，把所有人都叫上，去讨论和决定重要的问题。你没发现吗，越是重要的会，参与的人会越少，比如，你们部门的奖金分配方案。所以，曾经一度我只听精英的意见。如果我自认为是某个领域的专家，即使采用了头脑风暴这种形式，最后也会武断地按自己的意见行事。后来也发现了它的危害，队伍会变成一言堂，沉寂，令人尴尬的沉寂。如果身在卖方市场的央企里，可能还无所谓；而如果所处的是一家正常的商业化公司，这种领导风格绝不是什么好事；如果是一家以创新为生存根本的公司，则基本离关张不远了。你自己也很难再从中得到成长。
所以，相信“高手在民间”。从专制走向民主，是一个人职业生涯的升华。
● XY方法
不知道是不是我们自创的。你几乎可以把任何事情分成X、Y两个维度，在每个维度上分解出3～5个（太多太少都不好）要素。然后，在每个二维表单元格中填入内容，最终得到的结果会超过你一个人冥思苦想的结果。比如分析一个系统软件在重要性及难易程度上的取舍。
如果你说这个很常见，一点也不稀奇，我也没啥可说的。其难点在于，你能否在激烈的讨论中灵光一闪，为讨论对象列出两个维度的要素，并引导比你更聪明的人花一个小时把这个表填出来，如果可以，那么这次会议就是值得的。
有时间看看《麦肯锡方法》之类的书吧，虽然过去好几十年了，但有很多还适用。
● 决策制订工作表
这个是真正高级的方法，是我在正规培训里学来的，在这里介绍下应不算侵权。举一个为公司挑选新的办公场所的例子：
第一步列出挑选一个办公场所的所有考虑因素，这期间可以用头脑风暴法；然后合并同类项；接着，把它们分为限制性条件和期望要素两类。
● 限制性条件。即达不到的话就不用再考虑。比如年租金不能超过50万元，某个写字楼各种条件都好，面朝大海，春暖花开，租金要1个亿，你付得起吗？
● 期望要素。好理解，就是最好能达到，达不到的话也能凑合。比如说，附近餐饮方便。
第二步，为每个期望要素设置权重，从1开始，自然数，无上限；要求不能是同一值。这个比较狠，因为必须排出座次。
第三步，拿限制性条件，对标每个备选方案，符合的就“继续”；不符合的就“停止”。
第四步，给在限制性条件里通过的每个备选方案的期望要素打分，1～10。这个也有规矩，即每个期望要素在每个备选方案里的值不能相同。比如，某个场所的租金是30万，另一个是40万，你心理期望是少花钱，那么第一个可以得8分，第二个可以得6分。
第五步，用每个期望要素的权重乘以计分，得出得分。
第六步，将每个备选方案加和计分。
第七步，比较每个备选方案得分，不出意外的话得分最高的会胜出。
需要注意的是限制性条件和期望要素之间的界限。比如你的老板告诉你年租金不能高于50万，它是个限制性条件。但肯定是租金越低越好，所以在设定期望要素时，应该有租金尽量低这一要素。
当然也有例外，你费尽千辛万苦花了一个多月，又整出这么高大上、无懈可击的一个选择表给老板，他可能说，选C吧。即被你首先PASS掉那个面朝大海、春暖花开、租金一个亿的海景房，有他此生永远铭记的回忆，那只能由着他去了。
● 其他方法
还有几个好东西。
● 思维导图。它是非常好用的一个思维导向工具，简单、易用、直观。力荐。
● 鱼骨图，决策树等。这些都是可以使用的方法。各位项目经理的同仁可以多看看，参加一些培训，只有好处没有坏处，别总自负于自己的实践经验。当然我们用得最多的还是在白板上写写画画，使用基本的图形、箭头作为引导思维，得出结论。所以很多项目经理的板书能力都不错，不行的最好多练练。
有关决策的见解就讲到这儿了。说了这么多，都是让你该出手时就出手。这里面有IT项目中常见决策点，以及一般决策方法。虽然并不权威、系统，但是都是以实际经验为主，经常被我拿来作为内部培训使用。关于决策有很多专业书籍，大家可以上网搜索。
最后，把主要观点总结一下：
1．性格决定命运，无论是管理型还是技术型的项目经理，其最大职责都是为项目做出正确的决策。
2．列举了IT项目过程中一些常见的决策点。你可以与此对照，如果发现自己在这些点发挥不了什么作用，可以看第一条。
3．决策形式有两种，一种是拍脑门，另一种是一群人拍脑门。项目经理要用逻辑化的决策方法武装自己，这是职业层次获得提升的必然途径，是对人类社会科学规律的感知与应用。那种纯靠经验、蔑视学习的言论不用理睬它。
2.3 融合BSS中的抉择时刻
● 选择去哪个省实施
先说个人的一个选择。
前面说了，融合BSS实施标，我司中标两个省，B省和S省。起初安排我为两省的总负责人，但很快发现每省都直属总部的推进组管理，两省间协调、可腾挪空间不多。这时摆在我个人面前的选择是，去B省还是S省？这两省我都有工作基础，与分支团队合作不成问题。不同的是：
1．我司确定的项目策略是优先S省，B省跟随。
因B省历来项目执行都很难，不只是客户关系问题，它的项目运营特点是标准出奇的高；这里的用户很专业，也很敬业，但对乙方的“折磨”也很厉害；所以这里执行的项目一般会比全国晚。
2．S省用户基础更好。相互间有信任基础；S省的文化也是更讲人情、礼。
3．选择B省可以每天回家，而选择S省要长期出差。
然而，我义无反顾地选择了S省。原因就一个，在这里把项目干成的几率更大，更能发挥个人价值。对于B省，我和同事，在一开始就有一种预感，即进度肯定要慢一些，甚至它的结果都非常难以预料。后来公司也同意了这个选择。因为以我的性格，不可能去一个“暂缓”的省份。至于离家远、长期出差虽然是一个问题，但我不认为这个工程会做上十年八年。事后证明我的这个选择是绝对正确的。
举这个例子，是想说明，项目经理很多时候没有选择项目的权力，是“上锋”交下来的。但当面临抉择时刻，最好以职业经理人的本能做出决断。
● 工期：T+9月
T+9的意思是项目启动后9个月内上线，T为中标通知发出时间点。这是L运营商作为甲方一项非常重要的招标应答标准，也是其政治诉求。
作为乙方，投标阶段肯定按照应答点承诺工期，但真正启动后，怎么给局方报计划是个问题。因为谁都知道9个月干不完。很多项目都面临这类问题。是采用T+9的方式倒排，按领导、甲方要求违心地排一个谁也不信的工程计划，还是充分估计困难，“科学、严谨”地整一个现实点儿的计划（也只能是一点点儿，启动时谁也没有能力准确估算工期）？
想都不用想，按T+9月排。不解释。
● 数据移植，按什么方式干
有一种情况我们经常遇到：局方强力安排我们在极短时间内完成不可能完成的任务。而且，要按他要求的方式来做。
但真理很多时候还是在乙方手里。即使乙方执行能力确实存在问题，但对工程进度的预测还是乙方准一些，因为甲方再圣明也是“规划和管理者”，而乙方当然对自己的执行能力更了解。
提出不合理进度及方式最普遍的原因，是甲方受政治上的压力。如乙方表示无法达到这个进度，他们马上会提出：加人。当然甲方自己也知道这并不科学。有个运营商领导曾在会上举过这样一个例子：一个大肚婆十个月生一个孩子，为了赶进度，找来十个大肚婆，一个月也能生出个娃呀。说明甲方也是被逼无奈出此下策。
还有因为专业方法上的分歧。局方很多人技术业务很强，也更有经验，因此对自己坚持的方法非常自信。但很多次的事实证明，IT是一种理论与实践相结合的学科，并且以实践为主，而乙方是实践的主体。制订极其不合理的进度目标只有坏处，没有好处。
还有一种原因纯粹是因为甲方某个人偏执，心智不健全，这只能作为个案对待了。
说我们的例子吧。
先介绍一下在一般IT项目里数据移植工作的基本步骤：
1．理解老系统数据模型，以及对应的业务场景。
2．理解老系统数据模型下每个字段的含义，取值定义等。
3．理解新系统数据模型，对应的业务场景。
4．理解新系统数据模型每个字段的含义、取值定义等。
5．比对新老系统数据模型，编写数据移植脚本。
6．运行数据移植脚本。
7．核对数据，检查数据一致性、完整性。
T+3月，我们的移植组从全国集中实施地撤回S省项目组驻地后，终于逃脱了总部的魔爪。这么说是因为集中实施没有遵从上述基本步骤，不给各厂商对新老系统理解时间，上来就是人员集中，简单讲解后，写移植脚本（主要是存储过程）。一个月内要求80%数据移植脚本写完，90%以上准确率。这可是数千万用户量，几千张表。但组织上强压，天天盯着，只能勉强为之。
但回到“家”就不一样了。没人在边上看着了。总部要求继续这种模式，每天上报进度。还听他的吗？我司内部的例会上，移植组负责人提出了这个问题：这么做以后肯定要返工，舍本求末。
我们问了移植组负责人几个问题：
1．集中实施方式完成的数据准确率能有多少？还是根本没有能力评估准确率？
回答：也就40%，再这么干下去到规定完成时间内不可能提到95%；
2．为什么这种方式不行？
回答：对老系统不熟是主因，原表结构还没整清楚。数据移植的简单规律，必须先把核心基础数据，即三户、产品、资费、组织机构、资源等在老系统中的结构理清，与目标系统中的结构对应上，才能整其他的。不可能所有表并行开展。
3．你们想怎么整？
上面已经说了。CRM侧先梳理老系统产品、三户等基础资料，计费侧先梳理固网资费等基础数据。关键是，这两个系统在S省是由另两家公司建设的，需要其维护人员全面参与。
于是我们郑重决定：按移植组想要的方式来，通过用户协调其他厂商参与。然后定自己的时间计划，这个计划可以晚于局方要求时间一个月。
为什么这么决定？第一，简单动下脑子也清楚总部的集中实施模式是不得已而为之，但活儿还是要实施厂商干出来，必须遵从客观规律。第二，我们相信，如果我们在规定时间内干不完，达不到正确率指标，别的省也达不到，还不如早点按正常模式来。
总部通报怎么办？不理他。不过，后来发现不行，只能分一点人继续做规定动作：按天提交移植脚本交总部工程组审核，避免矛盾太尖锐。
● 何时开始计费对账
先介绍一下电信业务支撑系统中计费系统的对账方法：
1．新老系统数据移植，并核对完成。
2．新老系统以同样的顺序，运行同样的数据（主要是话单），以避免因为处理顺序不一致导致的赠送量差异。
3．新老系统结果数据比对，包括总账、分类账、明细数据，以及处理后的优惠信息等。
4．根据比对结果定位数据移植、应用系统的准确性。
由于上述数据移植工作的本末倒置，客户资料的准确性不具备基本条件，所以我们在S省迟迟未开始计费对账工作。
到T+5月大项目组例会时，我们才知道LN省早在一个月前已开始计费对账了。可是，不是核心版本还没下来吗，拿什么跑话单？他们就用培训时那个0.5版本。数据移植不是还没完吗？他们不等数据移植，反而是以计费对账来校对数据移植的结果。后来我们也采用这个办法，这样对版本的依赖性低，自主把握性更强。
反思我们没有这么做是我们的思维禁锢住了，想等核心版本稳定，等数据移植准确率95%以上再搞计费对账，传统项目都是这样。然而我们忘了特殊项目要用特殊方法，导致在此事上落后LN省至少一个月。
回顾这件事，我们最本能的反应是：没想到。所以说到决策这个事，我们没有意识去改变、去决定比决策时的选择还要难。再进一步，在系统尽早上线这个终极目标及各项工作并行开展这个大策略指导下，我们应有组织地为达到这些目标找到促进的办法，而不是一味等待。等待只会使项目策略变成空谈。
● 产品资费绑定方案
先介绍一下产品资费移植的一般过程。
1．产品管理牵涉CRM和BOSS两套核心系统。定义好接口后有两种思路，一是以计费系统为主，计费系统定义好产品的资费策略，由CRM引用；二是以CRM为主，CRM定义好资费代码由计费系统实现。
2．若CRM、计费是同一个厂商完成的，一般来说，接口衔接会比较顺畅。但若CRM、计费是不同厂商完成的，一般需要转换，在上线后的系统容易出现数据冗余、数据不一致等情况。
3．产品资费的移植需从两个角度进行验证，一是前端业务办理；二是后台计费账务处理，即计费对账。
4．因为产品资费，直接作用于用户费用信息，一般来说，以计费系统为主导合适。面向市场营销的产品政策，在计费的基础上进行语言描述。
融合BSS项目中，由于CRM侧进度一直领先于计费侧，故采用了CRM定义好资费代码，由计费系统实现的方式。但进行到一半时发现，有大量的数据对不上。这个事提到我这里仲裁时，考虑的因素如下。
1．产品资费数据无论采取哪种方式移植，最后都要达到99.99%以上的准确率，所以没必要在这个事上争执太久。
2．CRM侧已完成相当一部分，推倒重来会遭受损失。
3．数据移植组组长坚持以CRM侧为主，我一般支持组长。
4．最重要一点，是对CRM侧的人更信任。和他们合作已3年多，而计费组的同事大多刚认识。计费属后台产品，其人员共性的特点是不善表达、一味固执已见，让人从心理上排斥。
所以很快确定继续以CRM侧为主定义资费代码。没想到的是，后期的工程策略主要以计费对账为主，反过来校验CRM侧数据资料移植的准确性。但CRM侧倒换过来的准确率极低，远没有以计费侧为主的高。只能再次修改方案，以计费侧为主导，而这期间已浪费了大量人力与时间。
我们的决策出了什么问题呢？没有考虑到后续工作模式是一方面；项目技术总体组没有发挥出作用是另一方面。正是他们几次讨论不决，才提交到大项目经理最后裁决。而我也没有做出最合理的决定。这是一个非常典型的反面案例，上述因素应成为技术方案决策中的重要改进点，而我自己也有不可推卸的责任。
● 项目策略调整：回头望
“回头望”是融合BSS工程期间最大一次风暴。“风暴”这个词不带有褒义或贬义，实质是项目策略调整。T+5月大项目组月例会后，S省决定改变自己的项目策略。原因前面讲过，大家都知道这个工程很难搞，但落后了以后会更难搞。所以要从“跟随”改为“争先”。这个转换过程可圈可点。
首先，要参与厂商评估项目前期进展、问题、下一步规划。我们认为这是项目中期汇报，很重视，所以集全体PMO人员准备。对于工程进展评估，实话实说很悲观。原因很简单，我们自知没有能力实现T+9月工期，并且认为主导权不在自己手里，而是在版本提供商，在总部。如果再像前几个月一样掩盖尖锐矛盾，静等事态变化，那么很难过关。
汇报本身很成功。但后半程事态越来越难以控制。先是省内高级领导召见，然后S省用户召集总部各方面相关人员（包括我司高级领导）到省份开会、开会、再开会，各种批判会。提出对我们的质疑：你们真正起到实施商的作用了吗？实施商，要为甲方的工程实施落地起到主导作用，制订项目策略，排除千难万险，为了系统的成功上线想尽各种方法。而我们的表现更像配合厂商，推一推，动一动，静观其变。我这个总负责人，被批到羞愧得后悔自己来了S省，后悔自己入职这家公司，后悔自己选择了项目经理这个职业。
公司内部会议有时也是这个效果。从基本逻辑上说我们不可能一无是处，但是，就像用户永远是对的，老板也永远是对的。你的位置决定了这一切是正常的，有些公司就是这种风气，不用被吓倒。
回到正题。“回头望”活动中，我们面临一些抉择，我们可以接受批评，但没必要接受无休止的批判；我们至今不认为T+9月是合理的；后续的工程组织方法，也颇有微词……那么是高举真理的大旗绝地反击，争取更“合理”的待遇，还是一声不吭地接受？
以我的性格，可能反驳。兔子急了还咬人呢。但此时我很清楚，用户并不针对任何一个人，涉及几百上千人的重大工程，要想调转船头，矫枉务必过正，重症务下猛药。所以，此时只能接受，委屈一下就是了，没任何必要另起波澜。
从项目后期直到现在，我们认为“回头望”是正确的，甚至应该庆幸。我们迅速改变观念、跟上局方的脚步也是正确的。由此争取到总部资源倾斜是一方面，更重要的是使所有人相信这是一个能干成的项目。如果继续跟随，以S省体量和复杂度，结果难料。所以我们在期间的表现，勉强及格。
● 割接策略调整：四地市改一地市
这又是一个技术和政治因素相交映的案例。
S省割接上线策略很早就经论证确立下来了。即本省目标系统划分为四个域，每个域有四五个地市，而每域用户量为1200万左右。要在保证进度同时避免一次性割接风险，割接策略是试点上线割一个域，经过至少一个账期后，第二把割全省（另三个域）。
尽早确定下来割接策略很重要，因为工程实施中的数据移植、割接预演、业务验证、计费对账，乃至培训等都与割接策略有关。影响最大的是移植脚本和接口路由程序开发，其次是平台划分、割接预演等。
但当我们即将等来割接试点域的时候，最终命令迟迟没有下来。各种传言开始不绝于耳：据说试点省效果很差，甚至发生了群体事件；本省的各种数据不是那么完美，领导难以下决心；业务部门在和信息化博弈，等等。想象一下几百人惴惴不安地等着一个决策性消息到来的情景，很不轻松。
这种背景下，S省领导召集了一个只有少数成员参加的会议：割还是不割，怎么割？大家一如既往地机智又勇敢：各项工作准备就绪，请领导定夺。领导之所以被称之为领导，就是因为他的脑瓜比你好使。没有说割还是不割，而是提出了一个所有人都没想到过的方案：能否从原计划试点割接域里挑一个小地市割接，割接用户量从1200万降到200万，以将风险降到最低。并且要大家现场表态。这个域里一共4个地市，后来我们把这个叫四拆一。
考验我们的时候到了。
为什么要现场表态？没有为什么，形势需要。你以为领导随叫随到，等你想明白了直接推门进去搞定？也没时间使用偏差概率理论分析上十天八天的。所以各位当场表态。
我的第一反应：不可能。这意味着什么？数据移植、接口路由所有已完成的脚本、程序都要改，也没搭环境验证过。
这时，S省用户项目主管大炮同志（我司员工起的名字）在桌子底下踢了我一脚。我厚着脸皮说：可行！其他几位同样表态：可行。
其实跨域移植乃至接口路由各种方案技术组讨论过若干次了，想不听都不行，因为我那个办公室就是公共会议室。技术上是可行的，问题是移植效率受影响、修改脚本的时间够不够。我们有史上最长的4天5夜停业期，预留给数据稽核的时间非常之长，移植效率也有一定把握。至于修改移植脚本及路由程序的时间太短问题，这是本人最擅长的了。最擅长什么？打鸡血。经过漫长的一年合作，我已被兄弟们视为周扒皮式的人物，以压榨工人血汗为已任。电闪雷光之间，做了上述表态。
这是政治决定技术吗？如果早期项目组里那位以追求技术完美为已任的牛人还在，他会连吃了我的心都有，还好他已退出项目组。回去宣布这个消息时，全体人员接受决定，半小时散会，一百多人立即分头行动！这是何等效率？主要还是因为太想割了。
这算不上政治决定技术，任何项目不是为自己而做，任性而为。这是为用户做的，这个用户是甲方信息化主管部门，更有他们的用户，他的老板、市场、销售、客服，以及终端用户。而用户是人，是人就有自己的主观判断，你绝不能期望所有人和你是一个视角看问题。尤其终端用户，别人才不关心什么新系统上线、网络升级，他们就关心能不能打电话，缴了费为啥不开机。
直至项目整体完成，我们都认为赞同四拆一是正确的。当时S省已不是第一个试点省割接，各界对系统割接带来混乱的容忍度在下降，一招不慎极可能影响部分同志的政治生涯。而我们项目组，遵从这种政治形势，虽然短期工作量、工作难度增加了，但保住了如期（已经是第N次改期）割接，为项目收尾打下了关键一战。