项目管理中可能出现的问题及如何面对!-研发项目管理

>>项目管理中可能出现的问题及如何面对!-研发项目管理

项目管理中可能出现的问题及如何面对!-研发项目管理

引言:当今社会市场竞争激烈,软件开发企业想要占据前列需要在研发管理上下功夫,“向管理要效益”已经成为软件开发企业的共识,研发项目管理在软件企业中的普及也是大势所趋。国内做软件项目管理工具的开发商翼发云近几年发展十分迅速,越来越多的软件开发企业认识到研发项目管理的重要性,能切实有效降低成本,规范软件开发流程,提高软件产品质量。国内研发项目管理系统、敏捷开发管理工具的领导品牌翼发云敏捷项目管理系统采用可视化业务流程技术,支持瀑布模型等传统软件研发项目管理,同时也支持scrum等敏捷开发流程,是理想的敏捷开发管理工具,涵盖软件项目管理工作的整个生命周期。为提高国内软件开发企业的项目管理水平,分享一篇企业管理相关的知识文章。

项目管理中,一些问题如何去解决?

问题有如下

1。如何真正的理解客户的需求

2。需求总是在变化,用户今天看到你的需求说明书及演示界面认为不错,过了几天却提出要加入新需求,再过几天又加点东西,到最后这个软件与开始的那个版本相差很大,成了垃圾系统??

3。每次的需求变更都是口头描述,没有形成文档,即使形成文档客户也不愿意在文档上签字?

4。由于甲方对软件不熟悉,所以某些需求并不是他们真正想要的,而公司由于不熟悉客户的业务,所以也无法对此做出正确的理解

5。甲方很多潜在的需求在项目进行初期不会提出来,但在中后期会提出来,如何处理?

6。需求说明书得不到及时的更新,导致理解的误差和工期的延误

7。需求说明书的具体需求描述不准确,怎么办?

8。项目初期公司提出的需求到中后期又作废,导致大量的无用功,而且需求也不能管理到位,怎么办?

9。如何有效的标识一个需求?

10。用户总是抱怨需求说明书看不懂,只看演示界面,最后验收对需求说明书不予认同?

11。需求调研过程中,客户不配合怎么办?

12。在什么时候建立需求基线比较合适?

13。需求稳定到什么程度可以开始后续阶段的开发?

14。在关于需求的沟通中,非面对面沟通导致需求失真,如何做?

15。客户对软件开发不熟悉,不能提供详细需求,怎么办?

16。需求频繁的变更,需求管理难度很大。。。

17。客户是用户的上级,用户对开发本项目有抵触情绪,在需求调研时不提任何需求,项目如何进行?

18。迭代式开发如何来控制需求变更,如何用面向对象方法来适应需求的变更(不要出现因为需求变更导致设计框架的变更)?

19。怎样对待需求变化后,项目计划、成本和产品竞争力、客户满意度之间的平衡?

20。软件项目的需求稳定度到底怎样?

21。对需求进行跟踪管理,管理的粒度到何种程度比较合适?控制到用例就够了吗?

22。需求变更来自公司高层,出尔反尔,无所适从?

23。新产品软件开发需求获得更加困难,怎样在不确定客户的情况下获取需求?

24。如何应对琐碎的、细节性的(比如不超过1个工作日,但是又频繁发生的客户变更要求)需求变更?

25。需求变更的审批流程很长,影响工期了,怎么办?

26。用户管理层角色与操作层角色的角度不同,对同一个功能的需求可能是冲突的,如果照顾了管理角色,这个系统就不适用,如果照顾了操作层,管理人员又可能不在验收上签字,怎么办?

结果:

1。如何真正的理解客户的需求?(一个很开放性的问题~:))

a.需要有行业专家的支持,不然不容易理解客户的真实需求

b.对需求调研人员需要很强的沟通、学习能力,特别是要会听,能够识别各种需求描述中的真实内容

c.不断的确认需求记录

d.要认真、准确、结构化的记录客户的需求

e.第一次进入一个行业,没有行业知识和背景,做行业项目的风险是很大的,很可能抓不住客户真正的需求

f.使用图形化的文档进行和客户交互,可以增加和客户的共识

g…….

-------------------------------------

2。需求总是在变化,用户今天看到你的需求说明书及演示界面认为不错,过了几天却提出要加入新需求,再过几天又加点东西,到最后这个软件与开始的那个版本相差很大,成了垃圾系统(不知道这么维护这个系统了~)??

a.需要建立需求基线,双方都要签字认可,并尊重这个基线

b.如果做一个新的行业系统项目,出现这种情况的可能性很大(这叫交学费~)。

c.在发生这种情况的时候,应该适当的引导客户,有专业软件公司的判断,不能说加需求就很快的答应下来,即使答应下来,也不要轻易承诺实现的时间点,需要认真评估后,再答应具体的提交时间

