IT项目管理读后感.docx
《IT项目管理读后感.docx》由会员分享，可在线阅读，更多相关《IT项目管理读后感.docx（30页珍藏版）》请在冰点文库上搜索。
IT项目管理读后感
李沙沙0906014
老师推荐给我们看的几本书让我受益匪浅。
特别是《你的灯
亮着吗?
》。
看进去之后方才知道老大的用心良苦，自己在处理工作
中的事情时，不管用户是非对错，用户提出问题，我的思想老是照
着用户的问题去解决问题。
在这本书中针对我目前的情况有详细的
解析。
这些书带给我的启发不仅仅是关于高级 IT 项目管理这门课程的，也
给我今后的人生上了重要的一课。
正如项目经理案头手册中提到的
J.M.朱兰将一个项目定义为一个计划要解决的问题。
该定义使我们
认识到，项目管理是在大的规模上对问题的处理。
我们生活中也在
不断的遇到各种各样的问题，在进行项目管理的过程中，随着工作
的进展，也给我们生活中解决问题指明了一条正确的思路和方法。
项目问题就是人的问题，这些书启发我们在做事的时候不要怨天尤
人，惟有付之行动，生活才会回报付出者；没有计划，就没有控制；
要积极主动，不要被动反应；承担责任，争取权力；所有的行为只
有从执行者的视角来理解才有意义；人最害怕的是被拒绝，最需要
的是被接受；沟通技能是项目经理最应具备的技能之一。
书中有说到一句：
“问题其实就是你期望的东西和你体验的东
西的差别”。
对于我工作中，用户正常使用 TAJIMA 的流程，就是我
期望的东西，而体验到的东西都是，用户不按正常流程执行。
问题
就在于，用户更本不按流程走。
而对于用户来说：
用户期望的是可
以直接改个供应商或直接改个单价就可以满足采购或财务的需要，
而体验到的是在系统中供应商无法更改，单价在采购单更新后，财
务部那边的出入库金额数据无法更新。
所以用户的问题就是：
采购
单无法更新供应商，单价更新了无法满足财务的需要，怎么办？
到
底是谁的问题？
当出现这种情况，我往往把用户的问题定义成了问
题。
想尽方法帮用户解决。
书中还有说到：
“在寻找问题定义的道
路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经
迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于
用户目前是最简单的？
回头想想，有的时候真的帮用户解决到问题
吗？
没有！
因为我在找解决方法的过程中，已经错误的定义了我在
解决的问题。
用户入库拒收的库位选错了，入错了库位。
我首先将
问题的定义为：
将入错库位的数据调整至正确的库位。
一股脑的想
如何去调整，用哪种调整方案最简单？
结果表面上是以经解决了，
可过不了多久此类情况又会发生。
其实遇到这种问题应该先想想，
库位选错的原因是什么，是不是之前的培训没有到位？
如何杜绝这
种情况再次发生？
现在该做些什么？
应该教会用户在开单时就先确
认库位。
如在开单时就选错库位就点选取消，重新开过单据。
还有
一次，财务部提出采购部在采购单上更新了价格，但出入库记录的
金额还是没有，希望我们帮忙解决。
我首先想到的就是帮财务部将
采购单上更新的价格导出给财务部，方便快速。
但没有想到问题的
起源是：
采购部在入仓之前没有输入价格，而要在入库之后才补上，
导致现在这种问题。
要解决这个问题的方法是让采购部在入仓之前
就把价格填上，在入库的时候就会自动获取价格，而不是给财务部
导出价格。
书中有个章节“什么是真正的问题？
”里面有指出：
“每种解
决方法都会带来新的问题”，回想过去的工作，的确存在很多问题
解决之后，产生了更大的问题。
针对这种现象,书中指出：
“问题最
难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，
慢慢的就会无法意识到它们的存在。
如果采购部一直都是后补单价
的话，就更本不会意识到后补单价是一种错误的方法。
因为时间的关系我没有全部看完这本书，有时间还需要经常翻
看。
在今后的工作中，需先将问题定义清楚，找到真正的问题，再
去找寻解决这个问题的最佳解决方法：
解决后产生的问题，没有解
决前的棘手且最不棘手的解决方法。
书中有说到一句：
“问题其实就是你期望的东西和你体验的东
西的差别”。
在一个项目的进行过程中，我们不可避免的要和用户
之间沟通和交流，当然，在交流过程中，会遇到一些问题。
不管用
户是非对错，用户提出问题，我的思想老是照着用户的问题去解决
问题。
在这本书中针对这种情况有详细的解析。
我往往把用户的问
题定义成了问题。
想尽方法帮用户解决。
读完此书，以后在用户提
出问题后，需先想想问题到底出在哪里？
找出问题的真正定义！
书
中还有说到：
“在寻找问题定义的道路上疲倦地游荡时，不要忘记
随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮
用户想解决方法，哪种解决方法对于用户目前是最简单的？
回头想
想，有的时候真的帮用户解决到问题吗？
没有！
因为我在找解决方
法的过程中，已经错误的定义了我在解决的问题。
书中有个章节
“什么是真正的问题？
”里面有指出：
“每种解决方法都会带来新
的问题”，的确存在很多问题解决之后，产生了更大的问题。
针对
这种现象,书中指出：
“问题最难以处理的部分恰恰是去意识到它们
的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。
《项目经理案头手册》一书对整个项目过程进行了透彻的分析。
刘易斯循序渐进地教 我们 如何从头到尾地计划、执行和控制一个
项目，如何选择项目经理和能解决问题的项 II 团队，如何用
WBS，PERT，CPM 和甘特图编制项目计划，如何设计项目控制系统，
如何利用挣值分析跟踪项目，如何与团队中各层次的成员进行有
效沟通，如何在项目完成后进行经验教训总结 。
为项目经理展示
了如何成功管理不同大小、不同类型的项目，内容讲解深入浅出，
案例丰富全面，既深刻地分析了项目管理的本质及一些项目管理
现象的内在含义，又简单明了地介绍了实践中具体应该如何操作，
很好地实现了理论性和操作性的结合。
美国著名项目管理专家刘易斯为我们提出 16 步管理模型。
从 16 步管理模型中可以看到项目的战略计划所处的位置：
概念确
立。
就是对所要做的事情有一个框架性的设计，有一种思想；问
题的定义。
即对长远目标说明。
第二步骤是对第一步的进一步细
化和具体化；生成项目的备选方案和战略计划。
就是提供思路、
备选方案和战略计划总体思路；战略计划评估和选择。
就是在选
择方案的同时，有一个从总体技术路线到总体项目管理策略的评
价和选择；战略的确立。
就是确定具体的战略、目标；制订项目
的实施计划。
这是一个更加具体的、第二个层次的项目计划，就
是怎样实施；项目干系人批准计划。
这里的计划包括战略计划、
初步计划、详细计划，在这些项目实施之前，有一个批准过程；
签署项目计划。
项目的批准人、参与项目的有关干系人要签署项
目计划，对计划做出承诺，同时建立项目的跟踪记录，做一个项
目进展情况日志或者周志、月志、记录，根据这些记录信息进行
知识管理；执行项目计划。
执行项目就是正式开展计划，进展这
个项目；监控项目进展。
计划开始实施之后，就要考虑计划执行
得如何，有无问题，要对进展情况进行监控、监测和控制；审查
项目定义。
项目实施之后，需要做一些评审，评审包括对原来工
作的评审，同时也包括对项目目标定义的评审，如有问题就返回
到步骤二，重新修正项目的定义；对项目的战略进行评审。
首先
是评价目标或项目的定义，然后评审战略计划、战略制订是不是
有问题，如果有问题就返回步骤四，重新修正你的项目战略；项
目的实施计划。
具体的计划工作流程、对一些细节要进行评审，
有问题就进行修改；循环。
按照整个过程不断地从计划的执行到
监测、评审，有问题就要修改计划，然后再执行，再评审，这个
过程一直延续到全部工作结束；总结经验教训。
项目全部完成以
后，及时总结经验教训，对一些问题进行归档，作为今后项目的
指导和借鉴；结束项目。
这是一个完整的项目管理流程，从这个
流程可以看到整个项目战略计划实际上是在制订项目的详细计划
和实施计划之前。
在项目计划的时候，首先要有一个总体的战略
计划，在总体的战略计划指导下再开展具体的项目计划。
书中指出项目在结束时失败，而是在开始时失败。
在我们开始
一个项目时，首先应该搞清楚项目的使命，前景，目标和目的。
确
定是否要进行此项目。
当我们决定要开始一个项目后，就应该制定
相应的战略计划，战略要回答“我们怎样对这项工作展开活动”这
样的广泛问题，而制定实施计划则要求一丝不苟，换句话说，制定
实施计划有关怎样做这项工作的详细事宜。
制定计划涉及回答的问
题包括：
做什么、谁来做、何时、何地、多长时间和怎么做。
其次要对项目进度进行详细计划。
项目进度计划编制既是一门
科学，又是一门艺术。
关于进度计划，真正的重点是为在最短的时
间完成项目，找出并行尽可能多的活动的方法。
项目管理科学的一
面涉及到资源的平衡，它通过计算机运算完成，并存在许多算法。
但是，同首次进行项目人力资源分配应用的技术相比，其结果差不
多。
另外，资源计划也是重要的一环。
完成一项活动的时间取决于
分配给它的资源，并且如果没有相应数量的资源，工作就不能按计
划完成。
如果项目经理不能解决资源分配的问题，项目进度计划就
不会成功。
此外，要对项目控制和评审。
要达到项目目标，有必要采取适
合的项目控制和评审。
项目检查有三种类型：
即状况、设计和工作
过程检查。
状况检查主要检查项目是否在进度计划和预算之内、范
围是否正确、绩效的要求有没有问题。
而设计检查仅仅适用于包括
设计工作的项目，检查中经常要问的问题是达到规范了吗？
用户界
面友好吗？
我们有能力制造吗？
市场需要我们开发的产品吗？
投资
回报及其他的产品开发理由荏苒适合吗？
之所以进行项目需要检查
时因为：
随着项目管理水平的提高，同时提高项目绩效；确保项目
工作质量不居于进度和成本问题之后；尽早找出开发问题，以便提
前采取措施；识别应采取不同管理方式的其他项目领域；确保业主
获知项目状况。
在项目即将结束之时应该总结经验教训，若失败，则分析失败
原因，可以从以下几个层次进行分析：
（1）项目管理环境中的失败
。
这些失败的根源可以追溯到项目组织与项目目标、项目任务、高
层管理部门以及更大的环境之间的不适当的“配合”。
它们包括使
用对于项目目标和项目环境来说不正确的项目管理方法或模型，以
及缺乏高层管理部门对项目的支持等。
项目不具备正确的组织结构、
项目经理或者团队（以技能、经验、权力、正规性、复杂性来衡量）
来“配合”项目。
（2）项目管理系统中的失败 。
这些失败的根源
可以追溯到项目领导及错误实践。
它们包括项目经理在项目生命周
期中对系统方法的忽略，以及项目管理技巧的错误应用等。
具体的
可以归结为：
不胜任的项目经理；忽略了项目的系统本质 ；管理
技巧不恰当或者错误的运用 。
（3）在计划和控制过程中的失败 ：
项目中没有良好的沟通 ；没有用户的参与 ；不充分的项目计划；
不充分的项目定义；糟糕的时间和资源估计；不正确的工期安排和
资源处理；在执行阶段为数众多的变更 ；不恰当的控制 ；项目终
止的计划很拙劣 。
同样项目成功也应该总结经验。
要取得项目成功，
项目的目标定义、项目的系统、整体系统控制、整体计划，包括战
略计划、实施计划、日程计划要通过详细、认真地预算、估算，保
证项目能够得到充分的资源。
在项目的实施过程当中，要通过经常
性的审查、控制和评审来保证项目能够按计划不断地推进。
除此之
外，组织目标的实现还需要在组织上保证。
包括项目经理的领导艺
术、项目经理的管理才能、管理技能以及相关的技能、组织结构和
团队建设方面。
所有的这些，都是保证项目走向成功必不可少的环
节。
《微软研发制胜策略》和《微软项目求生法则》两本书也给了我
很多启发。
求生法则从求生心态、求生准备、逐步迈向成功以及完
成任务几方面向我们阐述软件项目是如何存活的。
作者利用在研究
与工作中获得的经验告诉我们项目开发过程中的规划、设计、管理、
质量控制、测试与完工所需的策略与观念，并利用大量技巧建立一
套精简可靠的框架来成功的管理项目。
软件项目的存活不是一种意
外的结果。
要让一个项目成功所需的努力并非特别困难或耗时，只
是需要从项目开始进行的第一天就勤奋努力到最后一天而已。
软件
项目是发现与发明的过程。
发现与发明融合为一的最佳方式是透过
“阶段性完成”的做法，将产品的功能分阶段完成，而最重要的功
能最早完成。
当项目进行时，许多活动交互重叠，把产品由抽象概
念转化成具体成果。
项目进行中的源代码倾向以S形曲线而非线性成
长，而大部分的程序代码都是在项目中间第三部分完成的。
追踪程
序代码的成长提供对项目状态的洞悉力。
执行良好的项目也可以由
一名上层主管选择最有成效的一组来进行追踪。
软件项目被切分成三个概念阶段。
在项目初期，焦点摆在“发
现”，特别是发现使用者的真正需要。
透过技术性调查、与使用者
访谈和建立接口雏形，把不确定性的概念转换成确定的观念，这就
是第一阶段的特色。
在项目进行中期，焦点移到了“发明”上。
往
大方向看，开发人员要发明软件构架与设计方式。
细节的地方，如
每个函数式或对象类别也不能忽略。
如同发现阶段般，发明阶段的
特征在于将不确定的概念转换成确定的观念。
如果还有别的特征，
就是发明阶段的不确定性要高得多。
在发现阶段，开发人员可以确
定答案“就在”某个地方。
可是在发明阶段，就不能以此类推。
在
项目的最后部分，焦点又转移了，这次摆在实作上。
不同于发现与
发明阶段的是，实作阶段的不确定性少多了，故可发掘出许多已确
定的观念并可实现成具体成果。
本文提供的项目规划依循着“阶段性完成”的轮廓进行。
由于
她将项目中开发的软件分阶段完成，而不是到了项目结尾才一次完
成，这种方式称做“阶段性完成”。
在每个实作阶段中，项目团队
进行细节设计、程序写作、除错与测试，在每个阶段都建立出可能
推出的产品。
分阶段完成有以下好处：
关键功能更早出现；早期预
警问题；减少报告负担；阶段性完成可降低估计失误；阶段性完成
均衡了弹性与效率。
阶段性完成的做法听来似乎毫无缺点，其实则
不然。
阶段性完成的做法要付出相当代价。
因为项目团队需要时间
准备各种可推出的软件，在每个阶段重复测试已经测试过的功能，
推出软件前进行相关的版本管制工作，提供试用的不同版本软件没
预料到的问题的解决方案（如果阶段性完成的软件真的拿出去给人
使用），还有规划阶段性发行这种做法的好坏等等，都会提高项目的
负担。
阶段性完成并不是万灵丹，不过总合起来，那些额外的负担
相对于明显改善了的状态、质量与时间的匹配、精确预估与降低风
险等来说，不过是一点小小的付出而已。
《微软研发：
制胜策略》一书中，作者详细描述了他在美国领导
项目的各种实际的策略方法，教我们如何开发高质量的软件。
卓越
的领导者从不同的角度看世界。
若是公司被大火烧得精光，他非但
不为丢饭碗惊慌，反而利用火焰来烧烤一顿大餐。
当每个人都摇头
离去，卓越的领导者仍有充分的信心保持乐观，对每件事都从正面
角度来思考。
就因为凡事都看光明面，卓越的领导者并不把失败当
失败，反将其当作学习克服障碍的经验。
正因如此，卓越的领导者
乐意尝试各种稀奇古怪的想法，并从中获得重大的突破，即使不成
功，他只把这次经验当成获得信息的方式之一。
这种领导人不一定
要有经验，而是需要强烈的进取心和明确的理想，能够将理想与他
人沟通，鼓舞他人共同追寻理想的能力，再加上一点机会，这就是
能将理想实现的卓越领导者。
坐着告诉我们开发项目要制定详细的
目标，包括你要求的输入和输出的目标、长期和短期的目标，项目
组要时刻被各个具体目标的实现所鼓舞和激励；不要浪费时间在错
误的问题上，一定要先确定真正的问题在哪里，然后才去改正它；
人们开口要求的东西未必是他真正想要的，处理他的要求之前，请
务必先确定他究竟想要做什么；如果您能够先明确定义自己的需求，
再向别人提出，这是避免在沟通上发生误会的好方法；任何不能改
善产品的工作，都是浪费时间或偏离方向；项目组每部分的进度要
协调一致；一旦发现错虫就立即清除掉，别拖延；程序设计前要先
确定它的优先级表，比如稳定性、可移植性、速度和效率等；绝对
不要答应别人自己做不到的事情，这样对双方都有益无害；注意定
期会议的价值，确定它是否值得每个人放下手中的工作召开会议之
前，请确定本次会议的目的是什么，达成这个目的的条件是什么，
然后，务必达到开会的目的；会议尽量安排在一个时段的最前面或
最后面，尽量减少工作的中断与时间的切割；最会误导项目发展、
伤害产品质量的事情就是过份重视进度，这不仅打击人员士气，还
会迫使组员做出愚蠢的决定；为了保持创意的活力和团队士气，必
须让每个小项目都有令人兴奋的结果；不要让设计师的学习停滞不
前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺
样样精通的组员。
组员的技术和知识应该精益求精；员工应积极学
习新的技术、养成良好的工作习惯，做事更有效率，把握有限的时
间，增加你个人对公司的价值；不要用年终考评来订立学习目标，
要利用年终考评来记录个人的成长；不要给使用者次品，宁愿延期
交货，务必追求质量完美；将程序的可共享性当作优先考虑的目标
之一，否则程序设计师将经常做重复的工作；如果您创造了一项资
源，并且让别人知道，那么总有一天会派上用场的；主管应该把自
己视为团队的一分子，与其他人平等，而不是高高在上；健康的生
活是一切创意的源动力。
这些经验也同时告诉我们做人的道理。
《人月神话》一书对我的触动很大。
作者详细讨论了包括工期规
划、团队组成、文档、排错等软件项目进行全程中的方方面面。
当
我捧起《人月神话》，马上就被深深的吸引了。
书中很多细微之处
都对我的思维造成了冲击。
上一本给我类似感觉的书是那本四人帮
的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。
把感触比较深的几点记下来，顺便整理一下自己的思路，与大
家分享。
1，保持设计的概念完整。
无论对小软件还是大软件，都必须由
一个设计师主导，最多两个人讨论来共同完成软件的整体设计。
作
为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都
在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。
具体的实现人员可以细化概念，但只有总设计者才有否定与发展基
本概念的权力。
需要注意的一点是，即使是总设计师一直是同一个
人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明
确的文档化，而没有成为所有开发者共同的概念。
在其他开发者编
码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法
），导致整体结构的恶化。
这个时候总设计师一定要即时发现，做
出更正。
概念的完整性，对于很多小规模软件，由于开发人员不多，开
发经理一般都能控制住所有的代码，概念完整性在组织层面就维持
住了。
但要注意以后的 Bug 修改，功能扩展的时候，也要时刻留意
与最初的设计是否概念上相容。
对于大规模的软件系统，则必须通
过树状组织结构，层层控制，总设计师还是一到两人，每一层都有
对下层的绝对把握能力。
我以前参加过一个 15 人左右的项目组，就
是分为两层。
感觉整体概念完整性的控制效果还不错。
我没有更多
人数项目的具体实践经验，希望以后能有机会参与比较大的项目。
2，“一个拿 2 倍工资的人，生产率可能是其他人的 10 倍。
”
我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认
同。
不知道其他公司的程序员们如何看。
我的同事中有一个牛人，
做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过
工资最多也就是普通程序员的二倍。
是不是有些不公平呢？
我也说
不清楚。
因为那些普通程序员也十分的努力。
不过，我觉得，作为
公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。
组建一个团队，最好的就是那种精英团队，大家都是牛人，效
率会特别高。
微软就是这种思路吧，把最聪明的人集中在一起，想
不成功都难亚。
3，进度落后与增加人力。
记得当年看《C＋＋编程思想》，Bru
ce 说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚
戚焉。
而本书作者 Brooks 得出的结论是对我是震撼性的：
“向进度
落后的项目中增加人手，只会使进度更加落后”。
以前，增加人手基本是挽救进度落后项目的主要办法。
这个办
法行不通的话，难道只有“加班”一条路了？
但长期加班是对个人
的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”
。
：
）
如果不想加班，不想削减功能，不想推迟发布日期，那么。
。
。
。
。
唯一的方法还是只有….加人。
加足够的人。
而且不要逐步加
入，一定要一次性加入。
要小心的是，新加入的人可能对原来的组
织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有
比较强大的设计者）。
那么，就当作，新组建了一个团队吧。
交流
，培训新人，就设计达成一致，继续向者目标前进。
升级会员 