Posts Tagged ‘Project Management’

客戶：「我們需要畫七條紅線，彼此互相垂直，兩條用紅色的墨水畫，兩條用綠色的墨水，剩下三條用透明的墨水畫。」

業務：「沒問題，我今天帶了專案經理與他的團隊。」

專案經理：「這位是我們的畫紅線專家 Anderson。」

Anderson：「抱歉，一般用綠墨水是無法畫出紅線的，除非你的 TA 是色盲。而要讓七條紅線互相垂直更是完全不可能做到。」

專案經理：「怎麼可能不行，Anderson 你是專家耶。」

業務：「是啊，客戶的需求非常明確，你們把它畫出來就是了。」

Anderson：「#*$#&#@*」

客戶設計專員：「對了，其中一條線需要是喵咪的形狀。」

Anderson：「我只會畫線，不會畫貓。」

客戶：「不是貓，是喵咪。」

Anderson：「#*$#&#@*」

客戶設計專員：「我們還需要你幫忙吹一顆紅色的氣球。」

Anderson：「為什麼我需要吹氣球？？？」

客戶設計專員：「因為它是紅色的。」

業務：「Anderson，反正他們會出旅費，你飛一趟幫他們把氣球吹好就是了。」

Anderson：「#*$#&#@*」

業務：「很好，今天的會議非常有效率，讓我們開始工作吧！」

這是昨天 YouTube 上流傳的一支影片 The Expert 中的劇情，當然不一定是紅線與綠墨水，但這麼雞同鴨講的專案會議你一定參與過不少。

這些會議都有一個共同點，就是需求方完全不了解執行面的種種限制，而執行方也完全不了解需求方真正想達成的目的，中間再加上一個只想趕快成交的業務 (或是一個超級忙碌不管細節的老闆)，結論就會變成一個根本無法被落實的專案。

這就是為什麼在很多公司，本來應該緊密合作的行銷與研發，卻往往是對立的。如果你問行銷，他們會抱怨研發什麼都說做不到。如果你問研發，他們會說行銷總是異想天開。

當然商業模式成熟，具有規模經濟優勢的大公司，是可以忍受這樣的內部對立與效率損耗的。但身為資源匱乏的新創公司，你沒辦法負擔內部有這樣的對立。

改善的方法有兩個：第一，創辦人必須要既懂市場又懂技術。第二，創造一個結構，讓行銷越來越了解技術，也讓研發越來越了解市場，久而久之，他們需要你當橋樑的機會就會減少。

創業不只是在改善市場真實存在的問題，在營運上也要積極突破窠臼，才能在時間與資本的重重限制下，有機會打敗高聳站立的巨人們。

___

歡迎在 Google+ 上加入我

聊完了軟體工程估算時間的問題，工程師薪水的問題，今天來和大家分享兩個很不錯的程式設計「做」與「不做」列表。首先，是 Andres Taylor (安綴斯‧泰勒) 寫的「Top 10 Things Ten Years of Professional Software Development Has Taught Me」，翻成中文就是「十年的程式設計經驗教我的十件事情」。

原文不長，裡面有很多不錯的觀念，我鼓勵你們去讀讀。以下是中文版：

1. 物件導向比你想像中的還難，很多
2. 程式設計師最重要的技能：溝通
3. 你必須要學會說「不」
4. 如果所有的事項都一樣重要，那意思是它們都不重要 — 無論如何必須把先後順序排出來
5. 千萬別把事情複雜化
6. 深入問題的核心，但是不要被困住了
7. 非常清楚的了解其他人在做的事情，無論是行銷、設計、客服
8. 你的同事就是你最好的老師  (你該試試 Pair Programming)
9. 無論如何最後的產品必須是好用的
10. 這世界上總會有一些混蛋

而至於什麼事情應該要避免，大家可以參考 Dare Obasanjo (戴爾‧歐巴桑侯) 寫的「Top 10 Signs Your Software Project is Doomed」，翻成中文就是「十個軟體專案注定失敗的跡象」。

1. 第一個版本就想做太多功能
2. 採用太新的技術平台
3. 「複雜的問題，需要複雜的解法…」
4. 團隊人手不足
5. 成員開始隱藏進度落後的事實和原因 (Schedule Chicken)
6. 不斷更改、增加的需求 (Scope Creep)
7. 不知道客戶在哪裡
8. 2.0 症候群 — 後繼版本非要更大、更強、更美 (Second System Syndrome)
9. 與公司裡面另一個很有份量的產品競爭 (這在創業團隊應該不可能發生)
10. 根本從一開始就選了一個你無法解決的大問題

以上，跟大家分享，希望能夠幫助你們在做的產品更順利、更成功，加油！

(via Coding Horror, photo via stianeikeland CC license)

