可以了解一下业界领先公司的做法
2014-08-08
Facebook已经被国内外很多人多次解读过了，不过作者作为亲历者介绍他所经历的Facebook，内容更显得丰满充实。不过也正因为已经被多次解读，而且Facebook的很多做法本来就很贴近敏捷方式，所以里面很多知识让我觉得“果然Facebook是这样做的”，但也从作者的经历里学到了很多新东西。
Facebook产品开发的三个准则：
1，迅速发布，再进行监测（Move Fast and Monitor Closely）
* 刚开始有Break Things，后来去掉了，因为人多出错太多
* 灰度发布：先开发给部分用户，效果好的话再提高开放比例
2，坦然对待不确定性（Be Comfortable with Uncertainty）
* 代码胜于雄辩（Code Wins Arguments）
3，不追求极致，应该不断地发布以达到目标（Done is Better than Perfect, Stay Focused and Keep Shipping）
把最重要的目标及相关的任务、目标日期、负责人等信息，写到白板上，挂在离我们最近的墙上。
[XY] 可视化，在敏捷中应用很广泛的。
Hack-A-Month：允许工程师可以参与另外一个组的项目，工作一个月。
作者总结了他在一对一交流（Inquiry Based Dialogue；Give Pointers）时的经验，会谈关注面引导：
1，工作开不开心（happiness）
2，效率高不高（productivity）
3，工作的影响大不大（impact）
4，当前的工作有没有提供学习成长的机会（growth opportunity）
建设性讨论
1，提出建议（statement of suggestion）
2，给出具体实例（evidence）
3，讨论利弊（impact）
4，形成共识，得到行动方案（action）
时间分配的“6-2-2”原则
* 60%左右：能够预期的工作
* 20%：后台架构和产品质量（出过很多问题，所以才去掉了break things）
* 20%：比较有风险、有争议的、可能会带来某种颠覆性的后果的那些想法上
产品设计的基本理念
1，不要过度设计（Don't Over-Design）
2，产品越简单越好，但并不意味着简陋（Be as Simple as Possible, but not Simpler）
3，对于自己做出来的产品，你必须是它的用户（Be Your Own Customer）
4，产品要确实有用，主要流程尽可能顺畅（It Should Just Work）
5，不追求完美（Don't Chase Perfection）
6，保留最基本的质量底线（Keep Minimal Quality Bar）
关于意见反馈：我们感知的即是事实（What People Perceive is What They Believe）
* 不见得都是负面的
* 必须摆事实、讲道理
* 必须是可操作的
硅谷的技术公司尝试用产品、理念、理想，以及期权、薪酬、福利等财务激励体系等，通过这一整套东西，来吸引员工自然形成对公司的忠诚度，而不是只说爱国主义式的大道理。
Facebook希望新员工能够自己去思考遇到的问题，然后找出解决方法。当然，也要学会适当寻找别人的帮助。当别人知道你做过功课的时候，会更加愿意帮助你。不懂就问，而不是自己先钻研的人，在Facebook不受欢迎。
[XY] 在国内太缺少这种精神了，到处都是自己不做任何探索就直接希望别人给答案的人。回答者的时间和意愿是一回事，但从提问者的角度来说，也没有好处，错过了自我学习的机会。
在Facebook，很常见的情形是，工程师会花很多时间去思考产品为什么要这样做，既有20%~30%产品经理的心血，又有工程师的能力，可以用代码将想法实现，这种人最适合做产品工程师。
在Facebook，产品工程师跟产品经理影响力的比重可能是60：40，而在后台系统方面，除非是直接关系到前台系统，两者的比重几乎达到100：0。
决定产品方向时，要的是想象力、激情和胆量，而不是数据。数据能让你的团队沿着正确的方向前进而不出轨，也有助于产品从“一开始是什么样”到“最后应该是什么样”的逐渐优化成型，但数据不能帮你决定方向，尤其是产品的初期方向。
Facebook有两个工具组。一个叫研发工具组（Dev Tools），专门负责研发工具的开发和维护，包括所有有助于工程师开发速度和质量的工具，主要服务对象是内部工程师。另外一个叫网站支持和工具组（Site Support and Tools），主要负责公司里所有通用工具的开发和维护，关注的主要是如何方便用户和Facebook的交流以及Facebook内部的沟通，主要都是通信工具，服务对象是用户和所有员工。
这些工具的基本理念就是，凡是被很多人不断重复的好习惯，要将其自动化，绑定到工具之中。以“Don't Make Me Think”（别让我多想）的方式来推广好习惯。
公司的工作效率，影响到你需要雇佣的员工数，影响到公司的成本究竟是多少，并将直接影响到公司内部产品的独创性。工具团队不应该是一个由二线员工组成的“事后诸葛亮”的后勤部门，公司里最有才华的工程师应该用公司自己的工具来工作，并且企业文化里要优先反映这些。
（工具团队招聘新员工）一种方式是用一些通过提高效率的具体案例和数据来做理性说服，这需要在开发工具的同时检测工具使用前后的效率变化。……如果真正做到如此重视，最优秀的工程师是愿意加入工具团队的，这样可以大大提升同事们的效率，从而更能够好地服务于用户，这也是一种外部用户所感受不到的成就感。
领导者最重要的事情就是去帮助员工发掘自己的长处，并尽可能创造机会让他们去发挥自己的长处。通过不断的激励和帮助员工，让他们挑战自己，做出比自己想象的更好的成就。
[XY] 这正是教练型经理、服务型领导的方向，我一直认为领导者就是要去支持属下充分发挥作用的，而不是去发号施令。
根据Albert Mehrabian（http://en.wikipedia.org/wiki/Albert_Mehrabian）关于信息交流的研究，在面对面的谈话中，言语内容传达的信息对于个体态度的影响只有很可怜的7%，语调传达达到55%，形体和表情语言达到38%。
Facebook的理念是升职到一个职位前，必须已经在这个新的职位上顺畅地运作了3~6个月，所以是行事在前、升职在后。
[XY] 这种做法太棒了！我觉得这样不至于让升迁这个梯子变成一场赌博，连老板也不知道升上去的这个人是否真的完全合适。我记得刚工作时台湾老板的一句话，他说“很多人跟我说提拔我做经理吧，我一定能做好的。可我怎么知道他行不行呢？真正的是你已经在现职体现出了胜任更高级职位的能力，提拔你是顺其自然的事。”
作者用马后炮的方式来思考自己在Facebook做产品、项目的实践中可能出现的步骤。所谓的“流程”，在Facebook内部并不存在，上述步骤并不都是必须的。需要根据自身情况，借鉴使用。
1，描绘远景，设置目标
2，收集想法并排出优先次序
3，跨团队沟通
4，告知所有可能关心的人
5，设计产品
6，指定项目责任人
7，定期碰头会（Scrum） # 估计作者的意思是Daily Scrum
8，了解进度，汇总报告
9，发布产品，监测数据
我们会在一个wiki工具上公布并进行项目管理，有时候也使用google的spreadsheet来进行项目管理。这里没有使用专业的工具，对这部分的要求只是：1）公开，容易分享；2）大家都能修改。
[XY] 记得曾经跟项目管理一批人进行的争论，我强烈地认为应该公开所有项目信息让所有人都知道，并参与贡献到项目管理活动中来，而很多人却支持只有项目经理知道所有信息。这里看来，至少Facebook的做法是站在我这边的。
反应项目状态的信息非常简单，如下：
项目X （Alex + Sridhar）
【未完成】增加决策树模型并发布该模型（Alex）
【未完成】修复关于属性X的bug#123 （Sridhar P）
[XY] 书中有个图，展示了Facebook团队在他们的Sprint任务板上用一个温度计的图示来表示他们的目标完成进度，挺棒的。
跨团队沟通，就是让相关组之间做的事情是相辅相成的，而不是互相扯皮，造成不必要的内耗。一类是不同职能之间的沟通，包括工程师、产品经理、设计师，还有你的项目相关的上下游团队或部门。另外一类是相关的工程兄弟组之间的沟通。
我们会召开一次最终的计划定夺会议。主要是由工程师和产品经理及一些非常相关的人参加，这种会议是小规模的。其他人的声音已经在之前的夸团队沟通过程中被充分地考虑了。如果前面准备工作做得好，这种会议速度都很快，一般半个小时左右。
整个计划定下来之后，我会发一封邮件给所有关心该计划的人和相关工作的人。我很清楚，并不是所有的人都会真去看这封邮件，但我给了他们一个参与的机会去了解“这个组究竟在做些什么工作”。换句话说，这个计划给了大家讨论我们组相关业务问题的一个基础。
对于任何一个项目，具体执行中一般都涉及四个维度：有哪些功能（Feature Set）、预期完成时间（Time to Market）、预算（Budget）、完成质量（Quality）。如果你的进度落后了，你可以去掉或精简一个功能，或者推后完成的时间，或者增加人手、加大投入，或者降低质量等，无非就是在这四个方面进行取舍。
[XY] 作为测试出身的人，我还是很遗憾看到作者将“降低质量”列为一种取舍方向的……
何种状况下才提高灰度发布的范围呢？只有通过数据监测来判断发布状态。需要监测的有两类数据。一类数据反映当前的系统状态，比如访问总量、访问成功量及其占总量的比例、致命范围错误的量和比例、访问速度、出现最多的错误类型统计，等等。另外一类数据反映新功能的用户影响（User Impact或者Business Insight），只有这部分的反馈数据是正向的，而且其变化达到了让人接受的程度，才可以考虑扩大发布范围。
所谓Post-mortem，就是通过分析过去发生的问题，从中总结可以采取的行动方案，以避免类似的错误再次发生。Post-mortem会涉及以下几个方面：1，发生了什么？2，影响多大？3，问题的原因是什么？4，事件发生的具体时间表；5，如何避免将来犯类似错误的行动方案。
[XY] post-mortem好像就是复盘的意思。我感觉这跟敏捷里常做的回顾（retrospective）很像，post-mortem主要是针对项目进行回顾，而且貌似主要专注于做错的部分。
业绩评价虽然跟薪酬挂钩，但薪酬奖励毕竟不是目的，而是能够反映员工贡献的手段，激励员工更好地为公司做贡献。所以，指出员工哪些地方可以做得更好，才能真正帮助员工成长，最终为公司带来好处。
[XY] 传统的绩效考核太过于注重在“考核”，而忽视了通过提供反馈帮助员工持续改进的作用。至少这里Facebook做出了一个不错的榜样。
员工的精力有限，你列出太多需要改进的带你，他很可能也做不好，没有实际意义。不如每次都让他关注在少数几个点上努力改进，对他的帮助会更有效。
[XY] 很多团队刚开始做回顾的时候，列出10几20条改进措施（action），我都会枪毙它们，要求只选出1条最重要的（基本上都是2~4周的Sprint）。
对于评级，不同的组之间还要进行校正（Cross Calibration），以防止各组的评价标准不一致。包括跟纵向的组进行评级校正，和跟横向相关的组进行校正。大家坐在一起探讨各自的评价标准，尤其是两头的极端评级要重点分析。
==========
徐毅：独立敏捷顾问，经验丰富的国内知名敏捷及精益教练，专注于敏捷软件开发、Scrum、敏捷转型、敏捷测试、测试自动化、robotframework等。
查字典图书网
