需求描素不是照書本就會的
要先將 [畫面][報表] 作出來
再給操作確認流程
再轉成[規格表]發包
就是 [人力外包] 就是依照試做程式 [複製] [替換物件]
不是 [技術外包]
[人力外包] 就是發包者要很清楚知道 [架構][功能]
[人力外包] 就是發包者要很清楚知道 要怎麼寫, 寫在哪裡
以下:
以下文章來自:
http://www.ithome.com.tw/itadm/article.php?c=70643
以前曾經參與過一個專案,這個專案在臺灣做需求分析的工作,之後的開發則移到上海做後續的設計、實作及測試。分析的規格文件可以說是十分的詳盡,厚厚的一大疊,兼之以運用當時最流行的UML塑模技術。可是,即使如此,當上海開發團隊依據規格文件開發完成系統、交付回臺灣之後,準備開始進行使用者接受度測試時,客戶端的使用者才發現,做出來的東西和他們想像的不太一樣。而且,因為已經到了開發週期的尾端,這個時候才來開始修改系統,需要付出的代價更為沉重。
cdfu提到:
海綿寶寶,看來您還是沒看懂阿伯大的意思
antijava提到:
如果問到、學會就算我賺到了喲
antijava提到:
印象中到了Windows/Web時代之後
就很少看到程式規格了
就算有規格
寫出來的結果誤差都蠻大的
albertachen提到:
技術轉移顧問
要將程式碼附上
[委外人力]只可以抽換 [物件/Table] [方法/Column]
你專案扮演的角色?
檢討別人總是容易
你想到的,人家都想過了
本來專案過程中就會出現一些有的沒有的問題
我想這些問題都在相關點找到最適當的解決方式
有些人喜歡用結果論去評論人家
有些人用第三者的眼光去評論
你以為人力那麼好找嗎?
技術那麼好做嗎?
你這些都考量,全部齊全了
案件早就被別人標走了