团队工作感言：任务分配及管理 - skycnit的个人空间 - 51Testing软件测试网 51Testing软件测试网-中国软件测试人的精神家园
团队工作感言：任务分配及管理
& 15:46:25
/ 个人分类：
前面说到过，刚开始带小组，接到一个任务，我就估算了我大概要多少时间，然后小组多少个人就算是多少个我，估算时间＝我要的总时间"小组人数（好笨的想法呀，不用时间跟组员交待任务的吗？个个组员都是我吗，比我强的还好，顶多做完了休息，差一点的就麻烦了），结果实际时间多了很多，而且小组里有的人做完了无事可做，有的人则忙得焦头烂额，容易打击组员的积极性，造成组员之间的不满。随着经验的积累，要想把任务分配得比较合适，首先要对自己的组员有一定的了解，最好能量化，其次要把握好任务（这就看需求分析及系统设计的功力了），以下是我的一点经验，我把我的组员分类（简称ABC分类），主要划分的指标有技术能力，做事速度，业务理解能力。主要看前两个指标，因为我在做需求分析的时候已经把业务弄熟了，分配任务的时候我会尽量从程序员的角度跟他们描述业务逻辑，以下是我跟组员讨论业务的一点心得：1，业务上的一些概念名词要注意讲清楚，不要一带而过；特别是跟程序名词相近的。2，讲流程，尽量多画图，对着流程图讲解方便易懂，把来龙去脉讲清楚。3，多讲讲为什么这样做（思想），反过来可以验证自己是否真的理解了业务了。4，对于组员提出来的疑问，要能明确回答（验证业务、设计是经得起别人考验）组员划分等级（每项满分10分），如图：能力等级技术能力做事速度A+非常好（8-9）慢（5）A好（7）快（6）B一般（6）快（6）C一般（6）一般（6）任务，主要从两个指标进行划分难度（技术，业务上），工作量，如图：任务类型技术难度工作量X大小Y大大Z小大Z-小小分配任务，任务类型对号入座到相应能力等级的组员中去(红色能力等级优先分配，依次往右递减）：任务类型能力等级XA+AYAA+ZBA,
A+我分配任务的原则是：技术好的多做脑力活，技术次之的多做体力活。不仅仅需求要分析到位，任务也要分析到位。很多Y，Z类的任务通过分析，可以化为X、Z-，化为这两种类型任务的好处是多做脑力活动，少做体力活动，相对减少开发时间。如图：转换1示例：信息系统中的一大部分为：业务数据的录入+数据处理+流程控制，可以把流程的控制抽象为一个工作流控制组件，组内一个人做好，其它的人根据说明文档直接调用就可以了。转换2示例：一些数据表对应的业务逻辑对应的操作仅仅是添加，删除，修改（难度小，量大），我们可以把它做成一个自动生成的模板，直接生成相应页面及操作代码。（CodeSmith是一个很好的自动生成工具，而且网上有很多做好的模板，很好用，推荐！）在平时开发中，在完成一个任务之后，我再回过头来看自己的编码，经常会突然想出另外一种方法，对比一下发现这种方法省时又省力，然后后悔当初为什么不用这种方法？需求没做好，过早地编码是做负功；任务设计分配没做好，过早编码则是多做功！组员任务的时间确定让每个人分别估算每个任务的时间，PM自身也要估算任务的时间，差距不大时以组员为准，差距大时商议决定！（时间尽量以组员的为准，体现着信任，再则假如PM硬压时间下去，该组员肯定心里有情绪，也不利于工作，再则之间关系闹僵也不利于之后的工作开展）在实际的操作中，比较关键的任务（比如基础的模块，很多地方要调用到）我会认真地估算一下时间，然后再跟组员的对比；对于一些不太重要的任务我只是感觉一下时间，只要跟组员差不了很多（组员的时间＝我感觉的时间*2之内），一律以组员为准。个人认为应该放权给组员，面面俱到，亲力亲为的话PM会很累，对于一些不是很重要的东西，放心地让别人去做吧！感觉程序员都还是比较实在的，组员一般估算的时间都比我的少，几乎没出现过＝我感觉的时间*2的情况。白纸黑字，责任要明确把每个人每段时间要做的任务写成文档，该文档最好是由任务的执行者来执笔，因为很多时候你给组员交代任务的时候，他看上去是听懂了（他自己当时也认为是懂了），可是做到中途的时候，才发现是似懂非懂，模凌两可，这时候他估算的时间自然也就不可靠了，整个项目的进度自然就比计划的慢了。PM看了文档后，就可了解该组员对任务的了解情况，发现有问题，便可有的放矢了。以下是我认为任务文档里应该清楚说明的几个地方：（1）该任务是实现的功能是什么？（2）什么时间完成？（3）要达到什么样的质量？（为了防止只顾速度，不管质量，可把标准的一部分当成要达到的质量要求，例如：不能存在1类错误&设计中有的功能未实现&，2类错误&存在严重的错误使流程无法继续&）（4）延时怎么处理？（开发中出现延时再正常不过了，我的做法：该任务执行人再估算余下需要的时间，只要是合理的延时直接同意）（5）什么情况该任务终止？ （我的做法：延时一次后未能完成该任务，该任务终止，换人或方案）这项在一般公司的任务文档说明里很少见，但我觉得很有必要，它的好处如下：
A防止无限延时（无底洞），有时候某人胜任不了该任务（分配任务的失误），到了时间做不完，延时，再做不完不甘心，再延时，如此反复，期间你不同意有点不近人情，不给面子，同意的话时间上又受不了。有了此项说明，出现了这情况就终止，有文档为证证，按依据办事＝＝对事不对人，这时对双方都是一种解脱。B起督促作用，因为延时后再完成不了会被STOP，出现了延时之后，组员都会提起十二分精神搞定，因为已经没下次了。这部分分档一式三份，一份交上级，一份PM，一份任务的执行者；有系统的话，直接录入即可。在这种情况下建议还是生成一份文档交给上级，因为上级一般不太进项目管理系统；再则看到专门的文档容易引起重视。信任，但是要检查当一个任务的时间大于6天以上，要进行相应的细化，细化到3-6天为宜（在任务上写清楚，在该时间点上，应该出来什么成果，如何进行检查），主要出于以下几个方面的考虑：A个别组员自我管理能力差点，当任务时间比较长时，容易出视前松后紧的情况，这时候把任务细化到3点一检查，可以避免这种情况。B检查时间正好为一周，在这个点上，正好小组一起开个例会，在例会上小组每个成员依次发言，内容为我这一周的计划是什么，实际进行得怎样，实际比计划好，则说说自己做得好的地方在哪，让大家；实际比计划差，则说说自己问题出在哪，大家支支招；最后我进行总结发言。这个例会看似简单，实则发挥作用很大，试想一下你完成不了计划的任务，当着这么多人的面说起来，假如原因仅仅是自己做事慢；又或者你每周都是在讲完成不了任务，只要不是脸皮很厚的，都会觉得自责，不好意思，甚至于脸红！这就是一种无形的督促，约束，这个组员下周肯定会拼命干（糗了一次，不能糗第二次嘛，人很正常的心理，这比你平时直接叫他快点做，或者责怪、批评他要强得多）C这好比跑马拉松，因为距离很长，在很长一段时间内看不到目标，人很容易疲倦，但你人为地将它划分为若干个目标（检查点）之后，目标清晰可见而容易到达，人就很有动力了，且不容易觉得很累。每次检查都要做完相应的记录，形成文档（更新到系统中），一定时间段内发送给上级，做为汇报的内容，让上级知道小组在干什么，干都怎么样。任务文档相于计划，检查记录相于实际，实际与计划对比就出来绩效。实际比计划好，就是做得好，反之则差，好多少，差多少，也可以在文档中找到相应的依据（时间，质量）。还有就是这种避免了中途加功能，出现延时说不清楚（对着文档，新加的功能作为一项新的任务，自然要加时间，可能在客户那边是一样的延时，但对于你的上级来看则是不一样了，他至少不会认为是小组不努力，偷懒造成了延时）。记得有一个项目，因为是项目收尾时客户加了功能，所以延了时间，还有销售、市场人员给客户演示系统的时候出了点问题（销售、市场人员对系统不解、操作不熟练，当然也有系统不够人性化的原因），在协调会上，销售人员就往开发身上推责任，就事论事也就得了，居然还扯到其它的，说开发的怠工，不够卖力，还延时了比较久。当时上级表示了也有同感（事后分析时估计是上级来检查时，正好组员完成了该段时间任务，有点放松，在看看书、报），假如是以前我的做法是诉苦：“你也不看看中间加了多少功能？”，“小组都加了好几天班了”之类的话语，别人肯定不买单，最后就变成吵架会了！这时我把任务、检录记录文档拿出来，指出哪些是加的功能，哪些是最初设计的功能（这些文档里都有记录），一对比，加的功能占了多少，都是在什么时间段追加的（主要是在后期，赶工也来不及了呀），这就是为什么延时的原因？再有是组员检查时的进度与计划的比较（那次还算比较好，实际基本跟计划一致），到底是不是我故意在延时，或怠工造成了延时，还有开发的卖不卖力，文档记录都能说明问题。讲完之后再把文档的递给销售、市场的人看，当即他们就哑火了，事实胜于雄辩呀！事后他还向我道了歉，说自己脾气比较直，说话说过头了，呵呵。其它相关心得：1，PM不要给自己分配给过多的任务，任务类型为X，Z-为佳，因为PM要抽出较多的时间比进团队的管理。因为开发以技术以主，PM要能服人心，关键是技术要比较好，所以建议选X类型任务，不会因为工作量太多而致使没时间管理小组。2， 需求分析—估算时间—分配任务，不是一个直线下来的操作，在需求分析的时候可以敏锐地找出一些与业务无关的技术难点，此时可以安排组员攻关。分配好任务，每个组员算好自己的时间，可做为估算时间的一个参考依据。3，不要把加班的时间当成正常的工作时间，因为开发经常会出现延时，加班的时间一般当成补漏的时间比较合适，再则我发现加班的时间效率比较低，一般晚上2、3个小时还不如正常工作时间的1个小时（很好组员都心不在焉，不过也可以理解，都辛苦一天了，晚上还要加班），还有周六、周日加班的话，很容易造成下周整个小组的疲惫，影响正常的工作效率（个人观察发现的结果，不知有同感吗？）；不过发现上级很喜欢以小组加班与努不努力挂勾，看见小组加班就觉得很卖力（其实出的活很少，我统计过完成的任务量），像这种情况就做做样子做上级看好了。在中介绍完高大上新概念的 Moxtra 之后，本期介绍的内容是相对来说比较接地气的以任务为中心的项目管理类团队协作平台。这类协作平台是以个人的 GTD 时间管理理念为基础延伸出来的团队协作产品，它的侧重点不是协作创作（比如 Google Docs、One Drive）而是协调团队间工作这件事本身。首先登场的是小清新的 ，是国内较早的一个团队协作创业项目，它在使用习惯上更加贴近于普通用户和非互联网创业团队，界面设计的没有那么“酷”，但是却也能让人一目了然。主要的功能分为讨论、任务、文档、文件这四个大部分，“讨论”这个功能比较有特点，它直接在协作平台内架设了一个论坛，每个成员都可以发布帖子并回复讨论，帖子支持富文本格式。这个功能在国外的项目管理类协作平台 Asana 和 Trello 中都没有，源自 tower.im 的原型 Basecamp。另外，关于文件和文档在 tower.im 中是这样区别的，文档是指直接在 tower.im 上撰写的并且可以进行讨论可以分配给成员的叫文档。tower.im 的文档编辑功能支持富文本和 Markdown 写作两种格式。文件就是一个类似于网盘的功能，上传后的文件不论是什么文件都可以在 tower.im 中进行分享，但是在线编辑就做不到了。由于界面设计的原因，tower.im 的任务列表功能稍稍显得有些混乱在信息层级上，tower.im 的组织形式是团队&项目&任务列表&任务。tower.im 的统计功能并不算好用，这似乎也是国内同类竞品统一的劣势，同意团队推出的另外一款协作平台 Teamcolla 看起来似乎是专门解决这一问题的但是却没有和 tower.im 结合在一起，Teamcolla 自身的功能又过于轻量化。价格：免费版有 20 个项目限制，企业版 299 元/月，独立服务器部署版 8999 元/年我们之前曾经 Worktile 的产品， 也是以任务/项目管理为中心的协作平台，除了任务管理本身之外在一定程度上也能替代文件共享和即时的讨论。Worktile 有简报功能，这里比 tower.im 统计功能详细一些，但是其实也不慎完美。现阶段这个功能只能大致的从数量上判断工作的进展程度，不能代替大多数团队需要做的周报或者月报功能（国内协作平台没有一个在这方面赶上 Trello 第三方周报应用比较可惜）。聊天记录本身是无法导出，但是聊天中产生的附件会被自动存档Worktile 在功能上也分为任务、日历、文件、讨论、文档这几大块，与 tower.im 最大的区别在于 Worktile 将即时通讯的功能也融入了协作平台之中。因此 Worktile 的重量其实是三者之中最重的。不过和上次介绍的 Moxtra 不同，Worktile 无法自动的将聊天内容转换为任务进行指派，即便是用 Worktile 进行即时沟通也存在事后重新整理聊天记录的问题。信息层级上，Worktile 也是团队&项目&任务列表&任务，这点与 tower.im 相同。总体来说，tower.im、Worktile 两者在功能上十分相近，界面上的差异大于实质功能上的差异。tower 的原型是 Basecamp，而 Worktile 在核心任务这一部分的设计的原型应当是 Trello。Worktile 的更加偏向于一个客户端式的（工具）界面，而 tower.im 的则更加倾向于用户对网站的认知。Worktile 在年后刚刚上线了 Android 和 iPhone 的客户端。就在笔者撰写这篇文章的过程中，Worktile 发来消息称他们将开始新一轮的大改版。价格：10 人以下团队免费，10 人以上团队每人每月 10 元，100 人以下公益团体及学生社团可免费使用相比其上面两款已经在宣传自己轻量化的团队协作工具来说，的设计更加轻量化，它的 Dashboard 界面看起来甚至不像是一个团队协作工具而像是一款个人时间管理工具。因此它最大的特色就是简单易用易上手，有 GTD 工具使用习惯的人可以轻易的上手风车，如果不用作团队协作工具的话当作个人工具使用也很方便。简单直观图形化是风车的优势也同样是它的局限因此风车可能适合“更加小型”的团队（团队成员不超过 5 人），相对来说团队需要协作的事情比较少，相对来说个人对工作的自主性大且任务的独立完成程度高。在这种情况下，风车可以作为团队间 GTD 的分享，方便小团队在各干各的情况下能够清晰的看到彼此之间在做什么。但是由于并没有像前两者那样包含文件分享、讨论等“重”功能，因此团队还需要另外选择如 Google Docs、Dropbox 或 OneDrive 之类的云存储来进行分享以及其他即时沟通工具（这么小的团队就当面聊吧）。不过，风车在新建项目时为项目设置了三种类别，这三种类别分别为“Todo 型”、“协作型”和“软件开发型”，他们之间的主要区别在于：Todo 型-不考虑任务执行的过程，任务只有待办和已完成两个状态。协作型-考虑任务执行过程，方便团队成员之间查看任务进度，任务分为待办、进行中和已完成三个状态。软件开发型-考虑任务执行过程，且考虑后续开发人员的验收，任务分为待办、进行中、已完成、已验收四个状态。在一般的 GTD 中，已验收这个状态应当是一个新的任务并被归类为整个团队的“Next Actions”（下一步行动）。但是 GTD 并不是一个严格的标准，风车这样用更加直观的方式表达更加符合初入团队协作和时间管理用户的使用习惯。如 Worktile 一样，风车也将自己的界面伪装成了客户端，任务列表中的任务是可以拖拽的。信息层级依次为项目&任务列表&任务。由于承载的信息量比较少，风车的界面看起来比前两者都直观。针对每一个任务可以展开讨论，但任务外没有安排讨论的空间。由于网页版界面长的就比较像客户端，所以手机客户端更是可以实现网页版的全部功能，在界面上与个人 GTD 无任何区别，一定程度上可以代替 Any.do，Doit.im 使用。价格：没有免费套餐，2 人团队 10 元/月，5 人团队 66 元/月，10 人团队 126 元/月，20 人团队 286 元/月其实从上面我们可以看出来，这三家团队协作软件基本上都能找到国外同类产品鼻祖 Asana 的影子，在 Asana\Trello\Basecamp&的设计理念上进行组合重构，细节微创新，语言和相关服务的本土化之后的产物。当然，从使用者的角度这类产品还是喜闻乐见的，毕竟国外的 SAAS 对于国内的团队来说使用门槛还是较高，语言、付款和本地服务对接方面都存在问题。当然，所有这些国内项目管理/团队协作工具比他们的国外原型都有的一点巨大优势是：快就一个字！团队协作工具最重要的作用是帮助团队高效的进行沟通，因此即便是国外工具确实好用，在天朝现有的网络环境下选择一款加载界面 10 秒以上的工具也有些得不偿失。
公开课：，听 WIFI 万能钥匙联合创始人李磊与你分享，共享经济时代下如何创业。
热门文章推荐您好， []|
Trello：团队任务分配和追踪管理器
腾讯科技讯（Kathy）北京时间9月14日消息，据国外媒体报道，著名的软件开发者乔尔·斯波斯基（Joel Spolsky）曾创建了问答平台Stack Exchange和供软件开发团队使用的项目管理系统FogBugz。今天在TechCrunch Disrupt大会上，他又推出了团队工作流平台和列表管理器Trello。 斯波斯基说，运行和管理一家公司，最困难的事情莫过于追踪大家的工作状况，因此他开发了Trello来解决这个难题。任何行业中的任何人都可以使用Trello团队工作系统。 这个基于Web的应用希望成一个“聚集地”，让所有的协作团队都可以在这里分配任务并进行追踪。其他的项目管理系统通常把重心放在开发人员身上，而且过于复杂，对比较大的社区不太适用。而Trello适用于任何类型的工作流，它是一个以业务为中心的工具，你甚至也可以把它当做个人的列表管理应用。 Trello为团队提供一个“board” （板），团队成员可以在这里创建待办事项，设定任务并把它们分配给同事，而同事在任务完成时就可以更新任务的状态。你可以为每个项目创建一张卡片，其中包含通信内容、活动、附件、更新等等。你可以把团队成员拖动到卡片上，然后再把卡片拖动到列表上。 像其他工作流应用一样，Trello平台也是视觉化的。它实时运作，无需刷新即可更新，在任何浏览器上都可以使用，能让通信变得更加有效率。而且Trello也内置了企业功能，比如权限和组织等等。Trello目前是完全免费的，但是将来当有很多人使用它时，Trello有可能采用免费增值模式。现在Trello有一个iOS应用，一个Web应用，很快它还会推出一个API（应用编程接口）。
推荐微博：
[责任编辑：loiswang]
(请登录发言，并遵守)
如果你对科技频道有任何意见或建议，请到交流平台反馈。【】
新闻排行财经科普数码科技
Copyright & 1998 - 2015 Tencent. All Rights Reserved