Learning Time

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


6 项目经理的自我修养

6.1 项目经理的风格:感性、理性和中庸

感性的项目经理关注成员的精神状态,宏观的项目行进方向,使用富有情感的沟通方式,使用开放性结论,倾向乐观主义,不再整体框架内谈论细节。

理性的项目经理关注项目的基本状态,使用数字说话,对事务进行条理分明的分析,给出确定的结论、建议和计划,几乎任何评论的都是可衡量的。

中庸的项目经理处于两者之间。

6.2 项目经理不是记者

记者只负责报道真实情况,而项目经理的职责是:保证项目达成目标。

一些项目经理对项目的情况了如指掌,但却假设项目失败也与己无关,他们坚持认为了解项目情况并汇报给上级是他们的职责,这些人显然是不合格的项目经理。项目经理首先要确保项目的成功,报告只是达成目标的一种手段,而不能用来代替目标。

况且,一个好的项目报告并不仅仅是反映项目进展情况而已,它应该是有结论和观点的:

不使用海量数据:仅使用经过慎重选择的,有限的衡量指标。

重点信息和次要信息层级鲜明:帮助团队找到关键点。

提供结论:而不只是数据的堆积。

除了反映现实情况,还能够预估未来。

反映出趋势:时间、数量等等。

各项衡量指标有明确的定义:每个成员都应该清楚指标代表什么,避免产生误解。

6.3 当好团队的保姆

一个优秀的项目经理除了分配任务,制定计划,寻求最佳的资源组合之外,还应扮演团队保姆的角色,让团队成员能够不受打扰的专注在项目上。他们为成员提供最好的工作环境、帮助员工提高工作技能、为员工设定合适的挑战、保障团队不受外来事务的影响。

糟糕的项目经理是这样的:他们热心解决(或参与)办公室政治、专注于行政管理和流程管理。在他们看来,与领导沟通、绘制各类图表比与成员沟通更重要,还有不少人,承担了太多的实际工作,而不是腾出时间去解决团队的需求。

6.4 神一样的项目经理对组织来说未必是好事

如果一个项目经理总是能让各方满意,则组织需要注意的是,这些完美的工作到底是依赖于团队的运作还是项目经理的个人能力?如果是后者,对组织来说并不是健康的发展方式。作为项目经理来讲,在工作中也应该逐步建立起团队合作的机制,培养一些管理人员和领导人员,而不是亲力亲为管理所有的事项,虽然在某些组织中,对手下放权和培养可能会对自己的地位造成冲击,但这是一个合格的领导人必须要做的事情。

6.5 在第一时间说不

出于政治因素,大多数时候项目经理都不得不应承一个又一个新加入的需求,虽然他明白加入新的东西,不断扩展项目范围会拖慢进度,增加投入,最终使项目陷入泥潭,但这是一个关乎“项目交付物”和“政治影响力”的两难选择,是项目经理必须面对的问题。

人们虽然都听过“少即是多”,但心里总还是会认为“多才是多”。从公司层面来看,当人们奇怪为何公司的发展如此缓慢的时候,检视一遍自身正在做的事情是有必要的,也许正是因为有太多的项目、产品、战略拖慢了公司的脚步,才使之最终一事无成。

6.6 做个发明者

即便是显而易见的好主意,对于组织来说,也不会很快被接受。人本质上是不愿意改变的,由人组成的组织则更抗拒变化,他们会不停的论证新的想法,分析风险,而迟迟不愿行动,越庞大的组织越是如此。但这并不是组织的错,毕竟新的想法即使再好也只是理论上的,而实施的风险和成本是组织必须要考虑的。

解决之道是把自己从倡导者变成发明者。提出一个好点子的人是倡导者,而不断提出好点子的人则是发明者,正是这个区别使某些人与众不同。从倡导者转变为发明者需要的是实实在在的努力,这或许需要很久,而正是因为这一点,也会使人们更愿意接受你的想法,因为它经过了考验。

把创新变成自己的基因吧,当组织里有越来越多这样的人,组织自然就存在了这样的特点,而无须费尽心机去寻找“创新”。

6.7 学会关注细节

