人人都是管理者

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/bit_kaki/article/details/82963440

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

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

 

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

 

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

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

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

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

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

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

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

 


 

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 


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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

1、重要且紧急,迅猛龙式的出击;

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 


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

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

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

 

 

 

 

 

没有更多推荐了,返回首页