团队认知管理，项目成功的关键

目标管理的核心不在于目标的定义，而在于团队认知的一致

---

我们知道，在项目管理里面，目标是第一要素，在目标的定义上，我们通常要遵循SMART原则：

S=Specific          -------具体的

M=Measurable   --------可衡量的

A=Attainable       --------可实现的

R=Relevant        -------- 有相关性的

T=Time-bound    ---------有时间限制

为什么需要按照SMART原则来定义目标了， 因为这样的目标，才好理解和认知，然后才能产生好的执行力； 据统计，90%以上的执行力不行，其实都在于目标的定义问题上；

在这里，我要说的是，目标定义清晰，明确，只是手段，让团队成员理解到位，认知一致，才是关键点所在。

记得傅盛在他的一篇针对创业者的文章中说到的，CEO的核心任务，就是把创业目标从一个开放式的问题，变成一个闭环问题，而这里所谓的闭环问题，其实就是一个简单可行的目标；

我深以为这确确实实是真相，是很多创业CEO们知道却不肯承认的真相。

所以，我想说，在你做项目目标管理时，除开定义好目标外，把重心放在团队对目标的一致认知上，才是做好目标管理的核心要义。

其实反过来，当你的关注点落在结果的“目标认知一致”这个点上时，它一定会倒逼着你把目标定义得清晰、具体和可执行；

说完项目目标的认知管理，我们再看来看软件的需求管理；

 

需求管理的本质，仍然是需求认知的一致性管理

---

一个软件项目里面，最重要的就是需求管理，一个失败的软件项目里面，需求永远是脱离不了干系的；

需求管理，其实就两点：

1. 确定需求范围；-----------这一点在外包项目中尤为重要；

2. 管理需求变更；-----------这一点常常发生，经常带来致命的影响；

说起来就两点，可做起来真的很难，几乎所有发生需求扯皮的地方，不是在需求范围上，大家意见不一致，就是在需求是否属于变更上，双方存在歧义；

所以，你看，所谓的需求管理，其实还是一个需求范围和变更的一致性认知问题 ，把认知统一了，自然就不扯皮了；

我们再回顾一下软件开发项目的变化历程：

以前传统的软件项目开发里面，我们会出具详细的需求规格说明书，可是需求规格说明书，只有比较专业的人员能看懂，你想让客户也理解你梳理的规格说明书，然后脑补出相应的产品界面，那除非他就是产品经理；

今天，需求规格说明书，逐步演变成了PRD文档，更注重从用户的角度来描述需求；

以前，基于UML，我们会有各种用例图、类图、业务流程图等；

今天，我们还是会绘制各种业务流程图、交互逻辑、功能框架等，但更多的，我们增加了原型的输出；

特别是原型的输出，把原来大家基于文字的揣摩理解，表象化为对图形界面的理解，这一下大大的提升了各方对需求认知的一致性水平；

所以，你会看到，软件项目中中间输出物的变化过程，本质上就是一个不断提升需求认知一致性的过程；

 

说这么多其实看似很浅显的道理，其实还是想让各位项目管理者明白： 项目管理过程，关注到结果才最重要，而着眼于认知一致性的管理，就是一种有效的结果管理的方法；

否则，我们往往能看到这么一种情况：过程好像都是对的，该有的流程和环节都有了，可结果就是错的

作者：贝克曼
链接：https://www.jianshu.com/p/93b983beded4
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。