了解编程的心理 谈谈软件项目管理的重要性 (转)

关键词： 了解编程的心理    谈谈软件项目管理的重要性    (转)                                          

了解编程的心理

原著：Bryan Dollery
编译：Jenny Chen

原文出处：Understanding the Psychology of Programming

　　与众所周知相反，程序员更多地象艺术家而不是科学家。 如果你想最大限度地调动团队的创造潜力，你必须开始研究程序员的心理，而且愿意用管理策略支持它。
　　人们常说，程序员很内向，我发现这不是事实。通常情况下，程序员确实比多数人能保持较长的注意力和集中力。一个程序员能花长时间集中精力解决单项任务而不顾其他，这就让一些人认为其有自闭特征，有人甚至认为大多数程序员都有轻微孤独症。我不认为大多数程序员有自闭取向，果真要是这样，我们的注意力就太容易破碎了。
　　编写程序是一个创作的行为，尽管程序员乐意在尽可能的情况下把科学和工程应用到这过程中，但编程既不是科学，也不是工程，因此一名程序员必须具备很高的创造力。这就是为什么程序员喜欢新项目的开发，而不是对旧项目的维护。这并不表明他们不想卷入过去陈旧的东西(尽管是编程的一部分)，而是项目维护并不为程序员提供创造的机会。

"为了原创点子能出现，你必须让它们在内心世界里渗透，让它们在那里不受我们自己的愿望和自己的方针所约束。"
——Mihaly Csikszentmihalyi，Researcher

　　当有创造力的人做事的时候，他们经常进入一种精神状态，让创作的思路源源不断。这是很高的思想境界，非常有利于本人和他所在的研发机构。
　　著名的心理学家，芝加哥大学心理系的前主任，Mihaly Csikszentmihalyi 教授就创造力的问题，已经对几百个典型个人进行过研究，其中包括诺贝尔奖获得者和 IT 企业家，就此他也写了许多有关思路和创造力的书和论文。
　　Csikszentmihalyi说：“为了原创点子能出现，你必须让它们在内心世界里渗透，让它们在那里不受我们自己的愿望和自己的方针所约束。然后通过一些未知的，随机组合力量的推动，而让它们出现。正是经过这种重新组合，而不是人为的直接推动，新生事物才会涌现。”
　　思路是脆弱的，是需要时间来实现的。如果程序员的思路被干扰，那是需要很多的时间去重新进入状态。就是一个小时，也让你的工作整体失去一个小时的生产率。如果一天中程序员的工作被干扰多次，或许他就根本再也无法进入工作状态，没有工作的状态，创造力会是残缺的。
　　思路是易脆的，但也并非如表现的那样脆弱。只有那些让程序员改变思维方式的干扰才能打断思路。就是说你可以拍肩膀和程序员打招呼，询问他们在忙什么，甚至建议点什么，都是没有问题的。但是如果你问他们的进度，那么你就干扰了他们的思路。我已经几次从经验丰富的协作程序员那里听说这样的事例。他们应该知道：如果思路超过了它自身的脆弱性的话，那协作编程是不可能的。思路是某种依赖前后关系的状态，只要他们都在这种状态中，你便可以主观操纵去完成不同的任务。如离开这样的状态，那会需要相当时间来重新建立它。

创造思路，…对，思路
　　那么你怎样才能为开发团队最大限度的调动这神奇的力量? 方法再简单不过了：从精神上和时间上给思路的酝酿提供适当的绝缘环境，同时灵活对待个体在工作中所选择的奇异行为。

1. 提供适当的精神空间
   　　当程序员被安排去做任何具有创造性的工作时，应该容许他们不受非理性干扰地去完成任务。保证不让他们参加不必要的会议，不安排辅助性的任务。尽力去安排好这一切，让他身边的其他程序员也尽量做同样的工作。如果那样不可能的话，就让程序员拥有他自己的工作间。
