/ 闭门造轮子 / 从远程工作到团队作战三年记

从远程工作到团队作战三年记

2020-01-31 posted in [闭门思考]

2017 年开始，最大的变化就是我把自己的远程工作转变成了团队作战的方式。通过之前在个人口碑上面的积累，接触到了更多的项目，同时也刚好有非常靠谱的伙伴，于是我们就决定继续向前一步，组建了现在的 ROGUE.GROUP 项目团队。再次回顾了自己上一次工作状态的总结文章《作为程序员从自由职业到远程工作三年记》，感触良多，磕磕绊绊到现在又是三年的小周期，是时候给自己和现在的团队一并再做一次总结，也算是一个微型外包团队的真实经验分享。

文章本来在去年末就开始整理，大致的内容也在 Yncoder 云南开发者社区 的年末聚会活动上简单分享了一些，但诸多事情只好趁过年稍微空闲一些才最终成文。另外由于比较长，没时间细读的可以直接拉到最后：太长不看版。

团队和技术栈

团队组建的时候，最初招募的是两个之前合作过的本地伙伴，前后端都能写，所以也算是全栈工程师。

除了开始固定的三个人（包括我），我们还有和兄弟团队共享的一部分资源，在遇到项目负载不均衡的情况下会互相借调。另外也有兼职的设计师和产品，只在有项目的时候一起合作。

从配置上来说在起步阶段算是够用且非常灵活了，因为在项目不稳定的情况下始终要注意风险，没有良好业务支撑的情况下绝对不要盲目扩张，毕竟外包这个行业基本是不可能有 VC 来投资的。

团队内部因为我们共同的语言都是 JavaScript，所以也就成为我们主要的开发语言，包括服务端也是使用 Node.js。虽然之前手头上有一些遗留的 PHP 项目，但尽早在团队内逐渐过渡并统一技术栈是非常必要的，而且最好强制执行，尤其对于小型团队。因为这不仅避免了争论哪个语言更好的问题，最重要的原因也是根据团队的技术储备和面向的项目场景。比如我们本身最熟悉的就是 JS，面向的项目场景大部分也都是 App 或微信类开发，在跨端能力上 JS 无可匹敌。通过一段时间（半年左右）的磨练，我们基本完成基础技术框架的知识储备，沉淀为现在使用的一些技术栈和基础架构：

技术选型上面大部分是经过验证的，少数有失误，但最终是可以通过我们本身的知识储备弥补或者在未来迁移的，所以也没有太大问题。我们也会在业余学习了解最前沿的技术，但用于生产最重要的就是：选熟悉的！x 3

经历的项目

作为一个团队，从零起步比当年个人开始做自由职业保守估计要难三到五倍，因为一个人吃饱全家不饿，但要形成一个健康的组织时，就不只是做原来自己做技术开发那很小一部分“份内”的事情。第一年一直处在一种兵荒马乱四处作战的状态，除开组织管理和技术开发本身的情况（后面介绍），这是因为大部分时候个人或者小团队接触到项目都很杂，为了营收平衡什么项目都会接。

后来从 2018 年开始，团队稍微稳定一些，我也觉得太过杂乱的项目不是一件好事，所以着手开始记录每次接触到的客户和项目基本情况，会跟踪到最后是否成单。虽然每次情况都不太相同，大部分也不一定能最终成单，但经过更多的数据积累以后，我们逐渐可以总结出项目的各方面特征和场景，以及什么样的项目更容易成单。可以分享一些大致的数据如下：

总体来说，我们的项目来源从当年仅依靠我自己前同事的圈子，逐渐扩展到了后面合作的其他客户，他们之间也会互相介绍，另外很大一部分新客户也是来源于各种社群和跨界的圈子。

但就团队的营收来说，我是非常惭愧的，因为比起老周当年《从 300 到 300 万》的成功经历实在差的太远，仅仅达到了勉强维持团队存活的水平。这种情况说实话在软件外包行业普遍 50%~100% 毛利的水平下，让我们非常窘迫。

行业和市场分析

