過去的軟體開發方式都像是大隊接力的模式，當需求被釐清之後 (p.s. 也有可能沒釐清) 就會逐步的流到開發團隊中各個角色身上，而每一個腳色就如同一個大隊接力的每一棒，當上一棒跑得差不多之後，才能上場等待接力上一位傳來的棒子。

這種奇妙的軟體開發模式其實充斥著整個行業，為什麼會是這樣呢？因為這種管理模式就如同百年前的工業時代那般，將所有工作流程化後，逐步讓工廠的管理完善，而每一位流水線上的工作人員僅會知道自己所負責的部分，對於整體甚至是上上一位或者是下下一位在做些什麼？其實是一無所知的。

當軟體開發採用了這種形式之後，每一位開發的腳色，無論是 UI/UX 還是維運人員都是這大隊接力中的一份子，沒有例外的，每一位都不知道對方在做什麼。這種模式可能會衍生的狀況有以下:
1. 每個腳色都克盡職責，做好本份內的事情，對於其他腳色在做什麼，一概不知，也不感興趣。
2. 有些成員將工作移轉到上游或者下游身上，造成其他成員的困擾，但是為了專案 / 產品能夠順利完成，只好咬著牙繼續撐下去。

由於軟體開發已經逐漸從藍海市場轉變成為紅海市場了，因此，繼續採用百年前的工作管理模式，能夠與其他競爭對手一較高下嗎？相信答案你已經有了，但是該如何進行轉型？

改變認知

人們不願意改變是因為改變會帶來未知，而人類的祖先們畢竟經歷過凶險的時期，在基因中早就已經銘刻了避開危險 (未知)，因此，面對未知，絕大多數人選擇的是逃避。逃避雖然可恥，但是的確有用，起碼在心理層面有效果，但是這對於整個團隊是正向的幫助嗎？

改變認知的底層邏輯在於讓人們對於目前已經持有的信念產生懷疑，進而逐漸被新的理解所取代，當這個新的理解在往後許多場景中都被印證是可行的，就會成為新的認知。

透過理論 + 工作坊，讓這個可能性被達成。

盤點現況

做出任何改變之前，一定需要確認需要改變的部分有哪些，絕對不會是全面的大翻新，而是精準的指出哪些部分是需要：替換、改變、調整。我使用三個動詞來陳述，並以列表說明三者的不同：

• 替換：以整體或者是目標來說，該元件已經不適用，需要完全汰除
• 改變：該元件仍可使用，但是形式 / 定義需要重新賦予
• 調整：該元件仍可使用，僅需修改其中部分元素即可

從上面的描述中可以知道，其變化幅度是由上到下的，越是上面的改變幅度越大，同樣地，成本也會越高。因此，如果經由分析之後，發現到有許多地方都是需要採用 “替換" 的解決方案，那麼就需要更詳盡的規劃和優先順序的安排。

想要知道改變的成本以及規劃，勢必逃不開分析，而分析是做什麼呢？其實就是：現況 (As-Is) 和目標 (To-Be) 能夠讓所有參與改變的成員理解，如此一來，在後續變革的路上，才不會有太大的阻礙。

流程與組織

如果你想要改變流程，那麼你同時也需要改變組織。同樣地，如果你想要改變組織，你也必須要改變流程。這個是我擔任管理職多年所總結出來的經驗，很難僅改變其中一項就能夠達成目標。

不過你可能會想問，改變流程或許是容易的，畢竟自己是管理職有權利制定新的辦法和流程，不過組織是可以輕易改的嗎？難道不需要請示上級以及 HR 嗎？

在軟體開發中，有所謂的虛擬化，那麼這樣的概念是否能夠移轉到組織改變上呢？當然是可以的，你可以在你的團隊中，拆分出虛擬組織，例如：目前有某個緊急任務，需要團隊中的 A、B、D 三位成員處理，那麼由團隊成員 A、B、D 所組成的就是一個緊急救難的虛擬團隊。

而組織變更有可能是由上到下的，並且是 HR 同意之後公布。那麼，身為管理者的你，也需要盤點目前的流程是否仍夠在新的組織中發揮好的績效，如果無法，也需要改變流程以因應這個變化。

發現到了嗎？不論是調整流程還是組織，兩者幾乎可以說是一體的，如果目前的目標是希望能夠讓開發團隊往協作開發的模式發展，管理者就需要重新盤點和設計流程和組織。

制定指標

許多聽到 KPI 會有負面的反應，這很正常，因為許多指標會與自身的成績或者是直接一點的說，與自己的福利有著直接關係。

在坊間常聽到的就是 KPI 和 OKR，這兩者我都有使用過，並且了解各自的主要擅場。以 KPI 來說，它是用來觀察和確保事務的：過去、現在、未來的狀況，因此，管理者一定要能夠制定 KPI，不具備這種能力的管理者，績效通常不會太好，因為就如同走進黑暗森林，伸手不見五指的情況下，容易做出愚蠢的決定。

OKR 呢？這可是非常火紅的詞彙，OKR 偏向是激勵成員能夠讓目標對齊組織和自己的人生 / 職涯發展。任何最害怕的就是 “不知為何而戰" 的狀況，為了能夠妥善地避免這種負面消極的心態，一個較好的方式就是聆聽和了解成員的規劃，並且讓他能夠與組織的目標對齊，真正達到雙贏的效果，不過許多主管對於事務很專注，但是對於人就不那麼專注了，這就很容易會造成對於 OKR 僅是應付性質的處理。

兩者並沒有衝突，可以一起使用。當管理者想要觀察事務的發展，使用 KPI，當管理者想要確保團隊成員的成長與組織一致，那麼就使用 OKR。

想要達成協作開發，KPI 和 OKR 都少不了，也無法僅使用其中一個就能夠收到成效。因為這是整個團隊的變革，身為管理者的你定下了朝向協作開發的目標邁進，你需要制定 KPI 觀察這個計畫的進展，也需要和團隊成員溝通和制定 OKR，讓他想要做的事情能夠對於邁向協作開發的進展有著推進的助力。

結語

雖然標題是協作開發，不過主旨在於討論如何幫助團隊進行轉型。過去在擔任管理者的時候，由於沒有 Mentor 指導，很多事情都是靠自己摸索而來，這也讓我發現到一件事情，為什麼國外評價台灣的企業都是：一流技術，二流管理，三流行銷。台灣的技術是被認可的，但是管理方面真的太糟糕了，因此，也鼓勵管理者們多多分享你的經驗和看法，讓台灣逐漸成為三個指標都一流。