推 dream1124:我明白你的意思,要推動改革的關鍵在執行者累積的信譽 05/17 20:05
→ dream1124:還有大家的想法與共識 05/17 20:06
→ dream1124:那請問大家,要怎麼讓組織上層意識到現行做法有些問題? 05/17 20:07
→ dream1124:有在寫程式的前輩不支持, 更上層的平常不寫程式 05/17 20:08
→ dream1124:這樣意思是只能耐心等到重大有感問題出現才能趁機提議嗎 05/17 20:10
→ dream1124:現在是不大的問題都要稍微加點班,以後專案膨脹怎麼辦? 05/17 20:11
→ dream1124:處理問題要防微杜漸, 我是這樣想的 05/17 20:12
→ dream1124:就像土法煉鋼可以做破鐵器,不是無產值,但長遠不是好方法 05/17 20:13
幾個看法。
我自己也曾經待過IT 單位
以你描述的。你們應該是只負責內部ERP的單位
這種單位一般來說會認為掌握domain knowledge會認為比改善開發流程重要。
因為多半會認為，不管方法好不好。只要能解決的就是好方法。
更何況你也說架構運行已久，要轉換不是只有動張嘴巴，說比較好就可以。
這是需要花時間和花經費去做轉換的。
所以無痛轉換+Z>B是非常重要
而且你還要說服長官和同事一起做
（以你的說法。大家認為目前的狀況小小加班都可以接受）
舉一個例子
之前待的公司有一位資深前輩本身比較是技術狂熱
他之前想要改變當初的開發流程。
把MVC、linq、導入進去資料傳送、接受、下命令的方式
1.自己先搞出一套跨用門檻非常低、SOP機制完全沒有問題的流程
而且新舊流程都可以並行
2.自己把所有的底層都幹掉。只剩下最簡單的按照資料Table
建立model這一關，要自己建，其它API全部都寫好
3.徵求主管同意後（剛好我們主管也覺得大家有一些新技術是不錯的）
開了幾次課程。教大家用。只希望大家新需求開始用新方法
結果還是只有比較資淺或是新同事（像我），願意用新方法（因為跨入無門檻）
大部份資深同事還是繼續用舊的方法寫。
（我後來自己連手動建model都懶得做，就寫一個codegen。半自動產生了XD）
我覺得你可以從這個例子去思考怎麼去改變這一切:）