项目管理中的设计模式

软件这行，如果干得有滋味，也许会有这种体会：软件就是把一些做事的规则换一种表达而已。就说说我的体会吧。

分配任务和反馈：Request/Response模式，还是Observer(观察者)模式？

因为项目组有七八人，项目上线后，经常有一些bug要修改，开始是这样的：我提出修改建议，开发人员修改，感觉修改差不多后，我再询问开发人员，他答复。如果有五六人要沟通：通知业务人员改内容，通知设计师改界面，自己一忙起来，就忘了检查。

当然了，要是团队每个人都积极主动也没事，但如果当事人很主动，但事情一多也忘了反馈那咋办？问题出来了，看来要寻找一种Solution。

搞软件这行，都有一种职业思维，马上想到BugZilla、JIRA、Mantis，这三种我都玩得很熟，后两种自己部署实施过，用过几年。但感觉对于我们项目组：太重了。填个bug要打开浏览器，输入网址，新建问题，描述问题，提交，通知相关人…，很累，特别是业务员，实在忍受不了这种折腾。

用软件解决前，先想想我们的问题究竟是什么？
问题：负责人和执行者，怎么建立一种有效、高效的问题跟踪反馈模式？

我上面描述的沟通模式，不知大家抽象出来了没有：Request/Reponse模式，主动获取，就是我们敲www.kaixin001.com，然后出现一堆骚扰信息的界面。这是一种典型的Pull模式。

怎么改进我刚才说的问题呢？
大家可能都想到了：让执行者每次处理完毕后，主动通知负责人，并且将这形成一个制度。负责人分配任务后，等着被动告知就行了。

是不是很像Observer模式：定义一个对象间的一种一对多的依赖关系，当一个对象状态发生变化时，所有依赖于它的对象者得到通知并自动更新。只不过，我的情况是：多个对象状态发生改变，我这个依赖他们的对象得到通知并自动更新(知道问题被修复，可以重新部署了)。

在以前的沟通模式中，如果我有6件事情要跟踪，总共需要6+6次主动请求，新的沟通模式：6次主动，6次被动，压力小很多。

刚才说到了访问kaixin001是一种典型的Pull模式，如果我们每天要访问的网站一多，就很累，后来出现了RSS订阅，Pull变成的Push，就像Foxmail自动收信一样，轻松多了。这和我上面的例子一致。

上面这个问题还没结呢，因为我还是比较累。
ok，我又想到了一种沟通模式，并付诸了实践，效果很不错。

Bug处理：星型模式还是网状模式？ Chain of Responsibility (责任链)模式

上面这种沟通模式，大概应该知道，是一种星型沟通，也就是说，我站在中间，大家都和我沟通，都对我负责。

然后我想到了另外一种模式，并且一实施，团队沟通起来非常愉快。因为以上的模式，是上下级沟通，毕竟有些距离。

打个比方吧，开发一个电子商务网站，一个团队有做原型设计的，有做界面的，有做程序开发的，有做内容的。就说这四种角色吧，如果我是负责人，也就是测试人员，发现产品列表页排序不易用，那么我只需要向界面设计师阐述清楚问题即可，如果需要后台程序修改，那么他通知开发人员，开发人员发现内容，比如产品排序标志如“热门”需要勾上，找内容编辑。

这样，一个责任链就形成了。是不是有点像Chain of Responsibility (责任链)模式？(使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止),也许有点牵强。

从结构上说，是网络模式：去中心化，去掉我这个中心。
沟通从6+6次主动，到6主动+6被动，到2次主被动就够了。
我算解脱了，我可以专注于需求分析和功能测试这些更接近用户的工作。
因为是平级关系，沟通更顺畅些，因为沟通，关系也更亲密。

财务报销：模板(Template)模式

大家是不是在公司财务报销上总是感觉不爽，去财务室报销，不是收据不行，就是发票黏贴不对，或者报销时间不对，总之，财务总是折磨我们这些写程序的。

我们是这么做的：公司建议每个人在每月第四周前三天把发票啥的准备好，到时候部门行政MM来收(当然大企业这样做可能不行)， 是不是有种被尊重的感觉？

这种思路是从模板模式学来的：定义一个操作中算法的骨架,将一些步骤的执行延迟到子类中。

这么解释吧：定义的骨架，就是我们的财务报销制度，报销步骤也就是报销者准备账单，被动等待被执行(递材料、收现金)。

也许有人会问，原来那种不算模板模式？不太算，因为它的模板定义不清晰(出现报销时间错过)，而且，后来这种模板方法要处理的“逻辑”更少一些。模板方法的核心，就是“被执行”。

再举个例子，就是部门间沟通和责任界定的事情。

责任明确：高内聚、低耦合

做过管理的大概都知道，部门间协作较部门内困难得多，因为部门间利益很难制衡，打个比方，你开个户外店，别人试了你的望远镜半个小时，你有权力要求别人一定购买吗？

我就遇到过这种问题：网站要经常更新，更新是业务部那边的事情，我经常发现一些问题，比如产品价格过时，产品描述错别字。我该找谁？七八个业务员，难道我要一个个知道哪块归谁负责？并且通知其中某个人吗？再说，他可能会说，凭啥要听你的？

当然，如果企业有优秀的协作共赢文化，业务员可能会觉得你在帮他，但大多数情况呢？

也许我直接找负责人就不是最有效的？怎么做？先建立一套网站运营责任链，比如运营过程中，网站任何内容错误，如果没有及时反馈给IT部，是业务人员的责任。

如果我要提出业务问题，直接提给业务部产品经理，他确认、修改后给我反馈。我不需要知道修改工作，比如上传一张图片，是由谁来做。

一个部门，对外应该是高内聚，低耦合的，这里面蕴含的一个核心思想，就是职责分离。

这也符合软件上的面向接口编程：我和业务部沟通接口只应该是产品经理，他们内部沟通，对于其它部门来说，是private的。

先就举这几个例子吧。像软件分层架构思想，在建立高效的组织结构方面，也可以借鉴一下。因为软件本身也是一个组织、生命体。

组织有生命周期，也有从简单到复杂到衰亡的过程。组织有自我修复功能，健壮的软件也会有，比如优秀的异常处理机制。