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

想想，为啥有时候图比语言能表述的更精准？

我举的例子其实来自于经验，在早期，我们曾经盲目相信过文档和建模工具可以有效的加强沟通和实现高效的协作分工，实践中发现，文档能否正确表述写作者的意图，更取决于阅读和写作者之间的沟通信任能力和阅读者本身的背景。比如，有些人习惯于细节的思考理解问题，有些人习惯行动解决，有些人习惯于看图，有些人因为和写作者的长期合作能非常清晰的理解意图，而有些人又可能因为自身的项目背景（比如以前项目的不同处理方式的差异）对理解产生了干扰，再者一个有经验的人和一个没经验的人，看同样的需求，得到东西也是不一样的。所以文档还是不能完全取代面对面的有效沟通。

举个中文的例子，因为断句不同，一句话都可以引起巨大的差异，更何况一篇文档了。

纯粹从理论上讲，最终有没有可能将一个复杂的描述，转化为N个简单而不含糊的描述呢？

我也有同感，最近几年的项目，我对文档越来越缺乏信心，经常碰到文档落后的问题。最可靠的办法，还是从旧源码倒推需求，再就是直接和用户沟通了，可恨的是用户也有出错的问题。

为啥工具使用往往适得其反，就是这个道理

文档更应该是一种copy，是对某个想法，某个阶段的snapshot，这样就不会存在同步的问题。

我现在用wiki+生成工具对付文档，还不错。

工具主义是西方现代文明的代表产物。 凡是人能做的事都会有人去尝试发明工具去代替，这种行为贯穿了自工业革命之后的整个西方史。 做为现代文明结晶的计算机工业其本身更是这种行为的最极端后果。

软件开发中工具主义不只限于编程，也不只限于电脑之间，人机，流程，规范等都是工具主义的引申。 ide,OO还是6sigma等针对不同目的的工具不过是无数类似尝试中的少数几个亮点，而自有现代工业以来将人际之间的对话规范化，商业行为的流程化，无一不是为工具取代做准备或进行中。从近代史看，大范围内的自动化，从生产线，超市，到online trading，从VB进化到Ruby，甚至外包到印度等，自简至繁，由易到难，在各行各业的各个方面，这个趋势只是个时间早晚的问题。 存在时机条件成熟与否的问题，但绝不存在该不该的问题。

需求的管理在现有条件下对人的伊赖很大，但任何对人的依赖就存在管理上的不确定性，自然其投入产出及任何后续的食物链上的环节都因此而存在不确定性。 这个矛盾将是阻碍软件工业进一步发展的主要因素。 现实的状况并不代表没有解决办法的尝试，比如对需求流程本身进行格式化，统一protocol，降低个人perception造成的影响，提高对需求定义的细节化等等都是比单纯加强人际关系效果好的地尝试，更重要的是其可验证性，可恒量性，是科学而不是玄学，这是其后面的最重要动力。

有互联网-年是人间十年一说，计算机业一年大概是差不多。 人类一预测上帝就发笑。 二十年前谁又能想到计算机在人们生活中能占到这么的比重，十年内计算机业会变成什么样恐怕也不是今天能看得出来的。今天人们发明language，尝试减低成本，提高易用度所经历的一些尝试，以前有过，今后还是会不断的出现，但是在64K内存不在成为阻碍后的今天，我们已看到有多少不可能成为了可能，那么以后如果量子计算机出现了呢，将会有多少今天的不可能能够成为可能？ 保持好奇心，生活在不断的surprise中是计算机从业者的最大乐趣. 以今天的困难对照今天工具的缺陷而得出工具永远不可能胜过人类自身的结论，可能会发现这一天的到来有可能是非常的快。

比较欣赏是Steve Jobs的这句话："Stay hungry, stay foolish."

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

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

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

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

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

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

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

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

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

看什么都是对的。

再读十年，觉得书上说的都是胡说八道。

再读十年，发现书上说得其实并没错。

层次不一样了。

经验积累也大致是这个路子。

当年读书的时候看到这个brook定理，随便记一下而已，反正已经几十年前的东西了。等工作了以后，这个神话还真是不变的真理，就是一堆人，不知道是没头脑还是为了市场宣传，一个劲的往上面撞。

对于有些开发人员来说，与人沟通的成本非常高——而且有些经验不是很够的开发人员的思维模式相对死板一些，不如把这块划出去，做事情更专注一些～

话说当年某公司某部门市场形式一片大好，几个重点项目成绩都不错。通过推广统一技术平台之类的概念，客户叫好，内部也叫好。内部在老板看来，通过基础平台（工具）的推广，大幅度降低了人力成本，可以让一些刚毕业的菜鸟就承担主力开发任务，路子对头，老板大笔一挥，把部门化成了2块，做平台工具的，做项目实施的。概念对外吹嘘的很厉害，可谓业界知名。

但实际问题也不少。

首先平台技术不成熟，因为核心技术人员的能力问题，导致整个平台的架构从技术上来说是非常out和失败的，内部非常dirty，冗余东西太多。从当时的情况看，这个平台的使用，只是降低了一部分技术人员的门槛而已，但是这种短期利好，刺激的大部分人头脑发热，一个劲的热捧。

