人从众𠈌

人多地方就有了江湖

新工作32个工作日结束,焦虑了一个半月的心总算逐渐安定下来,承接上两篇工作谈内容,来聊一聊工作进展:

  • 项目管理工作走向正轨,项目组调整基本完成,形成一套方法,统一了团队的管理思路。
  • 人员逐渐齐整,请假小伙伴回归,新人到位,自己完成了所有人的一对一面谈。阳光、风和乌鸦中有提到。
  • 着眼技术实现与业务知识的学习,“以教带学“,采用知识沉淀的方式,用输出倒逼输入,保证学习质量。
  • 着眼于打破项目组间的信息壁垒,开始尝试事务流、信息流、知识流的传递。

今天基于实际的项目管理工作聊一聊项目管理的落地应用。PMP梳理出通用的项目管理知识、方法,可是在各行各业的应用中出于种种历史、文化原因,很难一杆子打到底。在不断的裁剪、演化下,五花八门,眼花缭乱。市面上也出现了各种项目管理的工具,初学者趋之若鹜,容易陷入工具的海洋。我在这段时间的实践也掉入了“想法的深渊”,不断出现新的思路,经过不断的策略调整,终于找到了破解的办法。

初入项目组,面对的是各种问题与现实:不到20个人的团队里,人员齐整,却无法完成产品经理安排的实际工作,总是有任务遗漏,总是有紧急事项,总是会拖到截止时间。整个项目组的工作像一个千疮百孔的塑料袋,拎起来到处漏水,放下去,一团糊涂。
实际工作做起来更是麻烦百出,沟通问题时表达不到位,不能主动思考和反馈,每一件任务都在给我这个新人“挖坑”,半天搞不定一个流程申请事宜(总是被打回,总是说不清晰)。
由于长期的人员变动,大家对旧的内容不熟悉,没有有效的知识沉淀方法,无法形成“团队记忆”和“团队知识”。

三流

项目管理工作,可以看作是在疏通三个“流”,如果这三个“流”理顺了,项目组可以进入良性运转状态。“流”的概念参考了计算机世界的“数据流”。

事务流

如果我们把具体的项目任务看作是“流动的水”的话,从业务提出需求到产品经理传递任务到需求分析、需求设计、开发实现、测试把关、上线运维整个系列的事项就是一个事务流。不到20人的项目组里每天推进将近30个事务流,事务流并不是一成不变的流转,过程中还涉及到其他系统的沟通协调、问题处理、联调联试等等。

信息流

好好说话站在个人的角度看待沟通,如果把项目组看作一个作战单元,十几个项目组的协同主要涉及到信息流的传递问题。而组内的信息流也并不顺畅。信息差无处不在,项目组的不同的人对同一个系统的理解不同,不同的项目组在沟通中立场不同,加上多任务协同的压力,往往达不到好的沟通效果,怎么办,多来几遍,花费了大量的时间,还不一定能达到好的效果。

举个简单的例子,A对自己的系统了解甚多,接口的问题找了其他项目组的B,而B只知道自己系统的情况,对A提出的协同要求无法有效响应。A为了说清楚事情写了邮件给B,结果A的邮件写的没头没尾,无法有效传递信息,只能继续口头沟通,或者找到C帮忙解释,费了半天的时间才把本来应该是很简单的事情说清楚。

知识流

有用的信息可以理解为知识。人员流动导致许多本应该属于团队的知识以个人为载体逐渐的流失,并未成为团队的知识,可以说知识流几乎是无效的。

没有有效的新人指导,没有可以全文搜索的查询方式,SVN海量的文档反而成为了“知识的诅咒”。

三宝

经过一段时间的实践,最终形成了基于三个管理工具的管理方法,简称“三宝”(三大法宝)。

每日日报

司空见惯的日报如何成为法宝呢?要抓住上下游,让日报真正的扼住“事务流”的喉咙。日报的条目是每天的实际工作内容,这些事项临时增加后必须在公司内部的服务平台新建任务单,利用任务单号和企业的管理流程关联,保证了内容可追溯。而后续的各个填充事项说清楚了某件事情由谁来做,谁负责,当天的任务和成果是什么,明天要做什么,后续如何安排,从中学到了什么。
日报通过详细的字段内容堵住了管理的漏洞,项目经理自己也有了可以跟进管理全组成员任务的工具。具体事务为单位的日报中通过对执行人的筛选可以清晰的了解全组成员的工作安排情况。管理工作更加“游刃有余”。

培训大纲

信息流的传递障碍,除了没有内部的知识沉淀(下文会提到),标准不够清晰也是重要原因。项目组内、项目组间要用什么样的方式进行沟通。我们应该知道什么,做什么,不做什么。这些内容,都需要通过一个培训大纲重新确立起来。

特种部队的选拔是及其严苛的,在好苗子的基础上,经过数个月高强度的训练、筛选,淘汰出了合适的人选,顺便完成了训练的工作。

