高效的协作环境w/ 案例分析

涂名雷tmlneu@gmail.com

这里讲到的一些东西可能不那么新鲜但追新求异不是这里的目标

事实上，我很多方案的一个可贵之处，是虽然追求的目标有点让人生畏但具体实施却简单平常

纲要• 现况梳理• 在线企业，分布 /动态决策，自治单元和个体

• 基础建议• 在线代码托管，整合的知识 /内容，便携的开发环境，想法 /方案交流区，责任单元，活动记录

• 问题 /案例• 基于内容的交流 vs. 关联内容的交流，直接沟通，自助模式，完整的任务，人员自由流动，以客户为中心，项目

管理的核心价值，学习型组织，技术氛围，绩效评估 ...

现况梳理• 在线企业

-- 以网络为中心的思考方式• 分布 /动态决策

-- 为决策支持而构建• 自治单元和个体

-- 相互支持和自适应

在线企业• 互联网公司基本上都是在线企业• 在线资源：网站，顾客，代码，邮件，文档，流程 ...

• 从某种程度上来说，我们都工作在一个无边界的产品当中：从不同的角度，观察

它，加工它，并且体验它 ...

• 但是，我们是以网络为中心的方式在思考吗 ?

• 联结的知识 /信息• 开放交流和协作

• 便携的工作环境• 知识 /信息随手可得

• 例子：基于 github 的协作

> 以网络为中心的思考方式

分布 /动态决策• 复杂动态的企业内外环境• 快速兴衰的市场，不断更替的技术，复杂的系统和依赖，

努力学习适应的人员 ...

• 分而治之，动态协调 > 动态规划和调整

• 为决策支持而构建，基于限制的管理 => 鼓励决策并提供支持

> 为决策支持而构建

• 可扩展的计划和协调机制• 支撑环境（组件 /服务 /工具，知识 /信息等）

• 领导而不刻板管理，支持而不粗暴限制

• 观点 1：更好的细节监督来自于搭档和自律，而不是顶头上司

• 观点 2：支持也是一种控制，它能有效影响决策

自治的单元和个体• 组件 /服务 /工具最终由人来提供和维护

• 专门的部门 / 团队 ++> 责任单元，个人 /小团队负责，个人可同时负责 /参与多个

• 自治的单元和个体更容易相互支持和自适应，实现超常规的价值

• 例子： github 上的 TJ， substack

> 自治的单元和个人• 持续改进之外，更愿意接受变革• 直接沟通和反馈• 日常融合，更少隔阂

• 观点 1：利 /害攸关的人往往能做出更好的判断• 观点 2：体贴入微的代码 /文档，产生于服务和反馈的过程，而不是管理要求下的产物

• 合理规划和协同至关重要

高效协作环境的要素• 便捷的学习环境• 专业知识 /经验使沟通更高效；而学习是一个累积的过程• 通畅的信息基础• 工作决策所需的信息容易获取，从相关人或文档 /代码中• 支持性流程 /工具• 在支持各个不同具体事务的同时，达到规范 /约束的目的• 好的计划和协调• 让人清楚正在为什么而努力，并知晓不同行动的后果• 开放而勤奋的人

基础建议• 在线代码托管• 整合的知识 /内容• 便携的开发环境• 想法 /方案交流区• 责任单元• 活动记录

在线代码托管代码即文档，在代码容易获取和浏览时才更有价值

• 参照 github，集中托管的在线代码可以带来 :

• 代码 /项目的容易发现和学习• 简单公开的开发 /讨论协作• 自包含的说明文档和编译脚本• 整合服务的状态信息，等等

• 主要工具： github 或 gitlab 或 gogs, 等等

整合的知识 /内容知识系统不应满足于文章的简单分类和编辑 /共享

• 而应该更进一步，• 多层次组织，不同角度可以获得不同的收获• 联结 /整合，容易发现相关内容，出现在被需要的地方• 容易创建，跟随需要和反馈而调整

• 形成一个有机联结、完整生产 /消费的整体• 主要工具： Confluence

便携的开发环境只需一两条命令就可以完成本地开发环境的搭建

• 需要一些基础服务的支持：• 发布仓库，解决代码依赖• 可迁移的运行环境• 容易传送 /恢复的数据

• 无须赘言，便携的开发环境能让开发大幅增速

• 主要工具： Docker, Vagrant

想法 /方案交流区初衷是作为效率改进的一个交流 /协作平台

• 动态收集、公布亟待解决的问题• 公开讨论影响范围、解决思路 /方案及安排• 链接到相关的人、项目• 进度更新和通告

• 注：这可能会成为检验企业内部开放程度的晴雨表

• 主要工具： BBS 或 Confluence 上一个空间

责任单元把一个组件 /工具有关的开发、维护、支持等完整的职责打包成责任单元

• 自主发展直接支持 /自助等不同服务方式• 自主选择邮件 /论坛 /现场参与等不同反馈方式• 自主决定重大升级的方案选择和开发计划• 用户也可以开发工具，自主管理，等等

• 责任单元足够小，使得一个或少数几个人就能管理

• 主要工具：独立小项目、专业细分领域，等等

活动记录对工作相关的活动和贡献作记录

• 代码提交• 建议 /讨论• 文档 /反馈，等等

• 这些记录可用于事后检查、统计和评估

