跳槽到新創團隊一陣子後，隨著一開始的新鮮感跟熱情逐漸散去，疲乏感就漸漸回來了。
相較於原公司的官僚，這次的疲乏感來源在於，團隊在乎的是開發時間要短、速度要快，而不看重細節與品質。
雖然可以理解新創團隊有其壓力，需要趕快滿足客戶的需求，需要趕快找到適合的商業模型，需要趕快建立起自己的品牌等。但作為一個工程師，心裡總是希望可以做出更好的成果的。
不過說起來，不管在什麼規模的公司，好像或多或少會遇到類似的問題，畢竟「時間」跟「品質」對專案管理來說，本來就是一件非常對立跟糾結的事情，很難做到大家都滿意。
專案管理三角形
有一個被經常用來分析專案的模型：專案管理三角形。在專案管理三角形中提到，品質受限於成本、範圍、時間，套用在軟體開發團隊中，最大的成本是就是人力資源，再來是一些運算資源，範圍就會是專案的規模大小，時間則是專案開發時程。
專案管理三角形：品質 = 成本 + 範圍 + 時間
成本通常是固定的，因為開發人力就是固定的那些人，臨時從外部找人是很困難的，最多是從內部其他團隊調人來支援；而範圍則通常也不是工程師可以決定的，大致上就是老闆說了就算，頂多可以稍微討價還價一下；所以對工程團隊最有討論餘地的只有時間，但工程師通常也只能盡量把時間估算的精準，想辦法找到底線，跟老闆討論搓合出一個合理的時間。
但問題來了，為什麼老闆或主管總是對估出來的時程不滿意，想要砍時數？而對老闆來說，為什麼驗收時間還是總是會延後？這就要我接著要談的專案範圍模糊性了。
專案範圍的模糊性
專案範圍的模糊性指的是，同樣的專案，每個人看到的實際工作範圍都不一樣，所以其實是有一定程度的模糊空間。而根據大家看到細節的不同，不同團隊估出來的時程會有很大的差異。
我們先不要討論太不切實際的，我們就拿「將商品加入購物車」這個需求來舉例就好。光是這個功能，兩個不同的團隊所估算出來的時間可能就會差上數倍，為什麼？
當一個團隊說一個禮拜就能完成，那它可能真的就只做了「將商品加入購物車」。把商品加入購物車，就這樣，沒了。
而另一個說它需要一個月開發的團隊，除了完成「將商品加入購物車」以外，也處理了各種例外狀況，比如說，商品無庫存時，無法被加入購物車，已加入購物車的商品，若已無庫存則做特別標記；這個團隊也同時將使用者介面做了最佳化設計，每個按鈕及資訊擺放的位置，都有經過細部調整；甚至連流量問題都解決了，可以承受瞬間大量使用者使用購物車的情境。
所以可以看到，一樣都是「將商品加入購物車」，兩個團隊做的事情的量跟尺度完全不一樣。說不定第一個團隊還只是能把商品加入購物車，沒辦法接著做結帳呢。
所以問題就來了，到底應該要像第二個團隊一樣，把相關的需求都一次做好，還是像第一個團隊一樣，只做完字面上的意思？
我覺得這就是專案範圍定義的模糊所在，這不會有標準答案的，即便是專案規劃的非常詳細，將所有細節都條目列出，也還是會有疏漏的地方。
抓大放小
因為每個團隊看到的細節不同，所以每個團隊估算出來的開發時程都不一樣。老闆看到的、想像的，跟實際開發的人所完成的項目會不同。
於是在與老闆談開發時程的時候，為了符合老闆心中滿意的時程，工程團隊就僅能利用專案範圍的模糊性，在某些程度上犧牲掉細節，只挑選優先順序比較高的項目來實行。
從好的方面來看，可以說我們把資源放在最有效的地方，畢竟例外處理或細部處理，一般情況下，不會影響正常使用。但是從壞的方面來看，作為一個工程師，對於自己開發的產品，總是會帶有「希望我做出來的東西是好東西」的心情，如果不能好好的雕磨細部，心裡總覺得不踏實。
而且有一個風險所在，工程師怎麼知道自己跳過的那些細節，是不是重點？
踩過雷才知道痛
而這樣的問題難道只出現在在新創嗎？
不，新創這個詞一直都是很模糊的，我覺得應該更明確的限制在「缺乏成功軟體開發經驗的組織」。
缺乏成功軟體開發經驗的組織，可能沒有踩過幾次雷，或是踩雷了，仍然不知道問題出在哪。面對一個需求的開始，總是過於隨意跟果斷，所以會隨便就開始專案，隨便就說要驗收，隨隨便便就逼著工程師壓時間，然後做出一個不好的產品之後仍然不知道問題出在哪。
而有成功開發經驗的組織，團隊成員過去或許踩過好幾次這樣的雷，與團隊產生了很多次衝突，但漸漸溝通改善，後來定義範圍的時候會比較小心，對於工程師提出來的時程也比較有概念；一個需求沒有經過仔細評估規劃，不會任意啟動，也不會任意把資源放下去。
結論
其實說到底就是溝通的問題，要是老闆或是 PM 總是太忙沒空跟你溝通或是不想跟你溝通，那這個專案的「品質」很大程度會取決於工程師的良心跟熱誠。
所以承接一下本文最一開始的出發點，為什麼追求快速會對工程師帶來乏力感？因為工程師會希望自己能做出好產品，要能夠顧及細節，要能夠把事情做好。但為了滿足老闆對時程上的需求，只能放下那些想做的細節，專注在比較有經濟效益的事情上了。