可不可以不要改 Code ？

可不可以不要改Code？ 一位曾是苦主工程師的誠實經驗分享 - Wilson 翁豪箴-

程式員悲歌死了都要改 • 不要改得太快你改得越快他的想發也就變得快改到現在才發現他媽的都變態沒有奇跡我們相信往死裡改！死了都要改不理你身體好與壞三個通宵你就會死掉死得不明白死了都要改不改到飆尿不痛快改到停電沒鬼曬窮途末路都要改不說句髒話不痛快筆會損壞圖會掩埋計算機還在！到絕路都要改不日夜顛倒不痛快改到最後還得改！改到變態才精彩! • 把每天當成是交code的dead line一分一秒都改到淚水掉下來不理會客戶是看好或看壞只要你勇敢給我改哎......這條路沒法改沒感覺去對著電腦all day and all night享受現在別一說改就怕受傷害許多好圖我們相信全靠改出來！ • 死了都要改不推翻重來不痛快我們這行都是這樣個個都明白死了都要改不改到通宵不痛快宇宙毀滅甲方還在把每天當成是交code的dead line一分一秒都趕到淚水掉下來不理會最後是改好或改壞只要有時間你還得改

上班後，週五最常發生的事… 老闆或客戶的一句話產生重大轉折

WTF ?You Must Be Kidding Me! 必須整個系統或功能重新製作? 開玩笑吧？

也就是說…. 六日公司見.. 我們不見不散..

冏冏冏冏冏

發生了什麼事？ 問題點在於溝通不良

職場中的溝通 • 對內 vs對外 • 其他部門 ←→ IT部門 ←→ 委外單位 • Ex: 系統委外製作時，內部需求確認，外部需求說明 -> 需二次不同種類的溝通 • 一開始需求確認錯誤，最後沉沒成本將很可觀 • 對上 vs對下 • 部屬 ←→ 上司 ←→ 老闆複雜且微妙關系 • 對等單位溝通 • 如何協調資源分配 • 如何請求不同單位支援

需求確認錯誤，最後成本很可觀 • 前置作業：需求分析工作很重要 • 建議專案最一開始在Run時，就需要與各部門進行溝通與需求分析 • 溝通：80%在聽、理解，與感同深受；20%才在說 • Prototype:附上介面的雛形與Flow • wireframe工具：Visio, Axure RP , Pencil , etc. • 目的 • 並非所有相關人員均為軟體/程式開發專家 • 讓討論從虛擬想法變成具體

週五魔咒。這種情形，是否可能徹底解決？ 同學們覺得呢？

週五魔咒(大幅逆轉事件) • 無法徹底解決，只能盡量降低機率 • PM、SA責任重大 • 別讓底下的Programer、Art白忙一場 • 每次都要分析原因並檢討根源為何

分析原因並檢討根源 • 老闆沒空，客戶時間寶貴，請代理人參與討論 • 但決定權不在代理人 • 或代理人並未完全了解老闆想法(見樹不見森) • 問題也是在溝通出了問題

降低大逆轉發生機率 • 確認整個專案的”關鍵人物”

降低大逆轉發生機率 • 確認關鍵人物後，請求對方盡可能參予討論 • 某大頭 • 某資深員工 • 甚至是某祕書？ • 某小三？ • CC(副本或密件副本)的功用 • 什麼情況下該CC ?且CC給誰？CC什麼東西？ • Ex: 會議紀錄、確認時程、決定重要事項之文件等等

接著，我們談談二種工程師

主動與被動 • 主動工程師 • 在工作上僅須口頭交代就行 • 會動腦去想解決方法 • 遇到問題，會主動去尋求資源(人或物) • 被動工程師 • 需給他們詳細的規格文件或SOP • 只照著SA給的文件做，遇到不合理的地方不會主動提出 • 遇到阻力，只會陳述問題，不會主動去尋求資源

例: 會員註冊必備的電子郵件欄位 • 被動工程師 • 僅將網頁上欄位做出來，卻沒加入確認email格式是否正確 • User隨意輸入字串，都能通過 • 主動工程師 • 加入驗証機制 • 甚至去思考此驗証機制該做在前端(如javascript)，還是做在後端(如PHP) • 是否可模組化，輪子不要再造第二次

Q & A Thank you.

可不可以不要改 Code ？