第一年的时候情况还比较乐观，通过我个人的各种关系找上来的项目还挺多，当时感觉有一部分都是做不过来都介绍给别人或者在帮客户找其他方式的合作。到 2018 年新接触到成单的项目就少了一些，很大一部分还是靠其中一个大客户得以维持，也有一些小项目的收入但基本只能用来填补人力空闲。最惨的就是 2019 年，接触和成单新项目的数量都急剧下降，周围各行各业也都扩散出不景气的讯号，尤其是中美贸易战开始之后。最后剩下还有合作的项目，就只有教育培训行业的了，这点上看和我们接触项目的数据也基本吻合。

基于现状往未来大方向上去想，to C 市场是完全不用想的，to G（政府）市场又有资质类的要求，或者受限于多级分包渠道被动的位置，回款周期长等问题，小团队难以涉及或风险太高。对于外包最重要的 to B 市场，也将被越来越成熟的各类垂直和专业化的 SaaS 服务所替代，但还有一定空间。要么是在某个垂直行业深耕多年，积累了大量业务领域的经验，可以和合作伙伴一起共同成长，要么是营销能力比较强，可以把服务卖给更多的小商家，但这也要求研发的成本足够低，某些情况还可能造成烂价。

这么看下来每条路都不容易，然而更艰难的情况是我们从一开始并没有什么选择，因为最少也要保证团队先活下来这个现金流的底线。所以渠道成为了关键的因素，于是很多项目接触到以后，不管能与客户合作的靠谱程度有多高，我都会去尝试了解和基本的谈一下。

项目前期和商务

对于一直做开发的人来说，每家都跑只能说是最笨的商务能力练习方式，也在某些最终不能成单的项目上花费了很大的时间和精力。比如其中一个高尔夫酒店的项目跑了四次高速去和客户团队开会，也提供了方案，但最后项目成不成根本不是我们能左右的。

从各种项目的接触情况分析下来，在商务方面我们的确缺乏一些技巧，但对于未成单的项目可能不是最重要的因素。在我们接触的项目里，不能成单有几大原因：

  1. 客户方没想清楚到底要做什么，通过简单的方案引导也无法给出结论或者就放弃了的（比如有时候一个微信群就能解决的业务问题）。
  2. 客户方清楚要做什么，但有时不愿意把隐藏的想法告知我们，或者项目只是另有目的的掩盖（某事业单位）。
  3. 客户方清楚要做什么，我们也梳理出了方案，但由于对方决策流程太长和繁琐最终我们放弃（某些大型企业的相关项目）。
  4. 客户方清楚要做什么，梳理了方案给出以后就没有了下文（一些中小项目，感觉像就是来骗方案的，尤其一些还会有其他团队对比的信息）。
  5. 客户方清楚要做什么，也认同我们给出的方案，但预算和我们的报价无法匹配。

反过来能成单的条件就是：客户方清楚他们要做什么，或者在我们协助下可以梳理出他们认同的目标方案，最后也最重要的是他们的预算能覆盖我们的报价。

的确以外包为主要业务时，团队第一重要的是业务来源和成单。对于我们这样开发人员转型商务或市场的情况，因为缺乏主动获客的能力或渠道，那么最好的选择可能就是深耕某个行业或领域，在其中接触到的项目上都留下比较好的口碑。通过这种方式获得的客户一般来说会更加精准和专业，能得到相应的信任，合作起来也会比较顺畅。

但无论如何都要对团队进行一定程度包装，我们也只用最案例至少要梳理一套，不管是一份 PPT 还是一个网站。更进一步的对商务流程最好也进行梳理和规范化，包括接洽礼仪、咨询流程、方案和预算评估、以及合同法务等。这里并不是说每个客户都完全按照模板去死板的执行，但至少要有一个对照表，来明确什么情况可以裁剪哪些流程，这样也能避免在前期咨询阶段的遗漏。

项目执行和管理

大部分项目在签单以后，我们才回到自己更加专业的部分。如果项目是第一版，团队内部通常也是按照互联网公司的项目周期来迭代的：

  1. 首先由产品与客户明确细节性质的需求，出原型稿，与客户确认；
  2. 然后交由设计师细化成 UI 稿，与客户确认；
  3. 开发团队在同期会搭建基础框架，完成技术选型；
  4. 开发团队按照功能表和确认的 UI 进行开发并本地测试；
  5. 主要开发阶段完成后各项功能都集成到统一的测试环境测试；
  6. 测试环境测试完成后交由客户进行验收测试；
  7. 验收完成后根据客户的需求部署上线，确认功能正常后完成本轮迭代。

