看了xp以后根据第一次的开发经历没事写的东西(100分)

小程序员的眼光
HT信息有限公司是一个新成立的民营小软件公司。毕业前的一天，小程序员Jelly来到HT面试；和以往经历的面试不同的是，坐在他面前的两个经理从来没有问他关于诸如“MFC的类库结构”这类问题。其中一个似乎面善的经理看了Jelly的英文简历，好奇地问道：“你的身高和体重分别用英尺和磅描述的，难道你真的算过吗？”Jelly笑了笑：“我上网在国外的bbs聊天的时候顺便算的。”对于HT公司，Jelly的印象还不坏。Jelly原先的主专业是化学；在这里，他至少不用整天在实验室里面站着忍受刺鼻的气味并无聊地等待。公司的空间感比较大，还有若干盆植物，四个人共享一个大的隔间，每个房间都有窗户（虽然有的是不能打开的那种窗户），每个人都能感受到阳光。这得感谢大楼的设计者：大楼是圆柱形的，电梯和楼梯加上管道等设施都被设计在了圆柱的中心。对于目前的人数来说，这个开发环境很理想。让Jelly不满意的只有一点，他的薪水很低，到了他能忍受的底线。
评注：崭新的开始，几乎一切都很好。
Jelly最终决定在HT公司开始他的第一次冒险旅程。他对新工作充满了热情。自从公司发给他一张门卡以后，每天你都可以看到虽然刷卡记录上Jelly不是最早来的但几乎都是最晚走的。在最初的一段时间里，晚上18:20以后绝对没有刷卡的记录。对于中午的工作餐，Jelly虽然不是非常满意但是开始的感觉的确不坏。经理和新员工午餐的时间都是坐在一张桌子前。通过一些交谈，Jelly了解到在面试的时候他遇到的和善的经理叫做Way，是公司的副总经理。和Jelly一样的开发人员都是新毕业生，对软件开发可以说除了一些语言知识和行业薪资标准几乎一无所知。Jelly被安排进行自我学习，并写一些前期研究文档。在公司里上网还不是很方便，不过可以容易地得到一些光盘。关于B/S结构系统的开发，离Jelly毕业前接触的asp最近的是php和jsp。对于apache和resin这些服务器，Jelly充满了好奇，并急于去弄懂怎样去使用它们。经历了两天的摸索，Jelly终于写出了他自己的“Hello World”的php和jsp的版本，并有了自己的配置文档。这时，软件开发部的经理Hawk出现在他的面前。Hawk是一个胖胖的很喜欢与人交谈的人，他与公司的其他经理和老板都很熟；的确他们以前曾经在另外一个公司一起合作过。Hawk以前开发的是基于Domino Notes的办公自动化系统。Hawk急于把关于Notes的知识传给Jelly，并给Jelly发送了一些相关的文档。第二天，Hawk召集软件开发部的人员开了一个会议，并给每个人安排了一些工作。Jelly负责和Hawk一起去找NCO公司的计划信息部人员去谈新系统的需求问题。这是Jelly第一次接触客户；他有点紧张，于是精心找出一个漂亮的笔记本掩盖这一切。
评注：第一次冒险前一切也都还顺利。
NCO是一个很大的生产型企业；不过这次Hawk的目的显然不是去接触一切有关ERP的复杂图纸。HT公司和NCO公司计划信息部商量的问题集中在办公自动化这一块。NCO公司原先的办公自动化系统是在Domino Notes的基础上开发的，使用状况也很好；更重要的是，Hawk曾经参与过这个系统的开发。一切的问题似乎都很明显，只要Hawk去找以前的开发需求文档就可以了。Hawk和计划信息部的客户代表X也很熟，他们只是简单地讨论了一下目标:一个能够取代原来基于Domino Notes开发的OA的客户端是浏览器的新的OA系统，并向Jelly介绍了一下该项目客户方的人员。一天过去了，Jelly漂亮的笔记本上只记下了几句话和一个很简单的办公流程示意图。Jelly虽然还没有完全明白需求，但是系统的整体构想已经出现了:一切以办公流程为核心。
评注：第一次旅程是一个简单的开始，没有发掘太多的问题。这可是以后隐患的根源。
回到HT公司，Hawk找出了以前的相关文档。不幸的是，这些文档是多么地不齐全，以至于很难从中找到太多有用的东西。Hawk对B/S系统并没有比Jelly更多的经验和更深的理解。Jelly对Domino Notes几乎一无所知。要命的是，该系统的最后期限已经出来了：一个月以后必须看到一个能运行的系统；两个月以后必须看到一个功能齐全的系统；三个月以后必须是一个通过客户验收的系统。老板已经想象着三个月以后的验收庆功会了。Jelly第一次感到恐慌。Hawk安慰他说：“没关系，一切都会解决的。”由于种种压力因素，由于没有经验，Jelly作出了一个愚蠢的决定：开发一个没有扩展性的系统。对于Jelly而言已经没有考虑和学习的时间，最快的实现客户提出的要求的方法莫过于用DreamWeaver一下画出一堆页面来，然后慢慢在页面里面添加插入式服务器端脚本；即使没有实现这些脚本，也肯定能满足第一个要求，即第一个月必须看到一个能运行的系统，只是这个所谓的能运行的系统并没有完全实现功能罢了。经过一段时间的磨合，软件开发部的一个员工认为薪水太低没有留下来，另外一个员工由于工作不是很积极公司没有把他留下来。公司希望的人是学习能力很强的，能够有团队精神的并且和现存的公司实体相容的人。HT公司诚然看到了这些情况对Jelly目前造成的困难，决定分给Hawk另一个新人G。Jelly快速地构建了一个Web页面框架，并决定用PHP实现动态部分的脚本。从表面上看，一切和其他基于Web方式的B/S系统没有大的区别。两个星期后，Jelly和Hawk把这个初步的系统拿到NCO公司计划信息部做了演示。
评注：非常的情况造成非常的设计。这一切前途未卜，充满了问题。现在看来，那个系统完全应该在每个客户的IE浏览器中装入一个Domino Notes的插件解决的，这样就不会有下面提到的灾难了；当时经理Hawk对这种方式开发Domino Notes系统还没有任何认识。更重要的是当时高层客户特意想抛弃Domino系统。
这个能够演示的系统的确让客户对新系统有了初步的印象。对比他们现有的基于Domino的OA，这个新的OA显然在界面上存在很多缺陷，操作方式也有很大的不同。有的客户问道：“我能否象编辑excel那样在浏览器中编辑图表？”有的客户问道：“我需要消息通知我去接收这个公文。在浏览器里面我怎样才能做到我不用打开浏览器就得到这个消息？”诸如此类问题，的确需要Jelly和他的同事花费一些时间去实现，而且有的问题具有技术上的挑战性，以至于根本不能在三个月只内完全完善地实现。这才是第一次演示，出现的问题已经让Hawk和Jelly疲于招架。相对于界面上细枝末节的问题，和公文审批流程密切相关的总秘书L小姐坚决否认了上次由客户代表X提交上来的公文审批流程，并且她额外提到了打印的功能：“如果打印的功能不能象原来的系统中那样，我们对这个新的系统只有一个结论-拒绝使用。”。让Jelly头疼的是，原来系统中需要打印的公文的格式真的很多，而他本人对打印方面的开发还没有任何经验可言，一切必须学习和实践。而这一切都没有包括在原先计划的时间内。
评注：改变任何一种现存的事物要比创建一个不存在的事物要困难。但是人们往往有两种思维定势：一个是改变意味着较少的花费；另一个是改变只意味者进步。向客户解释清楚这个问题本身就很困难。更麻烦的是高层的客户已经做了决定。对这个决定的任何的怀疑只意味者他工作上的失败。还有一个隐藏在问题背后的问题：“客户代表的需求是否真正代表了使用者的需求？”
Hawk向HT公司的老板提出了他的项目小组遇到的问题，他要求能够和客户商量一下最后期限的问题。这时候HT公司的老板笑了：“我早知道这个问题会发生，所以我和客户商量的最后期限不是三个月，是四个月。但是，为了让你们更快的工作，我不得不告诉你们是三个月。”Hawk无奈地同意了，并且他提出：“必须给我们这个小组尽快地增加足够的人手。并且，Jelly的薪水实在太少了，我们必须看到他一直在努力而有效地工作。”对于这两个问题HT公司的老板也给出了同意的回答。但是，即使是四个月，Jelly和Hawk也明白很难实现用户的需求。Hawk说：“我建议，星期六大家也来上班；不是作为开发，而是作为学习。可以自我学习。有时候我们也会安排一些有经验的人给大家作讲座。”对于星期六上班的决定，Jelly还没有太多的抱怨，因为他目前还是一个快乐的程序员。但是G很苦恼，因为他对于编程和学习方面总是比别人落后。几天以后，Panda加入了HT公司。不能不介绍一下Panda，因为他也都是快乐的程序员。经过一段时间的调整，Jelly和Panda根据重画的公文审批流程图修改了系统。大家还没有重构系统的打算。因为大家目前为止还是觉得没有扩展性的系统并不是一个大问题；关键是要尽快实现这个系统。这时候的开发过程纯粹是一种自发的过程。因为对整体的设计缺乏经验，Jelly和Panda只是憧憬大公司有经验丰富的系统分析员和完备的规范的文档。Hawk每天的工作是上上网，画画进度条，与开发人员就需求上的问题展开沟通。
评注：对于提高员工工作效率实施一些虚报最后期限这样的小伎俩事后被证明是完全无效的。和目前XP思想中提倡用先写测试代替先写文档这样的事实相比，其实对于目前大量的小公司中还存在着更初级更原始的方式：干脆既没有文档也没有测试。代码只是基于文本方式或者几张业务图表的描述而生成在程序员脑海中的未来系统的逐渐清晰的实现，也很难有效反映变化。一旦出现问题就想到加班，这几乎是所有软件开发公司的第一思路。但是，一旦快乐的程序员变成了苦恼的程序员，这个方法从此不再有效。
两个月过去了，客户已经能够看到基于第一次展示后讨论时确定的他们需要添加的功能。在NCO计划信息部的会议室，一些真正的用户和新系统坐在了一起。邮件、公文审批、打印、需要打开页面才能看到的消息提示。Jelly想，即使是原来那个Domino下的OA系统，也没有再多的用户可以看到的功能了。然而，一些用户再次提出了让Jelly意想不到的新需求。客户1问道：“这个公文审批流程可能并不实用。可以这样说，部长通常都不会自己去处理公文。在我们日常的工作中，他的工作只是签名而已。我们希望你们的系统中也能够让部长用自己的笔迹签名。”客户2问道：“既然部长很少自己用电脑，如果他的秘书没有部长的身份标记也就不能进入系统。我们希望你们的系统中权限管理能够更灵活。另外，你们的消息提醒不错，但是我们希望的是随时而不是只有在打开系统时得到消息提醒。”客户3干脆地说道：“你们应该有让我们自己定义审批流程的功能，能够随时改变审批的过程以适应机构的变动。”这些功能在旧的OA系统中没有，但是客户希望在新的OA系统中必须包含，而且每一个功能都被客户提到了最高的实现优先级。
评注：在没有真正的沟通的情况下，开发人员所做的一切就只能是妥协。尽管功能需求越来越多，但是没有办法得到用户心中真正的最迫切的需求。最重要的一点就是最后期限是指定的，即使需求的变化迫使预算也跟着变化。不单单开发人员和客户没有足够的沟通；客户之间本身，开发人员之间本身经常也没有足够的沟通。在这里，Hawk的小组碰到了最令人头疼的问题：“用户对高层客户的决策有强烈的抵触情绪！”
在第三个月里面，Jelly和Panda挖空心思地想办法解决客户的各种要求。Hawk发现客户代表已经不能完全控制住新系统使用者的情绪。Hawk向客户代表解释道：“这是一个新系统的第一版本，可能会有些小问题；但是我们会在后面的工作中改进它。”客户代表也相信Hawk的小组的确是在努力实现这个目标，但是他要说服用户也理解这件事情。现在看来如果不能控制住用户的不合作的态度，新系统在第四个月结束前根本无法通过验收；用户实际在干扰Hawk的开发人员获得真正的需求。因为在这一个月中，公文审批流程已经反反复复地修改了若干遍；Jelly和Panda已经在考虑流程自定义的问题。
评注：大量的客户盖章的需求确认书并不能代替用户真正的需求。这些文件可以只是一种敷衍。按照错误的图纸做出来的东西虽然在图纸上签名的人负全责，但是任务并没有完成。责备客户在缺乏沟通的情况下意味者失去客户。我们希望实事求是的交流，但是通常我们不得不遵守一些中庸的准则。我们必须挖空心思去找真正的用户到底需要什么。
Panda想到消息提醒功能其实可以通过手机短信实现，这只需要在服务器端安装一个短信发送设备。Hawk从网上查找到这个设备的供应商和开发工具，并积极和他们取得了联系。接下来的几天，Jelly和Panda一起完成了这个功能。客户代表提出再开一次会议讨论一下目前系统对需求满足的情况。在会议室里面，Jelly和Panda向用户演示者没有太大改变的系统，用户无精打采地看着屏幕。Panda最后说道：“我们已经把消息提醒功能实现在手机短信上……”客户代表X补充说道：“我们考虑给新OA的使用者每人配一部新手机用来接收公文审批消息。特别是部长，他可以用最新款的有手写功能的手机给公文签名。”用户为这小小的利益兴奋起来。这次会议开得很成功，因为用户非常配合。剩下的合理的需求很快确定下来。Hawk长舒一口气，终于能在第四个月结束之前完成系统的验收工作。
评注：巧合是符合人的心理学的。做生意讲回扣，新系统的直接使用者也总希望得到好处才使用它。虽然他们离开第一片沼泽地，但是剩下的路程也绝对不是平坦的公路。在这四个月中他们已经浪费了太多的时间处理一些不得不面对的问题。对于缺失的文档，对于这个很难扩展的系统，对于没有充分测试而很难保证的代码质量问题，还有若干个噩梦跟在Jelly和Panda后面。

