我
有的时候会被人叫做“大神”，和很多真正的“大神”不一样，我不会避讳这个词语，因为我知道我不是。
大学快要结束了，我承认我对自己的处境并不满意，因为我知道我现在拥有的和我想要的还并不相同。即将前往大不列颠日不落（我可耻的笑了，你不能理解我有多么重口的）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搜索要去抢百度的地盘。没有人会给你一条康庄大道让你就这么顺顺利利地进来。整个过程充满了阻碍。举个例子：一亩三分地是我最最在意的一个社群，它精华、用户融入度高、内容价值充沛、信息噪声很小、专业比较集中等等，我一早就像好了如何在这个平台上进行推广，但是无论是运营账号、诚恳地宣传（其实不是很诚恳，其他人都说我太假了，好吧，我确实不擅长这个。。。）、私信。结果就是所有的账号都被封了，包括自己之前自己在申请的时候用的账户。之后在寄托家园、太傻等平台都遇到了同样的阻碍。
运营就是一个产品的呼吸，你不做它就不能让一个产品的心脏跳动，不能让自己喘息，更不能让自己发展。我一开始对它只有重视，却没有尽心尽力，用户点击量很快就谷底。一部分是我们对于宣传比较缺乏经验，不知道怎么寻找自己的目标用户；另外一方面就是大家对于运营都没有放正态度。一个用了千百次的类比：一个平庸的产品（技术层面上讲）可以通过运营成为一个首屈一指的网站；但是一个再好地网站运营跟不上的话都会坠入深渊。
我们还在继续努力，这里只是希望做节过程中地一些经验。
