一 、喬爾測試

1.你們用源代碼管理系統嗎？

git 神器

2.你們能一鍵編譯嗎？

這個要去研究一下

3.你們做每日編譯嗎？

這個要去研究一下

4.你們有bug數據庫嗎？

有

5.你們在寫新代碼前修改以前的代碼嗎？

在做開發規劃的時候，要預留修改以前代碼的時間，而不能只是考慮到不斷疊加新功能。

6.你們的進度表是最新的嗎？

每周的進度更新是必要的，這樣才能知道每月的計劃能否順利完成。我們有最新的每周進度。

7.你們有軟件規格書嗎？

就是我們的產品設計文檔。產品設計文檔，原型修改5遍，也好過代碼開發出來了再推到重來。
沒想清楚產品細節之前，不要開始開發！

8. 程序員的工作環境安靜嗎？

遠程工作者可以選擇自己的工作環境

9.你們使用了能買到的最好的工具嗎？

可以有

10.你們有測試人員嗎？

3.1以前都是產品經理同時負責測試，3.2以后要引入專業的測試人才，提升測試完整度。

11.你們面試時會要求應聘人員寫代碼嗎？

可以有。

12.你們做過走廊可用性測試嗎？

在做，且必須做。每次要提供不同版本讓用戶來比較體驗，并給出反饋。

感覺上，喬爾十多年前提到的這些，已經逐步成為開發團隊的標配。

二、軟件功能規格書

1. 為什么要寫：

• 提高研發效率：能夠在開始研發之前設計好軟件，在設計的時候就暴露所有可能的邏輯問題可用性問題從而調整，而不是在研發的時候，從而大幅度提高效率，降低研發損耗。
• 提高對合作伙伴的溝通效率： 便于設計，測試，運維，客服，運營等等合作伙伴來學習和了解軟件，而不用把所有內容都用一遍同時還要打擾程序員不斷追問，才知道這是什么，該怎么用，有什么效果。而合作伙伴會面向用戶，告訴用戶這個軟件該怎么用。
• 沒有規格書，就無法制定進度表。

2. 什么是規格書？
   • 概述： 這個軟件是做什么用的
   • 使用場景：產生需求的經典用戶場景是什么，軟件如何幫助用戶解決問題。

場景

書摘：
從你產品的使用者中，選取積累代表性的目標用戶群，為每一類虛構一個想象中的、但完全典型的用戶。場景越生動，逼真，你設計出的產品就越適合用戶使用。(http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html)

思考：
這于我而言是新穎的部分。以后可以考慮在產品文檔里面也加上場景說明部分。

有用戶場景的需求才應該被重視和開發。
如果一個需求僅僅是個人臆想出來，找不到現實場景，那么不應該投入開發計劃。

比如說嘗試給ping這個功能寫一下用戶場景：

開發者Jack經歷了3個月的緊張工作，總算如期交付了公司要求的新產品。接下來是測試，運營推廣的事情了。預計會有差不多2周到1個月的相對空閑的時間，于是他到了客棧上，想看看最近能不能接到一些不錯的兼職。
他會嘗試去聯系客棧的客服，標明自己現在比較有空，想要接單。
同時，由于團隊是按周來規劃任務的，他對于一周后會不會有新的開發任務并不是特別有信心，因此他希望這個最好是本周內可以接到比較短期快速的小任務。
因此，他可以使用Ping這個功能。
點擊Ping, 他可以登上當天程序員列表的首頁，讓潛在的雇傭方有更多機會看到他；第二天他如果依然有空，可以繼續Ping;如果沒空了，可以不再操作，甚至點擊“接單”按鈕，切換到不接單狀態。
另外，Ping也會影響自動對接排序，他的排序馬上會靠前，而這個影響因子會在未來七天衰減，到第8天衰減為0.

Ping功能

• 非目標：本軟件本次不計劃做什么

這個我們目前也沒寫過。目前只寫了要做的內容，不做的內容不寫，放到待規劃不分區，留待以后規劃。

• 流程圖
• 每個頁面的功能規格說明（概述，細節）
• 本次不解決的問題：這些一般都是基于已經考慮到，但降低了優先級的問題。
• 多角度注解：技術注解，營銷注解等。

