找出專案的潛在問題

最近因為一些公司的專案忙得昏天暗地,剛好前陣子是TechDays,整個重心都放在TechDays上,又同時得顧及手上的一些專案工作,實在是有蠟燭兩頭燒的感受,很多事情即便列出優先順序,卻發現實在是時間不足,我常常有一早起來,坐在電腦面前,突然間一天就過去了的經驗,一整天都處於緊繃和忙碌中,偏偏email又一直來,突發事件不斷...似乎沒法喘口氣釐清一下事情的整個狀況。

回顧十多年的軟體開發生涯中,偶而會陷入這樣的情境中,這時候除了救火之外,找出問題的核心變得相當重要,我想起過去一個前輩告訴我的,他分享了他的經驗,因為每一個主管手上的專案和工作都相當多,實在沒有辦法深入到每一個項目中。可是,如果不深入到項目中,怎麼能發現問題在什麼地方呢? 怎麼發現專案哪邊可能有潛在的問題? 並且提早處理呢?

我之所以會突然想到這位前輩的經驗分享,是因為我最近就碰到了這些問題,手上同時有很多專案,坦白說我沒法深入每一個專案,但是畢竟我是負責這些專案的管理者,我得要能夠預先發現問題,確保專案能夠順利進行。

這時候,『問對問題』變得很重要,過去的經驗讓我發現,確實有很多主管問的問題都一針見地,立刻可以掀出專案潛在的問題,讓可能發生的意外無所遁形,我過去以為這些PM大概天賦異稟或是有常人沒有的洞察力,但是我後來發現,其實似乎也有一個方式可以遵循。

其實道理很簡單,當年,那位前輩各訴我,當你發現某些地方越被找理由蓋起來,那些地方就越要掀開來看,包含主管自己對自己的要求也是一樣,人都有惰性,你發現自己越不想碰的問題,越表示那些地方將有著大問題,甚至,有些其實是自己潛意識根本不想去碰的部分。做主管的得要能察覺這些現象。

自己寫了多年的程式碼,也帶了多年的專案,越來越覺得真的是這樣,當某些模塊,在專案討論的時候,總是被成員找理由(理由多半是很合理且冠冕堂皇的)跳過或是忽略,當時程總是被粗估簡化,當驗收條件總是被模糊化,系統流程好像不是很solid,那很抱歉,這些地方多半都有著嚴重問題,特別是我們(開發人員)很喜歡把規格模糊化,或是你在進行專案會議時,發現針對某些部分專案成員的回答似乎總是有些不很確定,那幾乎可以斬釘截鐵的肯定告訴你,這表示這些地方將來真的會有大問題。

大多數主管其實心裡也知道,只是因為自己也很忙,所以下意識的跳過了,想說算了,下次開會的時候再盯一下,這時候千萬要提醒自己,別忘了這一塊肯定是有問題的。

過去的經驗告訴我真的是這樣,自己潛意識越是不想打開的那段程式碼,裡面暗藏著越多的bugs,在一天的工作計畫中,自己越不想去碰的那塊,越是會出問題,反過來說,如果你專挑自己越不想碰的事情先做,越能夠讓一天的工作順利進行,想想還真的是這樣。

道理很簡單,大家都懂,只是要下定決心去做,似乎還真不容易。

留言

91寫道…
如果有QA幫忙盯著提早發現一些想企圖被掩蓋的問題的話,
老師應該會輕鬆一些。

其實分析人員、規格、專案經理對開發團隊打模糊仗,我都覺得還好...

最可怕的是跟User打模糊仗....

最後輸的一定是乙方,可能多做了40%都是原本沒講清楚的部分,而且這40%對團隊開發士氣和成本都是致命傷。
David寫道…
100%同意, 過去也有一個專案吃了這種苦頭,甲乙雙方都刻意模糊希望趕快成案,但是心裡其實各有盤算,最後的結果是花了n倍的時間結案,其實對彼此都不好。
91寫道…
順便謝謝老師在TechDays三天精彩的講課,
那三天真的讓我收穫很多很多很多,只是覺得時間怎麼這麼短,讓老師講課的速度被逼得要講很快,很多有趣的東西沒法子講得太深入。

不過老師真的把.NET的未來實際的方向、願景講的超級清楚,也讓我對很多新的東西抱持著很高的希望跟興趣。

聽老師講的兩堂課,
整個就讓我覺得不虛此行,
謝謝老師百忙之中還能準備這麼好的課程給我們,真的很感謝。
David寫道…
謝謝各位的支持,大夥的留言就是對身為講師的我們最大的回饋和鼓勵了。
匿名表示…
除了檯面上的問題清單,PM 本身也要有一本自己的流水帳. 每個案子都有一本,才能應付多個專案同時進行~ 人老了 不可能光靠記憶.. 有了流水帳要吵架 要評核某些人 都能有所本.....
David寫道…
呵呵,這是個挺好的建議^_^

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

精彩(且驚人)的Semantic Kernel入門範例

使用Semantic Kernel 建立自然語言請假系統

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...