2. 提供足够的时间恢复创造活力
   　　如果你希望你的程序员重复过去所犯的错误，那么你就象训狗一样不给时间休息；如果你想让他们有所创新，你应该让他们休息好。
3. 满足合理的特殊要求
   　　在 Csikszentmihalyi 的研究中提到这样一个案例，一个著名的计算机研究员，他说在计算机的很多领域，其所有好的发明创造思路都来自淋浴的时候。他说他相信，他的公司因为没有安装仅1400美元的淋浴装备，就让公司损失了几百万。Csikszentmihalyi写道：“当他换到新的有淋浴的公司，他的点子就层出不穷。”
   　　我并不是说你要为程序员提供新的淋浴设施 (至少不是所有的)，但是你应该停止象对待插头那样一视同仁地对待他们。他们是独立的个体，很多方面都是不同的，每每都有自己的规律和表现形式。大多数人都知道怎样找到自己的思路，这才是你需要关注的。
   　　如果一个程序员告诉你，他每天在下午2点的时候需要15分钟的休息，你就提供这个方便吧；这仅仅是放张沙发在咖啡间或者休息间。（你有休息间，不是吗?）
   　　或者这样：与其给整个团队配备相同的椅子和桌子，为什么不将预算派发给每个程序员，让他们自己去买他们自己的椅子和桌子? 办公室虽然看上去不太整齐，但提供了让每个程序员都感觉舒适的环境，那样可以激发他们的工作热情。

　　我知道你会争辩；要考虑费用问题！如果你要把这个问题放在首位，那么你就根本没有明白本文的整个主题。你要从头开始阅读本文，这次要集中注意力。

如果你不能调动人的积极性，那么你怎么能做好你的项目?

　　如果你雇佣图像设计师，帮你创造一个甜眼图在你的网页上，你或许为他们提供合适的工具，工作地点和宽松的条件促进他创作。你宽容他们的个性，为他们买透明的计算机。如果你不考虑程序员的需要，那么你就很难发挥他们的长处而得到你应该得到的。
　　我们的任务增强人的聪明才智，充分雇佣多样化的人才，取长补短。你应该尽力促使你所管理或与其合作的所有人做到最好——如果你不能调动人的积极性，那 么你怎么能做好你的项目?
　　这样做是否需要你花费更多的钱，我没有具体的数据，但潜在的好处是巨大的。如果你继续太在意风险／效益的东西，那么你将继续生产平庸的产品。你的软件是人来做的，了解人的心理是很有好处的。

评论：

这篇文章看了也没用呀，除非我以后当老板，如果你把这篇文章发给老板，那么他就会受不了，认为你在挑公司毛病，最重要的是把你自己的工作做好，本来印象不错，一下全毁了！我现在的公司软件开发也不正规，找了一个就会理论的傻X人，开发经验还没3年呢，软件工程中的名词就会了不知多少了，天天标准呀等名词，屁！ ( hexiyajin 发表于 2005-2-22 10:02:00)

谈谈软件项目管理的重要性
作者:马云冬(xacn)

随着中国加入WTO后，外界对中国的软件业带来了机遇和挑战；为新新的软件行业注入新的活力。但细细一想，其实所带来的更多的是挑战。我所说的挑战不单只是个人开发中的水平问题，更多的是我国软件项目管理的问题。下面我就几个方面来谈谈。

一、开发人员问题：

1、你开发中按软件工程做了吗？

