本文是我在2012年开始从企业信息部门出来负责去做互联网业务时，作为当时的技术负责人对于互联网技术团队的建设的一些思考。从一个领域跳到另外一个领域，如何做好角色转换，如何在新的领域能够入乡随俗，顺应规律，我们需要思考两个领域的共性和差异，以便能够从固有的思维里跳出来不受羁绊。
回看七年前写的这篇文章，我很庆幸自己很好的实现角色的转换，在互联网应用开发领域建立了适合自己团队的技术体系。希望今年在新的岗位上，也能快速的进入状态，实现新的突破！
本文虽然是七年前旧文，但很多思路依然指导着我现在的工作，当然也有些想法过去陈旧，在本文中我也增加了注解来补充和解释自己的观点。
谈谈互联网产品开发的特点
互联网的产品大都是面向海量用户的服务，且用户分布区域广泛，其教育水平、习惯也大多不同，具有高度不确定性，我们必须非常关注用户的行为和反馈。
因而，在互联网产品服务的整个用户研究，需求分析、产品研发及交付服务的过程中，都采用探索式、适应性的研发理念进行产品的研发。通常，会把整个产品研发周期划分为若干个迭代，采用迭代式的演进过程，不断的去交付新的产品特性，并通过观察用户的行为和反馈获取，进而随时调整产品的思路和方向。一切以用户价值为核心是互联网产品最核心的特点，而以价值驱动的敏捷开发方法非常符合这一特点。
敏捷项目管理实践，通过小步快跑，快速迭代、增量交付用户价值，不断获取用户反馈，持续、快速的调整产品，验证并适合用户价值。正是通过这些实践活动，我们以迭代的、增量的交付用户价值，最大限度的保证产品朝着符合用户实际需求方向发展。
谈谈技术团队
基于互联网业务的敏捷团队，大部分大型的互联网公司都偏向以下三种文化或者原则：
（1）自组织文化
如google、facebook等互联网企业，他们很少甚至没有特定的项目流程，通常怎么敏捷怎么做，具有浓厚的工程师驱动文化。敏捷团队的自组织特性弱化了团队技术领导这个角色，强调自我管理和自我驱动，对于每个人的能力和素质要求更高，但是会让我们做的更高效、更敏捷，可以走的更稳、更远。
（2）追求一体化
一体化团队作为敏捷开发方法中最具精益思想基因的实践，是指每个项目团队包括分析，开发，测试等角色，使团队满足一个需求从设计，开发到测试各个阶段顺利完成，达到符合质量标准并满足需求的软件。每个一体化团队一般都依附于某个产品，每个角色都为产品的发展贡献着自己的智慧。
（3）追求全功能
这里所指的全功能是希望项目团队能打破工程师角色之间的边界，如研发、测试和前端工程师的界线，消除开发、测试流程中一些潜在浪费，提高效率。在项目团队内部通过角色互换，不限角色的结对工作，加强不同角色，不同模块间的知识传递，打破技术壁垒，帮助员工从不同视角理解项目，锻炼技能，进而增加团队均衡生产的能力。
为什么要提倡打破边界？
项目整体效率依赖于项目过程中各环节的工作效率，而整体效率的优化往往依赖于均衡生产，即消除生产的波峰（过度生产）和波谷（生产不足），只有局部效率的增加无法直接转换为整体效率的增加（就象桶能装多少水，决定于最短的那块板）。
整体效率的优化要求IT团队消除技能壁垒，培养多面手，根据计划的的变动，弹性地调整任务，达到各角色和流程之间的平衡。（对小团队尤其重要，这也是风险管理所需要的。大团队每个角色和岗位都会设置若干人，通过人数的优势达到了均衡生产，但对于小团队，某个角色可能只有一个人力，如果这个人工作受到影响，整个团队的链条都要受到很大的影响，打破角色的界限，最大限度的降低了这些风险。）
技术团队的建设首先要从两个方面入手：一个是专业化分工，二是梯队作战模型。追求全功能或者均衡生产，并不是说每个人不分主次的全面发展，而是在保证一定的专业分工、深入专研的基础上，在技能上要有适当的广度。比如在我们团队，按照技术领域可以做以下组织模型：
技术团队组织模型
目前团队成员还比较少，如果每个人都均衡发展，对于技术体系就不会深入；但是如果都划定清晰的方向，只走专业化路线，意味着每个方向只有一两个人，项目开展就很难调动人力，这也是不可能的。所以每个方向固定第一梯队的人员，在该方向上能够专业化发展，同时每个方向的第一梯队的人员又将是其他方向的第二梯队，保证人力资源能够均衡的被调配，满足各种项目的开展。
同样在岗位上，我们依然是按照这个思路来进行，每个人都应具备“架构设计”、“程序开发”、“质量测试”的部分能力，打破角色之间的界限。这对每个人的整体素质要求是非常高的。
7年前，我所带领的团队规模较小，成员不超过10个人，在这样的规模下，我优先打造全功能团队，每个人几乎都是全栈的，能够两三个人一个小组快速敏捷，同时相互之间可以快速补位。但是今天，我所带领的团队是上百人的研发团队，研发的产品或平台也比之前更加复杂，所以此时我更强调的是专业化的分工，前后端的分离阶段不同，规模不同，我们的组织方式不同，切记惯性思维。
除了专业化分工之外，我们还需要建立梯队模型，将人力资源和时间分配的更加均衡。如下图所示：
技术梯队模型
这是一个漏斗模型，在人力和时间分配方面，自上而下优先级逐级递减。项目开发直接面对着需求，它的核心是“快”，要有快速响应需求的能力，以最快的进度完成产品的增量交付。
为了更快的响应，在架构设计、程序开发方面遵循“适可而止”的原则，不要过度设计，在可容忍的范围内可以适当降低程序的质量。
如果仅仅只做这些，我们的产品和系统是早晚都会出现问题，所以我们还需要下一个环节：产品优化。这个环节的核心是“精”，精益求精，将以前的瑕疵、隐患去除掉，考虑到更久的将来，不断地调整我们的架构，不断优化我们的程序，整个改进的进程和系统的发展进程相呼应，保证系统的平滑发展。
仅仅这些就够了吗？显然不够！项目开发如何快？产品优化如何精？源于我们深厚的积累，研发的重要性就是体现在厚积薄发，全面提升整个团队的技术厚度，提高开发的效率。我们团队有自己的框架和平台，大大的加快了我们项目开发的速度。
通过这个漏斗模型，我们将人力和时间按照这个层次结构，进行均匀的分配，保证我们的计划进度的执行非常平滑，没有过分的紧张，也没有过度的松懈。将以往我们的开发如过山车般的进程变成在一条平路上匀速前行。
思考：如何打造一个优秀的研发体系？
在研发体系的建设上，7年前的自己和现在的自己如出一辙，是不忘初心还是不思进取，等年底看效果吧。o(*￣︶￣*)o”
谈谈CMMI
公司最近在搞CMMI3，过程的持续改进是我们一直都需要去做的，引入CMMI，可以帮我们更好的进行过程的改进。我们的团队涉足企业信息化，软件项目和互联网项目，其实每件事物都有它自己特定的环境，都有自己繁衍的土壤，我们在这个过程中一定要有区别的对待，真正的遵循事物发展的规律，否则好心不一定能做好事。
各大软件公司搞CMMI 基本都是招标用的，这是中标的一个有力的砝码，更适合TO B的公司。而互联网公司，他们根本的生存法则不是依赖外包项目，产品销售进行的，而是针对终端用户推出的服务产品，提供非常好的使用体验，获得用户的认可，从而获得公司的发展。所以这就是为什么做互联网的企业很少去评CMMI，很多一流的互联网公司的产品研发过程甚至都达不到CMMI的要求。
网上对于这方面的讨论也特别多，但是我们既然要做CMMI，是因为我们还有软件开发的业务范围，我们也真正的想通过CMMI提升整个团队的研发水平，改进我们的过程。但是我也真心的希望CMMI在进行的过程中，一定是能深入到不同的项目团队，探究每个项目和业务方向的特点，找出适合每个团队发展的业务流程和管理模式，而不要凡事一刀切，一个标准，一个模式，或者更可怕的是将以往实施的案例不加考量的就转移到我们身上，反过来成为我们前进的阻力。
谈谈技术
作为技术团队的负责人，我一直在思考我们需要什么样的技术，特别像我们整个团队和领导都具有企业应用开发的背景，如何适应互联网应用开发的需要，如何要转变观念，用合适的技术解决特定领域的问题。
在谈具体技术之前，我想还是和我们以前一直从事的企业应用开发做一个比较，这样我们能更加直观的知道我们需要做哪些改变，哪些才是我们未来的技术方向。
企业应用和互联网应用的区别
根据这个表格，我们非常明显的看到企业应用和互联网应用的巨大不同，应用的不同决定了技术的差异，企业应用要求系统的稳定性、程序的复用性、数据操作的严谨性、业务的集成性，而互联网应用要求高并发、高扩展、高可用性。
对于我们团队，我们的业务主要在互联网领域开展，但是我们的管理又属于企业应用的范畴，我们的开发领域基本囊括了企业应用和互联网应用。所以对于技术团队的要求是非常非常高的，我们不仅仅根据不同的领域进行专业化划分，我们更需要学习更多更实用的技术解决各个领域的问题。
谈谈架构设计
我们张口闭口的谈架构，但是何为架构，可能谁也说不清楚，因为大家对架构的理解不同。从字面的意思来讲，架构就是确定一个事物的骨架和结构，从整体上勾勒出事物的意识形态。架构又分为很多种，管理企业需要进行组织架构。
就IT而言，实施系统需要系统架构和业务架构，开发软件需要软件架构，还有信息架构、基础架构、数据库架构等等。我们在讨论架构时，总是意见分歧很大，是因为我们并没有为“架构”设立边界，不同的人对架构的定义是不一样的。下面我谈的架构主要集中在系统架构和软件架构。
软件架构设计需要以长远的眼光以宏观视角从整体出发，深入分析外部环境、竞争对手与内部资源，明晰各方面的关注点，并平衡他们之间的利益，使大家可以明确目标，达成共识，解决主要矛盾。
架构师一定要有全局意识，不能过多的纠缠于细节。架构可以不过多关注功能，但必须考虑系统运行的场景和所处的领域，明晰关键点。
架构是一种平衡的艺术，最好的架构不是最完美的架构而是最适合未来一段时间的架构，架构要考虑到未来发展和当前资源的平衡，将性价比放在第一位考虑。
架构的确不容易改变，一个易变的架构不是好的架构，但是一个不能改变的架构也不是好的架构。架构的可变性也应该是架构设计的一部分。所以架构师要致力于设计一个可容易扩展的架构，在这方面如果我们经常拿盖房子作为比较是不合理的，软件架构的可伸缩性本身就是区别于传统行业架构设计的魅力所在。
架构师不仅仅有深厚的专业知识和技能，架构师必须具备必要的广度，特别是当前一个信息爆炸的时代，我们所遇到的各种情形都在当前的信息池中找到相应的解决方法和案例。架构师一定要掌握更多的信息，对信息进行系统的加工整理，在架构工作中首要想的是如何使用现有的解决方案，而不是闭门造车，不开放的醉心专研，重复发明轮子。现在有这么个说法，“掌握信息比掌握知识重要”，不是没有道理。
谈谈运维
单谈运维他是一个很泛的概念，有人认为很高深，有人可能没啥概念。其实运维是IT管理中一个很重要的环节，我们生产的系统如果没有运维的支持，它便存在着巨大的风险。我们一直在谈企业应用和互联网应用的区别，其实两者的区别也决定了这两个领域的运维也存在着很大的区别。
传统企业内网运维关注点是在安全、权限管理等重点，以及旧IT资产利用率，如何利用好现有的IT资产是他们目前迫切需要解决的问题。传统的企业内网，使用大量的小型机（IBM Power小型机、HP小型机、Sun小型机等）、高端网络和存储设备（Cisco、EMC、日立等），使用大量的商业数据库、ERP和中间件技术（IBM DB2、Oracle、SAP等）。
企业的核心业务运行于这些设备和软件之上，业务年限长、历史遗留问题多，数据安全、业务连续性等是这些企业的生命线，往往通过购买厂商和集成商的服务来保证其IT业务的稳定性。对于互联网运维，如何快速有效地部署，如何保证可利用率，如何处理大并发访问等是他们的头等要事。
现代的互联网企业，大量使用PC服务器、普通硬盘盘阵和集群、先进的SSD技术，大量使用Linux、MySQL等开源软件。业务模式单一，软件技术、硬件设备更替迅速。性能优化、部署灵活、提升IT硬件利用率是他们的工作重点，业务领先的互联网企业背后都有一个强大的IT运维技术团队。
运维是一件极其繁琐，极其复杂的管理工作，这就要求运维工程师具有很广博的知识体系，不仅仅熟悉网络、硬件，还要了解开发，了解各个系统使用的技术和软件，通过大量的运维数据可以有效地指导架构和系统的优化，运维工程师一个典型的复合型的人才。
运维工程师的岗位职责：
负责机房业务服务器的配置、维护、监控、调优、故障排除等；
大用户量下高性能服务器系统部署方案的制定及实施；
保障服务器与数据库安全，检查并消除安全漏洞；
数据监控、应急响应、故障排除、编写数据分析报告等。
就像我在谈架构时认为架构需要关注运维，指导开发一样，我还认为运维是关注开发、指导架构，一个好的架构师需要经过运维的过程，他才能深刻的预判到一个系统在未来的演变，以便今天可以实时可以扩展的架构。一个具备较高开发水平的运维工程师是向架构师进阶的最好路线。
7年前就开始重视运维，但是限于资源和应用规模，运维这部分一直没有做好。今年其实也非常看重运维，但是依然限于资源和规模，还是把几乎所有的资源投入到研发中。但是未来随着产品规模越来越大，打造专业的运维团队依然是一个目标！
谈谈云
当前云是一个很热的话题，所有的软件服务都尽可能的和“云”搭上边，但是具体什么是“云”，相比很多人都“云里雾里”的，不知所以。
“云计算”的概念应该是谷歌在5年前提出来，并得到快速的发展。“云”的诞生有其发展的必然性，而谷歌、亚马逊这样的互联网巨头是催发它的催化剂。
这些互联网公司的核心的商业模式就是利用提供互联网相关的服务，从而带来巨额的营收，他们必然希望越来越多的人和企业接受互联网服务的模式，让一切服务都能通过互联网替代传统的方式，所以宣扬“云”，也是为了更加优化自己的商业模式。
其次，这些巨头企业经过这么多年的发展，他们在服务器，数据中心，分布式计算方面建立起成熟的有效的解决方案，仅仅是为了支撑自身的服务，资源势必不能很好的利用，推行云计算，将自己的基础设施和平台以服务的方式出租出去，将闲置的资源加以更加合理的利用，这也是推行“云”的原因。
“利”字当头，任何一个事物的发展怎能少了一个“利”。当然 “云”的发展给我们的信息生活带来了翻天覆地的变化，推动着整个信息产业的变革。
“云”让基础设施的建设更加集中，互联网服务更加的规模化，资源的分配更加的合理，避免了巨大的浪费。
“云’让我们的观念发生了转变，让我们更加接受互联网服务模式，为人类的生活提供了更大的便利。
“云”的诞生更加优化了互联网的服务模式，提升了互联网服务的盈利能力。
“云”其实就是“服务”，一切传统的信息处理的手段都通过服务的方式进行交付。而在服务上，又分为几个层次：IaaS（基础设施既是服务），PaaS（平台既是服务），SaaS（软件既是服务）。
而在IaaS和PaaS层面上，一般由大型的厂商承担着，比如亚马逊、微软、谷歌等等，他们拥有天生的资源来做这些底层的，具有规模化的基础设施建设。
而在中国，这些一般由政府驱动，由大型厂商来承接。中小型的公司只能在SaaS上，提供更加细分、更加个性化的软件服务，才是生存的王道。
我们张口闭口谈“云”，我们是“云笔记”，“云相册”，如果服务不具备规模化效益，没有将服务转化为盈利的能力，这个“云”只能算是一个普通的互联网服务，和个人博客和个人相册有什么区别。
所以我们要做“云服务”，我们需要在基础设施、大数据计算方面有一定的掌握能力，这些不需要我们去创造，而是能很好的利用，将“云”相关的技术（虚拟化，mapreduce分布式计算，海量数据存储、负载集群等）很好的运用起来，这是支撑云的基础。在这个基础上，一定要做细分的“云”，有特点的“云”，提供用户最专业的个性化服务和解决方案，服务产生价值。
“7年前，云也就刚刚兴起，但今天我们已经离不开它了，云让我们更加的单纯，把精力完全聚焦于自己的核心业务。我的团队也做了几款云的产品，但只能是云的概念，还不具备云的规模，希望我们能把规模尽快做出来。”
谈谈移动应用
上面谈了“云”，有“云”必然有“端”，“云”是服务的提供，“端”是服务的消费。目前最重要的两个端是PC端和移动终端，未来物联网建立，所有事物都俨然是“端”，在PC端，依然是传统的浏览器和客户端。
随着移动互联网的发展，越来越多的服务已经开始向移动终端倾斜，利用移动终端的便利性，服务的提供和消费也变得越来越快捷。未来移动应用将带来一个崭新的时代，一个属于移动互联网的时代开始了。
在移动应用的技术领域中，我们需要面对多个平台（ios，android，wp等），每个平台可能还需要面对不同设备的规格，移动开发也面临这很多很多的问题。很多厂商也在致力于利用一些中间的语言和技术来统一移动领域的开发，比如目前以html5、javascript、ruby等中间件平台也开始蓬勃发展起来了。
最近google推出了将java转化为object-c的工具，未来的移动开发必然要面临也需要我们考虑如何解决跨平台的问题，特别对于中小企业，处于成本的考虑，我们也将不得不面对。
目前，我们要解决的是如何将原生语言和跨平台语言的结合，因为一个服务，多个终端，业务处理逻辑都是相同的，不同的更多是在UI层面和交互层面上。所以通过和中间语言的结合，比如javascript、lua等，可以更加优化移动应用的开发，降低开发和维护的成本，而且多个端都可以在一个统一有序的环境中发展。
跨平台的移动应用在刚开始的确做了一些尝试，但是实际运行效果并不是太好，所以这部分这几年是没有更深入的发展，移动开发依然以原生开发为主。但是随着前端技术的日趋成熟，跨平台的解决方案也越来越成熟，这方面我们应该再重新出发，配合移动中台的建设，把端上面的技术好好的沉淀下。
2012年10月7日 一个十一假期的思考沉淀
