Re: [心情] 前輩拒絕導入任何其他工具....

作者: leoace (leoace)   2014-05-19 23:40:15
引述電影寒戰的台詞:
每一個機構,每一個部門每一個崗位都有自己的遊戲規則。不管是明是暗,第一步學會它
,不過好多人還沒有走到這一步就已經死了,知道為何?自以為是。
第二步,就是在這個遊戲裏面把線頭找出來,學會如何不去犯規,懂得如何線上球裏面玩
,這樣才能勉強保持性命。
結論: 你要在無論在軟體界或在其他環境生存,一定要學會明的或暗的規則。每個環境都
有它的遊戲規則,搞清楚規則再玩,才是明哲保身之道。
進公司沒多久,應該要把公司遊戲規則搞懂,有時候軟體會用這種管理方式是有它的歷史
因素存在的,也許一隻程式經手好幾十人,一段程式碼可能是因為專案評估錯誤造成要
加班努力趕出來;也有可能是相同模組賣給不同客戶但介面不同,功能需要客製化等因素
造成你現在看到的結果。你看到的是結果,就說這個管理不好,這個要改、架構要改...
老鳥大概會覺得這樣的新人是自以為是
所以進公司第一件事情就是把請把線頭找出來,學會在這一個遊戲規則下生存,在你可以
掌控的資源中來進行你覺得應該要做的事情
Ruby on Rails在web application framework生產力比JSP高出30%,這樣為什麼一堆公司
還在用JSP開發呢? 維運成本跟資源的掌控才是大部分的公司考慮的重點。你光要換掉JSP
後端,除非你是主管有勇氣承擔替換過程的混亂時期,不然你就提個所謂的
"加速後臺生產力執行計劃書" 並且提出WBS(Work Breakdown Structure),以專案
執行的方式來看待此事,以專案管理的做事方法來進行此事,你就是此計劃書的PM,
因此你要做的事情要有:計畫、時程、資源分配、風險評估、預期效益、Staffing Matrix
(就是誰要負責哪件事情)、教育訓練、範圍為何等諸多任務以及其解構之後的工作細項。
在執行的過程中要有高度的意志力來貫徹此專案一定要成功,不然也是嘴砲而已。
引述電影寒戰的台詞:
基於一個片面分析,沒經過嚴密的邏輯推算。浪費你們的寶貴時間是不是很興奮啊,
等你坐上我的位子,你就會心裡有數。
這不是一個新人說我覺得這個很好,所以後我們就全部換成這種管理模式,這麼簡單
再來講維運成本:
會JSP比RoR的人可能是好幾10倍,在人力市場上要找到可以立即上工的人機率很高,
加上如果案子從研發轉移至維護單位,駐點也許只要學Apache以及網頁的基本設定以及
依照安裝手冊跟問題排除程序就可以保持良好的維運狀態,因此聘請駐點工程師的成本
就會降低。要是你換掉了,萬一負責開發的人離職了,可能替代的人要在人力市場上找
很久還不見得找到可用的人。
因此有些主管會要求說程式不要寫太難,因為接你的人會看不懂也是一樣的道理
你用 git SVN想要取代舊有的專案以及軟體維護方式,也許這一套軟體在客戶端已經安裝
上千套,程式可能在幾十年的開發下已經在既有的管理模式運作得好好的,要改變的話
在初期光commit跟版本分類就需要討論很久了,替換計畫為何? Role & Responsibility?
老鳥有很高的機率在趕案子,對老鳥來說維持現有的模式一定是風險最小,而且你忽略了
RD的主要工作不是這個,是 "產出",長期來看這個投資是值得的,但是需要有一個計畫
來完成,你確定你的主要工作(main job)是這個? 還是coding? 你的KPI有這一項嗎?
如果你跟你同事的KPI都沒有,請問誰要來幹這件事情?
另外有這樣的想法很好,但想法最終還是要回歸執行力,因為用嘴寫程式永遠比實作來的
容易。你要實力足以讓同事以及主管認可,如果沒有的話,那還是在你可以掌控的資源中
進行你覺得應該要做的事情。例如: 自己的程式自己管,同時也讓你同事知道你在做
可能改天同事突然性情大開,希望能跟你一起改造這個巨大的程式怪獸
舉我的例子好了:
我剛進公司的第一個禮拜就在觀察RD的工作方式,結果就看到Execel紀錄Bug, 資料夾命
名法, 要什麼程式跟文件都要問特定的人, 主管記得在幾年前有哪幾個功能要找出來,就
直接叫我去問負責開發的RD,大概有25%的機率會得到的答案是這個做的人已經離職了,
你確定要嗎 ? 我找到後再寄給你;或是"這個功能當初只給某某客戶用而已,因為合約有
寫到,但不在主要程式中"等等這種開發模式。研發部門RD有一半待超過6年以上,而且
公司規模還不小(>100人)。
所以我前兩個禮拜就在公司自己架設 Redmine + SVN, git用來管理我自己的程式,因為
我是主要負責一個新產品的開發,主管也沒在管我管理的方式。之後我就鎖定幾個同事
詢問有沒有興趣試用看看,結果都是開帳號後就再也沒登入過了。或是得到的答案是
"等我這個案子忙完"、"我很有興趣、但我現在沒時間"、"有沒有相關的資料寄給我"等
後來新人補進來後,我強制規定一定要用Redmine管理,程式上版本控制系統,幾個月後,
主管發現我在用這種管理方式,現在想要推廣到其他產品跟專案試試看,但目前仍然是
很沮喪的狀態。轉換工具的過程需要時間跟縝密計畫,最重要的是要有權力的人支持你,
讓你的同事相信學這樣的東西,可能每天花你10%的工作時間,但是可以讓他的工作效率
提升30%。你要讓他相信你做這件事情不是挖洞讓他跳,最重要的是這需要時間慢慢來
如果你的實力被大家認可的話,相信你應該可以做得到,不要只是出張嘴而已。
引用用寒戰最後一句台詞,作為結尾:
我以前都看不起你 因為你沒有實務經驗 但我錯了
就因為你沒有實務經驗 所以可以用更宏觀的角度看事件 00局 00署 都是你運用的工具的
(後面不太記得)
※ 引述《tyc5116 (累人啊....)》之銘言:
: ※ 引述《superpai (超級白)》之銘言:
: : 我只想問改用 Git 的風險在哪裏...
: : Git又沒有很難也不用錢也不會幫你code加入bug
: : 也不是最新的科技,也沒聽過不穩
: "為了便於新人學習,所以程式@#$%^&*()",簡單說就是引用工研院的程式架構MSD
: MSD意思就是把程式分成Model,Status,Design,將程式分為數個次模組
: 每個模組有各自的狀態切換,然後將其轉換為程式,細節就不說了
: "我們的程式架構雖然有很多改進的空間,但是堪用"
: 因為公司到現在程式的管理都是,今天開一個20140519的資料夾,
: 明天再開一個20140520的資料夾,導入Git總沒問題了吧?還是免費的東西耶!!
: 不但免費,現在也發展的很穩定了(應該是吧....XD)
: mail給小主管,cc給主管,小主管的回應是"有機會分享給其它同仁"
: 心得:
: 1.新人還是安靜點,說太多沒人會理你
: 2.自己有好東西自己留著,如果人家主動想要學再教別人
: 3.如果教別人要花很多時間,人家還不見得聽的懂,那就直接跟他說"我不會"
: (分享一下我老師說過的話XD)
作者: Ting1024 (無)   2014-05-19 23:43:00
+1
作者: yauhh (小y寶貝)   2014-05-20 00:38:00
完美的評論
作者: ray33 (愚人)   2014-05-20 00:44:00
推好文
作者: lovdkkkk (dk)   2014-05-20 07:54:00
推 在你可以掌控的資源中來進行你覺得應該要做的事情
作者: kwk22   2014-05-20 08:35:00
+1,以前推過svn,但仍不敵寧願用壓縮檔+日期的死腦筋 XDDD沒權限想推廣也推不起來啊
作者: obamina48   2014-05-20 15:59:00
推 好文

Links booklink

Contact Us: admin [ a t ] ucptt.com