小余

     最近做的一个项目，上个公司做了一年半，放弃了．原来定三个月完成，我们又做了一年半多，还离结束遥遥无期．老板都急了，有什么办法．公司给客户的权限是想提什么要求都可以，需求／设计，甚至人员调配都是客户说了算，惹不起啊．只有总结为什么完不成的时候，是开发人员的责任，扣奖金．有时候一个需求可以反复做几遍，只要客户乐意，前面提的要求，用不到一天就又变了，返工是家常便饭．
    而且，只要改动不论大小，即使是改一个按钮文字，都要在改好之后给客户演示一遍，并且讲一下改了什么（人家提完要求就忘记了啊）．最大的特点是客户是个领导，但是按照他的要求做的程序，下面的人不买账，人家不用啊．开发人员还要求爷爷告奶奶的去让人家用．有的钉子户坚决不用，项目一拖再拖．
这项目做到这份上，博主帮忙分析一下，谁之过？项目如何才能结？
    昨日的需求的陷阱--简单不简单的评论中，有一位朋友写下的评论。看我之后我感觉这个话题有点沉重，项目该如何处理，或许不是一两句话可以说清楚的。不过对于任何人来说，遇到这种项目就像遇到鬼一样可怕，完全就是一个恶梦的开始。
对于如何处理这个问题，可能需要从多个角度来说这个这个问题，老板，项目经理，开发人员。每个角色不一样，出发点也就不一样，所以问题不能一概而论。
 1.老板
    如果你是老板，你接到这样的单子，而且做到这种程度，那么首先要反省的人应该是你。为什么要接着个单子，有什么直接的利益关系。如果说整个公司就等着这个开锅的话，或者说这个项目的后续还有源源不断的新项目过来，那么尚且情有可原。因为从老板的观点出发，今后需要生存和发展，不得以而为止。但是如果情况不是这样的话，这个项目只是一个可有可无的项目，而且也看不到有什么将来，项目从预计做三个月到一年半，这样的项目应该说明显处于亏损严重的状态。先不考虑其它的因素，从经济的观点来看就要把这个项目想办法放弃。
不过不管项目的出发点如何，单就“公司给客户的权限是想提什么要求都可以，需求／设计，甚至人员调配都是客户说了算”这一点就直接表明老板的做事有问题，做为软件开发公司，搞得像外卖人员一样。公司的管理上就有严重的问题，而且更可怕的是且也缺乏魄力和自信心。如果公司不改善这种现状，老板还不如回家卖烤红薯，不必开一家半死不活的公司，自己劳心劳力，还害的一群员工没日没夜瞎忙活。
2. 项目经理
    对于出现这样的项目，项目经理只有被骂的份。本身项目经理就是处在老板和员工之间的一个中间成，不但起到项目管理的作用，同时也控制整个项目，还兼当老板和员工之间的缓冲层的作用。
项目经理本身就要想办法控制这种变更频频的事情，即使由于国情特色等因素做成项目如此，是你无力控制的。但是你还需要做很多的事情来改善这种现象，
    1）让客户所有的变更有记录，签字。不管对方愿不愿签这个字，作为项目经理就要做这件事情。让客户的无理得到纪录，同时由于签字会对客户多少有点警示的作用，可能因为执拗不过客户，这就需要项目尽力的魄力和技巧。这些东西都可以作为秋后算账使用。
    2）需要明确问题的责任，如果是客户的问题造成的，就要据理力争，维护开发人员的利益。必要把开发人员作为黑锅来用。
    3）对于需求的控制，有时候一个需求可以反复做几遍，只要客户乐意。但是必须合理化这些需求，如果意境做过的话，就要避免再次开发。可能我们拗不过客户，但是项目的本身还是要想办法控制。
    4）对于团队的士气和人员的安抚工作不到位，要为每一个团队成员考虑他们的出路，同时给他们一个希望。无论是薪金还是技术上都要为他们想想，如果项目是被迫要做，争过了，吵过了，还是无力回天。项目经理只要需要安抚人员的心情。
项目做成这样如此，可以看出项目经理也是失职不少，没有为开发人员考虑，可能也没有和上面争吵过，这样的项目经理可能就是挂牌经理，对于项目来说也是败笔之一。
3. 开发人员
其实作为整个过程中，开发人员最为无辜，本身就处在最底层，遇到问题就是叫唤吵闹也没人理。可能所能做的就是在看不到希望后另谋高就。开发人员我没有办法评价太多，因为其工作比较单调，只要能够按照规定和要求把开发工作处理好了，也算是符合公司的要求。在整个过程中，开发人员是最直接的一个受害者。不论任何开发人员参与了这样的项目，我想所遭受的结果都会是一样，心灰意冷。如果项目和公司都看不到希望，那除了选择新的出路还能后什么？毕竟是努力了一年半之后还是这样，错不在于你们。

其实我们现在谈很多的需求的都介乎一种理想的模式来讨论，但是有时候项目遇到项目以外的因素的时候，项目就显得很无奈。比如Vincent朋友提出的
记得我在一个企业做mis的时候遇到过类似的问题:
1,部门主管A要求上一个系统方便对下属子部门工作效率的考核,所以提出需求来开发系统,此时我们面对的客户是A.需求也只是A.
2,当实现了A的需求后,要求部署下去,让各个子部门去应用,并完善系统.
3,子部门领导B,认为这个系统对他们来说并不会提高什么,反而自己的工作还被上级更有利的监督起来.所以他从思想上是不希望这套系统能够部署起来的.
4,B在看完系统的演示后,提出需求,我们开始修改.
5,由于B是反对上系统又迫于压力不能直接反对上级决定的情况下,每次新需求修改结束后,他都会提出新的问题要求继续修改.
6,mis部门主管询问,为什么这个系统经历这么长时间还不能上线,B回答"你们一直都没有开发完".
7,1年半后,部门主管A发现B的工作有问题,辞退了B.由此我们才被真正的解放出来.(辞退B由于别的原因,而在辞退B后A才明白原来B一直在为这个系统的开发人为的制造障碍.)
8,我们经历了1年半的痛苦煎熬,我们的主管从开始怀疑我们的能力,到干脆对我们不报任何希望,到最后的真相大白.我们要承受多大的压力.
谈需求,是建立在对方需要你来帮助解决问题的先决条件上的,如果没有这个先决条件,也就没什么可谈的了
    在这种破坏为前提的开发中，我们除了无奈之外还是无奈。就像很多人在做项目中，遇到很多带有国情特色的问题，对于这些问题的处理，我相信是所有的软件工程书籍中所没有的。因为本身已经超出了技术的范畴，所以对于这些事情除了用小道消息共享经验之外，就是看个人的做事魄力，所有的技术以及规约再其中已经显得可有可无，这个可能是需求的最大的陷阱，不过我还是相信，随着国家的发展以及相关人员素质的提高，这些问题会慢慢减少。我们希望在将来讨论的主要是项目因素上的需求陷阱，而不再是这种抱怨与无奈。