从零开始学项目管理读后感(零基础学项目管理)

项目管理心得体会

项目管理心得体会

经过二郎山项目、鹧鸪山项目和水界等项目的项目管理工作实践，对项目管理的各方面事务感触颇深。在此，我将这多年的心得体会梳理，抛砖引玉，希望各位同行及领导多多斧正。

一． 管理时间就是管理自己，高效利用时间

每个人的工作课题存在差异，每个人的思想境界各有不同。但是上帝却很公平的给了每个人一天24小时的时间，因此我们提出管理时间，是每个人都可以做到的事情。每天把24小时规划好，也就管理好了自己。平时大家会说时间不够，事情做不过来，我建议大家把时间拿出来分析一下，根据工作性质合理安排时间。对于项目管理，事情多，工作琐碎.，这样我就养成了每天入睡前回顾一天工作的习惯，并对第二天的工作进行安排。在安排工作上要求本部门各级员工把握一个主次分明，轻重缓急合理的原则。这样每天当一到工作岗位上就能很快的进入工作状态，而员工的工作也各级抓好，紧张工作。这样就很好的把握和做到--"工作时效"。

二． 分清各项工作的轻重缓急

"轻重缓急"对于每个人来说都很重要，这就要求思路活跃，把火烧眉头的事情先处理掉，然后再去做日常工作。就好比用户要一个深层次的技术交流,要求特别着急,这时你就需要安排资深的人员进行相关的支持,电话中能够完整的提供就现场进行,若是需面对面的进行,那好,用户的需要就是一切.总之轻重缓急具有非常的灵活性、时间性、场合性要视具体情况而当机立断。做好了也是减少客户抱怨的有效方法。

三． 不断规范和调整制度，没有规矩不成方圆

谈到管理，就一定要从规范入手。规范是我们日常工作的行为准则，是企业生存、运作、发展、壮大的标尺和纲要。它的实施者既是所有领导，又是全体员工。只是各个岗位所规范的内容不同罢了。万事开头难，难就难在你走出的第一步，第一步迈出去了，第二、三步就没有问题了。正如我们日常工作，你没有第一稿资料，就没有后续的所有工作内容。你最近没有向职能部门提交××问题，就没有人来问你这个或哪个问题是如何如何的，等大家都有反映了这件事情，就有人开始琢磨怎么样来规范这项工作，让大家都按这个规定来做。以后大家就在这个基础上第二步、第三步的完善工作，把工作做得更好！任何事情都是一样的道理，只要你想做，你就会去规范这件事情，规范也就使每个人有了行为的准则。

四． 提高会议效率，事前告诉大家会议的内容

工作中的很多问题都是在会议中解决的。会议使我们对问题有了更多、更好的解决方案。我们平常碰到的会议也比较多，大大小小、各式各样的都有，那么如何提高会议的效率就成为大家关注的事情。如果我们在会议之前把要开会的事项告诉所有人，让大家都有准备，开会的时候就可以切入主题，谈每个人的思路，这样可以缩短一些时间。往往在会议上大家谈着谈着就会跑题，这时候就需要会议的主持人能够引导大家的思路往一个方向；再有就是会议结束前主持人或主管人员一定要重述这次会议的几项内容和解决措施，这样大家才会感觉到会议的重要性。

五． 统计数据，针对数据进行分析，分析结果加以应用，最后不忘评估、验证成果。

统计数据简单的说就是一个工作量化。是总结工作最直接、最明了的方法之一。统计对于各块的工作都很重要，没有数据的分析，我们不知道努力的方向，至少说轻重缓急把握不好，有了数据就可以比较，知道目前面临最大的缺陷在哪里，针对弱点加以改进。对于基层的管理人员来说数据的统计可以通过公司相关部门获得，得到的数据分析后一定要应用，只作分析不加以应用等于白搭，反而增加了工作量。有的会说，我应用了但效果不大，问题就是应用后，有没有跟踪验证，我们对分析出来的数据没有应用，没有验证，怎么会知道我们的分析是对的呢！因此分析-应用-验证，三者一个都不能少。

六． 愿景引来注意、尊重加深信心、沟通加强意义、立场导致信任

1）愿景--每次开会公司都会给我们描绘一下愿景，公司现在…… 即将……将来是…… 对于这些传到耳朵里的信息，员工们总是格外的在意，有的甚至在聆听笔记，这是不知不觉的愿景激励。因为这些都与公司的每一分子的切身利益直接相关，不管愿景好与坏大家都会关注，我们跟同事开会的时候也不要忘记强调三年规划。

