iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 7
0

本以為SM的案子就結束了,RJ打算讓其他人休完假後,再趕因為SM簡報造成已經有點落後的其他案子。大老闆Servo心想的是將這幾日得到的心得變成公司的資產,如何藉由其他六位已經有理論基礎的同仁,一起推廣成公司的基本功。Servo自我安慰:這個案子沒拿到,也許反而是好事,讓公司有機會改變聽命行事,低價搶單的代工模式。

大家意外的是簡報的隔週,SM公司 CIO 約Servo非正式聊一下。

“Servo,那次會議你談到 Unified Process 是否是 Jacobson 的 Objectory Process? 我請同仁深入了解,現在似乎沒有Unified Process這樣的說法” SM 的 CIO 其實在會場上已經看出大佬對 Servo 以及T軟很有興趣,當然不是因為Servo帥,而是他提出一套思維或是他宣稱的 Process,似乎是可以解決SM軟體開發要上線前總是突然發現有些問題,而且每次事後檢討,問題永遠都是用戶需求不明確呢!所以會議一結束,馬上召集主管會議,要求針對Servo 所說的 “Unified Process” 做深入研究。

“個人的確是受Jacobson Objectory Process影響很大,但是我堅持還要用 UML來輔助,所以我簡稱為Unified Process” CIO 是專家,Servo 清楚這樣的回答就夠了。

“我印象你有次跟我解說貴公司利用 UML Use Case 來做需求分析設計的工作,經常可以意外挖掘出需求背後的需求,而且這種一不小心就被忽略的隱藏需求,常讓專案實施宕延。我理解你說的UML 應該是指這個機制”。CIO 是聰明人,知道從供應商學東西,有時比找顧問上課實用許多。

“的確是,當時UML還沒有定案時,我覺得一些圖示對我們做物件導向程式開發實在太重要了,在我們公司這幾年就陸續推廣,多數同仁都以為其中的 Class Diagram 最有用。但是以我的角度來看,源頭卻是 Use Case。UML 幾個技術環環相扣,若以管理,專案成員,客戶等多個角度來看,都有其重要性。所以我反而不特別指名 Use Case”。

“你簡報的 Unified Process 是針對我們公司這個案子?” CIO試探性問一下。

“坦白講兩三週前,我是為了爭取案子出奇招,但是在準備簡報過程中,深深思考過去T軟遇到的困難,我已經在規劃要在半年內變成我們公司員工必備知識,我給自己的檢驗標準是未來一年,新接的案子必須有五成以上採用Unified Process。” Servo工程師出身,喜歡直來直往。

對於已經彼此信賴的夥伴不必隱晦。

“我口頭非正式的邀請貴公司加入我們這個案子,有兩個模式:當環球管理顧問公司的下包,這個我與環球管理顧問公司閒聊過,他們以前跟你合作過,很喜歡貴公司。或者你也可考慮獨當一面。”

“CIO你清楚當這種國際公司下包的軟體開發案的窘境,我寧可不接。現在我們承包小案子,利潤不高,但穩紮穩打,日子也過得去。”

“但是這個案子估計是需要近600人月的工作量,以一年專案時程來看,平均要有五十位同時作業。幾乎是現在貴公司的規模,你怎麼因應?”

“第一:傳統專案作法,先集合一群人,卻因各種角色工作量高低峰的差異,常會讓一堆人處在閒置的狀態,Unified Process 可緩解此問題,另外我正在推動師徒結對開發制,可解決人員調度問題”。幾年後,當Servo聽到 RJ與Gavin 聊 XP, Extreme Programming, 又覺得有點不平:為何沒人或文件記下是他先提出 Pair Programming的,儘管兩者立意差距頗大。

經過來回多次的拉鋸,T軟獨立承攬了SM該軟體開發案,雖然合約限制兩年內T軟不得承接SM競爭對手案子,但爭取到專案成員超時工作可額外報銷加班費。這一年是兩家公司的 UP元年。


上一篇
海闊天空談風險
下一篇
天馬行空看 UP與Scrum
系列文
UP, Scrum 與 AI專案31

尚未有邦友留言

立即登入留言