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