软件工程，这对软件开发员来说是多么熟悉的字眼，但其中的内涵你又知道多少? 再进一步说，在开发中按软件工程来做的又有多少? 大家常在网上听到一些程序员在抱怨说：“我加班加点地写了10万行的代码，所以老板把我给开除了。”这话扎听有点好笑，但细细一想这是他的悲哀。他写的代码虽多，可是关键的又有多少。如果里面的代码只要有80%的是关键的，我想老板是决对不会开除他的。问题出在10万行代码中有多少是关键的。先不说写这10万行代码所花的时间了，就说以后的维护问题，要是你到一个公司，老板首先要求你看完这10万行代码。我想你第一想到就是走人，第二想到的还是走人。因为对于一个没有按软件工程来进行开发的程序，不要说是这么多的代码；那怕是几十行、几百行，读起来也是很难受的事。记得我刚到深圳找工作，老板让我接手另一个程序员所开发的一个小系统。这样理所当然的就是看设计文档，可是没有，这样只有看源程序；当我打开源程序时，我呆了。看了一天代码，我决定走人。当我向BOOS提出时，老板给我做思想工作。当然加薪也是少不了的，这也打破加薪的记录了。所以我就留下了。之后我开始看代码。在我看代码的同时真不知道把写这程序的程序员骂了不知道多少次。这让我更加增强了对软件工程的认识。为了不让以后继我的程序员不骂或少骂我。所以得好好按规定《软件工程》办事。说这些只是想让大家静下来想想，你在开发中按软件工程做了吗？

2、你是先写文档再写程序的吗？

一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。在文档的指导下，这样写出来的程序至少不会出现写了10万的代码还被老板开除的情况。如果你不写文档，一开始就写程序，这样你就不会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，你想想等你写下一个时，回过头来看原来写的，你早就不知所云了，那时你就觉得好像在云里雾里乱走，修改的代码也就更不安全了。我所说写文档不是说很正规的，那怕你只用一张搞纸划上几画也要画点出来（这是对小功能来说的）。对于大的程序来说，你就必须正规的写了。因为这样才能详细的记下你的设计思想，如果开发一段时间后，感觉须要对一些功能进行修改或变态时，记住别删除原来的，而是在下面进行变更说明。这样再次看文档时你就会更清楚为什么要这么做的原因。一看就明白不是多好。总比你去再想以前的设计花的时间要少，如果删除原来的设计思想，当你再次看修改或变动的功能时，你可能会对其不理解。这是多么可怕的事呀！我想作为程序员应该知道文档的重要性。可是在一些小公司，先写文档后写程序的开发员又有多少。要成为一个好的程序员大家想想自己该怎么做的吧！

二、软件项目管理问题：

1、现代的软件开发，技术不是关键：

随着日益增长的软件需求和软件系统功能的增强，过去一个人开发的历史已不复存在。现在单枪匹马写程序也只是一种娱乐。我们一般开发的系统都是一个小组才能完成的。所以管理才是开发出好的软件的前提条件，没有管理一定出不来好的软件，当然有管理也不一定出软件的。一个成功的软件不一定是最好的技术，但在它背后一定有一个好的管理。所以现在的软件开发已不像从前把技术放在第一，而是该把管理放在第一位。我在网上看到一篇关于中国软件和印度软件的比较。我现在记的不是太多，但对我影响最深的是他们会去权衡技术和开发效率问题。如现在开发一个软件，用户要求在三个月内完成，你在做系统分析时也认为在三个月能完成。但你没有考虑到一些细节，你写完系统的总体设计，在进行详细设计时碰到要建一张不是太大的路由表。这时大多数国内的设计人员就会想用什么算法，去花很多时间去设计研究新的算法和技术，而人家首先考虑的是系统的运行环境，而这个软件设计了是在（CPU：1.1G，内存：512M）中运行，用户也没特意提出其运行效率要求。所以人家就在内存中开一个大数组来对这个路由表进行操作。从这点看，人家注重的是软件的整体，而不像国内大多数据设计员那样，把个体放在首位。其实这方面我觉得我们的开发员应当多向共产党学习（本人不是共产党员，团员也因没交团费被Cancel掉了）。把软件设计的整体放在首位，而不去花太多的时间在不一定成功的技术上。如果花太多的时间在技术上去，这将对系统的按时完成带来影响。我也不是说不该研究技术，我只是说开发中应当以全局为重。如果要加入新的技术，必须在分析时就预算其所需要的时间，并设置技术风险管理。如果风险太大就应当取消用这项技术，改用其它的已成功的技术代替。风险管理这是近来才提出的软件管理方法。它对我们的软件项目有着很好的控制作用。对于一些中、大型系统，它是一把走进成功之门的钥匙。这里就不谈了，我将在下面进行说明。

