实证(10.22)

最近在自己头脑里面一直在思考证悟这个词，或者叫实证，即凡所有事，必须经过你亲自实践或验证，往往你才能够最终确定是否满足你的期望，是否能够满足他人期望。

我们举个简单的例子，你如果是产品经理，你的老板问你研发的产品下个月末能否正常上线，你可能跟你老板拍胸脯说没有问题。但是你如何下的这个结论？你可能是问的你的项目经理，项目经理告诉你没问题，而项目经理又问的开发经理，开发经理问的下面的程序员。

这一连串的信息传递，哪怕每个人的概率都高达90%，那么最终到你的把握可能不足五成。即你作为产品经理，你给领导的承诺，给客户的承诺，最终全部寄托在你下游各个节点的承诺可靠性上面。

各种项目计划和WBS，项目进度跟踪，风险，沟通汇报，QA检查，各种标准规范流程和组织架构，看起来都是如此完美，但是最终项目并没按预定目标完成或交付。并不是说流程不重要，但是对于软件项目一定不能忽视人，人可能有足够的经验和主观能动性，但是最不确定的因素往往也就在于人。

不管是谈敏捷，谈扁平化管理，最终希望的还是减少人和人间信息传递带来的信息衰减和失真。特别是对于技术管理，比如产品经理往往就是最好的需求，测试人员和用户，他本身应该对产品最熟悉。对于项目经理同样的道理，IT项目经理没有存粹的管理，必须是技术型项目经理，有丰富的项目技术背景和经验。

如果你明天要去给关键客户领导汇报，你让你的助理给你准备了一个PPT材料，你会不提前看一遍和演练吗？相信很多人都不会，而是提前先熟悉材料确保没有问题。对于项目交付往往也是同样道理，对于一个业务系统的交付是否能够按进度完成，核心功能是否OK？作为项目经理一定不能是听你的开发经理说，听的测试说就完成，而是需要自己去实证，只有自己实证后你才能够最放心。只有在项目周期中迭代式的进行验证和检查，往往你才可能提早的发现问题和风险。

技术背景的人做项目经理最大的好处往往就是能够亲自去实证是否有问题，而不是听别人说。

你对客户的承诺，对上级领导的承诺，一定要掌握到你手里面，而不是最终无法按完成的时候来追求你团队里面成员的责任，也去推卸自己的责任。类似我们前面谈过的，一个项目交付，项目经理始终是第一责任人。

你越重视承诺，那么你就越应该明白，真正只有自己才是唯一能够100%相信和依托的，托付他人都有风险，只是风险概率不同而已。自己的命运要掌握在自己手中，往往就是这个道理。

那实际应该是如何？

就拿领导交付给你一个技术方案的制作来说，你将工作安排给你的开发经理来完成。领导如果要求是一周来完成。如果你自己来做，高效加班预估1天能够完成。那么你交付给他人做只能是4天，因为你手里面有PlanB，不行还可以自己上。

那么如果你自己做至少要3天的时间如何办？

这个时候你交付给他人做的时候就必须迭代，即让你的开发经理必须要在2天交付一个初稿，在你Review后再继续修改和调整。由于增加了检查点，我们仍然能够将概率掌握在自己手里面。即2天交付东西完全不可用，那么就自己上。如果2天交付内容问题不大，再给出重点后可以继续交付给开发经理来完成。

永远都要给你承诺的事预留缓冲，越是重要的事，缓冲时间应该越久。

永远都要考虑到一件重要事情的完成应该有PlanB

你再信任的人也可能粗心和犯错，包括你自己也可能犯错，亲身实证才是最重要的而不是依赖他人承诺

虽然我们平时也经常谈方法论，谈框架和模式，但是自认为所有内容均是通过自己实践总结出来的，而不是将他人的理论包装和加工。这篇文章也给所有空谈理论不实践，空谈管理无技术的IT人。正如我经常说的，长久信任关系的建立一定是基于踏实做，不忽悠上的。