目录

项目过程管理流程：

产品项目管理基本流程

整合管理

  • 制定项目章程

    项目章程是证明项目存在的正式书面说明和证明文件。

    项目章程是一份简短的文档，以简洁明了的方式说明了项目。章程通常在设计时就考虑了高层管理，章程应包含项目的范围，目标和参与者，这样任何人都可以在短时间内了解项目概念。

    项目章程还应划定许多角色和职责，必要时包括利益相关者，同时概述项目中的一些目标和截止日期。

  • 制定项目管理计划

    项目管理计划，就是说明项目执行、监控、收尾方式的一份文件。内容包含：项目管理过程是什么样的，项目选择的生命周期，项目干系人有哪些，范围基准，绩效基准等等

  • 立项

    • 项目背景分析
    • 项目目的
    • 项目目标
    • 初步范围说明
    • 项目里程碑
    • 项目组织结构

  • 干系人

    对于项目来说，有权利的，有利益的人，分布在四象限里，权力大利益大的，权力大利益小的，权力小利益小的，权力小利益大的，这四类人分别对待，重点管理第一类人，让第二类人满意，让第三类人来监督，及时告知第四类人。

  • 指导与管理项目执行

    监督、指导、引导、管理项目执行

  • 监控项目过程、实施整体变更控制

  • 项目总结

范围管理

项目要做什么

范围管理流程图

  • 需求梳理

    深入了解需求，梳理需求，按模块功能归类，自顶向下逐步细分功能点

  • 定义范围

    明确项目的范围、合理性、目标，以及主要可交付的成果。

    范围边界，是应该做的工作和不应该做的工作的分界线，需要比较明确的阶段范围说明。

    可交付成果，要仔细定义，这是很重要的项目产出，服务、文档、数据等。

  • 创建WBS

    WBS组织并定义了整个项目的范围。WBS分解后方便任务分配、时间估算、成本估算、跟踪交付成果。

    WBS表涵盖编号、模块、详细内容、负责人、关联任务、时间、开始时间、完成时间等信息

    WBS没有所谓的正确的方式，可以使用草图、excel、项目管理工具project等，只要能满足，可灵活运用。

  • 范围变更

    对应文档、WBS相应调整

  • 控制范围

    项目成员应该将工作时间和资源放在范围边界之内的工作上，反之回报将非常少。所以项目团队要注意控制当下项目范围。

时间管理

项目什么时候完成

在给定的时间内完成项目是项目的重要约束性目标，能否按进度交付是衡量项目是否成功的重要标志。进度控制是项目控制的首要内容。

  • 定义活动

    在WBS分解后，得到项目的所有叶子任务，每个叶子任务都是可以由单人短时间内完成。

  • 排列活动顺序

    一般来说，每项活动的执行可能需要依赖于另外一些活动的完成，也就是活动与活动之间存在先后依赖关系，在有此依赖关系的基础上，我们需要确定各个活动之间的组织关系。

    • 前导图法。
    • 箭线图法。常用方法。箭尾是紧前活动事件，箭头是紧随活动事件。

    当然依赖关系，可以是客观的固有的强制性依赖关系，也可以是团队人为确定的依赖关系。

    依赖关系除了先后顺序依赖关系外，两个活动同时开始我们称为平行关系，两个活动有部分在一段时间内平行进行，我们称为搭接关系。

  • 估算活动工作量

    要估算活动历时，需要估算活动的工作量。我们觉得通过代码量来评估的算法，都是为了评估而评估。软件产品本身的复杂性、历史经验欠缺，估算工具缺失，甚至人为错误，很难适应现在开放的互联网，工作量的估算，在成本估算中会提到一些，大多还是结合团队经验和团队状况。

  • 估算活动持续时间

    估算所有活动的工作量后，以一个最小粒度的活动作为单位，估算活动持续时间，并作为活动单位时间，其他活动参考该单位时间估算活动持续时间。

  • 关键路径法

    关键路径算法的核心思想是将WBS分解的活动按逻辑关系加以整合，统筹计算出整个项目的工期和关键路径。

    从开始结点到结束结点的最长路径称为关键路径，关键路径上的活动关键活动。

  • 制定进度计划

    我们可以借用一些项目管理工具，比如excel、project、wiki等进度管理工具制定进度计划，并用于监控进度。我们常见的是进度列表数据与甘特图的结合，可视性更好，近些年也有很不错的线上管理工具提供更好的进度管理工具，国内的worktile等在这方面做的不错。

  • 定期监控进度

    每周固定时间检查进度，我们建议重点查看分析关键活动的进度偏差情况，如果发现进度严重落下，需要对进度进行调整，一般是先进度压缩。建议团队成员应该及时反馈进度不畅问题，不应该在严重落下等进度监督时才提出不畅问题，一来已经影响进度，而来会再影响其他关联活动计划。

    项目进度计划调整：

    • 进度压缩的方法：
      • 关键活动调整，如范围缩小
      • 增加资源数量
      • 提高资源利用率
      • 改变流程、技术算法
      • 加班赶工
      • 外包赶工
      • 非关键活动调整保证关键活动可进行
      • 增减活动

    加班赶工是常用的方法，不改变活动之间的顺序，可以分配更多的资源用于加班赶工，但通常为延期的项目增加人员往往进度会更慢。