初版开发上线以后，根据客户的需求，针对升级和版本更新，我们会再走一遍从方案评估、商务谈判到开发测试的迭代流程。

对于项目制的外包合作这样的流程无可厚非，但如果跟客户形成了长期的合作，每一个新版本都重新进行商务谈判（其实就是讨价还价）的话，是个非常浪费精力的过程，最好的情况是之后的更新进行一定的人力评估，跟客户谈成长期迭代升级维护的合作模式，一方团队的现金流更加稳定，另一方面也节省很多沟通成本。

通常来讲，我们在方案输出的阶段就会按照 WBS 的方式给出一个工作量表，一方面明确每个项目（或版本）的工作范围和内容，尤其是经过细化之后所有人都会更加明确其中的风险，作为项目管理或商务也方便用这个表来汇总工作量评估或向客户报价。

正如下面的示例，在细化的功能点之后会有对应的角色需要加上完成该项工作的时间预估，通常是精确到半天（0.5）：

子系统 模块 功能点 细节 产品 设计 前端 后端
商户系统 通道管理 通道和应用的关联关系设置 应用间使用通道的互斥关系考虑 0 0 1 0.5

同时有这个表以后，开发阶段我们也会把对应每个功能点的任务加到看板里作为追踪，完成之后互相验证再改变状态，直到一个迭代周期结束。

我们有 70% 左右的项目会完整的按上面的标准方式执行，没有完全做到的原因是因为我们内部对项目有一个分级标准，通常分为 A / B / C 三个级别，完整执行的都是需要两人以上长期协作的 A 级项目，相对 B 级是指只需要一个人主要负责，另外有不到一个全人力偶尔协助的项目，C 级则是不需要一个完整人力的短期项目。通过这样的方式我们也减轻了一部分小项目上面的流程负担。当然能全部执行肯定是最好的，但当项目的预算或者重要度不够的情况下，比如有一次短期的一个可视化组件开发项目，只需要一个人负责，管理的粒度就可以稍微粗一些。

日常的项目推进里面，针对分级为 A 级项目我们也会执行每日的晨会，以互相沟通一天的计划、进展和遇到的问题，看是否需要其他成员协助。因为我们有时候也是远程协作的，所以不在办公室的情况下就通过微信语音完成沟通。这个环节是很重要的一步，对所有成员都是一个督促的作用，甚至包括我自己，尤其是在同时忙很多事情的时候，仍然需要抽出时间来关照每个进行中的项目。

很多项目执行下来以后，虽然有少数项目我们没法完全的按某种流程或规范来做，但我们依然觉得流程和规范是团队协作中必不可少的东西，不仅仅是用于管理的工具，更是方便所有人对齐认知的一种标准和依据，有了以后可以在做一些常规性事务的时候更“无脑”，减轻“管理”工作的压力，结果的偏差也会更小。同时这些内容在团队内部应该尽量的文档化，这块我们也在逐渐改进，后续也考虑可以开放出来，就像 LeanCloud 开放资源 那样。

协作工具

匹配每个流程环节我们使用了很多工具，下面我会一一介绍。

团队邮箱

我们使用邮件这个传统的方式作为内部账号管理的基础（所有成员账号都基于邮箱账号），同时也是和大部分客户正式沟通的载体，虽然更多的交流是在微信上完成的，但在一些标准化或者需要重视的场合下，比如发送合同或项目需求变更文档等，我们仍会发送和回复邮件作为正式沟通的存档。

域名邮箱服务我们使用的是 Yandex，最大的好处是免费，可以创建足够多的子账号和邮件组，以及足够的空间，而且也有专用的移动 App。在添加了邮件签名后，基本没发现被拒收或发送失败的情况。同时也用于一些线上监控服务的通知发送。国内厂商要么收费，要么限制比较多，对比起来 Yandex 目前使用下来总体感觉很好。

文档管理

这里主要指公司行政相关的正式文档和表格等，以及部分商务文档。我们使用的是 Google Docs，因为在线多人协作和格式支持都比较好，如果放本地每次改一个版本传来传去真的是苦不堪言，所以我们都以在线的为基准，导出下载的版本只用于传阅。