2、好的管理才能开发出好的软件（小系统除外）：

大家都知道，软件开发中有太多的不可预知性。但这种不可预知是对总体来说的，当软件进行到一点程度时，不可预知的东西就会变成可预知的东西。以往的做法是不去管理它，这样所带来的就是项目的失败。要是有好的管理方法就可以控制这些不可预知的东西，软件项目就会一步步随着你的设计思路起向成功。现在就和大家一起讨论一些常用的软件管理方法。

1）错误管理：

小时候当我做错事的时候，我父亲总是把我叫到他身边，对我说：“没事，只要下次不做相同的错事就行了。”这话也许很多家长都对自己的小孩这么讲过。小时还不觉得，慢慢长大后，会发觉其中深刻的道理。这就是说从错误中吸取经验教训。软件项目开发中的错误也是一样。软件开发是一项复杂的活动。一个典型的软件开发项目可能会给我们提供很多的机会去从错误中吸取经验教训。一般的软件项目也会提供少量的错误给我们学习。学过开车的人都知道，教练老是会这么讲：“我希望你们从我身上学习我和前人的的经验，这些经验你们就不要再去试了。如果要试你也许会赔上钱甚至于生命。”虽然软件项目开发不会赔上生命，但是失败的软件项目是一定会赔钱的。所是在软件开发中少不了要对错误进行管理。在项目的错误管理中我一般是这么做的，现在和大家讨论一下：

a、 列出典型错误：

典型错误中有人员方面的。如：对有问题的员工失控、挫伤积极性、人员素质低、英雄主义、项目后期加入人员、开发人员与客户之间发生摩擦、不现实的预期、缺乏有效的项目支持、缺乏各种角色的齐心协力、政治高于物质、充满想象等…

典型错误中有过程方面的。如：过于乐观的计划、缺乏足够的风险管理、缺乏计划、在压力下放弃计划、在模糊的项目前期浪费时间、前期活动不合要求、缺少管理控制、缺少质量保证措施、鲁莽编码等…

典型错误中有技术方面的。如：过高估计了新技术或方法带来的节省量、项目中间切换工具、缺乏自动的源代码控制手段等…

b、 列出自己的最差实践：

注意典型错误，建立自己的最差实践列表，可以避免在以后的项目中犯同样的错误。

c、 列出项目中的最差实践：

组织机构和其他项目组总结经验，学习他们的错误中得到的经验。和其他组同事交流项目开发中的磨难，学习他们的经验。列出潜在的错误，看到它我们就会尽量避免今后犯同样的错误。

打个适当的比喻，典型错误好比我们学车时教练讲的经验，自己的最差实践就像我们在实际开车当中出的问题，而项目中的最差实践就是我们学车前的笔试的书。

公司在发展的同时，也会积蓄一些各方面经验。列出所有的经验，按其分类。系统分析中的经验提供给系统分析，设计人员中的经验提供给管理人员，技术中的经验提供给开发员。这样我们就会有更多的时间花在新的错误的防范上面。开发出来的系统就会一个比一个好。

2）风险管理：

下面先看一下来自一段网上的文章吧！

“一般认为赌博是在冒险。拉斯维加斯老虎机的设计者将老虎机的最大赔付率定为97%，即你花一天时间，往老虎机里塞进100元，最多只能赢回970元。

