在创业公司做工程师学到的26条经验！

在过去的三年里，我在柏林的一家小型B2B初创公司工作。我是第一个后端开发人员，见证了公司的成长，从200个到720个商业客户，从20万到320万美元年收入，从5个到25个员工。

对于那段时间的个人经历，我简单地总结出以下26条经验教训。这些经验教训都是基于真实的经历，没有夸大，也没有缩小，供参考。

（1）回顾至关重要。作为一个团队，我们会定期坐在一起，反思最后一次迭代。回顾和评估的重要性怎样强调都不过分。首先要求每个参与者独自思考哪些方面运行良好，哪些方面需要改进。只有在每个人都充分表达了自己的想法后，才会开始进行团队讨论。通过这种方式，每个人都能够提出重要的问题，这样比那些由“声音最大”的人主导的会议要好得多。

（2）定期1对1沟通。在忙碌的创业环境中，似乎很难找出足够的理由来支持这种做法：每周和你的经理交谈一个小时。但那就是我们所做的，并且效果非常好。这种交谈可以让你与经理深入地探讨问题，或者是感受到自己作为员工的价值。

（3）为开发人员的工具付费。对于计算机来说，每GB或每MHz都有助于加快工作速度。对于软件来说，能够帮助你提高效率的每个有用的工具都是重要的。为开发人员提供快速、现代的工具，也表明公司非常重视他/她。关于这点应该无需更多讨论。

（4）与您的客户见面。我们定期拜访当地的客户，每年都有一次到客户热点地区的差旅（例如纽约和旧金山）。这确实有所不同。与客户通过电子邮件进行沟通是一回事，但与他们见面并直接听取他们的痛点和成功则是完全不同的体验。当你回到公司进行开发时，之前和客户见过面会对你看待客户的方式产生持续的强大影响。

（5）不要让代码构建变慢。你知道，当缓慢的代码构建成为办公室的问题时，几乎没有什么会比缓慢反馈周期更令人沮丧的了。我们曾经在后端使用Java，在前端使用Webpack。两者在一星期中都变得越来越慢。最后，这让我想用头撞墙。从长远来看，购买速度更快的机器无法改善缓慢的代码构建。你需要考虑应用程序的结构来处理它，例如模块化。总之，没有快速改善的方法。

（6）跨职能团队FTW。在组建跨职能团队之前，我们只能有效地处理小项目。一旦我们有一个由设计师、前端和后端开发人员组成的团队，事情就会起步。这使得我们能够应对更大，更有影响的功能项目。采用跨职能团队的形式本身会带来一些需要我们克服的挑战，但总的来说，这是创业发展的关键一步。

（7）作为缺陷管理或项目管理工具，Trello扩展性不佳。我们在使用Trello 进行缺陷管理。我很喜欢Trello，但总是感觉这种工具有所欠缺。使用Trello时很难进行搜索，并且只能在某种规模范围以内使用。在进行项目管理也同样如此。超过一定规模，Trello操作上的简单性和易用性会逐渐消失，变得难以应用并失去效果。我更喜欢能够真正支持并推动目标达成的专门工具。

（8）承担责任或默默无闻。要想在任何公司取得成功，你必须承担责任，并且责任越大越好。与大型企业环境的不同之处在于，在初创公司中这样做很容易：公司内的角色不是一成不变的，你能够很容易找到无人认领或无人想要承担的责任。你必须负责某些事情，从而提高你的地位。你需要积极主动，塑造自己的形象，否则你的形象将由他人的评价决定。特别提示：当你要承担的责任与公司目标一致时，你可能会成为一名优秀的代码架构师。但是如果公司只重视功能开发，你可能就选错了方向。

（9）适应或离开或在必要时抗争。在某些事情上，你可能会不同意管理层的观点。在这种情况下，你需要确定这些问题对你来说有多重要。如果对你非常重要，那么可以去承受挑战进行抗争，坚持你认为正确的事情。但这个过程往往非常艰苦。如果身边几乎没有人支持你，甚至没有人赞同你的观点，那么你需要问问自己是否值得。你可以忽略它并继续工作，或者寻找另一份工作。