2）尊重--同事之间相互尊重，可以加深合作，同时也会得到其他人的尊重，做起事情也会格外的舒坦。工作之余都谈到沟通很关键，企业领导鼓励下属发言，但自己却不太发言也不太敢发言，所以最后的结果常常就是大家都不发言，最后就变成你看着我、我看着你，然后领导看着现场所有人，脸上一副「说话呀！」的样子。这种状况就似乎是如果有一个人把话说出来之后他马上就会被企业宣判死刑一样，然后紧接着就被淘汰出局似的，所以大家对于自己想说的话都往肚子里吞，戒慎恐惧，一副「不要问我，我什么都不知道！」、「请你不要找我麻烦！」、「该死！怎么这么准，刚好问到我了！」的样子，所以只要你一鼓励他们把话说出来，大多数的时候，你很难获得到他们的回应，如果现场里有一、两个人敢勇于表达自己的意见，就已经算是不错的状况了。

3）沟通--「说出来」是沟通最基本的原则，如果连话都不愿意说出来，沟通肯定不会有任何的进展。如果在一个团队里，每一个人都必须要透过猜测才能够了解他人的想法，这将会是一件很累人的事，而如果你是待在这样团队里的一员，我相信每一天陪着你的一定是强烈的无力感。只要打破不说话的几个因素：面子问题、怕担责任、中庸、以为别人知道。主管或领导立场要坚定明确，我们平常说这个人没有立场，只要用户一投诉，主管就同意了；销售或市场一说，我们就得去做等等，这样同事会感觉到这个领导没有立场，别人怎么说就怎么做，以后有问题，他们也不会再问你，对你逐渐失去信任，因此主管人员一定要有立场，在立场发生变化的时候要和同事做好沟通。

七． 定目标，严格执行、考核、监督

一件事情的好与坏如何去评价，首先要看所定目标定的合理性。合适的目标对每个人、对企业都有好处，员工不会有太大的压力，安心努力的工作；企业每年都会稳步的积累和发展。定目标对我们每个人说就再简单不过了，人的一生中不知道给自己定了多少目标，但真正努力去完成的又占了多大比例？目标就要靠人来执行，执行过程中就有各种各样的评价，严格的说就是考核和监督。日常员工们努力的工作，都每个月底公司收集数据进行评估和考核，监督到年底每个是否能完成年初订立的目标。

八． 人不要会什么，关键在于你会学什么

在学校不管你学习什么专业，80%的学生找不到和自己本专业相同的工作，多数都是改行，有的从事本专业临近的工种，有的甚至与本专业搭不上边。从事本专业的人未必就有好的成就，从事非专业的人也有很多人打出一片天空。因此人不要会什么，关键在于你会学什么。

九． 培养人才资产：选、养、育、用、留。

关键在于留，留有3个因素：能力、价值观、人生志趣；能力的体现就是知识内涵，价值观主要表现在技能和态度。知识又分为：内隐知识和外显知识（内隐知识：平常看不到学不到的，要靠个人的感悟和积累；外显知识：看得到，学得到的东西）。平常总是要经过选拔招聘到一个适合企业的人员，进入公司后像小树苗一样培育，初长成就要考虑如何使用，经历这一系列的洗礼，人就有一定的想法，因此如何留住人才也是公司要积极考虑的事情，特别是在资源不足的情况下留住人才就更难能可贵。

十． 成绩好的时候要考虑如何提高团队的建设

随着其他公司技术能力逐步的提高，我意识到了靠个人的力量是不行的，要靠一个团队。平时一个人忙里忙外不亦乐乎还不见的有效果，如何培养一支可以打胜仗的团队呢，首先要了解团队中的每个成员，发挥他们的优势，挖掘潜能，根据每个人的个性不同选用不同的岗位，每个人在团队中都发挥作用，管理人员就成功了一半，团队也就有竞争力了……

求学习项目管理的收获或者体会

项目管理需要的知识，是一个体系的知识，包括项目管理本身的知识体系，以及项目管理要应用到的领域所需要的知识体系，然后就是管理的技能，当时最重要的，是软技能，也就是人际关系技能。

管理的核心：人。

管理的四大要素：

1. 选择正确的人

2. 为他们分配正确的工作

3. 保持他们的积极性

4. 帮助团队凝聚起来并保持团队的凝聚力。

1、 选择正确的人

首先要学会看人。虽然我不是人力资源专家，但是我清楚一个软件项目的成功所需要的成员素质，主要就是沟通能力和责任心。

由于工作需要，我面试过一些人，有毕业生以及有工作经验的，有各个大学的，大专生和本科生。我就开始学习如何考察一个人是否符合团队需要。

一般来说，面试的时候，问题有职业生涯规划是什么，未来期望在公司获得什么样的成长，对软件工程的认识，对自己的职业技能的描述，这都是常规问题。比较重要的是，我对每个人都会问，是否有团队开发项目的经验，不过大多数都没有。而且在大学期间，有完整作品的学生也比较少，大多数是作业。

