惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Hacker News - Newest:
Hacker News - Newest: "LLM"
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
L
LINUX DO - 最新话题
Cloudbric
Cloudbric
N
News and Events Feed by Topic
S
Secure Thoughts
Vercel News
Vercel News
S
Security @ Cisco Blogs
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
S
SegmentFault 最新的问题
Hacker News: Ask HN
Hacker News: Ask HN
博客园 - 聂微东
WordPress大学
WordPress大学
Google Online Security Blog
Google Online Security Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Google DeepMind News
Google DeepMind News
PCI Perspectives
PCI Perspectives
雷峰网
雷峰网
Hugging Face - Blog
Hugging Face - Blog
Blog — PlanetScale
Blog — PlanetScale
Apple Machine Learning Research
Apple Machine Learning Research
C
CXSECURITY Database RSS Feed - CXSecurity.com
T
Threat Research - Cisco Blogs
博客园 - 司徒正美
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
A
About on SuperTechFans
P
Proofpoint News Feed
大猫的无限游戏
大猫的无限游戏
V
V2EX
I
Intezer
H
Hacker News: Front Page
www.infosecurity-magazine.com
www.infosecurity-magazine.com
L
Lohrmann on Cybersecurity
F
Fortinet All Blogs
Schneier on Security
Schneier on Security
博客园 - 叶小钗
The Cloudflare Blog
月光博客
月光博客
W
WeLiveSecurity
T
Tenable Blog
P
Proofpoint News Feed
aimingoo的专栏
aimingoo的专栏
Help Net Security
Help Net Security
L
LangChain Blog
C
CERT Recently Published Vulnerability Notes
T
The Exploit Database - CXSecurity.com
美团技术团队
B
Blog

博客园 - Arthur_wuancheng(大步牛)

练手之作:易元威客任务发布系统(2) 练手之作:易元威客任务发布系统(1) 人生一世 草木一秋 项目管理的一点总结 极限编程法一点思考 WEB Service 下实现大数据量的传输 (转) 项目经验(转) Atlas 学习笔记: ajax 改进 by Atlas ajax for .net in vs2003 like gmail ^_^ 存储过程分页,以及动态sql(Sql server) C# 2.0 New Feature(1) WebService Enhancements 2.0 Learning Note ref type & out type Duwamish架构分析篇 (转) 程序编码应保持良好的规范(C#)(转) 也谈代码规范 (转) 如何用正确的方法来写出质量好的软件的75条体会 [转] How to Write to Database by EnterPriseLibrary2005 Logging Application Block(项目心得) 自己正在做电信的互联星空项目,里面用到的xml
如何进行高效的项目管理?(转)
Arthur_wuancheng(大步牛) · 2008-04-27 · via 博客园 - Arthur_wuancheng(大步牛)

 笔者涉足项目管理已有一段时间,而且通过CMMI培训和实践,笔者对项目管理中的需求获取、人员配置以及项目管理中需要注意的问题有一些想法,在此与大家共享之。
