🚌 👨🏿‍💼 🖐🏻 给开发人员的坏建议：如何“请”管理人员 💇🏻 🧔🏿 👆🏼

正如上一篇文章中所承诺的，我们正在朝相反的方向扭转局势。我碰巧不仅是一名开发人员，而且还是不同级别的领导者。我已经提到最近我对团队和同事很幸运。但一直以来，一切都发生了。

（Grigory Oster）

让我们谈谈管理层梦dream以求的开发人员。这次我将担任抽象经理...

在任何项目开始时...

您是否知道经理的最高技能是用最少的初始信息来做决定。领导们，不要阻止我们训练这项技能。请遵循以下策略：

命名有雾的日期，但根本不要谈论它们。
当我们询问拟议的改进是否不会破坏现有模块时，请保持沉默，紧紧捏住神秘的表情！
在谈论项目即将出现的问题时，请不要提供您的解决方案，请记住，我们需要人员问题，而不是人员选项解决方案。
— , , ? 48- , 10 , .
— , .

如果在设置任务的阶段您被客户邀请来询问客户澄清问题，请学习DDoS攻击-尽力而为。客户希望您收到至少50条带有问题的信息，最好是详细信息-他会感谢您在书信体裁中的表现。您无需附加任何屏幕截图或视频-让他们解密您的消息，即使其中仅包含“ Hello！”还有很长的“打字...”。

请记住：客户和最终用户是不同的人。切勿与最终用户交流，也不要想像他们！如果结帐处的Masha姨妈应该在监视器上看到25行文本，请冷静地放置它们而不看屏幕尺寸。如果她不喜欢，请让放大镜拿。

永远不要告诉我们项目中要解决哪些具体任务。只讨论解决方法。而且在所有细节上都是可取的-首席技术官今晚还能和平睡觉吗？

在您的故事中，绝不要提及他人理解的金钱，时间或其他指标。毕竟，甚至导演的秘书也可以将有关所使用的抽象结构的故事翻译成用户场景以及我们所获得的确切利润。因此，在评估任务时，请使用最抽象的数量系统。记住，一只蟒蛇是38只鹦鹉！

收获尽可能多的惊喜。除了解决问题之外，我们还需要付费订阅或工具，直到最后一刻我们才知道。我们喜欢这个陷阱，并很乐意在发布之前寻找摆脱僵局的出路。我和我的客户喜欢每周增加分配的预算，并在所有情况下不断进行协调。在每次更新有关存储科什切夫逝世地点的信息之后，从故事的开头驱使伊万·塔萨维奇（Ivan Tsarevich）进行一次新的迭代。

完美的代码...

尝试只为完美代码编写完美代码。不必第一次执行此操作。如果要赶时间，请快速写，然后重做，然后再次。记住：重复是学习之母。如果代码已被重写了三遍，并且至少与理想情况稍有不同，那么请立即执行重构，这是一项不适用于此任务的小任务的一部分。更好的是，将您的代码转移到另一个库或框架。让代码既时尚又年轻。最主要的是，在任何情况下都不能将所有这些流程表述为单独的任务。然后突然间，我们猜测该项目不理想？最好在发布前完成此类操作。此刻，整个团队的工作速度大大加快！

说到重构。如果同时更改代码中的机制，它将更有效地工作-以免爬到那里两次。请记住，这样的过程应该影响尽可能多的组件。为什么要花时间挑选单个模块？只有这样，您才能看起来像一个拯救了所有人的英雄！其他开发人员用脚射击时会很高兴发现新机制的惊喜。

完美的代码应正确格式化。尝试创建最大大小的文件，占用多个屏幕并同时包含多个组件。遵循这种设计风格，您可以英勇地克服合并冲突，并在很长一段时间内与更重要的编辑达成一致。该代码应类似于最长的面条，而无需浪费时间来创建小的无关紧要的文件。为了一个功能，想出一个文件名-什么会更痛苦？

您创建的完美代码不必涵盖测试。您只能谈论将覆盖率提高到100％的需要，但实际上10％就足够了。为了跟上您的需求，添加了一些实际上不检查任何内容的测试，因此不必更新它们。

如果突然发现快速编写的解决方案不起作用或无法按预期工作，请随意将一切归咎于系统架构师，API，服务器管理员等。很明显，您的理想代码只能奏效。记住主要的事情：我们和您一样，都知道理想的程序员只能在理想条件下在真空中工作。而且，如果您分心了，不要及时提供信息，写不懂的TK，那么您通常不对所实现的模块不能完成业务任务的事实负责。好吧，对，生意是我们的责任。建议保留所有有罪因素的名称，直到截止日期为止，稍后将需要它们，现在不要分散领导的注意力。

当我们谈到需要快速发布MVP时，请随意忽略我们加快项目速度以至于损害质量和速度的尝试。但是，他们知道，有了一个好主意，您可以随时在市场上开始。时间不起作用。让竞争对手大吃一惊，当您编写完美的代码时，我们的MVP将在5年内飙升。这些年来，投资者将乐于用自己的钱来创造杰作。