d.如果在做需求过程中,需求能稳定到80%,发生以上情形的可能性会下降

e.需求的有效性非常重要:很可能第一次定义需求就已经出错了,要重视第一次需求的定义,讲究清晰、准确、无二义。

f.使用用例加图片的方式来编写需求说明书,可以提高需求确认的可能性,也会减少这种情况的发生

g……

-------------------------------------


3.每次的需求变更都是口头描述,没有形成文档,即使形成文档客户也不愿意在文档上签字?

a.这个方面需要由一个正式部门提出,并记录下来,并且通过一定的上级部门了解需求变更的资料,而不是有变更马上就去完成.

   而是通过一次确认的过程.

b.加强需求变更流程管理,提高项目管理人员的水平.

18。迭代式开发如何来控制需求变更,如何用面向对象方法来适应需求的变更(不要出现因为需求变更导致设计框架的变更)?

a.要控制软件架构的稳定性,软件架构应该灵活的适应多数的变更,做这个架构要能够预见到大多数的变更

b.首先实现最底层,关联性大的功能和特性,建立基本的稳定架构

c.面向对象的设计的松耦合,强内聚的特性可以降低软件组件变更的可能性

d.迭代式开发是应对需求变更的一种好的方式,特别是XP开发方法(拥抱变化)

e.架构不稳定的情况下,需求变更导致的开发工作量、测试工作量是很难预期的

f.有不少稳定的软件架构模式(比如:MVC)可以相当程度的适应需求变更,有效使用设计模式,可以提高软件架构的稳定性,相当程度的适应软件需求的变更

g…….

-------------------------------------
scrum


19。怎样对待需求变化后,项目计划、成本和产品竞争力、客户满意度之间的平衡?

a.可以通过专家估计来评估成本,工期,满意度之间的关联关系

b.如果有历史度量数据库,将更好的量化需求变更和成本、进度、工作量之间的关系

c.不可能100%的答应客户需求变更请求,即使这样客户满意度也不一定高,老板也不答应 :)

d.要分析变更的需求会影响哪些角色的利益,平衡各种涉众之间的冲突,不同方式的应对需求的变更,尽可能提高关键客户的满意度。

e.软件实现要适应客户企业的文化,才可以融入客户的环境,也可以提高客户满意度

f.在软件行业还没有像建筑行业那样为每个需求变更买单的行业惯例。

g.使用项目管理工具来计算需求变更导致的工期、成本、进度的影响

h.对于琐碎的需求变更,比如界面上的细微调整,在开发过程中需要适当的满足,否则会影响客户的配合度和满意度的

i……..

-------------------------------------


20。软件项目的需求稳定度到底怎样?

a.需求在整个开发过程中都是在变化的,需求变更肯定会发生的

b.在开发初期,需求的稳定度大约在60~80%之间

c.客户在项目过程中也在逐步理解这个系统,所以需求也会演化

d.软件项目的需求稳定度低于传统建筑工程行业的需求稳定度

e.应该和客户达成这样的共识,在需求稳定到60~80%的程度,就可以进行下一步的开发工作,后续的按照变更管理流程来有效的管理变更。

f.在需求开发过程中,用完美主义的方式做是不行的,至少在中国多数的软件企业的项目开发(非产品开发)中是这样的

g.软件需求中的不同内容,变化频率是不同的,业务模型是最稳定的,业务流程相对稳定,业务表现(报表。。)是最容易变化的。

h…….

-------------------------------------
软件项目管理


21。对需求进行跟踪管理,管理的粒度(单位)到何种程度比较合适?控制到用例就够了吗?

a.不要把需求的非常细节的内容作为需求项来管理,否则工作量非常大

b.对于细节的需求(比如界面上的按钮表现)可以用图形方式来表现。

c.如果用例分解的粒度适当,可以把用例作为需求项进行管理。

d……

-------------------------------------


25。需求变更的审批流程很长(比如一个月),导致了工期的风险,怎么办?

a.如果对于大的项目,其中的变更审批流程长是很正常的,比如银行系统。应该适应客户的工作方式

b.如果有行业专家,可以很大程度的规避这种变更,没有行业专家,需求变更就会比较频繁,花在变更审批上的时间会很多。

c.在合同阶段建立约定,在一定程度上加快客户的变更审批流程

d.变更一定要在审批通过后才可以进行,否则就很可能返工

e…….

-------------------------------------


敏捷开发流程

文章从互联网整理而来,旨在传播scrum、软件项目管理、研发项目管理、敏捷开发管理工具的知识与应用,帮助软件开发企业真正了解研发项目管理的价值和意义,如果本文侵犯了您的权益或者您需要具体了解更多国内做研发项目管理系统的公司翼发云敏捷项目管理系统的相关信息,欢迎和我们联络:

【网址】www.effapp.com

2018-03-05T23:50:59+08:002018-03-05 23:50:59|Categories: scrum项目管理|