[請益] 開發流程中面對客戶需求

[xo1100 (蝦蒸河粉)]

各位前輩大家好

小弟想請問各位在開發的專案流程中

面對客戶需求變動是怎麼處理的



因為小弟所認知這狀況的處理

跟實際公司的處理有所落差

有點不清楚這是個案還是當今環境就是如此

也不知道比較正確的流程是如何QQ



小弟所認知的正常程序

是在合約簽訂的時候先確認好規格

擬個清單雙方簽名

之後會議討論功能驗收與先前約定有出入

需要加大小功能

(小至增加資料欄位抓取大致添加發信推播功能)

再另行至相關的報價流程

之後也會有相關的確認單請對方做簽名做紀錄



而目前的狀況是

流程是在合約簽訂進來後

才進行需求確認與訪談

會議記錄與驗收只有紙本報告要改的需求

然後就出現了一改二改三改四改

而四改做的是當初二改的原型......

不然就是當初對方看完規劃對這沒太多想法

照規格書完成後客戶靈感如雨後春筍般萌生 (os:X......)

於是產生這狀況很明顯就是有問題的疑慮

卻不知道如何提出比較好的方法

小弟至今也只是入行一年多

身上的菜蟲還沒拍乾淨

也不確定所預想的流程究竟是不是正確的





所以想上來請問版上的前輩看看

要怎麼修正流程才能處理這方面的問題呢




--
→ noocar:看到ID讓我想嘔吐
→ id:我有這麼噁嗎
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.143.7.179
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1493626831.A.474.html
推 buper: 看到id讓我肚子餓
推 NDark: 公司有肩膀跟成本觀念 就不會讓客戶一直改規格不付錢.
→ NDark: 相反地 假如改越多 客戶也會付錢 幹嘛不改(台灣挖馬路例子)
→ NDark: 比較悲慘的情形是 公司有賺錢 可是都被上層吸走了.
→ NDark: 從資本主義的角度就是"因為他們承擔了風險".
→ NDark: 誰叫工程師自己出去單幹拿不到單.
→ NDark: 總之,沒有甚麼正確流程的,只有該公司高層覺得正確的流程.
推 fowei: 你的認知是對的, 但實務上不容易. 目前業態就是如此
→ fowei: 但有能力的PM. 就會允許小改. 做人情. 而大改再報價.
→ fowei: 通常..都是案子趕不出來時. 就是對方同意延期.我們同意修改
→ ChungLi5566: 這是PM的事,PM不夠硬的話專案永遠無法驗收
推 FrAnKw: 專案管理思維的東西建議去修修PMP，培養一下sense
→ FrAnKw: 有理論基礎加上實務經驗多了自然知道該如何判斷
→ FrAnKw: （判斷目前這家公司還值不值得待XD）
→ FrAnKw: 畢竟小螺絲釘比較難改善公司體制上的問題或陋習
推 x123356: 自己變強離開接案公司才是真的
→ x123356: 想改變這些是不可能的 修修改改當作磨練吧
→ thinkniht: 反正工程師加班免錢 讓客戶爽才實在
→ pttworld: 其實自己夠強也不會進這公司，基層就只能認了。
推 now99: 一直改要小心工程師跑光光,然後就出包了XD
→ readonly: PMP 修一修
推 mapleone: 先簽約再做需求訪談正常
→ airtsubasa: 就算做到，你老闆一聲令下也是要改，翻盤啦
→ wuliou: 我還碰過超高層主管直接下令到底層單位要改的
→ wuliou: 有夠無言
推 mintu: 台灣好像不太能接受工時數的方式計費，而不是依照 project
推 SKII588: 還有東西做出來了，才跟你說要這樣要那樣的客戶
→ yyc1217: 其實再大改很正常 畢竟有時連客戶自己都不知道要什麼
→ yyc1217: 但台灣很少人把這部份視為成本 並且在契約中明定期限的
→ yyc1217: 個人覺得最好的方式就是每個階段分開簽約
推 guest0710: 可是別人肯包一起 你想分開的就拿不到案了...
→ manaup: 所以要先收30%以上的訂金啊
→ manaup: 要不加錢改 要不甲方單方面終止合約訂金不退喔
推 wildli0422: 太有感觸了QQ 做到死的底層碼農負能量滿點阿