Table of Contents generated with DocToc
写在前面的话：
接下来我要说的这些话可能都是扯淡。毕竟，没有很好的实践过的方法论≈扯淡
虽然我并不能算是有过领导开发团队的经验，也不敢自称是一名优秀的工程师。但身为一个向往极客、支持开源和信息共享的开发者，自己对于工作环境和团队建设还是有一些看法，更不用说向往着一个极客范的团队了。本文有感而发自《极客与团队》，顺便就几点附上个人见解。
一个好的开发团队其内部信息应该是完全透明的。这不仅意味着前后端工程师要知道对方做了什么，意味着看见shit一样的代码时应该以恰当方式提出并改进，也意味着全员都知道产品的走向和需求。
或许对于一个普通的开发而言，他自身并不想过多参与到产品的走向和决策过程。毕竟，“上班不要跟我谈理想，我的理想就是不上班”嘛。但是对于一个积极的、海盗式的团队而言，我不觉得有任何的益处。而一个想要成为优秀团队的团队里有那样的人，我想，管理者们也可以好好思考一下“劣币逐良币”这句话。
高信息透明度意味着大量的沟通，但绝不提倡频繁或冗长的会议。会议是扼杀创造的摇篮。如何在沟通时间和信息传达量上寻找一个微妙的平衡点，是一个值得研究的问题。
- 站会：估计是敏捷开发时最爱的会议了吧。团队聚集在一起快速交流，整体时间维持在十分钟左右。大家相互了解对方做了什么要做什么，同时也简要说下自己的情况，有任何问题，都放在会后私下沟通。
- 团队规划：团队规划通常有两种选择
- 开发团队/产品团队/设计团队三个大团队，共同负责某个产品的开发。而在会议时，会由各个团队的负责人碰面开会，之后由负责人向各团队组员传达信息。（不推荐）
- 开发团队/产品团队/设计团队各个团队分别抽出一两个人（建议不超过两人），组成多个小型团队，每个小团队负责某个功能点的开发。（推荐）
- 工作法：
撇开站会不说，先谈下团队规划。我个人更加偏好于第二种，即抽出各团队人员组成小型团队的方法。因为它保障了团队的敏捷性，并借助于人数少的优点，降低了沟通成本，减少了信息在传递过程中的扭曲率。而 Scrum 和看板两种工作法都很好，他们完全可以搭配在一起使用。比如这篇文章：《Scrum vs. 看板，还是Scrum + 看板？》，就很好的融合了两者的优点。况且 Scrum 工作法本身要求的就是“不大于10人的小型团队”。
团队需要在保存自我的前提下不断引入新鲜血液。有时候会由新人带来，有时候则是新技术。一个开放的环境极其重要的。如果可以的话，为什么不花一小部分时间研究一下新技术/新框架/新插件，或者自己造一个轮子呢？
我们在开发过程中，选择的插件或者框架必然是由真实的需求所决定的。但当某些现成的方案有缺陷，不能很好的达到自己想要的目标时，如果没有造过轮子，不了解其具体实现，很容易就会懵逼吧。所以，不仅仅是要知道在什么需求时用什么解决，多少也要了解其内部实现吧。鼓励团队创新，鼓励尝试新技术，鼓励踩坑。
对于管理者而言，冒险意味着放手管理，让工程师参与到项目走向/设计等“非专业领域”；而对于工程师而言，冒险意味着做自己认为正确的事情。产品的需求和设计或许有80%都是错的，而毕竟有时候，工程师是面向用户的第一道也是最后一道防线。
如果工程师缺乏思考，那就相当于把赌注全部压在了产品/设计身上。但这部分群体却往往不是直接接触用户的。你可能会说：“你在逗我？产品经理还不够接触用户？”，但别忘了，他们接触的用户，很大一部分要么是已经使用了线上产品的用户，要么是提出很多需求的用户（而他们的需求有可能80%都是无用的）。而只有工程师，尤其是前端工程师（还包括了iOS/Android端工程师），在进行开发的时候，会一遍一遍又一遍的调试产品。这种时候，开发人员完全可以充当一个小白用户啊！完全可以在开发过程中以一个用户的角度去思考产品设计、交互是否合理。
所以要时刻提醒的是，一个开发团队，远不止仅负责“最终实现”这么简单。他们是产品上线前的第一道防线，一个思考的机会，更是在上线后处于首当其冲的地位。
产品 -- 设计 -- 开发，这是一种传统的工作流。在这种工作方式下，工程师只要按需完成任务就行了。不能说这种方式有什么不好 -- 相反的，这应该算是产品开发最佳实践之一了 -- 但是，对 geek 而言，这是不是太无趣了一点？这一点和上一节的“冒险”相呼应。如果仅仅是单纯的开发，不仅无趣，而且危险。它会让你丧失一道防线，会慢慢的驱逐团队内优秀的工程师。
项目的方向是什么？我们最终是为了创造什么而开发什么？有多少用户在使用它？产品最终又给用户带来了什么价值？不知道这些的工程师们又怎能开发出优秀的产品呢？
Deadline不是万能的，没有Deadline是万万不能的。Deadline是工程师的天敌，而根据人月神话，软件开发的时间更是随着工程师人数的增加而指数式增加。要避免人数臃肿，最大化利用每个人的能力。
工程师需要知道他们开发出的产品到底在市场里获得了怎样的反馈。一个赞扬也至关重要。除非工程师对自己做出的东西没有感情，不在乎它的存亡，否则的话，自己亲手开发出的产品应该像亲儿子一般的呵护。我最讨厌的就是仅仅让工程师按需完成任务，而完成之后，有bug就疯狂的找工程师们维修，除此以外也没有其他反馈。拜托，不要把工程师们当做木头人啊。
很多创业型公司都会周期性规划复数个开发任务，以此不断的进行产品迭代。譬如说规划一周内15个任务。而一个糟糕的例子则是，当工程师高效工作提早完成任务之后，被认为偷懒或者任务安排的太少 -- 即便是后者，这也是管理者的错误 -- 在这之后作为“弥补”，给予了工程师更多的工作。而这种方式只会让他们的效率越来越低。
传统的条条框框，从来都不是一个培育优秀团队的良好环境，而是低效的温床。我不认为传统的打卡制和绩效制对优秀的开发团队会有太大的正面促进作用，反之，给人以束缚感，甚至可能降低团队工作效率。因此，我完全无法理解鼓励加班甚至影响要求加班的团队。身为开发者，如果真的热爱这个团队，热爱自己做的产品，对自己开发出的产品有自豪感的时候，是不需要有什么硬性要求的。
讲到这儿，我想起一个以前看到过的某一家公司制作的专门招聘工程师的宣传视频，大致内容如下：我（视频是第一人称视角）是个程序员，为了生计辛勤劳作，也换过好几家公司，但在每家公司都要加班到很晚很晚，陪伴自己的只有桌边恋人送的礼物和深夜的篮球直播。但到了这家公司（制作该招聘视频的公司），我依旧要加班，但加班到深夜时抬头一看嗬！同事们都洋溢着热情的笑脸围在我身边呢！从此以后我加班不在孤独了（此时放出画外音：我们陪你在一起！）
What the f**k!!!! Seriously??? 可惜我忘了视频在哪儿看的了不然一定放出链接。真的想知道贵司最后找到开发了吗？贵司听说过工程师文化吗？贵司尊重员工的个人权益吗？贵司。。还没倒闭吗？
我想说明的，就是上面说表述过的：身为开发者，如果真的热爱这个团队，热爱自己做的产品，对自己开发出的产品有自豪感的时候，是不需要有什么硬性要求的。
关于加班，你还可以再去看看这篇文章：加班与效率
其实说了这些，无非只有几点：
- 保持团队简洁，高效沟通，高透明度
- 给予工程师信任和自由
- 团队内所有人都能参与到产品走向和决策
- 尊重工程师文化
- 保持反馈
能做到这些很不容易。它不仅仅依赖于公司文化，更依靠个人素养和追求。但无论如何，我们都不应该降低标准。不降低招人的标准，亦不降低自我要求的标准。
最后，《极客与团队》是本好书。内容不多，身为工程师，无论是否是团队领导者，都应该去看一看。