• 实现工具： SCM、 JIRA、 Confluence 等的日志 /活动记录功能

实施考虑• 社区驱动• 公开征集、讨论和更新• 开放协作，汲取众人才智和开发力量• 众人参与，接纳、反馈和推广• 简单 /高效 /兼容• 简单，才容易吸引用户和贡献者• 高效，既然它是提高其他协作效率的基础• 兼容，尊重现有习惯和基础，重用或邀请建设新的

• 搭建平台容易，难的是运转和保持活力

问题 /案例• 基于内容的交流 vs. 基于话题的交流• 直接沟通• 自助模式• 完整的任务• 人员自由流动• 多角度 /并行• 以客户为中心• 项目管理的核心价值• 学习型组织• 技术氛围• 绩效评估

基于内容的交流 vs. 基于话题的交流

问题 1,2,3

回答 1

回答 2

回答 3

> 很明显，两种方式各有所长：“ “ “ “基于内容的交流 挺适合细节交流，直接、灵活； 基于话题的交流 很适合想法 /方案交流，抽象、综合。（ p.s. 异步方式不见得慢，因为并行。）

直接沟通

“ ”多数管理者不会反对 直接沟通 。但有多少能坦然下属很多事情上直接沟通、自主决策呢？

● 坦然，往往来源于：● 对计划 /要点的把握● 对下属能力 /习性的了解● 对风险 /差异的宽容

● 协作基础不解决上述问题，但在便利直接沟通的同时，也支持回溯，方便事后检查

自助模式

需求 /协作有不同层次，简单 /基本的应该通过自助方式就能满足 /做到

• 这意味着：• 项目 /模块，有使用说明，能自动构建• 任务，有背景说明，和相关文档、资料链接• 性能、安全等专业测试也能有一些自助工具，等等

• 协作基础的项目托管、内容组织、资源发现等功能为此提供支持

完整的任务

项目管理最扯的事情之一，就是把任务不同方面分给不同的人，把小事变成要复杂协调的大事。

● 应交给一个人来做，给他所需的各种支持● 如果确实太大，可以安排几人一起做；也可以分期做

● 协作基础不划分指派任务，但可以提供工具 /文档 /人员指导等多方面的支持

● 注：结构优良的代码、体贴明了的文档就是很好的支持

人员自由流动

管理糟糕的项目从不介意增派人手。在一些人眼里，软件研发可能跟搬砖一样。

● 项目新增成员总会带来一定的重新调整和适应，最终产出未必大于投入

● 协作基础通过简化语境组织和传递、环境搭建等，可以帮助新人快速融入

● 协作基础也可以帮助发现新价值点，在不同领域做出贡献，这是另一种形式的人员流动

多角度 /并行

… 我们都工作在一个无边界的产品当中 这一事实让我们可以多角度 /并行的方式做一些事情

• 需求提出 - 厘定、设计、实现方案• 代码提交 - 代码审查、日志、数据收集• 功能测试 - 性能、安全，等等

• 协作基础对此提供支持

以客户为中心

这里主要关注的其实是企业内部客户

• 除了观念，也要有相应的支持：• 需求 /场景的完整传递• 内部支持环境• 直接沟通的渠道，等等

• 协作基础对此提供全方位的支持

项目管理的核心价值

项目管理让项目明了可控，其核心价值有：

• 方案 / 计划 - 使项目开展有一个框架和基准• 协调 / 沟通 - 确保各方有合理的预期，协作顺畅• 判断 / 节奏 - 确保在模糊 /意外的情况下也能有序推进

• 协作基础使项目管理更轻松，让富有能力的一线员工也能有精力管理项目

学习型组织

协作基础为这个目标提供了很多支持：

> 学习环境方面• 内容 / 材料 – 联结 /整合，让发现和深入更容易• 支持 / 帮助 – 尽力做到触手可及

> 学习动力方面• 成长机会 – 让机会发现和贡献更容易• 薪资收入，这不是它能决定的

技术氛围

企业都渴求锐意进取 /不断创新的技术氛围

• 营造这样的氛围常常需要：• 技术大牛• 结果导向• 挑战性问题• 尊重 /激励

• 协作基础不教导怎样尊重人、招纳技术大牛• 但它让发现有价值的问题、做出贡献更容易，并使成果迅速得到应用和传播

绩效评估

脱离工作记录的绩效评估最后都归结 “ ”为 态度

• 基于实际工作记录，让我们这样提问：• 有没有让你眼睛一亮的东西• 这人算不算勤奋高产• 你的评价，参照，等等

• 观点：态度固然重要，但成果是更好的表达

• 协作基础收集的工作记录可以让绩效评估更客观

结语方案设计最有意思的莫过于，不同的人追求各自的小目标，却共同达成了更大的目标

• 上述问题 /案例想必很多人都在不同方面 /程度有兴趣• 当我们有想法有能力，又能够协同 /自主的解决各自的问题的时候，这种能量是巨大的

• 而我的推进策略是：某一部分如果有人领头，我配合 /支持；如果其他人观望，那就我来主导

• 对于这样的计划，我的作用不仅仅是规划 /部署，更重要的是可以驱动 /注入灵魂

谢谢 !

进一步了解我：• LinkedIn: https://cn.linkedin.com/in/tminglei• GitHub: https://github.com/tminglei• 豆瓣 : http://www.douban.com/people/tomleetml/