最近，从一些技术大拿、架构师、创始人的朋友圈中再次拜读了张小龙在14年5月对微信团队保持小团队文化的倡导。深表认同，也根据我自己的思考做了一些解读。记录下来，与有心人分享探讨之。

1，用户价值至上：尽人皆知，但做到不易因而最容易被打折。打折的危险和后果就是产品变得不那么锐利，缺乏生命力，平庸，对用户吸引力降低。

要做到这一点的一个基本前提是团队员工(产品创造者们)需要理解用户，所以他们还应该是产品的深度用户会比较理想。如果创造者都不喜欢、很少使用的产品，估计用户也不大可能会喜欢。在产品经理决定产品需求的互联网公司中，针对产品经理，还有更高的要求：或者是产品的深度用户，或者每周花一定时间(我以为至少20%时间)去了解接触用户的所思所想所愿。有一些公司在此点有很好的机制。

2，保持共同的价值观。期望人生价值观一致太难，因为涉及爱好、理想、习惯、文化，那么能否做到关于产品核心目标和方向、用户群、运营方式、技术、市场等价值观、方向一致？做不到这些，团队会频繁发生争论、犹如拔河但使力方向和时机不一致。可能有人说：一开始就要求这些太理想化了，在做的过程中慢慢一致、中间甚至争吵打架也行。我说如果一开始做不到，那么就充满风险和不确定性，中间可能会经历一些曲折。

因此原因影响公司发展的案例不胜枚举，西少爷肉夹馍是比较多人知道的一个。

技术团队也一样，如果不能统一架构，而是多种实现模式，技术方案过于复杂，则不适合小团队。办法就是统一架构、或者分拆成更小的团队或者服务(微服务)。过多的小团队或者服务都会增加管理维护难度。小米对团队分拆有一个规定，管理者直接领导的团队在12人以下不允许分拆算是一个较好的对策。而针对技术服务的分拆标准还有待确立。

3，保持小团队，保持敏捷。

小团队：沟通高效、必须只招最好(最合适)的人，只做最有价值的事。反之，当一个团队人员过多、一些人工作量严重不饱和时很容易就开始做一些可有可无、优先级不那么高的事情，也会导致团队分心无法聚焦重点。

保持敏捷：做快、做好。多人的团队要保持敏捷并不容易，把如何做快、做好形成一些基本的规则、共识，通过总结反省得到更好或者保持长期较好的状态。产品技术团队的需求确定过程、需求交付标准、技术设计、代码review、站会、项目上线后的总结、故障后的case study等都需要在磨合中形成共识的规则，且应该的确是务实有效的规则。

保持敏捷：重要含义是避免复杂的流程，但一些基本的规则、流程、工具还是应该具备。保持敏捷的另外一点是功能小团队化，一个微小功能变动如果需要影响十几人研发、多个产品经理完成就坠入误区了。devops、full stack都是为此缘故而流行。

4，学习比经验重要：不墨守成规，不满足现状，持续追求更好。现实中勇于打破现状的团队并不多，很多人和团队都习惯已经稳定下来的制度、流程、模式，这其实是不求进取的一种表现。个人、团队、技术和水流一样，要活动、变化起来，方有生命力。

5，系统思维。团队中要建立决策原则，减少人为干预和频繁调整。虽然团队管理、技术模式要经常考虑变化，但并不是随心所欲的变化，变革的合理性与科学性需要有一些原则。正如产品需求变更可以频繁，改版、调整功能、界面都可以，但一定要对用户更好，而如何评判、是否有统一标准很重要。

6，用户带来用户。每一个互联网产品都期望能形成口碑传播、社交传播，前提并不是简单的把分享、传播摆在显眼的位置，用户愿意传播的前提是他自身对产品的认可，因此这一条其实是对是否遵守了1的检测。

某种程度上，也可以说是否遵守了前面五条的检测。如果能够遵照前五条行事，用户价值至上、统一理念、坚持敏捷高效小团队(没有可有可无的人和事)、保持自省和进取心、建立系统思维决策原则，得到这个结果的机率很高。而如果有所甚至较多缺失，恐难以持续在迭代中做出用户认可的结果。

7，思辨胜于执行。这是让人倾倒的大神才能说出的经纶之音！有魄力说出这话的在各种互联网公司高层ceo、cto、cpo(产品负责人)中也不多见。因此这一点是最有争议的，几乎每一家公司都是强调执行力、强调show me code、强调先做出来看用户反馈。关于此点，我只能说：

(1)行胜于言是对的，言和思辨还是有区别。如果目标是一个巨大的市场的领头羊，思辨应该更优先于行。行成于思毁于随。没看清、想清，就改名叫人人网，行为代价很大。

(2)多数时候，思辨胜于行动只适合大神，如果是想一星期也想不明白的普通人(如我一样)，还是早点行动起来：)毕竟，机会有限，先用行动占住风口，然后在风走了时继续改进！

hasty.2015/05/24草稿于台中清境农场。