作为一名产品经理，首先要知道产品对于所属公司来说意味着什么，要探寻这个问题，我们又得知道和公司息息相关的是什么，在我的理解来看，与公司状况相关的因素有以下这些：
- 市场份额
- 平均订单金额
- 盈利能力
- 资产回报率
- 从订单转化为现金的周期
- 应收账款
- 借贷成本
从这些因素体现出来的最直接的就是公司收入，公司的财务状况，进而可以得出公司的经营状况，如果这些指标一塌糊涂，那么这个公司离倒闭也就不远了。那么现在我们再来看产品对公司意味着什么，应该不难发现上面这些指标都离不开产品，产品的市场份额、产品的平均订单金额、产品的盈利能力、产品的回报率、产品订单转化为现金的周期、产品的应收账款、投入产品时的借贷成本。好的产品就能创造出好的这些指标，反之亦然，所以往大了说，产品经理在某种程度上对公司的生存有着一定决定因素，尤其规模不是很大的公司。那么作为产品管理者，如何能帮公司打造出好的产品呢？
武装自己
首先我们需要能让我们打造出好产品的方法论来武装自己，所谓方法论，就是一门学问所采用的方法、规则与公理，放在软件工程中，它便指一系列编撰好的建议方法、训练方法及材料、使用的各种工具。在当今的IT领域，这种方法论莫过于DevOps了，我用它武装为自己的铠甲。
我不打算就DevOps做概念上的解释，我要说的是为什么我要选择DevOps，它能给公司和产品带来哪些好处，概括来说有以下五点：
- 它能使产品更快的投入市场。
- 它能提升客户满意度。
- 它能提升产品的市场份额。
- 它能提升员工生产力及工作成就感和幸福感。
- 它能给公司在市场中创造出巨大的竞争优势。
打造利剑
产品的产出过程就是开发过程，在开发方法上我选择敏捷开发作为我的利剑，虽然这不是什么新鲜东西，但是它却是经过长期千锤百炼，经得起考验的开发方法，就像使用千锻、万锻后的精钢打造的利剑一般，首先在材质上就不会轻易损坏，只是你能否耍好剑的问题。
从理论上来说，敏捷开发在当今湍流的IT领域中好处不言而喻，积极甚至激进的个体互动、时刻有可交付的成果、紧密的客户合作、快速的响应变化都完胜传统瀑布式开发那套冗长的过程、冗余的事无巨细的文档、漫长的合同谈判和循规蹈矩的拖沓计划。
有了利剑，我门要学习剑术，敏捷开发有若干方法可供我们使用，比如Scrum、特性驱动开发（FDD）、测试驱动该开发（TDD）、行为驱动开发（BDD）、精益开发等，但是敏捷开发不存在官方的方法，没有完整的方法列表，也不存在最好的方法一说，只有最合适的方法。我选择了Scrum，理由很简单，它同样经历了多年的历练，已去其糟粕。
个体互动
我们先来看看个体互动，首先要明确的是你的组员，不论是开发人员、测试人员还是运维人员，他们绝对不是你的工具，不是你的枪，更不是你枪里的子弹，他们是你的伙伴，一起战斗的伙伴，只是分工不同而已。所以我们要了解他们，和他们建立互信互助的关系，建立团队沟通习惯，围绕斗志高昂的团队成员开展工作，这也是敏捷开发的原则和成功要素之一。那么我们该如何做到这些呢？这就需要使用Scrum剑术中的这几个技能：
- 每日立会：每天不论早晚，抽15分钟时间，团队每人都要发言，汇报工作完成情况以及遇到的问题，让大家都彼此了解对方的工作内容和进度。
- 每周代码评审会：团队成员之间互相对代码质量进行评审，提出意见和建议。但是要确保的是每个人都要放下自尊，虚心接受和诚恳的评价。
- 每月畅谈会：团队成员之间勇于互相展现出自己脆弱的一面，可促使团队达成互相信任。每人发言，说说自己遇到的最困难的事，或觉得自己做的比较差劲的事，虽然这种方式一开始会有点残忍，但一旦团队成员彼此之间成为了倾诉对象，那么团队的团结互信将达到另一个境界。
- 每月回顾会议：也称为总结会议，每月进行总结并讨论在各方面需要改进的地方。
- 不定期技术交流会：我们鼓励团队中的每个人都向着专家的目标去努力，尽可能去专精自己擅长的技术，有一定积累后，无私的与大家分享交流，我很乐于看到团队成员彼此都称为对方老师。这有利于促进团队整体实力的提升。
时刻有可交付的成果
何为可交付的成果，这里的成果指的不仅是产品，每一个开发人员完成的功能模块甚至与一个功能都算是是成果。那么可交付的成果既对功能模块有用的功能、对产品有用的功能模块、对客户有用的产品。那么所谓有用又如何定义呢，它在这里指的不仅是代码逻辑无误并测试通过这么简单，而是让客户买账。那么我们要如何从源头就做到有用呢？这里需要用到Scrum剑术中的几个技能以及另外一个剑术，我们先来看看这个剑术。
区分“相关”与“无关”的工作
这个剑术用一句话来概括就是弄清楚与实现公司目标息息相关的是什么。具体的技能以下三个：
- 把公司上层的评估指标作为前提条件与具体的业务部门和开发部门的任务关联起来。只要能说明IT风险会对业务绩效指标产生多大的影响，就能着手指定更好的业务决策。
- 与各指标对应的业务流程负责人进行访谈，理解客户的需求与期望、产品系列、上市时间、销售渠道等分出项目优先级。
- 冻结低优先级的产品，保留高优先级的产品，形成相对单一的工作流。
从这个剑术可以看出，它不仅适用于产品层面的管理，也适用于公司层面的运营。但不管是作为产品经理还是作为公司运营者，我们都得有一个列表，那就是公司的远期目标，也就是公司上层的评估指标：
- 我们要创建什么？
- 我们有正确的产品吗？
- 我们能有效的创建产品吗？
- 我们能尽快把产品推向市场占有一席之地吗？
- 我的产品能带来感兴趣的潜在客户吗？
- 我们遵守了对客户的承诺吗？
- 我们是在获得客户还是在流失客户？
- 我们的销售预测准确率靠谱吗？
与此对应的是：
- 了解客户的需求和期望。
- 根据市场和客户确定产品系列。
- 提高研发效能。
- 缩短产品交付周期。
- 研究销售时机和销售渠道。
- 保证按时交货。
- 提高客户留存率。
- 保证市场和销售报告数据的精准性。
以上八点其实是环环相扣的。当把这些问题都搞清楚后，自然而然就可以区分出哪些工作是“相关”的，哪些是“无关”的。
细分任务
当我们确定了一堆相关的工作后，需要使用Scrum中的另外几个技能将这些工作根据优先级进一步的细分：
- 确定产品需求列表（Product Backlog）。
- 开发团队根据产品需求列表作出整体工作量的预估。
- 通过迭代计划会议（Sprint Planning Meeting）根据优先级及资源情况从产品需求列表中筛选出用户故事（User Story），作为本次迭代要完成的目标，一般周期在1-4个星期内。
- 将用户故事再进行细化，形成迭代需求列表（Sprint Backlog），通过看板将其可视化。
我们通过确定出的“相关”工作，根据优先级进一步确定产品需求列表，这要注意的是，现在的产品需求列表中的内容已经是和公司的评估指标相关链的任务，所以都是极有价值的，现将这个需求列表评估出整体的大致工作量，然后通过迭代计划会议从中筛选出用户故事，也就是确定团队的短期目标，最后再将用户故事细化为更小的简单任务，一般周期保证在2天以内，分配给每个团队成员，在必要的时候还可以使用计划纸牌工具进行周期确认。Scrum中的这4个技能干的事就是能让整个团队清楚我们的最终目标和每一个短期目标，以及对整个目标的时间把控，在不断分解的过程中消除团队对庞大目标的恐惧感，并建立信心。
计划纸牌工具的作用是确认探讨最小任务的具体周期。比如A程序员开发一个功能要5个小时，而B程序员认为只需要2个小时，那么他们各自取出有相应时间的牌藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以对这两个时间进行讨论，最后确定最合适的任务周期。
持续集成
持续集成也是Scrum剑术中的技能之一，持续集成也就是每日集成部署，保证每天都要有一个可以成功编译，并可以演示的版本，要做到这一点，传统的集成部署方式显然是无法实现的，所以我们需要使用自动化集成部署方案。
持续集成一般分为四个阶段，也是通过不断摸索实践，从历史长河演化而来，但这四个阶段的方式没有谁好谁坏，只有我们的现状适合哪个阶段。
- 代码级别的集成：这个阶段不依赖独立的集成工具，一般使用IDE内置的编译工具。同时代码风格检查、单元测试、测试覆盖率都有开发人员在本机人工执行。接下来的交付准备环境、运行测试、备份旧版本、新版本打标签以及反馈机制等其他重复的事情都由手工完成。
- 集成工作流：这个阶段整个开发流程的重心从代码级别的集成转移到了更自动化地编译和更完善的测试验证，致力于在最短时间内发现问题，缩短开发周期，提高软件质量。具体的形式是先进行代码编译，触发单元测试，集成测试，打包测试，自动部署到测试环境。循环往复，形成编译-构建-测试-集成-部署的工作流。
- 持续交付与部署：在上个阶段，自动部署只是最终部署在测试环境，还需要手动部署到生产环境，因为产品从需求到部署的过程中会经历若干个不同的环境，如开发环境、QA环境、自动化测试环境、生产环境等。所以在这个阶段要建立标准化的环境部署顺序，在工作流中增加部署预生产环境，并执行灰度集成测试，做好线上环境部署后的回归测试。持续交付并不是指软件每一个改动都要尽快部署的产品环境中，而是指任何的代码修改都可以在任何时候实施部署。而持续部署，指的是自动部署到生产环境中。
- 基于Docker的持续集成：这个阶段是上个阶段的进化，主要解决的问题是通过Docker统一部署环境。具体形式是开发者提交代码，触发单元测试，集成测试，打包测试，产品构建，触发Docker镜像构建，构建镜像上传至私有仓库，镜像下载至执行机器，镜像运行。
通过持续集成我们就可以大幅缩短成果的交付周期，从而达到不断交付有价值的成果以满足客户需求的先决条件。
至此，我们有互相高度信任的团队，有条不紊的做着正确的事，不过我们只完成了计划内工作流的第一步，既优化工作优先级。目前我们只是有了让产品更快的投入市场的先决条件，想要真正实现，那么还需要提高计划内工作流的流量吞吐率及流速。
寻觅坐骑
首先我们要明确在我们的所有工作中一共有四种类型的工作：
- 业务工作：也就是我们需要完成的和产品相关的工作。
- 内部工作：团队内部做的一些改进工作，比如搭建自动化部署框架等。
- 变更工作：由上面两种工作引起的工作，比如开发向测试交接时引起的问题，业务工作的需求改变引起的问题，内部的改进工作引起的问题等。
- 计划外工作：一般都由上面三种工作导致，尤其是变更工作引起的需要补救的工作，而且往往优先级都相对较高。
业务工作和内部工作我们又称之为计划内工作，变更工作往往也是我们无法避免的，而计划外工作是最为可怕的，如恶魔一般，我们要以牺牲计划内工作为代价去消灭它。
所以我们知道了影响计划内工作流流速的其中一个因素就是计划外工作，那么影响流量吞吐率的因素是什么呢？那就是约束点。
我们将产品从需求到交付的过程想象为一个加工工厂的加工流水线过程，产品需求看作是加工原料，开发、测试、运维等看作是工厂流水线上每一环节的机器，原料从流水线起始位置流入，经过一个个加工机器，最终加工为一个成品。但是当其中的某个机器工作效率很低的时候，在该机器处就会堆积越来越多从上游传来的半成品，而下游的机器则闲置着，或者使用率极低，这种情况下这个工厂的生产效率可想而知。那么这个效率很低的机器就是整个工厂流水线的约束点，不但影响了流速也影响了吞吐率。那么这个机器相当于我们产品开发中的什么呢？是不同分工的个人还是不同分工的团队呢？
带着这个问题我们继续回到这个工厂，仔细观察可以我们可以看出加工流水线上的每个加工环节都有四个部分组成，那就是机器、人员、方法、测评。机器是工具，人员按照方法操作工具，然后根据测评细则检查加工的半成品在这一环节是否合格。这四部分组成的就叫工作中心，工作中心就是产品开发中不同分工的团队，所以某个团队的效率低下就会称为整个工作流的约束点。
那么团队为什么会成为约束点呢？因为团队里也有约束点。我们来继续看这个工厂，如果操作某个机器的人操作不熟练，或者一个人要兼顾好几个机器的话，那么这个人员就可能成为这个工作中心的约束点，甚至是多个工作中心的约束点。所以，解决约束点的问题是至关重要的，所有在非约束点所做的改进都是假象。
消除或保护约束点
有些约束点是因为自身能力问题导致的，这种情况下我们可以先调整他的任务，将优先级相对低的任务分配给他，同时通过技术交流会或者师带徒快速提升他的能力，从而消除约束点。另一种情况的约束点恰恰是因为这个人能力很强或者他的工作牵连着别的工作中心，从而参与了多个工作中心，反而使他自己的工作中心效率低下，这种情况我们就要采取保护约束点的措施：
- 永远不要让这种约束点迁就别的工作中心，我们的做法应该完善每个工作中心的方法，使之标准化和自动化，我们的持续集成技能就能改善这一点。
- 将这种约束点着力于完成优先级相对比较高的任务。
所以我们要善于识别约束点，然后消除或保护约束点，最后寻找下一个约束点，以此反复。
杜绝计划外工作
为什么计划外工作会影响工作流流速呢？因为它增大了工作流中的某个工作中心，或者工作中心里某个人员的等待执行计划内工作的时间。等待时间怎么算的呢？等待时间等于忙碌百分比除以空闲百分比。
等待时间 = 忙碌百分比 / 空闲百分比因为计划内工作，在前期都指定好了合理的周期，所以团队成员的忙碌百分比一般不会超过50%，所以空闲百分比也是50%，那么等待时间就是1。如果有大量的计划外工作涌进来，那团队成员的忙碌百分比就有可能达到70%或80%，甚至更高，假如忙碌百分比达到了80%，那么空闲百分比为20%，等待时间将增加到4。所以从这个公式可以看到，超负荷的工作任务其实是产生约束点的罪魁祸首，而计划外工作又是超负荷工作的始作俑者。
那么我们该如何杜绝计划外工作呢？我们知道计划外工作一般都是有变更工作引起的补救工作，因为80%的计划外工作都是由20%的变更工作造成的。既然变更工作是不可避免的，那么就尽量做到不引起补救工作，也就是要干净利落的完成变更工作，防止因变更工作导致其他问题发生。所以要想有效的杜绝加化外工作，那就需要建立起变更管理系统。
变更管理系统的主要作用是确保能正确实施变更确认、分析、评估、计划、实施、检查的过程。它的相关干系人可分为三个角色：
- 客户：发起变更工作的源头，这个客户指的不仅是用我们产品的真实客户，在产品生命周期中，测试团队可能是开发团队的客户，开发团队可能是运维团队的客户，因为他们都有可能给上游或下游发起变更。
- 变更委员会委员：既对变更进行分析、评估、计划及决定变更优先级和变更实施者的人。
- 变更实施者：既具体实施变更的人或团队。
这三种角色的人参与整个变更流程，基本的变更流程如下：
- 产生变更：客户有新的需求或者更改原有需求。产品生命周期中，上下游的工作中心发起变更，比如发现Bug，或者修改部署环境配置等。
- 分析变更：变更委员会确定变更请求的技术可行性以及变更成本和变更收益，暂时过滤涉及约束点的变更。
- 评估变更：评估变更影响范围，既实施了变更后会对产品的哪些地方产生什么样的影响，明确变更影响和确定防范措施。
- 计划变更：根据分析变更和评估变更的结果，确定可实施的变更，既变更优先级，然后分配变更实施者。最后将所有状态的变更使用看板将其可视化。
- 实施变更：变更实施者根据计划变更的结果，按计划执行变更、测试变更、完备变更文档、发布变更。
- 检查和关闭变更：对已完成的变更进行检查，根据变更文档和测试变更的结果决定是否认定变更成果完成并关闭变更。
有了完善的变更管理系统，通过严格的变更流程，我们首先可以筛选变更，其次可以对变更了如指掌，可以通过计划内工作看板和变更工作看板分析出如何安排变更工作，安排给谁最为合适，最后我们可以确保更变工作在掌控中安全的完成，不会产生额外的需要补救的计划外工作。
所以消除或保护约束点以及变更管理系统可以帮助我们提高工作流吞吐量和流速，是提升我们速度的最好坐骑。
至此，我们就完成了计划内工作流的第二步识别保护约束点，并且基本实现了第一工作法，既帮助我们在工作到来时如何建立快速工作流，使需求-开发-测试-运维-客户整个自左向右的工作流流量最大化，不让缺陷流向下游工作中心，为了整体目标不断对工作流进行优化。在第一工作法的帮助下，我们似乎可以使产品更快的投入市场了。
装备盾牌
当拿着利剑乘骑着坐骑冲进战场后，其实战争才刚刚开始。根据我的经验，绝大多数产品在投入市场后依然会存在一些Bug，而且会被客户发现，哪怕之前已经经过了测试系统的测试，所以当产品快速投入市场后，客户的的各种新需求和Bug反馈会如猛兽一般砸向我们，我们要做的就是一边盾挡洪水般的新需求一边斩杀客户发现的Bug，但仍会让我们措手不及。然而客户的需求和要求是无穷无尽的，像填不满的沟壑，如果我们能及时进行预判，那么我们就能自如许多，逐渐和客户形成良性循环。
个体之间的反馈回路
我们在开发过程中，经常会遇到这种情况，A开发人员开发的某个功能流转到B开发人员使用，但是B开发人员发现这个功能开发的不完善，不能满足B的需求，于是B按照自己的需求修改了A开发的功能，而不会去考虑这个变更是否会影响到C的使用，于是这个功能在工作流上一直流转下去就有可能已经远悖与原始需求了，如果这个功能看作是工厂生产线中产品的一个零部件，那么这个四不像的零部件在组装成品时会带来什么呢？必然是零件不合规，于是20%的变更引起了80%的计划外工作，眼看交付日期降至，开发人员又开始奔命与修补工作，即使最后完成了成品的组装，或许还是会留下不可预知的隐患及Bug。解决这类问题的最好办法就是建立起个体之间的问题反馈回路，它能避免不必要的变更工作。
一般变更工作都是在事物相对成型的状态下动其内部细节的工作，这种变更工作往往能牵一发而动全身，一个不好就会像釜底抽薪一般，让整体摧枯拉朽的坍塌，所以我们要有变更系统来加以管理和约束。上面那个例子中，如果当B发现A开发的功能不合规时，能立即反馈给A，经商榷探讨后由A及时修正了这个功能，并且A的这个修正行为并不属于变更行为，那么也许后面一系列的问题都不会发生了。这就是个体与个体之间的反馈回路，这种反馈回路要尽可能的短，回路两头要能快速响应，工作流中的每个个体都应该要建立这种反馈回路，而且尽量不要跨个体建立。
工作中心之间的反馈回路
个体之间建立反馈回路，能有效保证单个工作中心能按照它的规格产出合格的成果，但也许这个成果与整个工作流对产品的规格来说还有差异，所以工作中心和工作中心之间也要建立反馈回路，开发团队和测试团队之间，开发团队和运维团队之间，每个工作中心要指定一个个人作为反馈信息接口人，这样从细节到整体都能有效降低变更工作的发生率，从而大大减少计划外工作的发生率。
然而，反馈回路反馈的不仅仅是各种问题，还有其他更重要的信息，那就是市场团队和产品团队之间的反馈回路承载的信息。我们能预判市场和客户的需求呢？市场团队通过反馈回路不断提供的各种销售统计和市场报告是良药，能使产品团队知道做哪些事能让公司利益最大化，做到对市场需求和客户需求的预判，从而能抢占先机的将迎合市场的新功能推向市场。
反馈机制就是我们的盾牌，有了这面盾牌，我们就能很好的完成计划内工作流的第三步按时高质量交付成果，做到不欠技术债务，减少变更工作，进一步杜绝计划外工作。同时这也是第二工作法的核心内容，那就是建立尽可能短的个体之间和工作中心之间的不间断反馈回路，在个体之间、工作中心之间建立共同的目标和共同的解决问题的机制，这使我们能在产品初始阶段就能筹划并保证产品质量问题，避免返工，并且能及时获取到市场数据，做到市场需求和客户需求的预判，从而提升客户满意度和提升产品在市场的份额。
营造环境
第三工作法的核心是在团队或公司建立鼓励探索、不断从失败中吸取教训、理解反复的实践是精通工作的先决条件的文化。让团队形成敢于创新、敢于冒险以及高度信任彼此的文化，同时要让所有人知道非功能性需求对于产品同等重要，合理安排功能性需求实现和非功能性需求实现的计划。第三工作法精髓在于不断尝试和理解重复练习是熟练掌握的前提。
总结
我们以DevOps方法论为基础，以三步工作法为指导思想，使用敏捷开发、区分“相关”与“无关”工作法、变更管理系统、保护约束点、建立反馈机制等具体方法，经过不断的实践和优化最后形成的工作流称之为价值流，它是从需求获取到代码签入再到产品投产整个工作流中的关键路径。我们要将价值流上的所有东西进行版本控制，使价值流中的每个个体都共享一种文化，这种文化不仅重视彼此的时间和贡献，而且为了实现整体的持续改进，要勇于不断向自己的工作注入压力，同时使每个个体都要像重视功能性需求一样重视非功能性需求，比如产品质量、可扩展性、可维护性、可操作性、安全性等。
如果我们能建立起这种价值流，那么就能提升员的工生产力以及工作成就感和幸福感，让公司重塑生产能力，从库存型生产转变为订单型生产，从给公司在市场中创造出巨大的竞争优势。