本来这篇想和大家聊聊设计报告的事情，写着写着，就扯到在解决问题时候，该如何选择方法的思考，算了，就把关于设计报告部分的内容放到下一章聊，这章我们就谈谈管理方法论的问题。
在管理方面，方法这个词，我觉得还是要做一些说明是很有必要的，不然在套用的时候，会发生一些不可预料的麻烦事，这是大家都不愿意看到的场景，好心办坏事。
在具体方法使用上，我觉得2点要讲明白。
首先，个人觉得是需要有环境来支撑的，从混在公司的角度上看，我还是比较喜欢待在有实行开发体制的公司，如实行ISO或者CMMI这类体制，无它，因为职责很明确，流程很清晰。想混生活的人，只要重复的做职责内的事情即可。想混经验的，就找办法来尝试不同角色做积累。想做成就的，就在体制内引入新的方法来改进某个环节的效率或成本。想升职的，就好好及时汇报沟通，巴结上级。在这个体制下，各取所需，如果处理的好，大家合作起来比较愉快，不要在责任上有太多的扯皮。
在大部分环境下，方法是为体制而生存的，体制意味着统一，在公司层面上，就是严格的制度和流程，到项目组层面上，就是意识的统一。我很佩服那些精英团队，他们甚至可以忽略体制，使用非常有效的方法来做出不可思议的伟大的产品，团队成员目标统一，思想统一，也乐于尝试。但是在很多公司里面情况又是如何？项目组的成员并不都是由项目经理来决定的。这里面的人思想多多，刺头多多，曾经我也是这样一个刺头角色，在一家公司待了很多年，做混子做了很久，资历深，对于那些没有制度支持，没有事先充分沟通下的管理方法，我第一个就会跳出来反对，先不谈它是否好坏，只因它影响我混日子的习惯，如果是作为一个制度规定下来，虽然我会发牢骚，但是我会去执行，会去调整，也是因为我需要继续混下去的利益驱使，成为新的习惯。
我想，在项目经理执行一个管理方法，需要更多的时间花在宣讲和平衡上。
其次，管理方法的效果是和应用场景有密切相关的，是在受到老板的想法，企业文化、公司制度、公司客户的业务领域、领导风格、项目成员素质等等条件影响下的特殊使用，是讲究场景和条件的。就说说需求跟踪表，只有在产品发布给客户后，以及后续的需求非常多的情况下才适用，在以前有大量需求的公司执行的效果非常好，换了公司，我想执行这个方法，但是我失败了，原因就是部门做的产品使用客户少，每年的需求更少，跟踪表谁也不想做，在形同虚设的ISO和CMMI体制下，项目经理觉得是增加额外工作量，宁愿在老板需要工作量报告，或者销售需要向客户讨费用的情况下，在那里想这几个月项目组都做了哪些需求，花了多少工作量，运气好的，都能想的起来，运气差点就随便估个数，反正好坏对项目组影响也不大。
以上2点，我只是在描述具体的管理方法不是一种放之四海而皆准的解决之道，它是有条件的，我个人认为ISO和CMMI都代表的是体制，是标准。在我看来类似敏捷就是一个方法论的问题，是在特定场景，特定条件下，解决问题的思路。就好像我们做ISO，如果看标准文档会觉得非常的好，但是实际操作的时候，就会感觉很别扭，这就是理论到实操还有些距离，需要一些方法论来解决这些在实际场景实际操作的问题。有个专家给我讲了一个印象很深故事：
肥皂盒装肥皂生产流程的如何解决出现空盒子故障问题：
某大公司巨资引进了一条香皂包装生产线，结果发现这条生产线有个缺陷：常常会有盒子里没 装入香皂。于是他们只好请了一个学自动化的博士后设计一个方案来分拣空的香皂盒。博士后拉起了一个十几人的科研攻关小组，综合采用了机械、微电子、自动化、X射线探测等技术，花了百十来万，终于成功解决了问题。每当生产线上有空香皂盒通过，两旁的探测器会检测到，并且驱动一只机械手把空皂盒推走。而中国南方有个乡镇企业也买了同样的生产线，老板发现这个问题后大为光火，找了个小工来说你他妈的给我把这个搞定。没两天小工果然想出了办法：他在生产线旁边放了台风扇猛吹，空皂盒自然会被吹走——几十块钱就把问题解决掉！
在这个小例子中，生产线就好像是ISO，是标准，是体制。探测器和风扇就好像是敏捷，是解决具体问题的方法论，都很好，能在特定环境下起到很大的作用。不能说探测器不好，如果在一个大工厂的生产线上摆了一排风扇，你觉得好看吗？至少外行人说层次太低，不够专业，不够现代。小公司有小公司的做法，大公司有大公司的做法。只要做的顺畅就行。
总体而言，我比较倾向于先体制，后具体方法。
从我个人经历来讲，一直都是混在福州这样二线城市里面，而且一直做MIS的，没有到北京、上海这类大城市，大公司混过，受经历、视野所限，所以我写完感觉有点乱，已经有思想准备，等着挨砖：）
