【继续讨论】软件业的人，工具和需求 5
顾非兄的这篇文章：格局决定结局，to java or not to java

还有风北客的这篇：回一个，有些说到点子上了

都是非常不错的，给埋在下面太可惜了，不如另开主题，大伙接着聊。

照例，先聊聊我的看法，算是抛砖

其一，工具就是工具，工具无法自动解决问题，软件开发，归根到底，就是要解决某个问题，例如OS就是要解决人机对话困难的问题，ERP就是要解决企业运作的问题。能否解决问题，关键在于人，是人解决问题，而非工具。

其二，愚以为，现代软件开发工具间的效率不存在数量级的差别，最多能够说某开发工具，在某方面，比另外的工具略微优胜。而这种优势，很容易被开发过程的其他因素掩盖，例如风北客说的需求分析。

其三，在大的项目里，为什么需求分析困难？愚以为有两个因素：

第一个是知识的管理和传播，我认为还是处于石器时代，大家有没有发现，要把某种知识，从老师的脑袋里传到学生的脑袋里，需要花很长的时间？同样，客户的业务知识，要传到程序员的脑袋里，也不是容易的事。要说难吧，也不那么难，客户也是人，不见得比程序员更聪明，他们会的知识，没有理由程序员学不会，为什么就这么难准确掌握需求呢？

这就带来了第二个因素，需求并非百分之百可测。客户往往不会知道百分之百自己的需求，　直到软件投入测试，使用，客户才会进一步了解自己的需求，而需求的一个小改动，很可能带来程序的大改动。

近期有没有可能大的突破呢？就是风北客说的银弹。我个人较为悲观，但附加一个条件，只要知识的管理和传播没有重大突破，软件开发的效率也不会有重大改进。

最后说点这几年的心得：既然软件开发是人的问题，人际关系变得重要，好的人际关系，往往使开发过程事半功倍。这里说的人际关系，不仅限于和客户的关系，和其他测试员，程序员，项目经理等等相关的人，搞好关系，对工作非常有帮助。

话说回来，能力同样重要，能力差，拖累项目进展的，往往被同事所鄙视，其他行业，不知道是否也是如此的？

看看我的一些想法
Knowledge development 1
Knowledge development 2
里面的一些观点的论证阐释没有贴出来。
关键词(Tags): knowledge development

偶们的组织里有这样一个角色
Title是Product Manager（产品经理），这个角色的主要工作之一就是分析用户的需求并传达给开发人员，基本流程如下：

【形成概念】：主要是和提出需求的任（客户或用户）及其他相关人员沟通，形成基本概念；
↓
【基础规划】：偶们是做Web项目的（网站为主），所以就写一份DOC（或PPT）出来，写个大致的规划（网站的结构、主要功能），与提出需求的人确认，并进行调整，这个步骤主要是明确目标；
↓
【基础沟通】：找设计和开发的负责人，讲解规划，确认目标，这里主要是定一个基本的实施计划，并一定程度的细化需求（要做什么，不要做什么）；
↓
【制定计划】：由设计和开发的负责人分配任务，并（安排）制定相应计划，再由PM进行整合，并与提出需求的人确认；
↓
【需求文档】：由产品人员撰写需求文档，完成后提交给设计和开发的负责人；
↓
【项目跟进】：PM会一定程度的跟进项目的进程，比如说向设计/开发人员解释需求、根据实际情况调整需求细节、决定取舍等；
……
……

上面是比较简单的流程，大致意思就是在设计开发人员和客户（或用户）之间增加一个环节，有一定“润滑”的作用——实际上根据不同的组织，对PM的定义也不同，如偶，还需要做运营的分析，还需要做网页，还需要……>_<
关键词(Tags): Product Manager 产品经理 流程
最后于2007-02-14 00:48:37改,共1次;

del
del

最后于2007-02-14 06:03:28改,共1次;

在很多组织里这个角色就是project M
不承担开发工作，项目管理工作其实也不多，主要是由开发经理或者架构师负责。简单的说就是2个经理，一对外，一个对内。道理是技术人员更容易被技术人员管理，客户更容易和非技术人员沟通。

