其實現在有很多方法可以讓大家把軟體發展得更好
CMMI UML SOA之類(隨便舉例的)
有人會採用嗎?採用的方法真的對嗎
有的公司可能會對外宣稱"我有用XXX方法啊"
但對內可能就說做做樣子而已
你有想過 為什麼別人不好好採用這樣的方法呢
是那些公司高層都是笨蛋嗎?
還是實做上真的很難?
你想弄一些制度使公司運作得更好...很好
但我相信制度的改變 一定會產生一些衝擊
你的身分是?
你知道這新制度會對公司產生甚麼不良影響嗎
你有辦法讓公司願意承受這些不良影響嗎?
如果你是老闆 你說了算 沒問題
如果你不是 甚至地位很低 那就沒甚麼用了
假如你真的執意要做...那...加油吧
※ 引述《littlethe (東周小星星)》之銘言：
: 最近要幫公司想一些制度讓程式順利運作,
: 然後我就在想一些軟體業的不好風氣,
: 我希望可以在我公司不要發生,
: 我在過去公司最討厭的就是無薪無補休的加班,
: 很多還很無理的,
: 有的是老闆因為看到其他公司常加班,
: 所以就要員工「為加班而加班」,
: 也遇過「陪加班」的,
: 老鳥事情沒做完,就凹沒事的菜鳥陪他一起加班,
: 還硬說是為了心理平衡...
: 但更多是因為程式改來改去,造成的加班,
: 我希望這種惡習能在我手中不要發生,
: 我想到兩個方法下手,
: 一個是從文件著手,
: 我真覺得一個公司好不好,
: 看文件就知道,
: 文件一開始就寫得很清楚,
: 事情就做得越順利,
: 文件一開始就偷懶,
: 寫得草率,
: 後面就會做得亂七八糟,
: 業界常見的做法是文件別人寫出來,
: 然後丟給程式,
: 但我認為這流程要改變,
: 因為非程式人員幾乎是不會寫系統文件的,
: 寫出來幾乎不能用,
: 所以我想說這文件部份就由程式人員自己寫,
: 寫完再和別人確認是否要這麼做,
: 寫得簡短無所謂,
: 只要寫得具體,
: 看得出功能就好,
: 這樣可以提升文件的水準,
: 由執行者寫,也可以確保文件寫的東西可以做得到,
: 第二個就是要檢查程式,
: 很多公司的老闆或主管會覺得過程「不重要」,
: 以為只看結果,就可以看得到結果,
: 我看到不管過程,不看程式碼的結果,
: 下場都蠻慘的,
: 所以我認為「惡魔藏在細節裡」,尤其程式碼這種東西,
: 一開始寫不好,後面就「連環炮」,
: 所以我希望可以嚴格的規定程式要怎麼寫,
: 因為真的很多人程式是亂寫的,
: 習慣很不好,
: 甚至寫10年程式的老鳥也會亂寫,
: 後面要debug時就很痛苦,
: 對於程式碼我真的不放心任由別人「自由的去寫」,
: 我是希望這兩件事,可以讓我們公司的程式寫出來是很順利很有品質的,
: 這樣就可以減少加班的機會,
: 甚至根本不用加班,
: 也能順利讓案子準時做完,
: 不知道大家對我這樣的想法有沒有指教的,
: 或是有沒有其他制度上的建議可以讓我參考一下呢?
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 125.232.141.173