聊一下《技术力量-一线技术团队成功启示录》

一、前言

最近有幸拜读了《技术力量-一线技术团队成功启示录》的第一篇-Team Leader团队管理/组织发展，该篇从组织架构、团队管理、效能提升、敏捷转型这四个方面展示了10位来自不同行业、不同领域的专家的不同看法，貌似形态各异，实则殊途同归。

二、康威定律

梅尔.康威于1968年提出的“任何组织在设计一套系统时，所交付的设计方案在上都与该组织的沟通结构保持一致。”，这句话就是后来的康威定律。

从微软的Office性能团队项目经理杨珂的分享中看到之所以其性能团队能够成功，我看到的是其团队成员的专业技能外，还有正确的团队组织结构及交互方式。他的OPERF团队会要求每个其他应由团队（如PPT、Excel）要指定一两个“性能联系人”，这样OPERF团队就能跟每个应用团队有机建立了“连接”。反思回团队内部，目前整个渠道条线中每个渠道团队基本上都是各自为政的，这样的弊端就是即使架构组已经定义了标准的技术体系与架构选型，但是在每个团队的实际项目过程中的细节实现会更多的站在自己团队去思考，即可能会造成重复建设、平台建设进度慢、平台通用化程度不高等问题。因为就算是渠道是个性化的，但是不同渠道还是有一定的共性（如用户中心、推送中心、进销存中心等），而这些共性则构成了平台化建设的必要性。参考了阿里的共享服务团队的建设经验，我觉得在渠道端需要做两个事情：

重新要针对渠道系统进行整体的业务流程、功能模块梳理，把所有的共性识别出来；

针对这些“共性”服务，为了确保共性服务的成功建设，更多应该组建一个业务平台小组，而且这个平台的成员最好是从各个业务系统抽调，这样做的好处是可以保证每个人对每个业务系统都是最了解的，同时又因为他们的职责（即KPI）更加“专一”，即平台化就是他们最优先解决的目标，这样这个平台化的工作才能更容易推进。

三、敏捷转型

道富科技是全球性的金融服务提供商，它们从2013年9月开始在IT研发和维护部门开始了敏捷转型工作，从传统的职能型组织架构、瀑布软件开发模型向跨职能团队（即特性团队）和分布式Scrum开发模型转变。在整个敏捷转型过程中他们坚持了以下三个原则：

梳理并坚持清晰的团队目标

坚持质量和业务价值重于速度和形式

坚持养成自组织团队

1、统一团队目标

首先，团队对敏捷转型的态度是怎样，支持、反对还是观望？团队目前的最痛点（即主要矛盾）在哪里？团队最痛点能否通过敏捷模式去解决？我觉得如果没有先去理清和解决这个问题，敏捷能持续推进下去并成功的可能性不高。因为团队成员从心底里就不认同这套方法论。人是有惰性的，团队也一样，如果团队在没有足够痛的情况下，是不太可能主动变更自己现有的工作模式，因为改变意味着不确定性，不确定性意味着潜在失败。

2、坚持质量和业务价值重于速度和形式

首先，我认为觉得开发团队价值的，是要看能不能提供业务价值，而不是做得有多快。团队在一开始推行敏捷的时候因为“初战告捷”就变得轻浮，一味的高歌猛进，每个迭代都不遗余力的帮团队提升迭代产能，搞得好像“众人拾柴火焰高”一样，这样非但没有好处，更会为团队带来隐患。

首先，初期开始时候每个人的精神状态都是高度亢奋的，这样的产能根本不能完全代表团队的稳定产能，反而会让团队失去原来的“免疫力”，如果后面的迭代由于某些原因导致产能的持续下降或者不稳，会导致团队变得很脆弱从而导致团队对敏捷产生怀疑，更甚至产生对立情绪，因为当人一遇到困难后且新环境还没有正式变成其舒适圈前，因为人由于趋利避害的特征往往会回到自己的原有作业模式中。

另外，因为时间、成本与质量本来就是项目管理的互相影响的三个极；当在成本（即资源）不变的情况下，时间越短产能越高，但是质量则是越差。回顾我们之前的敏捷推广的初期，很多同事动则就拿敏捷来说事，在开发过程逐渐忽略了文档的重要性，还美其名曰“敏捷就是免文档”，实则是拿敏捷作为借口。在我认为，敏捷倡导交流重于文档是有一定的基础：

1）当然我们不是要按照CMMI的那套条条框框用最重的流程去要求准备文档，我们是在敏捷过程中适当的裁剪我们的文档；

2）文档的编写最好是有相关工具支撑以便把编写成本最低化，最好能做到所写即所得，如在某些团队在编写接口文档采用目前较为流行的Swagger，这样可以通过在代码中加入注释则可以一键生成接口文档，同时这个接口文档直接就可以作为接口测试的文档使用。

四、团队培养

从奇虎360高级技术经理吴亮的分享来看，他为其负责的前端团队确立了团队的三大核心价值-三层金字塔：

金字塔基：服务业务

金字塔中部：基础平台

金字塔顶部：技术服务

金字塔基：服务业务

因为我们首先是一支服务于业务产品的团队，接着我们才是技术团队，我们需要用最佳的服务意识和合作态度去提供必要的服务。在很多的技术人员的意识层面总是认为自己只是一名技术人员，总以技术我最懂自居，经常使用一些复杂或者未经过验证的技术去实现业务需求，其他人稍有不同意见并“孤芳自赏”；殊不知这样的做法只会让自己脱离群众，脱离实际，脱离团队，而且自己本身对这个技术也是一知半解。爱恩斯坦说过：“万事应该简单化，但不应太简单”。这句话引申到我们的实际工作，就是说针对业务需求（业务目标），我们优先考虑的应该是兼顾时间、成本、复杂度的解决方案，而非一味追求技术热点。

金字塔中部：基础平台

当我们的团队成型以后，我们开始提供各种各样的服务，负责跟进各种各样的业务需求，也踩过各式各样的“坑”；这个时候我们需要开始怎么去把我们的经验沉淀下来，这个时候的基础平台就是为了顺应发展而不得不构建的平台，这个平台本身就是作为从团队经验固化到流程、工具里面的一个极佳体现。当我们有了这个基础平台后，我们才具备快速试错的也能能力。

金字塔顶部：技术服务

这里其实包含了两层的工作。第一，在我们把这个基础平台推广到整个开发室或者部门使用的过程中，我们决不能做甩手掌柜。为了保证平台推广的有效性，我们输出的应该是基础平台外加技术服务，在应用团队遇到问题的时候提供必要的协助；第二，这个基础平台除了满足业务使用后，我们需要在持续收集应用团队的意见的基础上优化该基础平台以便提升其通用性，说白了其实就是要打造该平台的产品化。

另外，从整个平台化三步走的过程来看，技术人员的工作从单纯的功能开发、设计、技术支持、产品化优化不断过渡，也为技术人员的从一专一能的I型人到一专多能的T型人才，再到多专多能的E型人才的发展提供了相应的在岗实践路径，这样人才能力的提升又反哺业务和系统。