推 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）
我觉得你可以从这个例子去思考怎么去改变这一切:）