另外更要命的是，管理不行，特别是开发管理，核心技术人员，项目经理都不具备这方面的素质，而培训支持又跟不上，写到这可能有人说了，管理和技术平台有什么关系？在我看来，所谓的架构设计也好，平台设计也好，都不能脱离一个原则，就是技术是要依赖特定人去使用和实现的，如果开发工具设计的出发点不结合现实的开发管理需要去解决问题，随时做调整，那么这个工具肯定是千疮百孔，最后害死人。就如rational的工具，离开了rup，就可能什么都不是。

而这个项目，因为新手太多，负责人自身也从未有过开发，管理大项目的经验，在scm，测试，需求跟踪，开发人员组织等方面乱成一团，而其他的问题虽然更多，也都是次要的了。每次系统发布，都会出现货不对版的状况，客户头痛，开发人员头痛，架构人员不知道怎么处理。而平台的问题更是不断，开发出来的产品虽然开发过程很短，但是问题也同样多多，而这些问题都很难单纯依赖于那些菜鸟程序员进行解决。

表面上看起来这问题跟工具没有关系，只跟工具开发人员的水平有关，实际又如何？ 前面说了因为整个技术平台的核心开发人员本身不具备很好的软件开发管理的概念和经验，所以他们设计这个平台的时候，根本就没有考虑到这个东西怎么和开发管理整合， 甚至说他们自己在做东西的时候，都无法很好的完成开发管理控制（所以版本问题不断，bug不断）。而做为工具，因为他的使用者是开发人员，而不是最终用户，所以工具的设计者对开发管理和项目管理的认识和理解能力，是非常关键的。

项目越到后期，下面的抱怨也越多，经常有人跑来说，这个项目如果全面推广，会死人。这里再说句题外话，俺只所以不相信任何一个厂家的工具能真正解决问题也在于此，工具毕竟是工具，再好的工具要用的好，也需要能充分融入开发团队和项目开发管理过程，而这些东西，不是厂商可以提供通用解决方案的，还是要靠项目管理者和架构师去推动解决。

而俺（俺当时不直接管理这个部门）在拿到这个项目分析以后感觉，这个项目的管理不整顿不行了，一方面整顿项目开发管理，另外一方面，结合项目开发管理的过程对工具平台进行重构。这样顺利的话，2，3个月就可以走上正规，之所以这么有信心，是因为项目的情况，曾经和俺经手的某个项目非常类似，问题都是共同的，短期的阵痛以后就可以走上正路。

但是这个时候，部门空降了一位大牛，话说这位大牛，当年也曾经是俺的领导，有着相当丰富混战型项目经验，自身技术功底扎实。而这两年主要的工作中心已经完全转移到过程管理，并长期担任police部门总监。大牛一上任，发现开发过程控制太差，除了个别项目，基本看不下去，必须整顿。然后该牛就闭门一个多月，拿出来全套改进以后的过程管理方案，而且信誓旦旦要亲手上阵监督，一定要在1年内实现整个部门开发管理的正规化。

俺在拿到这个方案以后就开始晕倒了，为啥？ 过程是好的，但是必须考虑人员的现状和可执行性， 教条的照搬书本和以往经验，如果无实际的可执行性，还不如不改，增加开发人员负担。而且这样大规模的改动，远不如我那种先收拾重点项目，可行性验证得到通过以后，再推广其他项目的路子实际。另外其实俺一直有一个保留意见没敢直说的就是，大牛你这几年都去做paper police了，没直接管理一线项目，不了解实际情况。期间和大牛多次主动沟通，希望他能正视实际情况，但是大牛基本不予理会。

后面的故事就很简单了，俺靠边站，项目问题继续不断，大牛和其他领导整天发邮件提醒各项目负责人必须正视问题，就这么正视了1年，感叹号从1个加到了n个，以前该怎么样，还怎么样。俺曾经跟领导说过，好的过程必须考虑实际情况和可执行性，随时进行调整，时代不同了，不会您发一个要求，下面就自动全部给你拼命搞定，领导的回答就一堆乱码。

后来俺就跑路了，俺跑路一年以后再碰到以前同事，同事摇头说不行了。

这就是俺经历的一个工具和过程玩死公司的例子，本故事一丝虚构，请勿对号入座。

管理者在无能的时候，总是期盼使用什么万能的工具，过程来解决问题，真是悲哀。明明是人才培养出现了断层，就跑去弄什么开发平台来解决。 明明是scm做的不好，就责怪 vss或cvs不好用，等等等等。开发管理不行，就化时间去请顾问抄书订一大堆乱七八糟的法规出来。

国内一般最重要的是你的教育背景(是否是名校毕业,有那一级别的学位等等),这边往往会问你c++到底用了多少年之类.国内更注意应试者的智力,国外更注意你以前的行业背景和EXPERIENCE.刚开始也很不理解,久了就觉得国外的做法更有道理.在真正的项目实施过程中,没有什么能够代替真正的EXPERIENCE.