PM,读《IT项目经理成长手册》

研发管理 1年前 (2020) 隐墨
256 0
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/kyle_1111/article/details/104357523

此书是工作后入手的第一本专业书,惭愧两年后才拿出阅读。不过项目管理类书籍,有了实践经验后阅读,体会更深刻。若无相关经历,会像读理论书般,既无趣,也难有感悟。这是项目管理的独特性造成的,凡涉及“管理”二字,往往需要的更多是软技能、综合素质。项目经理的实际工作,80%花在沟通上,一点也不夸张。硬技能,office套件足矣。项目经理看重的,跟进度、管理期望、带团队、定计划、监工、专题会、汇报,所需能力很难通过课本及理论习得。导致相关书籍,要么陷入操作细节,要么严重理论化。未入行的读者,读后很难有较大收获。对于读后的期望,不是“哦,原来项目管理是这样子的,转行后应该这么做”,而是“哦,这块我做时也是这样/相反的感觉。”

序言的作者经历介绍,与书中小M的升级之路类似。如打怪升级,技术员-项目经理助理-项目经理-项目总监-事业线主管,职场的道路,是在翻一座座逐渐高耸的山峰,需要的是无尽的好奇心与持续稳定的学习力。再重复一遍经常念叨的一句话,“系统学过、系统做过、系统总结过”。相信作者也是持续实现这三点,才能输出此书。难得的是项目管理相关任务,都做过,并系统地总结出来,既提供了流程/模板/方案,也分享了感悟/经验教训。

另一个亮点,在于每一章节,没有直接将怎么做。而是从背景出发,先分析为什么要做这个事。然后,是确定怎么来思考这个问题。而不是直接就动手干了。例如计划,先制定计划的计划,考虑项目组应如何制定计划。发现这也是牛人的普遍特点,接到任务,先考虑怎么看待、怎么思考问题,再专注到问题上。

回到项目经理岗位,没在乙方呆过,但有着充分接触。只能说,相比甲方,乙方就是海贼王中的新世界,把人丢到逆境中,借由近乎残酷的磨炼得以快速成长。不过甲方也有好处,对于组织设置、部门管理、业务如何与IT配合、IT流程、项目立项、业务等,可获得独特提升。不过甲方不能待久,尤其职业生涯前期,容易把人待倦了,提前养老。此外,要适应大趋势,产品经理,是个更promising的职业。告别传统IT,互联网产品经理,抓紧跳槽。就是赶上黑天鹅,今天还能是金三银四吗?还是等上三个月,经济回温产生补偿式的大量需求。

概述

1. 复杂问题,先考虑“怎么思考”,再思考要思考的问题

2. 计划制定后,从实操、细节层面完整过一遍,考虑可行性

3.倾听时想的是“对方的想法是什么”,而不是想着怎么给对方一个回答

  1. 项目一开始就始终奔着结果去,直到结果达成,没人赶你走就坚决不离开项目
  2. 项目中的质量管理人员应该做什么,什么时候、标准下有权利喊停,必须明确。否则无制度保障,质量管理就会不断让路,质量管理成为摆设。
  3. 是“人”在确定项目目标,推动项目进程,使项目成果创造价值
  4. 谈判不仅是信息的交流,还涉及利益的交换。

入门

  1. 因为项目的独特性,不是普通商品交易,交付成果买卖前看不到,对于最终要提供什么没法定义清楚,或达成一致,因此交付产品或服务易发生纠纷。因此为解决此问题,强调项目开始前的合同签订,明确描述最终产品是什么。往往签合同的同时已经决定了项目成败。(独特性的实战意义)
  2. 临时性决定了时间约束的重要性,往往是决定性因素。团队成员,接受任务的同时,必须明白“什么时候需要完成”;临时性造成了团队动态性强,如何快速组建有效的团队。(临时性的实战意义)
  3. 为减少不确定性,在能够满足要求的前提下,尽量采用成熟的技术和方法。因为旧方法的缺陷是清楚的,可以有意识避开,而新方法的缺陷难以预估
    1. 项目目标虽然明确,但事前对于达到目标的路径不清楚,对于项目完成后的确切状态不完全确定
    2. 干系人涉及多个组织单元和个人
    3. 团队面临的任务可能是全新的,许多考虑不周的地方
    4. 计划和预算是基于对未来的假设,执行过程中与实际存在偏差
    5. 执行过程中突发的风险与意外
    6. 周期长,需求、功能甚至目标可能变化
    7. 开发人员的个体能动性、情绪
    8. 里程碑
  4. 时间点、标志性事件、交付物、关闭条件
    1. 达到里程碑后,评估项目,按计划进行,或走变更和调整
    2. 交付物经正式评审,进入受控状态成为项目基线。基线是一些重要里程碑上的交付物

