人人都是管理者

以前我写过一篇文章，名字叫《毕业三到五年，别让“努力”毁了你》，

文中我将工作前三到五年，我们应该达到的目标概括为：

 

• 确认自己职业生规划，对至少接下来五年的职业发展有很明确的规划；
• 知识和技能上有一定的积累，在工作中可以独当一面；
• 形成一套自己的方法论，遇到问题时候有一套自己解决问题的方法；
• 某个领域上有较强的能力或者知识储备，并逐渐发展成改领域的专家，培养自己的“不可替代性”；
• 有一定的管理能力，能带领小团队完成任务

 

这个目标总体来说我觉得还是比较明确且接地气的，

尤其是前四点，都是针对自我规划和技术业务积累上，应该没任何问题。

但对于第五点的管理能力上，之前我认为管理这事只属于公司管理层或者团队leader，

直到最近看了《人人都是产品经理》的纪念版，纪念版比起之前的版本多了很多延伸阅读，

大概就是作者几年后再看自己之前写的文章，给予了一些批注和新的理解。

其中对于“一线员工眼中的管理”这部分，作者更新了他的观点，

他认为，所谓管理的能力，其实就是“在资源不足的情况下把事情做成”的能力。

 

---

 

管理大师彼得·德鲁克曾在《有效的主管》一书中简明扼要地指出：

“效率是‘以正确的方式做事’，而效能则是“做正确的事”。

效率和效能不应偏废，但这并不意味着效率和效能具有同样的重要性。

我们当然希望同时提高效率和效能，但在效率与效能无法兼得时，

我们首先应着眼于效能，然后再设法提高效率。”

 

我们每个人都掌握着不同的资源，所以需要管理的对象也不同。

当资源充分的时候，我们会觉得“以正确的方式做事”更重要，

比如我们被分配了某个重要任务时候，我们的目标就是做好这件事。

但是一旦资源出现了瓶颈，“做正确的事”就显得更加重要了。

比如同时有三个人请你吃明天的晚饭，这时候的资源，即你明晚的时间不够了，

你就需要判断和谁吃饭更有价值，谁的请客可以推后。

这就需要自己对自己的时间进行管理了。

 

在日常产品经理工作中，资源不足通常以以下形式表现：

1.信息不足已决策。时间有限，能力有限，每次决策前不可能掌握所有信息，做决定时总是头疼；

2.时间不足以安排周密的计划。总是接到3个月、1个月，甚至1个礼拜完成某项的命令，应承下来后如何计划；

3.人员不足以支持工作强度和难度。不但时间不足，可能人员也不足，能力还不够，士气又不高；

4.资金不足以自由调配。设备要钱，人员要钱，产品推广要钱，而花这些钱的前提是公司还得赚钱......

而把这几点推广到生活中的各方面，凡是资源，总归不足。

既然不足，就需要学会分配资源、管理资源。比如自己的时间、衣橱、工资、手机内存......

所以，我们人人都该是管理者。

 

---

我们人人都是管理者，作为一个基层管理人员，

我们的管理对象可能只有自己的资源和自己的工作任务，

当资源不足时候，此时我们应该怎么做呢？

 

1.简化解决方案，关注核心和关键问题

当我们资源不足时候，最忌讳的是通过降低质量来解决问题。

举生活中的例子，比如我们1天内要游玩北京五个景点，

从时间的资源上来说，要达到这个目标肯定不够。

此时如果我们考虑走马观花似的游玩这几个地方，或许时间上刚好够，

但是这样势必也会让我们觉得这趟旅行没意义。

对于项目上来说，在时间、人力等不够时候要完成整个项目，

如果通过降低质量的方式来完成，势必留下很多隐患。

对于软件平台而言，架构设计不合理、代码混淆等问题势必需要未来用更多的资源进行重构。

所以降低质量来完成项目，其实就是给未来的自己挖坑。

 

此时更好的方案就是重新梳理一下问题，找到核心业务目标。

比如把项目的方案建议书和需求规格说明书重新审视一遍，

结合用户需求思考和权衡，哪一些功能是目前比较关注的，而哪一些功能是未来系统需要关注的。

有必要的时候甚至可以在它们基础之上，整理出项目这一阶段的需求规格说明书来，

保证核心业务功能能顺利完成。

 

2.对核心问题和关键任务进行优先等级排序

关于个人工作效率的经典之作《高效能人士的七个习惯》那本书里依据纵坐标（重要性）和横坐标（紧急性）来划分任务，有如下四种组合：

1、重要且紧急，迅猛龙式的出击；

2、重要但不紧急, 准备好未来的方案、策略和计划；

3、不重要但紧急，学会说不，拒绝任何承诺；

4、不重要也不紧急，可以研究下隔壁的妹纸为何每次遇见你都会笑的很好看；

 

整理完核心问题和关键任务的优先级列表后，你会发现项目一半的范围进行了裁剪。

这是一个好的趋势和结果。因为管理，缩减和明确范围，永远对问题的如期解决是有利的。

比如对一个项目的实施，10个人有10个人的计划和结果，2个人也有2个人的计划和结果。

当你无法争取标配的资源获得对这个项目的足够支持时，关注核心功能、在核心功能范围内进行任务优先排序。

之后，通常困难都是一时的，规划良好的迭代实施计划，讲缩减至一半的项目范围，持续地补充完善起来。

通过持续渐进、裁剪和分解的方式最终实现项目的成功。

 

3.制定持续可行的迭代计划

迭代这个单词很泛滥，所谓迭代其实就是某个目标比较大，难以一次实现，

比如钢琴十级，需要我们不断重复练习钢琴，一步步提升自己钢琴水平，

而每考取一个钢琴等级，类似于就是对于我们钢琴水平迭代一次，

通过一次次迭代，一步步完成我们的目标。

 

对于迭代来说，但很多人都不明白需要迭代什么。

首先要明确，在那些核心的和关键的问题清单中，有哪些是需要放在持续的迭代计划当中的，不是所有的问题都需要迭代。

比如项目成熟的功能基本都是一次开发就落地实现，如果迭代设计登陆和退出功能都要迭代就显得非常逗。

通常需要迭代的任务都是那些比较复杂的，业界技术不是很明确或者用户未来期望也不是很明确的功能，比如权限体系、报表体系等等。

 

而在每个迭代计划上，最好是给自己制定一个个里程碑节点，

然后每个里程碑节点需要完成什么目标，怎样去匹配资源、怎么去安排动作，

注意别让自己的里程碑节点偏离自己的原定目标。

 

---

最后就如“人人都是产品经理”这句话一般，我觉得“人人都是管理者”。

管理好自己时间，管理好自己资源，管理好自己职责。

如同连自己都管理不好，怎么可能管理好一个团队。