引述電影寒戰的台詞:
每一個機構，每一個部門每一個崗位都有自己的遊戲規則。不管是明是暗，第一步學會它
，不過好多人還沒有走到這一步就已經死了，知道為何？自以為是。
第二步，就是在這個遊戲裏面把線頭找出來，學會如何不去犯規，懂得如何線上球裏面玩
，這樣才能勉強保持性命。
結論: 你要在無論在軟體界或在其他環境生存，一定要學會明的或暗的規則。每個環境都
有它的遊戲規則，搞清楚規則再玩，才是明哲保身之道。
進公司沒多久，應該要把公司遊戲規則搞懂，有時候軟體會用這種管理方式是有它的歷史
因素存在的，也許一隻程式經手好幾十人，一段程式碼可能是因為專案評估錯誤造成要
加班努力趕出來；也有可能是相同模組賣給不同客戶但介面不同，功能需要客製化等因素
造成你現在看到的結果。你看到的是結果，就說這個管理不好，這個要改、架構要改...
老鳥大概會覺得這樣的新人是自以為是
所以進公司第一件事情就是把請把線頭找出來，學會在這一個遊戲規則下生存，在你可以
掌控的資源中來進行你覺得應該要做的事情
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)