人人都是管理者
Posted bit_kaki
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了人人都是管理者相关的知识,希望对你有一定的参考价值。
以前我写过一篇文章,名字叫《毕业三到五年,别让“努力”毁了你》,
文中我将工作前三到五年,我们应该达到的目标概括为:
- 确认自己职业生规划,对至少接下来五年的职业发展有很明确的规划;
- 知识和技能上有一定的积累,在工作中可以独当一面;
- 形成一套自己的方法论,遇到问题时候有一套自己解决问题的方法;
- 某个领域上有较强的能力或者知识储备,并逐渐发展成改领域的专家,培养自己的“不可替代性”;
- 有一定的管理能力,能带领小团队完成任务
这个目标总体来说我觉得还是比较明确且接地气的,
尤其是前四点,都是针对自我规划和技术业务积累上,应该没任何问题。
但对于第五点的管理能力上,之前我认为管理这事只属于公司管理层或者团队leader,
直到最近看了《人人都是产品经理》的纪念版,纪念版比起之前的版本多了很多延伸阅读,
大概就是作者几年后再看自己之前写的文章,给予了一些批注和新的理解。
其中对于“一线员工眼中的管理”这部分,作者更新了他的观点,
他认为,所谓管理的能力,其实就是“在资源不足的情况下把事情做成”的能力。
管理大师彼得·德鲁克曾在《有效的主管》一书中简明扼要地指出:
“效率是‘以正确的方式做事’,而效能则是“做正确的事”。
效率和效能不应偏废,但这并不意味着效率和效能具有同样的重要性。
我们当然希望同时提高效率和效能,但在效率与效能无法兼得时,
我们首先应着眼于效能,然后再设法提高效率。”
我们每个人都掌握着不同的资源,所以需要管理的对象也不同。
当资源充分的时候,我们会觉得“以正确的方式做事”更重要,
比如我们被分配了某个重要任务时候,我们的目标就是做好这件事。
但是一旦资源出现了瓶颈,“做正确的事”就显得更加重要了。
比如同时有三个人请你吃明天的晚饭,这时候的资源,即你明晚的时间不够了,
你就需要判断和谁吃饭更有价值,谁的请客可以推后。
这就需要自己对自己的时间进行管理了。
在日常产品经理工作中,资源不足通常以以下形式表现:
1.信息不足已决策。时间有限,能力有限,每次决策前不可能掌握所有信息,做决定时总是头疼;
2.时间不足以安排周密的计划。总是接到3个月、1个月,甚至1个礼拜完成某项的命令,应承下来后如何计划;
3.人员不足以支持工作强度和难度。不但时间不足,可能人员也不足,能力还不够,士气又不高;
4.资金不足以自由调配。设备要钱,人员要钱,产品推广要钱,而花这些钱的前提是公司还得赚钱......
而把这几点推广到生活中的各方面,凡是资源,总归不足。
既然不足,就需要学会分配资源、管理资源。比如自己的时间、衣橱、工资、手机内存......
所以,我们人人都该是管理者。
我们人人都是管理者,作为一个基层管理人员,
我们的管理对象可能只有自己的资源和自己的工作任务,
当资源不足时候,此时我们应该怎么做呢?
1.简化解决方案,关注核心和关键问题
当我们资源不足时候,最忌讳的是通过降低质量来解决问题。
举生活中的例子,比如我们1天内要游玩北京五个景点,
从时间的资源上来说,要达到这个目标肯定不够。
此时如果我们考虑走马观花似的游玩这几个地方,或许时间上刚好够,
但是这样势必也会让我们觉得这趟旅行没意义。
对于项目上来说,在时间、人力等不够时候要完成整个项目,
如果通过降低质量的方式来完成,势必留下很多隐患。
对于软件平台而言,架构设计不合理、代码混淆等问题势必需要未来用更多的资源进行重构。
所以降低质量来完成项目,其实就是给未来的自己挖坑。
此时更好的方案就是重新梳理一下问题,找到核心业务目标。
比如把项目的方案建议书和需求规格说明书重新审视一遍,
结合用户需求思考和权衡,哪一些功能是目前比较关注的,而哪一些功能是未来系统需要关注的。
有必要的时候甚至可以在它们基础之上,整理出项目这一阶段的需求规格说明书来,
保证核心业务功能能顺利完成。
2.对核心问题和关键任务进行优先等级排序
关于个人工作效率的经典之作《高效能人士的七个习惯》那本书里依据纵坐标(重要性)和横坐标(紧急性)来划分任务,有如下四种组合:
1、重要且紧急,迅猛龙式的出击;
2、重要但不紧急, 准备好未来的方案、策略和计划;
3、不重要但紧急,学会说不,拒绝任何承诺;
4、不重要也不紧急,可以研究下隔壁的妹纸为何每次遇见你都会笑的很好看;
整理完核心问题和关键任务的优先级列表后,你会发现项目一半的范围进行了裁剪。
这是一个好的趋势和结果。因为管理,缩减和明确范围,永远对问题的如期解决是有利的。
比如对一个项目的实施,10个人有10个人的计划和结果,2个人也有2个人的计划和结果。
当你无法争取标配的资源获得对这个项目的足够支持时,关注核心功能、在核心功能范围内进行任务优先排序。
之后,通常困难都是一时的,规划良好的迭代实施计划,讲缩减至一半的项目范围,持续地补充完善起来。
通过持续渐进、裁剪和分解的方式最终实现项目的成功。
3.制定持续可行的迭代计划
迭代这个单词很泛滥,所谓迭代其实就是某个目标比较大,难以一次实现,
比如钢琴十级,需要我们不断重复练习钢琴,一步步提升自己钢琴水平,
而每考取一个钢琴等级,类似于就是对于我们钢琴水平迭代一次,
通过一次次迭代,一步步完成我们的目标。
对于迭代来说,但很多人都不明白需要迭代什么。
首先要明确,在那些核心的和关键的问题清单中,有哪些是需要放在持续的迭代计划当中的,不是所有的问题都需要迭代。
比如项目成熟的功能基本都是一次开发就落地实现,如果迭代设计登陆和退出功能都要迭代就显得非常逗。
通常需要迭代的任务都是那些比较复杂的,业界技术不是很明确或者用户未来期望也不是很明确的功能,比如权限体系、报表体系等等。
而在每个迭代计划上,最好是给自己制定一个个里程碑节点,
然后每个里程碑节点需要完成什么目标,怎样去匹配资源、怎么去安排动作,
注意别让自己的里程碑节点偏离自己的原定目标。
最后就如“人人都是产品经理”这句话一般,我觉得“人人都是管理者”。
管理好自己时间,管理好自己资源,管理好自己职责。
如同连自己都管理不好,怎么可能管理好一个团队。
以上是关于人人都是管理者的主要内容,如果未能解决你的问题,请参考以下文章
后台设计的基石:用户权限管理(RBAC)及工作流(workflow)模型(转自人人都是产品经理)