《项目管理之美》的序言很有意思，作者说本书是“不依赖任何正规的理论，而是针对核心情况，提供建议来说明如何正确的处理它们”。也就是说，本书并不是为了阐明某种理论而作，而是抛出实践中出现的现实问题加以引申，并给出建议的解决之道。本书的正文也大体是按照这一原则来组织，每一章节都有聚焦的问题，能给读者针对性的解答，也给跳读提供便利。
“项目的中心任务是将不同人的工作结合起来，形成单一完整的、对人类或客户有价值的产物。”这句话对项目任务的定位很高，我觉得核心词是“工作结合”和“有价值的产物”，“工作结合”指的是发挥团队的力量，“有价值的产物”对应的是产品交付的目的，和我们关注产品交付和团队成长的理念是一致的。
“负责使项目及参与项目的人获得最大的成功。”负责会使项目成功这点非常容易理解，项目的成功是依赖于所有角色各尽其职的。但是后一句负责也会使项目的人获得最大的成功是我以前所没有意识到的。很显然负责是一种非常宝贵的品质，能引导人们走向成功，这句话是在说负责的态度在项目中得以锻炼从而形成负责的品质吗？
“观察忙碌的餐厅的厨房和急诊室，发现其他职业如何跟踪任务的方法”这句话反复回味了几遍，第一次看到就感到眼前一亮，学习别的行业的工作方式不失为一个发现、反省的好方法~急症室的情况我并非十分清楚，但是忙碌餐厅的厨房我倒是颇熟悉，可以说看餐厅高峰期厨房的运作情况就可以判断这家餐厅的管理水平和经营状况。大厨、小厨、配菜、传菜、订单、翻台、洗刷……其中一个环节不流畅就会影响到整个流程的运转，其结果就是服务质量的下降。说来，厨房将菜单放在白板上跟踪的方法和我们的白板还颇为相似，只是其速度要快上很多，通常只会持续数十分钟。责任分明、及时反馈和拥抱变化是我觉得能从厨房运作中学到的原则。订单从服务员到传菜员到配菜员到大、小厨，再到传菜员、服务员，每个角色之间都需要默契的合作，菜的需求要被准确传达，而生产出来的菜也需要准确的到达客户手中。责任分明，但仍然会遇到意料之外的问题，如材料不足，客户需求变化等，这又要消息能立刻在整条业务线上传播，否则就可能产生不符合需求的产品。这种时刻也是最考验整个团队应对变化的能力的，是劝服客户，还是因材施法，还是回绝止损都是需要团队在长期的合作中积累经验的。
项目经理需要的特性（Tom Peters）：
· 自我/无我：有自己的想法，投注感情，可能会沾染上个人感情
· 独裁/委派：要有自信，某些时候要能推动团队去完成特定的工作
·忍受模糊/追求完美：控制模糊是产生优秀想法的关键，在初期之后应该追求规范与精准
· 口头/书面：知晓书写或口头沟通在特定时刻哪个更为有效
·承认复杂/拥护简单：在细节和整体间做出平衡，认识到对具体问题最有效的解决方法，并促使团队的目标简单化，而实现充分考虑复杂性
·不耐烦/有耐心：掌握如何推动问题，何时应该退一步让事情发生
·勇气/恐惧：重视风险，但也要勇敢面对
·相信/怀疑：要有信心，看到即将达成的价值。鼓励挑战假设，但要树立团队信念
这些辩证的特性真的有人能全部具备吗？？？但是，根据实际情况来去区别对待的理念是我从学习软件工程以来所一直坚信的——没有什么好管理方法，只有适合项目的方法。做软件的很多人，无论管理者还是开发人员都不喜欢CMM的体系，认为太过繁重，不但不能保证项目的成功交付，还很可能因为要践行高等级能力而造成大量额外的工作拖延项目交付。这些人大多忽略了使用CMM体系的一条重要原则：裁剪，一定要根据项目的实际情况进行裁剪。能做到四级成熟度的团队固然比三级来的优秀，但是对于项目来说未必需要四级的所有过程，强加过程只能是画蛇添足。
“项目经理可能会误认为数据和流程就是项目，更多关注图、数据表、检查列表以及报告等次要问题。应该关注重要且有挑战的事情（编程成果或进度）。”流程不是目标！流程不是目标！流程不是目标！我觉得这是每一个做管理的人都需要注意的，不能舍本逐末，这和敏捷中“工作产品高于文档”也相契合吧。
“你的项目是你的团队，管理好团队，而不是检查列表。如果检查列表有助于管理团队，那非常好。但如果你这样做下去，不久之后，你就需要你的团队来帮助你管理检查列表。”这句话和上一句一样，是管理人员非常容易走进的误区，当工具盖过目标本身，也将是舍本逐末。
项目进度表的目的：
1. 完成任务时间的承诺
2. 鼓励每个人把自己的工作看作整体的一部分
3. 易于管理和分解
下次再听到做计划无用论，就可以用这几点来回答。
“三分法（作粗略估算）：将时间分为 设计、实现和验证三个部分，各占1/3”我记得软件工程中还有一种说法是需求、设计、实现、测试：1/4、1/4、1/6、1/3，非常强调要保证测试的时间，但是在我们实际的过程中，QA的时间是被压缩的最严重的，可能1/6都远远达不到。目前，我们采用了将测试也纳入排期和测试提前介入的方法，期望能控制好QA的测试时间。
“时间表是一种一定几率完成工作的时间节点的列表。不存在完美的时间表估算，需要大家一起预估时间并不断更新时间的估计。主要依赖于可靠的需求和设计。”前一句我觉得体现了动态调整的重要性，虽然未来总是存在不可知因素，但是不断做短期近似预估就会让估算准确，这有点像积分原理，虽然一直是做近似的计算，但是最后就可以刻画出整体数值。后一句依靠需求和设计，我觉得虽然道理很简单，但是估算难做大概也就是因为需求和设计难定吧。软件的第一属性——复杂性，大多也是体现在需求和设计上，我觉得需求和设计也是要依靠迭代、渐近的方式来做才能保证准确性。
“帮助程序员定位到不能明确的部分，从而帮助他们产出靠谱的估算”，我能想到的程序员不能明确的部分：需求细节、技术探索、沟通成本、依赖环节等。可能并不需要PM来帮助他们去估算这些内容，而是要提醒程序员要考虑这些方面的时间消耗。但是感觉程序员本来的预估是依照经验的，本身是包含一定以上因素的，所以如此提醒估算出来的时间应当会比实际时间略长。
“项目管理需要将业务、技术和客户三种视角混合使用，把跨领域视角带进项目”如果每个人都能从其他人的角度多想一想，那么人们之间的争论就会少很多。具体到项目中去，业务、技术、客户这三种思维是经常发生冲突的，如果大家都会转换思维，从别人的角度考虑下，那么团队会更加和谐：如果业务能用客户的思维，那么产品的成功率会更高，如果客户能有业务思维，那么需求将不再难做；如果业务懂技术思维，那么需求将更易懂、更可能被实现，如果技术能有业务思维，那么排期啥的将简单很多，产品也更容易成功。如果这些人能够互相理解，那么项目将非常容易推进，成功率也会高很多。但是，这种设想是奢侈的，就算三种工作都要接触的强大PM，估计也无法保证能在三种思维间自由切换。我觉得PM能做的是记住这三种思维，在考虑重大问题时不断问自己，如果我是业务/技术/客户人员，我会怎么思考这个问题。如果是讨论，保证每种角色都有机会发表自己的观点也是让团队具备跨领域视角不错的方法。
“我们过于关注于自我，愿意花费大量时间为小事而争论，而不是努力去了解我们所做项目的各种视角。”真理！
“项目经理通常负责把每次会议和讨论的结果总结成几个关键点，确保所达成的结论有确切的记录，并能为团队方便参考；提出的问题应分配给恰当的负责人，并在下次会议时讨论。”能将会议和讨论既完整又简洁的记录下来，是一项十分强大的能力。记得以前在国企，如果会议结束不将每件工作分配到具体的负责人，规定好具体的完成时间和要达到或交付的成果，那么工作很容易就会被搁置下来。并非真的是国企拖沓，而是一件事很容易牵涉很多人，每个人手上也会有很多工作，如果不明确责任，时间和成果，那么大家都会以为别人在做，或者以为事情的优先级低而不去做。所以我觉得只要涉及到分工合作：明确责任、设定日期和约定成果这三件事就需要明确。
链接: https://pan.baidu.com/s/1o1pKJT2n3zrtwEHZLKgIQQ 提取码: nywy 复制这段内容后打开百度网盘手机App，操作更方便哦 |
|
