Project專案
Triton Ho https://www.facebook.com/groups/616369245163622/permalink/1736421439825058/
今天不寫發大財的事,直接寫一下project planning的雜感好了。
——————————————————————————————————————————————————————
最兇險的專案不是那些deadline定得很趕的專案,而是那些沒有deadline的專案!
別以為「沒有deadline」是真的沒有deadline耶。
你想一下,跟你大大聲說「錢不是問題的人」,最終有120%是「反正我又沒錢,錢當然不是問題啊~」。
公司不是做慈善的,也不是給工程師來試新玩具的。所有的專案,最終還是要談C/P值。
(再次一句:工程就是來談C/P的,不談C/P請去當藝術家)
所謂「沒有deadline」,這很可能代表……
A) 你的主管現在忙別的專案管理,暫時沒空管這專案。
(然後等他有空回來看這專案時,就會問為何拖這麼久還結不了案了)
B) 你沒法拒絕其他人的需求改動。(背景聲:反正沒deadline,改一下需求去做得更好吧)
C) 你沒法有效限制專案的複雜性,大量的over-engineering。(背景聲:反正沒deadline,寫得好一點/多留一點空間,這樣子未來才容易維護嘛)
A+B+C的後果是……老闆過了三個月,突然有空來看看大家做什麼時,發現這專案已經過了二個月還沒有做完。
然後要求:都做了三個月了,現在再給你二星期時間來結案耶!
結果是:
要麼結不了案,投入大量心力的專案成為上不了市場的垃圾。
要麼是勉強能結案,但是有大量的over-engineering和一堆因為需求改了又改下不好的程式加構。
——————————————————————————————————————————————————————
雖然一堆入市未深的工程師整天會罵專案deadline為何定得那麼硬,一天都不能改……
但是嘛,先不談專案,我們談一下去旅行好了。
去旅行嘛,第一件事當然是跟公司申請休假,然後把信用卡丟給另一半叫她幫忙規劃(註:這是高度危險動作,好孩子絕對別學)。
http://xn--axxxx-fg1h292av9ap80aa49or2n76lzmxyz1bcr7i.com/,sxxxxxxxxx.com,txxxxxxxxxx.com上天天比價比優惠看旅行遊記的生活~
然後如果沒定下死線?應該我進棺材那一天還是在計劃行程中~
(謎之聲:某人站在你身後,她看起來很火……)
計劃行程的死線能不能改?當然不行,公司休假可是改不動啊!!!
回到公司專案,為何公司死線定得那麼硬,很多時候都是跟業務宣傳/合約罰款有關的。
你想像一下,一個手游專案要上市,當然不是先等程式完成後才慢慢宣傳衝人氣的。
一個遊戲要上市,當然是先定好上市日期,然後預先數月就要慢慢地製造話題,找人來做宣傳,一步一步炒熱氣氛。
然後人氣炒到最高點,玩家的期待度到達最大時,遊戲同步開賣大賺特賺那一波。
如果突然發現有bug,遊戲要延期一個月?
sorry囉,遊戲消費是不理性的,過了那一波熱潮,本來會付錢的玩家們早就付給另一個遊戲了。
讓話題多炒熱一個月去等bug先修好?
你以為是炒青菜,你想炒多久就多久嗎?
先不談熱度能否額外維持一個月還不消散。但是,高人流的宣傳管道,網上KOL,不是你想付錢就能立即買到的!
如果你沒法如期把遊戲上市,那麼你這個遊戲很可能就賠本賠很很大囉。
——————————————————————————————————————————————————————
專案deadline不能改,商業社會就是這樣子了。
追求要完美的,你應該去當藝術家不是當工程師的。
怎去在deadline前做完專案,固然跟你是否有留下足夠的buffering有關。
但是,這跟你的專案怎計劃也有很大關係的。
上古時期,有一堆人(CMMI)覺得,只要把文件寫得好,每一個專案把工序所用的時間都記錄下來。
然後你就能越來越變得成熟,能很精準地預估下一個專案所需時間了~
然後這些CMMI人大約會覺得:把台北的象山步道走100次,就能很精準地預估爬玉山攻項要多少時間了(笑~)
(香港版本:走城門水塘100次,就能預估蚺蛇尖攻項要多少時間了)
會行山的人都知道:
地圖/網上文章只能給你一個很基本的大概,一個路線最終要用多少時間/體力,你只能親自走一次才能答出來。
然後嘛……
很多表面上看起來相同的軟體專案,真正做下去時才發現是全新的未知領域……
——————————————————————————————————————————————————————
如果專案deadline不能改,那麼能改的就是:軟件的質素了。
以去旅行為例:
如果你有非常充份的時間,你買機票時大可以找不同銀行的信用卡優惠,看看飛行里數計劃,看看連同旅行一起訂的優惠……
如果沒時間,http://xn–skyxxxxxxx-rl5q.com/,輸入出發和回程時間,那一家最便宜就按下去算了。
一個能賣錢的軟體專案,正常應該可以再拆分為多個sub-task和milestone的。
重點:
首先開始做的,應該是最困難/你最沒法預估開發難度的工作。
A)
專案越早階段要改動上市日期,你能成功改動宣傳計劃的可能性就越高。
B)
越早發現專案進度不理想。之後比較容易的sub-task,你還是能以減少testcase coverage,刪掉不重要功能這些手段去追回進度。
如果你把困難而且必要的工作放在最後才做,那麼任何的預估錯誤就是專案延期囉~
(註1:一堆人覺得堅持一定要先寫testcase才能寫程式的……要麼他真的很幸福沒遇上過要衝死線的專案,要麼他活在童話世界……)
(註2:deadline前做不完的軟體功能嘛……如果不是關鍵性的,看看能不能當成bug再後補囉~)
——————————————————————————————————————————————————————
專案到底先做什麼:
我們以(重要/不重要),和(容易/困難)來給每一個sub-task排一下:
如果你明知deadline是完全不合理,你怎也沒可能把全部重要功能都做完,那麼就先做(重要+容易),在死線前能多做一個功能就多一個功能。
否則,先做(重要+困難)的。因為(重要+容易)的工作,常常是總有一點時間可以偷下來的。越近deadline,你越會珍惜你每一秒不做多餘的事。
重要工作全做完後,然後是(不重要+容易),在deadline前能做多少就多少。
(不重要+困難)工作嘛,讓他留在backlog算了。
——————————————————————————————————————————————————————
後記:
在只發了一篇文下,RDBMS課程普通票全賣光了
(謎之聲:你不是說五分鐘會搶光嗎?)
歡迎來買石虎愛心票耶XD
https://datasci.kktix.cc/events/rdbms20191005
另外,高流量雜感的淺談,定在10/10和10/11的早上9:30—12:00(二天內容相同)
請繼續耐心等候正式報名頁面……