Skip to content

Update why_documentation.md #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update why_documentation.md #3

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 5 additions & 55 deletions 2016/11/why_documentation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,13 +12,7 @@

这个阶段，Paddle Team大概也就只有3-4人。整体的工作流程大约是这样子的。

![small team](http://g.gravizo.com/g?
graph G {
A -- B
A -- C
A -- D
}
)
![small team](http://g.gravizo.com/g?%20graph%20G%20{%20A%20--%20B%20A%20--%20C%20A%20--%20D%20})

这个阶段我们Paddle主要是一些维护工作，和follow新的论文，新的进展。有一个主要的leader A，然后这个A通知大家我们下一步要做什么，什么是有意义的。然后每一个人只和A讨论我们的工作进展，工作内容等等。

Expand All @@ -30,18 +24,7 @@

之前和一些其他部门的同事聊天，大家基本上说，团队到了7-8人就到头了。因为最后新加入的人沟通成本太高，我们根本没办法把精力放到工作上。白天上班开会，晚上加班回家写代码的惨剧就发生了。为什么会这个样子呢？因为我们的沟通模式没有变化。

![middle team](http://g.gravizo.com/g?
graph G {
A -- B
A -- C
A -- D
A -- E
A -- F
A -- G
A -- H
A -- I
}
)
![middle team](http://g.gravizo.com/g?%20graph%20G%20{%20A%20--%20B%20A%20--%20C%20A%20--%20D%20A%20--%20E%20A%20--%20F%20A%20--%20G%20A%20--%20H%20A%20--%20I%20})

如上图所示，Leader还是A，每个team member的沟通时间我们还是认为每天一个小时。那么Leader A每天要花8个小时沟通。如果按照每天工作时间8小时来算，A的工作就完事了。这是简单算数，但是实际情况会更加悲惨。

Expand All @@ -53,42 +36,15 @@ A同学也是一个热爱编程的同事，常年累月的沟通让他心情非

但是对于我们，本身上是开发分布式机器学习系统的人，沟通为什么要这么**集中式**呢？所以我们开始玩起了自组织(P2P)的团队沟通。也就是每个人为每个人自己的工作负责，每个人每周和大家汇报一下进展就好了。当然，自组织的时候，我们之间也是有合作的。但是可以是小范围的合作。那么我们的沟通关系就变成了这样。

![middle team 2](http://g.gravizo.com/g?
graph G {
A -- B
A -- C
D -- E
D -- F
G -- H
H -- I
I -- G
}
)
![middle team 2](http://g.gravizo.com/g?%20graph%20G%20{%20A%20--%20B%20A%20--%20C%20D%20--%20E%20D%20--%20F%20G%20--%20H%20H%20--%20I%20I%20--%20G%20})

我们变成了一个一个的小团体，每个小团体之间沟通比较多，然后大家还是为了项目的一个主线来努力。这一阶段又变得比较稳定了。一来是，没有了特别强力的Leader A作为单点，所以就不会有单点依赖。二来是，整体团队的沟通成本变小了，我们的沟通也方便了。有什么事情，只要和大家说一声，这个事我做了，大家也都没意见，我们就可以接着往下做下去了。

### 中型团队的沟通问题

之前的中型团队沟通我们已经解决了。但是，其实那个沟通方式有一个根本性的问题，就是虽然沟通成本下来了，大家可以专心工作。但是，新人非常难以融入。因为随着沟通的深入，几个熟悉的人之间必然有着一定的默契，做的事情也必然有一定因果关系。这就导致了，A不理解H在做什么，H也不知道A为什么要这么做。

![middle team 2](http://g.gravizo.com/g?
graph G {
subgraph cluster_a {
A -- B
A -- C
}
subgraph cluster_b {
D -- E
D -- F
}
subgraph cluster_c {
G -- H
H -- I
I -- G
}
J [label="新人J"]
}
)
![middle team 2](http://g.gravizo.com/g?%20graph%20G%20{%20subgraph%20cluster_a%20{%20A%20--%20B%20A%20--%20C%20}%20subgraph%20cluster_b%20{%20D%20--%20E%20D%20--%20F%20}%20subgraph%20cluster_c%20{%20G%20--%20H%20H%20--%20I%20I%20--%20G%20}%20J%20[label=%22%E6%96%B0%E4%BA%BAJ%22]%20})

如上图所示，"新人J" 很难融入这个团队。因为大家已经有了固有的习惯。

Expand All @@ -107,13 +63,7 @@ A同学也是一个热爱编程的同事，常年累月的沟通让他心情非

所以，其实文档就是我们的中间层。如果我们把大型团队的所有沟通，比如我想如何做这个事情，这个事情我有什么困难了，全公开的放到一个文档中，我们其实就只用和"文档"沟通工作了。

![large team](http://g.gravizo.com/g?
graph G {
doc [shape=box, label="team 文档"]
doc -- A [label="我要怎么做系统A"]
doc -- B [label="系统A的工作我也有一些看法"]
}
)
![large team](http://g.gravizo.com/g?%20graph%20G%20{%20doc%20[shape=box,%20label=%22team%20%E6%96%87%E6%A1%A3%22]%20doc%20--%20A%20[label=%22%E6%88%91%E8%A6%81%E6%80%8E%E4%B9%88%E5%81%9A%E7%B3%BB%E7%BB%9FA%22]%20doc%20--%20B%20[label=%22%E7%B3%BB%E7%BB%9FA%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%88%91%E4%B9%9F%E6%9C%89%E4%B8%80%E4%BA%9B%E7%9C%8B%E6%B3%95%22]%20})

这样，我们把讨论的过程放到了文档中，这个好处是\:
* 解耦合大家的时间\: 从SGD到AsyncSGD。我和别人沟通的时间，可以由我自己来掌控了。并不需要谁谁谁一句话，我就要和他聊。谁谁谁另一句话，我就要和另一个人聊。
Expand Down