许多公司希望追求完美的产品,因此他们到处挖人,并妄图去压榨设计师的智慧,这种做法效果甚微。实际上,完美的设计不仅在于设计人员,还受到经理的极大影响。如果一个经理关注细节,当他用心去欣赏某人的作品,也许会发现许多此前未曾注意的细节,两人会因此获得某种默契,这时,经理在设计人员的眼里就不再是个不错的经理,而是“值得一直跟随的老板”,最终形成良性循环,设计人员会更加努力,不仅仅是为了追求完美的设计,还为了获得自己所认同的人的欣赏。


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

其它章节

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

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

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

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

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

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

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


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

5.项目80%的工作是沟通

5.1 沉默不代表同意

每个人对于承诺的内容以及什么代表承诺都有着不同的理解,当某人提出要求时,另一人沉默,是否能代表他们互相达成了协议呢?当然不是,这种误解导致了项目中各类突发事件的发生。一个行之有效的方法是:公开声明少量的重要承诺,写下来,共享给相关人士。承诺者与被承诺者应确保对内容和遣词用句的理解是一致的。

只有说了“同意”,才是真正的同意。

5.2 选择合适的沟通方式

无论何时何地,语言沟通都是最有效的沟通方式,而书面则是最有效的记录方式,团队需要做的就是:说,然后写下来。

不要迷信任何一种沟通方式,任何方式都有适用的场景和范围,大公司也可以用快捷高效的对话完成决策,小公司也会将延续性的决策记录在案。

避免成为邮件狂人:在大公司或分布式团队中,邮件成为主要的沟通方式,慢慢的,人们会认为处理完邮件即完成了工作,越来越多的人被加入到抄送列表,通常的后果是,能够在一个简短会议上决定的东西在邮件中争论了几天也得不到解决。

5.3 让接口保持统一和简单

项目中复杂的人类接口容易导致复杂的产品接口。所以我们需要定义每一个接口,避免不同的人对接口做出不同的假设。需要定义的接口不仅仅是产品的,还有团队和团队之间,工作组与工作组之间,人与人之间的。

5.4 冲突总是存在,它并不意味着沟通失败

由于每个人的想法是不同的,所以在工作中总会存在冲突,但很多人会将冲突归咎于沟通问题,来转移真正的冲突,其潜在的观点是:我们是同事,因此我们不应该有冲突,如果出现不同的看法,那一定是我们沟通不够。但实际上,大家都很清楚彼此的想法,但却讨厌对方的看法。为了避免成为“不够职业的人”,人们宁可放弃去想办法有效的解决冲突,而是把精力放在了努力改善沟通上,这通常是于事无补的,冲突一直在那里,即使你千方百计的想要避开,但最终还是会无可避免的面对它。


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

其它章节

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

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

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

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

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

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

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


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


4.项目的最终目的是交付好的产品

4.1产品设计的美学

在产品设计中追求尽善尽美并不是镀金,而是一种态度。

镀金强调的是不断的通过堆叠特性或无必要的外在装饰,而追求美的设计只能通过减少特性来实现。最好的设计都是简洁的、功能明确的、易于测试的。即便对其进行修改,也不会带来新的麻烦。它会让你觉得没有比这更好的方式来实现产品的功能了。

 “美到极致不是增无可增,而是减无可减。”------Antoinede Saint-Exupery

4.2尽早修复那些低质量的数据

随着时间的推移,系统中存储的数据会因为变更的不断发生而导致质量下降,通常这类问题会拖延至无法修复的程度,然后再来一次成本高昂的“全面整理”。

对底层来讲,数据修复意味着逐个核对并改正错误的数据,而消息在传递到组织高层时被美化了,高层会认为数据修复是通过某种很巧妙的手段将错误的数据一下子就改正过来,所以我们在发现问题产生的时候总是倾向于去修复软件而不是数据本身(因为数据总是多的可怕,而软件总是易于修复的),最终,资源被投入到了“更巧妙”的方式上,比如变更软件的某种处理方式,但修复软件带来了更多的变更,因此导致数据质量进一步下降。

所以,数据质量降低的问题一旦被发现,就应该在第一时间进行修复,否则将积重难返,未来会付出重大的代价。


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

其它章节

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

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

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

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

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

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

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


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


2.人是一切的基础

