任务分配

  “把前台所有的操作添加上日志”,“把所有的菜单都检查是否有某某功能”,当你听到一个这种任务时是一个表情?
  对于任务分解分配者以这样的形式给你发一个任务时,我心中一万牛羊驼奔过。对于一个执行者,好多新手,或者码砖的熟手,他不是一个任务的分解者,即使前期做了整体的了解,他也不是一个分解者。他面临这种泛化的描述是十分困难的。我也遇到过几次这种情况,叫你把所有的某某调整成某某,这种描述我也是无法接受的。以前在一家公司,功能由产品做调整,开发修改。然后产品就有这一句这种描述,把所有的单菜某某加上某某。我去,所有的,当时菜单有很多分类,每个分类下面还有很多,有隐藏的,有非隐藏的。总之在一个十多年的项目里面,这种也整理一份,指定调整,一定会有些没有调整到,或者影响到其它地方。而且我第一感觉也是十分的困难,无从下手。
  其实即使所有的事情要让对方做,也可以尽量的分成一个个小任务来分配,这样可以大大的感少抵触情绪。比如,任务1.1,将目前的菜单做整,按分类,整理出所有菜单包括类型,是否有隐藏在哪些版本里面等等,这个花一小点时间都整理分配。比如这个3d时间。当整理完成后,现出来个1.2,按1.1的分类,或者指定哪些分类什么类型菜单加上一个功能。这个5d时间。这样子会比直接1.1,将所有菜单加上某某功能 10d来得实际,而且整理过一次中间还可能会避免一些错误,因为带“所有”,“全部”,“除什么以外”这种词汇时其实有很多你在分配任务时是不清楚的,可能你也没有花时间去查看所有的菜单。
  从我个人的理解和感受来说,分成小段,可以理解的小段比一大块甩给人家更好。

  反过来思想,当我们生活中人个理到一个比较难的问题时,无从下手时,也可以一步一步的分解开来,这样个个击破的方式可以让你处理复杂问题变得得心应手,无所畏惧,主要是畏惧这个词语,一个庞物,如果你分解开了也是一些很能理解,能处理的部分。当有了这种思想以后就可以变得脸皮十分厚(我这里是形容),老板让你建一个长城,我也可以回答没有问题。

时间: 2024-12-10 11:24:39

任务分配的相关文章

第九节 任务实例与任务分配

1.JBPM的任务:流程与交互者操作的一种手段 2.任务实例 3.任务分配

Daily Scrum 1 --团队项目所需时间估计以及任务分配

考虑到所有的任务不可能逐一细化分配给成员,我们将需要完成的任务进行了大致的分配.任务所需要的具体实现可以参看<学霸网站NABC> 所需要的总时间一共为44h. 我们会在以后的每日任务中进行细化任务,在细化的过程中可能会导致任务所需时间的增长. -------------------------------------------------------------------------------------------------------------- 在TFS中创建任务并将任务分配给

关于任务分配方式的一种设想

场景1:一个5个人的小团队在开会,他们在对工作包进行时间的估算,他们每人手上一幅牌,牌上面是一些1/2,1,2,4,5这些数字.A:4,B:1+2,C:4+1/2,D:5...这样他们各自表达了自己对当前任务的开发时间的估计,由于每个人的善长点,考虑的点都不同,所以时间几乎不相同.然后组长在分别收集他们每人对当前讨论任务给出时间的依据,特别注意用时最长和用时最短的人的想法,最后他们沟通后找到一个折中的时间,如果其中有些成员想法没有统一,最后也只能双方妥协,听组长安排,比如A说,这个地方肯定会用2

MapReduce剖析笔记之五:Map与Reduce任务分配过程

在上一节分析了TaskTracker和JobTracker之间通过周期的心跳消息获取任务分配结果的过程.中间留了一个问题,就是任务到底是怎么分配的.任务的分配自然是由JobTracker做出来的,具体来说,存在一个抽象类:TaskScheduler,主要负责分配任务,继承该类的有几个类: CapacityTaskScheduler.FairScheduler.JobQueueTaskScheduler(LimitTasksPerJobTaskScheduler又继承于该类). 从名字大致可以看出

团队项目所需时间估计以及任务分配

由于能力有限,我们还不能构架好一个大框架.但是初步可以完成任务的流程和分配. 所需要的总时间是58h. 由于目前尚未找到学霸项目的github代码网址,故目前尚未将任务创建到github项目中. 现在只是初步的任务规划,在时间充足的情况下,我们会逐步添加一些必要的功能,使得学霸系统的效果更好. 再加上有些人的功能实现是零基础的,可能我们给的时间是不太充足的,实际用时可能更长.这也就意味着我们的总共用时将会超过预期时间,甚至远远超过. 对于这个每个任务,我们都有较为细致的划分.但是有些方面我们了解

jbpm的智能选择审批人及人工任务分配的实现思路

一.jbpm中审批人的概念 在工作流中每一个人工任务的办理者被称作审批人,在原生的jbpm定义中,我们可以看到assignee和assignmentHandler这两个标签. <task name="review" g="96,16,127,52">       <assignment-handler class="org.jbpm.examples.task.assignmenthandler.AssignTask"> 

Akka(4): Routers - 智能任务分配

Actor模式最大的优点就是每个Actor都是一个独立的任务运算器.这种模式让我们很方便地把一项大型的任务分割成若干细小任务然后分配给不同的Actor去完成.优点是在设计时可以专注实现每个Actor的功能,在实际运算时由于每个Actor都在独立的线程里运行,能充分利用多核CPU的优势实现相似并行运算的效率.我们同样可以把一个独立的功能按不同的输入分配给多个Actor去完成以达到同样的效率提高目的,这就是Akka的Routing模式了.Routing模式的特点是所有运算Actor的运算逻辑都是相同

Activiti学习笔记10 — 动态任务分配

动态任务分配使用的两种方式 一.通过特殊表达式,来获取任务信息 ,在流程 UserTask节点上设置 ${流程变量的Key} 1.流程定义 1 <?xml version="1.0" encoding="UTF-8"?> 2 <definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:xsi="http://www.w3.org/2001

Activiti用户任务分配

一.前言 上篇博文<浅谈Activiti工作流引擎用户管理>中已介绍了如何自定义自己的用户管理模块.然而困恼大多数新手的另一个问题:如何将任务分配给有层级关系的组织结构用户呢?例如,我只想把任务分配给我上级部门的领导审批,而上级部门的任务又只分配给指定的上级审批.而按Activiti的用户(user).组(group)来平级关系来操作的话,则需要设计多个组.多个配置来实现,这显然不合适. 二.需求分析    一般公司的组织结构: 再看看我项目中的部分审批流程截图: 所以,我申请人的申请当然是给

hihoCoder 1309:任务分配 贪心 优先队列

#1309 : 任务分配 时间限制:10000ms 单点时限:1000ms 内存限制:256MB 描述 给定 N 项任务的起至时间( S1, E1 ), ( S2, E2 ), ..., ( SN, EN ), 计算最少需要多少台机器才能按时完成所有任务. 同一时间一台机器上最多进行一项任务,并且一项任务必须从头到尾保持在一台机器上进行.任务切换不需要时间. 输入 第一行一个整数 N,(1 ≤ N ≤ 100000),表示任务的数目. 以下 N 行每行两个整数 Si, Ei,(0 ≤ Si <