让其他人知道

Posted on Fri 21 October 2011 in 我思

我想分享的是在工作中要尽可能的让团队成员、领导和干系人知道自己做了什么。

首先帮团队成员想明白为什么要这样做

这样做有以下一些好处: 1. 因为这个做法本质上来说也是一种分享,所以自然会带来分享的好处; 2. 从绩效管理上来看,成绩可以换来升职加薪。让领导和团队都清楚你做了什么,那你获得高绩效的几率也会增加; 3. 从领导的角度,他要为你的行为承担责任,你及时的汇报能够增强他对你的信任;

然后鼓励他们尝试各种表达方式并进行指导

让大家知道自己的思路、计划、进度以及完成的工作有两种方式:口头表达和文字表达。需要注意的方法不尽相同

口头

尽量先总结再展开。 例如,过小组周工作计划(Jira Review)时,先告诉大家本周整体的工作完成情况:本周大致三类工作,10件具体任务,目前完成8件,明天还能完成1件,还有一件因为XX原因,顺延到下周。然后再逐件分析; 讲一个技术方案,先说一下我们要解决什么问题,基本的业务逻辑是什么,然后再深入进行讲解; 分析一个跨部门的任务,先讲讲外部门的需求时什么,然后再说我们是怎么做的。

对于复杂事情(发现三言两语自己说不清楚的),尽量落到文字上去表达,先发个邮件,然后再拉人去沟通。

文字

沟通类的,例如邮件,和口头表达的注意要点是一致的。

主要想说一下技术团队的文档。 1. 有必要的文档 不同类型的产品有不同的要求,拿一个SOA平台服务来说,具备哪些功能?业务逻辑如何?有哪些实体,关系如何?部署情况怎样?这些是业务、技术人员都需要了解的。 如果真对这个业务的历史是了如指掌的话,记录一下是怎么产生的,之前出现过什么问题或有趣的事情,那就更完美了。 2. 容易获得 把文档用邮件一发或往jira上一放就算完事的做法是不够的,因为不利于以后的查找。 目前的最佳实践是放在项目wiki下 3. 容易看懂 建议看图说话。 系统功能说明:Use Case Diagram 对功能的具体业务逻辑描述:Sequence Diagram 业务实体模型:Class Diagram 系统部署情况:Deployment Diagram