恰好之前也跟以前的同事針對這點有過一些討論和想法，列舉如下：
同事：真是每個專案都喜歡估schedule，而我最近很不幸又要估schedule了，而且是很細的worki
總之，我們還是要花時間做不知道要用在哪的paper work，唯一想到的地方只有和客戶談判，嗯，這是一項藝術。
沒道理對沒做過的事情還有辦法把schedu
我：針對以上的論點，大致都是同意的
只是換個角度想想，即使是一個粗估的schedule也是可以提供的用途：
1. 用以判斷Project是否可以在原本預計的時間內達成；如果不行，是否需要將沒那麼重要的feature移往下一個project中實現，還是願意將Project原本預計完成的時間往後移
2. 用以判斷某些人的loading是否比預期中還要大；是否需要調整Project中的參與人力，或者把工作重新安排獲得最佳效益
3. 讓每個RD對於所要完成的工作有個初步的分析和方向；讓大的feature細分成一個一個的小component再任何feature實作初期是非常重要的一件事；藉由Project schedule，可以有個初步的design，至少有個方向
我想，事情總是有好有壞
作了一定比沒作要強
至於能不能真的讓這些產生效益，就得看每個leader面對member所提出的schedule是怎樣的心態了
那又是另外一課囉
同事：我懂你的意思，不過這些是要站在預估有一定的準確度上，但是對於沒有做過的feature要怎麼知道預估有一定的準確度呢？有working item也不一定要有schedule不是嗎？
對管理者而言，他要的只是在deadline前拿到成果，中間過程是怎麼樣的不是那麼重要；對於一個積極的團隊而言，遇到困難的時候應該自動提出問題尋求幫助，而不是被動地等管理者發現問題，通常等管理者拿著schedule發現問題的時候已經太遲了。所以要工程師畫押估schedule這種行為，比較像是拿來要求懶散的團隊的工具，或是當成工程師偷懶的藉口。好啦，我知道這是我太天真，哪裡有這麼多積極的團隊呢？
可惜當專案結束，所有估過的schedule都被拋在腦後，不然應該拿出來好好研究一番，我相信可以發現十之八九的schedule都不準。
ps. 我還滿喜歡rework的幾段話：
>>>Writing a plan makes you feel in control of things you can't actually control.
Why don't we just call plans what they really are: guesses.
When you turn guesses into plans, you enter a danger zone. Plans let the past drive the future. They put blinders on you.
Working without a plan may seem scary. But blindly following a plan that has no relationship with reality is even scarier.
我：其實我也懂你的意思，對於一個預估完全不準的schedule，實在是無法發揮它原本的用處
這點我完全認同
只是，很多事情在做了第一步以後才能夠產生後續的動作。
一定會有先一個不準的schedule，然後才可以在Project的過程中慢慢調整方向。
老話一句，工具是在那裡，端看管理者如何使用
如果只是被當作一個Project初期必交的作業，那不做也罷
如果可以在Project過程中，能夠馬上反應當初計畫以及現實的不同，從而讓管理者不至於在問題變大之前可以有一些亡羊補牢的措施
再重申一次，個人也非常討厭paper work，但是每個paper work背後也潛藏著它當初想要發揮的功能；端看在組織中，是否能夠善用此工具囉？
從以上的討論，至少可以肯定schedule的評估是有其必要，的確有許多的好處；但是，如果奢望schedule的結果會跟一開始評估的相同，甚至當面對RD所提出的schedule時，採取壓迫的方式希望他們重新評估，那就是錯用這項工具了。
個人的淺見認為，採取任何動作之前，還是得採取計畫的，即使大家都知道事情不會按照計畫進行，但是起碼可以讓自己時時刻刻了解自己和計畫相差多遠，需要做怎樣的因應去改善目前的現狀。
你說對嗎？
沒有留言:
張貼留言