這個也很新鮮。目前我的產品文檔里面，只有產品注解。
技術注解，營銷注解都沒有做過。

7.如何招到靠譜的項目經理

• 不把程序員提拔為項目經理：優秀的項目經理需要具備的素質：文筆清晰，外交手腕，市場嗅覺，用戶視角，以及優秀的界面設計能力。和優秀程序員的能力發展路徑不一致。

從描述來看，這個其實是產品經理和項目經理職責的融合職位。不僅僅是目前我們理解的項目經理而已。

• 不要讓營銷人員做項目經理

不讓程序員聽命于項目經理：項目經理應該通過證明項目本身值得去做而贏得程序員的支持，而不是靠地位優勢，行政命令。

8.輕松掌握項目進度

• 只有最終寫代碼的人能夠預估需要多少時間
• 適當細分任務，保持合適的顆粒度（小時）：通常的規則，任務的顆粒度應該在2小時-16小時之間
• 如何提升項目預估精準度：只做開發人員的預估/實際開發時間對照表，斜率越小，誤差率越高。最好是斜率為1.把節假日，調試代碼的時間，集成的時間，緩沖的時間都考慮在里面
• 永遠不要讓開發經理壓縮程序員的時間
• 開發Excel5時，為了保證上線時間不得不把一些功能暫時延后到了以后版本。然而之后回顧，發現暫緩的那些功能在之后的幾個版本也都沒有精力去實現，被證明是看起來重要但實際上對核心流程沒有關鍵影響的功能。 所以，每次當時間和任務量沖突時，保證時間，刪繁就簡，反而能確保你一直專注于關鍵事務上。

三、bug

1. 修復bug這件事情，只有當收入大于付出的時候，才值得去做。
   三明治廠超頻小bug的故事，是讓機器帶著bug運轉3天，按照正常速度修復- 72個漢堡損失，還是加急現在修復但是機器要停機三天-4.5萬美金的損失？

2）大部分時候，bug還帶來隱形損失：公司和產品的名聲。因此，還是值得去修復的。

3）修復bug的步驟：

1-盡可能地收集bug相關的所有信息
2-衡量修改bug的成本和收益
3-算出修復所有bug的價值
4-不要斷章取義

4）忽略只出現一次的bug

四、干擾射擊

1）步兵戰中只要記住一條：干擾射擊。不斷一邊前進一邊射擊，開火迫使對手多筆，這樣他就不能向你射擊；同時你不斷越來越靠近，來離敵人越近，就越能打中目標。

2)如果你不斷進取，不斷寫代碼改代碼，時間就會站在你這邊。
3）當競爭者朝你開火的時候要留神，他們是不是在干擾射擊，希望借此來降低你的速度？

所以，要關注的，永遠是用戶價值。不要被市場競爭或者媒體宣傳，資本要求等等迷亂了視線。
產品經理，要做的事情便是掌握人性，帶著善意去成就它。

4)對于我們這樣的小公司，干擾射擊意味著兩件事情：一是一定要抓緊時間，把開發的主動權掌握在自己手里；二是必須每天進步。這樣遲早會勝出。

五、針對開發者的非正式面試指南

1）簡歷上有語法錯誤的不接受
2）給候選人打電話，就某個編程問題聊上半小時 （想起培根的那句話，討論使人敏銳）
3）現場真人面試：6人中，5人應該是他未來的同事。6人中有2人不同意，那么就不該過。
4）在面試中要避免將那些可能適合的程序員招進來，只能招“程序員中的巨星”。

這個會成為技術為核心的團隊的要求，對于大部分企業而言，這個比較難。
軟件行業瞬息萬變，你需要的是有超強學習能力，什么開發任務都能勝任的人。

5）如何在面試中發現一個人是否聰明？你不需要向面試者重復解釋一件事情，溝通進行得十分順暢，候選者經常會妙語連珠，顯露出獨到的見解，深刻的思維或敏銳的直覺。面試官的作用是問開放式的問題，創造環境，讓被面試者能夠充分發揮。

問哪些問題：
1- 介紹
2-最近做過的項目
過程中，要關注：1.是否有激情；2.是否能將復雜的問題講得深入淺出；3.在團隊項目中努力尋找領導潛質
3-不可能問題 ：比如，紐約有多少調琴師，重點考思路。
4-編程問題 面試的大部分時間都應該花在這個環節
5-你對自己的表現滿意嗎
6-你有什么問題嗎？