前期

  1. 产品范围,用需求衡量完成度;项目范围,用计划。
  2. 功能清单
    1. 子系统,独立、完整的一组业务功能
    2. 功能集,子系统内按照业务特性归集的一组操作
    3. 执行单元,一次完成的一个独立业务操作
  3. 启动会后立刻进行培训,统一工作方法,并形成统一规范
    1. 项目管理概述、计划(统一项目管理过程)
    2. 项目开发过程、需求分析方法(流程、模板、样例)
    3. 产品知识培训(业务和技术能力)
    4. 管理工具培训(项目专用工具)
  4. 甲乙双方对于项目生命周期定义不同,乙方的项目起点,已是客户的执行阶段。因此乙方没有参加客户的论证阶段,可能忽视客户,为什么要做这个项目,解决什么问题,上线运行后能带来什么价值?
  5. 按期交付只是项目的最低要求,交付成果要解决客户的问题,给客户带来价值
  6. 项目打破组织的宁静,推动抵触项目的组织,为项目做事
  7. 涉及干系人,遇到困难,识别项目的得益者与失利者。由此可以找到关键点,利用非组织关系,设法得到高层支持。往往就是一句话的事

落地

  1. 工作范围是实现目标的途径,是为目标服务。因此客户的潜在需求,增加工作范围,但大大减少了实施的工作量;确定工作范围的关键,是识别潜在需求
  2. 范围的分歧
    1. 前期没说清楚。商务阶段,销售关注签约,遇到模糊问题避而不谈;甲方有最终验收的主动权,有回旋余地,也无意愿主动提起。
    2. 没想清楚。因为项目的目的,不仅是业务流程电子化,而是业务流程再造或业务创新,很难想清楚,需在过程中逐步明确
    3. 没法控制。长周期,商业环境、政策法规变化,组织结构、人事变动,产生直接影响。
  3. 工作范围说明书
    1. 没有说清楚的,现在就澄清,或记录下来
    2. 没有想清楚的,设定假设条件,目前构想是什么,将来可能变化,或明确有地方需进一步讨论
    3. 无法控制的外部政策变化,在制约条件中列举
    4. 依赖的、无法控制的外部条件,在假设条件中列举
    5. 不但确认范围,确认双方的分工与职责
    6. 不但确认最终交付物,确认中间过程文件。即使不向客户提交,是工作完成的证据,计算完工百分比
  4. 越是无形的交付,越需要有形的文档证明
  5. 需求分析之前,组织客户的产品培训,逐个功能比较客户需求与产品的差异;整理需求报告并完成评审。
  6. 活动分解,第一层次划分
    1. 责任人不同
    2. 交付物不同
    3. 活动周期大于检查周期
  7. 资源配置,参照标准当量。落实到具体人时,再考虑个体的当量系数。
  8. 项目预算,按照科目和时间两个维度展开
  9. 计划与个人工作脱钩
    1. 没有细分项目计划,以班组为单位,公示板布置小组成员每日任务,管理底层计划,根据执行情况随时调整
    2. 返工和复返,导致个人工作集合无法赶上整体计划,因此也就不看计划,抓什么就做什么。好的工作成果,作为样例参考;提交客户前,检查表自检,质量经理统一审核,拒绝边干边改的状态
  10. 周例会先确定真实状态,再讨论如何调整工作或计划;问题、对策、需要的帮助
  11. 计划本身没有用途,不断进行地计划才有用
  12. 只有提前建立了工作结果的验收标准,才能确定如何是完成任务
  13. 变更失控
    1. 私下沟通,总体失控。程序员不做记录,小量积累,需求、设计和代码无法保持一致
    2. 业务未达成一致,反复修改。
    3. 违规操作。直接在测试环境修改,无版本控制
    4. 没说明变更的影响。变更都是有代价的,未让客户清楚代价
  14. 变更控制
    1. 授权;杜绝私下交易,屏蔽客户内部的矛盾
    2. 审核;变更的必要性及优先级,特别是不需要立刻修改,可以后续逐步优化
    3. 评估;变更的代价,对各方面的影响
    4. 确认;评估结果必须要让客户知道,确认是否接受相应的代价,在确认过程中有了与客户协商的机会,这样可以知道项目组的苦劳,吃的是明亏
  15. 变得的目的不是让变更更困难,而是让变更更有序。

沟通

  1. IT项目目标不仅在于提供系统,更在于提供的一系列服务。影响客户满意度的不仅在于最终交付物的质量,包括过程中客户对人的体验,对过程满意。
  2. 客户的需求背后隐藏着真正的需要,这才是客户成功的标准
  3. 利益大于立场。将利益相悖,变成利益相同的谈判,与客户绑在一起,共同利益超越双方立场的差异。
  4. 做出让步时,也要达成妥协的平衡,即是双赢。
  5. 软技能涉及的问题,往往解决之前感觉非常难,但解决后又觉得十分简单。实质是改变思考问题的立场与角度,进而不同的解决问题的立场与方法