一个人的气质类型都不太一样，有说话比较快的，也有说话慢条斯理，有自信心满满的，也有胆小的。管理要根据每个人的不同性格特征来进行管理才能获得成功，所以管理人员必须研究人的心理学。

初步面试完毕，进入试用，就要考察他的主动性。《把信送给加西亚》里面说到，别人没有叫我们就主动去想事情做，那样获得的回报是令人敬佩和羡慕的，别人叫一次我们就去做，那样获得的回报是可观的，别人叫两次我们才去做，那样获得的回报是社会平均水平，别人叫三次才去做，获得的回报是微薄的，别人叫了多次才去做，那样不仅仅没有回报，反而会被人责骂。但是最终结果都要去做事情，我们何不主动些呢？

有些人就等着分配任务，然后完成任务，领工资，根本没有去为公司着想，为自己着想，这种人只能永远被人利用。有些人会想办法改进，并且经常有好的创意，这种人最终会获得成功，因为他主动了。我们选择的人要选择比较主动，能够及时领悟公司的任务并且及时去做甚至改善的人。所以选择人是一门学问。

2、 为他们分配正确的工作

分配工作是很容易的，但是要做到正确分配工作就有学问了。

我进行分配任务的时候，刚开始是任由他们自己决定要做什么，然后我再综合的进行一个整理，后来发现这样子任务并不能分配的较为合理。接着就是我自己给员工分配任务，后来发现，这样子分配的任务员工有些接受不了，例如时间，技术难度等等，员工往往会有情绪。

所以总结了以往的经验，分配任我采取了宏观控制加上微观调整。首先我要明确的知道每个员工的各项知识技能水平。我制作了知识技能水平考核表，以此来把握每个人的技术水平，接着，根据项目纵向划分成各个模块，模块的大小以及数量是有讲究的。每个人都负责从表现成到数据访问层的编写，这样做好处第一是可以让大家把握自己项目的框架，培养员工的项目管理基本知识，第二是避免按层次划分中出现的互相扯皮现象，比较适合于创业型企业的中小项目。然后根据员工以往的项目经验，让每个员工谈谈对各个模块的认识，以此来推荐他做什么模块。员工对感兴趣的模块会说的比较多，比较有见解。接着再根据他们的以往的编程经验，速度，定出两周内要完成的任务，不能定太多周，因为项目刚刚开始时无法预知进度的。

分配正确的任务的要点，就是最好要先集体说明一下项目的各种需求，让每个员工知道这个项目的规划。接着要单独的和每个员工谈话，让他做喜欢的工作。如果出现冲突，我就在中间起协调作用，让大家分别谈谈对项目的了解和建议，以便知道某个人想做这个模块的动机是因为认为比较简单想让自己的工作轻松一些，还是认为比较难有挑战性，想挑战自己的技术高度。接着再根据他以往的项目经历，来说服他做他擅长的模块，以便提高项目的成功率。因为项目管理中很重要的一个原则是，一个成员做的工作，应该是重复过去成功的项目经验，而不是挑战他的技术高度，否则对项目是有害的，会导致项目失控。也就是说他个人的技术水平可能得到提升了，但是这是以项目作为他的试验品为代价的，这个人的提高只能在下一个项目中体现出来，正所谓前人栽树后人乘凉。

分配任务的时候要非常谨慎和小心，因为往往公司员工比较不敢对领导提出异议，所以就会造成任务完成质量不高或者不能按时完成，使项目管理无法按计划进行，这是我最深刻的体会。在团队成型初期，我们必须按照一定的难度和数量来分配，并给予足够的技术支持和帮助，在做的过程中要不断跟踪，等到团队成熟以后，对项目进度的管理将会越来越顺利，越来越准确。

3、 保持他们的积极性

首先，人的积极性是个很有趣的东西，把握拿捏不好分寸，就会影响到一个人做事情的积极性。

在这里我引用一段很经典的X,Y理论：

X,Y理论可以用来分析一个经理的管理行为，如果这个经理的思想是X理论的思想，那么他就会采取比较强硬的措施，例如军队式的管理方法。这种经理就会用各种严格的规章制度来强迫人们进行工作，触犯了规章制度就会受到经济上的惩罚。我认为这种管理方式只适合一些标准化操作程度比较高的企业，对于软件行业来说，人才得到了极大的重视，近期人才流动性较大，员工的个性也比较强烈，无法应用这种强硬的措施。

