Re: [請益] 這樣的方式我應該如何選擇
※ 引述《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
推
04/04 01:58, , 1F
04/04 01:58, 1F
→
04/04 01:59, , 2F
04/04 01:59, 2F
→
04/04 10:32, , 3F
04/04 10:32, 3F
討論串 (同標題文章)