|
第1讲 程序员做项目管理的三个误区 管理的误区：1、事必躬亲；2、追在别人屁股后面做监工；3、拿着锤子，看哪里都是钉子 解决思路： 1、事必躬亲，团队长期发展，效率低下，自己也会越来越忙碌，濒临抓狂崩溃边缘。 改变：想办法影响他人把事情做好。 施加影响的三个层次： （1）让人知道要做（awareness）：学会授权，交代告知工作，知道要做。 （2）有动力做（desire）：讲清楚为什么要做，为什么要现在做，获取理解及认同，激发团队的动力。 （3）有能力做（ability）：核心能力。（短期看，短期借调、内部转岗）（长期看，作为项目管理人员，要有意识地发现和投资团队中有潜力的人，培训帮助其发展） 2、赶鸭子上架，做监工。 项目经理，不是每天逐个人逐条事项的监督，而是明确目标， 建立机制，并让这个机制运转起来，最终在项目组形成一种良性的秩序。 项目管理，最终是依靠流程和规则来约束大家的行为。当成熟的秩序在团队中形成之后，从日常琐事中解放出来的项目经理，就可以集中精力去做愿景驱动、激励团队等更高层面的工作，真正做到变“赶”为“引” 3、完善改革，从项目和团队当前的真实痛点出发，找到真正解决问题的方法和步骤。 首先，与项目中重要相关方加强沟通，理清前因后果。想想项目现阶段到底最需要什么，对项目管理方法的成功推进至关重要。 反思： 在你的项目组中，时间、成本、质量、范围这几个因素，到底哪个更重要？哪些是允许有一定调整空间的？ 各个角色目前的痛点在哪儿？哪些是最现需要解决的？这些问题背后潜在的原因是什么 ？ 团队对于这个痛点的改进是否有真是需要？需求的迫切程度如何 ？ 你的老板或项目发起人对于项目管理以及你本人的定位是怎样的？关于这些问题与可能的改进，你是否与沟通过并达成了一致？ 如果你打算引入新方法或工具，更适合用怎样的路径进行，是自上而下地全面推广，还是自下而上一步步优化呢？最有可能从哪个问题切入？ 第2讲 十大领域 整合管理：如何实现整体最优？ 1、干系人管理：如何管理干系人？（弄清楚哪些人是干系人；项目发起人对活动的预期效果是什么？比如增进团队的协作，提升凝聚力等；各方的期望和述求？各方的影响？活动过程中的各类决定，谁来拍板？干系人要以怎么样的方式参与？） 2、范围管理：做什么？（确保围绕着预期目标来设计相应的活动方案，然后进一步确定活动前、活动中、活动后分别要完成的具体工作） 3、进度管理：花多长时间？（规划好阶段性步骤，明确每个里程碑的目标成果和时间安排。） 如：第一阶，启动项目并确认概要方案设计；第二阶段，规划并落实人力和各项资源的投入；第三阶段，确定具体的活动流程和详细分工，完成活动前的各项准备工作；第四阶段，做好活动当天现场的统筹和运作。 4、成本管理：花多大代价？（预算？全局视角去思考，如何更有效地管理项目的各项投入，以达到更加匹配目标的预期效果）5、质量管理：达到什么要求？（确定成功的标准。现场参与人数、参与者满意度、管理者的满意度、对外传播效果？以终为始，引入必要的流程和方法，以保障活动效果的达成） 6、资源管理：有多少内部资源？（清楚内部哪些资源可以使用。如：宣传渠道、设计人员和经费支持、哪些人可以作为支持活动志愿者？提供活动哪些必需品？） 7、采购管理：有多少还要买？（有哪些工作需要外部人员支持？经费受限，是否可以通过交换资源的方式，来获取更多的外部支持？） 8、沟通管理：如何管理沟通？（活动策划团队、执行团队分别通过什么方式进行项目沟通？与发起人和赞助方的沟通方式和频率是怎样的？你如何保持团队内外项目信息的高效传递，使用什么方式来同步进展？） 9、风险管理：如何应对风险？（提前做好系统性的风险识别，分等级制定应对策略。（如：天气、场地、交通管制、赞助商经费紧张、物料供应延期、公司内外政策变化导致活动被喊停、业务压力大导致兼职志愿者流失）） 10、整合管理：如何实现整体最优？（统筹全局，整合并协调各个环节的利益冲突和工作安排，在不断变化的情境下，根据活动的目标“裁剪”初合适的过程、方法和工具，进行有效管理，从而达到全局的最优效果） 第3讲 五大过程组 PDCA循环，“戴明环”，规划（plan），执行（do），检查（check），行动（act） 1、启动过程组（千里之行，始于足下） 正式宣告一个新项目或新阶段的开始，公开确认项目章程，包括明晰各方干系人的期望和诉求，设定愿望目标和重要里程碑，确定责任分工和沟通机制等。 2、规划过程组（运筹帷幄，决胜千里） 把愿望目标转化为可落地的行动方案和工作路线。 3、执行过程组（言出必行，行之必果） 4、监控过程组（审时度势，沉着应变） 5、收尾过程组（慎终如始，则无败事） “趁热”复盘！ 互联网项目管理存在的现象：项目与项目间的边界相互交叠在一起，产品需求就如同海浪一样，一波未平一波又起，大浪中夹杂小浪。整个产品的生命周期中不会停息，看不到哪里是尽头，又哪来的启动和收尾？ “保目标、助决策、提效能、促协作” 围绕组织绩效目标，定位核心的3~5件要事，即关键战役，再把关键战役进行规划分解，拆到可交付可验收的里程碑，最后落地到版本/迭代的工作安排中。 通过清晰而系统的反馈机制和平台，把执行中的进展状态、变更、风险等集中呈现，以帮助管理者更好地进行优化和调整。 提效能就是要去关注和消灭团队中的低价值工作所引发的效能痛点。 促协作则是着眼于使用各种项目管理方法和工具，让高价值工作者可以更好地合作。（比如，建立清晰有效的信息渠道和沟通机制，积极推动各角色达成共识，实现全局价值的最大化） 保目标、促决策是要打通从战略到执行的闭环，提效能、促协作则是打通上下游协同 第4讲 识别项目中测四类干系人 1、“高利益-高权力”代表：项目发起人
2、“低利益-高权力”代表：职能经理
3、“高利益-低权力”代表：项目组成员
4、“低利益-低权力”代表：外围支持人员 深入了解干系人的核心述求（重点关注、预期等），约定好沟通频率、方式和内容，以便做好实时同步。 强烈的态度背后，一定反映了干系人对现状的某种认知。只有真正地理解了对方的逻辑，才有可能进一步对其施加影响。 主导、支持（明确了解其期望和述求，有意识地创造更多的空间和机会，让他们深度参与到这个项目的决策或创意环节，增强其主人翁意识）、中立、反对（建立信任，化解危机） 第5讲 规划：扫除计划中的“延期地雷” 做计划，是集体对焦的过程，是制定各个角色协同工作的基准。 雷区扫雷： 1、不够具体（任务的集合） 给出时间节点，给出依据和来源，更有效地对焦。创建WBS，把项目工作按阶段可交付成功分解成较小的、更易于管理的组成部分的过程。 2、不够全面（只有任务列表，没有识别关键资源和关键依赖，没有考虑研发之外其他环节） 识别依赖并画出关键路径，即从目标角度对资源进行统筹思考。 3、不够准确（定义理解不一致） 定义标准动作，定义完成标准。 常见时间节点标准： 需求/设计确认：执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。或有些团队会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。 功能完成/提测：所有定义的功能都已经完成（比如冒烟测试通过率高于90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当做BUG来追踪。一些质量基础比较好的团队，也可以吧CI自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准。 里程碑完成：质量已经达到适当水平（如不存在P0及P1优先级的bug），可以上线发布，或者可以开始下一个里程碑。 4、没有共识 没有达成共识的计划，是不具备任何效力的，因此要达成共识并公开透明。周知成员 5、不够即时 做计划，谨慎的过程，但也是反复修正，渐进明细的过程，我们要对计划进行持续地跟进与调整。更重要的是，每一次进行调整，都要确保项目中每个人知道当前的计划是什么，调整计划需要怎样决策过程，都需要谁参与决策。 解决思路：五个标准动作 具体：对工作进行WBS分解 全面：识别依赖并画出关键路径 准确：尽早定义完成标准 共识：召开全员规划会，对齐信息，达成共识；发邮件给干系人，正式告知。 即时：及时调整变更，并公开告知所有项目组成员 第6讲 执行：打造品质，要从头开始“闭环” 项目问题：需求和设计没有经过严格的把关，就匆忙投入开发；传统研发的串联的功能效果，只有等到上线才能看到和体验到完整运行的产品；产品的提出，需要多轮的螺旋式迭代，不断调整。 解决思路：构建系统能力，在产品研发整个过程中，建立起真正闭环反馈的产品验证机制。 开环和闭环之间的关键差异，在于有没有反馈环节，以及系统是否会根据反馈自动调节。 1、方案评审（OARP决策机制） 负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定； 批准者（Approver）：最终批准者； 审核者（Reviewer）：负责人和批准者挑选出的审核人。审核者有负责对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复； 参与者（Participant）：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题作出反馈。
2、Bug Bash （BUG 大扫除） Bug Bash ，最初来自微软，是指在项目开发里程碑的末期（比如Beta版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找Bug，目的是从各个维度衡量和体验产 品。 要点： （1）时间：测试类的Bug Bash ，可以选择在全面功能测试结束后，Bug趋于收敛的时间段开展；需求设计类的Bug Bash，一般会放在需求稿或设计稿完成后举行。1~2H,提前排除所有干扰。 （2）地点：设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围； （3）参与者：除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角； 3、冒烟用例评审 如果你是在完全没有基础的团队中推行这个做法，可以先从测试人员记录冒烟测试通过率开始。接着，你要收集相关数据，和你的团队在回顾会上一起看看冒烟用例失败所导致的后期返工成本，讨论出一种更好的确保质量的做法。在我直接管理的项目中，冒烟通过率的要求通常是 100%，你可以选择从一个合适的起点开始，比如 80%，然后再一步步地逼近更好的提测质量。 第7讲 监控：进展“巧”汇报，学会用数据说话 1、紧急汇报：直面问题有章法 紧急报告，是指在项目发生突发事件，或者提示重要风险状态变化时的实时报告。 紧急报告模板： （1）事件描述：购物车改造功能高延期风险； 2、常规汇报：项目周报回答的三个问题 项目周报是向项目团队和干系人沟通项目状态的常用手段，要用简要的方式呈现项目全貌，客观地展示项目问题，推进问题解决。项目周报模版中，最必不可少的就是整体项目状态评估、风险列表、项目概况及计划变更情况。好的周报，应该让大家对项目现状的三个问题形成统一、清晰的整体认知。这份整体认知，可以让平时扎在细节工作中的人，从全局视角来了解和看待整体，从而更好地完成自己的工作。 结合项目组中当前需要重点推进或改进的事项，选择合适的数据和图表去做“透明”。 如：jira中的图表插件 第8讲 收尾：项目复盘，小团队也要持续改进 项目团队有意识地向过去的行为经验学习。 决定复盘成功与否的关键，不在会议本身，而在于复盘会的一前一后两个环节。认真做好一次复盘，每次复盘后聚焦一个改进点。 要点： 1、复盘会的基调设定： 反思，为找到问题的根源并改进而复盘 2、复盘会的会前准备： 梳理整个版本的历程，包括项目或里程碑各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等，这些客观数据的总结。同时，还可以提前收集这个版本期间，团队满意度的问卷调查，为复盘会引入更多主观的输入。或视频 3、复盘会的简易流程： （1）现场回顾总结项目 / 里程碑的整体概况，包括目标达成情况、进度计划及变更情况、需求变更情况、质量报告等项目历程记录。 （2) 与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点，按照项目的各个环节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达。 （3）在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论。 （4）对大家总结出的好和不好的点，进行集体投票。 （5）由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案。 无法促发行动的复盘，说得再好都是空谈！一开始开复盘会，大家会期待，解决的问题越多越好，但焦点增多之后，哪个都是蜻蜓点水地过一遍，哪个都没改彻底。下次再开会的时候，大家发现之前反馈的问题依然还在，那谁还有动力继续提问题呢？ 所以，改进措施一定要落地，重点行动不要太多，一个就够了！如果每次复盘聚焦于改进项中的 Top 1，确保改进措施真正落地，长期坚持下去，就会促进持续的能力提升。同时，复盘的次数也不要太多，你并不需要每个版本、每个迭代都例行公事地去做一遍，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的。 4、打造团队持续改进动力： 不仅关注事，更关注人，更好地激发团队的主人翁意识，让团队成为复盘的主角，从而让团队进入自发改进的正向循环。（例：“批奏折”） 越是困难时期，越是塑造团队能力的大好机会。 第9讲 需求变更：化解程序员的“头号噩梦” 项目问题：“996”的元凶，之需求变更频繁 解决思路： 1、达成最小共识，变更时有代价的。（我们追求的是达成项目目标，而不是零变更） 约法三章： （1）所有需求及所有变更必须建单，无单需求开发有权不接； （2）需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员； （3）对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道。 2、源头治理，一次把事情做对（上墙文化。产品和设计的Deadline排期图、产品模块设计图、页面逻辑跳转图等搬上墙） 从变更的源头开始治理，从源头开始公开透明，一次把事情做对，最有效率的方式。 3、快试错，不可抗力巧应对 关于来自老板或客户的需求变更，不要直接顶回去，要快试错，要去剖析、把握和满足老板或客户的真正述求，巧妙应对。 如果你把需求变更当做洪水猛兽，各种严防死守，最后，只会身心俱疲。如果换一个视角，从失败中汲取教训，变堵为疏， 需求变更就不再是敌人，最终，需求变更时产品不断走向完美的底层动力。 第10讲 风险管理：如何系统化应对风险？ 项目问题：不确定的事件或条件，对项目目标造成影响 解决思路：系统化识别风险，根据风险概率和影响，召集项目成员完成风险登记册及风险具体评估，制定相应的风险应对措施及应急预案，同时对冰山下的风险保持敏感。 系统风险的识别：（识别出的风险越多，项目的风险越低） 风险识别的主体，应该包含 项目中的团队成员在内的各方干系人。组织中的每个层级，都必须有意识地积极识别，并有效管理风险。系统化的风险识别，是一个反复进行的过程，应该从构思阶段开始，贯穿项目规划和执行的始终。 识别风险的主要输出，即初始的风险登记册。包括已识别的风险清单，以及潜在应对措施清单。对于已识别的每个风险，都要评估其概率和影响，并进行优先排序。 冰山下的风险： 规避风险的原因：缺乏风险的沟通渠道；提出来也没有用；老板会认为自己没能力管好当前的项目 没人反馈风险，不代表没有风险。一个优秀的项目经理，必须是一个优秀的“情报人员”，上至最高的项目发起人及组织得各层决策者。下至项目最边缘的人群，比如外包、实习生、短期借调支持人员等，都要跟他们建立广泛且深入的联系。用一颗真诚交流的心，去关注项目组中的每个角色、每个成员的需求。理解他们的困难，愿意为他们提供发展的机会 ，帮助他们去获得更大的成功，仅此而已。 风险应对措施：对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案。 在项目排期时，确保有相应的故障演练计划，并且做好充分的准备。 通过周期性的风险审查，识别新的风险。 确定正确的风险观： （1）治未病，建立系统性保健机制。（事后不如事中控制，事中不如事前控制；致力于持续改善人与人之间的互动品质，提升项目团队的健康度；匿名的问卷收集或访谈，定期做一场坦诚布公的复盘会） （2）积极管理致命风险。（挖掘出致命风险，把他们变成可见的，可谈的；正视风险，不存侥幸心理；在项目的核心团队中，周期性地梳理和同步风险状态） 坚持在多个版本中反复使用，积累数据。 在互联网领域，成功突围者大多都是一路坎坷，从各种致命风险中爬出来的，堪称九死一生。致命风险的存在，本身就是一种警醒。加速构建核心能力，不断拓宽“护城河”，此案时最根本的应对之道。 第11讲 质量管理：一次把事情做对！ 项目问题：产品完成质量不好；bug多；技术债爆仓 解决思路：三方面入手。 1、质量规划，明确项目的质量标准； 2、质量分析，追根溯源，找到质量差距的根本症结； 3、质量控制，在需求到发布的过程中，设置层层卡点来控制质量。 关于技术债，定期积极主动还债。 关键要点： 质量成本：事前防止失败的一致性成本；事后处理失败的非一致性成本。事后检查处理的代价是最高的；预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多。 质量规划，明确标准。规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程。注意，在业务生命周期的不同阶段，质量标准应该是动态变化的。不同的项目对质量的要求也相差甚远，无法一概而论，因此，只能结合具体项目和项目阶段的质量诉求，对质量的标准进行合理定义。聚焦项目的整体目标上，质量作为目标的一部分，达到要求是最重要的，不需要追求质量的无止境提升。质量终究也是有代价的，是否够用取决于项目目标和要求。 质量分析，追根溯源。深入分析，定位问题，进而采取相应的措施进行改进和预防。 常用方法： 1、每月坚持开线上Bug分析会。召集产品、研发、测试，一期对过去一个月的线上问题，进行深入的根因分析，制定策略并推进落实。 2、持续进行内部Bug分类。从不同维度分析Bug原因，可按照具体引入阶段给Bug分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发的覆盖升级、历史遗留等，也可按照Bug类别分为功能问题、性能问题、界面问题、兼容性问题等。从数据统计上，就可以准确的知道，自己项目的质量问题主要出在哪个环节，下一步要先规范代码准入标准，还是加强需求评审， 以及哪些保障措施会更有效。 3、建立质量大盘，拉通不同业务线或模块的每月Bug趋势，对齐千行代码Bug率、Bug数/需求数的比率、Reopen Bug率等，对低于平均线下的业务线或模块进行有针对性的原因分析。 质量控制，层层卡点。 质量控制及卡点行为，要结合项目质量要求和团队的质量成熟度，一层一层地加强质量把关和收口。 第12讲 高效会议：项目中要开好哪些会？ 项目问题：会多（项目经理80%的时间都用在了沟通上，不是在开会，就是在开会的路上）；按框架开了所有的会，终觉流于形式，索然无味 解决思路：流水不腐户枢不蠹，没有什么东西是一成不变的，会议设计和流程需要根据项目各阶段的情况做相应的调整。想清楚要开哪些会，不开哪些会，怎么把会开好。即：“断舍离，坚持只开最有必要的会，开真正高效且产生决议的会（会而有议、议而有决，决而有行），做到借助会议做好群体沟通，从而让大家看到有效的进展。” 关键要点：（保障会议品质） 1、明确会议边界。（①明确会议主题、目的和参会人员范围。②why what how ③两确保：确保各部分的进展信息在会前统一提交，会议当场只说重要问题、风险及 需要支持的地方；确保会议当场严格围绕主题开展，对偏离主题的讨论，及时叫停！相关问题的主要决策人，对这个问题有责任的相关人员、负责执行决议的人员是必须参与的） 2、建立会议规则。 （迟到红包→拖堂红包→轮流担任“规则守护大使”→主持人判定违反会议规则者，成为下次会议的主持人） 3、做好会后跟进。（会后所有跟进事项，直接进任务系统，确保跟进到底） 第13讲 故事案例（上）：新手上路，如何引入变化？ 项目问题：发现问题，如何解决问题？ 解决思路：选择合适的时机，然后，找到因地制宜的解决方案，最后因人而异，采用不同的策略进行有效沟通。“天时地利人和” 关键要点：引入变化的发心。之所以要引入变化，不是因为你觉得这个方法好，解决了你的问题，而是要看团队需要的是什么，干系人的痛点是什么。建立在信任的基础上，站在对方的角度设身处地地思考问题。 “天时”即合适的时机。问题并不等同于时机，只有把问题和痛点关联起来，才能形成一个好的时机。不能产生改进动力，只能说明，还没有抓准痛点。 痛点，即必须及时解决的问题，包含着强烈的迫切感。判断是否是痛点的标志，就是看这个问题，如果不解决，对方是否会很苦恼，很痛苦。 促发别人的行动，必须换位思考，去体会和抓住他的痛点。1、访谈法，直接问。2、观察法。去观察那些花他时间和精力最多，他反复强调却又没有很好 解决的问题，那些才是他真正的痛点。3、同理心和倾听。变革早起，寻找早起支持者，围绕着你想要引入的变化，击中几个重要干系人的痛点之后，时机到了。 引入变化的第二点“地利”，学会因地制宜。结合每个项目团队的现状，做好本地化的场景适配。创造一个最小阻力的落地方法，先快速地跑起来， 让团队感受到变化带来的闭环成效。 “人和”。多聆听彼此，充分理解，找到共同的出发点。在沟通时，你要因人而异，针对不同的人，采用不同的策略。判断立场！把变化涉及到的干系人，按照角色和层级做个初始化分，思考下不同区域的人，会怎么看待这个变化带给他的影响。找出更多积极因素。 在大范围公布并引入变化之前，与关键角色进行一对一的沟通，最后，面向全员正式公开沟通。 例子：沟通延迟推行的每日站会变革。 第14讲 故事案例（下）：小步快跑，小而美的敏捷 敏捷问题：简单但并不好做（simple but not easy），掌握精髓？ 敏捷的特点：小而美，体现在人、事、时间三个方面。1、人：拆分成小规模（5~7人）、跨职能的小团队；2、事：拆分成一系列小而具体的交付物，按优先级排序，增量交付；3、时间：拆分成固定大小的短迭代（1~4周），在每个迭代结束后，对可工作的产出进行演示。总体来说，就是用小团队在小块时间，做做出小块的东西来，并且周期性地集成组装。 常见痛点与解决思路： 1、发布时间不可控（快速地增量交付） 考虑实际背景，确定迭代周期；和相关方一块做Sprint计划及Review演示。 提早集成与测试，问题得以及时暴露，更快的反馈及应对；及时规避风险；快速响应变化，每个sprint都是潜在可交付的产品； 2、摆脱“接力综合征”（从对抗走向协作） 宁愿选择等待（每个人都等着上一环节的人把东西弄好送到自己面前来，才能开始工作）；角色间泾渭分明（每个人觉得，只要把自己分内的事做完就行了。从而导致个角色之间有一定的对抗性，任何一件小事就可能造成冲突，最终大家都耗在那里，却不能把焦点放在达成整体目标上） 虽然彼此分工，但作为一个team，有共同的sprint目标，相互协作，一起完成。“燃尽图型项目进度模板” 3、需求理解不一致（面对面澄清及估算） 敏捷价值观，“个体与交互>过程与工具”。 迭代计划会思路： （1）产品负责人向团队和用户代表，面对面地讲解收集来的各方需求，最终明确需求的优先级及验证条件，也就是说，在迭代结束的Demo演示会上，我们要给用户呈现什么。 （2）团队估算。采用敏捷估算扑克的形式，由团队成员共同估算结果，最后综合得出这个迭代要交付哪些内容。 团队估算的过程，一个双向互动的环节，可以帮助团队和产品负责人共同加深对条目的理解。同时，产品负责人也会根据大家的反馈，及时修改条目，完善条目。 好处：需求探索更深入；估算结果更全面、细致；找到更优的整体解决方案。 宗旨：围绕项目中切实的痛点开展。 敏捷实践的好处： 1、提升客户体验。 更低的延误率；阶段性可见的产出；更快的反馈、适应与调整 2、提升管理者体验。 团队自主运行，管理更轻松；变“赶”为“引”，为共同目标奋斗 3、提升团队体验 更高的生产力；更强的责任感、主人翁意识。 快速可靠交付，用户价值驱动，持续自发改进。 第15讲 工具方法回顾串讲：手把手带你高效管理 1、viso 甘特图 里程碑图 2、power 3、devops “四步学习法” 1、破除“魔”障 留心你的定义，对失败的定义，对困难的定义，对问题的定义，对理想环境的定义......这些定义决定了你的体验，以及你下一步的行动。别让你的 定义， 限制了你的可能性。破除“魔”障，向前进。 如果你认为，只有在一线城市的所谓一线大公司，在没有那么多复杂关系的“理想”环境里，才能开展工作，那么，你将永远无法真正地开始。即便你有一天到了大厂，你对问题的错误定义，也会让你不断地看到各式各样的问题，遭遇各种各样的困难。 2、每次一小步 3、先找找“感觉” 学习某些知识时，产生了共鸣，接下来，就要多看你几遍，多听 几遍，把那种事情已然成真的喜悦和满足感，刻录在心中。然后，试着和自己的经验相关联，在大脑中想象自己已经做到这些的样子，越清晰越好。最后，把这个视觉化的影像记录下来。 4、“足”量的刻意练习 通过行动，反复加深神经系统中的凹痕，直到新的行为，巩固成为新的模式。 学而时习之，不亦说乎。 第16讲 向上沟通：你必须要注意的三个误区 误区1：所有问题，都自己扛! 迈过自己内心的那道坎，主动大胆地发起沟通，是做好向上沟通的第一步。 不管通过什么途径，我们必须时刻从大局出发，让这些项目关键信息，及时有效地流动，保障及时有效地决策。 误区2：只知道吐槽，不知道争取 情景：当团队和管理层之间关系紧张时，很多项目经理会特别容易掉进一个误区，那就是，尽自己的努力帮团队解决问题，脏活累活都自己来。“老好人”，升至“夹心饼” 改变这种局面，就是把“夹心饼”变成“连接器”，成为高层干系人与团队之间紧密联系的纽带。 作为项目经理，当需要高层重视和支持的事件发生时，该出手时就得出手，引发高层关注，把团队最一手的相关动态信息及时传递给他，争取高层必要的支持，而不是跟着团队一起吐槽。 误区3：抓不住重点，给不出方案 “团队现在加班很严重”“团队任务不及时更新”“某某工作不主动，总是迟到”·······如果你只是这样反应问题，只是说这里不好，那里不好，却没有告诉他，为什么要关注这个问题的话，你的意见不仅不会得到重视，甚至还会产生反效果。 高层干系人的时间往往很宝贵，所以，在沟通之前，做好 充分的准备，是必不可少的。你要反应的问题，与高层干系人的核心关注点是否相匹配，这是能否引起其关注并进一步行动的关键所在。在向高层干系人提问题的同时，一定要给他一个明确的“点”，让他知道，为什么要关注这个问题。 适时地给出“行动点”，眼前的解决方案，针对提出的问题，列举可能的解决方案！给出前进一小步的解决方案，给领导，也给自己，一个小小的行动暗示。 找到“核心关注点”；用数据和事实来作“论点”；给出一个小小的“行动点” 第17讲 跨部门沟通：如何巧借力？怎么让不归你管的人积极配合你？ 情景:项目中出现的冲突，“部门 墙”，跨部门沟通，直线上升的复杂度。不是“自己人”的困境。冲突的起源，始于“边界” 应对措施：约法三章、先说清楚 1、建立君子协定 在合作前，跟对方建立合约，明确合作目标、合作事项、双方各自的需求和责任、时间进度要求、风险及责任人。双方责任人进行邮件确认，公开做出正式的承诺。 在刚开始合作时，建立稳定的预期是关键，双方责任及进度要求，必须要得到公开确认。 承诺越公开，越正式，日后对双方的约束效力就越大。 2、建立机制 合作建立后，建立常规的沟通机制来维持推动。比如：项目信息开放共享，每周在固定的时间开碰头会，双方相关人员交流工作进展及风险情况。更进一步的话，还可以借助标准得任务管理和文档管理工具，对项目任务和文档做到统一的流程化管理，在过程中确保及时地跟进检查。 确认是否存在“三不管”地带？每个依赖任务的职责是否明确，责任是否具体到个人？ 3、解决问题 通过周期检查，及时发现问题。 “找他们领导”，王炸牌？！不到特别时刻，不要随便拿出来用。在找领导之前，建议你自己先摸清楚状况，尽快启动风险应对机制，确定问题处理方案，比如改变方案，调整时间、增加资源、减少范围等。 另外，你要把问题和相应的决议结果抄送给双方的负责人，让双方清楚问题对整体项目的影响及调整方案。同时，你还要明确的是，今后要采取哪些预防错是你，以避免问题的再次发生。 情景：两边领导达成正式约定，但不是每个牵涉进去的协作方都会立马配合。 原因：这个部门的KPI早已定义好了，双方约定确定，但对之前的KPI并无影响，故新增的工作，要额外投入人去做。因此，他们非常担心，虽然增加了工作量，但产出却不受领导的重视，类似这种会影响合作落地的根本机制问题，就需要引入双方领导，来一起研究解决方案。 如，在双方绩效考核指标中，加入跨部门利益的指标，来强化这种目标和利益的捆绑，让双方真正把劲儿往一处使。 第18讲 向下沟通（上）：无权无势，他们不听你的怎么办？ 第19讲 向下沟通（下）：无权无势，他们不听你的怎么办？ 第20讲 进阶之路：项目经理预备战之PMP认证 |
|
|
