还是读书笔记，尽量不让自己每天读一堆东西但啥也记不住，好的东西精读并且思考，分析过程事一个锻炼思维能力的过程。把自己的思考形成文字则训练表达能力。
这两篇文章是Deep Develop的创始人写的，互联网公司或者程序员我都不熟悉，但作者文章里体现出来的思想很值得学习。
第一篇：从 300 到 300 万，一个远程外包团队的发展历程和经验
第二篇：从 300 万到 1000 万，DeepDevelop 外包业务第二阶段总结
在分析完自己所有的技能和优势后，发现唯一适合做的可能就是帮人做个网站了。
其实起点很低，创业碰到团购井喷，身上欠债几万，打算回到职场，寻找机会时，首先是“分析完自己所有的技能与优势”，然后找到适合自己的工作。所以对自己的情况进行评估非常重要。
带着如此的技术，用 Google 去搜索中文 “Wordpress 开发” “Wordpress 招聘”，很快找到了 Will（他之后也成了我们的同事）。我告诉他我可以做 Wordpress 开发，并且不收任何定金，开发完满意再付款。
就这样第一个项目来了，金额只有 300 元。对现在的我来说，可能只需要半天来完成。但当时自己看什么都一头雾水，更别说要亲自去写代码了。那几天自己几乎每天都在连续24小时工作，边 Google 边学习边练习边做任务，困了就在桌子上趴一会儿，因为我不能让对方发现我是个毫无经验的家伙。终于，在约定的时间交付了结果，并且对结果很满意。拿到300 块收入的时候，很困很累却高兴的怎么也睡不着。
技术不行时靠勤奋来弥补。几个关键点，不收定金——换取信任，突击学习，以免对方发现短板——利用信息不对称来补拙。
当时我的目标是每个月收入够 1500 元，这样就可以确保我的负债不再增加。
在享受欣喜的同时，给自己制定了新的目标：每个月存下 1W 元。如果月收入不够 1W，那就去想各种办法凑够并存起来；如果超过 1W，多出来的部分就去挥霍，尽情犒劳自己。这样 1 年以后自己就有 12W 可支配资金了。
给自己设立目标，那么为了实现目标，就有最初的动力。也有奖励机制，推动自己往前走。
利用搜索引擎继续在网上搜索类似的中文关键字，去寻找更多的项目。同时，将自己做过的每个项目都精心包装，作为案例。
这一步仍然是换取信任，用成果来告诉客户，他有能力完成对方的项目。
几个月后，作者的经验与能力都有提升，并且收入也大幅增加。这个变化来自于前期的策略，包括对自己与对业务的策略。
这里还讲了一些作者建立品牌的过程，最初靠案例集拉活，后来建立网站，取团队名，积累声誉，使获得信任的成本降低。
从哪里寻找潜在的同事
在这几年里，我们尝试过很多途径。主要包括：
1、主动发现优秀的博客、Github主页，然后主动联系作者（50%）
2、朋友及现有同事介绍（25%）
3、相关社区发招聘帖 （25%）
4、相关 QQ 群里发招聘信息（0%）
途径1其实相当于传统行业中的面试，简历就是优秀博客。这样找到的人至少能力是在平均水平上的。
哪些习惯是最被欣赏的
首先是可靠性。简单来说，你总能在规定的时间内完成任务列表里的事项，而不是经常有意外、推脱、找理由；你做出来的产品总是很可靠，而不是bug一堆。道理很简单，但事实证明能做到的人并不是大多数。
其次是自主解决问题的能力。我曾经形容我们的一个同事是推土机，又像是一个封装好的万能的类。无论什么任务丢给他，无论有什么困难，他总能不声不响的按时把结果摆在大家面前。而不是像有些人一样，一直把问题丢回来，“这里看不懂” 、“这里没用过”。
雇主需要的能力和你自己以为自己有的能力其实有分歧。所以求职时想的应该是雇主需要你在这个职位上拥有什么能力。注意这里对求职者的考察相当于终面环节了，已经经过了网申群面，确定求职者基本能力满足需求了。
这里未引用的一个实习生的例子，侧面说明了雇主找人时，也会考虑你如果加入团队，是否可以大家和睦共处。
接下来是拉活的分析，太长不引。简要概括，作者首先剔除国内的活和面对终端客户的活，都是因为要耗费大量时间但是未必能保证产出。而国外客户，则是和当地agency合作获得。这里之前整理的案例集再次发挥作用。你需要让客户或者中介知道你有能力完成项目——还是建立信任。在工作的选择上，作者思路是考虑效率与收入的均衡，尽量高效的获取收入，不无谓耗费时间精力。
我们向所有客户承诺，在项目交付前不收取任何费用；直到项目完成并满意之后再付全款。这个承诺一方面来自于对自己团队的自信，另一方面也相当于给还在犹豫的客户注入一针强心剂。
仍是信任问题，不再赘述。
可靠，做别人做不到的
可靠，道理很简单。但这几年与很多客户接触，与很多同行接触，与很多求职者接触，一路下来发现真正能做到可靠的人其实并不是很多。我们希望每个团队成员都做一个可靠的人，同时我们也努力的在客户面前塑造可靠的团队形象。对于承诺必须遵守，对于自己做出来的东西必须负责。
有人看到这些场景可能会嘲笑程序员要随时待命，最近在微博上我也经常看到大家发一些程序员在街边打开电脑解决问题的照片来调侃。实际上这不是工作的常态，一年里可能只会有三两次特殊情况，但就是因为可以处理好这少数的几次特殊情况，才会让自己与别人区别开来。
正是这些细节，以及处理紧急情况的能力，才会一次次巩固我们可靠的形象，才会成为我们的核心竞争力。才会让我们不需要销售人员，就能保持业务持续增长。
作者自己已经说得非常好了
帮助客户共同成长和发展
我们的客户都是 digital agencies 或者 design companies。在长期与每个客户接触的过程中，会发现他们每个公司都有很多长处。比如 A 公司的文档写的特别好，B 公司的流程特别合理。我们从他们身上学到了许多东西，用来改进我们自身的不足。在吸收到这些优点的同时，我们会将它们有针对性的重新分发回每个客户那里，以帮助每个客户提升自己，比如协助 A 公司改进他们的流程，指导 B 公司写出更好的文档。
当其中一个客户在某个方向取得不错的突破时，我们会马上反馈给其他客户，协助他们来发展这个方向的业务。比如几年前一家美国客户率先做起了响应式设计，我们马上将它推广到了其他客户那里，他们都取得了非常好的成绩。
这其中并不涉及竞争和秘密泄露的问题。一方面这些客户分布在不同的国家和城市，另一方面所有的信息都经过了我们整理和过滤。
这一点别的行业不能复制，但是仍然可以做到像他们这样替客户多想一步，给客户一些他们没想到能获得的服务。此外，这也是在展示自己的可靠，这样就形成了竞争优势。
每个新进入团队的同事，我都会跟他聊聊接下来 1 年、3 年的中长期规划。主要有两方面的原因：
1、我们是一个长久的团队，希望每个同事都能长久相处，而不是短期路过。如果个人规划与我们的发展路线不符，比如只是短暂的来工作2个月，之后有别的打算，那我们是不会接受的。
2、在团队发展的同时，我们希望每个成员都能收获自己想要的东西。了解每个人的规划，就能知道他想要什么，团队就可以根据他的需求进行一些针对性的调整。比如有人偏向于更高的收入，有人偏向于技术的积累，有人偏向于更自由。
对于老同事，我也会不定期与他们交流想法，因为现实不一定会完全按照计划来走，常常会发生变化。要及时捕捉到这些变化，及时调整对每个人的关注点，从而维持团队不断的凝聚和进步。
企业招人也是有成本的，招人以后的培训和磨合也是，所以招聘的时候都会聊短长期规划，像投行也会问你的职业规划，你想做的业务方向。一方面求职者的规划让企业放心，知道这个人会留下来，另一方面求职者的规划展现出的是此人对自己的了解，对公司的了解，了解越深，就能越好的建立信任。
————————
中间有个开除老员工的故事，这里作者还是比较仁慈，事不过三，第三次犯错后才开除的员工，但职场上有时候你犯了错就会被开，这种时候人情不管用。
用书面文档取代口头传授
我们有一个 wiki 知识库。里面包含团队介绍，团队协作及工作习惯，编码规范，测试规范，开发工具等内容。
知识库的内容使用 Markdown 编写，使用 Git 做版本管理，所有成员均可编辑。
在平时的工作中，我们会随时将新知识或者新工具补充更新到知识库中。当有新同事加入的时候，我们只需要将这个知识库展示给他，而不需要浪费人力和时间来培训。
不赘述，应该学习。
与客户之间的沟通
对于我们这样的团队来说，与客户的沟通重在两方面：
一是降低成本。 这里所谓的降低成本是降低沟通成本。降低沟通成本最有效的方式就是标准化，将沟通过程标准化。对于一个新项目来说，从第一次接触，到最终完工验收通过，总共有哪些环节要沟通，我们可以将其形成一个标准化的流程，客户只需要 "Config"。
二是明确需求。在达成协议并开工之前，务必要确保项目负责人已经完全明确每个细节的需求。我们在这方面吃过很多次亏。这个阶段的大意很可能意味着开发过程中要为自己的大意付出惨痛代价，而这部分代价必须自己买单，客户不会再多掏一分钱。一旦明确，需要尽可能将所有需求都以详细的书面形式呈现；以后客户如果要做任何修改，我们会将修改组织成新的版本，并对版本升级单独收费。
除了以上两点，还有三个细节：
一是需求文档。刚开始的时候，有的客户并不知道如何写出一份好用的需求文档，这会给后面的开发带来很大的麻烦。于是我们采取措施来解决这个问题，其中最简单的方法就是为他们提供优秀的文档做参考。这是件一劳永逸的事情，一旦每个客户都能够写出好用的文档了，沟通成本更是可以降到最低。
二是付款周期。现在我们几乎没有坏账的风险，也没有催款的烦恼。我们与每个客户都采取按月结算的方式，每个月底付清当月已完成项目的费用。
三是尽量用文字而不是语音。在没有特殊情况的时候，我们尽量用 Email 和 Basecamp 做所有沟通。这样做的主要目的是确保所有的沟通都有据可查。如果事后某方对自己此前的说法不承认，Gmail 的强大搜索功能立刻就能派上用场。其次，异步沟通也能提高效率，避免反复被打断。
同事间的沟通同事间的沟通最重要的是协调好异步沟通和实时聊天的关系。当我们一起探讨某个产品时，我们会在 Hipchat 的 某个 Room 里进行实时聊天。而在具体做某个项目的过程中，我们会尽量避免直接聊天，有什么问题都会通过 Basecamp 进行。
说得非常好，就学习。
看到很多人担心全职远程工作之后社交圈子是不是会突然变小，与人沟通的能力是不是会突然下降。根据我们这几年的经验，我想说，多虑了。
社交圈子的大小，与人沟通能力的高低，更多的应该取决于自身的性格。远程工作也只是份工作，它不可能占据 24 小时的时间；相反，它能给人提供更多的自由。在工作的时间内，可以结实很多志同道合的朋友，无论他是不是跟自己在同一个城市或者同一个国家；由于这些朋友的生活环境与自己可能有很大差异，反而能给自己带来更丰富的信息和灵感。在工作时间之外，可以自由的经营自己的生活和爱好，无论是否与自己工作相关的团体、组织、活动，都可以自由参与，而不用担心今天是否必须要上班，是否会被扣工资。
是的。
周围人的看法
总会有很多人不太理解这种工作方式，尤其是自己的父母。如果在工作的同时要面临周围人的压力和奇怪的目光，那实在难以舒坦，难以享受到远程工作带来的乐趣和自由。
目前来看，能有效缓解这个困局的途径有两条。一是确保自己过得好，不断成长，不断收获自己想要的东西，只有这样周围的人才能放心；二是推动“远程工作”这个概念走向大众，就像当年巨头们推动“团购”一样。
到 2014 年的时候，我们从 7，8 个人逐渐增加到 10 个人。这时候最大的危机感来自增长和发展。简单来说，如果上个月的收入是 20 万，这个月的收入还是 20 万，那这就意味着退步。团队里每个人都在不断成长，大家的技术水平在提高，做事习惯在改进，协作流程在完善，个人追求也在提升，但团队收入却没有增长或者增长的速度赶不上大家成长的速度，这种压力比解决个人生计的压力来的更大更猛烈。
危机意识。也有一个问题是如果公司不增长而员工能力增长，那么二者失衡后员工会离开这家公司，去更能匹配自己能力及给出薪酬的地方。
在原有的方向上下了一番功夫之后，局面并没有很大改观。从 2014 年开始每开拓一家新的客户都变的更加困难，毕竟我们大部分同事都在国内；如果在国外不设立办公室并做好运营的话，很难实现规模和价格的突破。同时，欧洲和澳洲的经济形势并不乐观，我们一直在努力协助推动现有客户的业务增长，但他们似乎无能为力，业务量很难有跳跃式的增长。
首先，必须看到瓶颈期，其次，当公司瓶颈期来临的时候应该怎么去改变？对个人来说也是这样。
中间省略了一段，是公司探索的过程。首先是借鉴成功公司的经验做类似产品，但结果不太理想，然后作者接了以前会拒绝的不那么流程化，而是有一定个性化的项目。结果很好，但过程中也是一步一步摸索的，并且，没有人能保证这就是未来公司增长的新方向。
就在第一阶段的总结文章发出来之后，一位很优秀的大学同学联系到我，希望一起来做一个服务于投资人和创业者的项目。她的为人、资源以及项目本身都对我有很大的说服力，我们在深圳一起吃了一顿饭就把事情定下了。
第一篇文章展现了公司价值和作者（管理者）本人的价值，所以得到了机会。其实大家最需要的还是能做事的人，像作者是通过他的文章、公司网站来展现能力，求职者也可以思考怎么让别人了解自己的能力。
合作的前提是能力，软硬件都是能力，能力带来信任，信任带来决策。
不止一次听说重要决策都是快速做出的了，如果说作者犹豫等待，那么可能三顿饭吃完也没定下来，他的同学就去找别人合作了，而他继续在瓶颈期发愁。
此时，我们的视角也随之发生了变化，不再盯着本月收入 5 万还是 50 万，而是尝试站在更高的层面去理解这个几百亿规模的市场。
我们决定调整定位，专注于为优秀的中小型公司以及初创项目服务。
做出这个决定之后，（我）并没有马上站出来宣布，因为还有两件重要的事情要先做好。
新方向的尝试证明可行，因此作者决定进行公司的战略调整。决定成立新公司是一顿饭定下来的，但前期只是试水，现在打算全面推进了，就要全面考虑，包括框架和细节。
第一件事是给现有的国外的这些客户一段缓冲期，协助他们找到新的合作伙伴并顺利交接，保证他们的业务不受影响。同时也再次跟他们说明，凡是我们做过的项目，将来有任何问题都我们都继续负责。
第二件事是重构团队。更专业的服务需要更专业的团队来支撑，我们的氛围和流程很好，但一部分同事的基础和成长速度不能满足新业务的需求。我们要有优秀的新鲜血液加入，同时要为原有的部分同事提供理想的归宿。
这两件事是我觉得非常专业的。对客户和对员工都做好安排，建立信任。公司和作者本人的reputation都会好。
首先需要下手的就是我自己：由于这两年我大部分精力都放在团队和业务方面而很少再写代码，现在我已经是整个团队里技术水平最差的人。我的技术缺陷已经无法为团队的飞跃式发展提供帮助。我们决定为每一个环节各引入一位技术精湛、经验丰富的核心成员，包括产品和视觉设计、Web 开发、App 开发、测试、运维。这几位核心成员负责各自环节的建设，他们也是持有公司股份的合伙人。
首先公司的管理者懂技术就可以，但不需要是技术最好的人。这里作者的经历是一个验证。管理者更应该做全局的长远的考虑。所以专业的事情交给专业的人来做。而内部晋升的好处是老员工更熟悉公司文化和工作流程，能保证品控。给股份则是激励机制。
其次需要更新的是一部分像我一样技术水平无法满足团队成长需求，或者技术栈不符合我们后续需求的同事。客观来说，他们的水平并不低，全中国的互联网公司都在被招人的难题困扰，尤其是成千上万的创业小公司，他们去找一份开发工作应该是很简单的。但我们希望可以给这部分同甘共苦一路走过来的同事一个更好的选择，于是将我们原有的国外的客户交到他们各自的手上，由他们去自立门户，努力经营下去。同时，希望他们继续留在 DeepDevelop 的圈子里，跟大家一起交流成长。
这一块有点像有的家族企业创始人传位时所做的业务分离和放权。但最根本原因还是作者对老员工的重视和真诚。对比ofo案例还是能看到管理者行为对公司发展的影响。
许多互联网公司在招聘的时候会写出一个长长的列表，可以给员工提供各种各样的福利，比如期权、大屏幕、零食、椅子、宠物、旅游。DeepDevelop 从招聘第一位新同事的时候就开始思考这个问题，我们想要的那些人才，他们到底想要什么。
对求职者或者free lancer来说也是一样的，想要的职位，他们到底想要什么，想要的项目，雇主到底想要什么，尽量站在对方的角度思考，给他们他们想要的和需要的东西。
自由和认同感
可观的收入，并且没有天花板
与优秀的人共事并成长
这是作者总结出来的远程人才需求，分析得也很详细，是结合行业特点，公司特点和程序员群体特点总结的，我自己进行分析的时候也要看这几个方面，行业、公司、recruiter，从业者特点。
我们每个星期都会收到几封邮件，除了个别毫无营养的之外，这些邮件都会得到认真的回复并希望引发更多探讨。其中一大部分是关于远程工作、外包行业、技术学习等方面的探讨。我们会将有价值的人才信息以及沟通记录整理到一个 Trello Board 上并合理分类。这个 Board 已经成为我们的人才库。当发展到某个阶段，对某一类人才有需求时，就会在这个 Board 里的某个位置上将潜在的同事找出来并与他取得联系。
两方面：1、信息收集——organized，方便日后使用，2、看似是回答别人疑问，但是作者把这件事转化为了团队自我提升的机会，同时进行了social，可能是social了未来员工也可能是social了潜在客户。有时候做事情不是立竿见影的，但是坚持做下去，总会厚积薄发。其实这家公司发展还是非常迅速的，但是公司同时也做了很多像这样扎实稳定，也许短期不见效的工作，这些工作都是未来的财富。
每个项目开始之前，我们并不会跟客户要需求文档这类的东西，而是希望跟他们进行一次长谈，由他们来讲讲这个项目的故事，团队的故事。我们的产品负责人和技术负责人都会参与到这次长谈中，确保大家都能深入的理解项目，甚至对项目和团队产生认同感。之后，才会由我们的产品负责人来梳理这个项目，协助客户一起将其形成一个合理的产品，然后继续推进到后续的环节。同时，我们会将产品背后的故事整理下来，确保后续参与进来的每个人都知道这个项目和团队的背景，可以从更深层次把握产品的特点和走向。
由于我们服务的项目大多数与互联网以外的行业结合的比较紧密，客户也多数来自其他行业，很多时候他们无法把握产品的发展步骤，经常发散思维。我们在协助梳理产品的过程中，为需求分级就成了一项重要的工作。每个阶段只开发当前一级的需求并逐步上线，由此帮助客户将时间和金钱成本降到最低，从而降低风险。
在产品和技术层面，我们在每个环节都会与客户进行专业化的探讨，甚至引入第三方的朋友一起参与，不把客户当傻瓜，也不把自己当权威。
团队做的事：1）品控和流程化、确保项目不会因为少掉了某个关键员工而停摆。2）将大任务分解为小任务，再逐项完成。对公司来说目标清晰可控，对客户来说也能看到具体的outcome。 3）了解客户的真正需求。
代码方面，每位开发的同事都会严格遵守我们的规范；每个人的代码确保至少经过一个人的审查。
品控。
每个项目我们都会以星期为单位制定开发计划和交付计划，通常每个项目的每个阶段会拆解分配到到 8 - 12 个星期里。每个星期一给客户交付上一星期的工作结果，探讨遇到的问题。通过这种方式确保客户随时知晓项目的进展和质量，而不至于 3 个月后突然冒出一句 “我们要延期了” 或者 “质量太差用不下去了”。
这种track方法也可以用在个人规划中。
部分客户在项目上线后并不能组建好自己的技术团队，我们会有一位负责运维的同事一直协助他们保证线上产品正常运转；同时开发团队会负责已有功能的维护，发现 bug 要立即响应并修复。
售后服务。
我们正在计划尝试建立一套评价体系，客户在每个节点给产品和服务作出评价，评价结果将关系到产品和技术团队成员的收入和晋升。
Peer Evaluation