K
kt133
Unregistered / Unconfirmed
GUEST, unregistred user!
小程序员的眼光
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后面。
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后面。