幻想場景：
主管：Ａ，我現在需要一個XXX功能。
Ａ ：這大概需要一週
主管：不行，兩天內就要會動。
Ａ ：這不可能做完
主管：Ｂ，給你兩天把這個做完。
Ｂ ：好。
兩天後
Ｂ ：做完了
主管：很好。Ａ，你看，明明可以兩天完成。
Ａ ：..........
這肯定有問題啊～這肯定有問題啊～這肯定有問題啊～
相信身在軟體業的大家，對這樣的場景應該不陌生，自己沒遇過應該也聽同學們描述過。
那到底問題出在哪裡？
即使我自己剛畢業也是個寫程式的工程師，現在帶著團隊也發生過不少次類似的狀況。我覺得應該一個工作天就可以完成的工作，但是 team member 會給出三個工作天的估計。這中間幾次討論的過程讓我發現這個溝通的落差，並且試著用一些方式來降低溝通落差。
通常對於功能面，已經有很多方法來減少溝通誤差。但是對於“完成度”、“目標” 的溝通落差卻容易發生在各個大大小小的開發流程之中。
大部分的溝通落差就會發生在描述一個功能的時候，我們並沒有去描述期待的完成度。或是期待的完成度與投入的資源有龐大的落差。
首先我會將軟體開發根據“完成度” “目標” 分成多個階段的定義。（這是我自己為了溝通產生的定義，各個組織應該都可以根據自己的溝通需求做調整）
讓我們用把運送人員從 A 點運到 B 點來比喻軟體開發。
一路上有草叢，樹木，大石頭，跟河谷。
Level A (Proof of Concept): 山徑小路
完成度：會動
目標：確認這一條路是通的
Level B (Prototype): 水泥小路
完成度：95%以上的狀況，不需要人力介入處理
目標：上線賣錢
Level C (Beta): 柏油大道
完成度：能夠處理各種不同例外狀況，不管什麼狀況都不用人力介入的動
目標：全自動處理，有完整的 monitor 跟 alert system
Level D (Production): 軌道工程
完成度：容易Scale up、完整的功能開發與上線流程確保99.99% SLA
目標：以穩定為前提之下，用最少人力支撐最大成長
Level A (Proof of Concept): 山徑小路
這個程度的軟體開發，目標是的是用最少的資源確定從A點到B點是否可行。
所以做法就是讓一個人，帶著指南針跟開山刀從A出發移動到B。不管過程多崎嶇，走了多久，看到樹木擋住就繞過看到河谷就下切上爬，只拿出開山刀清理草叢。
當完成任務時，這條路就沒用了，千萬不要拿這東西去賣錢，每次都得這樣走，頂多因為走過一次，現在可以有人整隊帶路。10個人就得一起跋山涉水走這整條路。
通常是新創或是嘗試新商業模式時會用到，畢竟如果別人已經有一條康莊大道從A到B，那麼你要做的應該是可以直接開始 Prototype。
Level B (Prototype): 水泥小路
這個階段做的事情就是要認真的考慮未來的成長，但是又沒有足夠資源完成完整的功能以及 Error Handle 。
比喻上來看的話，就是一小組人馬，帶著電鋸，跟水泥，鋪一條水泥小徑。盡量以直線的方式，將路上的樹木都清除，遇到大石頭就先畫線，然後繞過。遇到河谷就先量測哪邊可以搭橋，預先留下空間之後架設上下垂吊設備。
在這個階段，因為只是簡單的水泥鋪成的路，想要截彎取直，想要改變方向相對容易一些。同時道路會被雨水沖刷的機會也高許多。
在系統架構上花的時間越多，未來成長時遇到的困難就越小。但是這是理想狀況，實際上不管是因為對於軟體架構的經驗不足、對於商業邏輯的經驗不足甚至時間與資源的不足，經常容易選到未來不易擴張的做法。但是為了生存，為了與商業的平衡，算是一種取捨。
Level C (Beta): 柏油大道
在這個 Level 比 Level B 更多要完成的基本上與功能本身沒有太多關係，更多的精力是花在如何更穩定，如何自動化的處理各種例外狀況。
這邊的比喻就是要鋪一條柏油路，並且有穩固的周邊防護，遇到河谷還要造橋。
如果先完成了 Level B 那就是開始慢慢的把水泥小徑變成柏油路，並且加上穩固的周邊防護，讓送貨員不管遇到什麼天氣狀況，都不需要找工程師來協助。在 Level B時犯下的任何錯誤，欠下的任何債務，都是這個時候需要好好的還。
在 Level C 想要增加個支線雖然比 Level B 困難，但是基本上就是拆掉一些圍欄，拉出另外一條柏油路或是水泥小路，困難度比 Level D 簡單不少。
Level D (Production): 軌道工程
就是現在被罵翻的前瞻計畫軌道工程啦，如果在不確定運量的狀況，又不從 Level A, B, C 先做實驗與影響測試，應該就事只有浪費錢。
不過如果經過 Level C 的驗證，那麼建立起軌道工程就可以大幅度的提高運送量。然而除了造價高之外，中間想要增加個支線並且維持原來運送順利，所要付出的成本則大大的提高了。
=======
常發生的就是雖然對功能的理解沒有落差，但是對於完成度的理解卻有龐大的落差。
讓我們回到一開始的例子。
A 為什麼給出一個比主管期待更長時間的預估？
1. 因為主管想要的是 Level A 的東西，但是工程師想的是 Level C 的水準
2. 主管想要的是 Level C 以上的水準，但是卻以為用 Level A 的資源完成功能就好了
B 真的達成期待了嗎？
1. 主管要的是 Level A 的水準，B 完美的達成了
2. 主管要的是 Level C 的水準，只給了 Level A 的資源，因此 B 完成了 Level A 的水準，但是主管卻以為自己拿到 Level C 的成品
因此現在除了描述功能需求之外，完成度與目標我也都會盡量的描述清楚，減少溝通的落差。
Appier持續招人中，詳情請洽 加入我們
No comments:
Post a Comment