质量管理

项目要做成什么样

  • 质量投资效益

    • 减少返工，降低成本
    • 提高生产力，提高效率
    • 增加利润
    • 提高品牌力

  • 规划质量

    • 过程质量

      软件工程的三要素：过程，方法，工具。过程是软件工程中很重要的因素。过程涉及软件开发流程环节、规范约束等。

    • 文档质量

    • 产品质量

      产品质量属性：参考系统架构质量属性

      涉及：性能、可靠性、可用性、安全性、可修改性、可维护性、功能性、可改变性、可测试性、互操作性。

      每个产品项目都有一个质量期望。比如网站的可靠性，3个9，4个9，日访问100万，支持1k并发等。

  • 设计用例

    在设计阶段，测试通过测试用例工具，根据需求设计测试用例。 测试用例管理工具：excel表、

  • 实施质量保证（执行测试用例）

  • 实施质量控制（测试迭代）

  • 现代质量管理观点

    • 质量是规划出来的。不是检查出来的。
    • 质量不仅仅说的是产品，包括产品整个过程。
    • 质量管理，人人有责。质量管理不仅仅是质量管理部门的事。
    • 如有质量问题，责任应该从上到下划分。基层质量管理人员不应该负主要责任，但会影响其绩效。
    • 范围、时间、成本影响质量。质量并不是单纯的质量，而是要符合、适用、多方满意，需要考虑时间、成本问题。
    • 改进质量要重视预防和评估。

成本管理

项目要花多少钱

  • 估算成本

    对项目投入的各种资源成本进行估算，估算也主要靠分解和类推进行。

    • 自顶向下估算法。

      参考过去已完成项目成本，推算当下项目总成本，并按比例分配到各个模块中去。强调项目的普遍性，由于项目的特殊性，该估算法往往不是很准确。

    • 自底向上估算法

      在任务分解后，将已经明确的子任务工作量加起来得到项目总工作量/成本。忽略了任务之间有联系，估算值往往偏低，需要灵活校调整。

    • 差别估算法

      将以上两种方法相结合，当然我们还要考虑项目具有发展性质，所以估算就是估算无法做到精确，也需要不断的跟进调整。

  • 成本预算

    成本预算是将成本估算分配到项目的各项具体工作上。以确定项目各项工作和活动成本定额。

    成本预算考虑一些因素：

    • 非直接成本。租金、保险、其他管理费用。
    • 隐没成本。项目之前已经发生过的成本。
    • 学习曲线。新技术的尝试与试验。
    • 时间要求。过短，项目风险高，项目压力大，过长，项目成本大
    • 质量要求。成本会影响质量要求。
    • 保留。为风险和未预料的情况而准备的保留成本。

    预算步骤：

    • WBS
    • 分摊项目总成本到WBS各个模块任务，为每个模块任务建立预算成本，在将所有模块任务的语段成本相加，不超过项目的总预算成本。
    • 将每个模块任务分配得到的成本再二次分配到下级模块任务活动上。
    • 确定各项目成本预算支出时间计划，以及每个时间点对应的累计预算成本，制定出项目成本预算与计划。

  • 控制成本

