記得進到這間公司沒多久，主管就問過我一些程式上的東西，當時我跟他們的建議是不要用那樣的方式寫程式，因為最終這程式是要在embedded system裡面執行，不能用寫桌上電腦的習慣，否則以後會有很多問題。想當然～～我的主管不鳥我。
最近問題一一出現了，前幾天主管叫我進去約談，他跟我說要我想辦法在不需要讓大家重寫的情況下解決問題，嗯～～這我整個給他傻眼。好吧，我想這也就算了，但事後主管約談我後也沒有後續動作，我總不能一個一個跑到同事旁邊問說『你有啥問題』吧。
工作多年後，其實真的發現並沒有遇到多少真的會當『研發主管』的主管，並不是說沒有厲害的主管，而是這些主管大多不會『當主管』，曾經有遇過寫程式很厲害的主管，不過這些人大多有一個毛病，完全缺乏溝通與表達能力，因此事情大多會變成一團亂，因為很多時候就算屬下想要幫忙也不知道如何下手。
另一種是完全的業務型研發主管，這類的主管根本不管開發的過程，就是每天追著工程師問『程式啥時可以寫好』，不過當你要跟他說明問題時，他卻連試著了解都懶。這樣的主管我也遇過，其實很多時候都會跟我處得很不愉快，因為對於這樣的主管我大多不會和顏悅色，而這些業務型主管卻特喜歡擺官架子～～ㄏㄏ。
當然還有工程師轉型主管，這類主管會寫程式，但在職場規劃的某一階段就決定要往管理階層爬，所以對於工程思維這些事情也只是有接觸但不深入。如果這一類主管並不負責實際程式的撰寫我覺得也無可厚非，但常常因為人手的不足這些人也會寫些程式，但～～～卻很難跟他們說他的程式有問題。
其實不管是那一類的主管，問題常常都發生在溝通協調上面，一個研發主管要控制研發的方向，所以對於一個專案初始的時候是很重要的，當然我的意思不是說他應該幫所有人決定研發方向，但～～他應該來做幫助大家了解相互開發思維與整體的互動關鍵。而事實上，常常可以看見的是主管通常只做所謂的『工作分派』，然後～～等著你把程式寫完。
這有點像是一個農夫把種子播下便等著收成，當然環境會有自然的滋潤，也或許會有些強健的種子會活的很好，不過這樣一來對於收成就必須有『隨緣』的心態～ㄏㄏ。資訊研發也一樣，很多的問題其實出現在ㄧ開始，而不是結束，但往往我們最不重視ㄧ開始的階段。
資訊產業～～一個我現在好想脫離的產業呀～～
No comments:
Post a Comment