在后续项目组的培训中,我选择了类似的方式,面试通过的是“好苗子”,在试用期内提供大量的培训和指导,通过高强度的学习、训练,达到团队的要求,转正后立刻投入正式工作。如果考核未通过,立刻放弃。而培训大纲就是这一切的起点,从需要培训的内容开始梳理出一个项目团队的方方面面。

可以说一个培训大纲的背后是完善的考核、培训体系。用培训稳定下来的不仅仅是人,更重要的是团队的标准。基于统一的标准,能够减少信息差的产生,降低沟通成本。如果各个项目组有统一的标准,这样的效果会更加明显。

内部维基(wiki)

培训大纲是“纲“,纲领性文件,落地到哪里呢,内部的Wiki。为什么是Wiki,对比SVN,Wiki有着不可替代的优势:

  • 低成本的获取方式:全文检索
  • 低成本的编辑方式:所见即所得
  • 低成本的沟通方式:请自己查看

SVN的问题在于内容庞杂,对新人并不友好,如果没有人教你,几乎不知道如何使用,该看什么。有一些主题内容藏在某一个N级目录下的某篇文章里,熟悉这个内容的最后一个同事昨天刚离职。大海捞针感觉并不那么方便,而编辑方式也是找到文件,打开编辑再保存,别人需要时再进行文件的同步,如果有冲突更是麻烦。想告诉同事一个东西在哪里,嘴是说不清楚的,得给链接,要么发邮件,要么发QQ……
这些问题完美的得到了解决,如果用好了Wiki:你想知道什么,不求人,自己搜索。全文搜索第一时间告诉你需要的所有内容,,搜到了就是找到了。所见即所得的编辑方式,有不对的内容直接网页编辑,其他人下一秒查询已经可以看到最新答案了。再也不用一个一个的去确认某一个系统设计的细节是什么,Wiki上都有,享受自己快速探索的过程吧。

非常感谢大妈的友情帮助,推荐我在实际工作中使用wiki进行知识沉淀。

知识是属于大家的,而不是基于某一个人的。知识流动起来,可以发挥更大的价值。这里的风险在于,大家是否愿意主动维护。wiki本是开源社区的产物,基于谁主张,谁负责的原则,这完全是给全职工作的追求“工作最小化”的人找事儿。所以光有工具是不够的,还需要其他的一些辅助方法。

团队文化

我为人人,人人为我

如果团队没有形成合力,这只是一群人而已,每一个人依然是独立的个体。但是一群人的力量远远大于十几个人。实际工作中有太多的事务需要协同,在如何协同间你有无数的选择,是点到为止,还是“倾囊相助“,会对团队效率产生巨大的影响。

《兄弟连》这部经典的美剧很好的阐述了这个问题的答案:生死相依的兄弟身上特别容易找到这种互助,无论是大牛落单后几个新兵蛋子冒死尝试回到已经失守的阵地营救,还是德军轰炸时爬出散兵坑帮助已经炸断双腿的战士进行遮掩保护。还有最后被喝了酒的其他士兵打伤时,想尽一切办法寻找战地医生的救护。每一段故事里都是浓浓的兄弟之情,你可以把你的生命放心的交给你的团队。

wiki的维护更是如此,于他人方便便是与己方便。如果都能有这样的认识,事情推动起来,指日可待。

知识“可复用”

如果仅仅是说一遍,你的生活里有无数需要讲解的重复内容。我自己的做法是写成博客,经常有小伙伴get到我的金句:这个事儿我在博客里有详细阐述,你去看我的博客吧。
团队更是如此,大量的内隐知识会通过口述、会议、邮件的形式表达出来,如果能顺手整理到wiki里,以后就不需要翻箱倒柜的只为找到一句话了。换一种说法,这样的好处是重复的事情尽量只做一次,剩下的都交给机器。

开源社群

论沟通成本和效率,开源社群应该是极高的沟通成本和极地的协同效率的产物,并且由于没有团队凝聚力很快就被时代淘汰掉。剧本没有这样写下去,相反,开源社群为计算机的发展做出了不可磨灭的贡献。正是因为开源社群遇到的很多问题,大家想到了许多解决办法,并且形成了自己独特的文化“谁主张,谁负责”。对于开源社群的李洁,参考我的其他博文中世外桃源,开源世界章节。

最后的最后

最后的最后,想写给我的团队小伙伴们,这只团队在我心中未来会发展成为的样子,共勉之。

小而美的作战单元

项目组应该成为“小而美”的作战单元。大家有共同的期许,在一起工作时就像战时的特种部队一样简单高效的运作模式。每一个人都可以独当一面,每个人都有强烈的主动性推动事件的发展。

低内耗高产出的架构设计

从组织的构架上就开始减少内耗,强调结果导向。不断的输出优秀的成果。

学习与知识沉淀

有浓厚的学习氛围,不断的研究新技术,提升个人能力。
重视知识沉淀,形成团队的流程、经验库、以及项目组独特的记忆传承。

声明: 本文转载需标明出处,禁止用于商业目的。

ChangeLog

170309 新建
170324 发布
170325 修订