关于软件思想在管理中的一点体会

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

分配任务和反馈：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的。

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

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

好文章, 非常有启发~

wow,,有想法，把设计模式运用到管理中！

其实象BugZilla之类的软件，当执行一个操作后，可以设定给相应的关联人发邮件，其实这就是一种通知方式。

个人认为并不一定面对面的告知才是通知，面对面告知在小的项目组是可行的，如果是一个比较大的项目组，不一定可行。

没有bug跟踪系统会很痛苦的,现在我用的是redmine,

楼主文中提到让业务员等填写BUG表单不可行,这点我赞同,但这个问题可以通过"高内聚,低偶和"的模式解决,业务员统一将问题反馈到自己部门的某个负责人,再由负责人(报告人员)来填写BUG

"让执行者每次处理完毕后，主动通知负责人，并且将这形成一个制度。负责人分配任务后，等着被动告知就行了。"
我认为这里仍然存在负责人不够主动的问题,楼主没有提到如何监督制度执行情况,在企业中制度制定却很难被执行的现象仍然很普遍吧

Bug管理，这两年，我们经历了三个阶段。
先说说使用环境吧，因为这是决定一管理软件是否适合的最核心条件之一。

人员 有开发人员和不懂软件的业务人员 问题主要是业务员提出
距离 原来一年大家在一个办公室 后来IT部和业务部分，距离约1km
项目 旅游电子商务网站 包括前台和后台 这类网站重业务和用户体验 技术上没难度

最开始，使用的是Bug管理系统JIRA 用了约一年，基本上是推，业务人员不适应，最后我觉得反馈一个问题很烦琐，自己主动废弃了。

后来，使用Excel，当然这是为bug管理定制的Excel， 执行一个月就觉得不行，因为问题汇总、截图等不方便，简单问题这样汇报似乎也太累。

最后，使用Foxmail邮件 用得非常顺，特别是业务部和我们分开情况下。因为邮件有三个特性很受用：抄送人，延迟执行，贴图。
有些很小并且及时的问题，直接通过QQ完成。

反正，在我们这个小团队，最后一种方式，直到现在都觉得很适合我们。

其实，在Bug管理的背后，有一个非技术支撑：信任。我们的重点不在责任界定、责任追究等和权限有关的事情上，我们只关注目标：问题被及时发现、及时解决，以及解决过程中的低成本协作。

经验谈，受教了。 不过感觉楼主没有把经验的精髓说出来，就是经验所处于的情景。

LZ好厉害 呀， 思想可以融会贯通~~ 受教 了~~~

我觉得方法因人而异，因公司而异！目前我们是用excel来进行bug的跟踪和管理！
可能小团队用邮件来管理bug就足够了，但对bug的跟踪和开发人员的错误率不好掌控！

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


------------------------------
如果你的产品比较复杂，而且是需要在不断运营中改进的，你就特别需要track系统的任何改动（起因-经过-结果）。没有bug tracking和文档系统，日积月累下来你的系统就会变成没人可以维护了