2.1 让团队参与招聘

招聘是需要团队合作的项目。无论招聘什么职位的人员,寻找一个真正合适的人从来都不简单,但往往又很重要。

对于招聘,大多数公司是这么做的:HR找人,约人,第一轮面试,应聘者的未来上司进行第二轮面试,然后决定是否聘用此人。不过,如果想要打造一个以团队合作为价值核心的组织,或许可以考虑让团队的成员参与其中。

初步筛选仍是需要的,或许是HR,或许是经理,或许是团队中的某个核心成员,比如技术最强的那个,或许是以上方式的组合。通过筛选的应聘者接下来将面对整个团队,团队成员作为面试官对可能在未来成为同事的人进行提问,甚至让应聘者暂时加入团队一起工作几个小时,最后大家一起决定是否接纳应聘者。也许团队成员都认为不错的人会因为经理出于其他考虑最终进行了否决,但一个团队成员都不认同的人,很明显经理没有任何理由去雇佣他。

以上的做法至少有以下几个好处:

1.当前团队成员绝对不会被迫接受自己不愿意与其共事的人,他们有否决权。

2.应聘者能更加了解团队,他可以接触到未来的同事而不仅仅是老板,也可以了解真实的工作情况,感受公司的文化。

3.经理可以借鉴团队对应聘者的评价而不仅仅依靠自身的揣测,同时他也会知道团队在一定程度上接受了新员工,而这意味者个人在领导和管理方面的成功。

4.作为整支团队,成员在参与同事预审的过程中可以向其他人学习,参考其他人使用的问题和标准,即“我的同事究竟在意哪些方面”,这有利于未来自己在团队中进行调整,还可以在以后的面试中把这些派上用场。经理也能对自己的成员的思维方式有更深的了解。 


2.2 年轻人能带动整个组织的节奏

年轻人可以使组织变的更有活力,更愿意学习和提高。

从成本上看,雇佣年轻人的成本较低,但培养的成本很高,不过,这仍然是值得的,除非组织已经放弃成长。


2.3 尽量把团队成员放在一起

面对面的沟通永远比其他手段要好,很多时候,一个眼神的效果好过一封描述详尽的电子邮件,因为那代表着信任。所以,应该尽可能的把团队成员放在一起,至少是需要频繁进行接触的那些成员。


2.4 记得设定人员储备

出于成本的考虑,组织倾向于使用最精简的人员组成团队,但是一旦项目出现意外,则很容易面对没有替补的状况。项目的损失是显而易见的,最重要的是时间的损失,特别是在项目的中后期,没有任何办法可以弥补这种损失,而如果有参与整个项目的替补队员的话(不需要深度参与),便可以迅速到位,给团队一个“用金钱换取时间”的机会。


2.5 专注才有生产力

对于雇主来说,支出的是员工薪水,购买到的并不是员工的时间(你不知道员工的时间利用率和使用效率)、能力(你无法对能力的价值进行评估)、忠诚(SB老板才会想要这个)诸如此类,你购买的是员工的“全神贯注”,即单位时间内最高的产出率。

为了保证你买到的东西的份量,你必须保证员工在工作的时候能够全神贯注。许多公司采取了一系列措施来保证这一点,良好的工作环境(消除对人不舒服的影响)、丰厚的薪资和福利(消除私人事件对工作的影响)、改进的流程(减少与产出无关的工作)等等。

对于项目来讲,特别是当组织有太多项目在同步进行的时候,还应该尽量避免将某个员工加入不同的项目组,工作内容和背景的切换将占据员工大部分的时间和精力,而这些是无法产生任何东西的,只会被无端端的消耗掉,因此,如果有可能的话,让员工专注于一个项目。


2.6 引导那些能干的员工

有的员工是这样的,他非常聪明能干,喜欢挑战,愿意帮助其他同事做一些他职责范围之外的事。这种人喜欢和大家一起并肩战斗,他热爱工作本身,而跟金钱无关。虽然他并不总是薪水最高的那个人,但薪水是无法激励他的,他也不会为了薪水而跳槽。

