0 →1 ? 1 →100 ? 軟體顧問到底在顧什麼？

功能的厚度？https://revteltech.pse.is/feature-thickness

忻旅科技軟體開發顧問：https://consult.revtel.tech/

最近幾年陸續做了一些顧問案，從醫療 IoT 設備的系統架構規劃到國家藝文單位網站的建置建議都有。但除去直接顧問，在過往蠻多合作的執行過程中也都參與相關產品規劃及技術配置，比如隨選電信電商、金融看盤軟體及印刷 ERP(更多案例可參考 RevConsult 軟體系統顧問)。

這篇來聊一下到底這些歷程中的軟體顧問在做什麼

難道你會比我更了解自己？ 外面的人真的能給建議嗎？

首先得先回答一個問題「為什麼需要從外部找尋顧問？」

在第一次執行顧問案之前我就是先從這個問題開始，畢竟如果大方向錯了一切也就白搭。

確實最知道自己要什麼的應該就是自己，但外部顧問應該至少要有兩個價值

1. 不被內在阻力限制的觀察角度
2. 團體在運作過程會有些明顯或隱性的內部阻力，其可能來自科層結構或組織慣性。這時候外部視角往往可以比較中立。
3. 有局中人沒有的資訊儲備及來源
4. 「燈下黑」一直是需要避免的陷阱，局中人往往會因為不具備需要的資訊而很難做出客觀且正確的決定。

基於這兩個點在過程中不斷調整才能避免失焦。

試著以風險掌握度貫串整體

不知道大家有沒有做過工作上的交接？不管是交給別人或者接過別人的任務，交接完成後總會覺得好像有做到什麼，但又哪裡怪怪的！？

交接的本質要點在於風險的排查(更多內容推薦大家可以參考湯君健·給中層的管理課30講)。如果沒有辦法從風險角度作思考，最後可能就是流於一堆的圖紙及文件。

顧問的協作也是這樣，通常我把它視為是邊界偵查的一部分。把握到合作方到底在哪些地方需要你的協助對於整體至關重要。

舉例來說，過往曾遇到「我要開發 APP，請問 iOS 跟 Android 時程及功能該怎麼安排比較比較好」的命題。在這裏就有很多可以探討的點，茲列舉兩個

• 開發 APP 的這件事是否正確？這個問題的出發點可能來自對 WEB 生態系及營運的不理解
• 分開開發 iOS 及 Android 是否正確？這個問題的出發點可能來自對整體資源管控及人員配置的不確定

失之毫釐謬之千里，要是沒有正確的判別出方向其實最終顧問品質也不會好。

0 → 1 及 1 → 100 是兩種導向：效率及穩定的取捨

延續邊界掌握的議題，因時制宜因地制宜也很重要。比如要判別當前是屬於 0 → 1 還是 1 → 100 的狀態，其追求解答的方向也大相徑庭。

如果處於 0 → 1 的階段，往往會是追尋效率最佳化。在這種情況下摘除不必要的相依性來打帶跑可能就會是答案之一。而如果處於 1 → 100 的階段就不太一樣，在已經有一定成果的基礎上穩定過渡及適時煞車可能就是必要的

0 → 1 及 1 → 100只是舉例，事實上每個時刻的問題情境都有很多複雜維度。給出跟團隊文化差異太大的建議方向，下場可能就不會太好 … 很多時候還是得努力穿過重重迷霧，畢竟

• 你不知道你不知道的事
• X-Y 問題也很困擾人，有時候逛了一大圈才發現問題其實出在更根源的地方，這裡就很考驗訪談跟梳理的能力了
• 你不一定知道你已經知道的事
• 越是成功的 SOP 或文化常常像空氣一樣不會被人提起，外部人員得花點心力去發現來勾勒當前狀態

引入主觀：接受妥協 > 提出異議

最後一個點是盡力引入主觀的意見。

這裏可能會有朋友覺得怪，前面一直提到中立及客觀分析，為什麼這裡反而要引入主觀意見呢？

因為顧問協作並不完全只是靜態的資料蒐整及分析，最後加入屬於自己的主觀視角能有助於更深刻的展現之前所爬梳的資訊。

舉個例子來看，真實世界的開發及維運總是不完美、總是得在各方折衝之下取得平衡。列舉各個維度需要「避免」什麼不如直接指出哪些「妥協」是可以被接受的。

其實這個原則也會有助於整個顧問協作的節奏收束。通常一開始我就會訂定好最終的預期目標並跟合作方討論以確保最終成果是有效的。

總結 — 每件事都是學習

以上的一些思考主要來自這幾年下來的自身經驗，權且做個分享。也相信不同領域或者換個人作法及思考點可能跟我大不相同。

紙上得來終覺淺，絕知此事要躬行，軟體顧問畢竟是個水極深的領域，對我來說也是藉著機會不斷打磨屬於自己的觀點及心法。總的來說，每件事情都是學習。

您又是怎樣做顧問服務或者給別人意見的呢？

RevtelTech 忻旅科技 https://www.revtel.tech/

email：[email protected]

facebook：https://www.facebook.com/RevtelTech/