Bloody Sunshine

Just too damn hot

Japan

组织结构与敏捷开发的一点随笔

在日本呆了几个月之后,对于一些我们原本习以为常的架构,有了更深的理解。可以说是看到了落后与传统之后,更能明白先进的价值。
对于国内的互联网公司,敏捷开发是默认选项,而且实用主义的中国人并不拘泥于传统敏捷(Agile/Scrum)那一套,在软件工程管理上走得更远,更灵活。

传统的软件开发模式

传统的软件开发模式是长周期,里程碑式发布的,典型的是类似微软Office早年没几年发布一个大版本。这个开发模式的流程通常是市场研究/反馈 - 确认功能需求 - 设计(工程/视觉) - Coding - 内部QA - 小规模外部测试 - 交付/上架。这里面每一个环节都是以月甚至季度为单位计算的。
这个流程的目标是按时高质量的交付需求产品。但是现实是非常骨感的,在一年甚至数年的项目周期中,外部环境千变万化,如果在进入Coding之后的阶段有需求有变更,可能会对之前的设计架构有所冲击,开发团队将会面临三个选择

  1. 一旦需求确定,拒绝变更:会导致无法快速响应市场变化
  2. 在之前的方案上打补丁:如果架构设计出色可能问题不大,不过没有万能的架构,总会有一天补丁打得太多导致积劳成疾。
  3. 推翻重来:市场变化这么快,这次推翻重来了,谁知道俩月之后是不是要再推一次?

显而易见的:交付周期,交付质量和灵活度无法同时获得。因为有这些个问题,也就有了签字画押确认需求确认设计确认确认确认的超长流程。

敏捷开发模式

为了改善软件开发流程中遇到的问题,九十年代中期(是的1990年代),敏捷开发模式初步成型,并广为软件/互联网行业所接受。敏捷开发理念如今看来也并不过时,但是和所有理念一样,在生产实践中仍然需要具体的方法论,目前最流行的敏捷开发方法论应该是Scrum,核心方法是以周为单位开发/每日站立会/定期回顾,这些方法也被国内很多团队所采用。

大体上敏捷开发的目标是即使需求不断变化,也可以高效高质量的交付产品。
但是,如果读过敏捷开发的书籍或者文档,你就会发现,有一个词被反复提及:客户(Customers),这和国内互联网公司关注的用户(User/Customer)是不同的概念。这里的客户通常是需求方,这也引出了下面这个话题。

传统行业实际操作中的软件开发团队管理方式

在互联网行业,我们非常习惯高度集成的团队:一个产品团队中有相对独立的产品/设计/工程/商务/销售等角色,这个团队对产品结果负责。但是对于传统行业来说完全不是这样,传统行业(和这个世界上很多人)对软件工程的理解是:外包。很多行业认为软件开发并不是自己业务的一部分,所以并不会建立一支团队开发和维护自己需要的软件产品,而是通过购买或者外包开发实现目的。这种情况在发达国家非常普遍,所以各种关于敏捷开发的文档里才会如此强调交付(Delivery)。

时至今日,很多行业需要的软件仍然是行业工具,通常通过购买(比如制图软件)或者定制开发(比如ERP系统)来获得,但是随着人们生活的信息化,越来越多的行业开始通过软件或者网站为消费者提供服务,比如房地产或者服装品牌。于是需求方寻求定制开发用户产品,简单的比如官网,复杂的也许会有在线销售或者定制业务。
传统企业的组织结构示意图

相对应的,既然有这样的运作方式,组织结构自然也是如此,通常一个公司会有供应链/产品开发/市场/销售等部门,以官网为开端的互联网产品通常是市场部门寻求外包解决方案,随着需求越来越多,能带来的价值越来越高,外包成本越来越大,该市场部就会考虑自建一个团队进行用户产品开发。于是变成了供应链/产品开发/市场(包括互联网产品开发)/销售等部门。这个互联网产品开发部门其实和公司主营业务关系不大,存在的原因一般都是成本考量,这解释了为什么传统企业的互联网相关部门没有什么话语权(甚至有的时候在IT部门下),这也可以理解为一种历史包袱。
传统企业在新时代的组织结构示意图

在日本发现的有趣的事情是,某些公司虽然本身是互联网公司,在组织结构的设计上却是非常传统的横向大部门方式,业务部门/设计/工程开发部门这样,因为业务部门是最终赚钱的部门,所以有最高的话语权和最终决策权,其视设计部门为内部外包公司,把需求提给设计部门之后,设计部门整理确认,然后二度“外包”给开发部门。这样的组织结构会导致不同角色各自为政,缺少产品团队内部沟通,难以产生优秀的产品。

国内的情况

按照我的了解,国内的互联网公司基本上倾向于高集成度的小团队作战,通过减少组织层级保证信息传达的有效性。因为是一个相对稳定的团队长期经营一个产品,多数团队都对Scrum进行了简化,以对应更高节奏的开发。

从产品管理的角度看,无论网站还是App基本上都可以做到以周为单位快速迭代;工程管理角度上看,有追求的团队基本上能做到:

  • 持续集成(CI)
  • 持续测试(CT)
  • 持续交付(CD)

国内社交媒体上的产品狗们经常会黑自己经常改需求,之所以敢于自黑,通常是因为真的自信:今天改的需求明天就特么上线了,这是多么强大的效率啊。
总的来说,我觉得优秀的人才,灵活和高效的组织结构和项目管理方式,是中国互联网近十年弯道超车的重要原因。

优秀的人才

提到优秀的人才,还想补充两句就好像设计方法论无法保证作出牛逼的设计一样,项目管理方法论也无法保证项目的结果牛逼。关于敏捷开发有太多的最佳实践了,但是无论Pair programming, Code review还是TDD都无法保证你的代码是牛逼了,只有牛逼的团队能帮你接近牛逼的结果。

工作搞定了。

在家赋(wan)闲(shua)了四个月之后,接了日本乐天的Offer,4月初入职。

感谢找工作过程中各位老板和朋友的帮助!

有几点希望说明一下

  1. 日本乐天不是做巧克力派的那个公司?,主营业务是电商,网址是 www.rakuten.com 说我去做巧克力派的朋友,回国我就去物美给你们买巧克力派做礼物!
  2. 之前和一些同学约了饭,但是没吃,有同学反馈说:『你是不是别人都吃完了把我忘了?!』真的不是!我是那样人么!!其实是我担心我和你们吃完饭又在国内赋闲了两年什么的,那见面多尴尬是不是?!
  3. 我2月底回北京,然后预计三月中下旬去准备入职,可以约起来啦!
  4. 做RD PM UI的朋友,想去日本工作生活可以小窗我,可以介绍工作机会(有汉语友好和英语友好的)。
    然后插播一组广告:

我家房子出租,7月初可以入住,预计租期2-3年。

* 价格公道,有兴趣的朋友请小窗,看眼缘 :)