作为这种员工的经理,对他的管理很容易,但更容易犯错。通常一个员工很能干的时候,经理会倾向于把更多的、更重要的工作移交给他,而一旦工作变成一种负担,他就再也无法感受到工作的乐趣并最终会选择离开,公司也失去了最好的员工。能干的员工是很容易找到工作的,但组织显然很难找到一位如此之好的员工,所以最终组织失去的要更多。

对于这类员工,经理的角色就是引导他去从事他感兴趣的工作,帮助他排除工作以外的干扰,仅此而已。


2.7 那些越权的人或许是最宝贵的成员

工作中有3种事情:1、明确规定要做的;2、明确规定不要做的;3、无明确规定的。

经理在安排工作的时候,总是尽量避免任务重叠或冲突,也避免产生漏洞,但无可否认的是,要精确的限定任务的每一部分几乎是不可能的,所以那些无明确规定的事情到底由谁去做变成了一个问题。

有些人谨小慎微或中规中矩,他们只做那些明确规定要做的事情,这无可厚非。有些人不但做了明确规定要做的事情,还会去做那些无明确规定的事情,在他看来,为了完成项目,这些都是必须要做的事,甚至,他还会要求批准去参与那些明确规定不要做的事情(通常他们都会有极好的建议才会这么要求)。这类人是团队的宝贵资源。


2.8 团队内部的通用语

太多的项目失败是由于沟通产生的误解,因此,人们醉心于如何统一人与人之间的沟通方法,他们制定了术语表、发明了UML之类的东西试图让所有人对某一个词汇有共同的理解,但效果往往差强人意。

实际上,最好的通用语是在团队内部慢慢形成的,成员们一天又一天的重复某个话题,互相熟悉和理解对方给予某个词汇的定义,调整各自的语法和表达方式,最终形成团队内部的、每个人都理解的通用语。然后,他们会提炼再提炼,将这些定义固化。

因此,任何团队都不会一开始就存在通用语,试图复制其他人创造的通用语也注定失败,只有让团队自己进行磨合,才能有效的改善沟通,减少误解。


2.9 绩效考核总是粉饰过的

在由项目经理提交的绩效报告上,几乎所有人都处于“高于平均”的平均水平,没什么人特别拔尖,也没什么人特别差劲,整体看起来一切都很好。很显然,这是不可能的。

这是因为,即使经理按照HR的标准公正的进行考评,仍然会有意无意的得出错误的结论,比如,A员工的工作一团糟,团队又不可能在项目进行中减少人手或另外换人——那只会增加风险和成本——因此经理不得不将A的工作量调低,并把一些困难的工作移交至其他人,这样,A慢慢就可以将手头的比较简单的工作做的比较好了,也因此,A的绩效得到了提升,但实际上,我们都知道那并不代表他真的做的很好。

这种绩效评定的方式很容易产生不公平的现象:

首先,对于那些卓越的员工来说,你没有让他们知道他们到底有多优秀,他们看到的是,在考核结果上,自己与一群平庸之辈挤在一起,至少没有拉开距离。

其次,对那些糟糕的员工来说,你没有及早让他们知道他们到底有多差,也错失了弥补和改进的机会,有时候,糟糕的绩效并不意味着个人能力的问题,也许是因为双方对工作的理解有误。

最后,对那些中庸的员工来说,没有拉开距离的绩效使他们做出错误的判断,无法对自身进行改善,并且,由于处于中档的人数太多,自认绩效良好的人会认为自己被低估,自认绩效较差的人会认为自己做的已经足够好了。

 

无论如何,这种方式都会对员工的积极性造成大范围的打击,没有人从中受益。因此,如果必须要进行绩效考核,那就不要吝啬给卓越的人奖励,不要担心给糟糕人警告,基于实际的平均水准,讲出事实,对所有人都有好处。另外,如果要进行绩效考核,那组织就必须考虑如何对工作内容进行定级(重要程度、优先级、难度等)。


2.10 远程管理团队

越来越多的组织将团队分散到世界各地,而管理这些不同地点的团队带来了很多麻烦,虽然人们对于这种模式有不同的观点,但是无可否认,这种方式大大增加了沟通成本,带来了许多不必要的风险。以下一些建议对这种模式也许有用:

1.本地迭代。对于需要快速迭代的工作,最好还是由同一地点的团队完成。

