程序員遇上頻繁改需求的甲方,究竟會擦出怎樣的火花?懂的都懂

程序員説:我不討厭改需求,討厭的是頻繁地改需求。

程序員説:我不討厭頻繁地改需求,討厭的是頻繁地改完需求後,工期卻不延長。

改需求不可怕,可怕的是工作量加倍,其實程序員最終的訴求是延長工期,畢竟只掙一份工錢。

程序員遇上頻繁改需求的甲方,究竟會擦出怎樣的火花?懂的都懂

第一個項目,只是純粹壓縮時間

當時接手的第一個項目,是做一個在線的課件,可以即時通訊,收發作業,在線筆記,在線考試。

第一期,只把在線的課件做出來,其它的先不做,因為要做發佈會。

發佈會前夜,通宵做東西,程序是外包的,那晚才知道,工期對方報的兩個月,後來壓縮至兩個星期。

我説呢,為什麼這麼厲害的團隊只把東西做成這個樣子,但這個項目是老闆做的第一個項目,奠定了以後頻繁改需求的基礎,因為,在他眼裏,兩個月的東西,既然能壓縮到兩個星期,那説明報的時間都是有水份的,可以加班無限壓縮程序員的時間。

程序員遇上頻繁改需求的甲方,究竟會擦出怎樣的火花?懂的都懂

第二個項目,三個月的活壓縮到一個月,這一個月改需求改了三個星期

第二個項目,還是外包的,找了一個兼職的團隊做,前期由於提的需求沒有提到以後可能會多個學校用,程序員那邊就沒做成多校區的架構,只能一個校區用。

課程準備做品牌之後,由於以前的功能太弱了,加了不少需求,項目對方估算三個月完成,這邊需求一個月,本來一個人做這個項目,因此就另外引進兩個人來,那麼,接下來,就是麻煩的開始了。

在已經壓縮的時間下,對方是馬不停蹄的寫東西。

之前説過,程序員一般都很實在,讓做東西,改東西,只要改的不大,基本上都會給改的,很好説話,但這就造成了外行以為,改需求的成本很少。

由於那兩個人沒有預料到改需求會是這麼得頻繁,就一遍一遍的改,後來感覺不對勁,提出疑問,得到的回答是:“做出來的東西沒法用還做他幹嘛?”

程序員遇上頻繁改需求的甲方,究竟會擦出怎樣的火花?懂的都懂

小夥伴們,你們遇到這樣的客户你們會怎麼處理?

繼續説後邊的,需求一直改到第三週,後面一週沒有再改東西,原本定的一個月後,提交代碼,測試,原定的需求只做了這一部分,畢竟真正開發時間就這一個星期。

然後,甲方、客户方、也是就是我們老闆,説了一句很傷人的話,“程序員這一個月沒做出什麼東西來,不給結錢”。

程序員當然不幹了,不結錢就刪代碼,後來是接這個項目的人做雙方的工作,先把錢結了,剩下的功能他來接着做。

這還不是最誇張的,誇張的改需求是我寫的項目,本以為老闆已經在這個項目上吸取了不少經驗,後來證實,我真的是太幼稚了。

程序員遇上頻繁改需求的甲方,究竟會擦出怎樣的火花?懂的都懂

第三個項目,朝令夕改

由於老闆得罪了人家,又找不到程序員來做,我和另一個同事夾在中間,很是痛苦,那時候是創業公司,也沒錢,就自己學了學ruby,開始自己做項目。

團隊嘛,一個人,沒有UI,沒有前端,一個開發,就是我,沒有測試,沒有運維,沒有客户,沒有培訓團隊,一個人幹完一個項目。

上線後,團隊經過一段時間招齊了,後來老闆要提個新需求,我問他,公司裏誰明白這個系統,得到的回答是整個公司只有他明白要做什麼。

這個不奇怪,為公家辦事,大部分人只是在處理上邊下來的任務,很少有人會去思考應該做什麼。

第一天提完需求,第二天我給做完80%,因為用的是敏捷開發,而且做的是B端業務,我對這塊業務是要比老闆還熟悉的,所以做的很快,這個需求很早就想做了,只是原本打算開啓的時間要靠後。

程序員遇上頻繁改需求的甲方,究竟會擦出怎樣的火花?懂的都懂

第二天晚上,給他看半成品,當場改需求,我讓他重新提,再見一次面,得到的回答是我以為你昨天聽懂了,我問他,你確定昨天説的和今天是一樣的?

得到另一個回答:“之前的功能太簡單了,沒法用!”

如果你做過銷售的話,就看出問題來了,避開話題,總是重新提話題,從來不是自己的問題。

小夥伴們,你們遇到這樣的產品或老闆嗎?大家討論一下,都有什麼招可以回應。

版權聲明:本文源自 網絡, 於,由 楠木軒 整理發佈,共 1473 字。

轉載請註明: 程序員遇上頻繁改需求的甲方,究竟會擦出怎樣的火花?懂的都懂 - 楠木軒