项目中的订单...

你的任务就是你的个性。创意混乱会加重我们的视线。建立混乱并将其保持在相当混乱的状态的能力非常有价值，以至于我们甚至为了提高混乱程度而相互交接项目。一旦混乱达到最大，我们将奖励您一个新项目！

如果您知道该项目已经形成了一个烂摊子，但尚未搬迁，要么开始用爪子挖出技术债务，要么自己寻求另一个项目。也许我们只是没有跟踪情况。

团队内部发生的所有事情都必须经过我们。即使您决定与测试人员一起抽烟，也一定要通过项目经理与他达成协议，但是最好让CTO参与其中。如果没有人抱怨我们的同事，没有解决工作组内的纠纷或引入一些工作规则，我们感到没有必要。

关于设计问题，建议我们仅使用PM编写。这会将我们活动的所有痕迹隐藏在高层管理人员的手中，同时将迫使我们向流程中的其他参与者重述已制定的解决方案。我们非常喜欢它！

解决问题...

解决问题或修复错误后，切勿检查解决方案。呼喊“万岁”，并尽快远离工作场所！因此，您将更快地移交任务，并为下一次冲刺的前半部分找团队上课-您将纠正刚刚完成的任务的门槛。重要的是，您也不会剥夺其他测试人员的工作。解决方案中由新拐杖引起的一系列错误是周五晚上的最佳礼物！仅在一个成功的案例中签入代码，您就是一个乐观主义者。

解决问题时的正确操作顺序：

阅读传统知识，忽略注释，
抽烟忘记细节，
快速，毫不犹豫地仅执行基本功能，
尽快完成任务
明确解密未读的TK注释，获取修订版本，
就这样，以3-4次迭代解决问题。

无需进行重构，也无需进行代码组合。在洞察时让您的左腿想要调用这些变量，并且代码仍然很难读取。这不是您以后要理解的！好吧，训练一下使您的代码立即得到审查-您是一个很好但是很敏感的人。

在此阶段，不可能创建任何证明任务已完成的证据（否则他们有时会拿出一段视频，在项目上写出模块如何启动……）。也许测试人员不会注意到与TOR的任何差异，否则该任务将被发送到另一个任务，而现在您可以放心进行一项新任务。

例如，如果任务中存在含糊不清的时刻，则不知道输入字段是否应同时仅接受英语或俄语字母，请根据自己的喜好和生活经验随意回答问题。因为它不是写在工作说明中，所以这对于每个人都应该是显而易见的！

永远不要在任务的一小部分上检验任何假设，否则您的同事会认为您有疑问！

如果您急于发布任务，并且知道以后需要完成某些功能，则不必花时间在项目管理系统中设置任务。最好在代码注释中直接做一个注释，不要告诉任何人。因此，追上技术债务将变得更加有趣。会有很多这样的感觉，您仍然非常需要该项目。

在项目存储库中保留不超过一半的文件！难怪世界上发明了这么多不同的存储位置。重要的是，将其余文件均匀地放在员工的个人存储库与文档之间（例如，对于当前项目不一定如此）。因此，有关该项目的“秘密知识”将在团队中平均分配，每个人都是无可替代的。然后该项目的一些新来者会来，并在已经实施的项目中迅速解决。您在他们的地方无法抗拒的东西-每个人都会立即被便宜的琼斯所取代。

每个项目都应具有从嘴传到嘴的秘密知识。只有这样，您才能长叹一口气，然后吐口水说：“哦，这些六月工作了一个星期，但他们对项目一无所知。退后一步，自己动手！”

如果您承诺执行Jira的任何任务，则绝对没有必要标记它。我们只是媒介-我们会猜测您现在正在做什么，但同时我们也会猜测项目的当前状态。顺便说一句，我们可以用所花费的时间来做到这一点-我们不必在任何地方写任何东西，我们将找出工作时间并计算您的工资。

关于项目的沟通...

您听说过全渠道吗？最新趋势是不分渠道进行交流。成为潮流！如有任何疑问，请将PM写给某些使者，最好是个人，而不是工作人员-这样他就知道您并没有落后于这个世界的最新趋势。但是Slack和其他Messenger的项目团队最适合与猫和个人对话发送有趣的图片。

参加例会15-20分钟，要迟到。更好的是，远离工作场所使用苏联时代的麦克风和Wi-Fi。让每个人都听您的嘶哑，就像抽象画一样-每个人都能听到他想听的东西。在Daily上，您可以提出关于项目的所有问题。如果没有足够的设计问题，请添加更多offtopic。最糟糕的是，您总是可以提出抽象的问题。这样一个很好的例子最好地反映了为什么您不喜欢打电话以及为什么最好不参加会议。

好吧，不要忘记，每个人的脑海中都有高速蓝牙。因此，如果您已经想到了脑海中的一切，那么只需转移这张照片即可。言语只能解释图片中看不到的小细节。让他们尝试了解您，这是他们的工作。

