简评：作者是一位在创业公司有多年工作经验的工程师，见证了公司从零到一的成长过程，从切身的体验总结了作为一名工程师在一家创业公司工作学到的一些经验。

在过去的三年里，我在柏林一家做 B2B 的创业公司工作。当时我是公司的第一个后端开发工程师，见证了公司客户从 200 增长到 720、年收入从 20W 美元增长到 300W 美元、员工从 5 个人到了 25 个人的增长过程。

下面是我在那段时间一点个人经验的小总结，希望你能有所收获。

1. 回顾总结至关重要

我们经常会以团队形式坐在一块讨论下最近的一次迭代，回顾总结的重要性是不可忽视的。在讨论开始前每一个成员都要想好接下来需要提高和改进的地方，每人轮流发言，然后再进行小组讨论。这种方式能让每个人都指出关键的问题-比那些口号响亮的主题会议效果要好很多

2. 定期花点时间 1 对 1 交流。

在忙碌的创业环境中，每周和你的 leader 一小时的交流可能很困难，但是我们仍然这样去做了，并且收效明显。你可以借此深入地讨论遇到的问题，也可以简单说说自己作为员工的一些感受，这样的交流方式收获是非常大的

3. 为开发者工具付费

对于电脑来说，每 GB 或者 MHz 都会让它运行更快；对于软件来说，每个有用的工具都会让工作更高效。为开发者提供一个快速、现代化的工具库不仅仅是效率的提升，更让他们意识到公司对开发的重视

4. 去面见你的客户

我们会定期的拜访下当地的一些客户，每年也会去一些客户集中的区域出差，这让我们有了很多意想不到的收获。与发邮件和客户交流不同，直接面对客户听取他们在使用产品上的痛点和建议，那种强有力的感受会持续影响到你后续开发时对于产品的思考。

5. 不要让构建变慢

没有什么比上班时慢的要死的编译过程更让人煎熬的了。我们后端使用的 java，前端用的 Webpack。这两块后期编译变得越来越慢了，最后都让人有撞南墙的冲动了。长远来看，换一个性能更好的机器并不能改变现状，需要考虑的是在应用架构上的优化，比如说：模块化。

6. 组建跨职能团队

在拥有一个跨职能团队前我们只能做些技能范围内小的项目，一旦团队有了设计师、前端和后端开发那就不一样了，团队就可以做更多的事情了，当然也会面临更多的挑战，但是对于创业公司来说这是必须要跨过的一步。

7. Trello 在 bug 跟踪和项目管理上并不是很有效

我们使用 Trello 来管理我们的 bug，尽快我很喜欢用它但是 Trello 也有些短板，Trello 的搜索并不是很好用，在项目管理上也面临这样的问题。Trello 在一定程度上失去了简单性和易用性，让人用起来觉得有些过重，我更喜欢用专门的工具去做这些事情。

8. 敢于承担责任

在一个公司要想成长就得要承担责任，责任越大越好。和大公司不同的是在小公司角色并不是一成不变的，而且会有很多无人认领或者不受待见的任务，这个时候你必须敢于担当来提升你在公司的地位和领导对你的印象，塑造自己的形象。如果你的方向和公司目标吻合，那么你很容易就会得到应有的奖励。当然你可以选择专心做一名优秀的代码架构师，但是如果你公司只看中业务功能的话，你就很容易变成别人眼里的瞎折腾了。

9. 接受你所不能改变的，改变你所不能接受的

在一些事情上你肯定会面临和领导的意见相左，这个时候你需要衡量下这件事对你多重要，如果是非常重要的事情，你可以站出来据理力争，但往往是一场苦战。如果你身边的人都很少有人支持你，甚至没人赞同你的观点时，你需要审视下自己是不是真的值得这样去做。当然你可以选择忽略并接受他们的想法，你也可以选择走人。

10. 追求有实际意义的fuli

很多公司都会提供一些fuli，有乒乓球桌、周五下午的开放酒吧、甜点茶饮……这些都是陷阱！要多追求些对员工有实际意义的fuli，比如午餐、定期学习培训、教育经费、健身fuli等

11. CEO 有机会休假

当一家创业公司发展的越来越壮大时，CEO 必须逐渐的放权，毕竟一个人无法再承担更多的事情。基本上，CEO 要逐步的变得具有可替代性。一个好的衡量指标是公司是否为他制定了休假计划。

12. 制定实时消息的策略

即时通信工具我们用的 Slack，尽管有时候很有趣但也扼杀了很多生产力，对于这个聊天工具的使用上我们没有一个共同的态度去对待。明确好哪些不该使用聊天工具去沟通很重要，有些沟通内容显然通过邮件、面对面交流或者 wiki 会更好些。

13. 第一印象很重要

你所说的和做的都会在别人那里塑造一个对你的印象。如果你周末在家工作，那么你就是个「工作狂」，如果你想出好的点子，他们会认为你是个「神奇的孩子」。而关键在于：这个印象很难改变。通常，早期的印象非常重要，后期你就很难改变周围人对你的看法了。

14. 团队要有梯队性

