神话神话人月
已发表: 2022-03-10作为一家科技公司的产品负责人，我是一个无底洞的需求。 作为 Mailchimp 的首席产品官，我的工作是将产品推向市场，从而在竞争激烈的领域中获胜。 Mailchimp 的抱负很高，要实现这些抱负，我们需要向市场提供大量产品。 通常对公司的许多人来说，感觉我们做得太多了。 我们总是处于车轮脱落的边缘。
当你做的太多而你决定做更多的事情时，你将不可避免地开始听到提到的神话人月。 这就像一个减压球，如果你挤压一端，另一端就会弹出神话人物月。
这本书由 Frederick Brooks 于 1975 年出版（你还记得 1975 年，对吗？当软件开发 100% 类似于 2020 年的软件开发时？），这本书在软件工程师中相当有名。 具体来说，整本书中有一点很有名（如果他们读过这本书，我不相信人们会读到这一点）：
“......增加更多的人会延长而不是缩短时间表。”
轻松修复。 从现在开始，我只会让女性参与项目（参见国王归来和与安格玛巫王的战斗）。
但是让我们假设 Brooks 的观点与所讨论的软件工程师的性别认同无关。 重点是：具有许多复杂的相互依赖关系的软件很难构建。 每个人都需要共同努力来完成它。
当我将人员添加到团队中时，他们需要加入并移植到项目中。 总得有人为他们安排合适的工作。 团队必须进行沟通以确保他们的所有东西都能协同工作，并且每个额外的人都会以几何方式增加沟通的复杂性。 在某些时候，增加人员会成为项目的负担，而不是好处。
这是书中说明这一点的图表：
这绝对是一个公平的观点。 这就是为什么我在工作中经常听到它。 筋疲力尽的个人贡献者和筋疲力尽的领导者都会把它扔掉——我们不能走得更快，我们不能做得更多，停止招聘，阅读The Mythical Man-Month并绝望！ 唯一的解决方案显然是停止增长并终止一些项目。
当我作为 CPO 说：“我们要做这件事！” 回答通常是，“好吧，那我们要杀什么？” 神话人月将产品开发变成了一场零和游戏。 如果我们想要一件事，就必须阻止另一件事。 现在，这是一个真正的神话，我称之为废话。
考虑到其病态的误解（我们会得出这个结论），这本书显然说最快的科技公司是雇佣全部四个人的公司——显然是四个人。 更多的只是减慢这一切。 有人应该向亚马逊、苹果和谷歌发送这本书的副本，这样他们就可以修复明显臃肿的组织。
这种方法的唯一问题是，在竞争日益激烈、迭代和执行的空间中——仅仅阻碍了组织的增长——编辑和集中工作负载以匹配可能会导致灭绝。 你会更清醒，压力更小——直到你失业。
作为我公司产品管理的负责人，我对这种放慢速度和专注的需要并不同情。 我们必须毫不留情地优先考虑！ 毫无疑问。 但是运行产品是一种矛盾的练习。 我必须优先考虑我已经完成的工作，同时计划完成更多工作。 但是面对神话中的人月我该怎么办？
令人惊讶的是，这个问题的答案来自布鲁克斯的同一本书。 这是同一章中的另一个图表：
在扩展产品开发方面存在一场战斗。 如果您尝试完成的工作是完全可分区的，那么请继续添加人员！ 如果您的工作都是相互关联的，那么在某些时候添加人员就是错误的。
如果有人说我绝对必须终止一个项目才能开始另一个项目，事实并非如此。 如果这两个项目需要很少的沟通和协调，那么我们可以缩小规模。
这就是为什么在 CPU 中添加内核可以将您的计算机或手机的体验速度提高到一定程度——工程师应该知道的一切。 当然，添加内核不会帮助我完成复杂的单线程计算。 但它可能会帮助我运行一堆独立的任务。
产品经理在扩展和无情的优先级之间的冲突可以得到管理。
- 你无情地优先考虑单线程的地方（比如说产品团队的积压工作）。
- 您可以通过添加更多内核来处理独立工作来进行扩展。
然而，很少有任何事情完全独立于公司的其他一切。 至少，您的公司将集中支持功能（全球 IT、法律、人力资源等），从而导致瓶颈。
一切都与依赖管理有关
产品主管的工作不仅变成了制定战略，而且通过确保吞吐量和尽可能降低相互依赖风险以最大化客户和业务价值的方式执行。 “尽可能”是这里的关键。 这样，您可以使公司看起来更像后者而不是前者。 相互依赖是一种无法治愈的疾病，但可以通过多种治疗方法来控制其症状。
一种解决方案是为公司制定战略方向，通过精心挑选的举措组合最大限度地减少或限制依赖性。 有趣的是，很多人会反对这一点。 假设我有两种选择，一种是我可以执行几乎没有协调的项目 A、B 和 C（假设它们影响不同的产品），另一种选择是具有大量相互依赖的项目 D1、D2 和 D3（假设它们都影响同一个产品）。 通常情况下，神话人月将针对前一个计划而不是后者被调用。 因为在纸上看起来更多。
确实，它不那么“专注”。 但是，从依赖的角度来看，它实际上并不那么困难，因此增加人员会更好。
请记住，我并不是说要为不相关的公司选择一堆工作。 Mailchimp 不会很快制造微波炉。 所有工作都应该朝着同一个长期方向发展。 这种方法会增加客户体验风险（我们将在后面讨论）以及客户研究等全球职能部门的负担。 请注意这一点。
另一种处理方法是创建一个产品和程序管理流程，以便在必要时促进依赖关系协调和沟通，而不会使团队在不需要时的协调负担过重。 有时在尝试管理协调以便我们可以做更多事情时，我们最终会创建如此繁重的流程，以至于我们最终做得更少。 这是在协调太少导致碎片无法互操作和协调太多导致碎片永远无法构建之间的平衡，因为我们都在永远站立。
Mythical Man-Month中的论点是，当您将人员添加到软件项目中时，沟通需要以几何级数增加。 例如，如果项目中有 3 个人，那就是 3 条沟通渠道。 但如果你有 4 条，那就是 6 条通信线路。 在这种情况下，一个额外的人会导致双倍的沟通！ 乐趣。 （当然，这是对软件开发项目沟通的过度简化。）
不同的人有不同的角色，因此获得不同程度的自主权。 也许项目经理需要与团队中的每个人沟通。 但是开发 API 的工程师需要与产品营销人员沟通吗？ 还是营销人员可以直接通过产品经理？ 一个好的流程和会议节奏可以消除不必要的沟通和会议。 关键是布鲁克斯的互通公式是协调的上限，而不是死刑。
最后，使用工具、原则和框架结合独立工作而不是实际协作来对抗相互依赖症状。 例如，如果我可以协调两个团队的关键绩效指标（KPI，即成功的衡量标准）来激励或多或少相同方向的运动，那么他们的独立工作更有可能最终“更紧密地联系在一起”，而不是如果他们的 KPI 激励正交运动。 这并不能确保事情完美地结合在一起，只是为了让它们在未来结合在一起，我需要做的工作比其他情况下要少。 其他示例可能包括使用“均匀”语句、设计系统和自动化测试。
所以有一个开始。 但是相互依赖在代码之外还有很多形式。 让我举一个 Mailchimp 的例子。
客户体验风险：防火墙工作的隐藏（但可以接受？）成本
由于 Mailchimp 的客户通常是营销新手的小企业主（全球有数百万小企业主转变为营销人员），因此我们必须提供无缝且可立即理解的端到端体验。 我们无法像企业玩家那样通过收购来组装弗兰肯斯坦的云怪物。 我们不能用顾问和客户经理来掩盖集成不良的软件。
作为消费产品（想想 Instagram 或 Nintendo Switch 或 Roomba），我们必须开箱即用。 对于一个旨在为您的业务提供动力的一体化营销平台，这很难！ 这意味着 Mailchimp 构建的每一件事都必须从体验的角度无缝连接。
但是，完美划分项目会带来经验风险。 并不是说代码不能独立编写。 这是可以实现的，但仍然存在产品看起来像是由不同团队构建的风险，并且这种体验可能会让用户感到非常困惑。 我们违反了康威定律——我们的客户可以知道一个团队的工作在哪里结束，而另一个团队的工作从哪里开始。
因此，您尝试将每个人的工作联系在一起——不仅在后端，也在前端。 在生态系统时代，以苹果等公司的卓越客户体验为主导，这几乎已成为消费领域的赌注。 但这是一个神话般的人月噩梦，虽然这次不是从工程的角度来看。 这是从服务设计的角度来看的。 随着我们在所有这些“端到端”连接的工作中增加更多的人，一切都变慢了协作爬行。
除了我上面提到的第三个修复之外，使用工具和框架而不是过度观察者和阶段闸门，还有另一个释放阀：做出一些慎重的客户体验权衡。 具体来说，我们在哪里可以轻松地发布与其他体验脱节的体验（即低于标准的体验）？ 接受风险并继续前进是产品负责人的工作。 因此，您使用一些标准对其进行分类（也许它不会将应用程序的新的、低流量的区域与您的“摇钱树”保持相同的体验标准），并做出决定（例如迭代和学习对相邻区域的优化）创新）。 当然，这超出了设计范围。
您始终可以通过选择防火墙来缩短布鲁克斯定律，包括在完美世界中不应设置防火墙的工作！
“
我将通过说我构建的软件不会杀死任何人来警告这一点。 如果我正在制造医疗设备，我不会提倡这种方法。 但是在一家营销软件公司，我可以故意隔离团队，因为我知道我增加了不兼容的可能性，作为扩大人员规模和加快行动速度的权衡。
我很遗憾地承认，在我的公司里，神话般的人月是一个现实，我也怀疑在你的公司里。 但它是可控的——这是底线。 并行化和依赖性缓解为我们提供了一条限制神话人月的近乎神话状态的出路。 因此，下一次在您的公司提出明显的二分法时（扩大规模以放慢速度或放弃您的抱负）请记住，如果您对如何安排工作很聪明，您仍然可以发展壮大。
不要忘记缩放的较软的一面
请记住，管理神话人月不会阻止工程师像黑魔法一样调用它。 他们之所以援引这一原则，不仅是因为其中有一些道理，而且因为从情感和认知的角度来看，缩放（总是）很糟糕。 如果我认为编写代码和解决客户问题是有报酬的，那么我最不想做的就是改变我的日常工作并弄清楚如何与新人和更大的团队合作。
当你扩展你的公司时，记住要理解扩展和改变的痛苦。 从信任和文化的角度来看，即使增加一个成员的团队也会成为一个全新的团队。 人们厌倦了这种变化。 这意味着当你开始管理和缓解神话般的人月时，你需要管理围绕增长的情绪。 这也许是最关键的任务。
团队本身对神话人月的坚定信念可以将其结论变为现实。 这基本上相当于彼得潘的飞行信念。 如果团队认为扩展会减慢他们的速度并且他们不接受这种变化，那么他们确实会放慢速度。
因此，当您努力管理依赖项并引入有助于扩展的工具时，请确保您清楚地传达实践背后的原因。 让人们参与选择减轻人月问题的工作和流程，因为当他们参与变革并且他们的前景发生变化时，突然扩展至少在文化上成为可能。