希望确认一下有没有写下去的必要。不过我本来的想法是：任何过程即使是失败的也能算一个案例；如果有更多的实践者愿意整理他们所经历过的事情，对于国内软件开发过程的研究这不能说不是一件好事。
本人联系的mail：kof2k@xinhuanet.com

好,支持,希望能写出去,从成功我们吸取经验,从失败我们吸取教训.

支持,,我认为XP编程比较适合的,..和别的有许多不同..我是比较喜欢的

很好，文中的境遇在项目过程多多少少都碰到了，近两年来，都是一个人在负责开发，工作热情逐渐消磨，Jelly起码还是个快乐的程序员，而我则早就是个苦恼的程序员了！
楼主请继续……

写得不好，不过上面的人给我很多鼓励，谢谢！
第二部分描写了Hawk建立和稳定他的开发团队的经过作为一个真正的大项目考验的前言。初期这个团队熵值很低，行为的效果很明显。有时候我不禁这样想：“如果许多公司都是这样匀速前进的话，怎么会出现目前一个乱字了得的情况？”虽然这个想法不现实，但是任何公司的确可以适时从系统外获取负熵的。但是，很遗憾，这种事情很少。
小程序员的眼光2
虽然Jelly的第一个项目说不上圆满，但是终于通过了客户的验收，度过了第一阶段合同的最后期限这个难关。Hawk的小组已经增加到5个成员：Hawk、Jelly、Panda、Allan和Bat。这个小组已经有过加班的经历，不过这还能让人忍受，最少没有出现不愉快的加班。很多时候，他们和客户代表一起去附近很一般的小店进餐。虽然小店的饭菜不很可口，但是他们和客户代表的合作非常愉快。吃饭的时候，大家经常随意地聊天，谈工作环境、个人问题甚至最新出来的游戏。
会议室里，HT公司的老板以一贯深邃的眼光注视着每一个人，慢慢地说道：“上一个项目结束了。NCO是我省比较大的生产型企业了。我的希望是我们不单单是做项目，更重要的是做产品。如果我们把项目当作产品来做，一定能事半功倍……”。Hawk的表情没有一点变化，Jelly的目光中闪过一丝不安，Panda在倾听，Allan和Bat则附和地低了一下头。老板继续说道：“我们虽然才起步，定位一定要高；因为后面我们还有一个非常大的项目要做。在此之前，我希望大家好好利用这个机会锻炼自己。”
会议结束了，Hawk开始google和打电话的过程。“看这个系统。”Hawk召集离他最近的Panda和Jelly，指着他的显示器屏幕说道，“这是RH公司的一个OA产品，用了jsp实现的，里面包含的功能其实和我们上次的系统差不多。我的一个大学同学是RH公司的，他说这个产品每年获利100多万。”Jelly仔细地看了看这个系统。RH公司已经把它放在互联网上供浏览的用户测试。显然，它仅包含可怜的测试数据，并且还存在一些系统错误。很难想象这个东西每年能赚100多万。Jelly知道RH公司的办公室墙上是挂着太阳旗的。
这段时间里Hawk在写一些策划书。公司希望大家趁这个比较清闲的时间段好好研究一下怎样在j2ee平台下开发的问题。之前，显然没有一个人做过java的开发。5个人中间，除了Hawk和Rat，其他人都是刚毕业的新人。Rat以前从事过一年的delphi编码工作。Rat的加入让Panda觉得安心，因为关于打印的问题Rat可以搞定。HT公司的老板一再向Hawk解释他的用人标准：培养为主，让新人成长起来。
评注：这里不得不先说明一下人的所说和所做经常是相违背的。其实老板真实的想法是最大限度减少用人的成本。这本没有错。不过缺少一个好的教练令团队不得不花费一些额外的时间在摸索中成长。明确的目标、必要的技能、相信团体的大于个人的总和、不断的激励；他们在第二点上受到了困扰。
HT公司开始安排一些著名学校的计算机系的教授给Hawk的小组上课；老板要求公司所有的人都去听，无论是程序员还是网管，甚至会计和前台。Hawk和Jelly去著名的NU计算机系拜访教授S，希望他能提供一些帮助。教授S是一位令人尊敬的年轻有为的学者，在NU任计算机系副主任，和老板私交很深。临走时S教授送给Hawk和Jelly每人一本书。每当谈到一些学术上的问题，S教授的眼中总是闪动着一种激动的光芒，言语中都是对大师和巨著的赞美之情；他毫不掩饰地说：“这本书真的很好！”。私下里，S教授的学生都尊称他为某公。说到人际关系网这个层面，HT的老板有着全市甚至全省其他的软件公司都没有的特别的家族优势。诚然，没有实践知识也不行，HT公司还在周末安排员工听一些技能培训。Hawk等人满怀希望地从这些地方用笔记本拷贝回来一堆工具。买书报销的事情也很方便。过了一段时间，Jelly等人感觉java网络开发也就是那么一回事，不就是jsp和Servlet。Jelly从网上了解到UML，开始用自己的理解画用例贴在文档里面。Panda对Wsad和Jbuilder这些有界面的IDE更感兴趣。Allan在看php和jsp。Rat则继续用Delphi做一些报表打印。又一天，老板让Hawk、Jelly、Panda一同去参观HR公司。HR也是一家日资公司，不过在他们的办公室Jelly没有看到一面大大的太阳旗。HR公司安排技术部长Z给Hawk等人介绍了他们的公司开发情况和一个图形化的Struts开发工具WP。在这以前，Jelly和Panda都不知道何为Struts；在他们的认知中，J2ee不过是和php差不多的jsp再加上一些可有可无的servlet。Jelly对面向对象的认识很有限，对如何创建一个可扩展的框架也很无知。技术部长Z还安排了他们参观了HR的开发小组的工作；在这里，每个人的空间很有限。Z介绍说：“自从我们采用了WP工具以后，新人只要一个星期就完成了培训；并且，创造了一个4人小组一个星期完成一个有60个页面的项目的开发效率。”。通过这次会面，Hawk等人对HR公司的WP工具有了很深的印象。Jelly和Panda更感觉到，原来B/S系统可以把页面当作对象连起来；联想到最近看的UML，Jelly更感觉活动图就是那么一回事。他们也知道了可以去看apache的公开代码项目的文档。
评注：学习是一种快乐。不过这里他们犯了一个错误：没有传播知识。xp中的结队编程的目的就是让知识像病毒那样快速传播。直到最后，Jelly仍然对图形界面的Wsad感冒，Rat总不明白服务器容器中的对象，等等。统一开发工具也是必要的。还有大家需要一个版本管理系统。这时候Hawk小组中的大多数人还没有意识到这么多。Hawk和Jelly已经认识到自己和同行的差距。不过HR公司的运作其实并不是很美妙，在创造高开发效率的同时，他们也常常为系统的修补付出额外的飞机票。这个阶段Hawk的小组正向团队好的方向发展。Jelly等人此时显然没有充分理解j2ee的结构设计。HT公司此时目前看来如果能有一个真正理解j2ee系统设计和分析的成员加入这个团队而不是在团队之外演讲，效果将更好。虽然以后这个条件的确满足了，但是错过了适当的时机；更坏的是，老板因为下一个最后期限和开发成本全盘否定了Hawk辛勤建立的原本良好的团队，逼迫大家成为加班狂人。这个以后的篇幅中再提到。能真正成为加班狂人的地球人实在只有机器人了。
有一天，Jelly感觉到身体实在太虚弱了；晚上，他就不得不去医院挂水。这是一个信号，他不得不锻炼身体了。于是，Jelly找到附近的好友羽毛球俱乐部。俱乐部的高手实在很多，还有几位是专业队下来的。在第一次脚掌磨出水泡的痛苦经历后，Jelly开始迷上这项运动。一个星期六，Hawk也注意到了他的队员体质上的变化：Panda更胖了，Allen和Rat则猫者腰喊头昏，他自己也感觉有点怕爬楼了。Jelly建议Hawk考虑在星期六下午抽出时间来运动。在星期六的时间安排上，此时Hawk还有足够的自主权。Hawk提出可以一起去打篮球和打羽毛球，大家都欣然接受了。此后的每个星期一，明显可以看出每个人的精神状况有了好转。
评注：身体是革命的本钱。如果按照xp每周40小时的计划严格实行，锻炼身体完全可行。HT的初期显然连XP为何都不知，但是集体锻炼身体这种计划的确深得人心。我的同学曾在东软，靠近五台山，他们的团队也有每个星期的集体锻炼。然而，很少看到有公司为这种集体行为付账单，也就意味着这件本来非常美好的计划不能坚持长久，也难怪人才的流动率高。如果公司或者企业只是在口号上高呼企业文化、团队精神，并且仅仅为总裁或者老板自己的团队建设想法买单，而不去考虑员工实际需要什么，就像花钱买了一堆无用的东西。或者认为这些工作之外的事情只是员工应该自己掏钱买的东西，员工怎能对这样的企业或者公司产生信赖和依靠的感觉？强制同化的思想在中国很难实行，求同存异才是可行之道。有时候公司为个人的发展或者某种爱好付出5000元，将比给他增加10000元年薪效果好很多。团队凝聚和解散其实是一个纳什均衡问题，建立怎样的均衡显然也像所有同类的问题一样：决定因素在均衡涉众之外。
以下准备写怎样向这个团队中插入新成员的事情，待续，欢迎插入评语和给出修改意见……

