读《项目经理应该知道的97件事》

来源：互联网发布：上海达观数据公司咋样编辑：程序博客网时间：2024/05/23 01:57

尽早让用户参与
避免打地鼠式开发
1. 当估计某一功能的实现时间时，不要只考虑最初写代码所花费的时间，还要加上提升、调整和改进这些代码所需的时间。写高质量的代码和测试都需要花时间。从短期来看，这似乎是一种损失，然而它带来的却是长期收获
一词不慎坏大事
让项目发起人自己写需求
1. 项目不能达标的首要原因几乎总是需求定义太差
2. 处境最危险的公司是那些业务分析能力较差的公司
3. 如果在需求定义阶段没有认真、具体的考虑这个项目要创建什么，那么，这个项目可是岌岌可危了
4. 项目所有人需要传达的是他们想要这个软件做什么，而不是程序员将如何着手生成这一结果
要简单，不要复杂
1. 软件通常要解决复杂的问题。现在的问题是，那种固有的复杂问题中有多少是你强加给最终用户的？你的软件是不是一个复杂问题放大器？成功的软件通常是一个复杂问题吸收器，因为它首当其冲的为用户承受了复杂的问题，而不是将这些问题一路传递给用户
2. 简单性不会偶然发生，它需要积极培育。而复杂性会因你不留意而丛生
偿还你的技术债
1. 当开发人员最终举手投降说他们需要在一个系统上重打锣另开张时，实际情况极有可能是，许许多多没有偿还的技术债已经使他们不堪重负，债台高筑之下，他们觉得还不如痛快的宣布这套软件破产了
2. 只有一直坚持识别债务并迅速处理它，你才可能总是用“最低补偿”来避免接踵而至的混乱
为团队增添人才而非技能
1. 我和我的伙伴之所以会进入这个高新技术产业，正是因为我们希望走在科技的最前沿。我们之所以进入这个行业，正是因为这个行业所涉及的永远都是新的领域，永远都要学习新技能和新技术
2. 如果看到一个雇主在聘用新人时要求其技能达到精确匹配，那么，这个雇主其实是说：“我们不打算投资你”
3. 请记住你要聘请的是人才而非专业技能
西蒙，保持简单
1. 项目的利益相关者往往使事情变得过分复杂，这是软件项目失败的一种常见原因
2. 利益相关者不应该把软件项目建成一个统一、巨大而僵化的怪物，而应该让信息技术团队把项目建成一颗洋葱，每长一层就表示成熟一分
你并不是非比寻常
1. 注意力集中在软件项目的解决方案上，而不是试图为一个已经满满的工具箱再装入一个工具
2. “非我发明不可”综合症使许多杰出团队脱离正轨
随时间滚动
你们的问题，我不买单
如何发现优秀的IT开发人员
1. 编程世界正朝着敏捷开发方向发展，跨职能沟通和软技能将越来越重要。开发人员将会与公司中其他部门的人组成小组一起工作
2. 招聘软件开发人员时需要遵循以下指导原则：
  1. 审查他们是否掌握开发生命周期的正确知识、方法、工具，以及他们对所在行业（领域）的熟悉程度
  2. 考察他们在工作环境下应用知识的能力
  3. 测试他们的沟通能力和社交技巧
  4. 寻找对工作有正确态度的人——既渴望创造出高端产品，又能接受项目的限制条件。是否有证据表明他们能及时且在预算之内生产出“切合意图”的产品？