顺便说一句，如果您在我们的领土上工作，值得迟到办公室。这是给您留下重要印象的唯一方法。永远不要警告迟到。这将表明您很着急，即破坏您的镇定大师形象。

如果您离开工作场所，则不必担心Slack或其他即时通讯程序中的状态安排。任何在您不在的情况下写信（并发出通知）的人都将给出一个漫长而深思熟虑的诅咒，理由是您在自己的私人时间里分心。您还能在哪里找到这样的原因？并让经理和同事在您的正式工作日开始之前学习积累他们的快速问题（当天将要讨论的事情）。

经验交流是多余的。因此，如果您仍在Slack中将任何文章或框架的链接发布到“教育”频道，则无需对其进行任何描述。让它成为对同事的追求。他们需要新知识-让他们紧张并了解您向他们扔了什么。没关系，这可能不是他们的专长。绝不要分享您的项目观察，有趣的决策，错误和有益的结论。开发人员到开发人员的狼。您必须竞争，而不要发展共同的团队经验！是的，我差点忘了！如果您发现一篇冗长的文章，则不要自己阅读，只需将其布置给您的同事，也许他们会感兴趣的。

同伴开发人员的工作可以而且应该受到批评。您必须发现每件事的缺点。只是不要混淆批评和评论。有必要进行广泛且有品位的批评（最好是尽可能抽象的，例如：“您的代码很糟糕”），但是要尽快进行审核-单击绿色的选中标记而不查看代码，也不要留下任何评论。然后，必须提出一些不满意的建设性理由。

将您的动力和高级培训的全部责任移交给我们。我们已经在为您休息，甚至是来自各个度假胜地的头盔照片。让我们也为您自己提供动力。显然，在项目中，所有任务都很有趣，只有出于危害，我们才能为您找到例行程序。而且我们有计划地安排紧急起飞，因为您在这种模式下工作得更好。但是，我们也不会出于有害目的而使您注册课程。您通过内置在您大脑中的蓝牙将所有需求转移给我们，我们会收到它们，但是会忽略它们。无论如何，我们都无法将它们变成文字。

在项目即将结束时...

当我们要求您向客户展示项目时，无论如何都不要提前准备演示。每个人都很清楚：如果项目是在笔记本电脑上启动的，则意味着该项目可以100％正常运行，并且可以在任何地方启动。我们都很幸运！

根据演示的结果，如果客户不满意，您会感到迫在眉睫，则必须将客户送入地狱。他只是什么都不懂。无需通知经理。顺便说一句，与客户发生冲突是要求我们提供更多资金的最佳理由。我们很乐意同意！

发行日期是虚构的。我们只是喜欢在日历上标记这些日期。实际上，管理人员，尤其是远程管理人员，确实缺乏沟通。推迟发布日期是快速召开3-5次会议的最佳方法，人们不会拒绝参加会议。

当该项目的局势升温时，该消除有关一切即将崩溃的传言的时候了。将尽可能多的同事投入到您的假设中，扩大负面影响。如果谣言是正当的，它们的散布就会促使我们用魔杖的浪潮来纠正这种情况。如果没有充分理由，我们很高兴您的身体还不错。

顺便说一句，如果谣言无济于事，开始在合唱团中感到恐慌。这是最具建设性的解决方案。此时，您不仅可以在公司内部而且可以在公司外部（例如，在采访中）开始谈论有关公司的令人讨厌的事情。这无疑将有助于平衡财务状况，并在自己的同事中树立坚强的同事！

在项目结束时，您可以大声，有效地离开它，明确说明离职的原因是薪水太低，尽管您从事该项目已经很多年了，并且为了我们的利益，不要接触新技术。随时去竞争者那里，他们将不胜感激。我们最喜欢的任务是在发布前一周搜索新专家。当您前往另一家公司时，请不要忘记我们。

告诉每个人问题的一方面。对您的“漏洞”保持沉默，告诉我们哪些经理不公平。告诉外人，不要试图了解我们。 NDA想出了wards夫！

如果该项目无法投入生产，则应仅在万不得已时报告所有陷阱。当团队在重要发布或已经投入生产的前一天晚上联合“扑灭大火”时，这是最好的团队建设。不要剥夺自己和团队的这种乐趣！

如果您仍然在团队中经历过发布并且出了点问题，则可以安全地将错误放入生产队列中。他们应该和其他所有人一样享有同等的优先权。让他们排队！

好吧，并且知道在开发人员被任命为服务站的那个晚上，他就发生了深深的变态。他忘记了开发人员的所有需求，变得目光短浅，专制，愚蠢且难以接近。因此，我们-经理，经理和服务站-对开发人员了解得很少。

文章作者：Eugene Wetsel（意象）

PS和上次一样，我的故事与现实只有巧合。道德是这样的：让我们考虑所有这些讽刺，在团队中建立关系。

PPS我们在多个Runet网站上发表文章。订阅我们在VK，FB，Instagram或Telegram频道上的页面，以了解我们所有的出版物和其他Maxilect新闻。