在日本呆了几个月之后，对于一些我们原本习以为常的架构，有了更深的理解。可以说是看到了落后与传统之后，更能明白先进的价值。
对于国内的互联网公司，敏捷开发是默认选项，而且实用主义的中国人并不拘泥于传统敏捷(Agile/Scrum)那一套，在软件工程管理上走得更远，更灵活。
传统的软件开发模式
传统的软件开发模式是长周期，里程碑式发布的，典型的是类似微软Office早年没几年发布一个大版本。这个开发模式的流程通常是市场研究/反馈 - 确认功能需求 - 设计(工程/视觉) - Coding - 内部QA - 小规模外部测试 - 交付/上架。这里面每一个环节都是以月甚至季度为单位计算的。
这个流程的目标是按时高质量的交付需求产品。但是现实是非常骨感的，在一年甚至数年的项目周期中，外部环境千变万化，如果在进入Coding之后的阶段有需求有变更，可能会对之前的设计架构有所冲击，开发团队将会面临三个选择
- 一旦需求确定，拒绝变更：会导致无法快速响应市场变化
- 在之前的方案上打补丁：如果架构设计出色可能问题不大，不过没有万能的架构，总会有一天补丁打得太多导致积劳成疾。
- 推翻重来：市场变化这么快，这次推翻重来了，谁知道俩月之后是不是要再推一次？
显而易见的：交付周期，交付质量和灵活度无法同时获得。因为有这些个问题，也就有了签字画押确认需求确认设计确认确认确认的超长流程。
敏捷开发模式
为了改善软件开发流程中遇到的问题，九十年代中期(是的1990年代)，敏捷开发模式初步成型，并广为软件/互联网行业所接受。敏捷开发理念如今看来也并不过时，但是和所有理念一样，在生产实践中仍然需要具体的方法论，目前最流行的敏捷开发方法论应该是Scrum，核心方法是以周为单位开发／每日站立会／定期回顾，这些方法也被国内很多团队所采用。
大体上敏捷开发的目标是即使需求不断变化，也可以高效高质量的交付产品。
但是，如果读过敏捷开发的书籍或者文档，你就会发现，有一个词被反复提及：客户(Customers)，这和国内互联网公司关注的用户(User/Customer)是不同的概念。这里的客户通常是需求方，这也引出了下面这个话题。
传统行业实际操作中的软件开发团队管理方式
在互联网行业，我们非常习惯高度集成的团队：一个产品团队中有相对独立的产品／设计／工程／商务／销售等角色，这个团队对产品结果负责。但是对于传统行业来说完全不是这样，传统行业(和这个世界上很多人)对软件工程的理解是：外包。很多行业认为软件开发并不是自己业务的一部分，所以并不会建立一支团队开发和维护自己需要的软件产品，而是通过购买或者外包开发实现目的。这种情况在发达国家非常普遍，所以各种关于敏捷开发的文档里才会如此强调交付(Delivery)。
时至今日，很多行业需要的软件仍然是行业工具，通常通过购买(比如制图软件)或者定制开发(比如ERP系统)来获得，但是随着人们生活的信息化，越来越多的行业开始通过软件或者网站为消费者提供服务，比如房地产或者服装品牌。于是需求方寻求定制开发用户产品，简单的比如官网，复杂的也许会有在线销售或者定制业务。
相对应的，既然有这样的运作方式，组织结构自然也是如此，通常一个公司会有供应链／产品开发／市场／销售等部门，以官网为开端的互联网产品通常是市场部门寻求外包解决方案，随着需求越来越多，能带来的价值越来越高，外包成本越来越大，该市场部就会考虑自建一个团队进行用户产品开发。于是变成了供应链／产品开发／市场(包括互联网产品开发)／销售等部门。这个互联网产品开发部门其实和公司主营业务关系不大，存在的原因一般都是成本考量，这解释了为什么传统企业的互联网相关部门没有什么话语权(甚至有的时候在IT部门下)，这也可以理解为一种历史包袱。
在日本发现的有趣的事情是，某些公司虽然本身是互联网公司，在组织结构的设计上却是非常传统的横向大部门方式，业务部门／设计／工程开发部门这样，因为业务部门是最终赚钱的部门，所以有最高的话语权和最终决策权，其视设计部门为内部外包公司，把需求提给设计部门之后，设计部门整理确认，然后二度“外包”给开发部门。这样的组织结构会导致不同角色各自为政，缺少产品团队内部沟通，难以产生优秀的产品。
国内的情况
按照我的了解，国内的互联网公司基本上倾向于高集成度的小团队作战，通过减少组织层级保证信息传达的有效性。因为是一个相对稳定的团队长期经营一个产品，多数团队都对Scrum进行了简化，以对应更高节奏的开发。
从产品管理的角度看，无论网站还是App基本上都可以做到以周为单位快速迭代；工程管理角度上看，有追求的团队基本上能做到:
- 持续集成(CI)
- 持续测试(CT)
- 持续交付(CD)
国内社交媒体上的产品狗们经常会黑自己经常改需求，之所以敢于自黑，通常是因为真的自信：今天改的需求明天就特么上线了，这是多么强大的效率啊。
总的来说，我觉得优秀的人才，灵活和高效的组织结构和项目管理方式，是中国互联网近十年弯道超车的重要原因。
优秀的人才
提到优秀的人才，还想补充两句就好像设计方法论无法保证作出牛逼的设计一样，项目管理方法论也无法保证项目的结果牛逼。关于敏捷开发有太多的最佳实践了，但是无论Pair programming, Code review还是TDD都无法保证你的代码是牛逼了，只有牛逼的团队能帮你接近牛逼的结果。