不要問哪些問題：
1-違法
2-帶有歧視/偏見的問題
3-腦筋急轉彎問題

六、獎勵有害論
1-成員對于盡責，自我成就，價值認同等方面的需求，會被誤導量化為簡單的獎勵。
而物質獎勵，是最沒有忠誠度且邊際效應遞減的刺激。

七、揭開冰山之謎

1. 用戶界面只占開發工作的5%，而用戶能感受到的，只有這5%。

一定要平衡好 這5%和剩余95%的進度關系，讓用戶能看到的，和實際開發完成的進度匹配。

2. 把展示在用戶面前的部分做的漂亮非常重要。有了漂亮易用的界面部分，用戶才有可能來使用。

3. 做產品演示的時候，唯一起作用的就是產品截圖。一定要讓截圖100%完美，而不是讓用戶去想象產品。

4.掌控人們對于開發的預期：每周更新進度

八、吃自己做的狗糧

1. 作為用戶來使用自己的產品，找到不足，然后改變

九、凡是沒有看上去那么簡單，一定要先做好設計，再開始開發。

十、企業發展戰略：

1）小而美，還是靠資本快速推動壯大至市場領導地位？

1.小而美：競爭對手多，沒有網絡效應，較低的用戶粘度，用時間慢慢累積金錢，如本杰瑞
2.靠資本快速推動壯大至市場領導地位：競爭對手少，有網絡效應，強用戶粘度，用金錢換時間，如亞馬遜

互聯網企業的價值，和其用戶的平方成正比。

所以第2類型公司，時間是關鍵。盡早覆蓋盡量多用戶并黏住，才能獲得競爭優勢。

最不可取的發展模式，就是在兩者中搖擺。

2）先有雞還是先有蛋：提供某種向后兼容的模式，要不提供很多雞，要不提供很多蛋，先專注于做大一端，通過這一端來吸引另外一端。

3）轉化競爭對手的用戶成為自己的用戶：找到所有轉化障礙，并解決。

4）膨件和二八法則：

一般用戶只會使用到20%的功能，可是每個人的20%都是不一樣的。

5）開源軟件：從微觀經濟學的角度來看，開源軟件的發展并不是來自于企業的善心，而是降低配套產品成本，從而提升本身產品的銷售量。

比如：對旅游景點的機票降價，刺激更多人到旅游景點消費，促進了景區經濟增長。

6）微軟是如何輸掉API戰爭的：
雷蒙德。陳，舊聞新知博客（ https://blogs.msdn.microsoft.com/oldnewthing/),披露了很多微軟對于向后兼容（兼容更低級的版本，以及為這些版本操作系統所 開發的第三方軟件）而做出的努力。

而MSDN派推出的longhorn，以及之后的版本，因為喪失了這種信仰。導致用戶不愿意再來升級產品，開發者也漸漸不愿意再基于不斷變化的windows來開發。
?
網絡應用成為新的潮流，而不是windows 操作系統。網絡成為了新的API。

十一：問答
1）強大的競爭對手推出了和自己一樣的功能怎么辦？

答：不用管競爭對手，只用關心用戶的想法。

• 一定有用戶不知道競爭對手的
• 盡快上線，通過用戶的反饋來不斷修正提升自己的產品，讓用戶愿意買單。（實際上，用戶如果已經買了你的單，是不愿意再轉移到其他產品上去的。）
• 在產品上提供盡可能多的反饋途徑，讓用戶很容易能反饋意見。（比如，在每個地方都能看到反饋入口）

2）關注“我不用是因為你們不能xxx“的問題，而不是我希望你們能夠xxx。前者說明了使用障礙，后者可能只是一些與決策無關的想象。

3）預留緩沖時間時，需要考慮的幾種情況。

• 臨時想到的新需求
• 競爭對手帶來的新影響
• 把不同開發者的代碼集成起來
• 在測試中尋找并修復bug.
• 雇員必須履行的與開發無關的行動
• 由于時間預估不足而引起的緩沖
• 某些任務沒有提供預計的時間，所以需要緩沖