您做的是通用软件吧？
Product Manager（产品经理）这个角色，大多都是卖通用软件的公司里才设置的。

服务型的软件公司，软件大多是专用的，似乎就很罕见有这个职位了。

好端端的，怎么给删了？
唉，兄台怎么把国内的经营环境描述得如此凶险，诚信可是所有交易的最基本的要求呀。

说两句澳洲这边的状况。澳洲本土也有服务型的软件公司，还是上市的。他们的生意是这样做的，譬如说，有些企业要开发软件，自己人手不足，或者经验不够，就去找这种公司，这公司先报价，报时间，接着签合同。

合作的方式也很灵活，可以整个项目外包，也可以由这公司提供相关人员，企业的项目缺什么人，这公司就派什么人过来，价钱就按人头来算。

一般来说，付款期都是每两星期或者每个月，比较无良的雇主，可能会拖两三个月，这种情况很罕见。但象您说的，先交货，再付款，无法想象，不会有人接这种生意的。

当然了，这种生意也不容易做，合同要签得很小心，项目无法按时完成，派出的开发人员无能，也有很多争执的。还有就是，有时确实没有项目开工，要养着不少人，开支也是很大的。

因为突然想起了里面有些事比较敏感 1
某人可以根据相关信息抓到我，呵呵。
这些soho的东西，一般都是小公司为了节约成本，或者又是一些有背景但是没有技术能力的小公司或个人转包出来的，所以里面存在相当的变数，而我接手的，一般都是相当熟悉的人找到的转包单，即便签订了服务合同，拖款也不好意思催的太紧，这次我就估计他们是因为过年资金紧张就拖欠我的了。以前也碰到过项目都做完了，中间人那边又说不要了，一分钱都没拿到的情况。所以吸取经验教训，就算再好的朋友，以后的项目没有预付款一律不做了，另外对于转接外包的项目，能不做就尽量不做了，绕了几圈，都是空手套白狼的主，即便不考虑付款，因为沟通困难做起来也很辛苦。而接国外的单，或正规外企的付款，相对来说就比较好一点。 其实不要说我个人了，圈子里面很多中小公司，就是因为项目付款的问题，倒闭的，为数不少。做政府项目的时候特别突出，虽然政府项目可以保证拿到钱，但是超过一定标准的项目付款要启动验收支付流程，至少交货半年以后才能拿到余款，这半年，对于有些公司已经可以倒闭了。还有不少项目，因为自以为客户关系牢固而由开发商先期自行投入，到了快完工的时候， 客户人事关系变动，血本无归的也不少。
现在说it业都是民工是很有道理的，不过民工拖欠工资，政府和舆论还要照顾一下。我同行里，拖欠是很普遍的。以前公司在挽留离职员工的时候总是说，别的公司给的多一些，但是你能保证他一定兑现么？他一定不会拖欠么，俺们公司可是从来没不拖欠员工工资的哦，你看连这都是美德了。

有没有看过death march
其实就现在的趋势来说，专用和通用产品的界限会越来与弱，大部分公司都会走向通用产品+定制服务的模式。

最后于2007-02-14 20:57:21改,共1次;

其实我倒是觉得和知识的管理传播的关系不是特别大 1
这方面总的来说，已经进步很多了，但是解决不了本质问题。每个时代的需求，总是会领先于技术的，而技术的进步又一再推动需求的发展，这种互相竞争的不可调和的关系，只会导致软件系统越来越庞大复杂，任何已知解都是针对过去时代的最佳解。
而我在看来软件系统（主要是应用系统）的本质，其实是人脑思维的一种延续，人脑如何假借电脑软件来完成一系列相关的社会活动，这种特质决定了软件的未来和人类的文明的发展一样无法准确预知。或者换句话说，在这种背景下，知识的有效传播管理也是无解的。而软件行业未来的较大的突破，我猜测会来自于对人脑思维模式和社会行为研究的突破，这会对未来软件行业的运作有比较大的改变，但是恐怕还是不能解决本质问题。各位河友可以记录一下我这个预言，50年以后记得我给上香。

