推 zazard:我只能說個人在前公司 一些博士級經理想推動軟體開發流程 04/04 01:58
→ zazard:過程都會受阻了 何況是小小蝦米的RD 04/04 01:59
→ sunnypeng:爛軟體公司，甚麼公司請甚麼人 04/04 10:32
※ 引述《steve206241 (stevehan)》之銘言：
: =============================抱怨結束==============================
: 綜合上面的爆點大概如下
: 1.設備老舊卻裝載消耗資源的VS2005 + SQL2008，好像跑不動是因為自己不準備新筆電
我覺得這個可以持續提出來，公司提供良好的設備是必要的。
: 2.設計規設計，功能歸功能，資料庫歸資料庫，各司其職，我碰到的卻除了DB的建立
: 與圖片的製作不是自己外其他通包
這個很常見，只要是人力不足的情況這種事情常常發生。
: 3.至少運作3年的專案基本上技術文件量基本上會扎實龐大，讓接續的人不必耗時費工，
: 我並沒有碰到
: 4.做了這麼久的資料庫，開了這麼多的資料表，寫的這麼簡易的解釋內容，卻沒有思考架
: 構圖，就像是整個的秘密只有我知道
: 5.沒有規劃時間，進度，詳細規格，潛在的危機一直圍繞卻沒反應
: 6.龐大的變數量和代號量沒有直覺化反應也沒有文件支援，完全就自行摸索
: 7.搞不清楚到底哪個效果才是實際的依據，一通電話幾乎可以"再微調"的狀況
歡迎來到業界的真實。
你認為一個軟體公司什麼是最重要的？
建立良好文件資料？
專案規劃詳實，設計文件完整？
正確應用 design pattern ?
不對喔，上面說的都是屁！
一個軟體公司最重要的，就是讓股東賺錢。這是唯一的目的，其餘跟這個目的無關的
都是可有可無的東西。跟這個目標相違背的，都應該要徹底被消除。
OK，我假設原po是剛自學校畢業的職場新鮮人，可能在學校當中吸收了不少軟體規劃、
開發的知識，也很樂於導入這些軟體工程的概念。但是請謹記一句話，公司開門就是要
賺錢，你的所作所為能夠幫公司賺錢嗎？
今天專案就是面臨到 300%的工作份量，而時間一點一滴流失，為了最後能夠成案，勢必
要有所犧牲。你手上todo list就是這麼多，那些東西要被放棄，你自己要有盤算。
今天如果是個絕佳的專案，有非常多的時間跟數不完的後援，當然可以做出一個從文件到
程式全部bling-bling的專案。但是現實上這種perfect case跟本不可能存在阿，作為一個
RD，事情都有priority，本來就是要在 resource/schedule之間取捨，要能夠在最經濟的
情況下達到最高的成果。這一點請你自行思考。
當你發現前輩寫了一個很爛的code的時候，不要只看問題的表面，更該思考問題後面的問
題：是否當時專案碰上很嚴重的設計瑕疵？或者時程非常超乎想像？碰上人力大退潮？
當然我希望問題很單純是因為寫code的是個爛RD，但往往事情不是那麼簡單，旁觀者總是
能夠(自以為)認清問題的本質，但是要跳下去之後，才知道這是個tar pit。
--
well....一開始我原本是想給你一些建議，但是很抱歉後來寫得有點陰暗。
但我的重點是，業界寫軟體很多時候都要遭受一些"非技術"困難，在一家公司碰到的
也會在其他公司碰到...如果一家軟體公司能夠活著兩三年沒倒，表示本身一定有過人之處
(也許是技術性或非技術性)，我想實戰經驗對於新人來說是很重要的，多打怪練等總是有
好處...當然，如果公司技術爛又不賺錢，那還真的別待了。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.160.18.180