從評估軟體時程,論人性化管理

從評估軟體時程,論人性化管理

■     評估時程的無奈

以前在軟體公司擔任Project Leader,評估時程總覺得是不可能的任務,因為在事前我會大概知道公司未來的經營計畫,還有主管希望的時程、業務答應客戶的時程與工程師們實作產品的預估時程,這些時程通常差異很大,就算把大家找來一起溝通,大多也只是某些人在發表意見而已,一些軟體工程的理論與做法很難找到「切入點」,而在Deadline的壓力下,大家也覺得評估時程似乎沒有什麼意義。

在一個討論時程的會議中,各個角色的心態可能如下:

 總經理/經理 

  • 東西又不是很難,為什麼要花那麼久時間?
  • Project Leader你要有一點狼性阿!
  • 我要看看那些員工才是值得留下來的人。

工程師

  • 合理時程 = [(自己認為的時程 * 主管想法的權重) ± 主管現在的心情]/自己薪水高低的權重。
  • 實作的邏輯我很熟,但是如果講太多話,工作勢必又會落在我頭上,多一事不如少一事,還是不要多嘴好了。
  • 有一個Bug隱藏很久,但是發生機率不高,也很難解決,所以還是不要講好了,避免自找苦吃。

業務

  • 客戶經營很久了,時程也談好了,絕對不能失去客戶,一定要在時間內完成產品。
  • 總經理/經理會挺我。

Project Leader

  • 想釐清合理的專案時程,但是關鍵人員怎麼都不表達自己的意見?
  • 拜託別再施壓,我好不容易才安撫好工程師!
  • 我不想選邊站。

■     社會性的問題,遠比技術性或工程性的問題難解決

評估專案時程的意義不只在於定義時程,也是希望藉由大家的討論能夠釐清專案的面貌,但討論若要「有效而且有意義」,最起碼我必須要讓工程師在壓力下還能「敢說真話與表達意見」,而且主管與業務還須「耐心聽完」工程師的話後,撇除其他因素,「客觀」的來討論內容與解決問題,並「願意」還原時程壓力的真相,讓工程師們知道公司經營的難處。

所以我嘗試請主管以專業的立場(聽聽工程師的意見)考量事情,或是拜託工程師站在公司經營的角度(配合主管或是公司的計畫與步調)看待事情,但是效果都不大,原因是「每種職務都有他的立場」,面對的事情也完全不同,所以要資方與勞方能互相體諒實在是很難。要解決這樣的狀況就像是在挑戰人性問題,不過若不解決人性問題,合理的專案時程沒有辦法浮上檯面,公司的文化也就永遠是這樣。

■     使用Planning Poker來解決人性問題

後來一位有參加敏捷開發[附註1]社群的同事,在與我討論軟體工程的時候,提到了Planning Poker[附註2],這是一種使用撲克牌來評估時程的方式,當下我們都覺得這個方式似乎可以用來解決在時程討論會議上的人性問題。

Planning Poker的規則如下:

  1. 由Project Leader或是Project Manager擔任會議主持人。
  2. 使用撲克牌,發給大家相同數量的點數,1點可以代表1個小時或是1天,依工作項目的大小與難易度來決定。
  3. 主持人拆解並說明目前所要執行的工作項目,相關關鍵人員可以補充說明。
  4. 大家針對目前要評估的工作項目,先思考大約1分鐘,並決定好自己認為的合理時程,也就是撲克牌點數。
  5. 1分鐘後,大家「同時」翻開撲克牌。
  6. 主持人請極端值(點數最高與最低的人)解釋自己的想法,為什麼會與其他人有所差異?
  7. 如果大家對於時程的想法差異過大,則重複步驟4~6(正常狀況下,大家的想法會漸漸的收斂),直到大家對於目前評估的工作項目都有共識或是沒有補充說明後,將大家的點數加總並除以人頭數,便是該工作項目的時程。

PS:當初於公司使用Planning Poker時,有考慮合適性,所以在不影響效果下,我們修改了部分的規則,其正式規則可以參考[附註2]。

 

幾次使用Planning Poker後,會發現連技術能力差不多的工程師,對於時程的看法都存在著很大的差異,這讓我們十分的驚訝,所幸Planning Poker建立了互相溝通與學習的橋樑,找出了隱含的問題並得到不同的解決辦法,讓知識能夠被分享,團隊能夠進步,這也是軟體流程改善(Software Process Improvement)很重要的一環。

學者Haugen也於2007年在18th Australian Software Engineering Conference發表了一篇Planning Poker的研究論文 「Combining Estimates with Planning Poker – An Empirical Study」,驗證了Planning Poker所得的時程與專家所評估的時程並無顯著差異,而且還可以避免達克效應[附註3],也就是個人認知偏差的問題。

使用Planning Poker所得到的時程,還是會與相關關鍵人員所希望的時程有所差異,但因為大家「共同擬定了時程」,也理解了「可能的解決辦法」與「各層面的執行困難點」,所以在心態上,主管會較願意提供資源、業務會與客戶解釋原因、工程師也因為體會公司的經營狀況與自身相關,會較願意發想新的辦法與嘗試完成工作,這樣的方法,降低了大家的隔閡與衝突,也讓我了解到唯有處理好人性面,才能事半功倍。

■     不同的工作型態,其管理的思維應該要做調整

