主题：【继续讨论】软件业的人，工具和需求 -- 懒厨
家园 【继续讨论】软件业的人，工具和需求 顾非兄的这篇文章：格局决定结局，to java or not to java
还有风北客的这篇：回一个，有些说到点子上了
都是非常不错的，给埋在下面太可惜了，不如另开主题，大伙接着聊。
照例，先聊聊我的看法，算是抛砖
其一，工具就是工具，工具无法自动解决问题，软件开发，归根到底，就是要解决某个问题，例如OS就是要解决人机对话困难的问题，ERP就是要解决企业运作的问题。能否解决问题，关键在于人，是人解决问题，而非工具。
其二，愚以为，现代软件开发工具间的效率不存在数量级的差别，最多能够说某开发工具，在某方面，比另外的工具略微优胜。而这种优势，很容易被开发过程的其他因素掩盖，例如风北客说的需求分析。
其三，在大的项目里，为什么需求分析困难？愚以为有两个因素：
第一个是知识的管理和传播，我认为还是处于石器时代，大家有没有发现，要把某种知识，从老师的脑袋里传到学生的脑袋里，需要花很长的时间？同样，客户的业务知识，要传到程序员的脑袋里，也不是容易的事。要说难吧，也不那么难，客户也是人，不见得比程序员更聪明，他们会的知识，没有理由程序员学不会，为什么就这么难准确掌握需求呢？
这就带来了第二个因素，需求并非百分之百可测。客户往往不会知道百分之百自己的需求， 直到软件投入测试，使用，客户才会进一步了解自己的需求，而需求的一个小改动，很可能带来程序的大改动。
近期有没有可能大的突破呢？就是风北客说的银弹。我个人较为悲观，但附加一个条件，只要知识的管理和传播没有重大突破，软件开发的效率也不会有重大改进。
最后说点这几年的心得：既然软件开发是人的问题，人际关系变得重要，好的人际关系，往往使开发过程事半功倍。这里说的人际关系，不仅限于和客户的关系，和其他测试员，程序员，项目经理等等相关的人，搞好关系，对工作非常有帮助。
话说回来，能力同样重要，能力差，拖累项目进展的，往往被同事所鄙视，其他行业，不知道是否也是如此的？
本帖一共被 1 帖 引用 (帖内工具实现)家园 需求分析和需求式样 第一个是知识的管理和传播，我认为还是处于石器时代，大家有没有发现，要把某种知识，从老师的脑袋里传到学生的脑袋里，需要花很长的时间？同样，客户的业务知识，要传到程序员的脑袋里，也不是容易的事。------这对写需求分析和需求式样的人来说，正是工作的核心部分
家园 我刚出国的时候,就发觉这边找工和国内不太相同, 国内一般最重要的是你的教育背景(是否是名校毕业,有那一级别的学位等等),这边往往会问你c++到底用了多少年之类.国内更注意应试者的智力,国外更注意你以前的行业背景和EXPERIENCE.刚开始也很不理解,久了就觉得国外的做法更有道理.在真正的项目实施过程中,没有什么能够代替真正的EXPERIENCE.
家园 没错 我曾经犯过这样的错误，对一个各方面条件都很突出，非常聪明能干的人委以重任，但是却忽视了他没有任何工作经验这一条，项目差点被玩死。
家园 借这光来说个旧事-- 工具 过程 管理 话说当年某公司某部门市场形式一片大好，几个重点项目成绩都不错。通过推广统一技术平台之类的概念，客户叫好，内部也叫好。内部在老板看来，通过基础平台（工具）的推广，大幅度降低了人力成本，可以让一些刚毕业的菜鸟就承担主力开发任务，路子对头，老板大笔一挥，把部门化成了2块，做平台工具的，做项目实施的。概念对外吹嘘的很厉害，可谓业界知名。
但实际问题也不少。
首先平台技术不成熟，因为核心技术人员的能力问题，导致整个平台的架构从技术上来说是非常out和失败的，内部非常dirty，冗余东西太多。从当时的情况看，这个平台的使用，只是降低了一部分技术人员的门槛而已，但是这种短期利好，刺激的大部分人头脑发热，一个劲的热捧。
另外更要命的是，管理不行，特别是开发管理，核心技术人员，项目经理都不具备这方面的素质，而培训支持又跟不上，写到这可能有人说了，管理和技术平台有什么关系？在我看来，所谓的架构设计也好，平台设计也好，都不能脱离一个原则，就是技术是要依赖特定人去使用和实现的，如果开发工具设计的出发点不结合现实的开发管理需要去解决问题，随时做调整，那么这个工具肯定是千疮百孔，最后害死人。就如rational的工具，离开了rup，就可能什么都不是。
而这个项目，因为新手太多，负责人自身也从未有过开发，管理大项目的经验，在scm，测试，需求跟踪，开发人员组织等方面乱成一团，而其他的问题虽然更多，也都是次要的了。每次系统发布，都会出现货不对版的状况，客户头痛，开发人员头痛，架构人员不知道怎么处理。而平台的问题更是不断，开发出来的产品虽然开发过程很短，但是问题也同样多多，而这些问题都很难单纯依赖于那些菜鸟程序员进行解决。
表面上看起来这问题跟工具没有关系，只跟工具开发人员的水平有关，实际又如何？ 前面说了因为整个技术平台的核心开发人员本身不具备很好的软件开发管理的概念和经验，所以他们设计这个平台的时候，根本就没有考虑到这个东西怎么和开发管理整合， 甚至说他们自己在做东西的时候，都无法很好的完成开发管理控制（所以版本问题不断，bug不断）。而做为工具，因为他的使用者是开发人员，而不是最终用户，所以工具的设计者对开发管理和项目管理的认识和理解能力，是非常关键的。
项目越到后期，下面的抱怨也越多，经常有人跑来说，这个项目如果全面推广，会死人。这里再说句题外话，俺只所以不相信任何一个厂家的工具能真正解决问题也在于此，工具毕竟是工具，再好的工具要用的好，也需要能充分融入开发团队和项目开发管理过程，而这些东西，不是厂商可以提供通用解决方案的，还是要靠项目管理者和架构师去推动解决。
而俺（俺当时不直接管理这个部门）在拿到这个项目分析以后感觉，这个项目的管理不整顿不行了，一方面整顿项目开发管理，另外一方面，结合项目开发管理的过程对工具平台进行重构。这样顺利的话，2，3个月就可以走上正规，之所以这么有信心，是因为项目的情况，曾经和俺经手的某个项目非常类似，问题都是共同的，短期的阵痛以后就可以走上正路。
但是这个时候，部门空降了一位大牛，话说这位大牛，当年也曾经是俺的领导，有着相当丰富混战型项目经验，自身技术功底扎实。而这两年主要的工作中心已经完全转移到过程管理，并长期担任police部门总监。大牛一上任，发现开发过程控制太差，除了个别项目，基本看不下去，必须整顿。然后该牛就闭门一个多月，拿出来全套改进以后的过程管理方案，而且信誓旦旦要亲手上阵监督，一定要在1年内实现整个部门开发管理的正规化。
俺在拿到这个方案以后就开始晕倒了，为啥？ 过程是好的，但是必须考虑人员的现状和可执行性， 教条的照搬书本和以往经验，如果无实际的可执行性，还不如不改，增加开发人员负担。而且这样大规模的改动，远不如我那种先收拾重点项目，可行性验证得到通过以后，再推广其他项目的路子实际。另外其实俺一直有一个保留意见没敢直说的就是，大牛你这几年都去做paper police了，没直接管理一线项目，不了解实际情况。期间和大牛多次主动沟通，希望他能正视实际情况，但是大牛基本不予理会。
后面的故事就很简单了，俺靠边站，项目问题继续不断，大牛和其他领导整天发邮件提醒各项目负责人必须正视问题，就这么正视了1年，感叹号从1个加到了n个，以前该怎么样，还怎么样。俺曾经跟领导说过，好的过程必须考虑实际情况和可执行性，随时进行调整，时代不同了，不会您发一个要求，下面就自动全部给你拼命搞定，领导的回答就一堆乱码。
后来俺就跑路了，俺跑路一年以后再碰到以前同事，同事摇头说不行了。
这就是俺经历的一个工具和过程玩死公司的例子，本故事一丝虚构，请勿对号入座。
管理者在无能的时候，总是期盼使用什么万能的工具，过程来解决问题，真是悲哀。明明是人才培养出现了断层，就跑去弄什么开发平台来解决。 明明是scm做的不好，就责怪 vss或cvs不好用，等等等等。开发管理不行，就化时间去请顾问抄书订一大堆乱七八糟的法规出来。
家园 理工科思维 vs 文科思维 工具主义是西方现代文明的代表产物。 凡是人能做的事都会有人去尝试发明工具去代替，这种行为贯穿了自工业革命之后的整个西方史。 做为现代文明结晶的计算机工业其本身更是这种行为的最极端后果。
软件开发中工具主义不只限于编程，也不只限于电脑之间，人机，流程，规范等都是工具主义的引申。 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会乐于接受，原因么，呵呵，既然本质不是技术问题，又怎么可能真正得到解决.
家园 其实我倒是觉得和知识的管理传播的关系不是特别大 这方面总的来说，已经进步很多了，但是解决不了本质问题。每个时代的需求，总是会领先于技术的，而技术的进步又一再推动需求的发展，这种互相竞争的不可调和的关系，只会导致软件系统越来越庞大复杂，任何已知解都是针对过去时代的最佳解。
而我在看来软件系统（主要是应用系统）的本质，其实是人脑思维的一种延续，人脑如何假借电脑软件来完成一系列相关的社会活动，这种特质决定了软件的未来和人类的文明的发展一样无法准确预知。或者换句话说，在这种背景下，知识的有效传播管理也是无解的。而软件行业未来的较大的突破，我猜测会来自于对人脑思维模式和社会行为研究的突破，这会对未来软件行业的运作有比较大的改变，但是恐怕还是不能解决本质问题。各位河友可以记录一下我这个预言，50年以后记得我给上香。
如果本质问题真的解决了，我想软件行业的发展可能也就到头了。 在弗洛文气的小说天渊里面，人类文明经过漫长的发展，计算机系统已经成为文明生存的关键，而在舰队里，成千上万年积累下来的应用系统，已经导致整个系统已经复杂的没有办法再革新了，技术不会再进步发展，没有任何一个人可以再维护舰队的计算机系统，大量的程序员只做少量的修补工作，保持系统的正常运行。人类的文明基本也进入了修补阶段，不再进步了。
或者人类文明，有蛋白质文明进化到电子文明，或者其他类型物理文明以后，这个问题才能真正解决，就是所谓的人软合一了。
家园 此言甚善 而软件行业未来的较大的突破，我猜测会来自于对人脑思维模式和社会行为研究的突破，这会对未来软件行业的运作有比较大的改变，但是恐怕还是不能解决本质问题。