团队知识库部分我们另外在 git 服务器上建立了一个仓库来解决，用于存放项目执行过程的各类规范和技术相关文件，主要因为对习惯 markdown 格式的程序员来说写作和修改都很方便，而且版本管理也很自然。

项目协作

我们的项目大部分都放在 Teambition 上进行管理和协作。其中看板功能的使用是针对任务管理和协作最主要的场景。对应到之前说的项目执行流程中的各个任务事项，是比较好的一个方式。如果客户需要，也可以添加对应的人员一起参与。这个选型没有太多考虑，一开始用习惯了也就懒得换了，Trello / Tower 这些其实也大同小异。另外也可以考虑 Notion，目前看可能是最一体化解决所有这些问题的方案，用下来体验也不错，不过就是需要团队做一些相应的定制和规范设计。

另外有少量的项目我们也会直接用 git 仓库的 issues 解决，这种一般是和技术开发结合比较紧密的情况。

代码管理

最开始我们使用的是 Bitbucket，但是访问国外的速度实在太慢了。而国内 Coding 这类的平台总觉得用不惯（虽然速度飞快），最终我们在自己的内部服务器上搭建了一套 GitLab / GitLab Runner，基本上也就是一个 docker-compose.yml 配置文件就完成了。

自己搭建最大的好处是使用起来速度飞快，内部服务器 ping 日常都在个位数。另外就是 CI 服务器也没有了执行时间限制。但坏处也不是没有，因为这台服务器放在办公室内部，偶尔会有园区停电的事情发生，或者服务器其他故障需要我们自己解决。综合考虑以后也有可能迁移到 GitLab 官方平台上（速度还 ok），毕竟现在的项目导出导入就能完整的迁移，也是很方便的。

另外我们有一半左右的项目都上了 CI / CD，今后还会陆续提升，因为这的确极大的解放了每次要人工运维操作的生产力，同时避免出错。

产品和设计相关

我们兼职的产品大部分使用墨刀制作产品原型，因为是在线的，链接发出去就可以看，很方便和客户沟通并确认功能。所以基本已经放弃 Axure 之前使用客户端传文件的方式了。

合作的设计师使用 PSD 和 Sketch 的都有，但最近几年好像逐渐都转移到 Sketch 了。在合作过程中有时候我们更希望设计师针对对应项目出具一份设计规范，包含标明各类颜色尺寸的说明，这样其实可以在大部分情况下让前端完全不用打开专门的设计软件，而单单凭借一份类似文档的图片就可以完整的实现设计的效果。

财务软件

虽然不是主要的团队协作工具，不过这里还是可以提一下。市面上有大量的财务管理软件，比如用友等，但要么收费比较贵，要么只有在线 Saas 版。所以我们比较之后选择了 科目记 这家，一是免费，二是可以部署自己的数据库服务器。

用下来感觉功能还是非常完整的，包括账号权限，和各种记账模式，都符合会计行业的一般标准，我们的会计说有的地方比用友还方便或更细致。唯一不足是现在公开的版本都只支持 SQLite 或 SQLServer 数据库，我们一直用他们之前短暂公开过一个可以支持 MySQL 的版本，当时客服还是很积极解决我们提出的问题的，所以还是比较推荐这个软件，对于小公司来说应该是足够了。

组织管理

工具其实只解决一部分问题，尤其是那些事务本来就已经习惯于大部分开发人员的工作过程中了。

所以管理这个问题，正如开始说的，从个人单干转型到带团队，几乎是一个“硬着陆”的转型，也是很多其他从专业转管理的业内人士共同的问题。因为事情都堆在面前，即使之前只是个没任职过任何管理 title 的开发人员，既然走了这一步，也只能硬着头皮上。

这对于我个人来说，表现出来最大的烦恼就是：时间严重不够用！因为除了自己也要做一部分开发，还有方方面面的事情都只能由自己负责。从责任心的角度，我自认为对自己是有很大提升的，因为所有的事情只要任何环境有疏漏或者没做好，最终都会落到自己头上，完全是逼出来的，也真真切切感受到什么叫团队负责人的角色。但反思下来这其实也并不是一个好现象，用流行的话说就是在“用战术的勤奋来掩盖战略的懒惰”，因为团队管理核心的问题其实应该是尽早建立规则和制度，明确各人的角色，通过各司其职的合力来完成每一个目标。

