管理软件的实施浅析之一
做为一个初级的软件实施人员,经过度日如年的实施过程,总结的一点小东西,希望对大家有点帮助。
我认为管理软件的应用客户根据他们上系统的目的可以分为三种:
一、客户公司已经具备了一个上软件系统的条件,客户上信息管理系统的要求非常强烈(主管,经理,总裁),并且尝试着上过一些小型的信息系统,或者购买过一些固定行业模式的管理软件,但是并不成功。
二、客户第一次引进系统这个概念,一切都在摸着石头过河。
三、客户只是在做一个企业信息化的门面,由于客户所处的环境和客户的合作资源要求客户上一个系统,客户只是在装饰一自己的公司,表明自己没有out。
我认为客户方的软件项目经理在项目的实施过程中起着举足轻重的作用,根据他们的资质可以分为二类:
一、名存实亡,形同虚设
这种项目经理的存在有利也有弊。利是我们可以掌控全局。弊是所有的客户方协调工作都得我们去处理。实际上我们做了两个公司的项目经理。假如我们控制的不好的话,所有的黑锅都会背在我们的背上。
二、强势的客户项目经理。
这里又分两种,一是一个强势的热心的智者。二是一个强势的愚笨的对项目软件一窍不通的混蛋。前一种人会把项目引导上一个新的高度,有利于快速的完成实施。作出合乎客户方的软件,皆大欢喜。后一种就很可怕了,他一个人的主张可能会使做出来的软件在半年内遭到客户的遗弃。项目失败,也可能半途而废。但是假如我方实施项目经理非常厉害的话就不好说什么结论了
我先说一下第一种客户公司:
先说一下第一种客户,他们已经形成了自己对系统的固定认识。想上我们的系统,但是需要按照他们的模式做二次开发,增加,并且修改软件的流程,功能模块。
这些客户会非常的配合我们的工作,但是在关键要求实现的功能上毫不让步,因为可能在他们的眼里,我们的系统要非常的符合他们的意愿,而他们不会跟着我们的系统走。因为通过他们以前上的一些系统,他们模糊的知道了他们的需求。但是需要落实到开发文档,需要 频繁的修改确认。然后开发出来他们会需要会有严格的确认,核对。他们不会敷衍了事。
对这些客户,在项目实施的前期,要做好非常详细的需求分析,但是可能这个过程比较困难,因为他们的主观意愿是清晰的,是具有强的坚持性,原则性的。但是他们的具体需求是比较模糊的。所以要尽量的了解清楚,形成一定的设计思路。在项目实施的前期,要求他们提供尽可能详细的资料格式,业务表单。也许通过这些业务表单我们会更贴切的了解到他们的需求和对系统的期望。这种表达是真实的。比语言说的要清楚。或者我们可以针对这些表单进行我们有目的的深入交谈,了解业务的来龙去脉。
在项目实施的中期,可能会有许多的事情冒出来,影响项目的进度,比如说客户的业务比较繁忙,不能够按时配合我们的实施工作。会打断原计划的实施时间安排,一般是推迟。比如说在项目实施的过程中会推翻原来的需求,提出新的更棘手的需求,但是必须得需要系统做。比如说某些需求在调研初期无法确定明确的业务方式,随着项目的不断推进出现而逐渐明确,需要作出设计方式,方案。还有客户方项目负责人的更换(这是最糟糕的)。无论出现那种情况,时间都会不停的向前走。我们必须紧紧的掌握住项目的进度。项目实施是累人的,残酷的,为了进度,必须加班加点。
在项目实施中有一点是非常烦人的对于客户和我们来说都一样。那就是不断的确认。确认系统的需求是否正确。确认客户提供的资料是否准确。确认我们的设计思路是否正确。确认设计出来的东西是否是客户想要的,满意的。确认我们的设计计算,控制方式是否合理。确认我们我们软件界面的布局是否合理,客户处理起来是否顺手。然后就是不断的签字确认。直到客户会烦恼的问,你们软件公司的做事方式是否就是不断的确认。然后我们肯定的点点头。这时他们就会I服了YOU。其实大多数时候的确认并不是我们为了不承担责任,推脱责任。而是客户提出的有些问题是不经过周密考虑的,或者提出的并不很全面。所以我们要落实到确认签字上。这样他们才会认真的考虑一下。假如他们拒绝不签的话,那就是这件事情还需考虑(证明客户提出的设计要求不严密,不全面),或者这事根本就不靠谱。那这样的事情就我们就不能做详细的开发。所以我认为确认工作一定要做好,无论是提供的资料的准确性(假如客户提供的资料不准确时,会影响后面的测试。也可能影响前面的开发)还是提供的开发需求的准确性。而在不断确认的过程中也会消耗一定的实施时间。
在项目的实施过程中还有一点就是要学会说不。学会说不不是说这个问题系统解决不了。而是要结合客户的实际情况作出说不的决定。我认为在三种情况下说不客户会同意。第一种就是花费10万元钱开发一部分系统功能来处理客户一年才回出现一次的业务(出现的概率很少,但是这种业务不按照一般流程来走)。第二是开发出来后在系统中做需要十个人做十分钟,而手工做只用一个人一分钟就做出来的业务(不必所有东西都上系统)。第三也是最重要的一点,假如在系统开发实现这个功能很麻烦的话,我们要替客户想出一个实际的管用的招来,让客户很方便的手工处理,必要时给客户找找什么辅助软件也好。其实大家的目的只有一个。快速的处理业务。
结项是项目实施中最艰难的时刻。项目的调研是否扎实,周密,会影响整个项目的进度。伴随其项目的整个实施过程。而项目的整个实施过程决定了项目结项是否会干净利落。几乎所有的项目都不会干净利落,呵呵。这个时候所有的以前做过的确认,项目日志全部就成了陈堂供词。一个好的实施日志文件能很清楚的记录一个项目的实施过程,过失,责任,棱角分明。结项要最大限度的做到皆大欢喜。那叫完美。
做为一个初级的软件实施人员,经过度日如年的实施过程,总结的一点小东西,希望对大家有点帮助。
我认为管理软件的应用客户根据他们上系统的目的可以分为三种:
一、客户公司已经具备了一个上软件系统的条件,客户上信息管理系统的要求非常强烈(主管,经理,总裁),并且尝试着上过一些小型的信息系统,或者购买过一些固定行业模式的管理软件,但是并不成功。
二、客户第一次引进系统这个概念,一切都在摸着石头过河。
三、客户只是在做一个企业信息化的门面,由于客户所处的环境和客户的合作资源要求客户上一个系统,客户只是在装饰一自己的公司,表明自己没有out。
我认为客户方的软件项目经理在项目的实施过程中起着举足轻重的作用,根据他们的资质可以分为二类:
一、名存实亡,形同虚设
这种项目经理的存在有利也有弊。利是我们可以掌控全局。弊是所有的客户方协调工作都得我们去处理。实际上我们做了两个公司的项目经理。假如我们控制的不好的话,所有的黑锅都会背在我们的背上。
二、强势的客户项目经理。
这里又分两种,一是一个强势的热心的智者。二是一个强势的愚笨的对项目软件一窍不通的混蛋。前一种人会把项目引导上一个新的高度,有利于快速的完成实施。作出合乎客户方的软件,皆大欢喜。后一种就很可怕了,他一个人的主张可能会使做出来的软件在半年内遭到客户的遗弃。项目失败,也可能半途而废。但是假如我方实施项目经理非常厉害的话就不好说什么结论了
我先说一下第一种客户公司:
先说一下第一种客户,他们已经形成了自己对系统的固定认识。想上我们的系统,但是需要按照他们的模式做二次开发,增加,并且修改软件的流程,功能模块。
这些客户会非常的配合我们的工作,但是在关键要求实现的功能上毫不让步,因为可能在他们的眼里,我们的系统要非常的符合他们的意愿,而他们不会跟着我们的系统走。因为通过他们以前上的一些系统,他们模糊的知道了他们的需求。但是需要落实到开发文档,需要 频繁的修改确认。然后开发出来他们会需要会有严格的确认,核对。他们不会敷衍了事。
对这些客户,在项目实施的前期,要做好非常详细的需求分析,但是可能这个过程比较困难,因为他们的主观意愿是清晰的,是具有强的坚持性,原则性的。但是他们的具体需求是比较模糊的。所以要尽量的了解清楚,形成一定的设计思路。在项目实施的前期,要求他们提供尽可能详细的资料格式,业务表单。也许通过这些业务表单我们会更贴切的了解到他们的需求和对系统的期望。这种表达是真实的。比语言说的要清楚。或者我们可以针对这些表单进行我们有目的的深入交谈,了解业务的来龙去脉。
在项目实施的中期,可能会有许多的事情冒出来,影响项目的进度,比如说客户的业务比较繁忙,不能够按时配合我们的实施工作。会打断原计划的实施时间安排,一般是推迟。比如说在项目实施的过程中会推翻原来的需求,提出新的更棘手的需求,但是必须得需要系统做。比如说某些需求在调研初期无法确定明确的业务方式,随着项目的不断推进出现而逐渐明确,需要作出设计方式,方案。还有客户方项目负责人的更换(这是最糟糕的)。无论出现那种情况,时间都会不停的向前走。我们必须紧紧的掌握住项目的进度。项目实施是累人的,残酷的,为了进度,必须加班加点。
在项目实施中有一点是非常烦人的对于客户和我们来说都一样。那就是不断的确认。确认系统的需求是否正确。确认客户提供的资料是否准确。确认我们的设计思路是否正确。确认设计出来的东西是否是客户想要的,满意的。确认我们的设计计算,控制方式是否合理。确认我们我们软件界面的布局是否合理,客户处理起来是否顺手。然后就是不断的签字确认。直到客户会烦恼的问,你们软件公司的做事方式是否就是不断的确认。然后我们肯定的点点头。这时他们就会I服了YOU。其实大多数时候的确认并不是我们为了不承担责任,推脱责任。而是客户提出的有些问题是不经过周密考虑的,或者提出的并不很全面。所以我们要落实到确认签字上。这样他们才会认真的考虑一下。假如他们拒绝不签的话,那就是这件事情还需考虑(证明客户提出的设计要求不严密,不全面),或者这事根本就不靠谱。那这样的事情就我们就不能做详细的开发。所以我认为确认工作一定要做好,无论是提供的资料的准确性(假如客户提供的资料不准确时,会影响后面的测试。也可能影响前面的开发)还是提供的开发需求的准确性。而在不断确认的过程中也会消耗一定的实施时间。
在项目的实施过程中还有一点就是要学会说不。学会说不不是说这个问题系统解决不了。而是要结合客户的实际情况作出说不的决定。我认为在三种情况下说不客户会同意。第一种就是花费10万元钱开发一部分系统功能来处理客户一年才回出现一次的业务(出现的概率很少,但是这种业务不按照一般流程来走)。第二是开发出来后在系统中做需要十个人做十分钟,而手工做只用一个人一分钟就做出来的业务(不必所有东西都上系统)。第三也是最重要的一点,假如在系统开发实现这个功能很麻烦的话,我们要替客户想出一个实际的管用的招来,让客户很方便的手工处理,必要时给客户找找什么辅助软件也好。其实大家的目的只有一个。快速的处理业务。
结项是项目实施中最艰难的时刻。项目的调研是否扎实,周密,会影响整个项目的进度。伴随其项目的整个实施过程。而项目的整个实施过程决定了项目结项是否会干净利落。几乎所有的项目都不会干净利落,呵呵。这个时候所有的以前做过的确认,项目日志全部就成了陈堂供词。一个好的实施日志文件能很清楚的记录一个项目的实施过程,过失,责任,棱角分明。结项要最大限度的做到皆大欢喜。那叫完美。