因为“好奇害死猫”，什么都想有所了解，所以至今身无长技，各方面都仍是个新 兵。偏又话唠，喜欢与人聊天。近期收到ITPUB编辑小韩的邀请，说是可否聊一聊技术人生 ，这倒是不敢，要么就说说我自己的一点儿故事和事故吧，我觉得倒是可以说出来大家开开心或引以为鉴。

我 先 是 做 了 软件产品（包含硬件）的实施部署，后又接触测试、用户培训，被技术团队推到前面成了“项目经理”。

帮助筹建过一个业务条线的PMO，遭遇过自己的项目失控，经历了老大年龄又回到起点老老实实从HelloWorld，逐字逐句敲进去从头学JAVA，基于对自己产品相关业务、功能的了解和不再犯怵代码，渐渐敢于在售前工作中答应、拒绝和引入变革。

第一次当项目经理是在北京一个银行的项目，虽然之前已经参与了几个现场开发（主要是旁观），也在投产后的客户现场做过技术支持，但在取得了当时信产部“项目经理”证书后，被公司领导询问是否能当新项目的项目经理、觉得需要什么条件的时候，仍颇为意外和兴奋。

因为是公司已有产品、新客户，销售打算做成标杆项目，公司领导很支持，技术团队的人员个个能力很强。（后来了解，他们中至少两三个人自己带项目都没问题，为自己哭三秒钟）

技术团队的老大只叮嘱了一句：“你去开会，我们写代码，不要乱答应需求、不要乱激发需求，万一答应了，我们做你的后盾！”。 有了底气，交流、倾听客户需求时静定了许多，倾听、反馈、探讨、质疑、建议进退自如了不少。

◆   客户对于我们是新的，我们于客户也一样

真的体会到了“麻杆儿打狼，两头儿怕”。我们不知客户是否会在尚未了解已有行业内实践和系统的情况下，天马行空大拆大改；客户担心我们固守已有产品、代码，不肯做他们的个性化业务需求。

一些技术选择，与其说是因为技术决策所致，倒不如说是双方在过程中相互观察、体会对方意图、意愿的影响占多。

虽然中间有跌宕起伏，但项目还是如期上线了，并且经受了年终业务的考验，没有发生一笔金额错误。

在项目过程中，亲身感受到了甲方的诉求、疑虑、坚持、思考、积极行动，乙方的需求困惑、技术决策犹豫、团队技术带头人在团队中的能量和作用。

但，也造成了两个错觉：“自己可以独当一面做一个项目经理了”，“技术团队，应该都是相似的水平”。

◆   过于乐观的判断，为今后坎坷埋下伏笔

通过了PMP考试后不久，接到委托，帮助直接领导的业务条线成立一个PMO（项目管理办公室）。

类比重大工程成立的PMO，我们显然并不是一个决策机构，甚至实质无权直接下达停工令。而更多是检查、度量进行中的项目，为领导及时定量了解项目进展、风险提供信息，对项目进行风险提示，引入项目管理工具、对项目经理进行技能培训，对各团队的项目管理机制进行落地和持续改进。因为之前也参加过CMMI培训，办公室的工作人员也被我叫成“过程改进工程师”。

PMO确实做到了利用“挣值法”对项目进行持续度量，为项目经理提供了“风险识别”、“Project与进度网络图”、“WBS分解方法”等具体培训，帮助发现、纠正了一两个项目范围扩大、需求“半路”失控、项目交付物定义不明确问题。

◆   但，管理并不能代替经营

为了激发各团队的自主经营意识、算账能力、生存意志，公司向“多层级合伙制”调整。希望从“领导要你干、你要听话干”，转变为”我要干“、“赋能让你干”。PMO这种传统职能型组织的作用弱化、取消，也成为必然。

信心满满的以为了解了项目、了解了项目管理方法，只要坚决贯彻管理意志、使用项目管理方法，就能帮项目走上正轨。每一次貌似的逻辑自洽、自我感觉良好的盲目笃定，都终会被现实毒打。只是，来得如此之快，不知是不幸还是万幸。

受到客户信任，部门接到一个新行业、新客户的新业务项目（对于我们已有积累而言是新），目标是重构现有业务系统，使之能够恢复对业务需求的敏捷支持。

◆   接手新项目， “我”搭台你唱戏，这步棋走错了？

作为项目经理，根据以往的经验，特意挑选了一个技术部门经理带其固有下属的成型技术团队，业务需求分析、技术人员管理、技术决策，全部交给技术团队。 而自己全力争取公司在资金、人手上的资源支持，联络客户、甄别协调各方诉求、解决团队吃好、住好、心情好，与主要负责人和骨干持续强调成功交付的意义和价值。

就像当时自己说的“我给你们搭台，你们来唱戏”。

但随着时间推移，发现项目在需求阶段迟迟无法取得进展，客户现有相关业务理解、原有系统业务功能、周边关系、内部数据结构不能产出，也无法进一步决策新系统实现、替换方案。