我們都有這樣的經驗：要開發一個東西，請工程師估算時間，大概要五天。結果過了一個禮拜，東西還沒出來。一問之下，碰到了原先完全沒有預期的情況，否則就是某個套件原來不能這樣用，必須要換一個，否則就是一個莫明的錯誤，找了一個下午還是不知道為什麼。久而久之，工程師開始習慣在回報的時間裡面灌水，預留空間給這些「未知數」，而我們也常常把他們給的時間乘以二，來得到最壞情況的數字。問題是這樣的方法之下，最後整個組織開始習慣用最龜的速度前進，因為估算精準、動作快，在這中間一點好處也沒有。更壞的情況，是叫九個女人去生一個小孩，那才是災難的開始。

為什麼軟體工程無法估算時間？

要了解這件事情發生的原因，你必須要先知道為什麼軟體工程是無法估算時間的。我以前常常喜歡用「常態分布」來解釋軟體工程時間的花費 — 上述的情況，讓大家慢慢從 Average 變成 (Average + 3 STD) 估算，最後平均浪費了 3 STD 的時間 — 不過這只是統計學上的解釋，並不是真正的「原因」。直到我前幾天看到這篇文章：「Why Can’t Developers Estimate Time?」，才給了我超大的一個領悟。(文章有點難，不過英文不錯的人，我鼓勵你們去讀讀。)

作者 Ashley Moran (愛許麗‧莫倫) 說：

我們無法預測軟體開發中每一個項目的時間，是因為這些工作的本質就是「創造新知識」。開發軟體的目的是創造「自動化的流程」，一但目標達到，自動化後的流程就可以重複的被執行，在可預測的時間裡面。所以一個軟體就像是「食譜」一樣，而電腦就是「廚師」，輸入的資料是「食材」，而輸出的資料是「晚餐」。

因此，我們在做的事情是讓未來從不可預測，變得可預測，讓大哥小弟、老爸老媽、只要想煮飯的，人人都可以當食神，給他三十分鐘，都可以弄出一鍋超級無敵海景佛跳牆。所以，「開發食譜」這件事情的本身，是一個創造新知識的過程，時間上當然很難預測。

如何管理

因此，軟體工程用硬體工程的模型去管理，從出發點就是錯誤。一個建築案是先有了「藍圖」，才去估算每個細項需要的時間。當我們在做的是藍圖本身，怎麼能夠沿用他們的模型？如果是這樣，一個創業團隊該如何「管理」開發的時間？

我的答案是你沒辦法 — 你怎麼能夠控制臭蟲什麼時候要出現？但是你可以管理「生產力」，也就是確認團隊總是在高效率的情況下工作，那最後你會得到的是 Average 的工作時間，比起前述 Average + 3STD 快上了 3 STD，這前後有可能就快了 2-3 倍。

而要管理「生產力」，一個現代化的軟體開發團隊，我認為有以下的幾個好工具可以用：

• Pair Programming (兩人小組) — 一個人寫程式常常會有盲點，兩個人一起則可以看到對方遺漏的地方。更重要的是兩個人都會從對方身上學到很多知識和技巧，彼此都會成長。而當兩個人都了解一組程式碼，日後的維護也有了兩個選擇，不會因為一個人請假、離職，這些 code 就變成孤兒。記得給他們兩個鍵盤，實務上這會比鍵盤移來移去有效率。
• Daily Stand-Up Meeting (每日早會) — 每天早上固定開一個快速早會，全部人都站著，每個人依序報告昨天的進度，碰到的問題，和溝通彼此程式間該如何傳遞資料。這讓團隊明確的知道彼此的進度，也省去很多溝通不良的麻煩。
• 高效率的工作環境 — 開放、明亮、舒適的工作環境，或許讓大家換上拖鞋，確認團隊成員們可以取得他們需要的飲料、食物，但是不會吃得過飽、或是喝下過多的咖啡因。當其中一個成員困惑時，確認有人可以幫助他。
• 隨時找得到使用者 — 代表「使用者」的那個人 (通常是 PM)，最好是使用者本身，必須要隨時在現場，幫團隊解釋開發上細節不明確的地方。
• 設定上線時間 — 雖然你沒辦法知道每一個子項目會花的時間，但是你可以設定一個上線的時間，然後所有的人通力合作在那個時間之前，盡可能做出一個可以推出的版本。當然，如果第一個版本推出時你不會覺得丟臉，那就是花了太多的時間。

以上，希望可以幫助你們重新思考軟體開發該如何做，也希望對你們正在做的網站、行動應用有幫助。(當然這不是完整的列表，歡迎大家提出你們喜歡用的工具。）

___

除了網誌，我每天都會在 Facebook 分享許多創業者應該關注的資訊，歡迎追蹤

(Image via purecaffeine@flickr under CC license)