如果软件只有一个版本、一次交付完成，过程就很简单：
乙方软件公司维护，主要工作有：数据库维护。错误修改。功能微调（产品已开发完，要改的地方不多）。
甲方配备两个维护人员就可以。一个人负责汇总修改意见、把用户描述的问题转换为软件公司能理解的问题（不容易），另一个人负责服务器和数据库的日常维护就可以。
如果是一个多版本、多种产品、长周期的开发，情况就很复杂：
一、软件产品实施的四种方式
方式1： 完全交由乙方外包、订做，乙方负责后续维护和升级。甲方给乙方维护、升级对应的工程经费。
这是最常见的。但是项目大，就会使得成本高、周期长。
方式2：甲方自建团队、自行开发。
自建团队的好处是省去了沟通成本，整个开发过程可靠、可控、可行。甲方不是软件公司，自建团队稍微有难度。甲方组建一个小团队，其实不难，问题是小团队的人力成本也相当大，甲方能否承受。
方式3：乙方软件公司做第一版，经过维护对接、升级对接，甲方做第二版。
人们往往以为方式3可行，其实不对。有一个关键问题被卡住了。乙方不给源代码，甲方只能是维护、升级一些辅助功能。如果是涉及源代码修改的功能，没源代码，怎么改。
有了源代码，问题一：源代码的质量。这个源代码写的好不好？如果是一团乱麻，也没法改。少不了用一个新的架构，重做一遍、重新还原。生活中，为一个系统的数据库里加两三个字段，牵一发而动全身，牵连太大。为一个旧软件加功能，没办法的情况下，只能用新技术、新架构重写，重写完了，再添加功能。软件行业的一部经典著作，叫《重构》。
有了源代码，问题二：这个源码所用技术、工具是否新的？主流的、小众的？后续开发的人，必须先掌握对应的技术工具，才能继续往后做。
有无源代码很重要。更重要的是：1. 开发过程优化 2. 技术工具选择 3. 工程模板和同类项目资源
方式4：软件公司A做第一版，另一家软件公司B快速接手、做第二版。多家软件公司并行开发，并且能整合到一个系统中。
多家公司一起合作，公司A的项目被公司B快速接手，都需要源码公开。
如果甲方拿到源码，可以促进项目的快速完成，其实是一件好事。项目问题少、周期短，双方还可以再合作。乙方软件公司可以大方一些，甚至实现几个公司联合开发。大公司有大公司的优势。小公司做项目，也有自身优点。
二、软件成本
一个参考标准：开发：6人x8000（元/月）x10月= 48万
维护成本：界面调整、修改错误、功能调整或添加
一个小问题的修改，非常耗时间，也就是在耗经费。小问题的修改过程：
（1）甲方向乙方反馈错误和问题 ；
（2）乙方制订修改方案、改动代码、测试功能 ；
（3）乙方更新产品；
（4）甲方使用新产品，确认修改完成 。
升级成本：升级是大规模、多个问题的维护。多个小软件，组成一个大型产品。在一个小产品上，添加新功能，需要解决开发、应用、修改等问题。
三、联合开发：
能公开源代码最好。没有源代码的情况下，可以做以下联合开发：
（1）乙方软件公司A，开发主要功能。
（2）业务拆分，乙方软件公司B，并行开发其他功能。
（3）业务拆分，甲方的技术人员，可以开发一些小的辅助功能，协助文档编写，协助制作用户手册、用户操作视频，协助数据库的简单维护。
相比上述联合开发的办法，一个节约成本的办法是：乙方入驻甲方，深刻了解产品业务，预判项目中最需要返工、修改的模块和功能。甲方确定了的需求和软件细节，经常是不合适的、要调整的。更何况是甲方转达给乙方的需求。
三、节约成本
乙方出于稳妥考虑，一般是甲方说做什么、乙方照做。甲方不是软件的最终用户。最终用户、甲方，功能和细节的调整、改错，占去了软件开发过程的大量时间。乙方要为业务重点、难点，提前有所准备。
效果一：第1年，开发版本1，版本1的长期返工、修改. 第2年，开发版本2. 版本2的长期返工、修改
效果二：大幅度减少返工修改。开发时间和成本降低30%。
不公开源代码，也能实现成本降低30%。解决方法是：
(1)开发过程优化。乙方参与需求确定，不只是开会调研，要用axure等工具制作原型。需要原型制作、原型评审、原型试用、原型修改。当用户想要的软件细节确定了，再开发。这样，省去长期的返工、修改，省去在制作中途才发现功能要调整、要改。
(2)技术工具选择。用java，源码不会公开。如果用PHP，工程源码本身就是公开的。node.js、TS、python Django，这些都是脚本语言。
(3)工程模板和同类项目资源。如果有大量模板和同类项目资源，不必从零做起。
如果这三个问题解决好，工程成本、工期都会降低。乙方不公开源码也可以。双方以较低成本完成项目，是一件好事，双方可以继续合作，启动新版本、新项目。
对于同一个项目，高成本、长周期的开发，必然会被低成本、短周期的开发取代。
扫一扫
174
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
