Garbage In Garbage Out

        前幾天一位前同事到家裡做客，邊玩邊聊，談到他最近在工作遇到的挫折。         這位前同事跟我一樣都離開前公司後，帶著一些理想加入了新創公司。先前我一直鼓吹他要積極爭取新公司新團隊內 Team Lead 的角色，但 自認淡薄名利、不想爭權奪利，只想好好做事的他，覺得誰當 Team Lead 都一樣，所以並沒有把我當時的建議當回事 。如今，在這個依然 沒有 Team Lead 的新創公司內，他遇到了團隊合作中 無法跨越的磨合障礙 。         這個新團隊的組成各有各的來源與背景，大家帶來的做事方式、文化、習慣與見解各不相同。而其中兩人洽巧是同氣連枝的夫妻檔，難以溝通和差異頗大的做事方式讓他配合起來苦不堪言。         對原本堅信透過實事求是、良好的溝通就能達成共識的他，我直白的說：「 我的經驗告訴我，溝通不是萬能。你們需要的，就是一個拍板定案的 Team Lead 。 」         「 但是公司 Manager 說：Team Lead 要等第一階段上線後，看誰的表現好，再決定由誰擔任。 」         真是大錯特錯！         已經陷入群龍無首局面這樣糟糕的團隊，管理階層還想把問題拖到上線後才處理？這樣的思維，代表管理層把 Team Lead 這個位置當作一個 promote 的獎勵手段。無功不受祿，對於才剛成立尚未有戰功的新團隊，用這樣的思維當然會找不到 Team Lead 的合適人選！ 這時間點該立即找到的人選，該是願意挺身而出為成敗負全責的人擔任 ！也只有願意替成敗負全責的人，才有拍板定案的權力！          這時候的 Team Lead ，未必他的薪水就該拿的比其他人多，單純只是承擔更多的責任和壓力，所以不必用 promote 的眼光看待這個職位 ，這需要事先跟其他團隊人員溝通清楚，避免破壞團隊合諧的誤會。   ...

        JD，Job Description ，是應徵招募職缺時重要的參考資訊、也是一個公司營運方向的重要體現。讓我們來看個我手上最近拿到的範例： 1.         BU Team Lead   a.        Product technical owner   b.        Provide technical support to project/incident   c.        Provide mentorship and guidance to fellow team members   d.        Assist to manage/review release process 2.         Technical Architect   a.        Review project/incident design by request   b.        Code review by request   c.        Establish the code standard 3.         Production Support   a.        Analyze sticky incident   b.        Support...

        前幾個月和同事在業外接下一個稍具規模的專案。承接這專案其實背負著相當高的風險，其一為此案所需要的各項專業技能我們是 完全付之闕如 ，能夠在什麼都不會的情況下接觸到這案件，完全是同事的人脈引薦所致。其二為對眼前這個合作夥伴的不熟悉，以及一些不信任因素。         當初會考慮冒此風險，原因之一是此案的極高的報酬，再來是因為上過 激勵課程 ，內心感覺要跳脫筐做冒險： 若要如何，全憑自己 。所以在工作規劃分配後，對於必須惡補的技術項目覺得有賭一賭的信心。         如果是之前的我，只敢做有把握、會做的事，當看到實力和目標有如此懸殊的差距，一定會直接拒絕。         當然，最終沒有成功完成此專案，但其實我一點都沒有難過的感受。因為這個挑戰的本來就是『 失敗是應該，成功才奇怪 』的任務，然而我從這個挑戰的過程看到自己的延展性和真正的弱點。若我承接的是個十拿九穩的案子，面對的可能就是『 成功是應該，失敗卻難過到想不開 』，而且什麼都沒學習與成長的結局。         所以接下案子後，我們當務之急就是如何將技術落差產生的風險降到最低，並且爭取最多的工作時間作為克服技術障礙的緩衝之用。         這次團隊組合的專精是在 Adobe Flash / .NET ( ASP.NET ) / MS-SQL，但客戶要的是 HTML + AJAX ( No Flash ) / Java ( JSP ) / PostgreSQL 。在最初幾次與客戶的會議討論，總算把其中一項置換為同事所宣稱熟悉的 PHP 。客戶的網站除了少部分的特色項目，大多是一般網站都該有的常見功能，而 PHP 是出了名的有很多免費既存套件可以快速架站，因此我研究幾套自由免費的 CMS ( 內容管理系統 ) ，挑選了 Joomla 做為整個專案的開發基底。         由於 Joomla 只支援 MySQL 和客戶需求不同，經過幾次強力說...

        相信大部分的人對於目前的工作、公司的文化，內心有很多的不滿與抱怨，我也是。         去年年底，我曾經因為對職位工作內容的失望，對人事糾葛內耗的無力，而跟公司請辭。被慰留時，我還 寫了一封信 給慰留我的高層主管。         當時認為自己在工作崗位上已經『 學不到我想學的東西 』、『 推動不了我想貢獻的改變 』，專業沒有成長，工作因為公司的氣氛而沒有成就感。那時的我，實在找不出自己想在公司內做什麼，只有 面對一堆『不想做』的事情 。         我很感激公司高層願意幫忙排除掉那些『不想做的項目』，但在當時那個階段，仍未找到『想去做的項目』。過去我一直認為當工作內找不到讓自己有企圖心的項目，就是該轉換環境尋求其他發展的時刻，所以在食之無味、棄之可惜的情況下，一邊騎驢找馬，探訪其它出路。         然而就在今年初一場課程的突破，我發現到： 一切與我有關 。         我們不妨回頭再想想，為何大部分的人都在抱怨自己的工作和公司呢？至少就我周圍接觸的人統計來，這個比例應該接近百分百（ SHIT，這是吸引力法則嗎？ ）。         我們可以推導出原因的真相，可能是因為： 世界上沒有百分百合意的工作： 也許我所嚮往的其他公司，裡面其實也有一堆抱怨不滿的員工伺機逃出，所以才會走到哪都遇到對工作不滿的人。 會抱怨不滿的人到哪裡都還是會繼續抱怨與不滿： 牛牽到北京還是牛，心態不正確的人到哪裡都是不對的。         根據第一點，既然世界上沒有百分百合意的工作，那換工作根本無法解決問題，只是從一個火坑跳到另一個火坑。 地獄反正有十八層，大家可以輪流玩看看，反正人生就是一票到底，不玩白不玩 ，但不論怎麼玩，終究無法解決問題。         根據第二點，問題出在自己，卻妄想用外在環境來改變現況，根本是緣木求魚， 換工...

        今天，收到客戶回傳的『專案取消同意書』，終結了我人生第一個失敗賠錢的專案。這個專案說來也創下我許多第一次經驗與嘗試，是值得回顧研究的特殊案例，也該好好想想原本是一個十拿九穩鈔票輕鬆入袋的專案，怎麼會搞到認賠收場這樣的結局？         話說這個專案來得有趣，是因為我大學時期寫的一支 Freeware 工具程式，客戶因為想根據這個工具程式做出功能強化的版本而找上門。對方剛開始提出的功能需求，讓我覺得這個案子除了賺錢外，對我來說似乎沒有更多的附加價值，學不到新東西，程式碼也可能沒有再利用的機會。         於是乎，一開始我就 強調軟體量身訂做的費用高昂，對他不划算， 採取比較高調的回應希望客戶知難而退。沒想到對方意志堅決不肯放棄，硬要我開出一個價碼。         既然價格策略失敗，面對這樣吸血的條款客戶仍高興地抬高脖子面著我，卻也開啟我另一個經驗學習的機會－專案轉包。         這個案子我估計的實際價值和我開出的價格有相當大的落差，工期也從只要一個月結束的東西，硬拉長到半年，轉包的利潤空間和時間上的緩衝俱在，加上專案本身技術層次不高，若轉包的下游出了問題，我不管是再次轉包他人或是自己跳下去完成，都在風險與獲利可以兼顧的範圍內。         最重要的，我可以試試水溫，有實際的轉包管理與溝通經驗，增加我擴大工作室團隊的機會，這個原本學不到東西的案子換個方向竟然也可以讓我學到更多轉包管理的議題。         怎麼看都覺得天時地利人和，是個機會。         然而，從找人就是一種挑戰。在 104 和 JCASE 與程式設技俱樂部刊登外包專案，雖然一開始不少人來詢問，但是真正誠心願意回覆的人太少，大多喜歡讓案主空等，真不懂這心態是怎麼回事？還有人請他回覆報價和時程後竟然沉默了快一個月後，突然來信說他已經開發了七八成了，問這案子還能不能給他接，...