3. 不管你的应聘者多么有风度而且懂技术，都要始终核实发证机关的资格证书和前任雇主的履历条目。聘请阶段小心谨慎可以防止未来很多问题
优秀与普通的天壤之别
1. 真正优秀的软件开发人员比普通开发人员要高效得多
2. 一个熟练的程序员不只是略高于平均水平，熟练与否的差异是巨大的
3. 雇佣中等或普通的开发人员会减缓项目速度。常常是，让一个差的开发人员离开团队比新加入一个优秀的人员作用还要大
4. 普通开发人员会拖累整体生产力，并且使项目花费的时间比实际需要的更长
5. 给优秀的开发人员强有力的工具，你将更快获得高质量的软件
6. 拥有普通开发人员对项目没有帮助，并且照顾差的开发人员会消减优秀开发人员（他们是工艺师）的生产力
7. 花额外的钱聘请和培养优秀的软件开发人员。这将在短期和长期（维护代码时）都给你带来回报
规模决定一切
1. 把项目尽可能的分成许多独立的但可掌握的工作流
2. 确保每个工作流至少有一个负责传送的关键联络点
3. 如果可能，尽量让主要成员在工作流中有交叉，以使整个团队可以共享大局观
4. 分别独立追踪每个工作流的进展（使用任何工具），并且定期监控节奏以掌控整个项目的动向
5. 分别记录和共享每个工作流的风险、问题、承担的责任以及以来的条件
6. 定期举办小组会议，通报每一个工作流的状态
7. 公布整个项目的进度路线图，包括所有不同工作流的发布计划
8. 积极使用在线工具来共享用户需求、里程碑更新、错误报告、报告时限以及风险
记录工作流程，然后严格执行
剔除多余的流程
1. 成功的团队做了什么其他人都没有做的事情？他们不断质疑自己的流程，并努力消除多余的环节。他们毫不留情的对自己的软件开发进程进行重构
2. 完美，不是指无可增，而是指无可减
3. 谈到流程时，“少即是多”是一个非常重要的哲理
矛盾体的需求说明书
1. 将你努力制作的东西与怎样去制作它区分开来。然后让训练有素的各个团队成员根据他们自己在项目中的角色来做决定
商业价值始终是衡量成功的标准
1. 如果没有把项目的商业需求联系在一起，再好的软件也可能一败涂地
不要总因项目放弃休假
1. 在敏捷开发中，让团队具有自我指导能力是很重要的，其作用十分强大。项目经理把易于理解且高度透明的工作流程放在显眼的位置。随着时间的流逝，团队采用且适应了这些程序，项目经理就会管理的越来越少，并且越来越顺利。从本质上讲，消除障碍和解决问题就会逐渐取代日常的细节管理
2. 永远不要仅仅因为没有你项目就会停下来而取消休假
集中精力
1. 通常情况下，一个人在经历一件琐事后需花费20分钟才能回到原来的思路上
2. 开发人员要知道他们需要优先考虑的头两项事情是什么，这样他们才能在限期内有效的安排自己的工作。在没有被明确告知什么才能带给项目真正的商业价值时，就算领悟力最好的开发人员也只能随意的瞎猜，抓不住重点
3. 计划中的会议对编程者来说特别成问题，因为他们提前知道日程表上有一个即将要办的事情时，就可能会浪费时间
4. 对于开发人员来说，他并行参与的项目每增加一个就会使他的生产率降低50%以上。同时参与三四个项目的开发人员经常需要花费更多的时间参加会议解释为什么工作没有进展，而不是在实际工作上花费更多时间。当开发人员必须投身于多个项目时，一定要确保在转到另一个项目之前，至少能将连续两天时间花费在一个项目上。这样他们重新熟悉每个项目的时间总量就会减少
项目管理即问题管理
1. 项目管理就是问题管理
2. 一个项目最具挑战性的方面不一定是技术或时间表，而是参与项目的人
授权：蒂姆的故事
1. 往往一个软件项目经理的最佳工作方法就是设定愿景，确定好优先级，然后就闪开
2. 任务追踪系统的重要意义常常未被充分认识
3. 当一个优秀团队拥有清晰的愿景、明确的验收标准和众所周知的项目优先级，而不是由项目经理一个人掌握、记录并且管理整个团队时，你将会为这个优秀团队的能力惊讶。有时候项目经理最好是无为而治
聪明代码很难维护
1. 最好大胆的让开发人员探索更多的新语言和开发工具，赋予他们这种自由，因为这是他们发现新方法以改善编码实践和结果的必由之路
2. 要毫不犹豫的让程序员着手尝试新的语言
3. 若没有足够的文档记录来维护你的软件时，就只能替换它了
4. 任何程序员为了保住工作，都可能试着聪明的解决问题，但是没有项目经理能从中受益
5. 太过聪明的代码最终会难以维护。那会导致维护失败，对软件系统展开代价高昂的返工
掌控人的因素
1. 种种人为失败都可以归咎于我们喜欢重复过去的行为方法
2. 因为大多数项目的目标是开发新的产品、服务或解决方案，所以应该鼓励敏捷与灵活的头脑和工作方式，而非重复过去的行为。当你面对一个新的艰巨任务时，依照旧程序恐怕达不到原来的目的
3. 是什么在给你的团队施压？
4. 压力导致人们沿用过去的行为而不是积极采取解决问题的行动。作为项目经理，你有责任找出会导致项目组成员回到过去老路上的压力是什么。通过与他们积极对话并且仔细管理好他们的工作环境，你可以为他们免除压力或者将压力的影响降至最低
5. 人都有感情，所以在工作中受情感影响是自然的。但是只有人才能开发软件，所以要像监管和保护你的其他资源一样仔细的培养和管理你的人力资源
使用维基
1. 不要复制信息。如果信息放置在其他地方，可以链接它而不是复制
2. 任何时候你想通过电子邮件传送项目信息的情况下，你都应该考虑团队维基是否更适合用来交换和存档信息
缺失的环节
1. 确保所有的管理层支持该项目的目标
2. 在每个新项目开始时，软件项目经理、部门经理或主管、资助者或另一位关键利益相关者应该联名给每位项目成员发送一封个性化邀请信。这封信或电子邮件应该解释即将开工的项目的高层目标和每个具体团队成员的高层职责
3. 宣布项目成功完成时，要给每个项目成员颁发成就证书。这份证书的副本将放进他的人力资源档案中，用作季度业绩评估时的参考
估算，估算，再估算
1. 要想能更好的进行估算，最好的方法是确保随时了解实际情况，这样团队就能得到估算结果的反馈信息。
2. 估算的真正作用不是让人们达到他们的估算目标，而是一旦他们认为达不到时，可以事先提醒你
项目管理办公室在前进
1. 似乎全世界的所有人都在所有部门推进标准化的方式
重苦劳，更重功劳
1. 如果你墨守陈规的要求程序员必须加班加点的工作，那么一定要确保他们工作能产生额外且可用的结果
2. 谈到工作时间，你的程序员就像枫树。占用他们少量但充足的时间，指定一些宽泛的任务，他们就会茂盛起来。给他们布置艰巨的任务，要求他们经常加班，他们就会开始枯萎
3. 连续工作12小时甚至一整天的程序员不可能多产而高效
4. 鼓励程序员报告他们所取得的进展，而不是报告他们工作多长时间。让他们知道你关心他们取得的成果，而不是想掌握他们在电脑前花费的时间。一旦团队成员意识到你是一个注重成果的经理而不是一个“投入时间”的经理，他们的关注点将转到获取结果而非数着钟点工作
软件的失败是组织的失败
1. 开发软件需要有效的度量标准、清楚的沟通交流以及全身心投入的业务和管理人员
2. 工作的每次迭代应该包括新的业务功能，也包括对一些不可避免出现在代码中的修改进行重构。这是一种编程现实，而相关的管理者必须给予一贯的全力支持
3. 组织必须努力跟踪行业发展趋势，获取恰当的工具，并采纳优良实践提升程序员的工作效率。要鼓励开发人员在工作时间内外拓展他们的知识。尝试新工具、接受培训、参加高价值会议、阅读书籍和博客，这些都是在这一领域必需持续努力去做的
4. 软件开发工程师一旦感受到来自老板的支持，往往就会表现得更加忠诚，更愿意完成额外的工作。而且，他们更有能力随时应对需求与技术风格的改变
来自另一端的声音
1. 试图拥有一切，你最终会一事无成
2. 我们本应该从一个更简单的系统开始，在熟悉了其功能之后再增加其复杂性。我们本需要一辆完整的自行车，结果却得到了一个不完整、不实用的宇宙飞船
保持洞察力
1. 如果项目经理决定最佳解决方案的依据只是热切的想取悦用户，那将会导致严重的问题。事实上，项目经理可能还没有训练自己保持不偏不倚的洞察力
2. 洞察力意味着寻找最好的解决方案，而不是感觉适合用户的简单解决方案
3. 如果没有揭示出真正的问题，则所有努力只是治标不治本
4. 当面对沮丧的用户时，应该提出一些列的问题，去发掘引起他们沮丧的根本原因。千万要克制，不要为解他们的一时之痛而提供一种暂时的解决办法。在设计解决方案之前，确保瞄准的目标准确无误，这才符合客户的最佳利益
怎样定义“完成”
1. 如果没有明确定义“成功”意味着什么，一个软件开发团队就很难取得成功
2. 不管你的方法如何简易，可交付的软件都需要一定数量的文档资料
3. 我们不要因为行政或者商业的事情来加重开发人员的负担。我们需要传递的重点理念是：迭代不仅仅是开发人员的事。对更大范围的软件项目团队成员来说比较重要的任务，都必须和这些迭代协调一致
60/60定律
1. 软件生命周期中60%的费用与维护相关，而维护活动中60%的费用与用户产生的改进（需求的变化）相关，23%与迁移活动相关，17%与修复bug相关
2. 超过80%的维护活动都或多或少与需求变化相关
3. 维护期间的一项主要活动就是理解要作出的改变。大概总维护时间中的30%是花在对现有软件产品的理解上
4. 软件各部件之间不需要那么紧密耦合，应该像万维网一样，各部件在最后必要时刻才以灵活的方式捆绑在一起
遭遇敌人……敌人就是我们自己
1. 如果会议时间太长，你就是在窃取开发人员宝贵的编程时间，而他们正指望用这些时间来完成项目进度
2. 无论以前用过的方法如何完美，在这里都将不起作用
3. 如果一个人的工作被打断，他可能至少需要一个小时才能恢复先前的生产效率
4. 不要拒绝让你的开发人员使用最适合工作的工具
工作循环
1. 开发人员是受他们的胃驱动的
2. 任何循环的最后阶段都是奖励阶段，对团队和个人的可持续健康成长来说，这是很重要的。如同电池在使用后必须充电一样，大脑和身体必须通过大家对工作的认可来获得犒赏
先照顾好自己
1. 先快速戴上自己的面罩，我们才会有能力使出100%的力气照顾别人，最后大家都活下来
2. 虽然生活会一直给我们抛出难以击打的曲线球，但制定短期和长期目标会帮我们明确目的，在经历风雨之后重新回到正确的人生和职业轨道上
别指望开会写出代码
1. 除非有明确目标，否则不要安排会议，而且就算开会，也只邀请那些有必要参与的人们出席
2. 在会议上提出已经显现的风险或障碍是好事，但会议上不是提出解决方案的地方。可以组成更小的团队或指定适合的团队成员在会后继续深入探讨这个问题
3. 如果你遵从敏捷方法，日常短会是必须的。但如果不遵从敏捷方法，那么一定只在必要时才召开会议来传达信息或搜集数据
绘制变化进程图
1. 当要求人们改变他们的工作方式时，使用诱饵的方法（奖赏）比使用批评（惩罚）的方式要好得多
2. 用户和他们的管理人员始终关注的就是实现他们的商业目标。转变到新的流程、工具和系统对这些目标构成了潜在的威胁。详实的前期计划有助于提供向新系统的平稳过渡，为认同和接受铺平道路，并且提高长期使用的可能性
达成共识
1. 让每个团队对于整个计划目标（而不仅仅是自己承担的项目任务目标）都有清晰的认识，这无疑是大有益处的
依据现实制定计划
1. “缓冲时间”能够在无需做出重大调整的前提下，为项目的每个阶段赋予一定程度的灵活性。可以把“缓冲时间”开做是一个阶段的应急储备时间
完美实现的谬论
敏捷的沟通系统
1. 当反思失败的项目时，大部分责任都归于软件项目经理、团队成员和利益相关者之间的无效沟通
2. 敏捷方法的关键之处在于及时的沟通循环，使敏捷团队能够有效应对未预见的变化，并且快速的重新评估和设置优先完成的项目功能
3. 一个典型的误解就是同步沟通总是比异步沟通有效。添加开发工具和简单的异步沟通环路可以作为面对面沟通的有效辅助
4. 项目经理的职责和挑战就是简化每一个项目层次的反馈环路，使之更高效
不要崇拜方法论
1. 过于推崇某种方法论，就会妨碍自己管理项目
2. 项目经理所关注的一定是项目的成功完成，而软件项目的成功完成主要与交付相关
3. 所有项目管理知识只是一种手段，不是最终结果
4. 同你自己强劲的判断力相比，任何一种让你感觉需要被迫去遵守的项目管理书籍或方法都不重要。你应该先进行产品分析、合同分析、初次风险分析以及与主要利益相关者（客户和赞助商）的面谈，然后再选择项目管理战略
电子表格解决不了人的问题
1. 在想法、目标、价值观、信仰和需求方面的多样性应该是团队的主要优势，而不是弱点
2. 大多数冲突会影响生产力和工作效率，圆满的解决这些问题能切实的增进人际关系，促成创造性的改变，改善工作成果。所有解决冲突的策略都依赖于积极的沟通、主动的倾听、富有同情心的理解以及一些有效的谈判或仲裁
一件交付任务需由一个人负总责
1. 每一件交付任务都应有一个对应的责任人负责它的完成。在一个项目里，应该清楚的知道负责每件任务交付的责任人
2. 在项目进展的过程中，当无论遇到任何问题都能确切的知道该找谁咨询时，所有团队成员，特别是新加入的成员，将会效率更高
3. 当一群人浪费时间来讨论谁应该对这件“群体”任务负责时，那对整个团队的执行力而言，实在是最具破坏性的
4. 你不应该是不断的归咎责任方，而应该是正确分配责任
知识完善的谬论
1. 假如停止学习，我们很快就会落后于别人，特别是在软件行业里。一个人可以在一个行业里先做学徒，然后用余下的一生在这个行业里实践——这个观点就像渡渡鸟一样已经过时了
2. 科学、技术及其背后的思想在这个年代变得太快，任何一个实践者都不可能在任一方面及时的掌握他所需要掌握的所有知识
3. 在软件项目生命周期内的任何阶段，需求永远不会被完全了解
培养团队跑马拉松，而不是冲刺
1. 为了跑马拉松，团队必须纪律严明，每天训练，保持一个可以持续的速度
2. 我们需要保持一个稳定的工作进度。可持续发展的团队就像是在跑马拉松而不仅仅是在冲刺
3. 软件项目经理是促进团队发展的最佳人选，其工作的目标就是建立可持续发展的团队，通过这种途径为项目带来附加价值
4. 假如项目经理重点关注团队建设和个人能力提升，整个团队自然就能不超时、不超支的完成交付任务
5. 通常，项目经理会陷入日常的灭火任务。因此，他们不可能真正有时间从战略高度来建立团队
6. 我们需要从根本上改变软件项目管理关注的重点，以使项目经理扮演更具战略性的角色。将战术性的东西留给编程的团队，这将确保团队在项目中具有主人翁精神，而项目经理则成为真正的协助者或催化剂，确保这个项目整体朝着正确的方向发展
7. 项目经理的大部分工作应该是培养团队处理不可预料的变化的能力，而不是参与日常编码和架构决策
8. 软件项目经理就像操作系统的内核。内核本身不会完成最终用户的任务，但是它能确保用户的任务是有顶端的应用程序准确完成的。如果项目经理可以成为真正的推动者和教练，确保团队成员实现最佳合作，那么他一定可以建立一个能自我管理的团队，这个团队不仅能跑马拉松，还能交付高品质的软件
三位一体的项目管理
2. 对范围的界定会是关键的第一步，而且也是一个主要限定条件
3. 在所有项目刚开始时，一定要对基本的项目管理内容进行概括，这可以帮助团队成员充分理解他们的职责以及具体的支持细节。同时不要忘了介绍你作为项目经理的职责
路线图：最近我们为你做了什么
1. 对于任何项目而言，良好的内部和外部沟通都是成功的关键因素
2. 重要的沟通工具就是正式的项目路线图。项目计划可以帮助你手下的项目团队定位任务阶段的变化。项目路线图能够使更广泛的利益相关团体充分理解可能在更高层面上发生的变化
3. 项目路线图有助于传达计划之中的变化、特定变化的时间表以及这些变化将对工作造成的影响
4. 如果说不出商业价值，那么你就应该考虑该项目是否需要实现这个功能。如果一项功能没有切实的商业价值，它就不应该出现在你的路线图上，对于这样的功能，我们一定得采用成本/效益分析来做进一步的审查
5. 建立项目路线图的方法使利益相关者有了话语权，而且让他们知道该期望什么。同样重要的是，路线图让团队能够定期对外公布每个季度已成功提交的功能
项目规范说明的重要性
1. 范围说明详细阐述了项目的愿景，它描述了目标和交付成果，并诠释了怎样才算项目最终的成功
愿景与期望结果保持一致
1. 要真正理解项目的技术需求和要提供的商业价值
艾丽丝不是美国人了
避免合同纠纷
1. 客户是搭档而不是对手
2. 当发生争议时，要通过双赢的方式来解决。即使合同对你有利，也要进行协商。虽然你可能会觉得你能够在法律上证明你是对的，但是这样做会伤害双方的关系，就算官司结束了，双方关系的恶化以及显而易见的项目僵局都将有碍项目的最终成功。只要还有一线希望，就不要使用法律手段，那是万不得已而为之的举措
评估什么，就得到什么
1. 如果你以错误的东西作为评估指标，你就是在鼓励错误的行为
2. 研究显示，延长工作时间未必会产生更好的工作结果。在大多数情况下，延长工作时间实际上会造成工作质量更差
3. 创建真正的产品所需要的不仅仅是研发速度
4. 要确保团队里的每一个人都能真正理解成功意味着什么。要帮助团队成员建立一个共同的愿景和共识。通过建立双赢局面鼓励团队成员间的合作，以使每个成员都有共同的关注点，并朝着共同的目标前进。
5. 成功项目的秘诀是利用衡量指标作为达到目的的手段，而不是使衡量指标本身成为交付的任务
他山之石，可以攻玉
1. 项目管理知识体系是指那些“公认为好的”技能、工具和方法
要现在不要马上
1. 快速成功仅仅比迟来的成功好上一百倍，但快速失败可比迟来的失败要好上百万倍
2. 如果你使用的软件语言或框架不能在几秒钟或几分钟内实现新功能，那么你正在使用的工具就是一个问题。如果编译代码需要几个小时而不是几分钟或几秒钟，那么你就做不到早构建、常构建
速度就是生命，越快越好
1. 对于特定的行动、战术和表现形态而言，具有优势的是最佳速度，而非超常速度
2. 在公司的商业计划里，“第一个上市（速度）”也许根本就无关紧要。首先进入市场者因为过于关注能量（速度）而忽视能量管理（只有当某项业务功能的确需要速度时才运用高速）并最终破产或牺牲的例子，在技术领域里数不胜数
激发团队士气
1. 软件项目经理的一个主要职责就是，创造一个良好的工作环境
  1. 对团队在项目发展方向上加以控制
  2. 保护团队免受“官僚制”影响
  3. 想办法改善工作环境
  4. 让团队成员感觉他们的确像一个团队
  5. 保持工作和生活间的协调关系。你可以偶尔要求人们加班，但是如果你打算从人们的生活中占用时间，你就需要日后再把这些时间还回去
  6. 有因必有果。你应该问自己“我能做些什么来改善团队的工作条件呢？”
  7. 确保团队成员能看到你的努力。你也是一名团队成员，因此整个团队需要知道你正为团队所做的工作。团队成员往往不会信任一个总是藏在门后的经理，也很容易跟随那些有目共睹在为团队争取利益的人
