《网易一千零一夜》读书笔记

Notes 项目管理

创建时间:2020-09-09 12:35

字数:3.3k 阅读:

0. 为什么开始看这本书？
1. 项目管理Overview

0. 为什么开始看这本书？

接到了让人兴奋的项目，小振奋，然后突然意识到项目的复杂程度，需要涉及的方方面面可能已经超过了我能够处理的能力范畴，所以需要补课了…

看了很多知乎的答案啊，看着看着意识到当自己在努力寻找沉淀下来的经过思考的单领域的内容的时候，从知乎或者其他快节奏的平台找倒是真的有点舍本逐末哎。项目管理还是有很多核心理念是可以也已经沉淀下来的，所以就开始了找书看，对照着自己现在的境况，一点点解决的状态。

另外踩的一个小坑是太追求优质的工具，即疯狂比较各种管理记录的软件，比较omniplan vs xxx vs blablabla, 瞎倒腾了好一顿才意识到对于一个不懂项目管理的我来说，倒腾哪个都是白瞎。一定会按照完全不是软件本身设定的方式，来使用它，应该说是完全解决不了问题。

所以还是踏踏实实的带着敬畏感的从一本不太学术的书开始，从互联网公司 – 网易的产品经理的视角，来看看怎么做项目管理，怎么跟进项目的进程，如何应对各种过程中的设计变化，如何做各种取舍。

1. 项目管理Overview

1.1 High Level的建议

项目到底需要什么
- 接手一个项目之前，应当与项目的重要干系人加强沟通，理解前因后果
  - 对于技术项目，理解整个大致技术实现的思路，其中的痛点难点，潜在的不确定因素
    - 比如跨组的合作
- 而后，理解项目到底需要什么
  - 时间成本质量要素的权衡与取舍
    - 范围
    - 时间
    - 成本和质量
  - 各个角色目前的痛点
- 大家对项目管理的认知和接受度
  - 通过怎样的途径，是全面推进，还是步步改善？
  - 从哪一个角度切入？
  - 蓝图是否清晰？
  - 是否与项目负责人沟通到位并且达成一致？
不要凡事事必躬亲
- 替别人待办他们本该做的事情，对于团队来说反而效率最低
- 需要努力让别人能够做好这件事情
  - Awareness
    - 使得团队成员知道需要做什么
  - Desire
    - 需要给予某方面的动能
      - 技术挑战程度？
      - 项目完成以后的影响力？
      - 升职加薪？
  - Ability
    - 确保其有足够的能力来做好这件事情
      - 初期的辅助
      - 必要的培训等

不要追在别人屁股后面做监工
- 项目经历不是监督事情做得怎么样的人
- 他是应该和大家一起将整个事情环节捋顺的人，需要建议一套对应的流程规则，明确各个角色在过程中的职责
- 获得认同，使得这个机制自行运转起来
- 努力做到是规则在约束大家的行为，而不是靠人看着来做
言必信，行必果
- 无权力下的领导力 – leadership without authority
  - 在弱矩阵结构下项目经历必修课
- 需要构建起团队对你的信任，建立自己的可信度，打造个人品牌
- 信任的获取需要一点一滴的积累了
- 专业度上
  - 确定自己足够专业
  - 至少相对更专业
- 跟进
  - 会议，发布，邮件，承诺
处理争端
- 与人一起解决问题，会因为不同的对于事情的看法产生很多争论
- 需要找出一致的地方并且努力放大

1.2 关于时间估算

有没有必要进行时间估算以及进行到什么程度的时间估算？
- 现状
  - 用了很多时间，但是最终的实际使用时间往往和估算的有不小的偏差
- 房子从凌乱到整洁需要20%的努力，从整洁到一尘不染可能需要80%
  - 有估算实际上是完成了相对性价比比较高的一段
- 估算可以给一个相对合理的计划，使得用户，管理层和团队都有一个稳定的预期

估算单位
- 理想人日
  - 指成员在不受干扰的情况下，全部时间用来开发需求所需的天数
  - 劣势
    - 人的不同会导致整个估算的不同
    - 这样的差异会导致我们队任务规模认识的偏差，很难衡量项目的实际大小
- 理想人时
  - 对应理想人日而存在
  - 在充分理解需求的情况下，能帮助团队做到更靠近真实值的估算
- 故事点
  - 对任务规模的估计，是一种相对的概念
  - 优势
    - 基于故事点的估算不会因为开发人员的变更，时间的推移而改变
  - 劣势
    - 难以找到合适的估算单位
估算的方式
- 自下而上的估算
  - 每个开发人员估算自己的任务时间，然后将所有的任务汇总
  - 团队特征
    - 成员间业务独立性强
    - 相互之间业务熟悉度不高，熟悉成本高
    - 各成员相对经验比较丰富
  - 优势
    - 估算效率高
    - 准确度也会比较高
- 专家判断
  - 专家根据响应开发的情况给出任务的估算值
- 扑克估算
  - 流程
    - 每个估计者都会分到一叠扑克牌，每张上有一个数值
    - 由负责人对某个需求进行估算的需求或者任务进行讲解
    - 讲解后，所有人都可以向该负责人提问关于该条需求或者任务的问题，直至足够了解
    - 然后所有成员挑选一张扑克牌代表自己对该条目的估算
    - 如果差值比较大，就需要人员说明各自给出这个估值的理由，然后再进行下一轮的估算
    - 最后取平均值
  - 优势
    - 多成员一件，更客观
    - 估算过程中，强化了大家对于需求和任务的理解，将任务考虑得更加细致，降低了不确定性给计划带来的冲击
    - 使得相对严肃的计划和估算变得更加有趣，但是会花费更多的时间成本
    - 需求探索的会更加深入，估算也会更加全面细致
    - 让潜在的冲突公开化，台面化，让大家去充分碰撞，然后用一种近似游戏化的方式再去化解掉
