主题：【继续讨论】软件业的人，工具和需求 -- 懒厨

如果工具能解决问题，银弹早就出来了。

对于你的论断，我是相当不同意的，在很多年前我也曾经相当盲目的相信工具可以解决问题，相信工具和你所谓的引申的工具，相信软件开发过程，相信文档。最后还是那句话，所有解都是过去问题的最佳解和部分解而已。

软件开发，本质不是一个可以工业化，流水化解决的问题。牛x如微软，不一样整天跳票，bug一堆？

“比如对需求流程本身进行格式化，统一protocol，降低个人perception造成的影响，提高对需求定义的细节化等等都是比单纯加强人际关系效果好的地尝试”

你说到底，还是希望通过特定的过程和方法论来解决问题，这个和我当年在做cmm的时候，印度顾问的说法如出一则，但是实际是另外一回事，当初我曾经拿我做的东西去问他，他最后承认，我做的已经非常好，而他确实没有办法解决我的问题。cmm的很多概念就是假定不变，但实际事务变化的能力，往往超过你指望单纯通过一个什么模型规范可以控制的能力。简单的说，需求的获取，可以有相当的规范性质的技巧，但是只指望通过这个可以解决问题的话，就太幼稚了，用户在变化，需求在变化，技术在变化，开发人员在变化，要什么样的牛人才能总结出一套放之四海都可行的“格式化”“标准化”的东西？

我的感觉里只有paper police才应该相信工具，文档胜过一切。

我个人怀疑你现在已经不在开发第一线工作了，而且如果我没猜测错的话，你在开发一线(编写代码，承担设计)的时间不会超过5年，而且并没有深刻的死亡项目的体验，纯粹个人感觉，没什么其他意思。工具是重要的，单不是冲要条件，有了正确的思想，可以创造工具来解决问题，否则什么样的工具都没用。工具是解决问题思路的一个实现，工具主义的真正含义是一种思考，解决问题的方式。所以别指望单一的工具，过程什么的，能解决所有问题。

如果你确实已经不在开发一线工作了，那么我觉得这类讨论的意义其实已经不大，见谅。

在我的经验里，工具问题往往是pm和管理人员的一个逃避责任的有力借口。缺少好的工具，对技术不熟悉，这些客观的貌似不容易改变的托词都是解释管理人员无能的一个很标准的说法。我在咨询某些项目的时候，曾经向管理人员提过很多可行的解决这些问题的办法，很少有pm会乐于接受，原因么，呵呵，既然本质不是技术问题，又怎么可能真正得到解决.