技术开发 频道

需求的陷阱——恶梦

【IT168 技术文章】

    最近做的一个项目,上个公司做了一年半,放弃了.原来定三个月完成,我们又做了一年半多,还离结束遥遥无期.老板都急了,有什么办法.公司给客户的权限是想提什么要求都可以,需求/设计,甚至人员调配都是客户说了算,惹不起啊.只有总结为什么完不成的时候,是开发人员的责任,扣奖金.有时候一个需求可以反复做几遍,只要客户乐意,前面提的要求,用不到一天就又变了,返工是家常便饭.

    而且,只要改动不论大小,即使是改一个按钮文字,都要在改好之后给客户演示一遍,并且讲一下改了什么(人家提完要求就忘记了啊).最大的特点是客户是个领导,但是按照他的要求做的程序,下面的人不买账,人家不用啊.开发人员还要求爷爷告奶奶的去让人家用.有的钉子户坚决不用,项目一拖再拖.

    这项目做到这份上,博主帮忙分析一下,谁之过?项目如何才能结?

    昨日的需求的陷阱-简单不简单的评论中,有一位朋友写下的评论。看我之后我感觉这个话题有点沉重,项目该如何处理,或许不是一两句话可以说清楚的。不过对于任何人来说,遇到这种项目就像遇到鬼一样可怕,完全就是一个恶梦的开始。

    对于如何处理这个问题,可能需要从多个角度来说这个这个问题,老板,项目经理,开发人员。每个角色不一样,出发点也就不一样,所以问题不能一概而论。

    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年半的痛苦煎熬,我们的主管从开始怀疑我们的能力,到干脆对我们不报任何希望,到最后的真相大白.我们要承受多大的压力.

    谈需求,是建立在对方需要你来帮助解决问题的先决条件上的,如果没有这个先决条件,也就没什么可谈的了

    在这种破坏为前提的开发中,我们除了无奈之外还是无奈。就像很多人在做项目中,遇到很多带有国情特色的问题,对于这些问题的处理,我相信是所有的软件工程书籍中所没有的。因为本身已经超出了技术的范畴,所以对于这些事情除了用小道消息共享经验之外,就是看个人的做事魄力,所有的技术以及规约再其中已经显得可有可无,这个可能是需求的最大的陷阱,不过我还是相信,随着国家的发展以及相关人员素质的提高,这些问题会慢慢减少。我们希望在将来讨论的主要是项目因素上的需求陷阱,而不再是这种抱怨与无奈。

0
相关文章