人较低需求层次是生存，高层次是自我实现，在软件行业中，生存已经不是问题，每个人都抱着自我实现的目标而奋斗，所以我认为在软件行业中采用Y理论比较适合，即一定要让员工参与到决策中。举个例子，有一个员工曾经向我抱怨，没有让团队的人参与一些事情的决策，他觉得不像团队，做事情效率比较低下。所以要让大家有积极性，就要让人感觉，这个项目是大家努力的结果，是大家团结的结果，而不是某一个技术牛人的结果。

我曾经在项目管理中采用了两种方法，一种是比较自由的方式，就是划分好模块，规定好一些项目规范以及界面规范，至于需求等等实现等等由大家一起自由发挥，结果效果一般。第二种就是完全由我控制，我规定好需求，规定好界面，甚至细化到每天要做什么，结果更加失败，员工感觉没有自由了。程序员和艺术家一样，既要有条条纲纲的限制，又要有一定的自由空间，所谓带着枷锁跳舞就是这个意思。所以作为项目经理必须把握好管理的松紧度，根据员工个性的不同来拿捏分寸，这需要经过一定时期的积累和磨练才能够炉火纯青，毕竟，管理也是艺术，需要悟性，不是从书本上就能够学得到的，要让如此复杂的人保持积极性，管理人员要付出更多的努力。

4、 帮助团队凝聚起来并保持团队的凝聚力

光光人的积极性还不够，每个人的用力方向还必须一样才能发挥团队的能量，团队是有一个生命周期的，分别是形成，躁动，稳定，表现。我在大学期间建立的团队就经历了这些阶段。那么在项目管理者面临的问题就是，如何使团队顺利经历这几个阶段，尽快达到表现阶段。

当团队形成的时候，一切都是新鲜的。我们团队尝试性的做一些任务，寻找哪些人比较合群，并且了解大家的性格以及特长。因为团队形成的时候，大家的工作热情比较高涨，但是容易出现焦虑，因为在团队中，他们的定位都不明确，所以作为团队的管理者在这个阶段应该做的是建立团队文化，例如团队名称，口号等等，甚至连什么时候开会，什么时候往也要事先有个规划，然后让团队的人之间互相充分的了解，然后做一些合作的工作来让大家了解在这个团队里面应该如何进行沟通协作。

接着当团队的目标和结构慢慢的清晰了以后，队员们开始躁动，开始关心自己的职责和权利，例如自己在团队里面负责什么模块等等，项目经理就要在这个阶段解决和协调队员之间的种种冲突，制定好规章制度和一些做事情的流程，并且倾听队员的不满。

然后团队渐渐稳定，生产力不断提高，项目和队员的能力稳步增长，目标清晰，成员之间已经形成一个整体，那么到这个阶段项目经理就比较轻松了，只要进行一些团队之间的关系处理，以及让大家进行一些重大决策就可以了。最后一个阶段就是表现阶段，那么这个阶段我认为是丰收阶段，团队成员配合已经到达非常默契的程度，基本上不需要频繁的交流，一切都有现成的流程，效率空前的提高。我经历的团队中最后达到这个阶段，开发效率令人感到非常满意，仅仅用了两个多月就完成了一个与我们以前快1年的项目差不多复杂的东西。

所以项目经理的职责就是在团队的各个阶段为团队保驾护航，保证大家的凝聚力，让团队的成员时刻充满责任感和自豪感。

总结

管理人员处于团队的中心，对管理人员本身的素质要求都比较高，而且管理人员与其他人员之间的关系也尤为复杂，属于圆心和圆周的关系，一旦处于圆周的人想靠近或者疏远管理人员，那么管理就不能圆满，管理人员对待所有人应该都是平等的，包括绩效考核，表扬与批评，个人关系等等。如果出现不平等就会有流言蜚语出现。

管理有很多工具和方法，这些都是通过学习的，唯有对人的管理，是属于软技能，需要一定的经验和悟性，需要管理人员对日常的小事情进行思考，总结，对自己处理事情的方法要进行合理性的评估，对每个人的个性要充分了解，对不同的人要用不同的管理技巧，不能搞一刀切。总之管理是为目标服务的，只有项目成功了，管理人员就是成功的，项目经理必须为这个项目负责！

追问：

不太合适可惜了 回答：

目标驱动，系统思维，风险意识，数据量化

凡事预则立，不预则废。如果你不知道要到哪里?给你一张地图也没有用。目标驱动首先要有最基本的计划管理和时间管理能力。对于一个项目，我们过程中做的所有工作都是为了要达到项目目标，因此在项目各个阶段所有活动都需要考虑对达成目标的影响，当发现偏差后及时纠正。目标驱动让我们从无目的的事后应急变成了有计划有目的的事前预测。目标驱动不是要抛弃过程，项目的成功涉及到过程，人和方法工具技术。为了达到项目目标，我们要根据项目的实际情况采取一系列项目原来已经总结的最佳实践形成一套过程，高效的过程和积极心态的人是保证项目目标达成的关键。因此作为项目经理要时刻问自己，项目的目标是什么? 项目当前状态和我达成目标的差距是什么?我如何解决和应对。

