在许多人看来，Yandex是一家大型的整体公司，其流程受到严格的管制，但事实并非如此。 我们一直在寻找新的方向，开始新的项目并尝试新的市场。 与Yandex.Health医生进行在线咨询的服务是经典的内部创业公司之一。
在该服务仍然是一个页面，其中包含内部Wiki简介的时候，我开始领导Health的开发。 在这篇文章中，我想分享我们在两年半的服务工作中开发的开发方法。
免责声明：初创企业有其自身的特征。 我们的主要任务是每单位时间进行最大数量的实验，并以最快的速度发布产品功能。 同时，我们必须将产品的质量保持在一定水平上，以免对其感到羞耻。
[一个因缺乏良知而发火的地方] 。 我注意到，功能的高速交付尤其意味着保持相当高质量的代码。 否则，该产品迟早会在错误中窒息。
下面的所有要点或多或少都受到了影响，几乎每个人都有一个现实生活中的案例。
代码质量和架构
- 我们将在确保可接受质量的同时将功能投入生产所需的时间减至最少。
- 任何任务都涉及两个解决方案：快速和正确。 对于任何功能，我们都考虑了这两个选项，以便可以将快速解决方案升级为正确的解决方案，从而使不必要的“弹出”工作最少。 推出快速解决方案后，我们会花一些时间，了解是否需要合适的解决方案。
- 至关重要。 通常，“解决用拐杖得分的第一种方法”与“精确准确地解决问题”之间的时间差是十分钟。 因此，我们总是在写之前思考。
- 如果要在次要优化和可读性/体系结构之间进行选择，请选择第二个。 两毫秒不会解决任何问题，并且使用此代码，我们仍然必须生存和维护。
- 我们正在考虑未来。 不久的将来比遥远的前景更重要。 如果可以使决定变得困难（读作“长篇大论”），灵活决定，或者简单但又容易确定，那么值得确定，然后根据需要进行重构。 最好现在花一天时间在一个简单的解决方案上，花一个月在一年内进行可能的重构，而不是现在花两周时间（是的，这就是所谓的技术债务）。 这样的决定值得与团队讨论，这一点很重要。 独自一人，您可能会错误地评估在不久的将来扩展此功能的可能性。
新技术
新技术很棒，让我们使用它们。 但是我们的产品不是试验场。 如果要应用新算法或新技术，可以在以下条件下完成：
- 技术带来了实实在在的利润（优化，架构质量，代码，可伸缩性，而所有这些都是真正需要的，而不是牵强的）；
该技术通常适合当前堆栈（如果所有代码都是用Python编写的，则无需在Go上编写某些服务） - 技术不会降低体系结构的质量和代码的可读性（这是主观的，因此将与团队讨论）；
- 实施和支持新技术（包括寻找新的开发人员）所花费的时间不会比在当前技术的框架内工作花费的时间更多。 同样，这完全取决于预期的利润，并与团队进行讨论。
- 与团队讨论任何新技术：如果很酷，那么每个人都可以使用它，如果不是真的，那么小组讨论将使您快速了解这一点。
您不需要独立地实现已在现成库中实现的算法（除非它是一个庞大的框架中的一小部分，并且将其全部拖到一个解决方案中是没有道理的）。 - 如果您做了一些既酷又方便的事情，请与团队（或者更好的是，在Yandex内部）共享解决方案。
沟通交流
- 我们一起讨论解决方案。 功能越复杂和关键，这种讨论就越重要。 如果有人不喜欢该解决方案，我们会说服对方，直到达成协议。 否则讨论时间将不会超过合理的时间。
- 如果无法达成一致，那么最后一个字要摆在头上。 我们有一个合理的民主国家，而不是17世纪的波兰下议院 。 同时，领导者在业力上大失所望，必须经历道德上的苦难。 当然也不要经常使用此权利。
- 一旦决定，我们就会按照约定进行。 即使我强烈不同意。 没有“我比所有这些产品专家都知道如何提供服务，所以我会做我认为必要的事情”
- “不在产品中-未完成。” 每个人都遵循自己的任务。 如果该功能已准备好进行测试，则需要确保将其推广到测试中。 如果她准备发布，则需要确保她尽快进入产品。 负责发布版本的人员并不总是记住每个功能。 随时提醒她。 [关于团队中各个角色之间责任分配的激烈讨论。]
- 有必要打开头部。 如果任务看起来很奇怪，难以理解或时间太长，则应明确并大声告知负责的经理。 并执行此操作，直到您清楚地知道为什么所有内容都应采用这种方式。 恰巧在正确的时间提出正确的问题可以节省数周的开发时间。
时间管理
- 如果任务不能在合理的时间内完成，我们必须大声谈论它。 您不应该坐下来几个月来进行三天的评估来削减任务。 如果拖动严重，则说明出现了问题。 也许在生产中存在误解，或者我们低估了工作量。 在任何情况下，都应重新讨论此类任务（因此有时会推迟甚至掩埋）。
- 出现的问题应独立解决。 但是，如果很明显该过程被延迟，请务必与他们讨论并寻求同事的帮助。 在“我必须自己做所有事情而不要分散我的同志”状态下坚持几天是非常糟糕的。
- 在我们获得成功之前，没有人会看我们每个人何时离开，而我们的政权不会开始干扰团队的工作。 但是，仅因为没有时间做某事而在晚上坐是没有必要的。 如果这成为一种习惯，那么问题就更深了-规划，重新评估自己的能力等。 当开发人员在晚上加班时（因此一切都按时进行），大大减少了有人看到并解决此问题的机会。
- 碰巧我们需要在约定的日期（或尽快）启动重要功能。 在这种情况下，我们要加班。 而且，领导者在业力上有很大的缺点，必须经历道德上的痛苦。 当然也不要经常利用这个机会。 这样的加班时间被抵消了。 [关于加班和报酬的大火] 。
致命罪
这是一个单独的部分。 在这里，我试图列出在团队合作中我认为是错误的和有害的。 每个项目都有自己的重量。 有些人谈论非常大的问题，而另一些则不是那么关键。 因此，应尽量避免：
- 工作，不包括头部：“被告知要做-我做了。” 每个团队成员必须了解他所制作的功能的本质及其对产品的影响。
- 使用“我已完成所有工作”一词，将功能未放到产品中。 我们所做的应该在生产中起作用。 虽然该功能尚未发布，但尚未准备就绪。
- 同意以一种方式进行操作，然后以自己的方式安静地进行操作。 上面已经讲到“我比谁都知道更好。” 但是，再次回顾这很糟糕并不会造成伤害。
- 加强重要功能，深入讨论罕见且不切实际但可能存在的问题。 如果在合理的时间内您不知道如何解决较小的且极难复制的问题，那么我们只是同意如何生活。
- 不要及时提出问题，尝试自己解决所有问题（通常在晚上）。 这种英雄主义只会导致措辞失败，疲倦和被低估的感觉：“我在这里做着壮举，但我也因工作缓慢而受到批评！”
- 对批评代码做出反应并弄清这种关系是很痛苦的。 即使某位同事说代码是如此普通（“让我们重写所有内容！”），也应理解并加以处理，并讨论其为何如此。 对于您个人而言，这与整个服务一样有用。
- 去找那个人。 批评代码或解决方案时，我们只批评代码或解决方案，但绝不批评编写或建议的人。 给定上一段，不要害怕批评。 与发送不成功的决定进行生产相比，与同事辩论的合理时间更好。
合计
在这里，您可以写出大约一百万种东西。 但是帖子越短，阅读
到末尾就越容易，我真的希望如此。 是的，我不会痛苦地接受批评（但前提是您不能变得个人化；）。 因此，让我们讨论吧！