（10）寻找真正重要的福利。很多创业公司都宣称有很多福利。有些创业公司会骄傲于所提供的乒乓球桌，有些则以星期五晚上的开放酒吧来吸引人，还有一些会炫耀所提供的多种超甜玉米糖果。这是一个陷阱！寻找真正有意义的福利，比如提供午餐学习机会，培训预算或健康福利。

（11）首席执行官应该能够休假。当一家创业公司不断发展壮大时，首席执行官必须逐渐放弃越来越多的责任，因为一个人精力有限，无法承担公司规模扩大而不断增多的责任。通常来说，首席执行官必须逐步淡出，其责任由他人代替承担。能够做到这一点的一个良好信号是，首席执行官决定去度假。

（12）你需要确立关于实时沟通的基本策略。我们会使用Slack实时沟通，尽管有时很有趣，但我认为它还是会影响工作产出。对于如何使用实时沟通工具，我们并没有公认的标准。因此重要的是要明确哪些内容需要在实时聊天中解决，哪些则是通过电子邮件，面对面交谈或wiki协作更好。

（13）你可以影响人们对你的看法----在第一次见面的时候。你的一言一行都会影响到别人对你的看法。如果你在周末工作，你将成为“工作狂”。如果你想出新的功能，你可能会成为“神奇的家伙”。关键在于：这种印象会一直持续下去。最初的印象往往是最重要的。时间越长，改变周围人对你的看法就越难。

（14）平衡老员工和新员工。在后端，我们拥有的几乎都是高级开发人员，他们的开发经历总和超过了55年。但令我惊讶的是，这却导致了他们之间的讨论很少产出好的结果。这种讨论非常激烈，有时我甚至怀疑是否有人能够真正从中胜出。另一方面，在前端人人都是新手。他们表现出很多的热情和创造力。尽管他们的用意良好，但往往看不到更大的局面，缺乏高水平的最佳实践。问题的关键在于新员工和老员工要有一个恰当的比例。

（15）在开始编码之前进行视觉模拟。一个新功能会有很多利益相关者，例如，项目经理，设计师，产品所有者，首席执行官，开发人员和客户。他们都有自己的期望和诉求。传达新功能愿景的最佳方式应该是尽可能接近最终结果的视觉演示。这种做法多次帮助了我们避免误解，达成一致。

（16）每个团队一个办公室。事实一次 ，又一次 ，再一次地 反复表明，开放式的办公室是一个糟糕的主意。我认为公司采用开放式办公室通常是希望节省租金，并认为这种办公环境能够促进员工合作并激发创造力。而我的经验则是你需要一个安静的环境来完成工作，但同时要能够与其他的团队成员轻松进行沟通。如果团队的规模较小，采用“每个团队一个办公室”的方式就能够在这两种需求间达到很好的平衡。

（17）在没有控制的情况下，外向者会主导每一次团队讨论。对于像我这样的内向的人来说，工作场所是具有挑战性的。外向者通常很喜欢口头交谈和书面表达。而内向者通常不善于竞争。由于外向者能够更迅速、更自信、更详尽地作出反应，在团队讨论中内向者往往处于严重的劣势。如果不能很好的应对这个问题，任何公司都会失去“沉默的少数”可能提出的伟大设想及贡献。

（18）开发者需要经常探讨来建立共同的理念。只要从独立开发模式转变为团队开发模式，就一定会出现冲突。每个人都是不同的。这就是为什么在代码风格、架构、开发和错误处理，代码评审等方面的建立共同的理念模式是如此重要。仅仅通过wiki协作写下规则是起不到作用的。共同的理念需要在实践中建立，得到所有开发者的理解，并根据情况加以改变。除了定期讨论，没有其它方式能够做到这一点。

