作者：曹亚波
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
闲话IT项目管理试读：
前言
这是一本写给项目经理尤其是IT项目经理看的书。
IT项目经理是一个具有挑战性的、需要综合技能的职位。很多中国人、外国人努力从管理理论及实践认知中提取共性的东西，使它从一个工作岗位上升为一个专业学科。因此，现代想从事这个职位的年轻人需要做两件事：一是考证；二是在现岗位上学些真本事。本书主要探讨的是后者。
本书写作的直接动力是笔者经历的几个大型项目。只有亲身经历过，才能真切感受到人类规模化生产劳动的方方面面。如果不把它记录下来，把规律总结出来，会很可惜，会随着时间的流逝被淡忘，重新归于平庸。另一个动力来自于同事、朋友的鼓励：既然你这么能说，这么能写，还给别人上课，为什么不写本书呢？那就写吧，也许还能出名呢。
由于本书是按照笔者熟悉的方式来写的，所以读者一翻开书就看到一个案例。这基于笔者的一个认知：所有的一切从实践中来；只有做过的事情够大、够难，才值得向别人诉说。虽然做的时候有些痛苦，但随着时间的推移，我已经可以用轻松的心态对待它。
本书中的部分内容作为内刊在笔者单位发表的时候，仅凭这个案例就已吸引了大量读者。因为它以调侃的笔调说出了大量IT项目常见的困难，引起了同仁的共鸣，也满足了很多人的好奇心。你们花费几千万元的成本、一年多的时间，到底干了些什么？这个项目的进程并没有超出启动→计划→中间管控→上线→收尾的传统范围，但它是独特而吸引人的。因为这是一个没有先例的系统、没有先例的组织方式，你在任一时刻都不知道后面会发生什么。但在项目总结时，又觉得其实每一件事都遵从了项目管理与企业运行的规律。我想这对没有参与这个项目的项目经理同样很有价值，所以把它写出来分享给更多同仁。
我曾经认为，通信行业的IT项目过程不应该如此艰难。因为这个行业在旁人眼里是高精尖的、资源充沛的、精英汇聚的——起码在刚进入这个行业时我是这样认为的。但是当我融入这行业后，发现其他行业该有的它都有：政治因素，不靠谱儿的计划，不计成本的投入，无休止的加班，不确定的技术方案，以及半路夭折的项目。而更困难的是，它的规模更大，技术复杂度更高，系统高可用更严格，对计算、通信、数据技术的应用更深入。所以我相信把通信行业的项目管理经验分享到广泛意义的IT行业，也是很有意义的。
写完案例之后我沉寂了一段时间，因为没想好后面按什么方式写。最传统的莫过于五大过程组、十大知识领域，但我不想把这本书变成睡前必读。同时我还纠结到底是讨论项目过程管理还是专门谈项目经理？最后决定在第二部分谈项目管理，第三部分专门谈项目经理。
第二部分的主题是谈项目管理，但主要还是从项目经理的认知角度去谈。比如项目管理中的决策，总结了一般IT项目会遇到的决策点以及决策时用到的或简单或复杂的方法，但着重强调的还是项目经理需具备的决策意识和能力。整个第二部分的基调是：项目管理的方法过程千千万，但作为项目经理，只有认识到、能运用才有意义。而作为一本读物，这种方式对读者也更有吸引力。
在这一部分里，章节的确定及每章内容的编写，不是为完整性、成体系去构建的，而是从其重要性、在实际工作中遇到的频率来选择的。这对我来说写起来很轻松，因为就像在做岗位描述。而对读者也更加实用，因为这部分内容几乎覆盖IT项目经理90％的工作情境。
基于上述原因，第二部分出现了其他项目管理书籍很少涉及的几章：用户与同事；为了上线、不惜一切；系统运维。它们是IT项目经理工作的重要组成部分，同样需要积累方法与经验，由于其具有独立性，因此独立成章。
第三部分个人认为是精华，因为其抛开了项目管理各种理论方法过程，纯粹谈项目经理个人。优秀项目经理应具备何种性格，历练哪些技能，以及如何规划自己的成长之路，是写这一部分的初衷。最吸引人的是，读者会在每个专题里看到自己的影子。你会边读边拍大腿：噢，我就是这样的人。可能引起争议的是：这是不是有点太绝对？有这么夸张吗？可能没有，但你肯定会遇到类似的问题。不管怎么说，项目经理作为职场中的一份子，需要在职业准则与价值观、管理与技术技能、个人工作习惯上不断追求优秀与成熟。相信很多人会喜欢这一部分的。
最后，不能免俗，本书能够成书要感谢一些关键的人。
首先感谢本人职业生涯中服务时间最长的公司及这家公司的老板吴总。在这里，我从一个初入行的菜鸟，逐渐成长为一个数百人团队的领导。这全部源于吴总及公司数十年如一日的专注培养，才使我有这样的成长机会。我们的吴总，他活着好像不是为了发财，也不是为了享受，他没有任何不良嗜好，他是我见过的唯一视工作为乐趣、为生命的人。
其次，感谢我的两位导师，陈总和焦总。坦白地说，我这点儿能力，包括写作的水平，不及他们三分之一，而焦总比我还要小上几岁，但他们为我树立了职业榜样。每当我遇到极艰难的境况时总会设想：我的导师会如何处理这个事，我能否表现得和他们一样好？焦总在我刚入司时，专门花三天时间对我进行入司培训，让我至今受益匪浅。书中很多工作法则与规律，都来自两位导师的言传身教。
然后，感谢我的同事。书中很多内容来源于与他们的共事。他们当中的某些人被我像神一样来看待。艰深晦涩的通信术语，这些人信手拈来；专业而刁钻的用户，被他们轻松搞定；纷繁复杂的交换网元，他们视为家常事物。在他们身上学到的，比我在其他任何地方学到的都多。当然另一类同事也值得感谢，他们的无知、无能、无责任，使我不得不努力学习、想尽一切办法应对，也因此丰富了我对项目管理的经历。
最后，感谢我的用户。是他们无尽的“折磨”为本书提供了大量素材。使我千锤百炼，百战成钢，并对电信业务支撑系统、对追求卓越有了更深刻的认识。其中，也有很多用户不打不成交，成为了我终生的朋友。更是他们给了我信心，让我知道我所坚持与践行的，对用户、对社会有着真实的价值。第1部分融合BSS项目案例第1章 融合BSS项目第1章融合BSS项目
融合BSS上线整一年的某一天，刚好在S省出差，一起战斗过的用户和同事都挺感概。当项目接近尾声时，我曾半开玩笑地说，工程结束后写本书，就叫“我在融合BSS的日子”，或“我和融合BSS不得不说的故事”。但真等上完线，就彻底歇了。时隔一段时间后，还是不时回想这个项目，因为它真的很特别。1．1 项目背景
融合BSS被看作是L电信运营商打造全国一套系统、拥抱互联网策略的前奏，但信的人并不多。系统向集约化、全国一体化发展方向虽成立，但要落地成为现实，难度很大，且充满不确定性。对比京东、淘宝这样的互联网企业，后者没有三十一个省份公司，没有各省发展了几十年的大小上百套系统，没有几十万从业人员，更没有业务规则的各省差异。一个要搞拆迁才能建设，另一个骑着马拉根绳圈地，不是一个概念。
但我们还是要搞。并且“创新”性地提出了先招标统一版本，再招标多个实施厂商、全国（部分省份）同步实施的模式。统一版本，意味着这个行业第一个国产套装软件要诞生了。最后，业内市场份额最大的A公司中标统一版本；在多省同步实施的招标中，我司中标B省、S省（本人负责的省）。工程要求在T＋9月内完成（T为起始点，即甲方发出中标通知日）。
由于我司在此项目中90％的工作是“实施”，所以有大量的工程组织、数据迁移、系统部署、接口联调、验证测试等工程范畴工作，而研发性工作并不多。以此为案例分析项目管理过程具有典型意义。1．2 工程概要进展
■启动阶段（T＋1月）
发布中标结果之后约一个月时间，都属于启动阶段。
这段时间我们的主要工作：
1．参加各种启动会。
2．内部疯狂抓人。
3．以T＋9月为目标排计划，制订项目策略。
我们最大的困难：
1．没人
在投标时我们承诺S省投入280人（售前一个疯子想出来的），而在启动时两省加一起也没有80人，我要疯了。
2．真的要用A公司的统一版本
很多人不相信这个行业能在9个月内落地实施全国统一版本。我们也不信，所以项目启动初是做着“适时”替换成自己公司版本的打算。但参加了甲方组织的几次启动会后便相信了。一是“政治”上的高压；二是在项目管控上采取了总部统一调度、集中实施的方式，不像原来开完启动会就不管了；三是将系统前后端分离，前端业务受理独立出一套系统，放到总部，后端业务分省实施。
但核心生产系统多个省实施统一版本的确没有先例。不仅要有电信业务支撑系统，还要有产品管理、业务受理、订单、渠道、三户、基础域、计费批价、预处理、账务处理等十几个核心子系统。使用传统方式，每个子系统做大版本升级建设，都要几十号人在现场，和用户折腾半年以上，投资几百万元；如果是核心主生产系统全面大版本升级，一般工期在18个月左右，要投资数千万元，甚至上亿元。各家集成商付出数年心血搞版本统一，用以实现软件的边际效益，但多数以失败告终。现在要一次性地使用一个竞争对手的版本，且在9个月内实现多省同步上线？做梦。
梦的解析：应用系统＝应用软件＋系统及应用参数＋数据。统一版本意味着，应用软件是唯一的、不允许各省间有差异，所以，业务差异及系统差异都要通过各类参数配置实现。套装软件成立的前提是业务的强一致性。在国内，由于各种原因，31个省份公司业务特性差异很大，每个省份公司都是年收入几十亿元以上的独立运营主体，绝大多数信息系统也是独立的。数十年的演进过程中，总部的角色是出规范、标准、监督检查。而这次，系统被上收并交由总部统一建设。但市场运营的主体还是在省份，业务规则流程也不可能一夜间全部简单划一，尤其对于存量用户、存量业务，比如小灵通。运营商想放弃、通过业务替换保留用户，但终端用户可能并不买账。甲方的意图是想通过系统的统一倒逼业务市场统一，从而推动互联网模式转变，这是一场巨大的博弈。如果因系统混乱造成运营商收入下降，这对极度重视业绩指标的运营商来说是不可容忍的大事。一切皆有可能。
有人拿银行系统举例（那时提阿里的还少），它就是全国集中或双中心模式。但毕竟电信和银行不一样，至于怎么不一样，这里就不展开了，其中很重要的一点是，两者在历史进程中的建设策略不同。
启动阶段除了启动会，更重要的是会下的沟通，以及与用户高层的沟通。我们马不停蹄地在总部、省份各级领导间拜访、汇报。得到的信息量如下。
1．这个事必须成功。
2．统一版本的决心很大。
3．你们要干不了就早说，我们找别人。
4．我们最关心的是你们怎么保证自己的人力投入，我们要你们最得力的人。
5．这个事史无前例，对甲方影响非常之大，本来就很难，如果还有人留心眼、使绊子，我们不会让他好受。
你看，越是高级别的人，说话越实在。
在启动阶段，我们完成的工作如下。
1．形成公司级PMO。
2．明确项目策略：积极投入，通过实施工作抢占核心系统地位，为今后在本省站稳脚跟、扩大份额打造基础。
3．初步形成60余人的现场实施团队（S省），明确总技术负责人、各大组责任人。
4．按照局方T＋9要求形成初步项目计划。
5．编制《融合BSS项目管理指南》，明确工程实施方法。
6．与用户形成沟通对应关系。
■集中实施阶段（T＋4月）
集中实施，就是把大项目群组中共性的工作让所有人一起来干。实施人员主体是实施厂商、版本提供商，也包括甲方信息支撑口、业务口人员，共有几百人。
而我们要做的是：
1．在某培训中心集中各厂商、甲方人员进行统一版本培训，为期20天，约300人。
2．在某培训中心集中所有厂商数据移植组人员，开始数据移植，为期2个月左右，约200人。
3．在某高级酒店集中所有厂商开发、接口、报表组人员培训，为期20天，约150人。
4．在某四星酒店，集中约200人，在一个半月内进行S省份业务需求与目标系统比对，编写新需求规格说明书及测试用例。
以上用的都是付费的培训中心或酒店场地，每人每天费用300元左右。在项目启动头三个月，我司在S省实施的花费就接近千万元，花光了合同中标的那点儿钱（低价投标）。甲方次年补了个大合同，那是后话。而对于上线，我们却连需求都没搞利落呢！疯了，一切都疯了。我们意识到自己陷入了一场疯狂的烧钱游戏，停也停不下来。
这时我公司参加上述任务的人员当中，CRM侧由于有我公司在S省份支底子，所以还好。而计费侧则是临时搭的草台班子，基本两眼一抹黑。新系统一直没下来，就只能先拿着版本提供商A公司某一省的老版本数据在那儿折腾。总部的管理模式，一上来就是细化到天的进度表管控、各省排名和红头文件通报。这还没完，刚启动3个月时，各项基础工作八字没一撇，便要求上报割接方案。主版本还没下来，就要求T＋4月内完成配套接口工作。
进入到集中实施阶段的那三四个月里，我们感觉自己像是进入了一个巨大的漩涡。坐在金融街办公室里的几个人，加上某高级咨询公司的十几员干将，对着墙上的进度表，指挥调动着全国上千人的集团军作战。方法简单、粗暴，要求各省的各项工作齐头并进，却全然不顾各厂商对承担省现状的了解情况。而总部承诺的统一版本的交付，一拖再拖。各实施商不断向项目投入人员，花费着巨大成本，却不能按照自己熟悉的、科学客观的方式干活儿。这时候我们才知道“大跃进”是怎么回事了。
项目结束很长时间后，我们才能稍微客观地看待这种集中实施方法。
如果你是这个工程的总负责人，面对全国性的复杂局面，让一个临时拼凑起来的队伍，把各省老系统、老业务整明白，提交给新系统集中开发团队开发，估计要用一年时间。再拿到省里实施，又一年过去了。先不说承诺的9个月工期，当两年以后业务环境发生了变化，这期间的增量需求就有上千条。所以你的选择很可能一样，不管那些老系统、老业务、老朋友是什么样，一切以目标系统为标准。先告诉你目标系统已定，一切以T＋2月结束的需求比对为基础，过期再提交的一律不“伺候”。所以工程一上来就是实施阶段。
通过集中实施我们明白了，这个项目的模式是：不用你写一行代码，全是实施，一心就等核心版本。
我们为核心版本总结两句话：
1．千呼万唤始出来。
2．想说爱你不容易。
核心软件的基础版本是A公司入围测试招标时的版本，但要以各省的业务梳理（T＋2月内完成）开发增量需求，形成基线版本。开始告诉我们1个月就能出来，结果没有出来；7．15是终级版，虽然下来了，但我们T＋2月提交的需求在哪儿呢？看来业内老大的研发能力不过如此。
核心版本的交付延迟是在总部极其严肃地对各省调度工作下发生的。好，我们什么都不信了，先踏踏实实干好自己本省的活儿吧。由此形成了S省的项目策略——跟随，我们等别人先上。它在各省里厂商关系比较复杂，体量最大，业务也最复杂。而统一版本的实施谁都看得出会是一路坎坷。难道说跟随有错吗？
有错，看看后来发生的事情就知道了。
■分省实施阶段（T＋12月）
T＋5月中旬在某省召开的项目月例会是这个项目的转折点。
激动人心的誓师大会过去了，各种红酒、白酒、地方酒也喝过了，集中实施也暂时告一段落，此时大家心里基本有个谱儿：T＋9月没戏。而问题在总部的核心版本，不在大家。于是T＋5月中旬在某省召开的项目月度会中会议日程前99％的各省发言，都是在摆困难，提要求。上百人的会议形成风向：要求分版，要求支持本省个性业务，要人。而割接时间，谁也不说。更出乎所有人意料的是，本次工程计划第一个上线的试点省H省也是这个态度。
但在最后时刻，总部领导讲话时形势发生逆转。结论：不分版，工程时间不变。强呀！有没有庐山会议的感觉？于是大家各回各家。
然而，好戏还没完。会后没两天，黑马LN省跳出来，说自己完全有信心，希望替代原试点省先期上线。要知道，试点省的确定是非常严肃的事情，因为它和总部有着特殊的关系。于是风向彻底扭转，各省开始纷纷“求上进”。凭借数十年的系统建设经验，大家都很清楚，这类项目只要在一省成功，就可证明当初的决策是正确的。而没有成功的省，只能是你配合有问题。而比烂尾楼更要命的是，信息系统干到一半时骑虎难下，左手要生产，右手要新建，十分难缠。
于是S省开始改变项目策略，从“跟随”转为“争先”。
变化是颠覆性的，S省甲方主建部门几乎全员加入，连地市抽调人员也增加了几倍。而在厂商这边，首先我差点被拿下（谁让你是头儿来着）；又被要求成倍增加人员；移植、对账、测试、配套、接口、培训、系统平台各项工作，也要以争取集团资源、第一批割接为目标来全面推进。
你不得不佩服这个项目的控局者。不用说这么大的工程，且是集团军作战，即使你负责的只是几十万元的小项目，你能做到使你的团队成员不惜一切代价，穷尽自己的智慧，在转变作战方向时唯你马首是瞻？很多人做不到。因为你不知道如何带领他们，更找不到让他们把项目目标作为自己个人终极目标的办法。你只能和大多数人一样，拿小鞭子抽着，或好酒好肉伺候着，让这帮人替“你”干活。这的确是门学问，只有最优秀的管理者、最老到的精英才能做到。
转变策略后省份实施阶段的工作一言以蔽之，就是根据形势需要，多轮次突击赶指标。主要是看业务验证通过率及计费对账准确率，并以此争取总部资源倾斜，而另一方面也希望借此不同寻常的工程方法，加快进度，以人力的加倍投入换取时间。这个期间工程实施的“新”方法、“新”思路层出不穷，也是加班时间最长、最辛苦的一段时间。
这期间的重要事件：
1．人员组织方式调整
打破厂商界限，按职能混合编组，即按照开发、移植、计费对账、测试、配套、技术与接口、培训、系统平台、割接职能分组，这是从来没有过的。而每个组里有不同厂商人员、甲方人员，我们既要按招标时厂商分工界面分配工作，也要考虑个人的工作能力。这种组织方式最大的好处是消除厂商间壁垒与竞争，使参与各方将大项目组目标作为自己公司项目组的目标。你想单搞一套也不行了，因为你的人不一定归你管，他首先要听自己所在组组长的。
在甲方强大压力下，我司从本部、各省分支抽调人员，又加入第三方外包公司，使人数从60人扩到160人，高峰时达到200人。大项目组人员在400人左右。参与人员数量急剧上涨。
2．各项工作并行开展
这是本次工程最重要的特色，也可以说是经验。极大地压缩、降低、人为拆解工程实施工作间的依赖关系，极力使各项工作并行开展，以缩短工期。而作为关键保障，每项并行工作都由专门小组执行，极大减少人员复用，这才使策略得以真正执行，但人员数量也极度膨胀。
割接方案。最难的并行工作是割接方案。以往我们一般在接口联调、用户接收测试通过后再出割接方案，做割接演练。而在本工程中，版本开发阶段就启动了割接策略、割接方案的制订。
计费对账与数据移植。对于传统模式下CRM与计费同步升级的项目而言，计费对账要待数据移植准确率达到一定比例后启动，本次反而是以计费对账工作校对移植效果。
培训。一般项目里培训是最后一项进行的工程实施工作。本次考虑到上万名人员接受培训，务必要分多个轮次，并且还要求经过培训的营业员进行工单补录。再怎么算，没有3个月都是不够的。因此，版本不稳定、数据不准确、环境资源紧张、项目组抽调不出培训讲师，都没能阻挡大规模培训开展的脚步。
3．办公地点更换
从市内办公地点转战到S省培训中心，这是一个方圆十公里以内很难见到城里人的地方。几百人全封闭，心无旁骛地干活儿。
4．京沪高铁开通
这个重要吗？重要。车站离培训中心很近，到其他中心城市很方便。我好几次周六晚下班乘坐最后一班火车回家，周一早上乘坐第一班火车，赶在上班前到办公地点，竟没人知道我回去过。
5．反复多次的数据移植、对账
数据移植组集中了约80人，计费对账组也差不多，都是史上最大规模。从T＋6月开始，到T＋13月试点地市上线，7个月里搞了不下30轮对账突击。而在传统项目里只会做4、5轮。这意味着多少个夜晚无人入睡，多少次攻坚围城，大家开始很痛苦，后来反而有驾轻就熟的感觉了。
6．版本测试
我们这个组四十人左右随着项目进程进行了各种测试：功能测试、贯通测试、拨测、冒烟测试（151个核心业务场景）、市场部业务验证测试、性能测试、高可用测试、版本接收测试、兼容性测试。看着那些脸色发灰的小姑娘的脸，真心觉得测试组也不容易呀！看来，女也怕入错行。
总的来说，测得还可以。从T＋4月只有30％通过率，到上线前已达到99％以上。
还有一个很重要的成就是测试组积累了数千个场景的测试案例库，形成了冒烟测试规范，为版本迭代升级提供了质量保障。
7．配套项目
项目配套是唯一让人欣慰的一个组。为什么？因为接口少，基本不依赖那个千呼万唤出不来的主版本。尤其我司承担的三个主配套系统，在这个大项目开始前就已说服用户启动解耦项目，所以分库、接口标准化，实施比较顺利。
8．接口组
生产系统里最易出故障的就是对外接口。它的建设过程比核心版本还难。要等核心版本的对外服务协议下来才能做开发，然后再和上百个外围系统（客服、网厅、短厅、银行、财务、办公OA、互联网等）联调。过程很曲折，好在最后上线表现极佳。
9．培训
据统计，生产系统升级导致投诉的有50％是由于培训不到位、营业员使用不熟练引起的，可见培训的重要性，而培训这个组做得也不错，取得了骄人的成绩。在版本、测试一直进展不怎么样，以及工程一直极度紧张的背景下，我们还是在三个月里做了几轮全省级培训，近两万人次。这次培训很彻底，为上线后无营业积压立下汗马功劳。
10．平台
新建机房、搭建开发、测试、移植、对账、并行录单环境，到上线前这些条件完全具备，很给力。
最后不得不说工期。T＋9月最终还是没有实现。但从另一个角度上也可以说实现了，因为后来确定的试点省LN省实现了，其他各省也号称“初步具备割接条件”。在这种局面下，各省份的自主性增加了，当然也包括S省。T＋9月后，我们一边收集试点省上线后的问题，一边把前期“萝卜快了不洗泥”的那些基础工作，尤其数据移植准确率、差异性需求的应对方案、版本测试等夯实，又把割接演练进行了5次，这在其他工程里是没有过的，很好地起到了练兵作用。
■割接阶段（T＋15月）
这个阶段反而简单，一切为了割接。T＋13月割一个试点地市（约200万用户），T＋15月一次性割接全省（约5000万用户）。
然而，这个阶段也是惊心动魄的。千年等一回，割还是不割？什么时候割？是按原计划割一个域（约1200万用户），还是改为一个地市以减小风险？割接后怎么保障？印象最深的是试点地市范围的变化，后面再细说。
不管怎么说，割接成功，三军过后尽开颜！一年多，数百人的辛苦，在投入全省营业的那一刻得以回报，这种感觉难以言表！
写了这么多，都是融合BSS项目，相当于本书的序。“序”很重要。它是各个行业每年都在发生的重大工程中的一个。它既特别，又普通；既不空前，也不绝后。但做项目管理的人，正是在这样的工程里对自己从事的行业，以及人类生产活动的客观规律有了更真切的认识。它再次验证：
1．人性最阴暗、最光明，最愚蠢、最智慧，最虚弱、最强大的一面，在巨大的压力和变革下都会展现得淋漓尽至。
2．只有实践，才会使人对职业有更进一步的了解。有专家说，最痛苦的时候，也是成长最快的时候。
值得多说一点的是，电信行业运营支撑系统，与现在方兴未艾的互联网系统有相同点，也有差异。从本人视角来看，二者类似的是承载的数据量大、业务并发高，以及7×24小时的高可用性。不同点在于，电信运营商财务充足，购买的都是高端设备、商用软件。而互联网企业，花的是投资者有限的钱，所以去IOE成为必然选择。同时，电信业务运营支撑系统各省差异很大，统一版本只能是核心一致、外围差异化；而互联网系统就是一套系统，用部署多个实例实现负载分摊。后者貌似已走在了信息应用技术的前沿，不少传统IT应用行业正开启追赶模式。
此处商务模式上也不同。前者是传统的乙方向甲方交付的方式，工程项目的政治因素很强。作为承建的乙方，有一个不太好的前提，即开发的系统自己并不用，完工的标准是甲方验收。而后者，不论规划、购买设备、功能开发、交付运维，都是自己负责。所以他们自然怎么省钱怎么来，怎么高效怎么来。实践是检验真理的唯一标准，所以慢慢地，他们近乎开创了一个在开源架构上搭建巨大规模系统的奇迹。这也是其后发而领先的重要因素。当然从项目管理者角度来看，当系统规模大到一定程度，企业机构足够细分之后，传统IT建设遇到的问题互联网企业也会碰到，而其该有的政治因素也会接踵而来。毕竟，我们都在地球上。
所以，我坚信项目管理者的经验和认知是行业性的，而行业的边界在模糊化。
下面进入正题，从项目经理的角度谈项目管理，也从项目管理的角度谈项目经理。
本书对话的假设对象是项目经理。然而，我不总结电信专业与IT技术知识，这方面有成千上万的人比我有水平。所以我主要总结项目管理规律与准则，以及项目经理需具备的技能。这个虽然也有很多人比我有水平，但希望能以我的视角，为读者提供多一点借鉴。第2部分项目管理的过程与方法第2章 决策，还是等待，这是个问题第3章 除了计划，还是计划第4章 扼住成本的咽喉第5章 度过最漫长的岁月——过程管控第6章 用户，同事第7章 为了上线，不惜一切第8章 项目绩效考核，想说爱你不容易第9章 运维，比建设难第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小时之内通知用户，把初步方案告诉他，请他一起和你想办法。这没什么神奇之处，需要的只是勇气。
试读结束[说明：试读内容隐藏了图片]