项目的成功受到多方面的因素的影响，而且各个因素之间还存在正反作用力。系统思维就是要让我们能够清楚的认识到影响项目目标和成功的各个要素，以及它们之间存在的关系。形成一种适合项目的动态系统模型，通过这个动态模型去平衡项目各方干系人的利益，平衡项目四要素之间的关系，平衡项目的短期和长期的利益。项目经理的一个重要能力就是平衡，没有最优解，只有满意解，懂得了平衡就知道当项目出现变更和调整的时候如何更好的应对。从单要素最优的单向思维过渡到关注整个系统的全局思维模式上。

风险意识简单来讲就是项目在执行过程中可能发生的各种问题我都事先预见到了而采取了适当的缓解措施，这样才能够真正的让项目能够按照预先制定的计划和目标进行。再简单点就是如果风险管理做得好，项目是不应该失败的。君子安而不忘危，存而不忘亡，治而不忘乱。风险管理的重点正是在于要形成风险意识，要能够通过历史经验的积累，能够把项目的关键风险识别出来，使项目能够从事后的救火转变到事前的防备，使项目能够在前面紧张后面轻松。

要谈及量化管理首先应该要培训用数据说话的分析思维。在软件项目管理中我们做度量的目的，就是要收集和分析各种历史数据，通过对数据的分析来知道项目真正的效率，同时为后续项目提供各种估算参数数据。以数据说话让我们从全凭主观经验臆断转变到对事物的客观数据分析上。只有能够收集数据，分析数据我们才可能持续改进。有了数据意识后就是要有统计和量化管理方面的意识，利用统计学的思维和量化管理手段不仅仅是让我们的过程稳定和受控制，能够去发现项目执行过程中特殊原因引起的波动，针对特殊波动进行根源分析并采取纠正行动;还能够让我们能够根据预测模型更加准确的预测项目能够达成目标的程度和概率

项目管理读后感

老师推荐给我们看的几本书让我受益匪浅。特别是《你的灯亮着吗?》。看进去之后方才知道老大的用心良苦，自己在处理工作中的事情时，不管用户是非对错，用户提出问题，我的思想老是照着用户的问题去解决问题。在这本书中针对我目前的情况有详细的解析。

这些书带给我的启发不仅仅是关于高级IT项目管理这门课程的，也给我今后的人生上了重要的一课。正如项目经理案头手册中提到的J.M.朱兰将一个项目定义为一个计划要解决的问题。该定义使我们认识到，项目管理是在大的规模上对问题的处理。我们生活中也在不断的遇到各种各样的问题，在进行项目管理的过程中，随着工作的进展，也给我们生活中解决问题指明了一条正确的思路和方法。项目问题就是人的问题，这些书启发我们在做事的时候不要怨天尤人，惟有付之行动，生活才会回报付出者；没有计划，就没有控制；要积极主动，不要被动反应；承担责任，争取权力；所有的行为只有从执行者的视角来理解才有意义；人最害怕的是被拒绝，最需要的是被接受；沟通技能是项目经理最应具备的技能之一。

书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。对于我工作中，用户正常使用TAJIMA的流程，就是我期望的东西，而体验到的东西都是，用户不按正常流程执行。问题就在于，用户更本不按流程走。而对于用户来说：用户期望的是可以直接改个供应商或直接改个单价就可以满足采购或财务的需要，而体验到的是在系统中供应商无法更改，单价在采购单更新后，财务部那边的出入库金额数据无法更新。所以用户的问题就是：采购单无法更新供应商，单价更新了无法满足财务的需要，怎么办？到底是谁的问题？当出现这种情况，我往往把用户的问题定义成了问题。想尽方法帮用户解决。书中还有说到：“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在解决的问题。用户入库拒收的库位选错了，入错了库位。我首先将问题的定义为：将入错库位的数据调整至正确的库位。一股脑的想如何去调整，用哪种调整方案最简单？结果表面上是以经解决了，可过不了多久此类情况又会发生。其实遇到这种问题应该先想想，库位选错的原因是什么，是不是之前的培训没有到位？如何杜绝这种情况再次发生？现在该做些什么？应该教会用户在开单时就先确认库位。如在开单时就选错库位就点选取消，重新开过单据。还有一次，财务部提出采购部在采购单上更新了价格，但出入库记录的金额还是没有，希望我们帮忙解决。我首先想到的就是帮财务部将采购单上更新的价格导出给财务部，方便快速。但没有想到问题的起源是：采购部在入仓之前没有输入价格，而要在入库之后才补上，导致现在这种问题。要解决这个问题的方法是让采购部在入仓之前就把价格填上，在入库的时候就会自动获取价格，而不是给财务部导出价格。

