分配工作时需要考虑的问题

文章试图总结作为一个技术管理者给下属进行工作分配时,需要从哪些方面考虑,以及需要注意的问题。实际上,也可以作为一个下属如何完成上级分配工作的一个指引。就像文章里说到的,我们在分配给别人任务的时候,别人也在分配任务给我们。我们在别人身上寻找某种特质的时候,别人也在我们身上寻找类似的东西。

一般情况下,管理者都会将工作安排给自己信任的人,因为对他的工作能力和工作态度都比较熟悉,能预估到他的工作情况,不会出现太大的意外,有更大的掌控,所以才偏向于自己熟悉的人。

那面对还没有建立起信任关系的人,应该如何分配工作呢?

首先,建立参考基线

通过第三方或者他之前的履历来衡量他的能力,这是做出这个人是否能胜任这个任务的起步基线。这一步,可能会包含太多的主观性,是要存疑的,要通过后面的步骤来确定。

根据对方的反馈确定他是否有综合考虑问题的能力,是否对任务有全面了解

在沟通任务的时候,首先要确保已经准确清晰的给他描述了任务内容。这时候要看他会提出什么样的问题,提出什么样的想法。有时候,『问对问题比正确答案更重要』。

还有一些细节,比如在问问题之前是否去有做过调研,在你给出建议或反馈后,他的反馈时什么,会不会又提出新的问题,这将提现他的工作态度。

工作量评估

能对任务有准确的工作量评估也是自身能力的一种提现,超前或滞后的评估其实都是对任务本身或者自身能力没有准确认知导致的。要懂得『近似的准确要好过确定的错误』,有相对准确的工作量评估,有时候甚至会影响整个项目的决策。

看他能否给出具体开发工作量有多大,需要依赖别人的工作有多少,有多少沟通成本,可能会碰到哪些技术难点,有没有现成的方案,系统框架用什么,后期的集成和测试的时间成本有多少,需要自己的上级提供哪些帮助,综合以后,再给出一个全面的时间评估。

很多时候,管理者希望能短平快地完成任务,在主观上就会倾向于那种给出更短时间的人,但实际上有可能是他在没有足够了解未知部分的情况下给出的乐观评估。所以,看工作量评估要有理有据,而且要全面。

执行力

有了时间评估,也就有了工作计划,接下来就需要依靠执行力来完成了。执行过程中,遇难就退,虎头蛇尾,都是不行的。这一部分考验的是『成事』的能力。

将整个任务细分,建立几个关键的里程碑任务,在不同的时间阶段去攻克对应的里程碑任务,出现延期时,还有可以调整的空间。

后期维护

完成一个项目,并不意味着项目结束,上线以后还有很多维护的工作。包括日志跟踪,bug排查,用户反馈问题跟踪,后续的迭代等等,这时候要去观察他是否主动去做这些工作,这是是否有责任感的体现。

总结复盘

项目结束或者趋于稳定以后,要看他是否会主动总结之前的项目经验,总结哪些地方做的好,哪些地方做的有欠缺,从中得到了什么经验教训,以后应该怎样去规避。能从中得到提升的人才能不断进步,总是犯重复错误的人,也很难承担重要的任务。

一个项目下来,就像将军带着士兵打了一场仗,哪些人成长很快,哪些人比较稳重,哪些人比较激进,哪些人主动性高,哪些人需要定期去督促,这些组成一个团队的合作方式。对于成长较快的人,就要不断给他更高的目标;对于慢工出细活的人,就适合分配一些比较重要核心的产品,这样不容易出错,对于一些动作比较快,虽然容易出问题,但能通过快速迭代去完善,就适合做一些新的产品。

要能够承担上级分配的任务,要有两方面的能力。一方面是自身的能力,这包括业务能力,技术能力,全局观,沟通、规划等能力,另一方面也要有自己的态度,有担当,全力以赴,让自己在别人眼里是一个能托付重任的人。

原文地址:https://www.cnblogs.com/u5f71/p/fen-pei-gong-zuo-shi-xu-yao-kao-lu-de-wen-ti.html

时间: 2024-10-12 16:42:44

分配工作时需要考虑的问题的相关文章

编写高质量代码改善C#程序的157个建议——建议10: 创建对象时需要考虑是否实现比较器

