美文网首页
持续交付中消失的milestone

持续交付中消失的milestone

作者: ABasicVersion | 来源:发表于2018-11-20 18:09 被阅读43次

之前一直在IT咨询公司工作,面对甲方的项目,已经习惯了项目立项、开工、实施、验收、收尾等一系列有节奏的敏捷项目管理工作。然而,到了另外一个环境,发现之前的节奏被抹平了。一个产品研发启动后可能2个月的时间就上线第一个版本,自从第一个版本上线以后,就是小迭代,不断从用户手里收集反馈,不断的把需求转化为系统的功能,大多数的功能一周或者两周就已经上线了,这种交付节奏已经是典型的持续交付。

对于互联网式的持续交付,我发现,很多需求都是一点一点的流过来,然后一点一点的实现,没有明确的时间点、没有明确的里程碑。我起初在怀疑,一个没有长期规划、没有里程碑的产品怎么能成功呢,然而,事实是,不止一个这样的产品已经获得了成功,我看到的这类产品的团队大致有10人左右的规模,研发已经和运营一体化了。

在一个持续交付的过程中,是否还真的需要milestone?为什么以往的项目都会有milestone?思量之后,我认为这个现象的背后一定是有一个合理的解释存在,这也是这篇文章存在的原因。

对比toB的传统项目和toC的互联网项目,这二者有很大的不同:

客户要求不同

互联网产品大多是toC的客户(不否认有toB的客户),个人客户的一个特点是,人和人之间是弱关联关系,也就是说,甲用了微信,并不意味着乙就一定要用微信,即使两个人关系非常密切。在这种情况下,产品就可以一点一点的往外推广,慢慢的完善。

而对于企业应用来说,对于严谨性的要求很高,不能出错。企业客户的部门和部门之间,人和人之间往往是强关联关系,一个部门实施了一套系统,往往会牵扯到其他的部门,部门之间是有协同流程存在的。因此,这种具有强关联关系的系统,不太适合慢慢的生长,而是需要规划。这种规划不仅要规划IT系统,还要进行业务流程的梳理。

系统环境不同

互联网toC的客户没有系统环境,因此开发一个新产品谈不上对用户已有的产品产生影响。

而企业客户往往会有很多的遗留系统,这些遗留系统承载着业务流程。当要实施一个新系统时候,往往会牵扯到老系统的集成以及系统的业务边界的问题,而且这个切换过程会比较痛苦,用户在工作中要忍受很多的不适应。其实,应该说每次功能调整都会引起操作上的不适应,最好的办法是功能一次做到位,不要改来改去,用户受不了。因此,在这种情况下慢慢演进的产品研发和实施方式就不太适应企业客户的要求。

组织制度不同

在互联网企业,产品一般都是由小团队孵化出来的,然后投向toC的客户市场,如果反应比较好,就加大投入。这种方式是一种自下而上的孵化方式。

而传统企业在启动一个项目的时候,即使是用敏捷实施,往往前期也要做规划,后面开发的时候逐步的深入和调整。这是一种自上而下的管理方式。

要说哪种制度比较好,这个不能单纯的进行制度的比较,要结合企业的业务模式和企业战略综合来看。

以上只是简单的比较了两种交付模式的不同。如果更近一步,在持续交付的过程中,难道就不需要milestone嘛?milestone的价到底是什么?思虑再三,milestone会跟业务目标相关,milestone会跟系统集成相关,milestone会跟规模化团队研发相关....

Milestone的价值在于协同

在一个具有强关联关系的客户组织中,如果进行一个系统的开发和实施,必然会考虑到各个部门以及各个系统的强关联关系,从而需要一个规划,一个方案在前期把相关联的各方的问题解决好,达成一致,然后再进行开发和实施。

在一个强关联系统的环境中,当要开发一个新系统来替代老系统的时候,需要考虑与其他老系统的接口规则和数据同步机制,保证一次上线成功,不影响正常业务。因此需要在前期做好规划,统一认识。

不论是部门间的业务流程还是系统层面的规划,都可以划分成milestone进行各方目标的同步。

对于一个中大规模的研发团队而言,milestone的价值更加明显,比如硬件和软件的研发团队需要定期的进行集成,每次集成之后一般就是一个版本发布,这中发布节奏到现在而言,可能会比较快,比如每两周做一次发布。这个节奏不应该叫做milestone,应该是一种发布节奏。这种节奏其实就是一种协同。

Milestone的价值在于战略执行

除了协同,milestone的一个价值在于战略的执行。战略执行需要通过不同的路径达到最终预期的战略目标,每一个阶段性的目标,都可以叫做milestone,具有重要的业务意义。

为什么很多小团队的小产品没有milestone?

我见过很多的小团队,10人以下,他们的研发没有milestone,只有每周的一次迭代。根据上面的分析,原因是
第一、他们没有强协同关系,这些小产品都是各自相对独立的,之间没有强依赖,即使有联系,联系也比较稳定;
第二、他们没有战略目标,看不清以后的方向,没有战略规划,因此也无法设置milestone;

综上所述,应该说milestone是在战略的道路上进行组织协同的一种节奏。当一个产品研发没有milestone,没有节奏的时候,要么就是没有战略方向,要么就是没有强协同的要求。

相关文章

  • 持续交付中消失的milestone

    之前一直在IT咨询公司工作,面对甲方的项目,已经习惯了项目立项、开工、实施、验收、收尾等一系列有节奏的敏捷项目管理...

  • OpenShift中的持续交付

    上一文中讲述了如何在AWS下搭建OpenShift集群。这篇文章将目光转向如何在OpenShift中实现CI/CD...

  • OpenShift中的持续交付

    持续交付 如果要打造一个持续交付的流水线,首先要考虑多环境的问题。一般一个应用程序会有多个环境,比如开发环境、集成...

  • 《持续交付》 - 持续交付管理

    一 项目的生命周期 一个新的开发团队一般会经历的几个阶段: 创建期(forming):团队的初步形成,主要是团队人...

  • 敏捷交付中的自动化测试

    提到敏捷交付,我们总会说到持续集成,持续交付,持续发布,即频繁地交付产品特性。而我们都知道要实现真正的持续交付,必...

  • 谈谈敏捷交付中的自动化测试

    提到敏捷交付,我们总会说到持续集成,持续交付,持续发布,即频繁地交付产品特性。而我们都知道要实现真正的持续交付,必...

  • 微服务的部署与发布:持续交付与持续部署微服务

    持续交付与持续部署微服务 持续集成(Continuous Integration)与持续交付(Continuous...

  • 什么是CICD?持续集成与持续交付

    持续集成与持续交付是软件开发和交付中的实践。我们项目中一直在践行持续集成(CI:Continuous Integr...

  • CICD - 持续集成与持续交付

    持续集成与持续交付是软件开发和交付中的实践。我们项目中一直在践行持续集成(CI:Continuous Integr...

  • 83.持续交付你的进展

    持续交付是互联网软件交付的一个概念,以前把这个概念用到了写作上,即持续交付写作 今天把这个概念用到职场中 职场中上...

网友评论

      本文标题:持续交付中消失的milestone

      本文链接:https://www.haomeiwen.com/subject/lljxqqtx.html