這個模式的專案執行應該不會在台灣

作者: qwerty0981 (qwerty@qwerty.tw) 看板: Soft_Job
標題: Re: [閒聊] 聊專案開發
時間: Wed Nov 12 04:05:09 2014

※ 引述《AmosYang (泛用人型編碼器)》之銘言：
: ※ 引述《TonyQ (自立而後立人)》之銘言：
: :         覺得有點感觸，來寫一下這幾年我對軟體專案的幾個看法，
: :            如果估計的時間有出入，通常都是 spec 的認知有出入，
: :            那時候該釐清的是 spec 細節跟重新估算。
: :            而不是在那邊「我覺得要一個月」、「但我覺得要一週」，
: :            這種愚蠢的菜市場喊價。
: 「時程估計」是 PM 與 Dev 之間的 eternal conflict  。有的時候
: 不是 PM 故意找麻煩，而是 PM 的上級在逼 PM 說出一個日期。
: 感覺上，以下這個模式是個還不錯的平衡點
: (1) 很明顯要花五天以上去作的部分，應該重新檢視，拆成更小的部
:     分
: (2) 很明顯是一天以內能作完的事 (尤其是很制式的流程) ，應該研
:     究將其自動化的可能性，及編列預算
: (3) 兩天至五天內的部分 (尤其是無制式流程可參考的時候) ，雙方
:     要達成以下共識:
:     (a) 視情形，先花 1/4, 1/6, 或 1/8 的時間試作看看，試試水
:         溫
:     (b) 試作時間結束後，很簡短地開個 stand-up 會議， Dev  告
:         之 PM 他對原始時程估計值的 "gut feeling"
:     (c) 誠實地調整原始估計值
: * 讓 PM 成為你的盟友，幫助他建立 burn down chart  ，掌握專案
:   進度，讓他的上級閉嘴
: * 讓 Dev  成為你的盟友，一旦 Dev  願意合作建立 burn down chart,
:   除非你帶給他們 free food, 不然別再去煩他們
: ============================================================
: 以上這模式有個前提: 管理者不是昏君，團隊裡沒有賤人


這個模式的專案執行應該不會在台灣，而且可能也只有軟體專案才會發生。


若以web system的專案而言，

PM和PG之間還有SA和SD，壓力通常不會從PM直接傳導到PG上。

PM還有分大PM和team PM。PG多半都是在和team PM溝通。

專案執行過程中，大PM根本不會(不屑?笑)理會PG，更別說是成為盟友之類的角色。


就時程估計而言，比較老練的team PM也不會問你辦不辦得到。

反而是自行訂下日期，並在期間多次問你有沒遇到困難，需不需要支援。


就程式開發而言，計算的是開發交易的完成度和數量，PG不會有試水溫的機會。

唯一可以試水溫的人和事，是經驗不足的架構師和可能砍掉重練的系統架構。

這也只有專案初期到中期才有可能發生的事，並且如果不想讓專案執行失敗的話。


就文件撰寫而言，專案規模和參與公司之數量，往往和依照文件開發真實度成反比。

那些在專案初期產出的文件並不完整，尤其是跨公司開發的部分通常會模糊帶過。

專案初期撰寫的文件主要是應付給客戶看的，並且在事後可能也不會再變動。


就PG同儕之間，除了有習慣性倚賴的同事以外，工作外的互動幾乎很難有。

當然這和專案規模及PG年紀也有不小的關係。

與其要當實質盟友，不如直接翻版控觀摩同儕寫的程式，可抄可改可參考。


專案執行中，

PM和客戶開會的次數與專案進度的嚴重程度正相關。

PG和上層最忌諱的是業務資訊不對稱的程度。

PG和PG彼此之間的嫌隙會發生在對業務資訊掌握程度的比較和team PM的信賴度，

尤其是team開會也不請你參加的情況，就要自己小心了。


總之，web system 專案是結果論的，

當PG者，只需參與並從中學得自己想要的技術，

剩下的，是以後身為SD以上才需要知道的事。


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.135.203.156
※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1415736311.A.D58.html
※ 編輯: qwerty0981 (220.135.203.156), 11/12/2014 04:05:51