但是，如果比起软件开发所冒险，拉斯维加斯的赌博简直就可以称为“安全的冒险”了。软件项目所面临的不断变换的用户需求、糟糕的计划与估算、不可信赖的承包人、欠缺的管理经验、人员问题、伤筋动骨的技术失败、性能欠佳...等等不胜枚举的风险，使大型项目按时完成的概率几乎为0，大型项目被取消的概率和赌博一样成败参半（Jones 1991）。”

所以项目开发中对风险进行控制管理就大大提高了软件开发的成功性。软件风险管理工作就是在风险成为影响软件项目成功的威胁之前，识别、着手处理并消除风险的源头。一般我们可以在几个层次上定位、管理风险。

1） 危机管理---救火模式，就是在风险已经造成麻烦后才着手处理它们。

2） 失败处理---察觉到了风险并迅速做出反应，但只是在风险发生之后。

3） 风险缓解---事先制定好风险发生后的补救措施，但不做任何防范措施。

4） 着力预防---将风险识别与风险防范作为软件项目的一部分加以规划和执行。

5） 消灭根源---识别和消除可能产生风险的根源。

1、2、3项都是被动进行的，亡羊补牢，为时已完。所以我们应当着力于预防风险，更好的是消除风险根源。

风险管理由风险评估和风险控制。而风险评估由风险识别、风险分析和风险优先级组成：

● 风险识别：就是提出一个潜在破坏项目进度的风险列表，就像生成错误列表一样。

● 风险分析：评估每一个风险出现的可能性及其影响，判定风险的级别。

● 风险优先级：按风险影响大小排出一个风险优先级，这个风险列表将作为风险控制的基础。

风险控制由风险管理计划，风险化解和风险监控组成。

● 风险管理计划：制定一个应对每个重要风险的方案，同时就确保每一个单独的风险管理计划之间以及与整体项目计划之间相一致。

● 风险化解：每个重要风险所对应计划的执行。

● 风险监控：就是对解决风险的过程进行监控，风险监控还可以包括识别新的风险并将其反馈到正在进行的风险管理进程中等方面的工作。

现在以我以前做的项目来说明一下我是怎样进行风险管理的。

接到项目对项目进行调研工作，在调研中就要注意到克服错误列表中的错误。调研完成后，写需求说明书初稿（一般根据情况至少给出两个以上的方案），为客户进行讲解，结合客户意见再次进行修改。把修改后的说明书和同事进行讨论，再次进行修改。在此期间写出总体设计的初稿（大的框架）。最后再为客户讲解，再次修改少量的功能。客户确定需求满足后就可进行总体设计了。在生成需求分析的同时，注意列出需求中存在的风险。如：需求改变问题、需求定义欠佳等风险。在进行总体设计时，多和客户交流。因为在总体设计中修改需求比在详细设计中修改要容易比在编码阶段修改就更加容易了。之后生成总体设计说明书。同时在总体设计中也要对一些不定的因素进行风险监控。列出风险列表。根据总体设计说明书就可以开始详细设计了。在详细设计中除了要考虑系统设计外还要考虑一些技术风险问题。把很难预见的问题列到风险列表中。注意，从需求分析到详细设计，随着系统开发的进度, 以前不明的因素将会慢慢显露。同时也会出现新的不明因素。这样就让我们必须在整个设计开发过程中进行风险监控、风险识别、风险分析和风险化解工作。同理，在编码中也同样处理。在开发过程中根据分析不同，把风险按阶段分为需求分析阶段风险、总体设计阶段风险、详细设计阶段风险和编码阶段风险。并交由此阶段的人员进行监控和化解。同时，如果在化解安全区（规定解决问题的时间段中）内无法完成解决，则提交专家组（包括到外请的专家顾问）解决( 我们一般是在周五下午的讨论会上进行)。当然软件开发中所碰到的风险是很多的。但不可能完全同时进行风险监控的。通常是把风险列表中认为最会发生的风险乘损失的大小后的最大数进行严格的监控起来。随着开发进度，风险是在变化的，所以风险列表可能会增加也可能会减少。只要风险管理好了。系统就成功了一大半。