希望可以继续写的很好.我喜欢...

很好的文章，有志于项目管理方向的同志应该好好看看。偶水平太菜，看了差点没有哭出来。当前软件公司（特别是中小的公司），对于软件文档的书写的确是不太重视，这个问题给后续开发带来了非常不利的影响，特别是项目易人及项目扩展时非常的不好，往往新人需要花掉大量的时间来阅读前人写的代码/模块，等到差不多了，项目的时间也要花去一部分。
以上愚见，各位见笑。

欣赏，继续发扬！！我喜欢。。。。。。

写的好,看了还想看啊.什么时候在发啊 ,我还要看!![8D]

自己写的东西水平实在有限。鉴于目前的无业状态，下一段可能等到星期一写，给自己一些看书和思考的时间。再次谢谢。
小程序员的眼光2续
Bull是老板熟识和信任的一个人，在北方某厂有过若干年erp的开发经验，年龄也是所有开发人员中最大的。Bull起初和Hawk的团队一起吃饭，并抢先付账单。最近，大家显然对大楼物业固定的食堂有了明显的不满：千篇一律的菜式、发黄的菜叶、糟糕的口味。虽然公司附近的小饭店也好不了哪里，但是终归有了其他的选择。周六的集体锻炼，Bull也主动买了所有人的饮料和支付了场地费。他是一个非常热情的人，除了有点不注意个人形象。大家合作得很愉快。月中以前，他还换了一个新手机。这个月底，Hawk等邀Bull一起聚餐，Bull婉言谢绝了。以后的若干天，中午围在一桌点菜吃饭的情形也很难见到了。大家都选择了最便宜的盒饭。HT公司出了新规定：工作餐不可以再凭每天的发票报销，而是改成每顿5元到发工资的时候一起结算。随后的几天，大家一致建议集体电话订餐。这个主意真的很不错；既把开支控制在5元以内，又让大家能坐在一桌前满意地吃上一顿丰盛的午餐。午饭时间过后，会议室的地毯上总会留下一些不小心弄脏的痕迹。几天后，Hawk遗憾地告诉大家：“老板说不可以在公司用午餐，因为这会弄脏会议室。更重要的是，让客户看到我们这种行为多么不好。这让一个公司不像一个公司。”
评语：节流。公司认为员工超过5元的午餐实在是一种食物浪费。也许很多公司是从规范财务管理和堵塞虚开发票的角度考虑吃饭报销的问题。不过，这的确令员工心寒。见过一些公司坚决不提供午餐或者午餐费，因为有的人利用公司的微波炉自己从家中带饭菜来热。即使这种理由能够成立，也总会让人产生不快；小小的不快的积累很可能会捅破团队凝胶的保护膜。没有老板不爱惜自己公司的财富；不过很多情况下，员工并不被当作公司的财富。在一个斤斤计较的公司工作着，员工总有踩着弹簧踏板的感觉。还有一件小小的私人建议，大方也要有度，尤其在必须自己掏钱的时候，毕竟每个月的后半个月很难度过。
月底，老板召集所有的人，包括Hawk的小组，开了一个全体会议。公司出台了一套规范的考评表，代替原先每周、每月每个员工必须写的文本形式的工作小结。这套考评表采取了标准题的形式，便于以后公司升级改成答题卡好用读卡机读数据。“这套考评表分成若干张。当然，你们原来的总结报告也要有。”，老板说道，“不要忽视填写考评表的重要性，这将关系到我们公司能否健康前进。当然，目前还很少，我们会不断完善起来。”
评语：管理的数据化似乎代表着管理的一切。有人这样想：一个超市一年的月平均库存和销售图表，的确客观反映了该超市的货物的一种管理情况。每个月，当主管收到一堆打满勾和叉或者填者ABCD的表格，忙碌于给每个员工下评语，写评分的时候，都有一种收获的满足。这里有两个极端。第一种极端，中层经理完全忽视评分数字的意义，基层开发人员完全不关心自己的评分情况。填考评变成了应付一种形式的行为。此时评不如不评，填不如不填。真应该考虑表格的设计是否有问题。曾经遇到这样的公司：公司总共有20个员工，部门经理和总经理每到年终都要为年终考评的事情忙一个星期，经常还不能完成。这个公司设计了很多表格，并且已经为解释这些表格的含义和填法开了超过3次比较长的会议；而且每个部门需要填写的表格很不一样。其实，软件部的员工只要填写其中3张表格即可，市场部的员工则要填写其他的几张表格。借用一下设计中的接口隔离原则，每个部门的普通员工只要知道本部门的表格和填写方式即可。更重要的是，3张表格已经足够多，其他部门在这个问题上产生的混乱实在是因为他们要填写太多的表格。一件重要的事实是，这些表格是该公司老板从一个大型的制造型企业中借用而来的。过度设计也是一个问题。另一种极端，每个人对考评表的填写战战兢兢，既要考虑自己实际工作情况，又不能把自己评得太低。每个人直到此时才觉得自己是待宰的羔羊。经理也左右为难。概率论学的好的经理，按照正态分布的模型给每个人划等级。这里不是否认每个人应该对自己的工作负责，但是在通常情况下，没有人愿意故意把事情弄糟；即使很糟糕，事情已经发生，损失也不可挽回。考评本来的作用是让人感觉到自己工作的价值和让大家分享这种价值。惩罚失败而不只是惩罚故意的失败，其副面作用是比较糟糕的。特别是当一切成绩可以和金钱挂钩的时候，这种副作用很可能导致一个员工人心事实的背离。因为是标准化的考评表，更多公司愿意把许多看得见模得着的东西无论有无作用都放在里面。我无意攻击打卡制度，不过我的确看到，有的公司一秒钟扣一块钱，有的公司迟到15分钟也不算迟到。原因是有的老板喜欢早起锻炼，认为员工理当按时上班；有的老板自己有点懒散，想想自己也就默许了迟到的行为。在小公司的模式下，看得见模得着的数据未必就是想象中那样清晰的。
歇一天再继续写。上次提到向团队中插入新员工的问题仅写到顺利的情况，还有另外一种令类天才综合法则以后继续，Hawk的团队中将插入Magic和Squirrel。以后还会提到上班的私人自由度问题，如Jelly通过EMail和同学聊天，Bull和澳大利亚的女朋友用msn语音对话，W公司的电子邮件封锁烦恼和搜身政策，为什么老板要求员工读《谁动了我的奶酪》并写读后感时几乎没有一个员工不和书中论点唱反调等等。

