如何正确的交付项目

前言

在一家科技公司，我们所谓的交付项目和编写代码是两方面的事情，公司里可能有很多技术大牛，他们擅长编写代码攻坚技术难题，但是最终交付的项目却总是不尽如人意。

因此，这篇文章我主要讨论的就是项目交付中的那些事。

交付本就不易

首先我们要脱离一个观念，那就是认为项目交付很容易。

项目交付本就困难重重

项目总是会遇到各种各样的意外情况，而这些情况可能导致无限延期、取消、半途而废，然后项目就终止。

项目并不是写完所有的代码或者关闭了所有的工作任务它就会自动交付。一个项目的交付，必然是有人承担了这些艰难以及微妙的交付工作。

交付是第一性原则

项目的核心是为了交付，我们花再多的时间放在完善用户体验或 UI 设计上，项目最终只会是无法按期交付。对于一名开发人员或者设计人员来讲，专注于项目的技术细节，设计的美观程度等，这些都是很好的行为。但是作为一名项目经理，这是完全错误的，并且会让项目越来越失控。虽然项目经理可以表扬或者鼓励团队成员的投入，这确实是一个好事情，但是一个项目的首要任务就是交付。

项目能顺利交付的原因，完全是因为一个人的功劳

这一个关键人物并非是写完所有的代码或者做完所有的工作，也并非意味着项目无需其他人就能交付。

项目必须有一个人对整个项目有全面的了解

所谓的了解有且不限于项目在技术上是如何整合的，项目服务的用户是谁，项目的建设背景是什么，项目是为了解决什么业务痛点，项目能够带来什么样的收益以及价值。

一个优秀的交付团队会确保每个项目有一名合格的负责人（可能是“技术主管”、“项目经理”、“产品经理”或“DRI(直接责任个体)”）。

一个失败的交付团队，他们会将项目的成功与否寄希望于有一个人能够主动承担这个角色。

而这通常代表着项目已经很难完美的交付了，而且项目的过程会很辛苦。

什么才是交付

很多时候，团队的成员都不明白怎样才算做交付。交付并不意味着部署好了服务器，上线了某个版本，更新了某个功能，提供了某些文档。

当项目的发起人及重要干系人认为项目已经交付时，项目才真正的交付

项目的发起人可能是指公司经理、公司老总、公司CEO、客户老总等，这需要根据项目干系人参与矩阵具体决定。而如果项目的发起人或者重要干系人对项目不满意，那么项目也并没有交付。团队可能交付了某些模块某些功能，但是没有交付最终的项目。只有当公司领导层或客户领导层承认你的团队交付时，这才是真正的完成交付。客户微信消息里面的大拇指肯定，签字之后的上线确认通知单、验收单是交付真正需要的证明。

如果上线的产品受到广大用户的喜爱，并且实现的收益，这也算是一种交付。这种交付因为用户的认可以及实现的盈利让领导满意。但如果上线的产品用户并不认可，而且也没赚到钱，但是领导很满意很认可，这仍然算是交付。

如果仅仅开发完某些功能或者交付某些文档就算交付，那么这类项目团队最终只会失败。

沟通至关重要

上文已经提到，交付主要是让项目发起人以及重要干系人满意，对于管理者而言就需要知道这个项目的建设目的。例如有些时候项目的功能是为了吸引特定的用户群体。有些时候公司需要投入研发一些免费功以此来扩大用户数。有些时候公司需要通过专门为某个大客户定制的项目来构建联系。有些时候这项目只是一位高层领导的核心诉求。交付团队需要与不同发起人的建设目的保持一致。

不同的项目交付意味着有不同的交付情况，管理者需要相应的调整工作和沟通方式。

例如企业级的项目通常不需要非常美观的系统操作界面，但需要功能完整。高层领导的核心项目意味着需要与项目的推动着保持积极的沟通。沟通的方式也要根据高层领导的偏好来选择决定。

不管什么项目，与管理者相比，发起人或者客户领导对于项目的技术背景肯定是不足的。这也意味着他们会信任管理者提供工作估算、回答技术问题并预测项目结果。

管理者应当重视信任的维护

如果他们不信任你有能力完成工作并且通知他们，项目肯定做不下去。他们甚至会考虑暂停或取消项目来降低风险和投入。亦或者，他们会更换人员，由他正式或者非正式的成为实际交付项目的人。

那么如何保持与领导和客户的信任？这里列举一些方式，后面可以再进行一篇文章的总结：