建议10: 创建对象时需要考虑是否实现比较器 有对象的地方就会存在比较,在.NET的世界中也一样.举个最简单的例子,在UI中,有一个10个人的Salary列表.根据排序的需要,列表要支持针对基本工资来罗列Salary.这个时候,接口IComparable就会起作用,代码如下所示: class Salary : IComparable { public string Name { get; set; } public int BaseSalary { get; set; } public int

3星|《工作生活双全法则》:我们很容易掉入注重工作时长而非成果的陷阱

工作生活双全法则(<哈佛商业评论>增刊) 工作生活双全法则(<哈佛商业评论>增刊) <哈佛商业评论>讲兼顾工作与生活的3篇文章.总体来说,这在全世界都是个难题.作者的调查和统计结果表明,有些时候工作的压力来自于公司对工作时长的关注超过了对工作成果的关注. 以下是书中一些内容的摘抄: 1:上述两位作者基于对全球4000名高管的访谈,发现成功的高管往往能巧妙地将工作和家庭融合在一起,这样他们就在取得职业成就的同时,保持了与家庭成员的和谐关系.#16 2:最后一点是高管的普遍

记录在Sungard工作时对ejb3.1的研究(2)--ejb3 集群(ejb timer/MDB)

以前和人家谈论sungard的工作时,总是被质疑:"你们还在使用ejb啊?太老了吧". "早就是spring的年代了". 我总是反击,你们真的了解ejb吗?了解ejb在分布式应用里集群部署和spring比较有多方便吗?不要总是把什么IOC, AOP肤浅的挂在嘴上, 现在早已不是ejb2的时代了. ejb3 dependency injection也很容易,除了在非javaee容器管理的资源里受限(需要借助javaee6 CDI). AOP?ejb也有intercep

浅谈人们工作时存在的2种思维模式

工作的思维模式分2种:即时回报型和延时回报型. 即时回报型的表现:注重立刻见效的方式,比如刀钝了舍不得花时间磨,提刀急忙去砍柴:比如每天都大老远的去提水,而舍不得花时间和钱去修条水管:比如工作上遇到难题了,直接上网搜答案,而舍不得花时间从基础学起:比如执行某个软件操作时舍不得花时间去找快捷键,每次都从菜单里点. 相对的是延时回报式,表现为:刀钝了就先去磨刀,磨快了再去砍柴:修水管而不是去提水:学习先从基础的开始:注意使用快捷键. 表现远远不止这些.从表面上看,即时回报的方式短期见效快,长期效率差

关于找工作时的境遇与情绪波动

前言:投了很多公司,大公司小公司,在专门的网站上投的基本是石沉大海了,找人内推的还在静候佳音中...大三结束升大四,压力远远不是大二升大三时能够想象的,就业难的问题到底还是重重的压下来了... 正文: 其实说就业难是大环境的一方面,还有同样很重要的一方面就是个人条件,我所谓的个人条件=实力证明+个人能力. 先说实力证明,至少可以追溯到高考,你考取了985,211的学校,在找工作时,就确乎可以得到比别的学校的学生更好的机会.等到了大学,你学习成绩不错,获得了很多奖状:还有兴趣和动力参加各种比赛,如

JS获取时间段内的工作时长

需求 1.给一个开始时间和结束时间: 2.计算在时间段内工作时间长度: 3.工作时间是9点-18点: 4.工作时长是8小时: 5.不记录周六和周日时间: 插件 使用了moment.js 代码 1 function GetWorkHours(beginDateTime, endDateTime) { 2 var _totalHour = 0; 3 //1.获取开始时间和结束时间之间的日 4 var _beginDate = moment(beginDateTime); 5 var _endDate

make工作时的执行步骤

GNU的make工作时的执行步骤 (1)读入所有的Makefile (2)读入被include的其它Makefile (3)初始化文件中的变量 (4)推导隐晦规则,并分析所有的规则 (5)为所有的目标文件创建依赖关系链 (6)根据依赖关系,决定哪些目标重新生成 (7)执行生存命令 定义在Makefile中的目标可能会有很多,但是第一条规则中的目标将被确立为最终的目标.如果第一条规则中的目标有很多个,那么,第一个目标会成为最终的目标. 为了避免和文件重名的情况,可以使用一个特殊的标记".PHONY

在汇报工作时,我需要做些什么

最近在更新计划文档或是汇报工作时,总有一些点讲不到位或是遗漏:针对此问题,想了下大概可以从以下几个方面去尝试描述,后续如有新的想法,继续补充. 1.结论.一般给领导汇报工作,首先要把结论说明,然后再详细说明过程,遇到的问题等 2.讲清楚问题 + 优先级高的问题:问题描述清楚,才能让领导更好的分析及判断怎么解决问题,如果连问题都说不清楚,就别提多上火了:另外就是高优先级问题提前识别出来,重点汇报. 3.计划:了解了问题后,就得有明确.详细的解决措施及计划,做定期做跟踪,及时汇报进展.   如果有问

Java对象分配内存时的内存图

摘自高琪老师的JAVA教程. Java对象分配内存时的内存图