1.你有使用原始碼控制系統嗎？
如果你沒有原始碼控制系統（source control packages），一旦需要與程式設計人員合作就會相當麻煩了。因為程式設計人員無法知道其他人做了什麼，也無法輕易回復成出錯前的狀態。而且原始碼控制系統還有另個優點，就是原始碼會被簽出（check out）到每位程式設計人員的硬碟裡。
2.你能用一個步驟建出所有結果嗎？
從最新的原始碼快照開始，要花多少步驟才能建立出貨用的軟體？好的團隊會有單一腳本檔，只要執行這個腳本，就會從頭簽出所有檔案、編譯每一行程式、建立執行檔等。若這個程式不是只有一個步驟，就會容易出錯。另外，當出貨時程緊迫時，修正「最後一個」問題、製作最終執行檔等過程必須要快速完成。
3.你有進行每日編譯嗎？
要確保能立即修正編譯失敗的最佳方法，就是每天下午（如用餐時間）重新編譯。大家通常會在午餐前盡可能的提交檔案。導致編譯失敗的人，必須從此負責重新編譯的動作當作處罰，直到有其他人出錯為止。這能讓大家盡量避免造成編譯失敗。
4.你有問題資料庫嗎？
一個最簡單有用的問題資料庫必須包含每個問題的下列資料：
- 重現問題的完整步驟
- 應該看到的行為
- 實際看到的（有問題的）行為
- 被指派的負責人
- 是否已修正
5.你會先把問題都修好之後，才寫新的程式碼嗎？
應盡可能地追求「零錯誤」：無論何時都要先修正錯誤才能編寫新的程式碼。
6.你有一份最新的時程表嗎？
如此才能強迫自己決定要製作哪些功能，並剔除最不重要的功能，以避免功能過度膨脹。
7.你有寫規格嗎？
透過撰寫詳細的規格文件，可以節省溝通時間、做到最佳的設計，此外，你才能訂出時程。規格才是一切的根本。
8.程式設計人員有沒有安靜的工作環境？
9.你有沒有用市面上最好的工具？
10.你有沒有測試人員？
11.是否在面試時要求面試的對象試寫程式？
12.是否進行過走廊使用性（Hallway usability）測試？
是指在走廊攔住下一位經過的人，逼他試用你剛寫好的程式。若能攔下五個人並且試用完成，就可以發現程式中95%應注意的使用性問題。
二.無痛功能規格
1.功能規格（Functional Specifications）：純粹由使用者的角度來描述產品如何運作。它不管東西是如何做出來的。功能規格會述及功能，還會詳述畫面、功能表、對話框等。
2.技術規格（Technical Specifications）：描述程式內部的實作。它會說明資料結構、關聯式資料庫模型、程式語言及工具的選用、演算法等。
3.當你從頭開始設計一個產品時，最重要的就是確定使用者的體驗。要顯示什麼樣的畫面，運作的邏輯為何，要達成何種功能。再來，才是考慮該如何達成。
4.規格應加入的項目：
（1）一段聲明：如「據我所知，這份規格已經夠完整了，若還有遺漏之處，請告訴我」。
（2）一位作者：規格應由一個人負責撰寫，而非整個團隊。當產品規模很大時，就切割成幾區，讓不同人寫各區的規格。
（3）情境：當你在設計產品時，一定要想出某些實際存在的狀況以及人們使用的方法。替你的產品選好客戶族群，針對每種客戶想像一個完全虛構、又完全典型的使用者，並且用很典型的方式使用產品。
（4）非目標：當你想要刪除功能時，就得利用「非目標」的章節，列出你們不打算做的東西。
5.產品經理是在蒐集需求、定義程式應有的作用並且撰寫規格。此外，他們也必須負責協調行銷、文件撰寫、測試、地區化、外交手腕、對市場的敏銳度、撰寫良好的UI設計等。
6.雇用產品經理應避免的三件事：
（1）不要把程式設計人員升為產品經理：優秀產品經理所需的技能，幾乎都不是優秀程式設計人員所必備的。
7.騙人讀規格的五個簡易規則：
（1）要有趣：範例是個表達趣味的好地方。在不需要的地方詳述細節，也能很容易讓你的文章變得更有趣。
三.無痛軟體時程
1.訂出確實無誤的軟體時程方法：
（1）使用Excel。
2.必須知道的Excel二三事：
（1）共用活頁簿：利用共用活頁簿命令，可以讓大家同時開啟並編輯檔案。尤其是整個團隊會持續更新時程。
四.每日編譯是你的好朋友
1.每日編譯腳本必須包含負責建立所有的編譯結果。由取得原始碼開始，到把結果放到網站上適當位置供人下載（開發過程中，理應有一個測試伺服器），所有過程全都包含在內。
2.只有從頭開始取出完整的程式碼，再經由每日編譯腳本製作出的程式才可以發行。
3.把你的編譯器的警告等級開到最高，即使遇到最小的警告都要停止編譯。
4.若每日編譯失敗，就要冒險停止整個團體的作業。全部動作都停下來重新編譯，直到問題修正為止。
5.每日編譯腳本應該在遇到錯誤時，使用電子郵件把失敗狀況回報給整個開發團隊。腳本也要能把狀態報告附加到對團隊成員公開的HTML網頁上，如此才能讓大家快速得知哪個編譯結果是成功的。
6.破壞編譯的人必須開始負責照顧每日編譯，直到有其他成員破壞才換手。
7.午餐時間會是個進行編譯的好時間。如此一來，大家都在午餐前把最新的程式提交進版本管理系統，用餐時就進行編譯。用餐完畢後，若有編譯失敗，大家就會一同解決問題。只要編譯正常，就能取出最新的版本繼續作業。
五.絕不妥協的抓蟲行動
1.確定知道問題的狀況：
（1）把所有出現的問題全部抓下來，盡可能記錄最多的資訊，然後再把全部資料以電子郵件寄給開發團隊。
2.確定你會得到經濟上的回饋。
3.找出哪些問題值得全部修好。
六.紙上原型製作
1.只用鉛筆在紙上畫出使用者介面的原型，越潦草越好。畫好後拿給幾個人看，詢問他們會如何完成某件事情。當他們說出動作時，就能立即把東西搬來搬去。
七.面試人員教戰守則
1.放棄錯誤過多的履歷。
2.找些有識別作用的內容，如這個人曾經歷了某些很困難的選擇過程，並且也通過了。
3.電話面試時，談談某個特別的程式問題。
4.現場面試時，至少要經過六位面試官（其中至少五位是應徵者即將一起工作的同事），若其中有兩位否決，則不錄取。開始前不要預告會有多少場面試。此外，應參考資深人員的否決意見，而非資淺人員的意見。
5.不要同時面試很多人，每次面試應只有一位面試官和一位應徵者，而且在一間有白板且可以關門的房間內進行。
6.只要閃過一絲左右為難的念頭，就表示不錄用。否決一個好人選比接受一個壞人選的結果好的多。
7.檢驗應徵者是否聰明：不必一遍又一遍地重複解釋事情。通常應徵者會說出某些事，話中顯露出真正的洞察力、智力或敏銳度。因此，面試有個重要的過程，就是要創造出某種情境，讓對方能夠展示出他的見解。
8.聰明不是指「知道瑣碎問題的答案」。公司希望雇用有資質，而非具備特定技能的人。任何工作上應用的技能在數年後一定會被淘汰，所以最好雇用能學習任何新技術的人。
9.面試計畫：
（1）簡介：主要是讓應徵者放鬆，再用30秒左右的自我介紹，並說明面試進行的方式。此外，應向他們表示，你感興趣的是他們的解決方式，而非答案本身。
<1>尋找熱情：只有會激動地談論該主題的、有肢體動作的人，才是真正有熱情的。
10.面試前別聽召募人員的話，也不要詢問該人選的事，而且在做好決定前，不要與其它面試官討論，才不會有先入為主的觀念。
11.不應提違法的問題，以及腦筋急轉彎。
八.人的工作切換有害無益
1.絕對不要讓人同時做一件以上的事情。
九.揭露冰山的秘密
1.客戶不會知道他們要什麼，別再期望客戶知道他們要什麼。
2.你必須自己弄出一些東西並假設客戶也喜歡你做的東西，而且他們最多只是會有點驚訝而已。你得自己研究，找出一個設計能皆大歡喜地解決客戶的問題。
3.把使用者介面的畫面展示給非程式人員看時，若介面不好看，對方會認為你整個程式也是不好的。
4.客戶想要玩設計的話，就讓他們去碰一些無害的東西，如改變某些元件的擺設方式、改變外觀和字型、移動標誌位置等。
5.你在會議室裡用投影機所做的任何展示，都只是像素而已。如果可以，應該把未完成的使用者介面畫得就像是未完成。例如，在完成功能之前，對應的工具欄圖示就只用草圖即可。要是你在一開始就把畫面做得太過完美，等到之後真正做內部的功能時，他們反而認為這段期間內你什麼都沒做，因為他們看不到。
6.要確定你控制了大家對時程的想法。提供一份Excel格式的詳細時程，每週寄出談論本週進度的電子郵件 。不要讓專案是否正常進行的想法影響到真正的事實。
7.不要重寫程式碼，維護一份舊的程式碼比之後替新的程式抓蟲要好的多。
十.小員工也能做大事
1.去做就是了：有很多改善專案的事，只靠一個人就可以做到了，就算其他人不做，也可以靠你自己。
2.利用病毒性行銷的威力：一直向他們洗腦。
3.建立一個卓越圈：想辦法讓聰明的人支持你。
4.讓笨蛋無害：當有人設計出有問題的程式，不需要幫他們從頭改寫過，只要一直報告那個程式的問題即可，他們就不會在其他的地方造成傷害了。
5.遠離干擾環境。
6.提昇自己的價值：塑造在團隊中良好的印象，再慢慢改善流程。
十一.為非我發明症辯護
1.如果是核心的事業功能，不管是什麼都要自己來做，絕對不可外包。
十二.策略書
1.如果你要進入一個有網路效應和鎖定特性的產業，最好是新科技，一開始沒有競爭者，而且網路效應和客戶鎖定都很強的產業。
2.除非擁有好的軟體，否則不會有人買你的平台，然而你的平台要有很多用戶，才會有人替你寫軟體。要克服這種雞生蛋蛋生雞的問題，就是要提供一個向後相容模式。
3.別對潛在客戶施壓。如果某人還不是你的客戶，試圖鎖定他們並不是個好主意。
4.當商品價格下降時，互補物品的需求就會增加。通常公司的策略利益是讓互補商品的價格越低越好。理論上能維持住最低價格是「普及價格（commodity price）」，也就是會有很多競爭者提供相同商品時的價格。因此，聰明的公司會試圖讓產品的互補物普及化（commoditize）。
5.傾聽你的客戶，而非你的競爭對手。
沒有留言:
張貼留言