【项目交付回忆录】三：跨越障碍

“写在前面：交付回忆录系列是一次完整的回顾记录，可以全面了解作为一个新人如何完成从0-1完成项目交付。通过复盘和总结，一方面找出做的好的，可以适用于未来场景的工作经验，甚至辅助提升思维方式和工作习惯；另一方面，找出做的不好的，仔细分析场景和原因，找出改进的方案和措施，能在以后中尽量规避。

上一期讲了通过3个月时间，逐步了解项目全貌、干系人以及项目系统集成部分工作内容，逐步成长为小白的过程，那么今天就讲一讲成为小白之后，在项目上过渡为一个大白的经历。

成为小白后，项目上有一些工作基本已经开始可以独立负责了，比如承担项目周报的编写、发送；与接口人沟通传达项目进展；解决分包商的疑问，参与部门的招投标工作等。由于项目内部成员有限，因此工作量每天都是超饱和状态，曾有连续两月无休息的工作记录（包括周末），经常每天都是工作十几个小时以上。

超负荷的工作内容，高强度的工作压力下，更需要一个清醒、理智、善于思考和总结的头脑。可能大家都会认为，已经很累了，还要我动脑子，还要每天做总结，那岂不是要了命？其实并不是的。第一，忙的原因（详见文章：时间管理的真谛），拆开来看，除了纯碎因为内容真的太多外，更主要的原因是由于单效率差，导致处理一件事情花费时间特别长；第二，如果工作内容太多，即某一具体时刻工作数并发量过高超出个人处理的负荷，其原因主要是由于无规划，没有分清楚梯队和优先级。所以，让自己忙碌的原因并不只是外在，我们应该多从提升效率和完成规划做起，不管多忙，都不能放弃这两部分不做，否则永远也无法改变，将会一直忙下去，越忙越乱，越乱越忙。

成为大白后，面临了第一个工作转型。之前提到过，项目是分为系统集成与软件开发两部分。由于项目上新增了一些角色，也考虑到个人发展因素，因此工作调整为从负责系统集成工作部署到负责软件开发工作协调，可能这个角色，更接近于项目经理，也是从这个时候开始，慢慢向真正的PM转变。

由于项目中涉及开发8套应用系统（共12个系统，40个子模块），所以涉及的工作内容还是非常多的，且每个系统都有不同的分包商、用户方，因此工作重心慢慢逐渐往与人打交道转变。据不完全统计，从切换工作内容开始，日常平均接口人30人以上，多则五六十人，QQ、微信、电话、会议……这种状态持续了一年多。关于与人打交道的过程，曾有段时间让我充满痛苦。

第一方面是身体累。当时的项目上，作为一个接口人，很多人眼睛都在盯着你，客户、用户、分包、你的领导……尤其在客户现场驻场，除了项目工作外，还会涌现很多跟项目有关或者无关的需求：帮忙准备个材料、临时的各种汇报、参与运维组的会议（与客户方运维协同），还有重大时期的网络安全保障等。有时候早晨一来，根本没办法待在工位，游走于各个办公室之间，接收各种各样的需求，再想办法去响应；夸张中的常态是，有时候在大楼内步行都能超过10000+。

第二方面是心里累。每天要接触各种各样的人，就要讲很多的话，要保障信息有效、合理的传达。这是一件难度超高的工作，到现在我也没见到哪个组织在这方面做得足够好。讲的话多，就容易出错，所以尽量让自己更专业、更精准，所以每句话都要经过思考，才能快速应变和做出一些决策。这样的工作模式对人的消耗是巨大的，所以经常下班后到第二天上班前，一句话也不说，经常长久的保持沉默。

经历过很多煎熬的场景，所以我对技术转型的项目经理会产生很多的共鸣。从跟代码、设备打交道，到与人、与组织打交道。整个的思维模式、压力层级是完全不同的。前者具有比较明确的确定性，以客观视角居多，是什么就是什么，模糊的只要能够去学习、探索就好，主观比较能掌握；但是后者，基本上全部遵从于主观意志，尤其是项目规则未建立起来的时期，基本是一天一个想法，一会儿一个想法，也完全掌握不到对方接收一些信息会有怎样的反应。面对这样的场景，犹记得跟直属领导的一番谈话：

领导：与人斗，其乐无穷~

我：是吗？那我为什么感受不到快乐呢？