资源管理

项目需要谁来做

这个章节只谈研发过程中需要的人力资源。

风险管理

项目可能会出现什么问题，具体是什么问题，怎么监测并应对

风险两个部分：内部风险和外部风险，但最大最多的风险都是来自内部，来自上级的变更。

风险管理在于降低负面风险的概率，提高项目成功的可能性。

  • 风险库表

    将风险记录在档，方便跟踪。

    涉及内容：

    编号、风险描述、（风险类型、影响分类、识别人、识别日期）、（优先级、生存期、生存点、影响原因分析描述）、（应对策略、负责人、开始时间、结束时间）、（跟踪频率、风险状态、关闭日期、审核人、跟踪记录）

  • 风险识别

    • 如何定义风险

      风险点：架构设计中潜在的、存在问题的架构决策带来的隐患，从而影响系统的某种质量属性。

      非风险点：在一个范围内，可接受的影响某种质量属性。

      敏感点：为了实现某种特定的质量属性，一个或多个组件所具有的特性。

      权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。

    • 如何识别风险

      不谈书上那些理论的了，网上查下很多。看一些当下国内常用的方法，项目是项目团队启动的整理设计的实现的，自己难发现自己存在的风险：

      • 参考识别。以前的类似项目经验总结。
      • 内部会议识别。项目相关人员的头脑风暴会议。
      • 实名自下而上。项目相关的周报，月报，项目例会等。
      • 匿名收集。匿名意见建议收集。
      • 财务审计。
      • 专家审计。
      • 项目流程图。能比较完整的画出流程图的，做到闭环的，基本都有依据，除非不负责任。

    • 风险来源

      • 技术风险：范围、需求、设计、实现、性能、安全
      • 管理风险：估算、规划、沟通、监控、制度
      • 内部资源风险：人力资源、开发环境、项目依赖
      • 外部环境风险：客户、服务商、市场、自然风险…

  • 风险评估

  • 风险应对

    识别风险，进一步分析风险，给出应对风险策略规范。

    有风险，一定要上报。

    规避负面风险影响，转移第三方，或减轻影响。

    风险也有积极的影响，提高影响。

  • 风险监测

    定期监测风险，人工手动，可以借助脚本工具等。

沟通管理

项目整体和谐有序，团队成员目标、行动一致

高效沟通的前提是消息对称，及双方对信息的理解一致。

  • 沟通原理

    沟通原理图

    从沟通原理图，我们了解到沟通不畅的原因在于：

    • 保证信息传递方向正确性
    • 保证信息沟通渠道通畅
    • 保证信息包含的内容准确性
    • 减少噪音的产生

  • 沟通漏斗

    上级心里想的100分，说出来的是90分，对方听到的是80分，对方理解后是70分，对方按60分执行。

    公司想法是100分，部门理解90分，项目团队理解80分，小组分析只剩70分，个人执行60分，甚至更低。

    • 减少消息传递层级数
    • 保证消息传递正确性
    • 保证消息传递不被阻断
    • 尽量保证消息传递及时确认反馈

  • 沟通方向

    • 向上沟通
    • 同级沟通
    • 向下沟通

  • 沟通工具

    • 面对面。最友好。
    • IM工具
    • 邮箱
    • 远程会议
    • 信息系统备注留言

  • 减少噪音

    • 5w2h法（who、when、where、what、why、how、how much）
    • 约定沟通标准流程

  • 干系人

    参考整合管理 - 干系人

    管理干系人期望。了解团队各个成员的要求与期望，了解团队对成员的要求与期望。

    考核绩效。自我考评与上级考评，双方考评相互知情，有分歧及时沟通，下属往往是吃亏不愿说的一方。

  • 沟通表达

    沟通时能说人话就别打官腔。逐级汇报是控制风险，对小公司来说，效率低下就是最大的风险。要反复沟通，反复沟通，反复沟通，重要的事要说三遍，小公司团队中的问题绝大多数是由于沟通产生，也可以通过沟通解决。

    对于管理者来说，沟通表达是一项要求很高的综合素质。参考 团队7大沟通技巧 、 如何用沟通解决工作问题 、 职场团队-沟通

  • 3要3不要

    • 赞美和鼓励的话要说
    • 感激和幽默的话要说
    • 与人格有关的话要说
    • 没有准备的话不要说
    • 没有依据支持不要说
    • 情绪欠佳时候不要说

  • 冲突常用解决方法

    • 进度冲突：常通过合作解决问题来解决
    • 优先级冲突：妥协调解，整合意见
    • 人力资源冲突：缓和、包容，求同存异，各退一步
    • 技术观点冲突：聆听，但命令
    • 管理程序冲突：撤退回避