书中有个章节“什么是真正的问题？”里面有指出：“每种解决方法都会带来新的问题”，回想过去的工作，的确存在很多问题解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。如果采购部一直都是后补单价的话，就更本不会意识到后补单价是一种错误的方法。

因为时间的关系我没有全部看完这本书，有时间还需要经常翻看。在今后的工作中，需先将问题定义清楚，找到真正的问题，再去找寻解决这个问题的最佳解决方法：解决后产生的问题，没有解决前的棘手且最不棘手的解决方法。

书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。在一个项目的进行过程中，我们不可避免的要和用户之间沟通和交流，当然，在交流过程中，会遇到一些问题。不管用户是非对错，用户提出问题，我的思想老是照着用户的问题去解决问题。在这本书中针对这种情况有详细的解析。我往往把用户的问题定义成了问题。想尽方法帮用户解决。读完此书，以后在用户提出问题后，需先想想问题到底出在哪里？找出问题的真正定义！书中还有说到：“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在解决的问题。书中有个章节“什么是真正的问题？”里面有指出：“每种解决方法都会带来新的问题”，的确存在很多问题解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。

《项目经理案头手册》一书对整个项目过程进行了透彻的分析。刘易斯循序渐进地教我们如何从头到尾地计划、执行和控制一个项目，如何选择项目经理和能解决问题的项II团队，如何用WBS，PERT，CPM和甘特图编制项目计划，如何设计项目控制系统，如何利用挣值分析跟踪项目，如何与团队中各层次的成员进行有效沟通，如何在项目完成后进行经验教训总结。为项目经理展示了如何成功管理不同大小、不同类型的项目，内容讲解深入浅出，案例丰富全面，既深刻地分析了项目管理的本质及一些项目管理现象的内在含义，又简单明了地介绍了实践中具体应该如何操作，很好地实现了理论性和操作性的结合。

美国著名项目管理专家刘易斯为我们提出16步管理模型。从16步管理模型中可以看到项目的战略计划所处的位置：概念确立。就是对所要做的事情有一个框架性的设计，有一种思想；问题的定义。即对长远目标说明。第二步骤是对第一步的进一步细化和具体化；生成项目的备选方案和战略计划。就是提供思路、备选方案和战略计划总体思路；战略计划评估和选择。就是在选择方案的同时，有一个从总体技术路线到总体项目管理策略的评价和选择；战略的确立。就是确定具体的战略、目标；制订项目的实施计划。这是一个更加具体的、第二个层次的项目计划，就是怎样实施；项目干系人批准计划。这里的计划包括战略计划、初步计划、详细计划，在这些项目实施之前，有一个批准过程；签署项目计划。项目的批准人、参与项目的有关干系人要签署项目计划，对计划做出承诺，同时建立项目的跟踪记录，做一个项目进展情况日志或者周志、月志、记录，根据这些记录信息进行知识管理；执行项目计划。执行项目就是正式开展计划，进展这个项目；监控项目进展。计划开始实施之后，就要考虑计划执行得如何，有无问题，要对进展情况进行监控、监测和控制；审查项目定义。项目实施之后，需要做一些评审，评审包括对原来工作的评审，同时也包括对项目目标定义的评审，如有问题就返回到步骤二，重新修正项目的定义；对项目的战略进行评审。首先是评价目标或项目的定义，然后评审战略计划、战略制订是不是有问题，如果有问题就返回步骤四，重新修正你的项目战略；项目的实施计划。具体的计划工作流程、对一些细节要进行评审，有问题就进行修改；循环。按照整个过程不断地从计划的执行到监测、评审，有问题就要修改计划，然后再执行，再评审，这个过程一直延续到全部工作结束；总结经验教训。项目全部完成以后，及时总结经验教训，对一些问题进行归档，作为今后项目的指导和借鉴；结束项目。这是一个完整的项目管理流程，从这个流程可以看到整个项目战略计划实际上是在制订项目的详细计划和实施计划之前。在项目计划的时候，首先要有一个总体的战略计划，在总体的战略计划指导下再开展具体的项目计划。

书中指出项目在结束时失败，而是在开始时失败。在我们开始一个项目时，首先应该搞清楚项目的使命，前景，目标和目的。确定是否要进行此项目。当我们决定要开始一个项目后，就应该制定相应的战略计划，战略要回答“我们怎样对这项工作展开活动”这样的广泛问题，而制定实施计划则要求一丝不苟，换句话说，制定实施计划有关怎样做这项工作的详细事宜。制定计划涉及回答的问题包括：做什么、谁来做、何时、何地、多长时间和怎么做。

