新的软件项目,成功的开端,决定了成功的一半!(需求和计划)-研发项目管理

>>新的软件项目,成功的开端,决定了成功的一半!(需求和计划)-研发项目管理

新的软件项目,成功的开端,决定了成功的一半!(需求和计划)-研发项目管理

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

刚看完”无问西东”,电影里说人总归还是要留下些足迹(文字)的,那么赶紧跑图书馆来留下些文字。

最近去瑞士启动了一个新的项目,那么早上做项目,晚上总结留下了一张张思维导图来记录当时的感受, scrum

手稿如下,字写得不好请见谅:)

全新的软件项目,好的开始决定了成功一半!(需求&计划) 软件项目管理

首先你得知道这个软件写出来是做什么的,因为不同的应用场景对软件要求是千差万别的。 敏捷开发流程

例如,机械控制?那可能需要实时性高;订票系统?那需要并发性好,还有数据准确性要高;购物系统?简单,好看,好用,操作不反人类……

所以第一重要的东西就是,Domian Knowledge领域知识。 研发项目管理

领域知识

领域知识,怎么获得?当然是找三类人(产品经理,领域专家,服务工程师)。

产品经理:是他定义的产品,他当然一般知道用户的关注点和痛点是什么,他一般也是在这个行业中摸爬滚打了很多年,你让他给你讲这个行业是个什么情况,

这个产品大概应该做成什么样子,为什么要做这个产品,他一般都有自己的一些想法(当然有时候也不是非常全面的)

领域专家:他一般知道客户生产产品的流程,知道客户会怎么使用系统来帮助他们提高产品质量或生产效率,他也知道这个行业的基本技术水平在个什么高度(现在市面上的软件能帮客户产品做什么方面的管控,如何提高生产效率和产品质量),也知道按照客户流程这个产品应该怎么做测试

服务工程师:也就是你这个软件产品交付给客户使用之后,他们负责和客户交互,解决使用和简单技术问题。所以客户的一些反馈,客户如何真正使用软件,以及客户心情他们是都知道的。他们是软件使用的老师傅。

抓住这三类人,你将获得巨大的领域知识,这样你提供给客户的功能不再只是可运行的系统,而是在不断的给客户提供价值。

要求的文件

人都是靠需求驱动的,马斯洛归纳了人类的5大基本需求。软件当然也不例外,软件也是靠需求驱动的,粗略的可以分成两大类–功能性需求和非功能性需求。

所以需求文档必须包含这两部分。

功能性需求:主要描述系统的行为要求。这个一般产品经理都会写,只是详略程度各有区别。

非功能性需求:主要描述系统的性能要求。

性能要求一般包括:易用性,效率性,维护性,安全性,可扩展性,等。

性能要求看似不起眼,而且很多情况下产品经理会漏掉定义这些。然后性能要求其实是驱动软件架构最重要的元素,所以项目开始这些也要定义清楚。

拿到需求之后有以下这些动作是要做的

  • 需求说明:读产品经理写需求文档,然后每次需要使用你自己的语言再次向产品经理,看看你的理解是否正确,有问题直接回答这些问题,因为迟早,答案是由项目上的风险造成的。在提出问题的过程中,你会发现许多产品经理的需求不想彻底。你问问题帮助他思考,当然,帮助自己不要写无用的代码。
  • 需求行优先级:需求必须具有优先级和释放最小功能集。如果你不能挖掘出这两件事,你很难在这个项目中取得成功。如果产品经理说有些需求很重要,请给他100元,然后说:“如果你只有100元购买软件功能,请分配100元来满足不同的需求,它的资金越多,它就越重要。”。之后,您就可以自然地知道需求的价值和粗略的优先级。另一个重要的策略是在获取需求文档后获取最小集。你说:“如果我们的手是有限的,我们只能提供软件最基本的功能。”。请告诉我哪些功能是必不可少的在线软件。之后,您可能知道该项目的范围。这样,一个有经验的项目经理可能会及时知道产品上市的可行性。
  • 需求文档要经过前两个步骤,项目目标、可行性和实际需求要比以前清晰多了。之后,项目经理通常会让开发团队产生一个项目评估。我只能告诉你,这个时候的估计一般不太准确,但我们可以试着提高估计的准确度。这里有一个技巧是需要使用用户故事(https://www.mountaingOAtsoftware.com/agile/user-stories)的方式来描述:作为…(角色)我想要(函数)..所以…那…(目的)被用作我需要什么样的工作的角色,这个功能的用途是什么?。可以发现,当一个产品经理问一个要求时,你最想问的是:“你为什么想要这个功能,谁来使用这个功能?”那么他通常如何使用它呢?当然,有时候,你为什么想要这个功能?“这听起来有点咄咄逼人,但这是个好问题:”
  • 有了上面的用户故事,您的团队就可以开始估算了。最好是估计一般使用计划扑克。当软件有技术困难时,一般时间将不准确。所以我建议我们尽早研究系统的困难。在那之后,我们才能真正知道它有多复杂。也许很简单。人们对自己不知道的事物总是有恐惧感,估计有时会估计出一个“天文数字”;。估计不只是一次。第一个估计是看人的手是否足够,技术点不是太大,不太在乎准确性。估计量可以不断修正,你知道的越多,就越准确。
  • 需求的利益相关者:虽然这个项目在最后,但它是最重要的:)确保参与项目的涉众处于同一个理解水平,这是同一页上的。因此,我们应该要求所有利益攸关方同时开会。我们对整个项目有相同的理解,我们可以就项目的范围、目标、时间和质量达成一致意见,以便继续进行以下工作。不要孤立或遗漏重要的利益相关者,也不要开小讨论。很容易浪费时间,无法达成共识。该项目是注定要失败的。有一些重要的决定,请邮寄,文件或签证。

后输出的需求

  • 当需求被固定时,一般可以生成基本的系统架构,这就开始进行技术研究或相关的编码。
  • 当需求是固定的,一个一英里的石头和一个可交付的计划通常是生产-这之前,相应的测试和其他资源的安排。

该项目的成功最重要和最重要的部分是写在这里。

角色定义和授权

  • 这是非常重要的。有了角色定义,项目的职责就有了很好的发挥作用,其他人也可以找到相应的有问题的人,也可以消除一部分人,不管他们自己的事情,总是盯着别人看。
  • 授权也很重要,每个角色都有什么权利,定义的哪些方面有很好的定义,在这个领域中不会有任何歧义,或者资源没有被听到。

需求文档 — 描述了做什么,什么不做,做的假设是什么

用户故事描述需求–可以捕捉,这个功能是谁要的,为什么要这个功能

软件架构设计–架构设计怎么来满足需求中的非功能性需求和功能性需求

估算–用来给项目计划提供支撑和合理安排资源

项目计划–给管理层一个时间节点和期望,相应的时间节点做资源安排等

后面找时间写后面几篇:

–全新的软件项目,好的开始决定了成功一半!(架构设计)

–全新的软件项目,好的开始决定了成功一半!(团队)

最后给大家show一下我在瑞士买的本子,我喜欢用思维导图捕捉思想,在瑞士偶遇了这个本子,大小纸张都很合适:)

全新的软件项目,好的开始决定了成功一半!(需求&计划)

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

【网址】www.effapp.com

2018-02-10T22:51:31+08:002018-02-15 11:26:00|Categories: scrum项目管理|