最近，我看到了许多示例，这些示例表明技术项目经理（又名CTO）如何在项目的开发和管理中遵循货运团队的经验，而不是根据需要引入实体，并根据当前需求，可用资源和技能来构建流程表演者。 我们将讨论如何确定这样的货运专家，以及他们对该项目承担的风险。
每日上午讨论（又名每日站立）
对于一个这样的CTO，我的自然问题是-这次活动的好处有多切实，CTO坦诚地回答-“我也不知道。” 尽管该团队有一些优势，但其中的一部分可以远程进行，但讨论肯定归结为“昨天我写了代码，今天我写了代码，明天我也打算写代码，但是，我仍然纠正了这样的错误”。 结果，我们离团队的每个成员只有半个小时的时间。 远程工作者的一些好处是与团队之间的日常沟通，对于某些情况而言，这很重要。 我认为，这种日常讨论对发展的用处很小，因为这种一般性聚会的主要任务是向所有人提供有关当前发展状况的信息，近期计划（从一周到一个月），以讨论一些有趣的问题。全部。 通常，这样的讨论会渗入到一些对某些人来说很有趣的利基问题的讨论中，而其他人则开始感到无聊，并期待何时结束。 当然，这应该被抑制并在以后以较窄的格式进行讨论。 当前的开发和计划状态非常重要，但是根据团队的工作速度，每周讨论一次甚至更少的讨论就足够了。
云部署
当前，有许多工具可用于以方便的形式描述项目基础结构（服务，网络，依赖项），例如Terraform。 这件事当然是有用的，但是当它变得相当复杂时，例如具有一定的项目规模。 对于大多数初创企业和小型项目而言，这是一种冗余工具，因为基础架构的变化极少，并且需要具有快速部署另一个生产的能力，大致来说，每年一次，许多初创企业可能根本无法生存。 因此，描述的项目越简单-对于许多人来说，更好的Docker Compose就足够了。
单元测试的代码覆盖率
对测试的过度热情导致了这样一个事实，即在其上花费了宝贵的开发资源，大大增加了重构的成本（毕竟，所有受影响的测试都必须重写），并且常常造成代码可靠性和正确操作的幻觉。 我遇到了一家初创公司，经过一年的发展，仅后端就编写了2000多个测试！ 为了有效地进行开发，测试只需要覆盖代码中真正重要的部分，这些部分需要进行一些计算并且很难进行手工错误诊断。 通常，对于初创公司而言，可以将测试覆盖范围延迟到代码结构变得稳定，业务逻辑变得清晰并且不太可能发生重大变化之前。 对于前端单元测试，它们通常无效，因为通常没有足够的复杂计算和算法，因此最好涵盖基本的SPA功能，例如在BlackBox测试阶段通过Selenium等进行按钮按下。
开发过程管理
CTO Cargo信奉者总是使用以前曾经为他工作过的工具和技术，他较早读过一些有趣的东西，或者被告知这些东西。 所有这些在当前条件下的适用性使他难以评估，因此他清楚地遵循了“邪教”的教规-“毕竟，飞机曾经飞过，所以我做对了。 要说服CTO最好在当前项目中使用其他工具和技术会变得艰巨而艰巨，因为CTO并不习惯于分析后果。
团队管理
货运信奉者有一种方法，他遵循。 团队管理需要根据项目的当前状态，承包商的要求，资格和局限性而建立，这对他来说是陌生的，他对此并不重视，因为他极有可能无法应对。 他不容易承认对高级和中级开发人员应该有不同的态度，有些开发人员在通信，业务方法和责任方面具有专长。 对他来说，棋盘上的所有棋子都差不多；他的棋子差不多。 他很可能没有听说有必要确定和利用每个开发人员的长处。 因此，团队的工作效率大大降低，开发人员注意到这一点非常好，这使他们对工作的满意度降低了，通常其特点是人员流失率很高。 此类CTO通常会说他们都有Fullstack开发人员，尽管我个人很少见到同样强大的前端和后端开发人员，但需要了解很多技术。
如何不成为/不成为货物信奉者
- 始终采用关键方法介绍新实体（服务，技术）。 如果您的团队中有些人对MySQL非常了解，但还没有使用Postgres，那么选择Postgres没什么意义，如果这样做不能给您带来明显的优势。
- 开发过程必须适应团队和业务。 如果Vasya使用Scrum并通过单元测试涵盖了所有内容，这并不意味着该方法同样适用于您，您应始终严格评估并与其他选项进行比较（瀑布）。 通常，对小型团队有用的东西对大型团队不再有用，反之亦然。
- 确定团队成员的优势并最大程度地利用它们。 这将提高整个团队的效率，并且员工将更快乐，因为他们以更少的精力带来了更多收益。