（19）定期更新工作状态能够产生激励作用。在第二天的例会上整个团队都会听取我完成了哪些工作，知道这一点对我起到了很大的激励作用。每周进行个人工作状态汇报的激励作用则更大。在我们的创业公司规模还很小的时候，每个人都会用简单几句话在会议上分享自己上周的成功和失败。 随着公司规模的不断扩大，只有团队共同完成的工作才能够在会议上进行汇报，此时这种汇报的激励作用就不再很大了。

（20）学习预算需要用时间来衡量，而不是用金钱来衡量。尽管我们有学习方面的预算，但是除了参加会议之外，这个预算几乎没有被使用过。研讨会也是一种可能采用的学习方式，但是通常找不到一个提供最新技术的研讨会。但是和很多同事一样，我可以从博客、书籍和视频中学到新东西。因此我建议开发者每年投入几天的时间来自学。无论如何，这是我们必须做的，通常是在周末。但是公司应该对员工的这种学习提供直接的支持。

（21）结对编程被低估。在团队成员甚至跨团队之间分享知识的好工具是结对编程。就个人而言，我觉得它比代码评审更有效。编码过程中的交互和讨论是非常宝贵的。结对编程的效果往往取决于两个开发者之间的合作程度。从经验来说，我觉得把不同的人组合在一起实际上可以产生最好的结果。

（22）缺乏正确的发布流程，导致整体功能实现停滞不前。这个问题可能看起来很明显，但却很容易被忽略。在我的经历中，由于没有人真正知道如何在已完成的功能点基础上继续推进，一些整体功能的开发曾陷入僵局长达几个月。清楚的了解哪个人承担哪些责任，或者更好的是有一个人来专门负责处理这个问题，这是非常重要的。

（23）自主权会带来很大的好处。给开发人员在其从事的现有工作上提供机会，可以成为创新的强大源泉。当公司支持这种优秀开发者所自然具有的驱动力时，就会产生很好的效果。否则，最专注的开发人员则会自己找机会（例如加班或周末），从长远来看，这可能会导致不快乐甚至倦怠。

（24）当你希望让他人牢记某个信息时，要反复表达出来。如果你有一个重要的信息，希望每个人都能理解、认同并牢记的话，只表达一次是不够的。你可以把这个信息用粗体字放在幻灯片上。需要一遍又一遍的重复这个信息。对信息的表达一定要十分清晰，毫无模糊之处。更多关于这一点的建议可以阅读《如何让他人牢记信息》一书。

（25）利用开源是创业文化的重要组成部分。一家创业公司总是想超越现有资源来做更多的事情。优先排序是必不可少的。这通常意味着利用开源快速产出一个可能没有效果的解决方案。这种快速产出有时候是出于好的原因，比如制作一个功能的原型，看它是否能够持续应用。如果原型确实能够继续使用，你就几乎没有时间再回头对其进行改善了。然而，我一直觉得非常恼火的是开源借用能带来多少值得庆祝的好处。总是有种我在作弊的感觉。但是我已经接受了：在任何初创公司，利用开源都是一个虽然罪恶但必要的过程，只是请不要做过头。

（26）设立最后期限是愚蠢的。对于当前不断变化的世界来说，设立最后期限是过去的一种人为控制方式。设立最后期限只能使经理自我感觉良好，但是却抹杀了有利于软件开发的一切因素。越是将最后期限当作一种控制方式，对于开发过程来说，它就会显得越发的可笑和危险。最后期限是一种方式，它变得越来越可笑和危险。更糟的是设立最后期限并附件一系列要求。这是软件开发最初年代的做法。未来将不会再有设立最后期限这种事情。

感谢您的阅读。我很快就会加入另一个创业公司，这次是在多伦多。我确信我将在那里学到许多新的经验教训。

作者：Stephan Behnke

软件开发人员永远都在做平衡。大部分时间都是在不断地追求致力于实现代码的简洁、高贵和典雅，或者在这三者中寻求平衡。

译者：BIG CAT

从科研，到开发，到售前，到实施。从高校，到央企，到外企，到民企。一直相信机遇只偏爱有准备的头脑，一直准备着。

↓↓ 点击"阅读原文" 【加入云技术社区】

相关阅读：

更多文章请关注