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

Obuntu

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

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

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

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

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

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

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

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

bobo307135136

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

客户刚开始其实是不清楚系统应该做成什么样子，只有当我把把软件开发出来，他们才知道是不是他们想要的东西，做为项目经理或者需求人员要注意引导客户，朝着客户可以接受和技术可以实现的方向去引导，这是一个技巧，需要经验，特别是现在的甲方，都很强势；所以需求调研很重要，设计很重要，DEMO很重要，用户签字很重要；

2.对于一套基本完全开发的系统，在进度控制上需要注重哪些要点？

整体规划，分步实施，确定好里程碑、关键业务、并行任务、串行任务，分清楚轻重缓急…………

Tomac

针对上述案例需要讨论的话题是：
1.如果用户的需求出现变动，或者出现反复时，有哪些有效的控制方式？
统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，不能卷入你们内部业务部门之间的矛盾之中；

這種方式只是局部適用, 有些情況就不太適用了.

Tomac

针对上述案例需要讨论的话题是：
1.如果用户的需求出现变动，或者出现反复时，有哪些有效的控制方式？
统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，不能卷入你们内部业务部门之间的矛盾之中；

這種方式只是局部適用, 有些情況就不太適用了.

trigger_lau

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

针对上述案例需要讨论的话题是：
1.如果用户的需求出现变动，或者出现反复时，有哪些有效的控制方式？
统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，不能卷入你们内部业务部门之间的矛盾之中；
---这一点在国企基本做不到，你会发现没有人出来负责，没有人给你明确的意见，但是总有人有意见。

所有需求变更全部要有书面文字，这点切记！这样做好处多多：
*有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的；
*便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的；
*对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了；
-----除非是特别的关节点，如果不断的让用户给文字性的东西，在国企基本是不可能的，邮件是基本不回的，谁也不想留什么证据。
以上两条，虽然难弄，但是把握好度就可以迎刃而余了。

系统开发告一段落后，就进入客户培训、系统验收阶段
一般来说，客户是懒的，这就是他花钱找你做事情的原因。一个项目的成败，和客户的配合程度很有关系。
作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。一般说来，项目经理在考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，把项目控制在一个合适的范围内，让客户从理想回到现实也是项目经理的分内工作。
---这一点很认同，项目经理必须清楚自己想要什么，不要想着不犯错，目标才是第一位的。


引用 书上说的
MIS软件项目经理应具有三种协调关系：
一、协调好和客户的关系
二、协调好和上级的关系
三、协调好和下属的关系
MIS软件项目经理应具有的四个能力：
一、学会引导客户
二、对客户需求的认知及把握开发进度估算
三、如何有技巧地说不和点头
四、计划与实际现场运作的时间点观念及协调统一


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

            开发速度 = 已完成工作量 / 已耗费时间
            当前进度 = 已完成工作量 /总工作量
            剩余时间 = 剩余工作量 / 开发速度 = （总工作量 - 已完成工作量） / 开发速度
-----实际工作中，这些公式只能作为参照，还是需要把握好要点，特别是那些影响全局的要点。

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

trigger_lau

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

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

整体规划确实很重要，在开发的过程中还需要注意留有接口，以应对变化的需求。开发计划是很重要的，只有一个好的计划及及时的跟踪才能确保住进度。

trigger_lau

jimn1982 发表于 2012-9-27 05:21
1,客户的需求是可以控制的，怎么控制看能力了，可以分期做，当然就可以分期收钱了，大公司就是这么干的。
...

1,客户的需求是可以控制的，怎么控制看能力了，可以分期做，当然就可以分期收钱了，大公司就是这么干的。
-----分期做有利于搞清楚情况，当然了，也能多挣些钱。一般预算都有限制，分开做也能看着项目金额小点。
2,客户的需求前期要调研清楚，当然在项目过程中可能还会有新的需求，这就是第一点说的。

3,客户的需求是要和客户确认的，必要要有书面的东西存在。不然就死无对证了。
-----这个在很多公司只能是尽量，就算书面的东西，最后也是你的问题。
4,客户的需求不能有求必应，而要有所选择。必要时需要推到上层。
------有时真的需要顶上去，不然最后出问题了还是自己的问题。
5,项目进度控制，如果需求清楚，分期规划好那么进度是可以控制的。不控制进度那么项目经理就是失职的，或者说是失败的。
----哈哈！对头！
6,在一套管理软件的实施过程中，有哪些要点是需要特别关注的？
实施人员与客户的沟通最重要。

------是呀，不同企业还需要不同的沟通方式。

trigger_lau

Obuntu 发表于 2012-9-27 13:48
1.如果用户的需求出现变动，或者出现反复时，有哪些有效的控制方式？

这也要看用户需求出现了什么变动。 ...

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

这也要看用户需求出现了什么变动。如果是合理的变动，你敢不让他变？不然开发完了，又是一大堆事。
-----合理不合理很难说清的。
一般出现变动的时候，估计是问题还没想清楚，这点在实际做开发前，其实要做好梳理和澄清，引导用户发现他们真正的需求，能让方案稳定下来，这样对后续的开发过程来说也是有好处的。

如果确实复杂，用户也实在是无法在一开始就明白需求，加上项目进度紧张，那其实开发过程中就要进行调整。
-------问题总会有的，关键是要考虑好对系统整体的架构有没有影响。所以，能够控制好架构的方案师很重要。

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

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

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

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

呵呵，都想着白纸黑字，有时只能是想想的

trigger_lau

bobo307135136 发表于 2012-9-27 18:10
1、如果用户的需求出现变动，或者出现反复时，有哪些有效的控制方式？

客户刚开始其实是不清楚系统应该做 ...

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

客户刚开始其实是不清楚系统应该做成什么样子，只有当我把把软件开发出来，他们才知道是不是他们想要的东西，做为项目经理或者需求人员要注意引导客户，朝着客户可以接受和技术可以实现的方向去引导，这是一个技巧，需要经验，特别是现在的甲方，都很强势；所以需求调研很重要，设计很重要，DEMO很重要，用户签字很重要；
------对于搞不清爽的客户，开始的时候一定是要做个毛坯出来，然后再完善，不然真是有问题。

2.对于一套基本完全开发的系统，在进度控制上需要注重哪些要点？

整体规划，分步实施，确定好里程碑、关键业务、并行任务、串行任务，分清楚轻重缓急…………

-----把握好重点很重要。

trigger_lau

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