作者介绍
Joel Spolsky
Joel Spolsky毕业于耶鲁大学，获得计算机科学最优等理学学士学位。曾担任微软Excel团队程序管理经理，后创办了Fog Creek软件公司。现在为Stack Overflow的CEO（也是联合创始人）。
想象一下，你第一次来到面包厂。一开始，它看起来像是一堆杂乱不堪的机器，周围有几个人在嗡嗡叫。当你调整你的眼睛时，你开始看到一些你熟悉的小东西：一桶桶芝麻。一大桶面团。小面团。烤面包。
这些都是库存。库存往往在机器之间堆积起来。在将芝麻籽涂在汉堡面包上的机器旁边，有一大桶……芝麻籽。在装配线的最末端，有一箱又一箱的面包，它们等待卡车把它们送到客户那里。
保持库存成本很高。假设你的面包店有6个50吨的筒仓来储存面粉。每当他们清空，你就得把他们填满。这意味着平均每天你有150公吨小麦粉库存。按今天的价格，你已经永久性地赚了73000美元。
库存也可能有其他成本，比如损耗。面粉可以持续几个月，但面包从烤箱里出来时，它的价值开始下降；24小时后，它几乎一文不值。
为什么要保持库存？因为耗尽东西也是有成本的。如果需要两天的时间才能下订单买到芝麻，而你的芝麻已经用光了，那么你就等于告别汉堡包生意两天了。库存提供了一个缓冲区，防止流程中的任何部分进入停滞状态。有现代算法来优化你在每一点需要多少缓冲（可以阅读丰田的精益生产系统和约束理论来开始习得这方面知识）。
我为什么要关心这些呢？软件生产过程本身有几个主要的“库存”积累点。在这些时间点积累的东西最终浪费了大量的时间和金钱。
“什么？把软件比作一间工厂？”你问道。
试想着把产品点子当作原材料。根据你的进程，产品点子在作为最终特性交付给客户之前可能要经过几个装配线点：
一个决策过程（我们应该实现这个特性吗？）
一个设计过程（规格、白板、原型，等等）
一个实现过程（编写代码）
一个测试过程（发现bug）
一个调试过程（修复bug）
一个部署过程（向客户发送代码，将其放到web服务器上，等等）
（P.S. 不，这不是“瀑布”。不，不是。闭嘴）
在任意两个阶段之间，库存会堆积起来。例如，当程序员完成代码的实现（阶段3）时，他们会将代码交给测试人员进行检查（阶段4）。在任何给定的时间，都有一定数量的代码等待被测试。这些代码就是库存。
代码库存的“成本”是巨大的。这可能意味着要花6甚至是12个月的时间才能把生产线上堆积的工作做完，而且还没交付到客户手上。这可能是拥有尖端产品（iPhone）和不断追赶的产品（Windows Phone）的区别。让人们购买Windows Phone几乎是不可能的，即使iPhone是只领先了6个月的水平。许多市场都有网络效应，成为第一名意味着赢家通吃。因此，在开发过程中去除库存可能会决定产品的成败。
我们来看看存货积累最多的三个地方。
功能点积压表。每一个产品都会吸引新的功能想法，你不能像想出它们一样快速地实现它们，所以你把它们写下来，这个列表叫做功能点积压表。挤压表中的很多想法都是糟糕的，你只是把它们写下来，以免伤害那些想出这些想法的人的感情。挤压表让每个人都感觉不错。
问题是功能点积压表中90%的内容永远不会实现。所以，你花在写下、设计、思考或讨论那些永远不会实现的特性上的每一分钟都是在浪费时间。当我听说产品团队经常有待办事项整理会议，他们每天或每周都在认真地浪费哪怕很少的时间和精力去思考每一个永远不会实现的功能时，我都想要把我的眼睛挖出来。
建议：不要允许超过一个月或两个月的工作量进入功能积压表。一旦积压工作已满，除非删除某个项目，否则不允许添加新项目。不要花任何时间指定、设计或谈论积压的项目：事实上，积压的项目应该被看作是不允许谈论或处理的事情的列表。
Bug数据库显然是一件很好的东西。错误报告应该是完整、准确和可操作的。但我注意到，在许多现实世界中的公司中，不容许遗漏任何bug的报告的愿望最终会导bug破产。一天你醒来发现数据库中有3000个待解决的bug，其中一些是如此的久远以至于可能不再适用，其中一些永远无法复制，其中大部分甚至不值得修复——因为它们太小了。当你仔细观察时，你会发现在准备这些bug报告的过程中已经花费了数月或数年的时间，你会问自己，当我们的产品令人愉快并且客户喜欢它并且每天都使用它时，我们怎么能在数据库中有3000个bug呢？在某种程度上，你会意识到你在bug数据库中投入了太多的工作，而在产品中投入的工作却不够。
建议：使用分类系统来决定一个bug是否值得记录
不允许超过需要两周来修复的bug进入bug数据库。
如果超过了两周，赶紧去修复bug，直到你觉得你在修复愚蠢的bug。然后把这些bug关闭为“不会修复”放到bug数据库中。别担心，严重的bug总有一天会再出现的。
未部署的功能。仍然有很多团队会按季度或年度发布产品更新，通常是因为他们的部署过程很昂贵。操作系统，或者任何必须由每个用户安装软件的操作系统，通常都是批量生产的。
这是最昂贵的库存形式之一：未发货的功能点库存。它可以给你赚钱，但它此刻在你工厂的货运码头上——而街上的人已经有了一个产品，可以做同样的事情。
有时，很糟糕的是，你甚至感觉不到痛苦，因为你的团队中的每个人都在数月来一直在内部试用的新版本。我敢肯定，微软的每个人都已经愉快地使用Windows 8一年了，所以他们不会体会到代工生产商试图在Mac OS X Lion世界中销售Windows 7的日复一日的痛苦。
建议：不要让已完成的功能以不赚钱的方式堆积起来。保持对部署上线的关注，这样你可以在几个月而不是几年内获得客户的需求点。如果你已经保持每月的上线节奏，那就想办法改成周。你需要不断推动越来越频繁的部署在越来越小的变更上。
那么，我该怎么办呢？在FogCreek，我们已经有了所有三种种类的库存：疯狂冗长的积压表、野心过大的bug数据库，以及等待下一个版本发布但要卡一年的功能。所有这些都是我们的。我意识到我们需要一个系统来限制库存，这样库存就不会过度增长。
我最初的想法是做一个叫做“五件事”的产品。这本将成为一个项目经理，每个人都被允许有五件事情分配给他们：两件他们正在积极做的事情，一件接下来要做的事情，还有几件他们正在计划的事情。这个设计理念最终没有跑通（但如果你想构建它，就去做吧)，但它确实演变成了Trello。
Trello对于合理数量的库存管理非常有效，但是如果你在一个列表中有太多的卡片，它就会变得惨不忍睹。而这正是关键所在：它使库存可见，以便你知道它是何时开始堆积的。(点击右边的图片可以看到Trello团队自己的开发板)。
每天，你查看你的Trello板，会发现有17个完成的功能点已经完全准备好去发布，但是由于某些原因还没有，你需要找到瓶颈并消除它。
每次有人提出一个疯狂的功能点的想法时，你查看功能积压表并意识到它太长了，所以你不会浪费任何时间来记录或设计这个疯狂的想法。希望你能花更少的精力在那些从未见天日的事情上。“清理积压表”。嘘~
欢迎关注公众号
微信搜索：产品经理什么都知道 或 ProductX 或 扫码，谢谢支持！
网友评论