專案開發二三事


不知道從什麼時候開始,看specification,寫schedule的時間已經遠遠超過寫code的時間…

去年求職時,是想過如果有機會的話,嘗試帶人帶看看,可以知道自己究竟適不適合這樣的角色─畢竟一直以來主要是從技術面進入軟體業,雖然曾經在不知不覺間變成系統整合 (System Integration) 產業的FAE,雖然曾經多少藉由參與ISO、CMMI的軟體開發評鑑了解一些管理知識,但那些一知半解、以管窺天的片面資料,是不是真正能派上用場,我當然也沒有把握。

在參與了兩個專案,凍結了一個專案之後,也許是「蜀中無大將,廖化做先鋒」吧,還真的如願以償─下場是,現實狀況比我所想的更嚴峻許多:帶人已經不容易,而要帶的還不只是人而已。研究型的專案,必須先期閱讀技術文件,必須規劃專案進度,必須構思軟體架構,必須維持軟體品質,必須兼職程式教練,還必須協調一些專案以外的事項,把自己所有的軟體開發相關經驗都用上,似乎都還不足以應付…

所以不知不覺間,好像具有了其他能力,自己找到答案的能力。

一件一件來看:

  • 我的個性還是喜歡研究,可能也是因為這樣,看技術文件總是衝第一個然後變成砲灰,嘿。這我並不排斥,只是總是會想,這種模式對嗎? 只有一個人掌握specification全貌,其他人全部都透過這個人的理解去進行開發的風險就是,如果理解有誤,那就是一子錯滿盤皆輸。在如果有更多資源的團隊裡,想來應該是儘可能有複數成員進行先期研究及討論,才能讓專案方向比較不容易發生太大的誤差。不過以現在的狀況來說,也只能且戰且走了,但至少,虛心以待,懷疑自己這點要時時保持,能夠隨著現實環境調整專案內容並修正錯誤。
  • 專案進度的規劃是不得不然,但其實研究型的專案進度也最難以預料─姑且不論專案成員的能力,因為既然稱之為研究型,就代表專案中有某部分的主題或該領域後續進展並不明朗,不確定的東西要如何合理的規劃進度? 我想這是我目前面臨的最大難題。但似乎就算是在最進步的美國軟體業界都還是會碰到這樣的問題,看來對我這種菜鳥來說也是當然的。Anyway,作文還是得寫,進度還是得交,剩下的我也只能聽天由命而已。
  • 軟體架構跟軟體品質感覺是一體兩面,而我在專案裡最大的樂趣,也通常都是定架構並實作出來這件事。規格就在那裏,需求也隱隱浮現,對於軟體工程師來說,能夠訂出彈性而有效率寫起來又漂亮的架構,似乎是唯一可以發揮的地方─我這樣想到底會不會是走火入魔? 其實我不曉得。不過至少我知道的是,越有彈性的架構可能帶來效率的減損,執行時期越快的程式碼可能更沒有彈性或寫起來非常的難看,所以在一番複雜的trade-off之後,最終只留下一個原則:越簡單的程式越容易維護,也越不容易出錯或容易除錯…簡單,就是美。
  • 架構得好,其實軟體已經無形中獲得了一定的品質。但如果要引入軟體工程的層面,架構也還只是一部分而已。我必須承認,舊有的程式碼品質是要求軟體品質的一個主要因素─那種學生作業類型的程式碼實在讓我看得太痛苦了,光難以維護就會是一個不得不面對的議題,已經有很多議題限於人力無法立即處理,但新專案就讓它是一個嶄新的開始吧。軟體工程其實不應該是封閉在自以為是的象牙塔中,或者像ISO、CMMI那樣的流於形式,UML是軟體工程,version control system是軟體工程,naming rules是軟體工程,coding style是軟體工程,code review是軟體工程,testing是軟體工程,所以整套實際的開發流程都可以整合軟體工程─視不同的環境因時因地制宜而已。\
  • 教寫程式這件事一開始也是有點挫折的─公司需要業績的話,專案不是應該要快嗎? 那是不是我自己寫還比較快? 後來慢慢就釋懷了…不管管理階層有沒有意識到訓練成本的問題,如果政策方針就是要帶新人,那我就帶,鉅細靡遺的把一些我認為軟體開發應該要有的觀念跟技術傳授下去,不過相對而言,專案進度就沒什麼妥協餘地了─新人的訓練成本總不能要我自己吃下去吧? 至於教學的過程來說,我想目前我還算不上是個好老師,這方面我也從來沒期待過我自己就是了…從專案管理 (Project Management) 的角度去看,應該是什麼材料都可以炒菜吧,差別只是在於要花多久的時間或品質─不過如果只給我肉屑要做出魚翅,那就請你自己想辦法了。
  • 專案以外的事情林林總總,不過基本上不脫人力資源的範疇─該不該要求專案成員加班? 這就又牽涉到另一個問題─我這個無權有責的project leader,真的可以稱之為專案經理嗎? 有壓力下來,如果我手上有什麼資源,也許我就可以去要求成員付出,並進而給予他們應有的bonus,但問題在我手上什麼也沒有,只有某塊一畫再畫的大餅,連充飢都有問題,是要叫人家付出什麼? 到頭來也體認到這種Project leader的title如此廉價,認真就輸了,如果我終究沒有什麼credit,那也就只能做自己能力範圍內的事情啦。

做著做著,慢慢覺得,帶兵帶心這種事似乎是天生的領袖才能,後天的管理技巧怎麼學也很難到達那個高度。我可以磨練的,或許還是做事的方法:就是自己去找答案吧。可其實人生並沒有標準答案,很多時候我找到的也只是就我目前思慮所及的較佳解答,但能一點一滴的釐清問題,讓事情一步步前進的感覺也很奇妙─那是以前只知道執行命令的時候無法體會的。

不斷發覺自己還在成長,也許,真的要感謝那停下來面對自己的ㄧ年半:不管是台灣這塊土地或是澳洲寬廣的大陸,都似乎教了我很多東西呢~

About David Yang

David Yang, like sports, nature, reading, music and...traveling. I am not good at sports, but like watching basketball, baseball and tennis games. I am not very strong, but like hiking, bushwalking and riding bicycle into the nature...Although I am a software engineer. Not only continue to read and gain knowledge, I also want to walk around every corner of the world. Here are some stories about my itineraries: https://dflucifer.wordpress.com/ I come from Taiwan...no matter where you meet me, either I am traveling, or just preparing for next trip :-)
This entry was posted in 產業現況及社會觀察, 軟體工程 and tagged , , , , , . Bookmark the permalink.

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s