项目管理读后感
发布网友
发布时间：2022-04-29 20:40
共3个回答
懂视网
时间：2022-05-04 02:55
摘要 ： 知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分 团队建设 篇、战略篇、 需求 篇、设
摘要：知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分团队建设篇、战略篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。
什么叫挨踢项目？
IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死，你想不“挨踢”都难！
指挥战争可能是最复杂的项目管理？
做挨踢项目可能比较杯具，但最复杂、难度最高、代价最大的项目管理可能是战争的管理了。战争靠什么取胜呢？如果你是这场战争其中一方的统帅，你会如何指挥这样战争呢？你可能会说：你不是在扯淡吗？说挨踢项目管理，怎么跑到战争去了？让我们先看看战争的战略管理，然后再回到项目的战略管理吧。
白起的故事
白起你不会没有听说过吧？就是那个杀死几十万赵国俘虏的杀人狂魔。但我说的不是他杀俘虏的事情，而是白起被称为战神，一生没有打过败仗，他是如何做到的？因为他只选择打战略上能打赢的仗！
当时只有赵国有实力和秦国一战，双方几十万大军对峙在长平一带。秦军统帅是白起，赵军统帅是廉颇。白起对于此战的战略上的判断是这样的：两国实力、军力相当，如果全力出战，秦国能胜，但只能是惨胜，这样的后果只能是削弱了自己，反而让其他战国有机可乘。秦国的优势在于全国上下一心，特别是秦王和大臣们众志成城。而赵国虽然军力不错，但赵国内部权力斗争厉害，各派只为自己利益不顾国家利益。因此白起定下的战争策略是：对外称病不能担当统帅，隐藏自己做统帅的事实，以拖待变，寻找有利战机再出击。另一方面，秦国使出反间计，成功让赵国更换主帅，换了那个很出名的只会“纸上谈兵”的赵括。
赵括上任后，全军出击，结果中了白起埋伏，白起利用地形，用基本相等的数量的士兵困住了几十万赵军，不与之决战，消耗赵军的粮草，最后赵军被迫投降。后面就是白起杀死几十万降兵的事情了。白起成功地用比较少的代价，给赵国带来致命的打击。
白起杀死几十万降兵后，立马建议秦王马上挥军灭掉赵国。秦王认为此时出击必会促使六国合纵，这样秦国会招架不住；但白起认为，刚杀掉几十万降兵，其他五国还在震惊之中，没有这么快缓过气来，一时无法合纵，此时正是灭掉赵国的好时机！但秦王坚持自己的想法，白起只有退兵。后来秦王后悔了，想让白起率军灭掉赵国。这时白起认为：其他五国已经缓过气来了，此时攻击赵国，六国必会合纵。但秦王一意孤行，白起托病不统军，秦王另找人统帅，结果六国果然合纵，出现了“信陵君盗取帅印”促使魏国出兵的著名历史事件，秦军大败。秦王再次要求白起统帅，认为只要白起统帅必能获胜，但白起仍然推辞，最后秦王恼羞成怒，杀了白起。
白起在战略上的判断是相当准确的，可惜他的老板和他想法不一样，白起拒绝执行战略上注定失败的决策，虽然避免了自己打败仗，但得罪了老板，下场凄惨啊！咱们这些做项目的，如果遇到一个战略上有问题的项目，你是做还是不做呢？
庞涓的故事
说起庞涓，大家可能马上想到的是他如何害孙膑，然后孙膑又如何设计杀之报复。其实庞涓是一个战略上判断正确的人，只是被迫执行了战略上有问题的决策。
庞涓是魏国的大将，他对魏王建议的国策是：先西进灭掉秦国，解除后顾之忧后再图其他。秦国当时并不强大，多年与魏国争夺河西河东，“三十年河西三十年河东”的故事就是这样来的。但魏王认为：秦国很穷，但秦人很彪悍，灭掉秦国代价太大，没啥好处。魏王最想做的事情是灭掉赵国和韩国，所谓的“三晋合一”，魏、赵、韩原本同属晋国，后来他们将之瓜分掉。庞涓认为：灭掉赵国、韩国是不可行的，因为附近的战国，特别是齐国不会让魏国成功的，其他战国必会出兵。但魏王执意要先灭赵国，然后是韩国，让庞涓统帅。庞涓只能坚决执行老板的决策，率军猛攻赵国，就快攻克邯郸之时，齐国突然出兵突袭魏国的大梁，这就是“围魏救赵”的故事。庞涓只能回师救大梁，途中遇到伏击，损失惨重，但还不至于战死。
魏王仍然不甘心，再次要庞涓统帅灭韩国，故事再次上演，这次是“围魏救韩”。庞涓再次回师，孙膑上演了“逐日减灶”的典故，让庞涓判断失误，率大军进入死地，被齐军伏击致死。
庞涓同样在战略上的判断是基本正确的，但他的老板想法不是这样，庞涓作为老板的手下，他选择了坚决执行老板的决策，但仍然得不到好下场！
遇到一个战略上有问题的项目，你不做会死，做也会死，怎么办呢？
认识软件项目的战略管理和战术管理
上面两个故事，希望我能大概说清楚什么是战略。项目的战略大概就是指：能决定项目成败的宏观因素，如：甲乙双方在这个项目上的商业利益、双方领导的特点、项目的预算、目标、工期等，还有就是你所带领的团队是否有能力有条件完成这个项目等。
战略上有赢的可能，加上好的战术，项目才有机会成功。
战略上没赢的可能，无论用什么好的战术，项目都逃不过失败。
战略上有赢的大好条件，但你的战术很差，项目也会失败，你浪费了一个大好的项目！
希望我们能尽量选择战略上有机会赢的项目，万一运气不好，挑上了一个战略上没机会赢的项目，那么就要想办法不要死得那么惨。
下面的法则供你参考。
法则1：从战略高度出发
客户为什么要做这个项目？我们公司为什么承接这个项目？
合同的金额是多少？我们公司对这个项目的预算是多少？项目工期有多长？
你的项目团队有什么人？每个人的水平和潜力怎样？
有没有其他影响项目成功的重大风险？
以上问题应该尽早搞清楚，通常来说可以在公司的高层领导那里得到很多重要信息，但如果你无法接触高层，或者高层不鸟你，你用尽所有办法都难以获取以上的重要信息，那么你基本上可以判断：这个项目死定！
最怕遇到一些让你自己解决所有问题的领导，这些只能是无水平、不负责任的领导！除了合同金额一些涉及公司机密的内容可能不方便漏录外，其他信息是必须让项目经理知道的，而且有些事情是需要高层出马帮助项目组去搞定的。
遇到高层不鸟你的情况，法则1-4都没啥作用，你可以直接看法则5。
法则2：尽量提高你在客户面前的地位
通常情况下，我们需要门当户对地和客户接触，高层VS高层，基层VS基层。如果你是一位小小程序员，想和客户高层说话，这是大忌！
很不幸的是，项目经理能经常接触的客户中的最高领导，只能是对方的业务骨干，最多是部门经理，而项目经理以下的项目成员，身份更加是低微了。
为了让项目组将来的工作更加主动，要做好项目组成员的“包装”，例如让项目经理挂上副总、总监之类的头衔，尽量让项目成员的身份放大和提高。第一次和客户接触时，就要包装好你的高大形象。例如项目启动会上，以比较高的形象来展示项目组各成员。
法则3：让客户的高层重视项目
越是高层的客户，越抓得住项目的目标，越是基层的客户，越容易陷入细节，甚至提出很多匪夷所思的要求。如果客户的高层能向下属明确本项目的目标和范围，那么客户的中层基层就比较容易搞定了。
法则2做得好，就很有机会让项目经理可以直接接触到客户的高层，项目经理在掌握了项目的战略的情况下，了解了客户大致想法的情况下，就比较容易驱动客户高层做事情了。如果项目经理不好接触客户的高层，那么就要动用法则4，让你的高层去找客户的高层。
法则4：驱动你的高层做事情
项目中很多重大问题，方向性的问题，其实是需要我们的高层去处理的。例如让我们的高层与客户高层明确项目的目标与范围，推动客户配合需求调研工作，推动上线试运行，推动验收等。项目中出现重大问题，会影响项目成功时，都应该第一时间将问题反馈给我们的高层，让高层去处理或给出建议。
我不觉得你能解决所有问题才叫厉害，在项目组的层面确实有些问题是无法解决的，这些问题如果不及时让高层知道并让高层支援你，问题将会变得更加严重。
如果你的高层是那种什么事情都让你自己搞定的“无能”领导的话，那么本法则不适用，请看“法则5：输少当赢！”
法则5：输少当赢！
如果是项目战略上判断觉得无赢的可能，但你的高层领导认为可以赢，执意要求你执行他的决策，那么本法则可能会让你不会死得那么惨。
做一个战略上不可能赢的项目是很痛苦的，最佳选择是不做这个项目，但通常你没得选，你只能硬头皮上。你应该庆幸，不是让你做战争的统帅，你不会象白起或者庞涓那样会死得很惨，你最多是辞职不干！
万一赢头皮要做这样的项目，只能是“输少当赢”了。向你的高层随时报告进展，遇到什么问题全部抛给他，美名其曰：向您请教应该如何处理！遇到与领导有某些分歧，你可以适当地争论一下，然后假装被你的领导说服，你还要装作很受教的样子。你只能在很有限的空间内，尽量降低这个项目的损失，尽量降低你将来需要承受后果的严重程度。将一些问题及时抛给高层，或许会有机会帮助高层重新思考自己的想法，逐步修正他对这个项目的战略判断，这样的话会慢慢变得对你有利。
采用法则5时，是不得已的选择。如果想不做这个项目，恐怕只能选择辞职；为生活，只能暂时忍一忍，接手这个烫手山芋吧。
关键是心态要好，尽自己力就OK了，对得起自己，也对得起这个项目。挨领导的批可能是不可避免的了，当他唱歌吧！
法则5是没有办法的选择
上策：不做这个项目，或说服领导放弃这个项目。
中策：在做这个项目的过程中，通过不断抛问题给领导，让领导重新思考修正想法。
下策：硬着头皮执行领导的决策，尽量少输。并且在一开始就将项目情况透明化，让领导随时知道项目进展和问题，这样至少有两个好处：1.领导有机会修正想法，从而向“中策”方向发展；2.将来发生问题时，领导就不会觉得“惊喜”了，项目组就不会死得那么惨。缺点就是：一开始就抛问题给领导，领导会不高兴的。你愿意选择一开始就让他不高兴？还是隐瞒问题，最后给一个“惊吓”给他呢？
不过话说回来，所谓我们认为领导对这个项目的战略分析是错的，这只是我们主观的看法。真是情况有可能是以下几种：
1.你是正确的，领导是错的。
2.你是错的，领导是正确。
3.你和领导都判断错了。
领导坚持他的判断，有些理由可能是不方便告诉你的，所以我们也不能断定自己的想法一定比领导的要好。
但这个项目最终是由你来完成的，如果你的想法与领导的想法从根本上是不一致的，做起这个项目来就会相当痛苦。
“挨踢项目求生法则（2）——战略篇”网络直播课程及回放：
我是作者张传波，对于这个题目我还开了一个网络直播课程（免费滴），如果你喜欢此文而且还看得不够过瘾的话，欢迎你继续学习这个网络直播课程。
直播及回放链接：（免费学习）
http://www.umlonline.org/school/thread-2582-1-1.html
作者：张传波
创新工场创业课堂讲师
《火球——UML大战需求分析》作者
www.umlonline.org 创办人
热心网友
时间：2022-05-04 00:03
这些书带给我的启发不仅仅是关于高级IT项目管理这门课程的，也给我今后的人生上了重要的一课。正如项目经理案头手册中提到的J.M.朱兰将一个项目定义为一个计划要解决的问题。该定义使我们认识到，项目管理是在大的规模上对问题的处理。我们生活中也在不断的遇到各种各样的问题，在进行项目管理的过程中，随着工作的进展，也给我们生活中解决问题指明了一条正确的思路和方法。项目问题就是人的问题，这些书启发我们在做事的时候不要怨天尤人，惟有付之行动，生活才会回报付出者；没有计划，就没有控制；要积极主动，不要被动反应；承担责任，争取权力；所有的行为只有从执行者的视角来理解才有意义；人最害怕的是被拒绝，最需要的是被接受；沟通技能是项目经理最应具备的技能之一。
书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。对于我工作中，用户正常使用TAJIMA的流程，就是我期望的东西，而体验到的东西都是，用户不按正常流程执行。问题就在于，用户更本不按流程走。而对于用户来说：用户期望的是可以直接改个供应商或直接改个单价就可以满足采购或财务的需要，而体验到的是在系统中供应商无法更改，单价在采购单更新后，财务部那边的出入库金额数据无法更新。所以用户的问题就是：采购单无法更新供应商，单价更新了无法满足财务的需要，怎么办？到底是谁的问题？当出现这种情况，我往往把用户的问题定义成了问题。想尽方法帮用户解决。书中还有说到：“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在解决的问题。用户入库拒收的库位选错了，入错了库位。我首先将问题的定义为：将入错库位的数据调整至正确的库位。一股脑的想如何去调整，用哪种调整方案最简单？结果表面上是以经解决了，可过不了多久此类情况又会发生。其实遇到这种问题应该先想想，库位选错的原因是什么，是不是之前的培训没有到位？如何杜绝这种情况再次发生？现在该做些什么？应该教会用户在开单时就先确认库位。如在开单时就选错库位就点选取消，重新开过单据。还有一次，财务部提出采购部在采购单上更新了价格，但出入库记录的金额还是没有，希望我们帮忙解决。我首先想到的就是帮财务部将采购单上更新的价格导出给财务部，方便快速。但没有想到问题的起源是：采购部在入仓之前没有输入价格，而要在入库之后才补上，导致现在这种问题。要解决这个问题的方法是让采购部在入仓之前就把价格填上，在入库的时候就会自动获取价格，而不是给财务部导出价格。
书中有个章节“什么是真正的问题？”里面有指出：“每种解决方法都会带来新的问题”，回想过去的工作，的确存在很多问题解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。如果采购部一直都是后补单价的话，就更本不会意识到后补单价是一种错误的方法。
因为时间的关系我没有全部看完这本书，有时间还需要经常翻看。在今后的工作中，需先将问题定义清楚，找到真正的问题，再去找寻解决这个问题的最佳解决方法：解决后产生的问题，没有解决前的棘手且最不棘手的解决方法。
书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。在一个项目的进行过程中，我们不可避免的要和用户之间沟通和交流，当然，在交流过程中，会遇到一些问题。不管用户是非对错，用户提出问题，我的思想老是照着用户的问题去解决问题。在这本书中针对这种情况有详细的解析。我往往把用户的问题定义成了问题。想尽方法帮用户解决。读完此书，以后在用户提出问题后，需先想想问题到底出在哪里？找出问题的真正定义！书中还有说到：“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在解决的问题。书中有个章节“什么是真正的问题？”里面有指出：“每种解决方法都会带来新的问题”，的确存在很多问题解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。
《项目经理案头手册》一书对整个项目过程进行了透彻的分析。刘易斯循序渐进地教我们如何从头到尾地计划、执行和控制一个项目，如何选择项目经理和能解决问题的项II团队，如何用WBS，PERT，CPM和甘特图编制项目计划，如何设计项目控制系统，如何利用挣值分析跟踪项目，如何与团队中各层次的成员进行有效沟通，如何在项目完成后进行经验教训总结。为项目经理展示了如何成功管理不同大小、不同类型的项目，内容讲解深入浅出，案例丰富全面，既深刻地分析了项目管理的本质及一些项目管理现象的内在含义，又简单明了地介绍了实践中具体应该如何操作，很好地实现了理论性和操作性的结合。
美国著名项目管理专家刘易斯为我们提出16步管理模型。从16步管理模型中可以看到项目的战略计划所处的位置：概念确立。就是对所要做的事情有一个框架性的设计，有一种思想；问题的定义。即对长远目标说明。第二步骤是对第一步的进一步细化和具体化；生成项目的备选方案和战略计划。就是提供思路、备选方案和战略计划总体思路；战略计划评估和选择。就是在选择方案的同时，有一个从总体技术路线到总体项目管理策略的评价和选择；战略的确立。就是确定具体的战略、目标；制订项目的实施计划。这是一个更加具体的、第二个层次的项目计划，就是怎样实施；项目干系人批准计划。这里的计划包括战略计划、初步计划、详细计划，在这些项目实施之前，有一个批准过程；签署项目计划。项目的批准人、参与项目的有关干系人要签署项目计划，对计划做出承诺，同时建立项目的跟踪记录，做一个项目进展情况日志或者周志、月志、记录，根据这些记录信息进行知识管理；执行项目计划。执行项目就是正式开展计划，进展这个项目；监控项目进展。计划开始实施之后，就要考虑计划执行得如何，有无问题，要对进展情况进行监控、监测和控制；审查项目定义。项目实施之后，需要做一些评审，评审包括对原来工作的评审，同时也包括对项目目标定义的评审，如有问题就返回到步骤二，重新修正项目的定义；对项目的战略进行评审。首先是评价目标或项目的定义，然后评审战略计划、战略制订是不是有问题，如果有问题就返回步骤四，重新修正你的项目战略；项目的实施计划。具体的计划工作流程、对一些细节要进行评审，有问题就进行修改；循环。按照整个过程不断地从计划的执行到监测、评审，有问题就要修改计划，然后再执行，再评审，这个过程一直延续到全部工作结束；总结经验教训。项目全部完成以后，及时总结经验教训，对一些问题进行归档，作为今后项目的指导和借鉴；结束项目。这是一个完整的项目管理流程，从这个流程可以看到整个项目战略计划实际上是在制订项目的详细计划和实施计划之前。在项目计划的时候，首先要有一个总体的战略计划，在总体的战略计划指导下再开展具体的项目计划。
书中指出项目在结束时失败，而是在开始时失败。在我们开始一个项目时，首先应该搞清楚项目的使命，前景，目标和目的。确定是否要进行此项目。当我们决定要开始一个项目后，就应该制定相应的战略计划，战略要回答“我们怎样对这项工作展开活动”这样的广泛问题，而制定实施计划则要求一丝不苟，换句话说，制定实施计划有关怎样做这项工作的详细事宜。制定计划涉及回答的问题包括：做什么、谁来做、何时、何地、多长时间和怎么做。
其次要对项目进度进行详细计划。项目进度计划编制既是一门科学，又是一门艺术。关于进度计划，真正的重点是为在最短的时间完成项目，找出并行尽可能多的活动的方法。项目管理科学的一面涉及到资源的平衡，它通过计算机运算完成，并存在许多算法。但是，同首次进行项目人力资源分配应用的技术相比，其结果差不多。
另外，资源计划也是重要的一环。完成一项活动的时间取决于分配给它的资源，并且如果没有相应数量的资源，工作就不能按计划完成。如果项目经理不能解决资源分配的问题，项目进度计划就不会成功。
此外，要对项目控制和评审。要达到项目目标，有必要采取适合的项目控制和评审。项目检查有三种类型：即状况、设计和工作过程检查。状况检查主要检查项目是否在进度计划和预算之内、范围是否正确、绩效的要求有没有问题。而设计检查仅仅适用于包括设计工作的项目，检查中经常要问的问题是达到规范了吗？用户界面友好吗？我们有能力制造吗？市场需要我们开发的产品吗？投资回报及其他的产品开发理由荏苒适合吗？之所以进行项目需要检查时因为：随着项目管理水平的提高，同时提高项目绩效；确保项目工作质量不居于进度和成本问题之后；尽早找出开发问题，以便提前采取措施；识别应采取不同管理方式的其他项目领域；确保业主获知项目状况。
在项目即将结束之时应该总结经验教训，若失败，则分析失败原因，可以从以下几个层次进行分析：（1）项目管理环境中的失败 。这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的“配合”。它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型，以及缺乏高层管理部门对项目的支持等。 项目不具备正确的组织结构、项目经理或者团队（以技能、经验、权力、正规性、复杂性来衡量）来“配合”项目。（2）项目管理系统中的失败 。这些失败的根源可以追溯到项目领导及错误实践。它们包括项目经理在项目生命周期中对系统方法的忽略，以及项目管理技巧的错误应用等。具体的可以归结为：不胜任的项目经理 ；忽略了项目的系统本质 ；管理技巧不恰当或者错误的运用 。（3）在计划和控制过程中的失败 ：项目中没有良好的沟通 ；没有用户的参与 ；不充分的项目计划；不充分的项目定义；糟糕的时间和资源估计；不正确的工期安排和资源处理；在执行阶段为数众多的变更 ；不恰当的控制 ；项目终止的计划很拙劣 。同样项目成功也应该总结经验。要取得项目成功，项目的目标定义、项目的系统、整体系统控制、整体计划，包括战略计划、实施计划、日程计划要通过详细、认真地预算、估算，保证项目能够得到充分的资源。在项目的实施过程当中，要通过经常性的审查、控制和评审来保证项目能够按计划不断地推进。 除此之外，组织目标的实现还需要在组织上保证。包括项目经理的领导艺术、项目经理的管理才能、管理技能以及相关的技能、组织结构和团队建设方面。所有的这些，都是保证项目走向成功必不可少的环节。
《微软研发制胜策略》和《微软项目求生法则》两本书也给了我很多启发。求生法则从求生心态、求生准备、逐步迈向成功以及完成任务几方面向我们阐述软件项目是如何存活的。作者利用在研究与工作中获得的经验告诉我们项目开发过程中的规划、设计、管理、质量控制、测试与完工所需的策略与观念，并利用大量技巧建立一套精简可靠的框架来成功的管理项目。软件项目的存活不是一种意外的结果。要让一个项目成功所需的努力并非特别困难或耗时，只是需要从项目开始进行的第一天就勤奋努力到最后一天而已。软件项目是发现与发明的过程。发现与发明融合为一的最佳方式是透过“阶段性完成”的做法，将产品的功能分阶段完成，而最重要的功能最早完成。当项目进行时，许多活动交互重叠，把产品由抽象概念转化成具体成果。项目进行中的源代码倾向以S形曲线而非线性成长，而大部分的程序代码都是在项目中间第三部分完成的。追踪程序代码的成长提供对项目状态的洞悉力。执行良好的项目也可以由一名上层主管选择最有成效的一组来进行追踪。
软件项目被切分成三个概念阶段。在项目初期，焦点摆在“发现”，特别是发现使用者的真正需要。透过技术性调查、与使用者访谈和建立接口雏形，把不确定性的概念转换成确定的观念，这就是第一阶段的特色。在项目进行中期，焦点移到了“发明”上。往大方向看，开发人员要发明软件构架与设计方式。细节的地方，如每个函数式或对象类别也不能忽略。如同发现阶段般，发明阶段的特征在于将不确定的概念转换成确定的观念。如果还有别的特征，就是发明阶段的不确定性要高得多。在发现阶段，开发人员可以确定答案“就在”某个地方。可是在发明阶段，就不能以此类推。在项目的最后部分，焦点又转移了，这次摆在实作上。不同于发现与发明阶段的是，实作阶段的不确定性少多了，故可发掘出许多已确定的观念并可实现成具体成果。
本文提供的项目规划依循着“阶段性完成”的轮廓进行。由于她将项目中开发的软件分阶段完成，而不是到了项目结尾才一次完成，这种方式称做“阶段性完成”。 在每个实作阶段中，项目团队进行细节设计、程序写作、除错与测试，在每个阶段都建立出可能推出的产品。分阶段完成有以下好处：关键功能更早出现；早期预警问题；减少报告负担；阶段性完成可降低估计失误；阶段性完成均衡了弹性与效率。阶段性完成的做法听来似乎毫无缺点，其实则不然。阶段性完成的做法要付出相当代价。因为项目团队需要时间准备各种可推出的软件，在每个阶段重复测试已经测试过的功能，推出软件前进行相关的版本管制工作，提供试用的不同版本软件没预料到的问题的解决方案（如果阶段性完成的软件真的拿出去给人使用），还有规划阶段性发行这种做法的好坏等等，都会提高项目的负担。阶段性完成并不是万灵丹，不过总合起来，那些额外的负担相对于明显改善了的状态、质量与时间的匹配、精确预估与降低风险等来说，不过是一点小小的付出而已。
《微软研发：制胜策略》一书中，作者详细描述了他在美国领导项目的各种实际的策略方法，教我们如何开发高质量的软件。卓越的领导者从不同的角度看世界。若是公司被大火烧得精光，他非但不为丢饭碗惊慌，反而利用火焰来烧烤一顿大餐。当每个人都摇头离去，卓越的领导者仍有充分的信心保持乐观，对每件事都从正面角度来思考。就因为凡事都看光明面，卓越的领导者并不把失败当失败，反将其当作学习克服障碍的经验。正因如此，卓越的领导者乐意尝试各种稀奇古怪的想法，并从中获得重大的突破，即使不成功，他只把这次经验当成获得信息的方式之一。这种领导人不一定要有经验，而是需要强烈的进取心和明确的理想，能够将理想与他人沟通，鼓舞他人共同追寻理想的能力，再加上一点机会，这就是能将理想实现的卓越领导者。坐着告诉我们开发项目要制定详细的目标，包括你要求的输入和输出的目标、长期和短期的目标，项目组要时刻被各个具体目标的实现所鼓舞和激励；不要浪费时间在错误的问题上，一定要先确定真正的问题在哪里，然后才去改正它；人们开口要求的东西未必是他真正想要的，处理他的要求之前，请务必先确定他究竟想要做什么；如果您能够先明确定义自己的需求，再向别人提出，这是避免在沟通上发生误会的好方法；任何不能改善产品的工作，都是浪费时间或偏离方向；项目组每部分的进度要协调一致；一旦发现错虫就立即清除掉，别拖延；程序设计前要先确定它的优先级表，比如稳定性、可移植性、速度和效率等；绝对不要答应别人自己做不到的事情，这样对双方都有益无害；注意定期会议的价值，确定它是否值得每个人放下手中的工作召开会议之前，请确定本次会议的目的是什么，达成这个目的的条件是什么，然后，务必达到开会的目的；会议尽量安排在一个时段的最前面或最后面，尽量减少工作的中断与时间的切割；最会误导项目发展、伤害产品质量的事情就是过份重视进度，这不仅打击人员士气，还会迫使组员做出愚蠢的决定；为了保持创意的活力和团队士气，必须让每个小项目都有令人兴奋的结果；不要让设计师的学习停滞不前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺样样精通的组员。组员的技术和知识应该精益求精；员工应积极学习新的技术、养成良好的工作习惯，做事更有效率，把握有限的时间，增加你个人对公司的价值；不要用年终考评来订立学习目标，要利用年终考评来记录个人的成长；不要给使用者次品，宁愿延期交货，务必追求质量完美；将程序的可共享性当作优先考虑的目标之一，否则程序设计师将经常做重复的工作；如果您创造了一项资源，并且让别人知道，那么总有一天会派上用场的；主管应该把自己视为团队的一分子，与其他人平等，而不是高高在上；健康的生活是一切创意的源动力。这些经验也同时告诉我们做人的道理。
《人月神话》一书对我的触动很大。作者详细讨论了包括工期规划、团队组成、文档、排错等软件项目进行全程中的方方面面。当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。
把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。
1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。
概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。
2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。
组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。
3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。
以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。：）
如果不想加班，不想削减功能，不想推迟发布日期，那么。。。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。
热心网友
时间：2022-05-04 01:21
