《解构微信》为系列文章。作者深入微信团队，围绕微信产品诞生与继续完善，从产品开发、团队工作、品牌推广、流程等方面进行深入研究，干货较多。点击可查《解构微信（一）》和《解构微信（二）》，分别讲述了微信诞生、发展以及团队。
敏捷开发
敏捷是一种态度，试错是一种信仰。——微信团队Harvey
敏捷开发是一种常用的软件开发模式，与传统的“瀑布式开发”相比，敏捷开发能够持续满足不断变化的需求变动。微信团队的情况正是这样，“整个开发过程中产品会不断修改，这是我们的特色。”Harvey说，“哪怕在发布前的十分钟，我们也要允许产品决策者提出变更。”“为了给产品决策者提供最大的自由度，敏捷原则成为整个开发流程的指导原则，”“极度敏捷”也成为技术团队乃至整个微信团队的追求。
微信团队的开发流程同样包含瀑布式开发中的主要步骤，“决策——需求评审——细化产品设计——交互设计——开发——迭代——灰度发布——测试——上线运营”，“但是这个过程我们（微信团队）是并发来做的，”Justin说。同时，整个开发过程中充满了由需求变动驱动的“微循环”。
在每一个“微循环”的起点——需求提出环节，产品经理、交互团队和技术团队的同事会一起，对平时收集到的用户需求和意见进行讨论。微信客户端UI组组长Kink认为，“如果只是产品经理闭门想产品，其实是不大好的；可能产品经理提出的需求在交互设计层面并不是最终需求，只是一个表面现象，用户需求需要更深层的挖掘；而从开发的角度看可能有简洁的方式来达到目的，但表现为不同的形式。
“通过三个团队的成员共同讨论确定下来的产品方向，他认为往往‘更靠谱’而且降低了项目夭折的可能性。接下来，由于交互团队、技术团队都参与到需求的生产环节中，对产品的大致形态比较清楚，交互、技术这两个团队的工作就可以和产品团队的工作并行开展。Kink说：“大家都明白产品是什么样的，就可以同步开始了，交互可以做交互方案，视觉可以选定方向，开发同事可以做代码设计。等交互方案出来，视觉设计师可以马上根据交互方案实现，开发同事一看到交互方案就可以开始写代码了。”
在项目推进的过程中仍会发现各种问题，这时三个团队的负责人会再次碰头对问题进行讨论，如果问题不大，这种小规模的讨论就可以当时解决；如果发现有比较严重的问题，团队成员会花更多的时间讨论当初的设计是否存在缺陷，这种讨论Allen、Harvey也会参与进来。如果确定问题在于原本的需求设计不合理，那么新一轮的“微循环”又会启动。
整个微信团队都在南方通信大厦的10楼，这使得团队成员之间的面对面交流十分方便。“面对面交流”既是敏捷开发倡导的原则，也是团队从邮箱时代积累的经验。Kink认为：“无障碍沟通有助于敏捷的实现，大家不管什么时候什么地方碰到面就聊：这边有什么困难，那个需求的时间点，设计上有什么能改善的……很多问题是在茶水间里一次三五分钟的讨论中解决的。”Lake对此的评价是：
1小时说的话，打出来要10小时，而且面对面沟通可以快速反应，有什么问题大家直接就可以讨论了。如果有面对面沟通的条件尽量用这种方式，但不是那种冗长的会议形式。在座位旁边两三个人五到十分钟的交流，然后快速散开，就一个问题迅速进行讨论，得出结论，散开，这是我们的工作生活，这个是必须的。
在敏捷开发中，需求的快速变动要求开发团队不断修改甚至是重写代码，这给开发团队带来了巨大的困难和压力。为了预防和缓解这个问题，微信团队在基本技术架构中确立了“大系统小做”、“让一切可扩展”、“必须有基础组件”等几个原则。技术团队认为这样的技术构架能保证“产品层面的改动对技术层的影响不会太大”，为技术团队适应敏捷提供基本能力。Justin回顾朋友圈的开发过程时说：
比如朋友圈这个产品经历了很多次变动，出了好几十个版本，但是有东西是不变的，就是数据模型是不变的。所以我们在产品设计和细节还没出来的时候，我们从后台到协议设计到本地存储的整个数据结构设计都已经做好了，界面的框架也可以先做，等设计最终确定的时候，我们技术这边已经进入ready的阶段。这是我们和别人不同的地方。
敏捷开发离不开技术团队的支持。对于产品团队提出的方案，技术团队很少以“技术上实现不了”为理由拒绝，Harvey把这个视为技术团队的“技术信仰”。从用户使用体验的角度思考问题，而不是从技术实现难易程度和开发量的角度思考，这是微信技术团队的特点。Justin认为，Allen对于技术团队的高要求是催生这种氛围一个原因：
在我们这个团队中，从Allen的要求来说就是“没有技术实现不了的”。他基本上是这么认为的，比如你和他说这样不行，他会坚持第二次第三次，最后很可能就可以了，那么后来团队就养成习惯了，技术团队不会轻易对一个功能能否实现做判断。
有不少用户对微信的评价都是“快速流畅”，“微信上传速度很快，没有等待的感觉。”“微信的翻页很流畅，手指向上拉动就可以很快的翻到前面的对话。”不过为了实现这种快速流畅的用户体验微信技术团队做了很多努力，以翻页这个操作为例，Lake介绍说：
翻页也有不同形式，做粗糙的话可能要等1秒钟，会停顿一下，这是不好的。我们希望虽然翻的时候有一屏一屏的概念，但是只有一瞬而过的loading过程，但翻的速度快到让你感受不到分页的存在，知道但是不需要等待——这都是很微妙的东西，这就是细节。但为了实现这一点很难，因为一个会话有几千条消息的时候，必然会影响速度。cpu需要计算，技术人员需要对技术有深入理解，要用什么样的技术保证功能的实现，而且翻页的动作每天都会发生，是一个非常重要的体验。无论如何要保证。
Allen认为，这种挑战可以带给技术团队更大的成就感和更快的成长：
我更多知道他们需要的荣耀感是什么。对于一个技术人员来说，他有事情可以作出来，并且做得很好，远远比他没有任何事情可做，然后每天平平淡淡的混一天日子，其实他并不希望混日子，他希望做出一个庞大的系统，并且是很好的系统，通过产品来验证他。
我们这里好多技术人员其实骨干是毕业生，他们进来以后，我们发现他们成长最快，成就感也最大，并且他们应该会很感谢说有机会参与到微信这样一个项目里面。
对一个技术人员来说，做一个后台系统，做一个前端的开发，能够在短短一年多里面从零搭建一个系统，服务一亿用户，这是非常大跨越了，或者说成就感也好，对自己的锻炼也好。
流程管理
微信发展初期，团队的流程管理和文档管理都处于不严谨的状态，“常常是为了快速，三个人站在那里讨论，但没有落实成文档，三个人自己都知道，是靠三个人的记忆去做。”Kink回忆说。随着微信形态和功能的复杂化，团队成员发现团队项目进度管理的问题逐步暴露了出来，“当我们一次讨论10个点的时候，就会忘记1个点；讨论到四、五十个点的时候，就会忘记十几个点。这时候我们就发觉又要保持敏捷，又要在敏捷之后去用文档或各种方式来保持信息不流失。”为了解决这个问题，各个团队都逐渐建立起一些需求管理和进度控制的流程，包括将不同团队的需求点明确为需求清单，同时在不同团队间安排专人负责项目接口，确认和监督每个需求点的落实情况。
对于敏捷开发可能带来的“混乱”，Allen认为：
可能这是我们这里研发上的一个不同点，就是看起来一些步骤挺乱的，但是这种“挺乱”的状态我认为又是必要的，不乱就太慢了……挺乱但不要真的乱掉，这可能是我们需要每一级的管理干部在心理上做到有序，形式上可以乱一点。
【声明】本案例是由郑小平和许家馨在杨斌教授的指导下编写的，仅用于课堂讨论。本案例中的情况描述不反映编者的观点，也不作为正式文件、基本数据来源以及管理活动是否有效的证明。案例版权归腾讯公司所有。转载请注明以上声明。
via：搜狐IT
解构微信系列文章
