即将去的一家互联网公司，由于规模很小，因此我面临着整个技术产品团队的重建问题。我不太主张全部替换，而是主张在提升中淘汰，也就是说，先尽我的可能去提升他们的各方面能力，实在是提升不起来的，只好淘汰。基于这个原因，在第一次给团队开会的时候，我提出了一个概念——Sharing Day，即每周的团队例会每个人除了要总结上周所做的工作任务及下周的工作安排以外，最重要的一个议程就是“分享”，每个人都要去分享自己觉得有必要和团队中其他人进行分享的事物，在彼此的分享中去学习到新的东西，从而提高自己。

在过去的几次Sharing Day中，我分别跟团队成员谈了职业规划、网页栅格理论、高并发高流量网站架构和特性列表法等等。突然觉得有必要将这些自己和他们分享的内容放到博客上，以便和更多的人进行分享（如果有足够的时间，我可能会把每次分享的内容做成PPT保存，进而在博客上提供下载）。

回到主题，第一次听到特性列表法这个词是在若干年前，当时公司项目经理存在一个问题就是当需求书内容过多或开发过程较长的时候，项目经理有时候会出现对功能点的遗忘或对功能细节的表述不清晰，进而影响项目质量。为了解决这个问题，那时，david教了我们一个方法：特性列表法，和todolist很相似，但也有一些不同。

• 一个项目的特性列表是由若干条特性组成；

• 一条特性由如下格式组成：

[特性属性][项目版本号+特性编号]特性内容描述

举个例子，某项目，当前版本为2.3，特性编号0001，特性属性为修改，特性内容描述为”将页面宽度由原先的960px，修改为970px，所包含的页面为：首页、内页、注册页”。该条特性如下：

[*][0230001]将页面宽度由原先的960px，修改为970px，所包含的页面为：首页、内页、注册页

• 特性属性分别有三种：添加、删除、修改，对应的符号分别为+、-、*

• 版本号不变，特性编号依次累加

对于项目经理，只需要将特性分配给不同的人去做，而自己则对照特性进行检查。

再进一步，项目经理在规划特性列表的时候，可以把某些特性的完成做为里程碑(milestone)，将项目特性列表设置为不同的里程碑，以便更加有效的控制项目进度。而在项目进行中发现的问题或新的想法，完全可以以累加特性编号的方法，完善项目特性列表，以作为备忘。

有些时候，一个项目特性列表并不代表着必须全部才算结束，毕竟有些时候某些因素导致项目必须结束而某些特性又没能完成。那么，在这种情况下，未完成特性列表将合并入下一个版本继续进行。比如假设上述例子中2.3版本的0015、0027未完成，那么，2.4版本的特性列表样式如下：

[+][0230015]xxxxxxxxxxxxxxxxxxxxxxxxx

[*][0230027]xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[+][0240001]xxxxxxxxxxxx

[+][0240002]xxxxxxxxxxxxxxxxxxxxxxxxxxx

这样，项目不同的版本，其特性有了很好的延续。

总结，采用特性列表法的好处：

1.细化项目需求，便于跟进

2.项目进行中，也能适当的进行调整

3.更有效的控制项目进度

4.量化项目需求，能有效的对项目团队成员的工作量进行衡量

5.项目特性列表的延续性决定了其也适合于某些存在版本升级需要的项目

建议：

1.每条项目特性一定要写到最细化

2.坚持使用这个方法

最后，感谢david教了我们这一方法，而在我所构思中的开源项目管理系统，其项目管理核心便是依赖于特性列表。