领导：因为你总是输啊，当然不快乐了。

我：哦……

刚开始接触软件开发这部分工作我是没有信心的。一方面受到上文所述与各接口人负责的困扰，一方面是自己对软件开发技术方面掌握较少，因此单独针对这个问题与部门领导进行了沟通。领导通过一段话打消了我的疑虑，也让我受用至今：“工作就是要这样做，什么都准备好了，那就不一定是属于你了”。

研究生导师也曾经说过：“要做，就要做好，要出彩”。既然必须顶着头皮硬上，那就只能尽力做到最好。关于培养职业自信这个问题，我确实花费了不少心思。总结经验主要包含三方面。

一是正向的心理暗示。不断告诉自己是负责人，打造个人职业标签，要坦然面对各种各样人提出的各种问题不慌乱，保持思考，要稳住，这是职责范围内的工作，必须要面对，不能退缩。

二是提升质量要求。不管是开会、发邮件还是日常沟通，确保自己传递的任何信息无误差，并且一定要能够完全自洽，每个单一的信息点，都找到其根因（背景土壤），并从全局视角找到相关联的其他信息，共同思考、梳理决策，这样就能保证信息至少不会是错误，顶多是不够完善。但，不够完善，至少是能够被解释的，也是环境能被接受的。

三是不断自我复盘。每经历一场会议，一次讨论，或完成一个文档，在交付后都会进行总结和复盘，其本质还是遵从过程改进的方法论。好的，留下，固化；不好的，改进，纠偏。（所以那段时间经常做梦都在工作。。）

经过坚持实践，慢慢的，自己确实拥有了职业自信，可以平静又淡定地处理各种突发问题。再后来，由于信息准确、可靠，承诺也能兑现，客户、用户、相关方也在逐步信任，不断把更多重要的需求直接给到我。我也无形中承担了更多超出当前岗位的工作。

第二个障碍是软件开发项目管理。由于对技术不了解，且每个组织都有分包商负责人，在组织会议、制定计划、成果检查等各方面都遭受到了很大的阻碍。犹记得第一次组织项目工作例会，当天领导有事没来，委托了负责人参会，由于之前第一次是领导主持会议，在我暗示负责人要开始的时候，他直接轻飘飘来了一句：你开始吧。我：。。。。。。

这大概是最让人难忘头秃的会议了，虽然我有充足的准备（会议议题、内容都是我准备的），但仍然讲几句就会被打断，根本谈不上任何主持，转变为辅助性的会议记录。虽然如此，但后续的会议都是我主持，不断整理、总结、反馈，每一步踏踏实实的去做。从记录大家的内容，到参与讨论，到控场主持，整整花了两个月的时间。那段时间，每次会议前的晚上，一定会失眠，每次都要不断去回顾，还有哪些点没有掌握，哪些信息没有理清。

现在回顾一下，其实管控软件开发部分主要有以下突破口。

第一是找准组织定位。从全局出发，作为总集成项目管理视角，虽然各分包商项目经理负责，但从组织层级来看，我们是距离客户方最近的，更能快速接受到客户信息，并且形成任务反馈给分包方。因此，在任何有关于分包方的任务，我主动承担了这样的角色，按照客户需求，结合项目侧重点，主动收集并反馈任务进展，成功将这两方连接在一起，建立沟通渠道。

第二是找到自身价值。虽然对技术了解不到位，但分包方对业务的了解也并不是很深入，这就找到了一个可以支撑和赋能的突破口。通过对初步设计的解读和与用户之间的深入沟通，对于把握需求调研方面积累了很多经验。每次沟通会议后，都协同分包商完成调研记录，并按记录要点跟进实现情况，逐步了解整个软件开发工作。

第三是验工计价管理。由于是背对背合同，即每次完成客户的验收后，才开始展开对分包商的评价工作。基于对客户方的工作经验，加之对项目工作量的逐步分解，经过试运行、探索及改进，终于建立起了一套分包商验工计价管理体系，并且能够与公司采购部门有效衔接，完成验收、付款工作。这项工作也能保障整个项目交付按期有序推进，为沟通和赋能都有很好的助力。

通过这三方面的操作，找到自己的定位，找到组织的定位，成为两方的连接，并且为两方助力，提供价值。最终成为一个合格的大白，承担起相应的工作。