3）人员管理：

不同人员之间经验的不同导致绩效差别是有目共睹的，大家可能对不同开发人员之间生产效率差距达10：1的观点较为熟悉，大家也知道一些明确激励措施所带来的正面影响。所以人员管理在软件项目中也有较重的分量。很清楚，人力因素极大地影响着生产效率，同时任何关注提高生产效率的组织首先必须有一套良好的人员激励、团队合作、员工选择及培训的机制。这样才能充分发挥人员的自身能动性。为公司创造更多的价值。

除了以上几个面的管理外还有其它方面的管理也决定软件项目的成功与否。如：团队合作、团队结构、生产率工具等等。这里就不多说。大家还是抽空多看看书。因为只要你选择了从事计算机工作，你就选择了永不能停止的学习、学习，再学习。否则你就将被淘汰。这是多么残酷但又多么现实的事呀！

三、在项目开发中软件工程VS项目管理：

开发员对软件工程是多么熟悉的呀！为什么会有这么熟悉呢？因为现在的项目要求开发员“按章办事”。否则充其量也只是一部编程机器。上面已讲了软件工程的重要性，这里就不多说。现在打个比喻，如果把软件工程比做音乐家，那项目管理就是音乐指挥家。一个好的音乐家一个人能奏出动听的音乐，但一群好的音乐家在一起不一定能揍出好的交响乐。它还必须有一位好的指挥家。软件开发也是一样的，有好的程序员只是前提条件，要开发出好的软件，还要有一个好的管理。

只代表个人关点，请大家多多讨论。不足之处请多多指教为谢。

同时一到一个功能基本相同的软件任务，其领导就说，容易，把以前的Copy一下，重新修改一下就行了。哈哈。。。这就是所说的代码重用了。注，这此代码写了5-6年了。但他每次都是重写的哟！这种代码我一天也可以看10000行的。这可是真的只要把每个OnButton连起就可以看懂的哟。
   在管理方面，我想大家以看出，给你的需求最多时不过两张纸。然后叫你写出程序。比如现在的这个系统功能如下：
    实现车辆的图像抓拍，读写微波卡，控制超声波，发手机短信，连接数据库。
    真是没办法。痛苦ing! ( xacn 发表于 2003-4-10 11:22:00)
 
我看过一些高手写的软件,其逻辑之复杂，水平之高，思想之好，真的是让我提高了许多。但是没有文档方面的资料。我看了一个多月才看了一点点。这个软件不是什么大系统。而是一般的电池检测软件，功能不多。但这个高手已写了6年之久。至今用户都没有找到一个bug。我想要是有文档看的就会太累。理解起来也容易。增加新功能也就很快了。如果只要把每个OnButton的内容连起来就看懂的程序，这样的程序其实没有多高水准的。真真要体会的是其内部的算法和其设计思想，还有就是其设计的数据结构。至于管理，没有计划和风险，就像我现在的公司，从需求到来现在，老板要你12天把它实现并进行验收，如果只是用OnButton一样去连接，不考勤将来的开发。还可以应负。如果考虑将来的开发。那这只是一个真实的软件笑话。下命令的人尽然是一个做了多年开发的软件人员。有多年经验的哟！如果这样就可以做好一个好的软件，我想这样就能写出一个好的软件的话，那真是中国软件人员的
悲哀。现下把我们这位领导的代码和大家分享一下：

( xacn 发表于 2003-4-10 11:21:00)
 
在乱七八糟的瞎讲,别的不说,前几天我就看了一个大约有万把行的程序,其实不难,一看程序么就知道大概什么功能了,把每个OnButton的内容连起来就可以了,在把重要的看一下就可以了 ( ikohl 发表于 2003-1-22 19:59:00)
 
装的象老大似的,实际没什么用.用来蒙老板还差不多.因为老板大多都不干事. ( sunrenliang 发表于 2002-12-6 17:06:00)
 