项目要依靠团队合作
1. 为了让大家高效工作并创作出优良的项目成果，工作责任的分配应该直接与个人挂钩，而不是与这个人所属的部门或机构挂钩
2. 根据个人的工作能力以及工作性质，每个人可以在一个项目中同时扮演不同的角色。一个人可以在此处是一位领导，而在别处则是一位参与者
3. 一旦委派别人去做，就不要干涉。作为软件项目经理，你要做的就是进行监管、提供支持、询问结果。这样做，你就可以激励团队、赢得尊重并培养团队成员的“反应能力”
为团队服务
1. 项目经理的一个关键作用就是提高团队的速度，要努力为团队的生产力创造一个没有阻碍因素的环境
大圆球谬论
1. 对需求变化的严格控制会起反作用，会降低软件系统对最终用户的实用性
2. 需求肯定是会变的。我们必须维护好代码，我们必须插入新需求，尽管这样做会破坏我们的最初设计
应对危机
1. 定期召开团队通气会，并在关键阶段（例如测试）之前，加大通气会的频率
2. 记录每个风险，且有确定适当的应对措施
3. 风险记录定期更新，保证是最新的
4. 团队专家所接受的培训达到相应的水品
5. 制定了危机管理计划，关键任务已分配到人
6. 危机管理计划有清晰的内部及外部沟通策略（计划）
了解集成要点
分布式项目要积极促进沟通
1. 站立会议比座谈会议好，参与者会更专注，因为没人希望站很长时间
2. 确定每个关键岗位都有一名后备联系人
在开始时就要胸有成竹
1. 了解期望和需求的差异（我期望得到一个SUV，但是我实际需要的是一个小排量的小汽车）
清晰的条款，长久的友谊
1. 清晰的条款等于长久的友谊
2. 开会时，尊重其他的项目团队成员，当有人说话时，不要窃窃私语、插话或者干扰正在发言的人
做实际工作的人才是最好的估算人员
沟通最关键
1. 在大多数情况下，如果你愿意倾听并且帮助寻找解决问题的合理方法，客户是会站在你这边并且随时支持你的
2. 软件项目依赖于面对面的沟通
项目就是对解决方案的追求
1. 有谁会比真正操作项目任务的团队成员更了解需要做的工作的呢？当项目经理认为只有他一个人了解怎样细数项目工作的方方面面时，项目就注定会失败
2. 如果不能清楚地定义项目工作，如何能制定计划、预算以及进度呢？
傻瓜，人最关键
1. 永远不要忘记，你的项目团队成员都是有野心、有优势、有局限并有弱点的人
2. 项目的成功更多依赖于团队成员的态度和才能
3. 管理项目可以很随意，但是不要忘记领导团队 // 参考《领导力是一种激励的能力》
4. 项目的成功取决于你的领导能力
5. 对待团队成员，要开诚布公、坦诚且直率。定期给出反馈，不要仅仅在复查阶段。反馈应对事不对人
文档是手段而非目的
1. 积极利用文档发起有意义的对话，而不要用它来替代所有的沟通方式，更不要在人们违约时用文档来指出这种违约行为
2. 是否有价值应当看是否在规定的预算内完成了正确的目标、让客户满意甚至超于预期。如果手握错误的准绳，那么很容易就会忘记真正的终极目标是什么
3. 成功的项目经理仅仅做够用的计划，把握够用的细节
4. 计划和流程中的文档是使项目正常运作的手段，而不是最终的目的
报告中挣值与速度两种度量能共存吗
1. 敏捷开发方法里，我们允许人们在下周承担的工作量预估值不会超过他们上周完成的工作量
范围改变经常发生，要适应它
1. 项目受到三方面的限制：成本、时间和范围
2. 如果项目遇到麻烦，此时投入再多的资金或资源都无济于事
3. 每一个新的软件产品都有“必须具有”和“最好具有”的特征和功能。通常来说，“最好具有”的功能的数量要成倍于“必须具有”的功能
买现成的软件
1. 如果你的公司决定要购买现成的软件，在购买之前，一定要多用一些时间去分辨真正的需求，并研究准备购买的软件在功能和技术上的细节。无论软件供应商对你来说是熟人还是陌生人
三类项目赞助人
1. 就像管理项目一样，管理赞助人同样是项目经理的责任。和赞助人保持良好的信息沟通，仅在必要时才让他们参与进来，同时避免赞助人控制这个项目。要学会识别不同类型的赞助人，并且准备好相应的对策
该少于承诺还是多交付
1. 在项目收尾阶段，如果交付的任务少于你之前承诺的，那么你就不是个好的软件项目经理。如果交付的任务多于你之前承诺的，那么你就是个英雄。但实际上，你应该努力交付之前所保证的，既不多也不少
每个项目经理都是合同管理者
1. 每个团队成员应该熟知合同内容，包括范围、时间和各方的权利与义务
2. 项目的成功主要以客户的满意度来衡量。关键在于不要抵制变化，而要控制变化
重要，但不紧急
1. 《高效能人士的七个习惯》中将任务依据重要性和紧急性来划分任务：
  1. 重要且紧急：迅猛龙式的出击
  2. 重要但不紧急：准备好未来的产品策略，重做产品中有问题的部分
  3. 不重要但紧急：邻居打电话说借点糖
  4. 不重要也不紧急：上YouTube网站浏览网页