采购管理

项目是否需要找第三方协助完成

外包采购在互联网公司很常见，特别是中小公司，因为没有互联网的基础设施，比如需要购买服务器、云服务等

现在国内互联网平台服务资源已经很多了，不用总是去找国外的，国内阿里、腾讯、华为、百度、网易等大公司及其子公司或投资的公司都提供了免费或付费的互联网技术基础服务，从早期的网站建设到现在的深度学习人工智能服务等等，应用服务齐全。采购需要相应领域专家提供建议和意见，货比三家，结合团队和公司实际情况制定采购计划。

  • 规划采购（评估）
  • 实施采购
  • 管理采购
  • 采购确认与结束

敏捷开发

  • 什么是敏捷开发

    敏捷开发方法与极限编程

    虽然敏捷开发将软件开发分成多个迭代，但是也要求，每次迭代都是一个完整的软件开发周期，必须按照软件工程的方法论，进行正规的流程管理。

    具体来说，每次迭代都必须依次完成以下五个步骤。

    • 需求分析（requirements analysis）
    • 设计（design）
    • 编码（coding）
    • 测试（testing）
    • 部署和评估（deployment / evaluation）

    每个迭代大约持续2~6周。

  • 敏捷项目管理流程

  • 敏捷开发原则与价值观

    敏捷开发与极限编程原则与价值观

  • 其他

    • 需求分析与讲解
    • 产品立项评审、需求评审、设计技术评审、验收评审
    • 需求打分。集中讨论或打牌的方式
    • 任务分配。负责人自动领取、强制分派，主任务的人创建子任务，下一级同样适合自动领取或强制分派的方式

项目团队发展模型

  • 形成

    团队间相互信任程度低，大家都保守观望，既有点兴奋期盼，又焦虑怀疑。

    • 典型特征

      有礼貌、相对客观、有所保留、防卫心理

    • 典型的疑问

      在寻找自己的目标；寻找自己的角色定位；摸索自己的具体任务；试探与其他同事的沟通与配合，是否合得来；

    • 士气

      一般，还行，高但又有所保留。

  • 震荡

    随着项目的深入，团队进入了震荡期，成员间的沟通配合越来越多，相互冲突频发，权威也时常受到挑战。有挫折有愤怒有紧张有对立。

    • 典型特征

      冲突、争吵、否决、攻击，不再那么客观，开始形成圈子

    • 典型的疑问

      职责混沌，不知道如何发起配合，不知道是否可以这么做那么做

    • 士气

      低落，甚至低谷

  • 规范

    经过震荡期，团队暴露出了很多问题，团队调整去伪存真，通过规范制度来约束解决问题，规范沟通，规范流程，建立互信。

    • 典型特征

      开始有组织性，团队内部有序，整体能力提升

    • 典型疑问

      接受自己的定位、职责，接受团队的规则

    • 士气

      再次提升

  • 成熟

    规范后的团队，也逐步稳定产出了，产出也逐步得到认可，团队整体更团结，矛盾不在内部，而在外部了，具有集体感、责任感、归属感、荣誉感，配合默契，有积极开放的态度。

    • 典型特征

      合作、高效、无私、集体感、归属感、荣誉感、挑战

    • 典型疑问

      身心扑在了项目上了，忘了自我。

    • 士气

      高涨

  • 解散

    没有不散的宴席。目标完成或项目终止或转移，团队终止。

    • 典型特征

      互相推诿，自私，低效，无成就感，无归属感

    • 典型疑问

      考虑自身成长，前景

    • 士气

      低落