一.             需求获取
需求开发在CMMI中有一个专门的过程域来描述,它在项目管理过程中也是很重要的一块,因为后续的设计、开发等都是基于需求。如果需求获取不正确或在需求开发过程中很多功能没有挖掘出来的话,那么在后期选择弥补时,将会造成项目延期以及成本的大幅度增加。
需求开发的目的是产生和分析客户、产品和产品组件需求。需求是客户在项目立项时就有的一个远景,在项目管理过程中它得到不断的变更和细化。客户根据需求会决定在整个项目的需求中,要承办方具体要做些什么,即承办方的任务, 承办方具体要实现哪些需求。 承办方在明确了需求后,就会开始后期的设计、开发、测试、部署等工作。
需求获取的目的是通过各种途径获取用户的需求信息,由于在实际工作中,大部分客户是无法完整地讲述其需求,因此需求获取是一件看似简单,做起来很难的一件事情。在需求获取过程中,主要需要弄清楚3个问题,即:明确需要获取的信息(What)、明确所获取信息的来源和渠道(Where)和怎样获取需求(How)。下面我们分别对这三点进行讲述。
1、明确需要获取的信息(What)
需求分析师应在需求获取前明确需要获取的信息,以确保在实施需求获取时有的放矢。
通常需求获取要获取的信息包括三大类:
1)与问题域相关的背景信息(如业务资料,组织结构图,业务处理流程等);
2)与要求解决的问题直接相关的信息;
3)用户对系统的特别期望与施加的任何约束信息。
2、明确所获取信息的来源和渠道(Where)
接着需求分析师还应确定获取需求信息的来源与渠道,以提高需求分析师在需求获取阶段的工作效率,使得所收集的信息更加有价值、更加全面。
需求信息的来源通常包括:
1)来自客户的需求:
a)       旧系统的用户或客户对系统安装、使用、维护、管理等方面的需求;
b)      系统的潜在用户或客户对系统的需求。
2)竞争对手的产品优势与不足;
3)国家政策、业务规则以及相关行业标准;
4)实施产品设计所需满足的需求;
5)执行测试验证工作所需满足的需求;
6)实施系统安装、维护所需满足的需求。
获取需求信息的渠道包括:
1)用户或客户;
2)公司研发管理部门;
3)公司技术管理部门
4)项目实施部门;
5)营销管理部门;
6)旧有系统的研发项目组;
7)  来自项目组内。
3、怎样获取需求(How)
接下来项目经理应选择至少一种需求获取技术获取相关的需求,作为需求分析的依据。需求获取技术包括但不限于:
1)  用户访谈
用户访谈的形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题,有针对性地进行;非结构化是只列出一个粗略的想法,根据访谈的具体情况进行发挥。有效的访谈需要灵活的结合这两种方法。
用户访谈具有很好的灵活性,有较广的应用范围,但实际操作时存在许多困难,例如客户经常很忙,难以获得充足的访谈时间;客户访谈需要需求分析师有很强的沟通能力,同时也要求需求分析师有足够的相关业务领域知识。
2)  用户调查
用户调查是通过精心设计提问问题形成调查问卷,然后下发到相关人员手中,让他们填写答案,来获取用户需求。
用户调查的方法最大的缺点是缺乏灵活性,由于缺乏面多面的交流,所获取的信息量也比较有限。因此在实际工作中,我们建议可以先采用用户调查的方式获取一定量的信息,然后有针对性地开展用户访谈。
3)  现场观摩用户的工作流程,观察用户的实际操作
俗话说,“百闻不如一见”,对于一些较为复杂的流程和操作而言,是比较难以用语言和文字进行表达的,对于这种情况,可以采用到客户的工作现场,一边观察,一边听客户讲解,从而更直观的了解客户需求。
4)  从行业标准、规则中提取需求
如果用户要求所开发的软件产品必须满足一定的行业标准和业务规则,需求分析师可以通过阅读政策法规、业务规则以及行业标准等各类相关的文档,并与相关领域的业务专家进行业务交流来了解客户的需求。
这种方法要求需求分析师有一定的行业从业经验,能够了解行业的发展动向,这对从技术出生的需求分析师来说是一个巨大的考验。
5)  文档考古
对于一些数据流比较复杂的、工作表单较多的项目,有时是难以通过说或者观察来了解需求细节的。这个时候就可以通过对历史存在的一些文档进行研究,考古一词非常形象地说明了其主要的工作重心是通过已经填写完毕的、也就是带有数据的文件、表单、报告,获得所需的信息。
6)  需求讨论会
这是一种相对来说成本较高的需求获取方法,但也是十分有效的一种。它通过联合各个关键客户代表,分析人员,开发人员,通过有组织的会议来讨论需求。
在会议之前,应该将与讨论主体相关的材料提前分发给所有将要参加会议的人。在会议开始之后,先针对材料所列举的问题进行逐项专题讨论,然后对原有系统、类似系统的不足进行开放性交流,并在此基础上对新的解决方案进行构思,在此过程中将所有的想法、问题和不足记录下来,形成一个要点清单,作为后续需求分析的依据。
7)  原型法
原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”,以可视化的形式展现给用户,及时征求用户意见,从而明确无误地确定用户需求。同时,原型也可用于征求内部意见,作为分析和设计的接口之一,可方便于沟通。原型法主要价值是可视化,强化沟通,降低风险,节省后期变更成本,提高项目成功率。
原型法的优点是:
i)鼓励业务管理者的积极参与;
ii)有助于解决业务管理者之间的差异;
iii)能给业务管理者一个对最终系统的直观感受;4)周期短;5)成本低;6)用户较满意。
但原型法也有缺点,主要为:
i)导致人们认为最终系统将很快产生;
ii)对系统操作权限的说明较弱;
iii)不适合于开发大系统;
iv)开发过程管理困难。
       在实际开发过程中,笔者所在公司一般比较常用的需求获取方法是用户访谈、需求讨论会和原型法。对于相对较小的项目,笔者极力推荐原型法,因为通过可视化的界面,可更容易的、更快的挖掘客户的需求。
二、人员配置
在整个项目的生命周期中,可能涉及到开发方的角色如下:
1、需求分析师
完成产品或项目的需求调研和开发,将客户的需求变成产品需求,参与需求的讨论和分析,完成需求规格说明书等的编写。
2、系统架构师
系统架构师负责理解系统的业务需求,并创建合理、完善的系统体系架构。架构师也负责通过软件架构来决定主要的技术选择。这典型的包括识别和文档化系统的重要架构方面,他侧重于系统的质量属性设计,包括系统的可靠性、可测试性、可重用性、可维护性、可重用性、可扩展性、性能指标、组件框架设计、共用基础结构等。
3、系统分析员
该角色是系统设计中的一个主要角色,他参与需求分析、系统功能设计、系统质量属性设计等过程。
4、项目经理
项目经理是项目沟通的纽带,他执行项目的进度跟踪、质量管理、客户非技术人员业务交流、项目成员共同、非技术风险管理等职责。
5、配置管理员
该角色的职责是完成项目中各文档的管理等。
6、QA
重点关注软件过程的质量,在项目中,主要执行的是监督的作用,他参与需求评审、设计评审等过程。
7、开发人员
完成系统的编码,在有些公司,开发人员还需要进行部分功能模块的设计。
8、测试人员
进行系统的测试,例如功能测试、集成测试、系统测试和验收测试等,在测试前期,需要编写测试计划,并编写测试用例来辅助测试。
9、美工
负责美化系统界面。
10、项目实施人员
职责为进行项目的实施。
根据项目的大小等的不同,上面的人员配置可能有一些合并,例如在一些较小的项目中,可能会将系统架构师、系统分析师、项目经理的职责都统一到项目经理身上。在一些项目中,若具有系统架构师、系统分析师和项目经理三个角色,有一些人也很容易搞混,在网上有人进行了比较明确的区分,下面让我们来看看下面的表格:

系统架构师

系统分析员

项目经理

需求分析

Y

系统功能设计

Y

系统质量属性设计(包括可靠性、可测试性、可维护性、可重用性、可扩展性等)

Y

Y

制定进度计划

Y

Y

进度跟踪

Y

指定质量目标

Y

Y

质量目标跟踪

Y

客户非技术业务交流

Y

客户技术交流

Y

成员沟通

Y

采购

Y

成本

Y

Y

Y

合同管理

Y

技术风险管理

Y

非技术风险管理

Y

三、项目管理中需要注意的问题
大家都知道,项目管理的四要素为:质量、进度、成本和资源。这四项如果有一项超出控制,项目就可能会失败。在笔者的实践过程中,总结了如下注意事项:
1、明确各人员的任务
明确各人员的任务并对其进行确认。例如,对各开发人员任务的详细分配后,有些开发人员并不一定清楚了自己所要做的事或理解有出入,做到后来,才发现所做的和项目所需要的南辕北辙,到了这个时候才发现问题,补救不及时的话很可能引起进度的拖延和成本的增加,所以项目经理需要进行确认。
2、跟踪项目情况
很多开发人员都有这样的情况,前期开发比较轻松,一到要验收的时候,才发现很多功能还不完善,存在很多bug,于是为了在指定时间内完成任务,只得加班加点。其实这也是管理不善引起的,因为没有定期的跟踪项目,对项目所处的状态不太清楚,所以导致了这种情况。
3、进行风险分析和管理
在项目管理过程中,风险分析也是一个很重要的方面,风险包括很多方面,例如技术风险、人员风险等。若在项目管理不注意风险的管理,那么当项目中的风险发生时,很可能引起项目管理的四要素的问题出现。例如若项目组盲目引入新技术,在中后期才发现该新技术在该系统中不合适。再例如,若在项目后期主要设计或开发人员跳槽,若没有风险管理,没有采取规避或减弱措施,那么当这些风险产生时,将会带来很大的影响。
4、重视需求开发
有些项目组对需求开发不太重视,做需求开发时没有深度挖掘客户的需求,在中后期还在进行需求的大幅调整,在进度等方面当然也会受到很大的影响。需求是后续开发的根本,后续的设计、开发、测试等都是基于它的,因而也是重中之重,需要引起大家的重视。
       本文浅析了项目管理过程中需求开发、人员配置以及项目中需要注意的问题,项目管理是一个很复杂的过程,需要项目组各成员的努力。

三、项目管理中需要注意的问题
大家都知道,项目管理的四要素为:质量、进度、成本和资源。这四项如果有一项超出控制,项目就可能会失败。在笔者的实践过程中,总结了如下注意事项:
1、明确各人员的任务
明确各人员的任务并对其进行确认。例如,对各开发人员任务的详细分配后,有些开发人员并不一定清楚了自己所要做的事或理解有出入,做到后来,才发现所做的和项目所需要的南辕北辙,到了这个时候才发现问题,补救不及时的话很可能引起进度的拖延和成本的增加,所以项目经理需要进行确认。
2、跟踪项目情况
很多开发人员都有这样的情况,前期开发比较轻松,一到要验收的时候,才发现很多功能还不完善,存在很多bug,于是为了在指定时间内完成任务,只得加班加点。其实这也是管理不善引起的,因为没有定期的跟踪项目,对项目所处的状态不太清楚,所以导致了这种情况。
3、进行风险分析和管理
在项目管理过程中,风险分析也是一个很重要的方面,风险包括很多方面,例如技术风险、人员风险等。若在项目管理不注意风险的管理,那么当项目中的风险发生时,很可能引起项目管理的四要素的问题出现。例如若项目组盲目引入新技术,在中后期才发现该新技术在该系统中不合适。再例如,若在项目后期主要设计或开发人员跳槽,若没有风险管理,没有采取规避或减弱措施,那么当这些风险产生时,将会带来很大的影响。
4、重视需求开发
有些项目组对需求开发不太重视,做需求开发时没有深度挖掘客户的需求,在中后期还在进行需求的大幅调整,在进度等方面当然也会受到很大的影响。需求是后续开发的根本,后续的设计、开发、测试等都是基于它的,因而也是重中之重,需要引起大家的重视。
       本文浅析了项目管理过程中需求开发、人员配置以及项目中需要注意的问题,项目管理是一个很复杂的过程,需要项目组各成员的努力。