2.做好生产率在最初会下降的心理准备,团队需要时间来适应新的合作模式。

3.认识到其他地点的团队与本地团队没有区别。他们同样喜欢富有挑战性的工作,而不喜欢仅仅被当作廉价劳动力。

4.树立各个地点的目标。让统一地点的团队有些精神上的追求和共同的目标(这一点无论对远程团队还是本地团队都是很重要的)。


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

其它章节

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

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

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

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

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

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

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


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

一直以来都很喜欢读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最终兵器:找一个关注产品和业务结合的人

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

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


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

其它章节

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

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

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

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

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

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

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


【To be better】一个信息系统项目案例分析

案例背景

老板交代给同事的任务是“将公司现有的各类系统集成为一个平台”,时间要求3个月,然后没有了。。。项目目前没有目标客户群,尚未进行全面的市场调查和分析,现有的各类软硬件系统大部分为外包产品,且并不成熟。公司的业务、部门、人员、流程等各方面都比较复杂和混乱。同事现在的职位为分公司现有的最高职位副总经理,手下勉强算有十几个人,其中有2个为开发人员,总公司另有1-2名单一产品线的技术人员可按要求进行协助。除人力以外的其他资源、决策性行动(合同、资金支出等)需要总公司批准。 

案例分析

通过分析以上情况,可得知以下几点:

1.      该项目的目标是无效的。因为目标不可衡量的,不明确。

2.      项目时间是明确的,为3个月。考虑到马上要过年了,可用的工作日实际上只有约50天左右。

3.      项目需要推向市场,但目前没有客户,也就是说项目的目标客户就是老板,那么项目结束标准应为“老板认可”,如果项目目标明确,那么完成目标即可。

4.      因为从头到尾没有看到老板关于项目质量的要求,那姑且可以将质量要求定为“通过演示使老板认可”,当然,这个“认可”是个不明确的标准,这点只能靠项目经理平时对老板喜好的了解,以及接下来在项目的进行过程中慢慢印证(如原型法)来确定了。

5.      项目属于软件开发项目,还没有开始任何一项工作。

6.      项目的内容是集成以往产品,且大多数为不成熟的外包产品。

7.      项目外部环境比较复杂,无法期盼能从外部获得更多的协助。

8.      该项目属强矩阵管理模式,可用的技术人员很少。

9.      项目经理对资源调配的权力仅限于人力资源。

 

总的来看,这位苦逼的项目经理要做的是一个没有明确的项目指标,资源相当有限的软件项目,难度很高。下面,按照标准的项目管理流程来理顺一下需要做的事情。

启动阶段

第一件要做的事情是明确项目的目标,几乎所有的项目管理书籍都会着重讲项目之初制定《项目章程》的重要性,因为在它里面,规定了项目的目标、可用资源及大概的项目范围。某种程度上讲,《项目章程》类似于在游戏开始的时候选择难度的那一步。无论一个项目的实际情况怎样,项目经理自己一定要有一个用以指导整个项目方向的《项目章程》且内容必须获得客户的认可(即使客户并不签署甚至不知道它的存在)。

在这个项目中,项目经理如果真的想做好项目,那么他就需要找老板认真谈谈,了解老板到底想要什么样的东西,比如都集成哪些东西进来(范围管理),想要做到什么程度(质量管理),可以向老板展示类似的产品或使用PPT、FLASH等做一个模拟界面,口述功能和状态的方法来进行需求分析(很显然,在这个项目中老板就是最大的客户),项目的可用资源都有哪些,还可以获得哪些协助(人力资源管理、成本管理、进度管理),项目干系人都有谁(沟通管理)等等等等,以此来定出一个合理的项目目标,大致的项目范围和明确的可用资源并获得老板的认可。从这个项目的情况来看,一个正确项目目标应该类似于“在3个月内(或X月X日前)将XX系统、XX系统、XX系统集成在一起并通过XX标准的验收”。一份完整的《项目章程》如下图所示:

项目章程

项目名称

 

项目介绍

简略的描述项目范围

项目目标

 

项目产品

可交付物(中间产品及最终产品)

项目经理

甲方项目经理

原部门及职务

联系方式

 

 

 

乙方项目经理

原部门及职务