在我们团队，后端基本上都是 5 年以上工作经验的高级开发工程师，但是令人意想不到的是，很多的讨论最终都没有结果，每次讨论都很激烈，甚至有时候我怀疑他们能否全部「活着」出来。而另一方面，前端基本都是初级开发，他们表现出更大的激情和创造力，虽然看起来很不错，但往往会因为经验的缺乏走了很多弯路。因此，团队建设的关键是要各个层级梯队的人员兼顾。

15. 开始编码前做个原型设计

一个新功能的开发会涉及到很多相关者，比如：项目经理、设计师、产品经理、CEO、开发和客户。每个人都有自己的期望和需求，对于新功能沟通的最好方式是设计一个最接近实际效果的原型，这会帮助我们避免产生的误解，让大家都在一个思维线上。

16. 每个团队一个办公室

我已经一次次的表明开放式办公是个糟主意。公司为了省钱同时想营造一个具备创造性和合作性的办公环境采取了开放式办公的策略，但是以经验来看，我可以明确的告诉你，你工作时更需要一个保持安静，同时还要保证能和队友随时沟通的环境，我发现一个团队一个办公室的规则就能达到很好的平衡。

17. 不要让外向者主宰每次讨论

对于像我这样内向的人来说，工作场所可以说是充满挑战。外向的人更擅长说和写，内向的人通常很难与其竞争。外向者更快、更自信、更精细的做出响应，而内向者则会处于严重的劣势。任何不重视这个问题的公司会因为“沉默的少数”失去一些伟大的想法和贡献。

18. 开发者需要形成共识

一旦你从一个开发团队转到另一个开发团队，你会发现有很多冲突点。每个人风格都是不一样的，这就是为什么要形成一套公共的代码风格、架构设计、开发和 bug 处理流程以及 code review 方式等等。简单地在 wiki 上定义下规则是没什么效果的，必要的时候要让这些规则被实际应用起来，让每个人都能理解和有机会去改变。因此，定期的讨论也是必不可少的。

19. 定期的进度更新是督促前进的一种方式

每天的站立会上我会给整个团队讲讲我上一天完成的工作以督促自己前进，当然每周的进度状态更新也是这样，当我们还是个创业公司小团队的时候，每个人都会用简短的几句话描述下过去一周所遇到的成功和挫折的事情。公司发展到一定规模就需要团队共同努力去前进了，这样的方式也不再是一种督促了。

20. 员工培训成本的预算应该按时间衡量，而不是金钱

尽管我们有员工培训的预算，但是除了参加一些会议外基本上没怎么用到过，而很多专题会议也很水，甚至连新技术都没有。和我周围的很多同事一样，我们只能从博客，书籍和视频中学习新技术。所以我建议让开发者每年投入几天时间来学习，虽然经常利用周末时间，但无论如何公司要对这方面明确支持下。

21. 结对编程不可低估

当你有一个重要的信息想让别人理解、分享和记住的时候，你不能只讲一次，或者只是简单在Slide 上加粗，你需要重复描述几次，表达上要清晰无异议。论是非常宝贵的经验，结对编程实施的效果依赖于两个开发者之间的相处程度，从经验上来讲，把两个完全不同的人组合在一起会产生更好的效果。

22. 避免缺少合理的释放过程导致功能卡住

这个问题看起来很明显，但往往却很容易被忽略。我亲眼目睹过一个已完成的功能因为没人知道它实际进度而陷入僵局几个月。清楚的划分好首要责任人对于一个功能开发来说是非常重要的。

23. 自主权催生伟大改变

让开发者有机会去做一些新的尝试，这或许会成为他创新的强大力量源泉。当一家公司鼓励开发者自驱动时，那么公司也将会收获巨大的改变。否则，开发者太专注于工作的话长期以往很容易产生负面情绪甚至倦怠心理。

24. 传达重要信息的时候要多次强调

当你有一个重要的信息想让别人理解、分享和记住的时候，你不能只讲一次，或者只是简单在 Slide上加粗，你需要重复描述几次，表达上要清晰无异议。

25. Hacks 是创业公司文化的重要组成部分

对于一家创业公司来说，资源限制下却总是有更多的事情要做，排好优先级显然很重要。这也通常意味着我们需要快速的 hack 一个方案来完成几乎不可能完成的工作，有时候出发点是好的，像通过快速产出原型的功能来观察用户的粘性。但一旦这样做了，你后续就很少有时间有精力去改进和优化了。一直让我觉得恼火的是一个 hack 方案可以在产品里存在很久，我始终觉得那是种欺骗。Hacks 对于创业公司来说是个原罪，千万不要过头。

26. Deadlines 是愚蠢的

在当今不断变化的世界，dealine 作为过去人为制造的一个概念，除了让管理者感觉良好外，却扼杀了软件开发中所有美好的东西。把 dealine 当做一种方法论的，越来越让人觉得可笑和糟糕，唯一比这更糟的事情是 dealine 再加一堆需求吧，这像是把我们带回了软件开发的远古时代。未来 dealine 肯定会逐渐消失的。

感谢你的阅读，接下来我将加入多伦多的一家创业公司，相信在那里会学到更多的经验。

原文链接：
26 Lessons From Being a Developer at a Startup