處在科技發展日新月異的時代中,我們非常注重科學管理(Scientific Management),也就是遵從泰勒主義[附註4],所以在生產績效的改善上,會去追蹤每一個工具、流程與員工的數據與效率,應用科學的計算,去做看似完美的改善與安排。但是要知道任何完美的制度與方法,都是由人在做執行的,也許大家對於某個方法或制度在檯面上會一片叫好,但在檯面下,多數人還是只在乎與自身相關的事情,所以若不考慮人性問題,事務的推行勢必事倍功半。

我們可以在軟體產業上,看到人性化管理(Human-based Management)的趨勢,例如本篇文章提到的Planning Poker或是遠距工作(Telecommuting)與內部創業(Intrapreneurship)等議題,這些都是基於人性考量而發明的管理方法,而且效果卓越,原因就是在於「管人不如管心」。

■     道家的管理思維

多數公司的管理方法比較偏向「法家」的概念,也就是制定工作的規矩、制度與明確的賞罰,並利用職位來做層層的監督與限制,但這樣的管理方法不見得適用於所有的產業,尤其是「腦力密集產業」,例如畫家、音樂家甚至是工程師,這類工作的產出較難以時間或應用技術去做度量,而且過程需要大量的靈感與創意,所以若長期處在壓力、壓抑或是限制下,是不可能做出好產品的。不同於法家的思想,道家講求無為而治,遵循天道與人道,以致無為而無不為,萬物自化,其含意是要領導者「順應自然」去建立「無為的環境」,讓事務「自育、自作與自息」,以求發揮潛能。

例如漢文帝與漢景帝崇尚道家,了解人民生活困苦,便除田租稅之半甚至全免田租,與民休養生息,而國家的收入來源是稅收,此一做法可謂十分大膽,但也因為減低稅賦,降低了人民的壓力,大家就願意耕作,國家後來竟富裕到:「京師之錢累巨萬,貫朽而不可校。太倉之粟陳陳相因,充溢露積於外,至腐敗不可食。」,史稱文景之治,而這便是遵循人性而成功的最好寫照。

又例如減肥這件事情,世界上公認最好的減肥方式是運動,不過多數人沒辦法靠運動就成功減肥,因為運動會「累」,人會「懶」,除非事先建立強大的動機與目的以克服人性問題,不然就算擁有運動秘笈,也會變成三天打魚兩天曬網,無法成功瘦下來;反之,面對減肥,如果已經擁有了強大的動機與目的,其實有沒有運動秘笈也就不是那麼重要的事情了,不是嗎!

 

附註:

  • 敏捷開發社群

敏捷開發是一種新型的軟體開發精神,強調應對快速的需求變化。目前有許多相關的組織在推動此一開發方法,例如Agile.Taichung。

  • Planning Poker

中文名稱為規劃撲克牌,是用來估算工作量大小的一種方式(工具)。市面上有販售其專屬的撲克牌,也有App可以下載使用,其正式規則與其詳細說明可以參考 https://en.wikipedia.org/wiki/Planning_poker

  • 達克效應

對專業熟練或是不熟練的人,都會因為認知的偏差問題,而錯誤的評估自己或是他人的能力。其詳細說明可以參考https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

  • 泰勒主義

英文名稱為Taylorism,是主張以科學管理提高勞動生產率的管理理論。其詳細說明可以參考https://en.wikipedia.org/wiki/Scientific_management

 

作者:江俊志   Gene

文章出處 : TechOrange 科技報橘

原文連結 :【給PM】如何估算軟體開發時間,又不會惹怒工程師?

圖片出處:https://images.unsplash.com/photo-1456406644174-8ddd4cd52a06?ixlib=rb-0.3.5&q=80&fm=jpg&crop=entropy&s=42689ecb42b1d503e16a9d8764cb8385

若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
江俊志

曾在學界擔任Coordinator,專注於人工智慧領域,工作為執行經濟部學/業界科專計畫、發表期刊與專利;在業界軟體公司擔任Project Leader,開發國際賭場管理系統,於2014年澳門亞洲國際博彩娛樂展會(Global Gaming Expo Asia)展出。 在軟體上的興趣是軟體工程,除了能力成熟度整合模式(CMMI)與敏捷開發之外,會涉獵與發想創新的專案與團隊管理模式,因為這是軟體開發的根本。 一路走來總會發想議題並實際去執行,曾獨立開發並在市場上執行過「運動價差套利交易系統」、「股票配對交易系統」、「選擇權買方黑天鵝交易系統」、「可轉換公司債對沖交易系統」、「運動媒合App」與「適性化補救教學系統」,參與開發「會議排程系統」、「專案監控系統」 與「工作流程管理系統」。

3 則讀友回應

  1. 路人 2016-10-21 11:27:51 第 3 則

    達克效應的連結錯誤,
    應該是:
    https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

    • Wenny 2016-11-02 10:19:51

      我們會將連結更新,謝謝!


  2. Gene 2016-07-14 16:20:05 第 2 則

    在軟體界,以錯誤的時程去符合顧客或是老闆的期待是非常普遍的事情,但這往往也是災難的開始,所以探究專案該有的正確時程、面貌與隱性問題是非常重要的議題,而使用Planning Poker是其中一種方法。這篇文章的重點其實不是在討論「評估時程」的準確性與其必要性,真正的涵義是在於Business Process Improvement。

  3. 小黃 2016-07-05 08:21:50 第 1 則

    不覺得有deadline的情況下評估時程還有什麼意義,反正在這之前把事情做完就對了。