找出專案的潛在問題
最近因為一些公司的專案忙得昏天暗地,剛好前陣子是TechDays,整個重心都放在TechDays上,又同時得顧及手上的一些專案工作,實在是有蠟燭兩頭燒的感受,很多事情即便列出優先順序,卻發現實在是時間不足,我常常有一早起來,坐在電腦面前,突然間一天就過去了的經驗,一整天都處於緊繃和忙碌中,偏偏email又一直來,突發事件不斷...似乎沒法喘口氣釐清一下事情的整個狀況。
回顧十多年的軟體開發生涯中,偶而會陷入這樣的情境中,這時候除了救火之外,找出問題的核心變得相當重要,我想起過去一個前輩告訴我的,他分享了他的經驗,因為每一個主管手上的專案和工作都相當多,實在沒有辦法深入到每一個項目中。可是,如果不深入到項目中,怎麼能發現問題在什麼地方呢? 怎麼發現專案哪邊可能有潛在的問題? 並且提早處理呢?
我之所以會突然想到這位前輩的經驗分享,是因為我最近就碰到了這些問題,手上同時有很多專案,坦白說我沒法深入每一個專案,但是畢竟我是負責這些專案的管理者,我得要能夠預先發現問題,確保專案能夠順利進行。
這時候,『問對問題』變得很重要,過去的經驗讓我發現,確實有很多主管問的問題都一針見地,立刻可以掀出專案潛在的問題,讓可能發生的意外無所遁形,我過去以為這些PM大概天賦異稟或是有常人沒有的洞察力,但是我後來發現,其實似乎也有一個方式可以遵循。
其實道理很簡單,當年,那位前輩各訴我,當你發現某些地方越被找理由蓋起來,那些地方就越要掀開來看,包含主管自己對自己的要求也是一樣,人都有惰性,你發現自己越不想碰的問題,越表示那些地方將有著大問題,甚至,有些其實是自己潛意識根本不想去碰的部分。做主管的得要能察覺這些現象。
自己寫了多年的程式碼,也帶了多年的專案,越來越覺得真的是這樣,當某些模塊,在專案討論的時候,總是被成員找理由(理由多半是很合理且冠冕堂皇的)跳過或是忽略,當時程總是被粗估簡化,當驗收條件總是被模糊化,系統流程好像不是很solid,那很抱歉,這些地方多半都有著嚴重問題,特別是我們(開發人員)很喜歡把規格模糊化,或是你在進行專案會議時,發現針對某些部分專案成員的回答似乎總是有些不很確定,那幾乎可以斬釘截鐵的肯定告訴你,這表示這些地方將來真的會有大問題。
大多數主管其實心裡也知道,只是因為自己也很忙,所以下意識的跳過了,想說算了,下次開會的時候再盯一下,這時候千萬要提醒自己,別忘了這一塊肯定是有問題的。
過去的經驗告訴我真的是這樣,自己潛意識越是不想打開的那段程式碼,裡面暗藏著越多的bugs,在一天的工作計畫中,自己越不想去碰的那塊,越是會出問題,反過來說,如果你專挑自己越不想碰的事情先做,越能夠讓一天的工作順利進行,想想還真的是這樣。
道理很簡單,大家都懂,只是要下定決心去做,似乎還真不容易。
回顧十多年的軟體開發生涯中,偶而會陷入這樣的情境中,這時候除了救火之外,找出問題的核心變得相當重要,我想起過去一個前輩告訴我的,他分享了他的經驗,因為每一個主管手上的專案和工作都相當多,實在沒有辦法深入到每一個項目中。可是,如果不深入到項目中,怎麼能發現問題在什麼地方呢? 怎麼發現專案哪邊可能有潛在的問題? 並且提早處理呢?
我之所以會突然想到這位前輩的經驗分享,是因為我最近就碰到了這些問題,手上同時有很多專案,坦白說我沒法深入每一個專案,但是畢竟我是負責這些專案的管理者,我得要能夠預先發現問題,確保專案能夠順利進行。
這時候,『問對問題』變得很重要,過去的經驗讓我發現,確實有很多主管問的問題都一針見地,立刻可以掀出專案潛在的問題,讓可能發生的意外無所遁形,我過去以為這些PM大概天賦異稟或是有常人沒有的洞察力,但是我後來發現,其實似乎也有一個方式可以遵循。
其實道理很簡單,當年,那位前輩各訴我,當你發現某些地方越被找理由蓋起來,那些地方就越要掀開來看,包含主管自己對自己的要求也是一樣,人都有惰性,你發現自己越不想碰的問題,越表示那些地方將有著大問題,甚至,有些其實是自己潛意識根本不想去碰的部分。做主管的得要能察覺這些現象。
自己寫了多年的程式碼,也帶了多年的專案,越來越覺得真的是這樣,當某些模塊,在專案討論的時候,總是被成員找理由(理由多半是很合理且冠冕堂皇的)跳過或是忽略,當時程總是被粗估簡化,當驗收條件總是被模糊化,系統流程好像不是很solid,那很抱歉,這些地方多半都有著嚴重問題,特別是我們(開發人員)很喜歡把規格模糊化,或是你在進行專案會議時,發現針對某些部分專案成員的回答似乎總是有些不很確定,那幾乎可以斬釘截鐵的肯定告訴你,這表示這些地方將來真的會有大問題。
大多數主管其實心裡也知道,只是因為自己也很忙,所以下意識的跳過了,想說算了,下次開會的時候再盯一下,這時候千萬要提醒自己,別忘了這一塊肯定是有問題的。
過去的經驗告訴我真的是這樣,自己潛意識越是不想打開的那段程式碼,裡面暗藏著越多的bugs,在一天的工作計畫中,自己越不想去碰的那塊,越是會出問題,反過來說,如果你專挑自己越不想碰的事情先做,越能夠讓一天的工作順利進行,想想還真的是這樣。
道理很簡單,大家都懂,只是要下定決心去做,似乎還真不容易。
留言
老師應該會輕鬆一些。
其實分析人員、規格、專案經理對開發團隊打模糊仗,我都覺得還好...
最可怕的是跟User打模糊仗....
最後輸的一定是乙方,可能多做了40%都是原本沒講清楚的部分,而且這40%對團隊開發士氣和成本都是致命傷。
那三天真的讓我收穫很多很多很多,只是覺得時間怎麼這麼短,讓老師講課的速度被逼得要講很快,很多有趣的東西沒法子講得太深入。
不過老師真的把.NET的未來實際的方向、願景講的超級清楚,也讓我對很多新的東西抱持著很高的希望跟興趣。
聽老師講的兩堂課,
整個就讓我覺得不虛此行,
謝謝老師百忙之中還能準備這麼好的課程給我們,真的很感謝。