業務和IT分離的時代已經過去! - OSKAR
業務和IT分離的時代已經過去,問題空間和解決方案分離的時代已經過去:
“請給我解決方案,而不是問題!” 我從業務和管理部門多次聽到這句話。你也聽說過,不是嗎?
我們程式設計師應該回喊“請給我呈現問題,而不是解決方案!”(你在教我做事嗎?)
想象一下,你正在從事人力資源系統的工作:假期、合同,諸如此類的事情。"業務 "來找你並說
"聽著,讓我們做一個網路應用,員工將在其中記錄他們的工作時間。我們最近在廚房裡談到了你的那些 "Reacts "和 "Angulars"。我們可以用它們來使它看起來不錯。你願意做嗎?"
於是,規劃開始了:嚴肅討論我們是否應該把表單放在這裡,或者把網格放在那裡。與後端進行激烈的談判,我們是做一個REST API還是GraphQL。在另外的會議上討論合同應該是這樣的還是那樣的。
爭吵過後,最後發現我們甚至能夠按時完成專案,即使是Jira中的需求(嗚呼!)。
這個系統只有幾個bug。我們需要多個衝刺階段,但工作已經完成了!這就是我們的工作。
如果它是如此美麗,為什麼它如此糟糕?
事實證明,系統使用者並不樂意在工作時每天手動輸入。以前,他們把自己的工作時間輸入Excel表格,每週一次傳送給他們的主管。然後,主管將其混合成一個大的Excel檔案,並將其傳送給人力資源部門。
這些不快樂的使用者會嘮叨著要你在你巧妙設計的系統中增加或糾正一些東西,以解決呈現給你的問題。在這種情況下,當不高興的使用者遇到他們不喜歡的解決方案時,最終會發生對抗。對抗可能是痛苦的,但也可能是有益的;它們可以暴露出需要解決的真正問題,而不是別人交給你的解決方案。在這種情況下,事實證明,使用者填寫時間表的能力並不是需要解決的實際問題。
它是由別人決定的問題的解決方案。
真正的問題是,人力資源部門需要知道每個人工作了多少天,以核實時間表和計算費用。永遠忙碌的小組長們被其他工作埋沒了,遲遲不能把這些Excel檔案放在一起。他們還把它當作一項繁瑣的職責,犯了很多複製/貼上的錯誤。工作人員也浪費了核實這些資料的時間,並在之後糾正這些條目的錯誤。
如果我們要問實際問題是什麼,我們可能會得出結論:你可能不需要建立一個新的網路應用程式。也許你不需要製作新的API。
只需要:
- 建立一個集體的電子郵件賬戶來傳送和接收Excel電子表格。
- 將這些與電子郵件系統整合,從該賬戶中抓取電子郵件,匯入附件並進行解析。
- 如果Excel中不包含錯誤,資料將被儲存到人力資源系統中。之後,它將向僱員傳送帶有確認的答案。
- 如果電子郵件不正確(例如,它不包含附件,不可能解析它或條目是錯誤的),系統將傳送一封電子郵件,要求更正。
結果可能是更有道理,做起來更快,對每一方都更方便。
我們程式設計師通常有兩種態度:
- "業務不會告訴我們如何寫程式碼":我們是大寫的程式設計師,我們最瞭解一切。
- 業務知道系統應該如何運作。我不會要求他們澄清的一些疑問。我只要按需求編寫程式碼。
這兩種態度都可以說是不負責任和危險的。
作為程式設計師,我們瞭解技術:這就是我們獲得報酬的原因。因此,"業務 "不應該來告訴我們使用什麼框架,或者如何建立API端點。
當然,前提是應用程式與我們的設計:
- 做它應該做的。
- 準時交付。
- 維護成本與其他解決方案大致相同。
- 不增加專案風險(例如,更高的開發成本)。
技術決定應該完全屬於我們。當然,我們的選擇的後果也應該是我們的。
然而,我們必須記住,我們不是商業專家,即使我們是一個高薪職業。讓我們把話說清楚:我們是高薪的工匠,而不是藝術家。我們的工作應該是幫助企業有效地掙錢。我們不是某個領域的業務流程的專家。
但是!
我們不能假設 "業務 "知道一切。如果我們的業務領域是人力資源和工資,"企業 "會明白授權管理皮膚應該是什麼樣子嗎?或者他們會知道我們有哪些選項可以與外部系統整合?他們會知道登入螢幕應該是什麼樣子的嗎?或者哪個表格會更漂亮?
也許他們會,但很可能他們真的不知道,因為這不是 "核心 "業務領域。商務人士都是專家,例如,人力資源和工資單。他們可能會猜測其他功能應該如何工作。
通常的情況是,"業務 "想要幫助我們解決問題,並自動提出解決方案。當我們問:"為什麼要這樣?"那麼我們經常會得到這樣的答案:"我不知道,我想這樣會讓你更容易。"。
我最近就遇到了這樣的情況,我的產品負責人希望我們在一些後臺操作的時候阻止所有使用者使用該記錄。
我們必須主動詢問,以確定我們得到的是對實際問題的描述,還是隻是別人向我們提出的解決方案(潛在的商業解決方案)。當我們試圖理解一個商業流程時,我們不會質疑它的正確性。事實上,我們的職責是幫助企業解決問題。盲目地接受需求,我們根本沒有幫助他們:我們甚至會使情況變得更糟
我預測,軟體公司和商業公司各自為政的時代很快就會過去了。這是過去的遺蹟,IT系統重複人們正在做的事情,以使其更快。現在隨著SasS解決方案的不斷髮展,IT就是商業。因此,業務和IT之間的密切合作不再是 "很好擁有",而是 "必須擁有"。
考慮一下以下情況是一個問題還是一個解決方案?
- SASS系統中的許可系統
- 使用者管理皮膚
- 認證和授權
- 唯一的發票號碼
- 開發一個貨物處理系統
相關文章
- 業務和IT分離的時代已經過去? - OSKAR
- 幽默:微積分可能已經過時 - AlejandroPiad
- Wasm 原生時代已經來到ASM
- IDC報告:企業外部儲存時代即將過去?
- Digital Turbine對Fyber和AdColony的業務整合已經完成Git
- 資料新時代已經來臨
- Runway CEO:AI公司的時代已經結束了AI
- AI大模型時代,人才的需求已經變了AI大模型
- 過去分詞的辨析分詞
- 動詞過去式過去分詞分詞
- IBM :我們所熟知的通訊服務時代已經結束(附下載)IBM
- 將業務邏輯和雲架構分離的多執行時Muilti-Runtime的微服務架構 〜Bilgin Ibryam架構UI微服務
- AI時代需要的網路,跟過去有什麼不同?AI
- 通過Eureka中已經註冊的服務名,呼叫服務
- 使用multus實現管理網和業務網分離——calico和flannel共存
- 2020已經過去五分之四了,你確定還不來了解一下JS的rAF?JS
- OpenAI CEO表示巨型AI模型時代已經結束OpenAI模型
- Barclays:迪士尼流媒體業務估值已經超過1000億美元
- 使用 django middleware 和 celery 隔離業務系統和積分系統的嘗試Django
- 寧德時代:目前公司已啟動鈉離子電池產業化佈局BLX產業
- 已經離開的人就永遠離開吧
- 時代和技術在變,但數控分離的架構設計理念未曾改變架構
- 數字化時代的科技雙模,雙模IT成為過去式
- ABAP 真的會過時嗎?聊聊 ABAP 的過去,現在和未來
- 應用架構之道:分離業務邏輯和技術細節應用架構
- 前後端分離時代,Java 程式設計師的變與不變!後端Java程式設計師
- AI時代已經到來,80%的程式設計師將無路可去AI程式設計師
- Kubernetes 已經成為雲原生時代的安卓,這就夠了嗎?安卓
- 第1期 | 撫今 現代企業已步入新的專案制管理時代
- 辛辛苦苦學會的 webpack dll 配置,可能已經過時了Web
- 那本你小時候看過的雜誌,如今已經500期了
- AIGC時代:未來已來AIGC
- 面試官:你使用webpack時手寫過loader,分離過模組嗎?面試Web
- KingData:BSC和以太坊上的DApp已經超過100萬個APP
- 命令和事件有什麼區別? - Oskar事件
- 華為音訊編輯服務,實時分離人聲、伴奏和樂器聲音訊
- Supercell的時代過去了嗎?
- 《鏡子》《過去已死》閱讀筆記筆記