[庆站庆]如何管理好一个完全开发的管理软件项目？

alexkidder

纯支持！

xin2v

针对上述案例需要讨论的话题是：
1.如果用户的需求出现变动，或者出现反复时，有哪些有效的控制方式？
统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，不能卷入你们内部业务部门之间的矛盾之中；
所有需求变更全部要有书面文字，这点切记！这样做好处多多：
*有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的；
*便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的；
*对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了；
系统开发告一段落后，就进入客户培训、系统验收阶段
一般来说，客户是懒的，这就是他花钱找你做事情的原因。一个项目的成败，和客户的配合程度很有关系。
作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。一般说来，项目经理在考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，把项目控制在一个合适的范围内，让客户从理想回到现实也是项目经理的分内工作。
引用 书上说的
MIS软件项目经理应具有三种协调关系：
一、协调好和客户的关系
二、协调好和上级的关系
三、协调好和下属的关系
MIS软件项目经理应具有的四个能力：
一、学会引导客户
二、对客户需求的认知及把握开发进度估算
三、如何有技巧地说不和点头
四、计划与实际现场运作的时间点观念及协调统一


2.对于一套基本完全开发的系统，在进度控制上需要注重哪些要点？
项目进度管理中，要遵循的就是如下三个公式，任何一个懂得小学数学的人都可以完成：

            开发速度 = 已完成工作量 / 已耗费时间
            当前进度 = 已完成工作量 /总工作量
            剩余时间 = 剩余工作量 / 开发速度 = （总工作量 - 已完成工作量） / 开发速度


3.在一套管理软件的实施过程中，有哪些要点是需要特别关注的？
进度 和需求 其实就是1和2  还有搞好和关键人物的关系

WOLFRAMM

项目都是领导们在开会，农民们在干活，然后农民不知道领导开了什么会，领导也不知道农民干了什么活，然后项目就结束了，除了一大堆代码，任何正式文档看不到农民的名字。
很多时候农民干完活好几个月了，领导们还在开会。。。

1983yu

客户的需求是不能控制的
项目的进度是反反复复的
项目实施过程中最重要的是薪水奖金能按时的。。。

book6

         对于全新开发的系统，最开始要做好需求分析，明确业务部门所提出的需求。根据需求设计软件功能和界面，系统流程。如存在很多系统，还需要做整体规划，减少重复开发造成资源浪费。制定开发计划，如果需求比较复杂且是长期的，可分阶段、分版本开发。对于用户需求的经常变动，通常是需求不明确，或者用户本身就没有了解清楚，所以一定要反复的讨论明确。做好开发计划，确定人工时。在一套管理软件实施的过程中，最重要的是人的因素，确定专人负责跟进，明确分工，保证质量，上线之后持续跟进。评定实施效果，总结经验。

fan12

前排占座

jimn1982

1,客户的需求是可以控制的，怎么控制看能力了，可以分期做，当然就可以分期收钱了，大公司就是这么干的。
2,客户的需求前期要调研清楚，当然在项目过程中可能还会有新的需求，这就是第一点说的。
3,客户的需求是要和客户确认的，必要要有书面的东西存在。不然就死无对证了。
4,客户的需求不能有求必应，而要有所选择。必要时需要推到上层。
5,项目进度控制，如果需求清楚，分期规划好那么进度是可以控制的。不控制进度那么项目经理就是失职的，或者说是失败的。
6,在一套管理软件的实施过程中，有哪些要点是需要特别关注的？
实施人员与客户的沟通最重要。

arron刘

xin2v 发表于 2012-9-26 13:11
针对上述案例需要讨论的话题是：
1.如果用户的需求出现变动，或者出现反复时，有哪些有效的控制方式？
统 ...

不错

jjkol1

book6 发表于 2012-9-26 14:18
对于全新开发的系统，最开始要做好需求分析，明确业务部门所提出的需求。根据需求设计软件功能和界 ...

支持下 关键在于开发之前做好需求分析分析并得到确认，需求留档涉及关键部门签字确认。做好项目计划，内部严格按照定制目标前进，每一段时间要内部和外部汇报项目进度（比如每周的某一天），另外交付时间要充足，必须预留测试时间。开发过程中逻辑必须清楚，千万不能在似懂非懂的情况下来设计，所以建议有专人开发，专人负责业务。

Obuntu

1.如果用户的需求出现变动，或者出现反复时，有哪些有效的控制方式？

这也要看用户需求出现了什么变动。如果是合理的变动，你敢不让他变？不然开发完了，又是一大堆事。

一般出现变动的时候，估计是问题还没想清楚，这点在实际做开发前，其实要做好梳理和澄清，引导用户发现他们真正的需求，能让方案稳定下来，这样对后续的开发过程来说也是有好处的。

如果确实复杂，用户也实在是无法在一开始就明白需求，加上项目进度紧张，那其实开发过程中就要进行调整。

像现在很流行的敏捷开发方法，其主要目标就是拥抱变化，适应变化，其中有一条就是“响应变化，胜于遵循计划”。例如1）把需求进行合理的划分，分成一个个比较细的story，如果某个需求发生变化了，那也只影响到其中的一个部分，对整体进度影响也不会很大。2）合理安排迭代，每个迭代只做部分的功能，这样如果有变化时，就能快速调整了。3）及时让程序运行起来，经常保持与用户沟通，接收用户的反馈，能尽快的做出调整，做出变化。

如果好好思考下自己的研发方式，有时候发现用户需求的变化，也确实不是什么很恐怖的事情。

其他如果出现反复的，而且是一些非主要功能的变化，能往后放当然就往后放。

当然，需求变化都是要白纸黑字，邮件来邮件去，而且要很正式的行动。。。各种扯皮的时候用的上：）