联系方式

 

 

 

资源条件

主要人员

姓名

职务

XX

XXXXXXX

。。。

。。。

物质

资金、科研设备、办公场所

成本

XX币xx万元

结束时间

X年X月X日

完成标准

按XX规定的验收条款通过验收。

甲方(盖章)

 

乙方(盖章)

 

 

有了以上的内容,项目应该也会有一些大致的思路了,接下来要做的事情就多起来了。九大领域的工作都牵扯到了,不过因为是该项目本质上仍属于内部工作,而且公司领导即不懂也不在乎很多细节的东西,所以有很多是可以省略的,毕竟时间太赶了呀。

规划阶段

项目管理计划,用来指导整个项目的管理工作,项目经理大概心里有个谱就行了,都差不多的东西,正公司也不要求进行项目存档、总结和回顾。

需求收集分析-定义范围-工作分解,这点是非常重要的,首先需求收集方面,要先决定下来项目到底是按照老板的需求来做(极大可能不被市场接受)还是市场的需求来做(可能因资源不够导致项目流产),如果是前者,就靠项目经理来和老板谈心+技术人员或商务人员与产品合作商进行初步沟通来确定。如果是后者,由于专业人员的紧缺,外包给咨询公司或市场调查公司是最优选择,但是按公司的实际情况,恐怕使用现有人员组建需求调研团队是比较现实的。收集好了需求就开始进行分析和筛选,确定做哪些不做哪些,规定好项目的范围,然后根据所要做的工作进行分解,由于人员少时间短,可能工作包的粒度要大一些。

在进度管理方面,需要进行活动定义、排序、估算资源、时间,最后定出进度计划,通常计划以甘特图和网络图的形式展现给项目干系人。这些工作我认为是整个项目管理中最重要,也是最麻烦的。它牵扯到质量、人力资源、成本、沟通、风险等各个方面,在项目管理环境复杂的情况下,由于各类的不确定因素凑在一起,会让项目经理很快就陷入变态的境地。在本项目中,项目经理需要尽快做出一份甘特图并向老板解释其基本概念,要让老板知道这个项目中都要做哪些工作,每个工作包需要什么资源,关键路径是哪条,某个工作包有延迟会对整个项目造成什么样的后果。很多情况下,向老板讲述这些东西并不是真的跟老板探讨项目,而是在汇报的过程中让老板认清现实:项目需要很多部门很多人(包括老板自己)的配合,如果有人不配合,结果就是项目永远都做不完;人和钱永远都不够用;项目经理要和很多人沟通,很辛苦;项目有各种各样的风险,可能超时也可能超支更可能两样都有,但这不能只怪项目经理。

在成本管理方面,根据活动估算出成本后进行汇总,以此来制定整个项目的预算。在本项目中,由于不是软件定制项目,人力成本可以忽略(当然,最好算上,以后总会用得上的),其他成本包括采购额外的软硬件、支出给产品合作商的各类费用、业务招待费用、差旅费用等。日常管理费用不计入项目费用。搞完之后交公司审核,如果有机会的话,最好能争取到预算之内项目经理有审批权,对于整个项目进度的控制大有好处,不然时间全浪费借款和报销上了。

质量管理方面前面已经说过了,主要是看老板的意愿,这点在前期就一定要把握好分寸,否则东西出来货不对板就死翘翘了。如果有必要,就做一份验收标准,这样对项目的双方都有好处。

人力资源管理方面首先制定人力资源计划,规定好在项目中用人的原则问题。在本项目中。。。还是算了吧,就2个开发人员,其余全是打酱油的,都往死里用就行了,也别做什么计划了。

沟通管理方面,本阶段要做沟通计划,用来分清楚如何和各类干系人进行沟通,沟通哪些内容。其实这点在项目管理中是很重要的,因为项目经理最重要也是最常做的工作就是沟通和协调,在大型和复杂项目中尤为如此。在本项目中,做好老板和协同部门的沟通工作几乎成为了最重要的事,但这些事,往往又是无法体现在绩效中的,所以几乎每个项目经理都觉得心累,大致就是如此了。沟通没什么好说的,做不做什么计划都是扯淡,最终还得靠项目经理EQ够高,手段够多,影响力够大才行。