好,辛苦了,写了那末多,继续支持!

好问，支持！收藏！
希望楼主继续写下去

很有文采，我喜欢。

to kt133:
鎬庝箞璇村憿锛岀湅浜嗗崐澶╂墠鐪嬪畬锛屾兂姣斾綘涔熸槸鍐欎簡鏇翠箙鎵嶅啓鍑烘潵銆備笉鐭ラ亾浣犺繕鑳藉惁缁?啓涓嬪幓锛屽弽姝ｅ埌鐩?墠涓烘?锛屼粠浣犵殑鏂囧瓧涓?垜鐪嬪埌浜嗕綘搴旇?鏄?竴涓?嫟浜庢

小程序员的眼光2续续
再次感谢所有阅读它的人！
to Justin：你不应该抱怨你的项目经理不懂Delphi，只是他做了本不该他做的详细设计。如果你还愿意在现在的地方工作，你应该向他和你的老板指出这个问题。如果你看到这位经理在画进度条，你最好提醒他说：“也许按照我们自己的设计安排进度更合理一些。”或者干脆忽略这些没有用的漂亮的彩色进度条。往往这些彩条最后人为被延长了一倍项目还没有完成。
Magic是一个戴着宽边黑框眼镜头发盖过额头的人。在Jelly的印象中，这种眼镜框只有30年代的女生才戴。Magic第一天就向小组所有的人展示了他的作品：“看，这个界面功能多么强大，外观多么漂亮。”其余的成员不能不承认这一点。至少Rat很欣赏，他说：“Magic，这的确不错；你能够帮我优化一下这个打印控件吗？”。Magic满口没问题，然后他看了一眼Rat的东西，随口叫出声来：“啊，这么丑陋，简直是垃圾。”他接着看了Rat的代码：“哦，你是用Delphi写的。为什么不用VB，VB多么好用。这样吧，我用VB帮你重写一个好了。”Rat的眼中闪过一丝不快，但是他答应了。接着，Magic巡视了一下Jelly和Panda开发的B/S系统的Web界面，他更不能容忍这样丑陋的界面存在于世上：“啊，这种界面能给客户使用。为什么不这样这样……”发表了一通演说后，Magic忽然意识到ie浏览器中没有他所想的那些元素。Magic也是一个勤奋的程序员。每天，他所做的事情就是在VB上拖动界面设计元素，不停地敲代码，查阅msdn设计手册。Magic经常有奇妙的想法。他写了一堆系列小程序，有阅读器、编辑器、离线浏览器、一些神奇的小盒子……他习惯并且喜欢用自己写的工具。Magic似乎是为数不多的从心底喜欢一天20小时坐在屏幕前生活的人。Hawk把NCO项目遗留下来的流程自定义功能模块交给了Magic。
Magic快速地在头脑中构思这个模块。第二天，他已经开始对这个模块进行编码工作。Panda希望了解Magic的想法，Magic说道：“这就是一些标签的组合。我根据数据库中定义的层次向用户展示这个层次关系；用户也可以通过编辑这种层次关系改变办公流程。”Panda和Magic做了进一步的讨论，Panda整理出一些东西，准备着手对NCO OA的第一个版本针对流程自定义功能实现做一些改动。这项工作进展还算顺利。在Panda的工作完成的时候，Magic的流程自定义工具的功能已经实现。Magic当然不能满足粗糙的界面，他额外花了两天时间对它做了美化。在Panda和Magic看来，这个工具功能应该比较多：存在各种各样的快捷键，外观和通常的设计工具统一，细心的浮动工具条和拖动设计，花俏的色彩设定……Hawk看了Magic的杰作，虽然很满意，但是他总觉得这对客户来说可能显得有点过于复杂了。他给NCO的客户代表X打了一个电话，希望他如果有空来看一下这个流程自定义工具。
评注：Magic是一个对某种技术或者工具迷恋的程序员，他还是一个完美型性格的人。我们可以看到Magic和Panda的配合很好，虽然他们有不同的开发信仰。在这里，无意中，某种意义上的结队编程的优势发挥了出来。也许有人无法接受别人认为自己的作品是垃圾。不过，改变一下对垃圾的评判标准的确能带来一些思考。当然，如果一个项目经理或者老板板着脸对他的下属说：“看看，这些天你干了什么？你究竟创造了多少价值？你创造的价值和公司付给你的工资多么不成比例！难道你的工作就是制造垃圾吗？”这就是一种绝对不应该出现的事情。也许这名员工真的产生了垃圾，但是这是产品研发阶段必须经历的摸索过程。在科研工作中，我们通常给最终的成果以实验的次数作为名称，并把它当作一种荣耀；为什么在软件开发过程中这是一种耻辱。同样面对较多的未知因素和同样的经历失败的过程，这两种过程得到的社会评价却如此的不同。还有一件是思维定势的问题。如果你已经习惯并且精通某种工具，某种语言，你一定会对它们赞誉有加；你可能无意地贬低其他的同类的东西。的确改变会带来效率的丧失，恢复高效率需要时间。在一个开发过程中没有人希望这种改变。不过每个人也没有必要因为这种原因令自己的视野不够开阔。杂学家更能适应当今的社会。
客户代表X对Hawk说，NCO OA第一版本在他们企业中已经开始了使用培训。不过，大多数人还是觉得原来Domino下的OA好用。但是既然这个项目已经通过了验收，并且召开过了庆工会，也没有太多的反对的声音了。X试用了Magic设计的流程自定义工具。他随即向Hawk说道：“这个工具的确界面很漂亮。不过，我感觉它的功能太多了，也太抽象了。其实，我们需要的是这样……”他在纸上画了两个方块，分别给它们标记上“部长”和“经理”，然后在这两个方块间画上一条线，并给出一个双向箭头。X继续说道：“如果流程自定义工具能够像我在纸上画的那样工作，我想那会更好。”
评注：纳什均衡的平衡路径的选择问题在NCO OA中得到了体现。一旦客户作了选择，他无法轻易改变这种选择，因为这意味着比较高的代价。第一次改变平台已经迫使用户花费一些代价作这种改变，他们在短期内一般无法再次做出这种高价的改变。客户的需要才是开发的需要。必须牢记这件事实。在没有确认客户的需求之前，我们没有必要作任何的细化工作。Magic额外的两天美化工作其实是一种浪费。这时候你给客户演示一个不完善的系统和演示一个非常完美的系统，带来的效果没有太大的不同。除非出于商业竞争的目的，你需要在这时候用这种手段击败其他的对手取得客户的投资。
未完待续……

mark
一下。
很真实的。

w我也mark

不错,不错,很多情况我都是遇到了的.很符合实际.
写出来给大家看看.结合自己,结合公司的发展,调整自己.

我也mark