2. 聪明的经理不会让员工做不重要的事情
3. 重要且紧急的任务通常在出现时就要及时处理。然而，你应该努力建立风险预防体系来消除这些事件的起因。要想减少重要且紧急的事情，最好的办法就是建立反馈循环，以处理这些时间发生的根本原因
4. 重要但不紧急的任务是你工作中要做的最重要的事情，这正是你利用知识工作并产生价值的所在
5. 作为软件项目经理，你要让整个团队关注重要但并不紧急的任务。你的工作就是避免团队做那些毫无意义的任务以及来自其他团队的紧急但不重要的任务
6. 你的团队不能忽视重要且紧急的任务，但是，如果你的团队将所有时间都用于灭火，那么，你就需要去修理引起这些火灾的故障线路。久而久之，你的团队花费在重要但不紧急的任务上的时间就会越来越多，这类人物才是项目成败的关键
讲授流程
状态的假象
1. “完成”是由客户定义的
他们到底想听什么
1. 沟通是项目中最重要的活动
团队士气金不换
1. 高昂的士气不只意味着工作环境更好，还意味着团队效率更高
2. 士气是一种衡量标准，它衡量的是团队对领导的信任程度、队友彼此间的信任程度以及大家对自己能力的信心
3. 作为软件项目经理，创建一种士气高昂的工作环境是你的责任。如果团队成员把你当作他们的领导者去尊敬，感觉到能和你开诚布公的交流并且能够影响事情的结果，那么士气就会提高
4. 士气高昂，员工的满意度就会高，人员流失率就会降低，生产率也会提高
让利益相关者全程参与
1. 与那些对项目结果有重要影响的利益相关者形成一种良好的工作关系是十分必要的
2. 使工作方向与所有关键利益相关者而不仅是几个高层利益相关者的需求相一致
3. 即使你不同意，也要尊重利益相关者的商业需求
计划的价值
1. 制定计划的唯一目的并不是编制一堆文件
2. 计划的目的是促使你去思考项目
3. 计划的过程会加深对项目的理解
4. 计划会帮助你明白完成目标所需要的条件和方法
5. 完整的计划是价值连城的项目沟通方法
6. 初始计划的目的在于设定方针路线。初始计划设定项目的意图，并绘制一个实现目标的合理路线图
不要总是扮演“信使
1. 项目经理需要在合适的时间召集到一群合适的利益相关者来讨论合适的话题
2. 转述过程中信息丢失是不可避免的，最终又要浪费大量时间来处理善后事宜
有效管理交付产品
1. 在检查点，应该根据基线和趋势分析对关键绩效指标和度量指标进行评估，以明确差异。根据实际标准而不是直觉或传闻来采取纠正措施
我们只是项目经理，不是超级英雄
增加交流：时常召开即时会议
1. 如果会议只是在老板或者项目经理在的时候才召开，那么就取消它。你的团队告诉你，他们并没有从中获得价值。千万不要只因为一个人感到有价值而开会
用灵活性简化项目管理
1. 不要对任何一件武器或者一种作战方式产生依赖
2. 绝对不能过于依赖某一种管理原则、软件工具或编程语言，不能贪恋唯一的武器
Web为现在指明了道路
1. Web是最大、使用最广泛、迄今为止人类所建造的拥有最健壮的信息检索功能的系统
开发真厌烦状态报告，经理们却喜欢
1. 一般来讲，一个项目经理会同时指挥五到七个项目
你没有控制住
1. 表面上对局势的控制，并不意味着你就真正的掌控了局面
分享观点
1. 分享项目信息的一个好办法就是每天开例会
2. 快速的“站立”例会是软件项目经理分享项目最新情况的绝佳方式
善于支持的组织就能获得成功
1. 团队中那些唱反调的人常常被看作是麻烦制造者。如果公司急于“斥责唱反调的人”，团队成员就不会再叨叨那些让你烦心的事儿了，甚至还会有意隐藏项目中的问题
2. 明智的管理人员会大力支持那些有助于开发人员提高效率的态度和行为
3. 一个经典的反面例子：公司官方“鼓吹”团队意识，但却一直奖励个人贡献
4. 永远做一个诚实的软件项目经理。不要企图掩盖问题或通过简单的大事化小来回避冲突和不愉快的讨论
5. 在你的项目团队中创造这样一种氛围，即你很愿意看到整个公司都来指出你们的错误
6. 如果项目前景并不乐观，精明且有原则的项目经理就应该建议取消这个项目，除非外部问题都得到了解决
建立项目管理控制
我讨厌你的网站的9.7个原因
1. 一上来就是一个慢吞吞的Flash界面
2. 淬不及防、难听刺耳的视频剪辑吓我一跳
3. 禁用后退按钮
4. 选择一个让人看不清的配色方案
5. 忽视我的便携式设备
6. 没留下电话，让我联系不到人工服务
7. 非要让我打电话了解情况
8. 区别对待（歧视）不同类型的客户
9. 提供了毫无用处的搜索功能
10. 把按键的标签弄错

from: http://dearymz.blog.163.com/blog/static/20565742013319932643/?suggestedreading&wumii

0 0