质量

  1. 质量在过程中产生,在结果中体现
  2. 质量保证
    1. 评审。中间产品检查,早期发现缺陷减少修改和返工
    2. 审计。工作过程检查
  3. 质量控制
    1. 测试。单元、系统、集成、性能
    2. 缺陷跟踪。确保所有问题都有结论,但并非一定解决。
    3. 变更控制。
    4. 配置管理。记录中间和最终配置项变化的历史,确保正确性和一致性
  4. 评审会,关键挑选评审专家。无利益关系的有经验同行,与有直接利益关系人进行制衡,牵涉到责任传递。
  5. 质量的问题往往是基本规律的事,大家都知道,但心存侥幸。因为成本和进度显而易见,但质量问题相比无法直观看出。
  6. 按规范测试短期看是在拖延进度,长期看是降低成本。开发需要的人力时间不能缩减,否则系统少功能。而测试的作用看不出来,因此后期的进度问题,往往压缩的是测试时间。而保证质量最有效的方法,是测试。每道测试尽量多拦截缺陷,才能保证质量,否则缺陷就是在uat阶段面向客户时,集中爆发。

团队建设

  1. 充分授权也要必要的检查。没有检查,完美的计划也会偏差。事前明确,交付物是什么,标准是什么,同时确保说到位了,做事人理解正确。
  2. 平易近人,想掩盖你是管理员的身份反而会失去成员的信任。记住是公司委派,再小也代表公司利益
  3. 团队的问题
    1. 组织结构设置,人为造成的矛盾。没有统一人,对纵向功能负责,沟通成本高
    2. 各小组的目标矢量和,不是总体项目目标
    3. 工作重点不突出,战线拉长。派人支援不必现在进行的工作。导致很多任务分派时,大家知道无法按时完成,反而失去完成目标的动力。大家都知道无法达成的目标,就不会认为是目标了。着急不重要的任务,由项目组解释,顶住压力。
    4. 项目任务存在相关性,工作负载不均衡,缺乏横向的平衡和调度。任务紧急,自然抓好用的人干活,导致忙的越忙,闲的越闲。结果好用的人变得不好用了。
    5. 过于强调领导力,缺乏必要纪律,奖惩不明。
  4. 各小组挑选核心骨干,资源不足时横向补位。但不能让雷锋吃亏,及时激励。
  5. 团队建设不在于管理方法的先进性,而在于准确定位问题,相适应的对策。具体正确的目标+白板就足够了。
  6. 个性成员的问题,从反馈的公正性和被接收程度出发,通过团队会议方式解决。避免项目经理直接找个性成员引起新的矛盾。

项目总监

  1. 关键是找对切入点,前提是能分析现状和问题,进而才能发现改进的机会。
  2. 两头说清,中间透明。立项时说清目标,结项时说清是否做到。中间在里程碑进行检查,每周通过周报跟踪项目的进展、问题和风险。
  3. 项目生命周期的6个事件
    1. 售前立项
    2. 签订合同
    3. 售中立项。内部批准预算、进度计划,可以获取资源执行项目
    4. 组织监控。组织级监控,纠正措施
    5. 验收开始
    6. 关闭项目。系统中关闭项目号
  4. 三分钟说不清项目进展,说明管理没有到点上
    1. 自顶向下,滚动更新三层制定计划,逐渐细化计划
    2. 白板记录及更新底层计划,动态跟踪到每个人的任务完成情况,自下向上逐层汇总,进而确定整体状况
  5. 售前谈是亲兄弟明算帐,以后谈就是撕破脸

项目群质量管理

  1. 组织级配置管理。产品研发项目之间、研发项目与客户化项目之间,版本发布规范不一致,开发进度不同,导致不清楚接口标准变化或最新版本,两个系统因接口报错,或版本错误已修改问题重复出现
  2. 配置管理系统,从面向文件到面向任务。关联文件构建新版本我,修改了哪些文件,修改后版本号
  3. 系统投资一次性,组织能力可以沉淀和固化。管理能力固化到系统中,变成组织能力并不断优化;而增加人员持续成本,管理成本上升,人员变化带走能力
  4. 确定一个角色,职责、范围、方法
  5. 推拉结合点,捂的压力,亮的动力

组织资产管理

  1. 企业文化、软技能、危机应对恰恰是在管理流程背后最重要的部分,决定了流程和方法的实际效果。
  2. 假设你有一颗银弹,可以解决任何问题,你会解决什么问题。通过银弹讨论,聚焦扫描目前交付中最突出的问题是什么。
  3. 搭班子、定战略、带队伍
  4. “开发中心比他们现在管的部门大近10倍,理论上只要找到10个跟他们一样的人问题就解决了。”
PM,读《IT项目经理成长手册》
版权声明:隐墨 发表于 2020-02-18 23:19:00。
转载请注明:PM,读《IT项目经理成长手册》 | 电子导航

暂无评论

暂无评论...