互联网创业怎么做产品技术规划（一）
从鹅厂出来之后的这几年，在创业公司做了很多产品技术方面的实践工作，得到一些关于产品技术管理方面的心得，这部分比实际完成一些什么样的系统设计和开发更加宝贵，这是有钱都买不来的。后面一段时间，我尽量将这些心得以博客文章的形式写出来。 之前尝试过大而全和分章节的描述手法，在废弃了十版左右的草稿之后，决定还是用随笔的手法吧，划定一个小范围，想到哪儿写到哪儿，不拘一格。大而全格局太大，自己荒废了很长时间没写文章，把控不住；章节形式专业性太强，没做好写论文的准备，就不拿一些带主观心得的东西贻笑大方了。
相较于我刚开始学互联网编程的那段时间，也就是二十一世纪初的那几年，现在的互联网盈利模式更加清晰，业务和产品趋于红海竞争，值得去尝试的蓝海领域越来越少。带来的一个好处是：产品技术方面能够复用的东西越来越多。
举个现实中的例子。因为花椒、映客等等关系，最近遇到一些朋友想要做直播平台，要我给他们建议。我大致估了一下，质量上以产品原型计，大约有百分之八十以上的组件，包括比较难的 P2P、DHT、CDN、视频实时压缩等都有成熟的第三方解决方案，只有涉及到所谓『痛点』的大约百分之十几的那部分逻辑需要自己去做。这些成熟的第三方解决方案不管是开源软件也好，还是云服务的方式也罢，都能避免创业者重复造轮子，大幅降低开发维护成本，还能提高用户体验。
然而更厉害，就算是差异化的那百分之十几的逻辑，我们现在也可以利用工程化的手段让它们的产出更加高效更加顺畅。
最近一年我在创业公司积极推进一件事情，就是把初级工程师的成果有效化。出发点是帮助公司降低对工程师水平的依赖，用技术手段提高工程师的工作效率，提高输出成果的有效性。这事儿说透了也很好理解：既然创业公司的项目需求更多是原型实现，并且还有那么多可靠的第三方资源可用，技术团队也就更像是在做集成，而不是技术创新，对工程师的初始能力要求不应该特别高。当然，公司肯定也会同意，因为省钱嘛。o(╯□╰)o
创业公司对初级工程师倒不一定有什么特别的偏好，不过创业公司的 boss 们大多对技术人才无法做到『准确识人』，这是事实。有时候哪怕他们自己想找一些大牛合作，也苦于无法辨别。就算找到真正的牛人，在工作方式方法上通常也会出问题，至少是让其能量发挥不出来。所以干脆的，很多创业公司 boss 与其花冤枉钱碰运气找大牛，不如直接找初级工程师先实现原型好了。很无奈，也是事实。既然是事实，我们首先得尊重它，而不是抱怨，然后才能往后考虑，怎么样改进。
当然，先解释下：依靠初级工程师实现的原型在技术上是不是能够拥有可扩展性，今后是不是可以生长和健壮起来，是个问题。考虑到这是架构师在开工之前需要完成的设计工作来决定的，不可能指望初级工程师去完成，所以这点不在我们今天的讨论范围之内。所以首先，假设我们有一位有能力有担当并且对项目理解深刻的架构师吧。
话说初级工程师的工作一般都不可靠，特别在他们工作拥有自由度的时候，自由度越高则可靠性越差。要提高初级工程师的工作有效性，首先考虑的是怎么『约束』他们，降低他们可以自由发挥的空间。这个思路跟现在流行的互联网『颠覆』的观点可能会有点相冲——你把空间限定死了再做事，还谈什么互联网颠覆呢。不过我认为，就现实中的中小公司创业环境，技术上的创新总是局部的，否则研发成本太高，就是作死，运营和产品上的创新才是具有颠覆性的关键。
通常我给初级工程师『画地为牢』限定他们工作空间的办法有下面几种。
- **必须全程参与需求评审，独立完成功能设计文档。**会议和文档化是让很多工程师头痛的两件事情，但是在任何团队中，首先要保证的大家目标一致，花点精力在统一目标上，经验告诉我们，绝对值。
- **统一的代码风格和注释要求。**每种语言都有好多种代码书写风格，团队统一采用一种就好，这没什么可争辩。至于注释，最好也要统一一下要求，以便工程师可以在代码中合理添加注释。代码风格可以通过 lint 来检验，而注释则只能通过代码审核的过程，人工指正。
- **代码审核后才能合并到开发分支。**一方面是代码的质量控制，确保代码仓库里面的代码都是有效代码；另外一方面，代码审核恐怕是帮助这些初级工程师成长最快的方式。一个好的 reviewer 胜过任何职业培训学校里面的任何授课老师。
- **一个严厉的非黑即白的框架。**我不会浪费时间跟初级工程师在技术方案的可行性上做探讨——你当然这样做也能实现功能那样做也能实现功能，但你就是得按照我说的做。整个团队都是这样。没得商量。而保证这一点的最佳手段，就是用一个非常严厉、越雷池半步就报错的框架。
- **统一的开发环境和部署环境。**同样，我也不会在这方面跟工程师们有太多商量的余地，必须统一。部署环境由于涉及到运维的配合，与用框架不同一样，从一开始就必须大家都统一。不同的是，开发环境这方面我通常会给工程师们一个过渡期，过渡期内我会推荐我认为效率最高的系统、IDE 甚至 IDE 配置文件，并且提供支持。通常来说，一到三个月的过渡期之内，就能把这事儿统一下来。
- **保持一致的沟通腔调。**技术上，各种专有名词和特定的描述方式很多，沟通中大量使用专有名词虽然有时候看起来很装逼，但这样的确可以大大提高沟通效率。对初级工程师，以及我们的产品经理同学，通过在文档、会议中不断加以引导的方式，来强化他们对一些常用名词和描述方式的概念，让他们既能懂也能用，从而提高整个团队的沟通效率。
这样执行之后，做执行的工程师基本上不再可能有什么自助发挥的余地，就像谷歌技术团队的风格：一千人写的代码，读起来就好像是一个人写的。无论是代码和注释的书写风格，功能实现的方式，都是一致的。这样的代码就算放个两三年换个人来维护，也没有障碍。
另外一方面，想要提高工程师效率通常意味着激发个人的积极性，释放他们的工作热情，同时帮助他们扫清工作之外的障碍。从字面上理解，这和上面限定他们的空间相左。说细了，不矛盾。
- **统一的开发环境、沟通腔调，降低沟通中的障碍。**在拥抱变化的场景下，沟通随时随地都在发生，如果不能把沟通过程做顺畅，尽力消除沟通中的阻碍，工作效率自然没法儿提高。初级工程师最容易遇到的问题就是遇到问题表达不清晰，想帮助他也无从下手。统一开发环境、沟通腔调，团队成员基于一个场景在沟通，效率自然就提高了。
- **把开发流程中重复的步骤工具化。**例如：分情况 pull 代码；根据事件和关键词创建新分支；检测代码风格；部署代码到线上之前跑单元测试；部署代码到线上服务器；排查应用日志…… 如果每次手动做这些事情，势必影响编码的连贯性，把它们做成工具，每次运行一两条命令就可以完成一件事情，不仅可以提升工作效率，还可以提高试错的次数，小步快跑、敏捷迭代。
- **研发生命周期的管理从头到尾要做好，对工程师尽量友好。**工程师只有一个工作是有效的，就是编码，其余的工作都是辅助，不能直接产出价值。所以，工程师越能专注地编码，生产效率越高。除需求评审和写文档之外的必要开销，确保工程师大部分工作能够在两到三个界面完成，是最优的结果。这就需要团队能有一套很好的研发管理系统，不是松散的几个第三方工具，而是一个有机的整体，涵盖整个研发生命周期。听起来很高大上，可喜的是，对创业公司也有第三方的选择，只不过需要自己做集成。
- **生产环境要有带检索的日志系统和调试工具。**这个就不说了，也可以看做是从第二点中延伸出来的。单独提是因为，线上排错不知道坑了多少工程师的时间，熬夜加班，专门等午夜人少时重现错误，说多了都是泪。浪费的时间不是一点半点。
能帮工程师把编码之外的工作梳理清楚，减少他们被干扰的次数和时长，对于提高生产效率，规避编码中的 bug 效果很好。虽然上面几点在创业公司里面实施起来有些难度，但做总好过不做。况且，其中一部分已经有第三方成熟的解决方案，具体实施的时候只需要做集成即可。
在是给与工程师一个明确的施为空间，帮他们扫清编码障碍之后，技术团队在执行阶段的高效率，维护阶段的清爽，都是可以预料到的。这些准备工作虽然表面看不到有什么明显收益，但是对于公司在中期对外连续作战帮助非常之大。
附录一：推荐的几个第三方工具和服务
- 代码仓库：gitlab。同时基于 gitlab 的 web service hook，还可以扩展出涵盖大半段研发生命周期的系统，以此完成工具化的搭建。
- 需求管理：tower。这个纯粹是个人习惯，其实 worktile、trello、teambition 等等都不错。tower 虽然也有 api，可以做信息流集成，但貌似只限于收费的 Pro 版。
- OS + IDE：Linux + vim。作为后端码农，这是不二选择。在这个前端要会用 linux 的时代，不会 linux 不能作为理由，只能是工程师自己的耻辱。前端码农根据项目不同，酌情选择更优的 IDE，例如 xcode（iOS APP）、atom（React）、Android Studio（Android APP）等。
- 后端开发框架：Laravel（PHP）。作为一款大量应用现代语言特性的开发框架，laravel 的缺点也是它的优点：太多的新特性，让初级工程师困在它规划好的地盘里，只能照做。