其次要对项目进度进行详细计划。项目进度计划编制既是一门科学，又是一门艺术。关于进度计划，真正的重点是为在最短的时间完成项目，找出并行尽可能多的活动的方法。项目管理科学的一面涉及到资源的平衡，它通过计算机运算完成，并存在许多算法。但是，同首次进行项目人力资源分配应用的技术相比，其结果差不多。

另外，资源计划也是重要的一环。完成一项活动的时间取决于分配给它的资源，并且如果没有相应数量的资源，工作就不能按计划完成。如果项目经理不能解决资源分配的问题，项目进度计划就不会成功。

此外，要对项目控制和评审。要达到项目目标，有必要采取适合的项目控制和评审。项目检查有三种类型：即状况、设计和工作过程检查。状况检查主要检查项目是否在进度计划和预算之内、范围是否正确、绩效的要求有没有问题。而设计检查仅仅适用于包括设计工作的项目，检查中经常要问的问题是达到规范了吗？用户界面友好吗？我们有能力制造吗？市场需要我们开发的产品吗？投资回报及其他的产品开发理由荏苒适合吗？之所以进行项目需要检查时因为：随着项目管理水平的提高，同时提高项目绩效；确保项目工作质量不居于进度和成本问题之后；尽早找出开发问题，以便提前采取措施；识别应采取不同管理方式的其他项目领域；确保业主获知项目状况。

在项目即将结束之时应该总结经验教训，若失败，则分析失败原因，可以从以下几个层次进行分析：（1）项目管理环境中的失败 。这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的“配合”。它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型，以及缺乏高层管理部门对项目的支持等。 项目不具备正确的组织结构、项目经理或者团队（以技能、经验、权力、正规性、复杂性来衡量）来“配合”项目。（2）项目管理系统中的失败 。这些失败的根源可以追溯到项目领导及错误实践。它们包括项目经理在项目生命周期中对系统方法的忽略，以及项目管理技巧的错误应用等。具体的可以归结为：不胜任的项目经理 ；忽略了项目的系统本质 ；管理技巧不恰当或者错误的运用 。（3）在计划和控制过程中的失败 ：项目中没有良好的沟通 ；没有用户的参与 ；不充分的项目计划；不充分的项目定义；糟糕的时间和资源估计；不正确的工期安排和资源处理；在执行阶段为数众多的变更 ；不恰当的控制 ；项目终止的计划很拙劣 。同样项目成功也应该总结经验。要取得项目成功，项目的目标定义、项目的系统、整体系统控制、整体计划，包括战略计划、实施计划、日程计划要通过详细、认真地预算、估算，保证项目能够得到充分的资源。在项目的实施过程当中，要通过经常性的审查、控制和评审来保证项目能够按计划不断地推进。 除此之外，组织目标的实现还需要在组织上保证。包括项目经理的领导艺术、项目经理的管理才能、管理技能以及相关的技能、组织结构和团队建设方面。所有的这些，都是保证项目走向成功必不可少的环节。

《微软研发制胜策略》和《微软项目求生法则》两本书也给了我很多启发。求生法则从求生心态、求生准备、逐步迈向成功以及完成任务几方面向我们阐述软件项目是如何存活的。作者利用在研究与工作中获得的经验告诉我们项目开发过程中的规划、设计、管理、质量控制、测试与完工所需的策略与观念，并利用大量技巧建立一套精简可靠的框架来成功的管理项目。软件项目的存活不是一种意外的结果。要让一个项目成功所需的努力并非特别困难或耗时，只是需要从项目开始进行的第一天就勤奋努力到最后一天而已。软件项目是发现与发明的过程。发现与发明融合为一的最佳方式是透过“阶段性完成”的做法，将产品的功能分阶段完成，而最重要的功能最早完成。当项目进行时，许多活动交互重叠，把产品由抽象概念转化成具体成果。项目进行中的源代码倾向以S形曲线而非线性成长，而大部分的程序代码都是在项目中间第三部分完成的。追踪程序代码的成长提供对项目状态的洞悉力。执行良好的项目也可以由一名上层主管选择最有成效的一组来进行追踪。

软件项目被切分成三个概念阶段。在项目初期，焦点摆在“发现”，特别是发现使用者的真正需要。透过技术性调查、与使用者访谈和建立接口雏形，把不确定性的概念转换成确定的观念，这就是第一阶段的特色。在项目进行中期，焦点移到了“发明”上。往大方向看，开发人员要发明软件构架与设计方式。细节的地方，如每个函数式或对象类别也不能忽略。如同发现阶段般，发明阶段的特征在于将不确定的概念转换成确定的观念。如果还有别的特征，就是发明阶段的不确定性要高得多。在发现阶段，开发人员可以确定答案“就在”某个地方。可是在发明阶段，就不能以此类推。在项目的最后部分，焦点又转移了，这次摆在实作上。不同于发现与发明阶段的是，实作阶段的不确定性少多了，故可发掘出许多已确定的观念并可实现成具体成果。