如果本质问题真的解决了，我想软件行业的发展可能也就到头了。 在弗洛文气的小说天渊里面，人类文明经过漫长的发展，计算机系统已经成为文明生存的关键，而在舰队里，成千上万年积累下来的应用系统，已经导致整个系统已经复杂的没有办法再革新了，技术不会再进步发展，没有任何一个人可以再维护舰队的计算机系统，大量的程序员只做少量的修补工作，保持系统的正常运行。人类的文明基本也进入了修补阶段，不再进步了。

或者人类文明，有蛋白质文明进化到电子文明，或者其他类型物理文明以后，这个问题才能真正解决，就是所谓的人软合一了。

呵呵，异曲同工嘛


社会行为不好说，但和软件开发的关系大概仅限于团队合作管理方面。人脑思维模式搞清楚了，知识的管理和传播也就不在话下了。

人脑思维模式有没有可能突破呢？我还是比较悲观，人工智能搞了那么多年了，有什么成果没有？

我的问题是，在没有弄清人脑思维模式的情况下，知识的管理和传播有无可能有什么突破呢？

不很明白一个事情
国内为什么不分阶段付款呢？项目总是分阶段的吧，把阶段分得细一点，按阶段收钱，天公地道。

雇主也短视，把开发商逼死了，后续的维护成本也高吧？

呵呵，国内的事情，太多让人费解。

就最后这个结论还同工呀 4
1.社会行为是必然的一部分，这是因为人是社会动物，软件作为人的思维的一种延续，本质上就带有社会行为性，比如现在的什么协同，说到底还是人类的社会行为的映射。这不单单是团队管理的问题，实际决定了软件内外部的行为模式，是个体和团体的差别。

我们为什么说oo好？因为o更接近我们现实中人的思维模式，为什么说oo复杂，在oo中，复杂的都是处理对象见的关系，这就是行为模式。

2. 在人脑思维模式研究没有突破的前提下，知识管理只可能是一种低水平的解，解决不了日益复杂的需求和技术问题。还是那句话，所谓的解决方法都只是对过去的最优解。而在思维模式研究得到突破以后，知识管理这个命题很可能就不存在了，或者以其他更符合的做法去处理了，毕竟这是在以一种简单的模式去描述高阶复杂模型的做法，相当的不合理。

即便在现行阶段，我也不认为知识管理是解决软件危机的一个有效或者比较有效的路子，因为软件gap的核心是如何准确实现期盼需求和实现之见的高效转换，而我们面临的需求千千万，技术人员千千万，不可能有银弹性质的知识管理工具能解决这种日益复杂的差异化。 举一个土一点的例子，一份设计文档，5个人看完以后可能会产生3种以上截然相反的看法。而这往往不取决于文档编写者的水平和文档编写的详细程度，更依赖是阅读者自身的背景和对设计者的熟悉程序。这么简单的东西都会有这么大的问题，软件的复杂的根基在于人脑思维模式的复杂和随意星，你又怎么弄出一个可以脱离人脑思维及行为模式存在的高效知识管理工具？

或者我们换个方式说，你怎么能在不理解人脑怎么运作的前提下，奢望用电脑来模拟人脑？

你脱光了衣服，找一个野地里好好感受一下，体验一下我们祖先的大脑怎么引导我们从不穿衣服到用电脑来工作的过程，如果能相通了，你就有解了。

最后于2007-02-14 20:46:50改,共1次;

嗯，确实是分阶段的
但是即便分阶段，这个风险还是很高，因为利润层层转包和盘剥以后，已经很低了。

这个难度太大


估计这么做，也还是想不通，赤条条的行为艺术，还是免了。

我自己也一直怀疑，在人脑思维模式研究没有突破的前提下，知识管理也没有可能有重大突破，只是无法证实罢了。

您举的文档例子有趣，为什么5个人看完，会有3种不同的见解呢？是人脑的问题，还是语言的问题？假如文档只是一个简单如2+2=4的描述，为什么5个人的见解又都会一样呢？

至于这一句：你怎么能在不理解人脑怎么运作的前提下，奢望用电脑来模拟人脑？

好象业界是有争论的。

两者都有关吧，如果都是2+2=4的表述，还有什么软件 2
想想，为啥有时候图比语言能表述的更精准？

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

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

赞同这一点。

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

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