同人在兩性戰國論壇的職場點滴的討論中，看到梅子回應淡紫的文字中，提到爭取加薪的問題，她提到： 如果妳是想要趁年輕多賺點錢，那就要勇於爭取自己的價碼，不要讓自己成為廉價勞工～ 這段文字讓我覺得有些不對勁，剛進入社會工作的年輕人，常常會去計較自己的薪資酬勞是不是夠高，最好是能找到那種錢多事少的工作，然而他們卻常會忽略了一句名言，那就是「天下沒有白吃的午餐」。 記得上次和同事去參加朋友的喜宴，回程他告訴我有關我們公司其他同事的近況，他說那位同事找到更好的發展，薪水比現在公司高很多（我們所服務的公司，其薪資水準比業界要低很多），我聽了之後很替那位同事高興。不過，同行的同事卻說，那位同事覺得很不平，因為比他早一年進新公司工作的人，已經領了一年高薪的待遇，那位同事怨嘆，為什麼他不早一年跟其他同事進入那家公司呢。 聽了同事的故事之後，我告訴他，薪水的高低重點不在於公司的好壞，而是在於被雇用者能力的高低，如果我們能力夠，才有可能爭取到較好的薪資，所以年輕人不要急著抬高自己的價錢，而是要學習無可取代的能力，創造自己的價值，否則就會變成：年輕人很有本錢，可是不努力就不值錢了，而只有價錢了。而且，那位同事之所以可以找到好工作，他也不該忽略這一年來，在我們公司所磨鍊而來的能力呀。 同事對我的觀點表示認同。然而，我的觀點也可以用動態系統來思考
Julian 又對我在〈需求過程的溝通問題〉提出看法，他認為需求可以改變應該基於兩大前提，亦即： 客戶同意專案時程或是時程內的完成工作項目也要可以隨需求一起變動。 客戶同意專案費用也可以隨需求一起變動。 Julian 用了一些經驗來指出開發者對於允許需求變動會遭遇的困難，最後對於需求變動提出他的結論： 需求應該要可以變動，但是前提是客戶夠好可以負擔多出的時程和費用；如果不行，就要向客戶強調一個穩定的需求對專案能否順利完成的重要性，並盡可能的防止變動的發生。誰叫顧客永遠是對的，開發廠商永遠是被坳的哪一方。 同人認為 Julian 說的都是實情，開發者常會覺得很無奈，有很多事看起來是「形勢比人強」的問題，所以要讓專案順利進行下去，不得不採用權宜之計。但變動真的可以防止嗎？軟體專案的實情常會顯示著一個現象，你愈不讓客戶變更需求，客戶就愈會去變更需求。 為什麼會有這種結果呢？因為甲乙雙方的利益不相容，會讓雙方不斷地嘗試增加或減低資訊不對稱的現象，因而造成彼此相互鬥法的動態系統。但如果變更無法避免，那麼要客戶負擔因變更而多出來的成本及時程是可能的嗎？同人認為要視甲乙雙方所簽訂的合約類型而定，從 Julian 的回應看來，我想他所做的專案都是 fixed-price 或 lump-sum 合約而不是 T&M (time and material) 合約。 本來專案合約的類型就不是開發者可以決定的，而是軟體公司與客戶高層間的協議，然而如果開發者如果清楚合約類型的不同，與成本風險息息相關，或許就更可以不去抱持不必要的期望，也就不會有那麼多的抱怨了，至少抱怨的對象可以換一下。;^)
喲哪桑說： 優秀的工作者，不論是管理職，還是技術職，其工作時數都很長。 因為，這不只是工作時間的問題，而是工作態度的問題。 石頭成針對喲哪桑學長的這個觀點，認為不能把管理者工作認同和管理者工作績效混為一談，提到了： 一個無法讓下屬準時收工的管理者是抱著什麼心態在執行「管理工作」。是否只是為了滿足自己的權力與控制欲望？所以我說管理者要用下屬做 reflection ，透過下屬反觀自己是否「做好管理工作」。 當然，如果下屬也能從工作中得到認同，並願意延長工作時數也沒什麼不好。但那是下屬的事。管理者要學會把自己的感覺和下屬的感覺分開考量。 同人也為此主題，寫了一篇〈核心價值觀與工作態度〉，提出工作者可以選擇適合自己的工作環境，然後從工作中創造出個人的價值與意義，並不需要迎合對自己生命無意義的價值觀，消極地藉由超時工作才能讓經營者肯定我們的表現，因而為此付出青春而追悔莫及。 但同人的文章並非否定工作態度的意義，工作態度當然很重要，但一旦經營者或管理者把它當成批判工作者的工具時，它就不具任何意義了。用自己的核心價值觀來看待他人的世界，怎麼看都不對，經營者或管理者應該學會用更理性、更客觀的角度來看問題，才不會對工作者造成無謂的偏見。 我的文章得到哈米尼斯的迴響，他提道： 面對自己的人生（包含工作），我們應該秉持的態度問題，我們可以選擇工作=賣時間的觀念，但同時也可以選擇把工作當成是一種事業的態度來經營。這兩者所會產生的能量是很不同的，也如同您所提到的，超時工作是一種選擇，沒有對錯，但是如果我們可以透過這種行為進而拿到自己想要的東西，也許這種想法就會產生另外的價值也不一定。 這期的Career談到了Me世代、也談到了21世紀新人才的競爭力。 要發展什麼能力、要用何種態度面對，其實就像公司的核心價值一樣，是取決於「經營者」的。 當個人的角色重新定位成「一人公司」的時候，其實問題不也是一樣的嗎？ 當許多人在怨嘆環境不好、競爭規則的改變；也不妨想想你曾經建立過自己的核心價值嗎？ 哈米尼斯說的沒錯，成功要有決心、要付出代價，可是在努力之前，請先問一問自己，我們是否確認了目標、認清了方向，培養「以終為始」的習慣[1]。「努力會有結果，但不見得會有好結果」，如果沒有在努力前，先弄清楚方向，我們將會誤入歧途，白費工夫，就算我們的努力，可以得到再多卻不見得會有絲毫的意義，因為那將不是我們人生真正需要的東西。 同人一再強調，身處知識經濟時代，競爭力的來源並不在勞力與資源，而是資訊與知識。windlove 說的好：＂台灣陷在製造業的思維太久了，花個一段時間想出一個更有效率的方法，才是真的解決之道。不然，人一天在多也只有24小時，不是嗎??＂，所以，工作時間拉長或許表面上，在勞力與資源的運用上會很有效率，但卻會造成邊際效應遞減及心理層面因素而造成工作上的捨本逐末，因而降低效能。其實，還有一個更嚴重的問題，那就是一個忙碌的工作團隊，將會形成不利創新的企業文化，造成知識分享的障礙並且管理者會付出相當高的代理成本。 附註 參考史蒂芬．柯維著（2005），《與成功有約》中的第二個習慣。[↩]
喲哪桑提出了〈落後指標與領先指標〉，強調融合了領先指標與落後指標的重要性，帶給我一些對工作績效的後續想法。同時，正巧同人近日也經歷了一段有關超時工作的所見所聞，正好想藉這個同步事件來談談個人對工作上的一些體會，且聽我慢慢道來。
管理者的工作重點在促成資訊與知識的流動，讓員工貢獻他的智力而不是只消耗他的體力與勞力，那些屬於後者的管理者，其所管理員工不會成長，而且管理者會花費很多用來監督員工的代理成本，而且對於這一類的管理者而言，授權往往是不可能的任務。
當我們清楚專案管理者的態度對專案的重要性時，體會到肉眼不能看見事物的精髓，唯有用心才能分辨事物的價值後，我們才有可能在專案中不去輕忽專案管理的自然定律。此時，我們會了解專案管理其實不是只有分派任務而已。 所以，管理者不能只是以任務分工來看專案的進行，而是要去思考如何領導專案成員從不如預期的現況朝向管理者所期望較好的未來遠景接近，讓專案團隊成員的努力與目標的達成能夠有所關聯，使每一次的努力都能為成功有所貢獻，而不是無謂地浪費資源與時間。
喲哪桑提出軟體維護的 Rule of Thumb：「解鈴還須繫鈴人，解bug要找寫bug的人」。有網友對於這個看法發表評論，他認為喲哪桑的想法太不切實際，因為公司人員會來來去去，所以，公司營運不可能把相同一件事都一直由某個人處理。然而，喲哪桑學長說的卻真的是軟體開發的常見問題，很多軟體常常會找不到人來維護及修改，寫程式不難，但要看懂別人的程式然後知道如何去修改它卻不是一件容易的事呀。 但公司卻不能忽略現實因素，如果軟體開發者無法負起維護軟體的責任，那麼程式是否就註定無法修改與維護呢？那倒不見得，同人就曾經接手過一個專案，該專案是某省屬行庫的銀行行內整合服務系統因應銀行加值網（VAB）的上線，程式必須配合修改。 然而，困難的是該系統原設計者乃至於開發團隊早已離開公司，也沒有留下任何相關文件，我僅能從曾參與該系統討論過的同仁片斷印象拼湊出斷簡殘章中找線索，然後再追踪原始程式碼以重建此系統的設計知識，而且，我只有一個月的時間把程式改完，如果做不到，那麼公司將會失去此重要客戶。 有人告訴我，這個系統的設計方式是很有彈性的，但也因為這樣，在缺乏文件的情形下，沒有人看得懂高明的設計者的設計意圖，只好靠有經驗的開發者（就是才剛進公司不久的我啦）的幫忙了。結果「臨危受命，幸未辱命」，我成功地把此套系統承接下來，寫下說明文件並且陸續擴展其功能，使客戶對專案成果感到滿意也讓我得到績優員工的殊榮。 但當我離開那家公司時，我發現此系統仍然會有維護的問題，而其真正的原因其實是在於管理高層忽視知識管理的重要性，而不是系統難以維護修改。
當甲乙雙方的利害衝突是不相容的，資訊不對稱的現象不可能會被消除，雙方鬥法的結果，引發衝突是必然的結果，差別只在於是否浮上枱面。我認為石頭成對甲乙雙方資訊不對稱的看法，其實隱含著「資訊不對稱的現象因為利益衝突而造成不良影響」。
如果對話充滿了意見分歧、情緒反應，並且其風險很高，我們可稱之為「關鍵對話」。 要如何掌握關鍵對話呢？在《關鍵對話》第 39 ~ 40 頁有這麼一段話： 我們每一個人都會帶著自己對眼前主題的意見、感情、理論及經驗進行討論。「思想」與「感情」的結合，構成我們個人的語意庫。這個語意庫不但代表我們的中心思想，也驅策了我們的每一個行動。當我們有兩人或多人進入「關鍵對話」時，代表我們沒有共享語意庫，我們的意見是分歧的；我相信這個，而你相信那個；我有這一種經驗，而你有的是另一種經驗。 善於處理對話的人，會盡可能的讓每一個人都能將自己的語意加入共享的語意庫之中－即使乍看之下似乎與自己的信念有些衝突、錯誤或是奇怪。現在他們顯然無法同意每一個想法，他們只是盡力做到最好，來確保想法都能公開於所有人面前。 這一段話說明了共享語意庫對溝通的重要性。網路上的討論是一種溝通，雖然網路上的對話風險並不高，參與討論的人彼此並沒有特殊的關係，就算有意見分歧或充滿了情緒反應，造成參與討論當事人生活上的衝擊的可能性其實很低，所以網路上的討論並不能算是關鍵對話，但誠如喲哪桑學長的省思所言： 除了想想專案管理與軟體開發，我倒是從他們這案例在反省自己：如何有效溝通？ 所以，學長認為網路上的討論正可以當軟體專案開發過程中的溝通活教材。在軟體專案中要有效溝通，自然需要關鍵對話。而從前段引述可以了解，讓個人的語意可以在共享語意庫中自由流動是很重要的，但要怎麼做呢？或許學長對網路上討論雞同鴨講的有感而發可以為我們找到一個起點： 雖然事實理應是客觀且正確無誤的東西，仍要注意它是不是雙方都接受的事實，而不是單方面的認知；甚至廣義地來說，只要是雙方都接受，主觀的意見也可以是事實。 事實真能證明一切嗎？請將認知的力量牢記於心，認知的力量可是比事實還要大的。
在鳥毅與 R 君的對談中，R 君說： 很多事情用說的侀不如先做出來低調點等到其他系統出包時就把您做的拿出來這樣自然有人會相信您 這正是「如果你不滿意現況，試著改變它；但，別抱怨。」的最佳寫照。要追求進步，採用創新的軟體開發方法論或流程是必要的，然而在現實因素的威脅下，多數軟體開發團隊多半徧向選擇低成本開發策略而捨棄差異化開發策略，相信很多開發人員常聽到主管這麼說：「我也知道創新的作法很重要，但公司要能夠先獲利才行，等到公司獲利之後我們再來考慮這些創新的作法吧。」，主管的觀點似乎言之成理，主管的心智模式正如下圖藍色線條所示。然而，這是否就意味著當下改變軟體開發的現況是不切實際的呢？
最新迴響