这是我第一次体会到项目管理的重要性
我学习程序设计也有3年了，从来也没有
考虑过这方面的因素，这次让在下体会到
了，多谢！以后看来我也因该在这方面多
下点功夫。但是空说是没有用的，我们
还是希望看到点示例，希望哪位能支持
我们，我还是一个学生，也没有机会接触这
方面的东西，希望能给于支持，多谢！ ( Tokza 发表于 2002-11-7 12:32:00)
 
用C语言的高效算法来类比全程项目管理不为过,假如项目管理者能达到那种组织程度就好了. ( zeno 发表于 2002-11-4 19:41:00)
 
真给我上了一堂很深的程序课。  非常感谢！ ( 周洋 发表于 2002-10-26 22:36:00)
 
哪里能找到关于这些方面的书籍？？能否推荐几本？ ( motorman 发表于 2002-10-18 17:56:00)
 
需求变化太多、太快，文档太多会增加程序员工作量，到后来是只改代码，不改文档。以前是没有文档，现在又太强调文档，形而上学。 ( CHEN 发表于 2002-9-29 9:53:00)

 
难,要老板了解员工的心理,老板在乎的是要求他的员工能为他创造多少的价值!只要你能为我赚钱了,那么一切都好办了,想要加薪,想要舒适环境,好,完成这个产品后再说!
之后,每天过来看看,拍拍肩膀问你,"进度怎样?".
我现在做的公司也好得不了哪里,老板只想着包装,程序的开发只要能做得出来就行了,管你规不规范,团队交流怎么样,我一头雾水,只知道任务下来,就一定要完成,想要点创新的思想,免提,文档完成还不算,还要向其他使用我的控件的人讲解,最好写得通俗易明,不然自已吃苦!!! ( laiboy80 发表于 2004-8-17 9:40:00)
 
to xinbao_1996：
恭喜你呀，但你和老板的关系很熟会对其他人不利，比如在有不同意见的时候，老板会更倾向于你，而不是“优者胜”，这看起来对你有利，但同时你也失去了校正检验的机会。 ( 周星星 发表于 2004-8-16 8:35:00)
 
对这篇文章有同感。因为公司里不可避免的有其他声音的存在，所以当我开始工作的时候，我习惯于带上耳塞。codeproject上不是有调查吗，20％以上的人有带耳塞习惯，呵呵，特别是那些节奏很强的音乐。我们公司还好，老板和我很熟，所以我的很多要求，在资金允许下老板都会支持^_^。 ( xinbao_1996 发表于 2004-8-15 20:11:00)
 
to pepperdiyu：我现所在公司的中层由一帮做MIS都失败的白痴们管理着所有的软件开发流程，而现在做的是电厂SIS，与破MIS毫无相同之处，而它们仍然保留着MIS时的陋习，认为只要想得出就做得出，极力的贬低程序员，连什么是对象都不清楚，却只要程序员给出UML中的类图，其他什么都不重要，能不能实现不重要，会不会因为逻辑不通被人嘲笑不重要，只要出现了class就合格，class出现得越多越优秀。
    但和你遭遇不同的是，它们不是骗子，它们只是从那些倒闭公司淘汰下来的垃圾货，无自知之明而已。 ( 周星星 发表于 2004-8-14 11:59:00)
 
这篇文章看了以后，真是让人兴奋。
我所在的是一家小软件公司，公司属于风险投资，可是我们的总经理、人力资源经理连起码的电脑基础都没有，他们以前是做机械的，还有一个是个骗子，拿别人的科技成果骗钱，一遇到技术问题就不知道该怎么办了，公司因此而失去了好多机会。

现在竟然又开始做软件，公司的软件人员的管理实在是太乱了。 从来没有写过文档，从来没有测试程序。....
更别想着舒适的工作地点和宽松的条件了，总是希望你周末也工作，可是谁有精神啊。更别想着创作了。