Learning Time

【读书笔记】关于项目管理的一些思考——对《项目百态》的理解(一)

一直以来都很喜欢读Tom DeMarco的书,他的书很少有教条的理论,而是着重于对项目管理的本质进行剖析。前段时间看了《项目百态——深入理解软件项目行为模式》,总体感觉不错,适合想要了解软件项目管理、企业管理、软件工程的人员。本书并没有采用逻辑的结构阐述某个观点,而是将一些经验和理念分散到不同的行为模式中,让读者自己去发掘,这点比较有意思。本书还用大量的篇幅进行了组织文化方面的探讨,令人印象深刻。

本文是对书本的内容做一些回顾,对书中的观点加入了自己的理解,算一篇读书笔记,也算是对最近思考的一些总结。

1.需求是一切的源头

1.1把握真实的需求是一个艰难的互相学习的过程

虽然最终交付物的功能或性能指标全部满足,但如果最终用户反映产品“不好用”,那依然是个失败的项目,通常这种失败源自需求分析阶段的工作。

对于软件项目来说,用户交互是非常重要的一环,在范围界定时就应明确的反映出来,并持续给予关注,及时调整。这里的用户交互并非单指UI或UE,交互设计固然重要,但把握到用户“真正的需求”,即,最终产品如何与客户业务相结合,则更为重要。

头痛医头脚痛医脚看起来是最省心省力的,但资源的浪费也是最可怕的,同时,最终用户还不买账。集中精力研究真正的需求,解决真正的问题,结果才能事半功倍,否则,项目最终只会贴满创可贴并被人遗忘在某个角落。

如果希望项目最终产生正确的产品或服务,必须深刻理解消费者的需求和支撑那些需求的特性。这种理解只有当消费者和开发者各自向对方学习的时候才会出现,而最难做到的就是让所有干系人意识到同心协力互相教学的必要性。

我们都知道,在项目开始的时候就指望每个项目干系人能想象出最终产品的样子是不现实的,希望统一这些人的想法就更不可能。因此在搜集需求的时候,往往是一个团队和客户互相了解、互相学习的过程,但是,以下一些障碍会阻碍这个进程:

1.客户太过熟悉自己的工作,因此对某些细节视而不见--因为他们以为开发人员已经知道了。

2.客户也许不具备良好的沟通技能,无法正确或精确的表达自己的意图,也许会对不停的提问变得不耐烦。

3.客户在没看到实物的时候去想象自己到底想要什么东西是极其困难的。

4.事先签署的需求规格书会让客户背负责任,因此,他们不得不强行指定许多内容,以免遗漏了什么东西。最终,需求收集者退化成了抄录员,双方没有了探索性的互动。

5.营销阶段的解决方案很少能解决真实的、更高层次的需求,要知道,它不是真实的东西,它也只不过是想象出来的而已。

6.没有及早开始互相学习,等到干系人脑海中的想法已经定型,改变就变得非常困难,再去学习新的东西也越来越难。于是,项目失去了创新的基石。

1.2想探寻真实的需求,请尽早并尽快向客户提供原型

很少有人愿意从零开始,但大多数人都是不错的改良者,因此,我们应该尽早并尽快的树立一个稻草人让客户进行批判,甚至我们应该故意做出一些错误的东西来测试客户的反应,原型的作用是一种需求钓饵,让我们可判断客户重视的点在哪里,其设计哲学在于尽早犯错,频繁犯错。

原型会带来以下回报:

1.每次评审之后,如果我们都使用新的原型设计来替代掉旧的(重新设计原型),可能会得到更好的主意。

2.对原型不停的改进,最终或许会得到一个完美的设计。

3.原型或者就是客户需要的(别指望它会发生,如果发生了,一定是奇迹,如果是奇迹,就要小心了——你可能在其它地方犯错了。)

1.3小心范围蔓延——需求或特性并不是越多越好

Peter Keen的论文描述过这种现象:那些想要挫败新项目的人没必要冒着风险跳出来反对。恰恰相反,他们可以通过提议数十个能够“帮助项目达成卓越目标”的附加特性和改进措施,给项目以最积极的投票。

实际上,每个人都自然而然的认为自己的需求是最重要的,因此在项目中不断加入新的、无关痛痒的特性,而这些零碎加入的特性并没有考虑到产品的一致性,没有考虑如何去与实际的业务结合,并且这些特性的成本/收益未知。虽然这些建议看上去富有建设性,但这种行为增加了项目的风险和成本,间接增加了项目死亡的可能性:项目的目标开始变得不清晰,产品的定位开始模糊,项目成员对进度、变更做出决定的方式不一致,等到产品发布的时候,已经没有折中或挽回的余地了,最后只能将一锅大杂烩交付给客户。

这种情况的产生从本质上来说,是因为项目对于“什么是属于范围内的”以及“什么是超出范围的”没有客观定义,所以额外的需求很容易从不同的来源渗透进来。避免这种情况的发生需要做到以下几点,并且团队的所有人都应该培养这种意识:

1.尽可能早的,干脆利索的定义项目目标和非项目目标。

2.声明项目范围,并以“精确定义输入/输出数据”的形式时刻保持更新。

3.拒绝那些对目标没有积极效应而又明显超出项目范围的需求。

4.遵循变更流程,对新加入的需求进行评估。

另外,采用迭代方式并经常进行特性评估的团队能够在一定程度上避免出现此类情况,因为每次评估会强制重新排定特性的优先级。团队可以选择一些具备高优先级的特性加入到项目中,另外一些会被暂时搁置到下一次评估或直接放弃,一直到列表中只剩下成本高于收益的特性,这个时候项目或许就可以宣告完工了。

1.4最终兵器:找一个关注产品和业务结合的人

很多项目失败是因为缺少一个人专门负责并确保最终的业务流程——从用户的角度来看——尽量顺利地开展。

所以,项目中需要存在这样一个人:他不需要为预算或计划负责,只关注产品如何与目标环境交互,特别是产品与最终用户的交互。他负责用户体验的一致性,并且这种工作贯穿整个项目的始终。这个人关注的是整个项目对于客户而言的最佳的结果,一直到最细微的细节。他可以不是团队内部的成员,也许是客户方的人员,但只要有一个人不断的询问子项目之间的协同状况,就足够了。


===============

其它章节

关于项目管理的一些思考——对《项目百态》的理解(一)

关于项目管理的一些思考——对《项目百态》的理解(二)

关于项目管理的一些思考——对《项目百态》的理解(三)

关于项目管理的一些思考——对《项目百态》的理解(四)

关于项目管理的一些思考——对《项目百态》的理解(五)

关于项目管理的一些思考——对《项目百态》的理解(六)

关于项目管理的一些思考——对《项目百态》的理解(七)


评论

热度(10)