筆者規劃跟看過不少很奇特的流程自動化規劃的方式
正規的流程自動化的方法, 不外乎是以下幾種:

• 瀑布式
• Agile
• Scrum
• 隕石流程自動化
• 外包

但 在奇特的工作環境中 ...

尤其是 外行領導內行的團隊中就不是這樣子了 ..

誰 應該去判斷這項目需不需要做自動化
誰 應該去判斷這自動化的技術能不能被做到

正常的答案可能是

1. 不會寫程式的需求方
2. 不會寫程式的需求方+技術人員

在奇特的環境中卻會變成

1. 不會寫程式的需求方
2. 不會寫程式的需求方
3. 不懂技術的工程人員

以下是真實案例 ....

某需求方要求做一個自動監控的產品, 需求方要求技術單位, 這監控的產品必須符合幾個條件

• 要由多個設計單位共同開發, 但不准合作討論跟設計規劃
  • 簡單的說就是要各做各的
• 要監控的是訊號 (細節跟呈現方式不提供)
• 要怎麼做的方向是不給的
• 交期要短
  • 兩週的工作天要產出
• 做出來的產品, 一推出就要會大賣
  • 如果不會大賣, 設計單位考績就打D, 代表你們都在混, performance 很差

製作前, 硬體部門評估這做不到.
需求方的頭頭就要需求方單位的專案負責人去實際生出來.

跟硬體部門主管討論出來的方式是, 以下兩者同步進行

• 樹梅派 外接一支天線 跟做了一個外殼
• 使用單晶片 + 一個電路

Part A:
當兩周工作天到了後, 苦主一個人把PoC 做出來後 ...
苦主: 就是自己做firmware 跟軟體的人

苦主的上司就大罵: 你做那什麼東西, 怎麼那麼不穩定也不能用
苦主: 由於設計前的方向完全沒有確定要做什麼, 又只有一個人不是專職的在做. 兩周出來的只是PoC. 而不是正式可以賣的產品
苦主的上司: 做不出來還有理由, 那就是你都在混啊. performance不好
苦主: ........

Part B:

罵完後就繼續開發 .....

某天, 苦主的上司臨時說: 你做的那東西 國外分公司有客戶想看demo ...

那時的流程是 訊號端+firmware 是苦主做, 後端的分析跟呈現平台是團隊B協同開發

狀況來了 ..

由於已經開發到版本轉換期, 上面的又臨時說要demo ...
那時被隨便帶出去的東西跟狀態是

• 硬體+韌體: 舊版的sample
• 後端平台: 新版

由於是需求方的主管在不通知的情況下,隨便去拿的 ....
當時就從國外傳回 根本不能用啊, 要直接記過處分 ...

(真的是心裡OOXX到極點)

當上面的人從國外回來後, 案子就整個被端走了 ...
端走的原因是, 苦主做的東西根本不能用 導致業務延宕 ...

(這件事情本身就是一個圈套, 很早之前就有人跟苦主打Pass 說那東西根本沒客戶要看demo, 是內部的團隊在詢問狀態而已. 內部的團隊也知道, 開發不會那麼快. 尤其是沒有方向的情況下)

專案被搶走後 .. 到了歲末年終, 苦主就收了考績D 的評價. 上
面說: 因為你今年都在混, 沒把你fire 就不錯了

苦主: ......

結論:
不管自動化的流程怎麼規劃都會被政治因素搞死, 除非上面的人很有sense跟支持. 不然怎麼規劃都是沒有用的
以這個例子而言, 有用到外包. 先找人做完後再搶回來抹黑就好了.
最後, 專業的技術很重要嗎? 筆者真的不知道