控制“库存”，组织软件生产的有利武器

绝对没有错，库存在软件项目生产也是存在的！库存就是指部分完成的工作，广义上讲就是指已经开始但尚未给客户创造价值的全部工作。在软件项目生产，我们可以容易地指出“库存”：

1. 尚未与用户进行确认的需求或者需求变更列表是库存；
2. 尚未被开发阶段验证的设计工作是库存；
3. 没有被提交测试的代码是库存；
4. 已经“做完了”，没有通过验收的开发工作、分析设计等工作也是库存；
5. ...

理论上讲，软件开发中的库存量是一次交付中的全部工作量。 这可能是1个月的工作量，也可能是半年，甚至是一年的工作量，但是长期大量持有“库存”将给我们带来很多的风险。譬如：用户A要求我生产100个零件，要求我在一个月内生产完毕，我有以下两种可能的做法：（当然还有更多）

1. 组织生产，等一个月后，100个零件一次性交付；
2. 组织生产，平均每天向客户交付3个零件；

以上两种生产方式看似结果一样，但是结果差别很大。采用第一种方法的方式与成本潜在的风险更大，因为第二种方法有以下的优点：

1. 减少了库存管理的压力，我不需要最大100件容量的仓库，即便是我有多批生产同时组织，我的配置管理压力也会少一些；
2. 直到最后一天之前，我的生产一直在开展，如果用户每天交付的3个零件不满意，有次品打回，我也能够快速调整生产，及时修正或者修订；避免等我最后一天交付，等用户清点完毕后，告诉我回去再把工人找回来修改！

呵呵，这个例子很简单，谁听了都能懂！不如举举发生在我们身边IT系统的库存故事：

 

故事一：需求变更的故事

昨日开会，某同事谈到了项目的超出计划工作量，需要用户确认从1月份到9月份，共发生了10人月，但是谈到了客户对10人月有疑义，可能追不回来。是的，可能很难追得回来。原因何在？抛开具体的工作内容的细节，共9个月的库存现在才交付给客户，客户能轻易认吗？如果这9个月的库存象其他项目一样，通过周例会或者月度备忘的方式进行库存交付的确认，结果可能很不一样。

故事二：系统开发的故事一

某项目，开发了近一年，然后才交付给最终用户试用，计划跟用户谈上线，就发现很多困难。是的，因为共一年的库存一次交付给客户，客户没有这个信任的基础，生产了一年，才看了两眼，就要谈上线，很困难。犹抱琵琶半遮面，才刚看一下，就要你结婚，你也不敢啊！（当年慈恩威胁杨过娶公孙绿萼，方可拿到解药，杨过还不从呢！）

 

软件质量方面也有库存的故事，我的体会是质量主要不在于你投入了多少人组建了一个多么大的后期测试队伍，而在于测试的时机和方式，等所有功能都做完了再测试就太晚了。

是的，这些都是软件库存的故事。掌握好方法，制造“频繁”交付就是减少库存的有利手段！从软件系统来讲，零库存这种极限是每次提交给客户都是交付就绪的成果。

管理者，你做好控制库存的准备了吗？