才发现：想始终对项目有驾驭能力，不能退居为支持型的“项目助理”，至少应该亲力亲为需求分析。疑问是否高估了团队能力、过于乐观了项目工期、低估了项目复杂度。

得到的感受是：

你对需求的驾驭能力，取决于你对客户业务的理解程度、换位思考和沟通，你对技术团队的驾驭能力，取决于你自己把握产品、技术的程度等“非正式权力”。

对于人员伸缩变化可能很大的项目，只有有“一人成军”的能力，才有可能在适当的时候通过增配人手，实现“千手千眼”。（此处说驾驭而不是控制，是因为我理解的驾驭是根本、重要方向不跑偏，而控制是锱铢必较、算计的博弈。）

◆   代码这东西， 会就是会，不会就是不会

半路卸任项目经理，自我认知遭到重挫。感恩公司，难得有一段时间允许我摒弃外务，类似寡妇撒豆、捡豆，“无求”、“息心”敲最简单的HTML、JAVA的HelloWorld，替代思虑、平复心境。

过程中发现自己原来很笨，敲几行最简单的代码都错误百出，以为看会了、看懂了，合上教材或网页，对于关键字、代码行结束符号、缩进格式、段落竟然记忆全无、理解全无、疑问百出。 

“纸上得来终觉浅，绝知此事要躬行“，才领会代码这东西，会就是会，不会就是不会，与你聪明、笨无关。

◆   代码不骗人， 若程序报错，定是自己错了

学习编程，只能从自己动手“编”下手、老老实实敲每一行代码、每一段代码，都跑通，再改一改、想一想、试一试、玩儿一玩儿，无法跳跃、无关“简单”不简单。

 “不纠结（于心）、不纠缠（于事），无心于事、无事于心”，成了这一段时间萦绕在心头，避免无谓内耗、平静心绪的口诀。

千手千眼

得到了一个进入某大型客户项目的机会，向各方明确不再担什么“项目经理”的虚名，就是负责产品测试、用户使用文档编写、用户培训。

◆   “逆境不空过，顺境不枉为，无忌守本心”

一切似乎轮回到了原点。任务明确，轻车熟路，心情倒也纯净、平和，工作进展也顺利起来。有节奏、有效率的完成本职后，正好可以自由地调试、阅读仍不大看得懂的这个B/S系统源代码。权当调节心情、锻炼意志、磨炼自己如笨拙铁杵般的代码技术能力（也许还有心智，苦笑）。

与枯燥的学代码不同，有项目需求、真实问题的推动，每次看代码就有了明确的目的和可验证的结果。以问题为线索，使我能够渐渐进入各个具体功能的代码实现中去观察和理解。对于各种对象、写法也基本混了个彼此脸儿熟。一段时间以后，居然也可以用IDE对代码进行编译、调试、修修改改、照猫画虎了。 

“逆境不空过，顺境不枉为，无忌守本心”是这一段时间，虽未成型，但酝酿在心里的一段话。

期间觉得，以前按照岗位定义要求每个人与岗位对齐是费力不讨好的，只有当你自己不同程度具备多种能力后，才能根据合作同事的知识、技能情况，主动调整对接时描述问题、下达任务的方式，去有效解决问题。

说白了，就是对方不熟悉系统的情况时，就明确具体动作指令，只延展借用同事的手、眼代替、延展自己的手、眼；如果伙伴对系统有知识就可以简练成术语交流；有自主工作能力就只描述清目标即可，既有效连接、延伸彼此能力，又相互体会到成就和尊重。也许就是相当于“千手千眼”了吧。

随着几年的项目接近尾声，我的工作压力也从上线推广支持、售后支持多出些许余暇。为了小团队的生存，开始分出精力跑产品售前交流、投标的事。

◆   客户需求的倾听者，客户期望的建立者

有了对客户业务、产品功能和结构的更多理解、代码的一点点驾驭能力，在售前交流中感到能更快的与客户有效进入业务情景讨论，结合客户业务讲解及演示产品，更从容地倾听客户需求、理解客户具体人员所处的需求情景。 甚至为了有效演示进行系统的快速修改、临时创造对客户有价值的功能，偶有左右逢源的感觉。

体会是：售前，不仅是产品的演示、讲解者，更是客户需求的倾听者、客户期望的建立者。

不能只追求自己讲得多、讲得全、讲得有条理、讲得爽，而是要讲到客户的关切上，听懂客户的诉求，问出客户的情景，建立客户对未来前景的希望和信心。售前不是靠提供虚幻的希望，给后续团队、客户挖坑，而是建立一个切实可达、可行的期望。

售前闲暇，把自己曾经的误以为、弯路、感触写了个豆腐块的《售前工作》分享在了公司群里，倒也不怕更丢人。但愿大家能从我的错误中看到“坑”，不必重蹈覆辙，在我的有限实践中，略有启发、甚至获益，秀出各自的精彩。

经历和水平太低，我的笑话和偏见先讲这些，告一段落吧。