• 产品 or 项目


    产品和项目之争

    2020年8月1日

    21:21

    工作中,常听人纠结,说我们是做项目好还是做产品更好。都知道我们没有产品,都是做项目的。支持做项目模式的说,我们现在项目挺多,客户也多,不愁没项目,虽然辛苦点,也过得去,产品哪有真么好做的,再说了,产品也没法满足用户的个性化需求啊,不能做产品;支持做产品的说,光做项目太辛苦了,做产品有规模效益,边际成本很低。我们已经做了这么多项目,应该抽象需求,提炼出产品来卖,只要量上去,还用担心收入吗!这确实是个纠结的问题,怎么选择。

    在论证这两种方式之前,先给这两种模式下个定义。这两种都是企业信息系统交付模式。这里所说的项目模式,是狭义的模式,是指信息系统的交付,不基于已有的产品或者半产品,所有的项目都是从源码级别,根据客户的需求,重新进行设计,编码和交付。而产品模式是指,基于社会上同类系统的公共需求、设计开出具备特定功能,满足特定需求的软件,作为产品交付给客户使用。

    一、先说项目型交付模式。

    我们公司90%以上的项目是采取的项目化交付模式。

    这种交付模式的过程大体是这样的。拿到项目后,看看之前有没有做过类似的项目,如果自己没做过,就问问部门的其他人,或者公司的其他人。如果有,就把当时的方案拿过来参考参考。然后调研,设计,编码。有类似的项目,就把项目的源码复制过来一份,数据库也拿过来,稍作清理,作为新项目的开发基础。不可避免存在清理不彻底的情况,代码里有很多废代码,数据库中有很多不用的表,甚至还有其他项目的数据。在开发中,碰到新的功能,如果自己之前做过,活且其他人做过,就就把代码复制过来,稍作修改拿过来就用。最终完成交付。

    这种方式有什么特点(我们不说优缺点)

    1,项目中废代码非常多。一个个项目复制过来复制过去,清理的不彻底,代码中的多余的代码越积累越多,数据库中的表不用的也越来越多,不用的数据也越来越多,尤其是配置表中,系统表中的数据。谁也不敢删,不知道有用没用。

    2,开发人员的体验非常差,给新人起了坏榜样。项目非常不干净,对有洁癖的人来说,兼职是一种折磨。本来系统开发就是一种比较严谨的事情,这样一弄,这一原则严重被打破,风气被严重污染,从而会影响人员的斗志,影响严谨的开发态度,影响项目的质量。尤其是对新人来说影响更坏,差不多就行,马马虎虎等风气盛行,多余就多余吧,反正也不用他等等。我在带项目的时候,就碰到很多人这种工作态度。这种工作态度职能开发出来能用的系统,开发不出来好的系统。

    3,做不出好的系统。

    项目没有一个不是时间紧张的,时间紧,设计就会不足,就会仅仅满足当下的要求,没有普遍性。反正是做项目嘛,交付了就ok了。项目的目标是如期交付满足当前用户的要求的系统,而不是一个好的系统。项目好坏的评价标准和产品的评价标准是不一样的。

    4,重复的工作。

    开发工作重复,本来之前已经做过的东西,职只能从代码级别复用。借用时,还要从代码层面评估是否满足当前需求,不符合,就要打开源码修改,修改就不可避免出错,甚至把之前正确的代码改错了,需要全部重新测试。因为你不能保证拿过来的代码时最新的,是否和数据库版本一致。

    5,项目质量难以保证。

    时间段,测试不充分,没有经过长期的考验,即便是勉强交付了,运维的成本依然很大,甚至交付n年了,系统仍然不稳定,需要修改。这时候修改的代价就很大了。没有文档,不熟悉代码,当时的开发人员调走了,这都是障碍。

    6,模块或者功能无法持续优化

    在一个项目上发现了bug,明知道其他项目也存在,但是得不到修改。一是因为其他项目当时并没有暴露出来,再一个也不敢修改,谁能保证修改这个一点,不会有连锁反应,导致其他的问题呢,甚至是雪崩效应呢;其三是没有修改的积极性,不是我的项目我也没有义务说,没有义务去修改。待到同样的问题暴露出来,只能是再重复之前的过程,发现问题,分析问题,定位问题,修改问题,测试问题。因为这个问题并没有记录下来,谁也不知道其他项目上曾经修复过这个问题。

    7,后续运维的问题

    铁打的硬盘流水的兵。项目交付了,项目组就解散了,谁来维护?也只能是原来的开发人员维护。这就出现了一个问题,我已经调岗了,客户还会打电话给我,原来的部门还会找我让我帮忙,碍于情面,只能帮看看,我现在的工作怎么办,肯定影响我现在的工作,在考核不严格的情况下,成本,时间,就慢慢这样耗光了,但是谁也意识不到问题出在哪里。如果让别人运维,修改代码,问题更大,需要熟悉代码,试着修改,保不住出其他的问题,如履薄冰,战战兢兢。这也导致维护的成本巨大。

    我们的成本、时间、人员都被这些事情吞没了,而不自知。就和黑桐一样,吞没人员,时间,成本,激情,战斗力。只剩下无奈,疲惫,应付。

    8,工作成果得不到有效的复用

    复用是源码及的复用,而且是个人行为,局部行为。并且很多得不到复用,因为我不知道谁做过。源码级的复用,效率是最低的,也是非常靠不住的。

    9,很难积累

    都是项目,做完就完了。新的项目重头开始,只能部分借鉴历史项目的成果,而且是分散继承。如果沟通不畅,不主动复用和继承,项目上好的东西随着时间的流逝,逐渐丢掉。就像黑瞎子掰棒子,只剩下最后的一个,而且不一定是最大的一个。

    这种模式造成的后果就是,几十年如一次,没有改良,一代代人重复着上一代人的故事,艰难前行。

    要非说优点,这种交付模式唯一的优点是对人的要求低,不要求复用,不要求抽象提升,不要求全面考虑,不要求代码质量有多高,只要满足当前需求,系统能用即可,从某种意义上讲,可以实现快速交付。

    这种开发模式,也许做个别项目,交付会非常快,但是他是以局部利益牺牲全局利益,短期利益牺牲长期利益。不是可持续发展的交付模式。

    二、我们在来说下做产品的交付模式

    现在很多公司都是这种模式,大的ibm,华为,微软,bat等世界知名的企业,小的用友,金蝶等等。你看看哪个公司没产品,而且是一系列的产品。这种交付模式的特点是,一是卖标准产品,二是基于产品做个性化开发,属于半产品。

    1、卖标准产品

    适合那种需求稳定、有标准,供方驱动的领域,适合工具类,系统类或者应用范围比较小的领域。比如财务软件,报表软件,工作流,即时通软件,游戏,各种中间件等等。这类软件功能稳定,比较标准,或者说用户要求不高,一般是用户适应产品而不是产品迎合用户。这种交付模式,交付周期短,边际成本低,利润高。

    2、基于产品的个性化开发。

    在产品的基础上,对需求进行差异化分析,看看产品标准功能和用户需求差异有多大,分析差异点,基于产品给出解决方案,通过配置,或者通过功能组合间接解决,如果实在无法解决,进行个性化开发。这种要求产品要提供个性化定制的功能,比如sap,标准功能提供了很多用户入口,也就是个性化嵌入点。

    这两种模式,要求产品要可以:

    1,产品功能相对完善(满足更多的目标用户)

    2,可配置型强(一定程度上满足用户的个性化)

    3,提供个性化开发点(在产品基础上个性开发,对产品进行增强)

    这种方式的优点

    1,交付周期短。因为有产品,产品部分能满足要求的不需要重新开发

    2,交付质量高,标准功能,经过实战检验,稳定,bug少

    3,能在交付过程中,吸收新的需求,不间断优化系统,使系统越来越强大。

    但是也有缺点

    1,对开发能力要求比较高

    2,对产品的版本控制要求比较高

    3,对产品的管理能力,策划能力要高

    三、产品还是项目?虚假的命题

    从第二种交付模式看,从来就没有单纯的项目交付或者产品交付。

    因此开头的问题就是个假命题,不是二选一的问题。有产品,有定制,有标准功能交付,也有个性化开发的项目化交付。但是中心是,一定有一个功能核心 ,也就是产品。这个产品就像滚雪球的最初的小雪球,是核心,越滚越大。有了产品,那么代码的复用,功能的复用,就水到渠成了,再也不是个人行为,而是组织的行为了,也不是偶然的而是必然的了。这才是最有效的复用。

    四、从项目化交付到产品化交付

    产品化交付,是大势所趋,是解决项目化交付的良药。纯粹的项目交付模式,利润率低,能活下去,但是非常辛苦。员工辛苦,公司艰难。

    1,要有进取心,有决心

    不能得过且过,论堆的思想,呼呼弄弄就这样了,反正这样也可能活,虽然获得不是非常舒坦。

    2、要有理想有追求

    产品开发就是最求完美,和做项目不一样。做产品才是软件开发的本质,才是真谛。项目只是产品核心之外的壳子,是补充。

    3,要有能力

    有了产品的思想,还有开发产品的能力。抽象能力,总结能力,设计能力。只有系统的框架做的完美了,可扩展性强了,才能支持不断在交付中进行优化,进行扩展,才能进行个性化开发。而且个性化开发的部分能与产品有机组合在一起,而不是割裂的。

    产品的管控能力要非常强。严格管理产品的分化,简历产品优化、良性进化的机制。

    从需求搜集,分析,方案设计。哪些功能有普遍意义,可以键入到标准功能中,哪些是个性化的,要有这个辨别能力,这个辨别能力只要有业务专家来担任。要有一批有经验的开发专家,业务专家,共同围绕着产品服务。

    产品研发不容易,产品有局限性,这是一些人反对产品化交付的主要理由之一。"我们项目做得好好的,做产品这么难,也不能100%满足用户的要求,为啥要做产品呢,咱不费那个劲。"

    现在火的一塌糊涂的低代码平台,其实就是基于产品的(可复用组件)的典型的应用,使用已经开发的产品化的、功能稳定的应用组件,来组合搭建复杂的应用系统,而不需要编码或者只需要很少的编码。看到这个,你还觉得前面讲的项目化交付还有生存的空间吗?人家用3个月的工期,完成你12个月的交付,而且质量杠杠的,售后运维成本非常低。慢慢地,就会把项目化交付的生存空间挤占掉。

    也许有人说,人家xxx,现在早就不提产品,而提服务、解决方案了,你还提产品,过时了。要注意,人家提这个,人家经历了产品化之路,积累了大量的产品,激烈了大量的业务经验和解决方案,是有大量的各式各样的产品做支持的,是有底气的,所谓服务,解决方式 ,是产品的组合形成的。人家吃饭,你只看到人家吃第三个烧饼吃饱了,你也想只吃第三个,能坚持一整天?门都没有,想啥呢。

  • 相关阅读:
    云计算的三种服务模式:IaaS, PaaS, SaaS
    Docker 容器备份例子
    软件版本号
    git 命令小总结
    【Oracle】ORA-12560: TNS: 协议适配器错误
    【VMware】The VMX process exited permaturely
    Linux(CentOS)安装SQL Server
    Linux源码编译安装httpd
    Linux安装MySQL
    Linux安装Tomcat
  • 原文地址:https://www.cnblogs.com/senline/p/deliverymode_projorprod.html
Copyright © 2020-2023  润新知