然而现实的过程远没有直接说结论那么轻松。因为往往项目来了以后人员负载就上升的比较快，但受限于之前说的业务不稳定的风险，比如客户做了第一期根据市场情况也不一定都做第二期，还出现过客户团队自己内部出问题款项拖欠半年的情况。所以也不敢贸然扩大团队的固定规模，甚至有客户预算较少的时候连兼职人员都请不起，于是这些时期所有无法分配到其他成员身上的工作量就只有我自己一个人来扛，从项目前期了解、商务流程、需求分析都需要我来对接，有时候技术选型、架构设计和难点攻关也只能自己来做。有句话说的好，就是：“Leader 就是团队的天花板”，一方面在技术上要带领团队上升，另一方面也更需要维度上的突破。如果能招募或者培养出能接替自己一部分重要技术工作的伙伴，减轻了这块工作量的负担，会有更多精力去做获客来源和制度建设等其他的事情，这样也才能带领团队突破维度达到整体上升。

我们团队开始时人员并不多，两三条枪的水平下，还遭遇了一些业务方向上的问题。由于没有稳定的业务，所有方向都会有风险，只有一种客户的业务非常明确，就是他们已经有一部分自己的团队，只需要一部分我们的团队作为他们的人力外包来完成他们的工作。长期看下来，这种合作模式是我个人认为仅次于完全没饭吃之上最最糟糕的一种模式。因为这样不但人力被完整的占用掉了，关键是所负责的事情和自己团队整体是割裂的，无法共同成长。另外盈利空间也是非常低的，毕竟客户选择的重要原因也是因为看到我们人力成本和一线城市招人之间的利差。所以只要有更好的项目制的合作，我都不愿意让自己团队的成员变成单纯的“劳务派遣”。

除了“劳务派遣”的项目里，本身我个人也是倾向于大家可以更自由的尽量在家远程工作的，因为一方面也是自己的目标，但初期团队不成熟的情况下我没有冒这个风险，即使之前我基本都是处于远程的状态比较自由。也因为我自己经历过这种工作状态，深知其中的各种问题，尤其不是每个人都能在独处的情况下严格要求自己保持比较好的工作状态，所以还是老老实实的叫上大家一起按时去办公室“上班”，以更稳妥的方式解决各类日常问题并达到磨合团队的目的。

也是因为对开始不成熟的团队不放心，我一直是以一种大家长的方式在推动和运作。所有的决策我来做，所有的风险也是我一个人在承担。就分配的方式也是我按工资+一定比例项目奖金的方式来确定。这种方式在不同方面各有利弊，好处是省去了很多需要来回讨论决定的事情，对于初创团队我至今认为在某种程度上是必要的。但坏处也很明显，就是没能全部按照伙伴的方式看待大家，所以导致了我一会是大管家，一会是救火队员，一会又要当老师，自己还要一起搬砖砌墙这种分身乏术的窘境。因为没有真正可以作为合伙人的伙伴来一起分担风险或是共享成长的果实，所以没能看到本可能激发出来每个人更多的潜力。

在这个方面上我还是希望今后有所变化，因为其实我们的成员也都在成长，每个人承担责任和风险的能力都是在提升的，也许我们能从其他的地方参考也好，自己探索也好，总之能找到一种更优化的合作和分配制度，将会更有利于团队整体的成长。

后来真正向远程转变是从 2019 年开始，一方面当时我们认为团队的工作流程已经磨合 ok，技术方面也相对成熟，另一方面成员也经历了一些变化（通过社区招募了远程的同事），刚好在几个个新项目的时间节点上，我们全员启动了远程模式。也是因为团队都有一定的远程经验，以及工具和流程的辅助，重要的是现在的成员基本都比较靠谱，所以我们过渡的还算 ok，没有太大的问题。而且这个转变其实本身也是我们所期望的方向，只是在一个合适的时候刚好完成了而已。