风险管理方面需要制定风险管理计划-识别风险-风险定性分析等工作。其中识别风险这一步,最好找一些不同部门,不同级别的人一起讨论,这样才能从不同的角度来检视一个项目,获得最全面的风险因素。在风险分析的时候,如果能与老板一起进行分析,是最好不过的了,因为老板才知道一个“风险”对于公司来讲到底算不算风险。

在外包管理方面,本项目的工作内容较多,因为其产品线复杂,多数为外包性质,自身技术人员又不够,外包是最可行的解决方案。所要考虑的是,找几个外包商,找哪些外包商,合同如何签订等等,在这方面,可能要专门安排几个人从头到尾进行跟进。而且它与项目成本息息相关,一不小心,就难逃项目失败的罪名。由于公司的整体流程(如合同审核、付款申请等)较慢,因此所有跟外包商的接触工作应尽最大可能尽早进行,商务谈判也应尽量节省时间(因为无论合同价格多少,公司的审核流程一样是那么慢),合同应在质量、进度方面进行严格把控,以免出现因一个外包商的失误而导致整个项目出现返工、延迟等问题。

执行阶段

如果有了详细和周全的规划,执行阶段其实是比较轻松的,just do it!

本阶段的工作包括管理项目执行、实施质量保证、建设项目团队、沟通干系人、实施采购等几项。在该项目中,管理项目执行可以忽略;质量实施方面需要跟外包商规定清楚;建设团队方面,手下就那么些人,能用的还不多,做一个大致的分工,然后各人按照工作包的分配做事就行了;沟通一直都是最重要的,在这个阶段也是一样,需要注意的是,根据项目的执行情况不断调整各个干系人对于项目的期望,也就是说,先打好预防针,免得回头有人抓狂;采购按照既定的计划和合同进行就OK了。

监控阶段

在项目整体管理方面最需要注意的是项目变更,是否进行变更需要通过该项目的项目管理委员会进行审核,所有的变更必须进行记录,并且由双方项目经理签字确认。项目经理在这个时候需要顶住来自各方的压力,对于不合理的变更要坚决抵制,即便是老板亲自下令。如果项目的变更管理失败,那么随之而来的就是范围蔓延,成本超支,人力紧缺,关键路径无法确定,风险加大等各方面的问题,最终项目将彻底走向失控。

范围管理方面,要时刻注意核实项目范围是否在控制之内,软件项目中尤其要注意需求镀金的问题,已经超出项目范围的部分要根据情况进行利弊分析,如果不能立即停止,则想办法尽量多争取资源以便匹配。

进度控制方面,需要随时注意关键路径的变化,在项目进行到中期的时候,关键路径总是会因为各种原因跳来跳去的,TOC理论有助于稳定关键路径,必要时,使用关键链法进行管理。pert计算最好每天都做,随时注意实际进度与基线的差异情况并进行分析和改正。每个里程碑都要进行一次小结,看看问题究竟出在哪里并及时向老板汇报这些问题。

成本控制方面,需要根据绩效测量来分析成本偏差,不过在本项目中无须在意,因为总公司财务部必定将成本控制在一直不够的状态,不太可能有超支的情况发生。

质量管理、沟通管理、风险管理和采购管理,在本阶段按照既定计划进行监控即可,唯一要注意的是风险管理中要持续的进行风险识别和分析,因为随着项目的进行,某些风险会消失,但又会出现新的风险。沟通方面,给每个项目干系人定时发送项目报表是非常必要的。

收尾阶段

项目整体管理方面,如果一切顺利的话,项目顺利通过验收并宣告结束,要做的事情就是将所有文件和数据存档,开总结会等等一系列工作。外包商的合同也需要进行一次归类和汇总。

 

以上是整个项目的一个流水账式的分析,说起来简单做起来难。要做好本项目的要点就是:

1.     明确目标

2.     要资源

3.     做好各方面的沟通

个人感觉,如果在最理想的状态下,项目有可能勉强完成,但在质量、成本和时间方面至少会有一方面无法达到要求,在现实情况下,最终这个项目会以表面成功实际失败而收场。

最后上一张图,与各位苦逼的项目经理共勉。

  

显示更多内容