本文提供的项目规划依循着“阶段性完成”的轮廓进行。由于她将项目中开发的软件分阶段完成，而不是到了项目结尾才一次完成，这种方式称做“阶段性完成”。 在每个实作阶段中，项目团队进行细节设计、程序写作、除错与测试，在每个阶段都建立出可能推出的产品。分阶段完成有以下好处：关键功能更早出现；早期预警问题；减少报告负担；阶段性完成可降低估计失误；阶段性完成均衡了弹性与效率。阶段性完成的做法听来似乎毫无缺点，其实则不然。阶段性完成的做法要付出相当代价。因为项目团队需要时间准备各种可推出的软件，在每个阶段重复测试已经测试过的功能，推出软件前进行相关的版本管制工作，提供试用的不同版本软件没预料到的问题的解决方案（如果阶段性完成的软件真的拿出去给人使用），还有规划阶段性发行这种做法的好坏等等，都会提高项目的负担。阶段性完成并不是万灵丹，不过总合起来，那些额外的负担相对于明显改善了的状态、质量与时间的匹配、精确预估与降低风险等来说，不过是一点小小的付出而已。

《微软研发：制胜策略》一书中，作者详细描述了他在美国领导项目的各种实际的策略方法，教我们如何开发高质量的软件。卓越的领导者从不同的角度看世界。若是公司被大火烧得精光，他非但不为丢饭碗惊慌，反而利用火焰来烧烤一顿大餐。当每个人都摇头离去，卓越的领导者仍有充分的信心保持乐观，对每件事都从正面角度来思考。就因为凡事都看光明面，卓越的领导者并不把失败当失败，反将其当作学习克服障碍的经验。正因如此，卓越的领导者乐意尝试各种稀奇古怪的想法，并从中获得重大的突破，即使不成功，他只把这次经验当成获得信息的方式之一。这种领导人不一定要有经验，而是需要强烈的进取心和明确的理想，能够将理想与他人沟通，鼓舞他人共同追寻理想的能力，再加上一点机会，这就是能将理想实现的卓越领导者。坐着告诉我们开发项目要制定详细的目标，包括你要求的输入和输出的目标、长期和短期的目标，项目组要时刻被各个具体目标的实现所鼓舞和激励；不要浪费时间在错误的问题上，一定要先确定真正的问题在哪里，然后才去改正它；人们开口要求的东西未必是他真正想要的，处理他的要求之前，请务必先确定他究竟想要做什么；如果您能够先明确定义自己的需求，再向别人提出，这是避免在沟通上发生误会的好方法；任何不能改善产品的工作，都是浪费时间或偏离方向；项目组每部分的进度要协调一致；一旦发现错虫就立即清除掉，别拖延；程序设计前要先确定它的优先级表，比如稳定性、可移植性、速度和效率等；绝对不要答应别人自己做不到的事情，这样对双方都有益无害；注意定期会议的价值，确定它是否值得每个人放下手中的工作召开会议之前，请确定本次会议的目的是什么，达成这个目的的条件是什么，然后，务必达到开会的目的；会议尽量安排在一个时段的最前面或最后面，尽量减少工作的中断与时间的切割；最会误导项目发展、伤害产品质量的事情就是过份重视进度，这不仅打击人员士气，还会迫使组员做出愚蠢的决定；为了保持创意的活力和团队士气，必须让每个小项目都有令人兴奋的结果；不要让设计师的学习停滞不前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺样样精通的组员。组员的技术和知识应该精益求精；员工应积极学习新的技术、养成良好的工作习惯，做事更有效率，把握有限的时间，增加你个人对公司的价值；不要用年终考评来订立学习目标，要利用年终考评来记录个人的成长；不要给使用者次品，宁愿延期交货，务必追求质量完美；将程序的可共享性当作优先考虑的目标之一，否则程序设计师将经常做重复的工作；如果您创造了一项资源，并且让别人知道，那么总有一天会派上用场的；主管应该把自己视为团队的一分子，与其他人平等，而不是高高在上；健康的生活是一切创意的源动力。这些经验也同时告诉我们做人的道理。

《人月神话》一书对我的触动很大。作者详细讨论了包括工期规划、团队组成、文档、排错等软件项目进行全程中的方方面面。当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。

把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。

1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。

概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。

2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。

组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。

3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。

以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。：）

如果不想加班，不想削减功能，不想推迟发布日期，那么。。。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。