其实所有的组织建设和制度的形成，除了专业性的方面，最终还是要回归到团队的文化，以及基本的愿景。就我们而言，最初就是要解决吃饱饭的问题，在这个前提下，如果能够用更灵活的方式解决吃饭这个问题，也能吃的营养丰富，就已经不错了。当然最大的向往并不只是吃，因为这还只是一个底层的需求，更长远的来讲，也需要精神方面的满足，就是做的工作也要有意义感。不过还在考虑吃饱的情况下，这点是很难实现的，所以我们只能先解决最紧迫的问题，抽一定空（比如现在）来思考未来的发展。

未来的发展方向

根据我个人的了解，90% 以上的小外包公司的远期目标都是不再做外包。外行听起来会觉得可笑，但是其中的味道内行一定有所体会。正如我曾经说“工作是为了自由”一样听起来矛盾却真实，对于大部分普通人来说这可能就是一个跳不过的过程。

外包这种形式会得以存在，就是因为看起来门槛不高，所以市场普遍的定价偏低，但又总有新人开始去做，导致竞争更加激烈。发展的好的团队，经过了原始积累，一旦有转型的机会，必然会放弃一个又一个不断重复接项目这种令人疲惫和没有成就感的过程，而去向更高层级迈进。而如果一直外包到后期没有发展起来，可能就只是拼渠道和拼体力的过程，本质上没有任何创新，在市场逐渐成熟的趋势下，机会只会越来越少。

大多数团队的转型方向，基本是沿着这样一条道路发展的：项目 > 解决方案（领域） > 产品 > 平台服务。这也是一个自然的过程，正如前面分析过的市场上可能有的机会。这条路线我们很大程度上会参考，不过适用于我们自身的话还有三个方向的分支会考虑。

一是技术本身的维度升级。我们已经接了很多外包项目，业务上基本的东西大同小异，抽象整合是必然的事情。规划合适的技术方案来解决我们很多重复开发的工作，将会是我们未来在技术方向上投入的一部分，这也将给团队成员带来相应的提升。这块我们已经有了一定的积累，甚至会向产品化发展，目标是以 serverless 环境和可配置化的应用生成来解决大部分 To C 客户的基本业务场景所需的 IT 服务。

第二是重新审视团队的结构，甚至是制度的升级。如前文提到的，我们会考虑合伙制，目前我们的生产关系并没能释放全部的生产力，这在短期看来讲还好，但如果希望长远的发展下去，且扩张规模的话，现有的组织形式有可能有一定程度的阻碍。

第三是业务的方向问题，这块很复杂，但也有了一些头绪。根据前面的判断，在保证吃饱的前提下，后面的项目我们会尽量找能和客户一起共同成长的那种，而且最好是长期的项目。这也很像把整个团队当做客户的技术部门的方式。额外的，我们也会探索一些小众兴趣和社区的领域，毕竟大的市场都已经被瓜分的差不多了，但这部分不会是主要投入。

三年以来我自己从未轻松过，自从走出了一个人只管写代码的舒适区，头顶就始终是顶着巨大的压力。但 2020 年开局已经变的更难，而且当前我们依然处在外包这项生意的初级阶段，毕竟很多事情就是真做了才知道，没那么容易就能走向成功。也很感谢曾经合作过的所有客户，和你们一同走到了现在。不过写到这里，应该可以作为对团队和自己的一次归档操作，复盘之前欠缺的东西，也思考未来我们要前进的方向。洗去一路摸爬滚打的尘土，留下更平和而坚定的心态，继续轻装上阵。

太长不看版