• • 保证所有工作有迹可循，事事有记录
• • 对项目的自信
• • 项目管理的能力
• • 专业而简洁的沟通，不要等对方追着你问进度，做好项目日报或者周报

这些事情甚至比项目按时交付更重要。有时，如果因为技术原因（如第三方对接、高复杂度技术难点）等原因而项目延期，只要管理者清晰、自信的主动进行沟通，最好提前预警，那么一般不会承担恶劣的后果。坦白来讲，如果真的因为某些问题导致项目进度受阻或者延期，对于管理者也许会有利，因为“挽大厦之将倾”的勇敢管理者总比“小心翼翼”的谨慎管理者得到的掌声更多。

投入交付工作

在具体交付工作中，常常会遇到各种细节问题。例如：

• • 需求细节：某些需求不明确、业务逻辑不清晰等
• • 技术细节：文件大小分割、缓存数据、数据脱敏、第三方 api 对接等
• • 其他细节：部署方式、备份管理、安全处理机制、法律风险等

这些问题有些是项目共性，有些则是项目特有的问题，而且管理者很难提前预测以及规划。处理这些问题需要对系统有深入的技术理解，并且具备快速适应的调整能力。

解决问题的方案有很多，包括各类技术选型或者开源方案等等。但是除非是非常了解，不然管理者很难知道哪些解决方案可行，哪些解决方案是性价比高的，既投入小又不会导致延期。

甚至在项目启动时，提前项目评估和团队讨论的问题都不一定真实存在。资深的开发人员因为经验经常会提出一些潜在的、前瞻性的问题（例如信创环境这个技术能否使用？这个中间件是不是增加了交付难度？）。

如果没有人切实的考虑和解决问题，项目一定会受到影响（延期），这就是管理者的责任，管理者错估或者忽略了团队成员提出的问题。

如果管理者不牵头组织解决问题，作为团队成员肯定选择对于他而言最谨慎保守的做法（比如差不多得了）。

管理者通常不会全身心的投入项目的实际工作，但项目的早期至少应该有 20%的时间投入与跟进，在冲刺阶段达到 90%-100%，这样在项目生命周期里的中后期（问题集中暴露的阶段）能够全身心的投入项目并与团队成员一起解决问题。

什么时候可以交付项目

Feature Flag（特性功能开关） 是一个很好的设计， 它能允许控制线上功能的开启和关闭，可以将它运用于预发布环境。有一个很好的方式是将现在正在进行中的一切尽可能多的展示给所有相关人员：管理者、工程师、领导层、产品团队、设计团队等等。不用担心功能粗糙，花几分钟时间上手实际操作一下也能发现一些意想不到的问题。让他们实际看到这些内容，也能让项目发起人和重要干系人确信项目还在你的掌控之中。

发现问题的最好方式就是尽可能早的部署。

尝尝问自己一个问题：我现在项目能交付吗？

不是本月本周，也不是今天，而是现在（Now）。如果答案是不能，我们就需要思考，我们还需要做哪些修改才能交付？当前这一个迭代完成之后是否可以上线部署？如果我们在等待其他团队工作，是否可以降低要求？例如缓存的热点数据目前先不做缓存，但是功能还是正常可以运行（尽管对性能以及资源利用差一点）。

管理者的首要任务是维护领导团队以及客户团队的信任。建立应急计划以及应急储备以应对紧急情况，这是管理者对于项目的完整把控。如果真有意外发生，导致你当天无法交付，如果作为管理者能够进行有效沟通“我们需要延期一周，或者让第三方供应商加快与我的团队对接”，那么他们肯定更乐意去找第三方供应商——尽管这不一定有用。但是这意味着他们对项目延迟会认为是你有效处理之后不可避免的问题，而不是你的失误或能力不足，降低他们的信任度。

工程师经常想要推迟上线的本质是因为害怕

如果想要项目交付，相反，我们应该尽早的上线更多的内容，并且尽早的完成最有风险的变更。身为管理者，就应该拥有对项目最完整的端到端的认知，管理者最不应该害怕高风险的变更。而其他人往往面临很多未知的因素，因此他们是不可能愿意走出突破性的那一步的。

ps：如果有其他人了解整个项目全貌而你在指望他，那么他才是真正推动项目落地交付的关键人物，这对你来说的话……

总结

• • 交付难是一定的，但是交付一定是项目的第一性原则
• • 交付并不是要交付所有的功能，而是让重要干系人(领导/客户)满意
• • 交付需要重要干系人的信任
• • 时刻问自己：我现在可以交付吗?
• • 积极沟通
• • 勇敢且自信