我
有的時候會被人叫做“大神”，和很多真正的“大神”不一樣，我不會避諱這個詞語，因為我知道我不是。
大學快要結束了，我承認我對自己的處境並不滿意，因為我知道我現在擁有的和我想要的還並不相同。即將前往大不列顛日不落（我可恥的笑了，你不能理解我有多麼重口的）Cambridge去繼續自己的學業，我絕對不是說去這些知名大學讀書是一個壞選擇也不是會太在意自己只是去騙個學位滿足家裡對於這方面的要求。我為想要表達的是我心裡面的自己應該不是這個樣子。
一天洗澡地時候，我心想這個申請中如此蛋疼的過程，發現當下爆火的留學論壇真的滿足不了我，為什麼我不做一個自己想要的關於中國同學申請的網站呢？？？
於是，在我不停地忽悠之下，召集了我最信賴的朋友開始了這個專案：GradChef，中文名字是畢老師
Gradchef · 畢老師
GradChef.com這個產品本質上還是自我需求的一種延伸，團隊裡的人都是畢業沒多久，經歷過申請學校的人，我去了劍橋，而他們則是在那些最有名的投行裡過著高富帥的生活。不過結果如何，大家一致覺得申請的經歷是很痛苦的，刷GT對於亞洲人其實還好，麻煩的地方在於選校，PS，推薦信，面試的種種複雜。這些東西不是很簡單的量化的東西，而是一個持久戰，尤其是資訊不對稱，沒什麼可以參照的標準，而且中間過程繁複，每個學校都有不同的要求，申請一旦很多很容易就丟三落四，錯過deadline。
所以GradChef的就是為了解決我們自己申請遇到的痛點，現階段（第一階段）要解決的就是選校的問題。這個問題聽起來簡單，但其實很複雜。首先就是要對歷史資料進行一個標準化的建模，然後根據申請人的背景來匹配。但第一步建模就問題多多，量化的資料比較簡單，但是有時候非量化的資料更重要。歷史資料的來源雖然多，但是質量參差不齊，資料的噪音很大，又什麼好的降噪方法，只能“手工”降噪。
還想解決的一個問題，就是申請過程中的忙中出錯，所以Gradchef.com也加入了學校申請的管理，說白了就是一個為了申請特別定製的一個todo list，這樣既可以幫助大家追蹤和記錄申請的狀態，也可以讓大家在出結果之後，讓資料造福後人。
關於做產品的方向，我們的考量很簡單：做一個小而美的慢產品。我們不想迅速擴張，因為我們沒有精力去管理擴張帶來的問題；我們也不想做的很全面，因為我們無法對一個大而全的產品做出巨集觀的掌控；我們無法做的很快：因為資料的積累只能靠時間，使用者的積累我們希望靠口碑。
Part-time、大家都很忙、不在一個國家的一個團隊怎麼合作？
然後就來說說團隊吧：我們的團隊沒有全職人員，大家都是業餘時間一起做專案。白天大家都要上班上學，晚上和週末會抽出時間來做。而且大家分佈在五湖四海，跨越時區，是一支很鬆散的團隊。如何組織這樣的一個團隊是一個挑戰，下面有幾條我們自己摸索出來的經驗：
-
認識到自己的限制：很重要的一點就是認識到這樣的一個團隊是不可能同一個全職的團隊的生產力相比的，所以在把握進度的時候要掌握好，避免給任何一個分配太多的任務。同時，每個人的生活中都有其他更重要的事（工作，學習，健康，愛情，家人），所以允許每一個人選擇自己要投入的精力。比如有人要忙著準備考試，那就給他少分配或者不分配任務。
-
規律性的會面：這一點太重要，即使我們跨時區，也會每個周都要Google Hangout一次，大家先講講自己上個周做了什麼，然後提出上個周的問題，討論完後說說下個周自己能做什麼，想做什麼，要做什麼。這次會面我們會爭取每個人都參加，有人缺席之後會在單獨傳達會議的結論。這是一個鬆散團隊保證前進步伐的關鍵。
-
隨時隨地的交流：現在智慧手機這麼流行，想要隨時隨地交流非常容易：微信，Whatsapp等等。因為大家平時的時間都很碎片化，比如在走路的時候突然有一個好想法出現，那麼就會在微信群裡吼一聲，之後大家會pick up然後繼續討論，如果想法非常值得深入探討，會拿到每週的會議上討論，這樣可以在隨時隨地的交流，不放棄任何一個靈光一現。
-
簡單的組織形式：因為團隊本身很鬆散，所以組織形式也很簡單鬆散，平時的進度只是用Bitbucket的issue tracker，不會用更加複雜，更加程式化的工具。而issue也不會非常具體，通常只是很籠統的描述問題的領域，只要被分配的人理解就夠了。能這樣做的原因，是團隊中所有人對於用的技術都比較瞭解，大家都是很優秀的程式設計師，對於程式碼之美都有很一致的追求，減少程式化的組織，是建立在每個人的基本質素之上的。
至於技術上和交流上我們用到的工具：
-
框架：Ruby 2 + Rails 4 （本來寫的時候還是Ruby 1.9.3 + Rails 3.2，寫完之後就發現落伍了，根據Rails這種向後相容這麼差的framework來說，如果一步跟不上，就步步跟不上了，於是狠下心來升級了）
-
前端：部分頁面用到了AngularJS，部分頁面是jQuery，所有程式碼都是CoffeeScript。Stylesheet用的是Sass + Compass
-
伺服器：Puma + Nginx
-
Source Control + Issue Tracking + Wiki + File Sharing: Bitbucket (Git)
-
日常交流：微信群
-
視訊語音：Google Hangout (不得不說Hangout做的真心給力)
之前團隊試過Asana / Google Drive / Dropbox / Trello 等等各種工具，大家還是覺得這些工具有時候還是更多是累贅，而不會增強生產力，畢竟大家時間很短，希望把有限的時間都花在有意義的事情上。
教訓
整個過程是一個學習的過程，上面所講的關於團隊合作是我學到的第一課，下面來講講我們快要上線以及上線後學到的另外幾個東西：
-
Idea is nothing。在自己小範圍介紹這個產品給身邊的過程中，我知道了很多很多同類的產品，我一一去認真地試用它們，分析它們什麼地方做的好、以及為什麼沒有普及（如果已經家喻戶曉的話，我們應該多少有些瞭解）。而最重要的教訓就是，想法誰都有，而且很多時候別人的想法都比我的好，更重要的是如何呈現自己的想法，如何把它更好地放在自己的產品中。
-
自己的目標使用者所在的世界是有圍牆的。這就好比，你做了易信要去搶微信的使用者；你做了360搜尋要去搶百度的地盤。沒有人會給你一條康莊大道讓你就這麼順順利利地進來。整個過程充滿了阻礙。舉個例子：一畝三分地是我最最在意的一個社群，它精華、使用者融入度高、內容價值充沛、資訊噪聲很小、專業比較集中等等，我一早就像好了如何在這個平臺上進行推廣，但是無論是運營賬號、誠懇地宣傳（其實不是很誠懇，其他人都說我太假了，好吧，我確實不擅長這個。。。）、私信。結果就是所有的賬號都被封了，包括自己之前自己在申請的時候用的賬戶。之後在寄託家園、太傻等平臺都遇到了同樣的阻礙。
-
運營就是一個產品的呼吸，你不做它就不能讓一個產品的心臟跳動，不能讓自己喘息，更不能讓自己發展。我一開始對它只有重視，卻沒有盡心盡力，使用者點選量很快就谷底。一部分是我們對於宣傳比較缺乏經驗，不知道怎麼尋找自己的目標使用者；另外一方面就是大家對於運營都沒有放正態度。一個用了千百次的類比：一個平庸的產品（技術層面上講）可以通過運營成為一個首屈一指的網站；但是一個再好地網站運營跟不上的話都會墜入深淵。
我們還在繼續努力，這裡只是希望做節過程中地一些經驗。