从前文里精炼了一些结论和一些零碎的感悟都集中在这个列表里：

  1. 低于 150w 预期年收入的业务不要开公司（经验公式：个人上班税前工资 x 3），这条是说给那些说“找个代理就能开公司，一年也就几千块的成本”的人。因为公司是为业务而生的，比如各种集团下面可能有多达几百家各种不同的公司，是因为有那么多业务要做，不是开着玩的。而且一旦开了公司，财务、税务等一定要尽可能的合规。
  2. 尽早制定各类规范、框架，撰写文档，不只是技术方面，还有团队管理和公司规章制度（但都要可执行）。
  3. 适合做外包的情况：市场早期供不应求；渠道占据信息差或关系极强，比如在大公司手握资源自己出来接原来的一块业务（很多运营商下属公司）。
  4. 以外包服务为主时，开了公司第一重要的是业务来源。作为老板必须是业务导向，要进行一定程度包装，发展各类关系以拓客。
  5. 客户筛选也很重要，通常微型团队尽量不要碰政府、国企和事业单位的项目，商业项目要考虑客户的背景，完全不懂的要尽量引导，让客户听（专业的）话，这也是一种服务能力。
  6. 还要衡量客户项目的靠谱程度以及兑付能力，通常能支付预付款的客户更加靠谱，而一旦出现拖欠针对新的投入就得非常谨慎。
  7. 客户合作方式、合同起草也需要尽早规范化，有范本有流程，节约每次接客时的思考时间。
  8. 一旦和客户形成了合作，一定要具有这个服务行业的服务意识，原则上预算内尽可能的解决客户的问题，预算外的也尽量给出解决方案。坑客户的钱不算赢，被客户拖垮也是输，共同成长的双赢才是真赢。
  9. 和客户的合作方式，第一次一般为单次项目制，但后期尽早视情况转化周期制，一方面更加稳定，一方面节省每次预算评估和商务谈判的沟通成本。
  10. 单纯人力外包是最差的模式，只比没事干要好。
  11. 一定要有产品（设计）方面的角色，最主要可以专业的帮助解决和客户沟通和分析需求的工作，避免瞎摸，否则负责人什么都干可能精力有限。
  12. 技术方面尽早统一团队内的技术栈，尤其是没多少人的时候不要在项目里用太多的技术栈，不稳定的情况下很容易找不到人负责。
  13. 善用各类工具，尤其技术上可以自动化减轻人工重复劳动的，程序员在专业上最核心的信条应该就是 Don’t Repeat Yourself。
  14. 如果有熟悉的领域内开源产品，尽早摸透使用，即使只是 Wordpress，重复为同类项目服务都将极大的降低成本。没有特别好的业务或者领先市场的创意千万不要自己重头研发，尤其是市面上已经有的产品。
  15. 承认在大部分小型商业外包项目或产品里，技术是不那么重要的一环。
  16. 行业形式分析：单干或小规模的路子可能越来越窄，各类主流需求市场上都有非常多的平台在满足，所以单纯被动式的外包服务今后的路会越来越窄，尽早做好积累待机转型。
  17. 转型的路径：项目 -> 解决方案（领域）-> 产品 -> 平台服务。

另外推荐也是这两天刚读到两个程序员界大 V 的文章，虽然不完全相关，但还是让我感触较深，而且他们总结的都比我好：

广告

首先感谢读到这里，其中一定还是有一些疏漏和未能言尽的东西，因为决定首转于 电鸭社区（一个国内主要交流远程工作的社区），所以可以在那边更深入的交流。

最后也算是个小广告，我们团队仍欢迎各类项目合作，如果有相关外包的需求，欢迎直接联系我们：[email protected]。

更新

2019-02-01

文章发到了耗子哥的技术群里，蹭着和群主老乡的关系，给出了几条 comments：

  1. 接外包是没有前途的。哪怕你有从项目 -> 方案 -> 产品 -> 平台这样的发展路线，这也是不靠谱的。我曾经也是这样的想的，但是玩过3个月，我就觉得这是非常不靠谱的。因为，这是格局问题，你不可能从外包->产品->平台，就像你不可能从 乞讨-> 找工作 -> 小老板 -> 企业家 一样。

  2. 大多数客户是不知道自己想要什么的。客户是“X-Y问题”重灾区。如果你想要做方案做产品，你要拥有说服客户的能力，你要有这种能力，就会逼着你去了解客户的行业和客户的业务。

  3. 如果你开一个公司整得跟别人的一样，那最好的方式是加入别人。没有必要再走一遍别人走过的路。

  4. 创业是开创一个事业，你要干的是充当一个搅局者，如果没有搅局的能力，也就是没有找到自己的核心竞争力，那还是不要创业。

  5. 找到商业模式非常重要，就是辛苦做一次，然后就可以copy-paste的模式。（我找了三年多了，感觉就这个模式就在眼前，但就是够不着……）

永久链接：https://yanjunyi.com/blog/posts/remote-work-to-group-up