估算的注意事项
- 估算仅仅是预测，当对外承诺项目完成时间的时候，最好提供一个日期范围，让听者知道你的估算只是预测
- 将任务分成更细的粒度是会有利于估算的
- 团队需要练习估算方式并且收集反馈，有迭代，有过去的数据，就可以做分析，来进行优化
- 估算需要进行反复进行，当项目进行一半，发现估算过于乐观的话，就需要对剩下的工作进行重新估算
估算与Scrum
- 在Scrum项目当中，我们会以迭代Sprint为周期来做增量交付
- 和传统的项目不一样的是在每个迭代计划当中我们不需要确定日期，只需要估算一个迭代我们能完成多少工作

1.3 进度计划

制定计划的重要性
- 计划的本质是团队对何时完成任务的承诺
- 排斥做计划的原因，在于人们不愿轻易做出承诺。人们都会有一种言行一致的愿望，一旦做出承诺，来自内心和外部的压力会迫使我们按照承诺去做。
制定计划的时间点
- 应该尽量早的制定出计划
  - 因为在混沌不清的时候，需要某种方式来做锚定，相当于挖个坑，根据少量的信息给出期望值，然后让人们一点点来填满它
  - 当有了坑以后，就让大家一起来填
调整计划的注意事项
- 计划是调整的基础和依据，但是调整计划需要注意：
  - 确保项目的每一个人都知道当前的计划是什么
  - 调整计划需要怎样的决策过程
  - 需要谁参与决策
如何做好计划
- 项目立项前
  - 将目标按照功能体系分割成几个重大的里程碑
  - 这个时候注意要给出立项的时间表 – 能够使得各个资源方有明确的预期，以便提前做好资源的调配
    - 什么时候完成初期调研和评估
    - 何时做好立项准备
    - 何时启动项目
- 项目立项后
  - 根据启动过程当中对于里程碑的大致预期，进一步推导出
    - 需求确认
    - 设计确认
    - 功能完成
- 需求确认后
  - 由设计，开发，测试一起做WBS，将工作细化分解
    - 注意的几个节点
      - 设计确认
      - 功能完成
      - no bug
      - 发布前的代码冻结
- 完成标准
  - 需求设计确认
    - 团队要准备好怎么编写，在哪里编写代码
  - 功能完成
    - 所有定义的功能都已经完成，已经通过测试，允许质量差距和少量的Bug存在
  - 里程碑完成
    - 质量已达到适当水平，可以上线发布，或者开始下一个里程碑
- Tips
  - 计划本质上是一种承诺，因此应该让团队共同参与制定出来
  - 想让承诺有效，必须要是当事人积极公开且经过一番努力后自由选择得来的

1.4 每日站会

定位在沟通交流
- 不是汇报会
- 是用来分享信息，做出承诺以及提出路障的，解决的是团队协同的问题
- 需要让人参与进来
  - 红黄绿三牌的方式
    - 黄牌 – 进行相关提问，向发言者了解协同和依赖的信息
    - 红牌 – 用来打断谈话，避免过度的讨论和无结果的时间浪费，提高站会效率
    - 绿牌 – 代表每个人的发言权，将牌归还给主持人则意味着站会结束

1.5 周会周报

周会的目的
- 不仅仅是同步状态，汇总团队信息，这些是邮件，文件共享就可以实现的
- 目的在于
  - 面对面感受项目当前的整体状态，重要问题，接下去的目标，以及所需的调整
  - 借此对项目当前重要的问题有一致的认识，进行小幅度的讨论，并形成下一步的工作事项
Tips
- 控制规模和时间
  - 最多10 - 15
  - 1.5h maximum
- 要不要轮流汇报？
  - 大部分项目整体情况可以通过项目经历事先收集来直接做整体概述
  - 对于部分方向性或者商务性的小组，可以简单汇报主要工作和主要问题
- 什么适合在周会中讨论？
  - 急事不适合
  - 非跨团队的问题不适合周会讨论
  - 纯执行细节问题不适合周会讨论
  - 大方向决策问题不适合
  - 可以讨论跨团队的涉及整体性计划的问题
  - 中期改进型问题
- 说话比例
  - 三分
    - 会议主持人，更新整体状态，主持讨论
    - 需要回报的与会者的发言
    - 所有与会者的讨论
全体类周会
组长类周会
三方类 – 产品，运营，市场三方周会

1.6 工作汇报

工作汇报的目的
- 将状态，问题，风险知会相关干系人
- 寻求帮助
  - 需要在遇到问题的初期就积极主动寻求帮助，进而迅速的去解决
- 自我审视
  - 周报是一种自我审视的过程，看看自己制定的目标和项目的完成情况
个人周报
- 内容
  - 本周工作完成程度
    - 做了什么
    - 完成结果如何
  - 下周工作计划
    - 需要做什么
    - 时间点
    - 完成的定义
  - 工作中遇到的问题和建议
  - 个人感言和建议
    - 工作中的总结和分享，让上司知道你在想什么

团队工作周报
- 团队周报更多聚焦在结果和计划上，而非个人微观层面的事件总结
- 计划的时间跨度根据团队规模大小不同可以从1个月到3个月不等
- 内容
  - 上周达成的结果
    - 量化的结果指标
      - 销售额
      - 用户数等
  - 未来一段时间的规划
    - 通过图形化的方式言简意赅地列出任务的时间点和期望达到的结果
  - 达成如上规划图的风险/ 需要的协助
    - 资源风险
    - 合作方风险
    - 建议的应对方案

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 stone2paul@gmail.com