Project專案

‎Triton Ho‎ https://www.facebook.com/groups/616369245163622/permalink/1736421439825058/

今天不寫發大財的事，直接寫一下project planning的雜感好了。

——————————————————————————————————————————————————————

最兇險的專案不是那些deadline定得很趕的專案，而是那些沒有deadline的專案！

別以為「沒有deadline」是真的沒有deadline耶。

你想一下，跟你大大聲說「錢不是問題的人」，最終有１２０％是「反正我又沒錢，錢當然不是問題啊～」。

公司不是做慈善的，也不是給工程師來試新玩具的。所有的專案，最終還是要談Ｃ／Ｐ值。

（再次一句：工程就是來談Ｃ／Ｐ的，不談Ｃ／Ｐ請去當藝術家）

所謂「沒有deadline」，這很可能代表……

Ａ）　你的主管現在忙別的專案管理，暫時沒空管這專案。

（然後等他有空回來看這專案時，就會問為何拖這麼久還結不了案了）

Ｂ）　你沒法拒絕其他人的需求改動。（背景聲：反正沒deadline，改一下需求去做得更好吧）

Ｃ）　你沒法有效限制專案的複雜性，大量的over-engineering。(背景聲：反正沒deadline，寫得好一點／多留一點空間，這樣子未來才容易維護嘛）

Ａ＋Ｂ＋Ｃ的後果是……老闆過了三個月，突然有空來看看大家做什麼時，發現這專案已經過了二個月還沒有做完。

然後要求：都做了三個月了，現在再給你二星期時間來結案耶！

結果是：

要麼結不了案，投入大量心力的專案成為上不了市場的垃圾。

要麼是勉強能結案，但是有大量的over-engineering和一堆因為需求改了又改下不好的程式加構。

——————————————————————————————————————————————————————

雖然一堆入市未深的工程師整天會罵專案deadline為何定得那麼硬，一天都不能改……

但是嘛，先不談專案，我們談一下去旅行好了。

去旅行嘛，第一件事當然是跟公司申請休假，然後把信用卡丟給另一半叫她幫忙規劃（註：這是高度危險動作，好孩子絕對別學）。

http://xn--axxxx-fg1h292av9ap80aa49or2n76lzmxyz1bcr7i.com/，sxxxxxxxxx.com，txxxxxxxxxx.com上天天比價比優惠看旅行遊記的生活～

然後如果沒定下死線？應該我進棺材那一天還是在計劃行程中～

（謎之聲：某人站在你身後，她看起來很火……）

計劃行程的死線能不能改？當然不行，公司休假可是改不動啊！！！

回到公司專案，為何公司死線定得那麼硬，很多時候都是跟業務宣傳／合約罰款有關的。

你想像一下，一個手游專案要上市，當然不是先等程式完成後才慢慢宣傳衝人氣的。

一個遊戲要上市，當然是先定好上市日期，然後預先數月就要慢慢地製造話題，找人來做宣傳，一步一步炒熱氣氛。

然後人氣炒到最高點，玩家的期待度到達最大時，遊戲同步開賣大賺特賺那一波。

如果突然發現有bug，遊戲要延期一個月？

sorry囉，遊戲消費是不理性的，過了那一波熱潮，本來會付錢的玩家們早就付給另一個遊戲了。

讓話題多炒熱一個月去等bug先修好？

你以為是炒青菜，你想炒多久就多久嗎？

先不談熱度能否額外維持一個月還不消散。但是，高人流的宣傳管道，網上ＫＯＬ，不是你想付錢就能立即買到的！

如果你沒法如期把遊戲上市，那麼你這個遊戲很可能就賠本賠很很大囉。

——————————————————————————————————————————————————————

專案deadline不能改，商業社會就是這樣子了。

追求要完美的，你應該去當藝術家不是當工程師的。

怎去在deadline前做完專案，固然跟你是否有留下足夠的buffering有關。

但是，這跟你的專案怎計劃也有很大關係的。

上古時期，有一堆人（CMMI)覺得，只要把文件寫得好，每一個專案把工序所用的時間都記錄下來。

然後你就能越來越變得成熟，能很精準地預估下一個專案所需時間了～

然後這些CMMI人大約會覺得：把台北的象山步道走１００次，就能很精準地預估爬玉山攻項要多少時間了（笑～）

（香港版本：走城門水塘１００次，就能預估蚺蛇尖攻項要多少時間了）

會行山的人都知道：

地圖／網上文章只能給你一個很基本的大概，一個路線最終要用多少時間／體力，你只能親自走一次才能答出來。

然後嘛……

很多表面上看起來相同的軟體專案，真正做下去時才發現是全新的未知領域……

——————————————————————————————————————————————————————

如果專案deadline不能改，那麼能改的就是：軟件的質素了。

以去旅行為例：

如果你有非常充份的時間，你買機票時大可以找不同銀行的信用卡優惠，看看飛行里數計劃，看看連同旅行一起訂的優惠……

如果沒時間，http://xn--skyxxxxxxx-rl5q.com/，輸入出發和回程時間，那一家最便宜就按下去算了。

一個能賣錢的軟體專案，正常應該可以再拆分為多個sub-task和milestone的。

重點：

首先開始做的，應該是最困難／你最沒法預估開發難度的工作。

Ａ）　

專案越早階段要改動上市日期，你能成功改動宣傳計劃的可能性就越高。

Ｂ）　

越早發現專案進度不理想。之後比較容易的sub-task，你還是能以減少testcase coverage，刪掉不重要功能這些手段去追回進度。

如果你把困難而且必要的工作放在最後才做，那麼任何的預估錯誤就是專案延期囉～

（註１：一堆人覺得堅持一定要先寫testcase才能寫程式的……要麼他真的很幸福沒遇上過要衝死線的專案，要麼他活在童話世界……）

（註２：deadline前做不完的軟體功能嘛……如果不是關鍵性的，看看能不能當成bug再後補囉～）

——————————————————————————————————————————————————————

專案到底先做什麼：

我們以（重要／不重要），和（容易／困難）來給每一個sub-task排一下：

如果你明知deadline是完全不合理，你怎也沒可能把全部重要功能都做完，那麼就先做（重要＋容易），在死線前能多做一個功能就多一個功能。

否則，先做（重要＋困難）的。因為（重要＋容易）的工作，常常是總有一點時間可以偷下來的。越近deadline，你越會珍惜你每一秒不做多餘的事。

重要工作全做完後，然後是（不重要＋容易），在deadline前能做多少就多少。

（不重要＋困難）工作嘛，讓他留在backlog算了。

——————————————————————————————————————————————————————

後記：

在只發了一篇文下，RDBMS課程普通票全賣光了

（謎之聲：你不是說五分鐘會搶光嗎？）

歡迎來買石虎愛心票耶ＸＤ

https://datasci.kktix.cc/events/rdbms20191005

另外，高流量雜感的淺談，定在１０／１０和１０／１１的早上９：３０—１２：００（二天內容相同）

請繼續耐心等候正式報名頁面……