前言
通常我寫書既筆記前, 我習慣GOOGLE 一下果本書既書評, 睇下人地會咩角度講果本書, 我自己認五認等等. 如果以搵到既書評數目黎作書本既熱門程度排名, 本書暫時係我睇過最冷門既書, 因為我只係搵到一個中文既書評. UMMMMMM, 咁呢個BLOG 應該係第二個….. HAHAHAHAHAH
廢話就講完, 都係開始做筆記啦….
呢類工具/生產類既書, 一般都會將書既內容歸類為幾個大方向. 晉身怪傑既歸類為
- 職涯手冊
- 見工有咩準備
- 見工有咩技巧
- 管理解構
- 管理人既技巧/心得既篇幅
- 你的日常工具組
- 我覺得呢個部份既命名文不對題
- 日常工具並五係講軟件開發設計上既工具, 而係講管理工作時間上用到既技巧
- 你的下一個事業
- 職涯手冊中內容既延申討論
我個人對職涯手冊入面講既野無乜共鳴, 可能我未有需要搵工住. 所以, 我先寫管理解構, 因為佢既內容我比較有共鳴.
管理解構
管理涵蓋既知識範圍廣而深, 作者對管理既睇法係管理身邊能接觸既一切, 當中包括下屬, 上司, 時間, 資源等等.
文化圖
作者管理篇章既第一個切入點就係想我地了解自己公司既文化圖. 文化圖並五係單指公司既組織架構圖, 文化圖當中包括公司種種不成文既規定, 職場文化等等無法用文字表達既概念. 作者亦都寫左幾個問題去比讀者思考了解一下佢文化圖概念:
- 組織最睇重既係乜?
- 誰人建立這套價值觀?
- 誰人在此體系下貢獻最高?
- 誰最了解點樣創造價值?
掌握呢類問題既答案, 有助打工仔回答以下一個對打工仔黎講非常重要既問題:
- 我應該做乜野以獲得升遷?
個人覺得呢套功利主義既諗法相當有意思. 正如, 考試目的就係追求分數. 最佳既答題方式, 當然係參考MARKING SCHEME, 咁樣自然事半功倍.
然後, 作者既另一句說話亦係非常有意思.
- 文化就係一種看不見但能將人連繫一齊既概念
我覺得公司文化既另一個演繹方式就係公司既使命感. 係一間有強烈使命感既公司, 我地都可以由在其佢地既職工或多或少咁體現得到. 例如, GOOGLE 既DON’T BE EVIL 格言, 亦有一則新聞體現出GOOGLE 既員工對呢個使命既堅持
文化圖既總結如下
- 掌握公司文化圖
- 掌握公司內部既不明文價值觀
- 調整工作既力度與方向, 以最大化升遷既機會
向上管理
第二樣作者講既管理就係向上管理, 即管理你的老闆. 呢個係一個大學問. 作者好聰明咁將討論聚焦係”如何決定問題是否上報老闆?” 這個問題上. 以下為作者自己決定上報與否會經過既思考清單
- 這是你的問題嗎?
- 解決責任以外既問題, 成功就係英雄, 失敗就被埋怨
- 我能處理好嗎?
- 所謂”能處理好”指能在沒有管理干預下把它處理好
- 這問題有多大?
- 如果是所謂大事, 即使自己能處理, 也應該馬上上報
- 這個問題與你經理旳某個興趣有關?
- 如果你知道你老闆會關心這個話題, 在情在理你也應該馬上通知他
- 獨立完成有什麼好處?
- 聲望….
- 自己搞砸了有什麼壞處?
- 個人信用度破產?
- 你會成長嗎?
- 這個問題是多餘的, 凡係落手落腳做既野總會令你有成長
另外, 作者另一句有意思既句子:
- 不要把問題丟給我, 給我解決方案
以上司既角度代入呢句說話, 我個人非常認同.
危機處理
雖然原文既標題就叫直覺反應, 不過我覺得呢個標題與內文關係比較簡接. 由於閱畢整章後, 我覺得作者想點出的是: 我們應該要了解公司同儕對危機剛出現時既第一反應. 我將呢個SECTION 改做危機處理
在危機出現時, 作者列出會在會議枱出現既人既類形
- 不博士
呢類形既人唯一既反應就係挑釁味濃厚既不. 應對方法為讓佢地多說話, 並讓佢地與其他人多交流.
這樣做有幾個好處. 討論既期間, 佢地有時間讓頭腦冷靜下來, 然後思考事情既最佳對策. 同時, 亦有一個宣洩既平台等佢地表達自己.
- 蠻牛
呢類形既人係一種有性格既不博士. 與不博士既類形比較, 佢地既目的係為吵而吵直至心理上得到滿足. 這類形既人係最危險. 應對方法, 如果手上沒有辦法制止爭吵的話, 最好馬上把會議結束, 擇日再開. 同埋要求呢類形既人坐底慢慢思考, 緩和佢地對團隊既負面影響.
- 心如止水
呢類形既人係會議室中保持沉默並在整個過程中都保持冷靜.
- 抽絲剝繭
呢類形既人會不斷透過提出問題直至佢地對問題有一個透徹既理解.
- 處理者
- 我的錯
- 命中註定
- 我不幹了
餘下既幾種都係程度不一既逃避反應. 最好既應對方法為塞其他工作比呢類形既人以分散他們既注意力.
綜合黎講, 不管係邊類形既人, 最萬用既解決方式係透過不斷既對話, 讓大家交換想法, 最後先能得出對危機處理有建設性既解決方案
日常工具組
呢到既日常工具, 並五係工程時平時工作上既日常工具. 作者講既日常工具係講緊工程業職業技能以外既技能, 例如: 人際溝通, 時間管理上用到既工具.
會議中既勢力分佈
原文既標題係位元, 功能與真相, 同上段既危機處理一樣, 我換了一個我覺得比較易理解既標題.
作者講既會議分成三個勢力, 位元, 功能及真相. 用返平時見開既名詞去表達既話就係講品質, 功能及時間. 正如漁與熊掌兩者不能兼得既概念, 這三者構成一個三角形, 說明軟件開發中既取捨問題: 三個項目中只能兼顧兩項並犠牲餘下的一項.
我嘗試列舉出會議中各勢力下既代表者:
- 品質:
QA部門. 成熟既軟件開發流程必需包含完善既QA以為正式推出既軟體作守尾門既功效. 這個部門就是為了軟件既品質而存在, 所以自然會是品質勢力既代表者.
- 功能:
SALES 部門. 除了CS外, SALES部門便是接觸客戶最多既一個部門. 以我自己個人既經驗, 只要交易額夠大, 我未聽過有SALES說事情是辦不到的. SALES部門可以說是一個對外簽支票既部門, 只要金額夠大, 客戶要求什麼也會說OKOK. 然後, 為了避免自己開出空頭支票, 就在內部會議上聲嘶力竭咁逼令開發部門將相關簽下既功能優先推出
- 時間:
最後一方既代表當然係產品經理同其後既工程師團隊啦. 如果SALES部門是一個簽支票既部門, 工程師團隊就係附負兌現支票既部門. 如果有無限期既時間, 工程師團隊的確能兌現任何荒誕既支票. 不過, 正如上一個筆記中 JOEL 既講法, 在商而商, 軟件推出總是有期限, 並且越快越好. 做不到的話, 大家就可以集體被辭職, 因為公司都不存在了. 所以, 工程師團隊既立場就係如何在有限既時間滿足最多SALES部門既要求.
有了三個勢力背後所代表事情既概念後, 作者以位元, 功能及真相將同樣既概念重新包裝.
作者既定義 | 一般三角形 |
---|---|
位元 | 時間 + 品質 |
真相 | 時間 + 品質 |
功能 | 功能 |
為什麼位元跟真相都是時間+品質既組合? 這是因為作者把時間和品質背後各自既細節打散再重新定義起來. 詳情可以睇返作者既演繹, 這裏就不再多談, 因為我想紀錄既重點不在這裏. 不過, 作者呢個新包裝表達力比舊有的包裝更好, 更能夠表達每個勢力所關心既項目. 接下來, 我都會用返作者定義既名詞.
會議上勢力平衡既重要性才是我想紀錄重點. 作者既建議係每個勢力最好各由一人獨立出任, 並且各自間既地位要不相伯仲, 這樣會議出來既結果才是最公正的.
以我有限既個人見解, 會議跟政治一樣, 都係一門協商, 分配資源既藝術. 在緊有既資源下, 各方勢力互有攻守, 各自最大化自己既利益.
SALES: 我要增加功能X, 但不能調整現有既時程
QA: 現在既功能品質與時程還算充裕, 如果額外新增X的話, QA方面應該還可以應付需要
工程師團隊: 現有既時程必定做不完功能X. 如果我們可以把還未做又無人用既功能Y刪掉, 我們方有機會按時完成
SALES: OK
QA: 這面也OK
QA: 現在既功能品質與時程還算充裕, 如果額外新增X的話, QA方面應該還可以應付需要
工程師團隊: 現有既時程必定做不完功能X. 如果我們可以把還未做又無人用既功能Y刪掉, 我們方有機會按時完成
SALES: OK
QA: 這面也OK
雖然上述例子比較烏托邦, 不過亦足以演繹各勢力間協商既流程. 由平衡既會議勢力中產生既結果, 必然不會偏向任何一方, 因為各方都會在概有既框架下爭取最大既權益. 以公司既角度而言, 這亦是最理想既狀態, 因為沒有一個部門能夠主導公司既發展, 這樣公司既發展便更為紥實.
SALES不能胡亂開出空頭支票, 影響現有既產品既時間表, 或隨意犠牲產品既質素. QA便有足夠時間核實公司產品既質素, 提升公司產品既可靠性. 工程師團隊亦能夠把時間和資源集中於對公司有利既產品功能, 提升公司產品既競爭力.
不過, 如果勢力既平衡被打破, 例如由同一人擔任多於一個勢力既代表, 會議既結果自然被該人所主宰. 這並不是一件好事情. 如果由工程師團隊同時掌握了位元跟功能 兩個項目, 公司產品既功能未必就能符合客戶所需要的, 繼而導致公司產品既銷售數字下降. 以公司角度黎講, 這個明顯不是一個好做法
後記
本書仲有作者其他雜七八九的工作分享, 但寫既呢一刻除左上面幾個要點比較深刻同認同之外, 其他就不再詳寫. 或者, 未來某年某月某日翻睇本書既時候會有更大得著.
總括黎講, 本書除左一開始比較難於閱讀之外, 書既其他部份相當有趣及易理解. 本身從事軟件開發既朋友, 睇到書既某D部份應該同我一樣識得會心微笑.
就寫到呢到啦 :D
沒有留言:
發佈留言