管理一个小的工程团队-无论是Facebook，Google或AirBnb等大型工程组织中的一个团队，还是整个工程团队-都很难。 为什么？ 因为您的任务是围绕一个共同的愿景协调一组熟练的专业人员：交付复杂的软件。
软件做什么也不重要。 无论是保险评估系统，燃油管理系统，操作系统还是社交媒体平台，您都需要协调复杂产品的创建（和维护）。
结果，需要技能和知识的人才能创建它。 这不是流水线式的操作。 您将与应该（在理想情况下）具有强烈见解，发表意见，挑战想法并在需要时扮演Devil's Advocate的人一起工作。
协调它们，使它们全都围绕产品或服务的需求，将是一项艰巨的任务。 你是怎么做到的？ 您如何使工程团队支持这一愿景并确保他们留在那儿？ 您如何在他们中建立信任，认同，敬业度和专业精神，以便他们想在那里，使他们致力于相同的理想，并坚持到底？
这不是一个容易回答的问题。 许多书籍，书籍和博士学位。 论文已经写在这个主题上。 今天，我将根据自己的经验与您分享一系列的经验教训，当我按时，按预算完成已经成功交付的项目时—是的，有可能！
不过，在我们深入研究之前，可以期望我会与您分享一套工具，方法论和技术实践，这是可以理解的。 尽管这些当然有它们的位置，并且我将介绍一些内容，但是我可以从经验中告诉您，如果这些内容是您的主要重点，那么您将（谚语）手推车放在马的前面。
工具，方法论和技术实践都很棒，但它们是补充。
您正在创造什么文化？
我最自豪地参与的项目是为一家澳大利亚主要保险公司提供的。 IT部门的任务是检修其核心保险索赔软件。
如果您不熟悉，保险理赔软件是呼叫中心员工用来为客户评估最佳保单的软件，无论他们是要制定新保单还是对现有保单进行更改。
无论您是否意识到，您都可能熟悉这种软件。 例如，类似这样的问题可能会响起：
您是介于18-25岁，26-40岁之间吗？ 你抽烟吗？ 您的家人有心脏病相关病史吗？ 等等。
我所在的软件工程团队的任务是通过实施新供应商提供的平台来替换现有系统。 这需要执行两项基本任务：
- 确定现有系统中使用的策略评估问题。
- 在新软件平台中实施这些问题，并根据业务分析师的需要在必要时进行更改。
我不知道能打动您多少工作。 如果您没有参与过这样的操作，那么我将了解您是否不完全了解所需的工作量。
因此，为了帮助说明规模，请考虑整个团队由数据库管理员，系统管理员，业务分析师，索赔评估师，软件开发团队（我是其中的成员）以及一系列其他团队组成。 所有这些团队都由一位出色的项目经理指导，而我的团队则由一位出色的团队负责人领导。
现在我知道这篇文章是关于一个小型工程团队（我们是一个由八人组成的团队）的项目管理的，但是软件工程团队从来都不是一个人工作。 这就是为什么我包括团队的其他成员，以便您欣赏规模并从整体上看情况。
专业文化必不可少
简而言之，我当时最记得的关键要素是项目经理和我的团队领导。 让我们开始讨论项目经理。
他积极创造和培育一种专业的工作文化，每个人都被包括在内，没有人被忽视，每个人的意见都得到了倾听。 但是，尽管听起来如此包容和体贴，但仍然希望您是一名专业人士，成年人和减轻体重的人。
将此与您可能正在或当前正在研究的其他团队进行对比。 在很多情况下，软件工程师被视为可替换的商品。 拿一个， 《神话人月》中的讨论。
弗雷德里克·布鲁克斯（Frederick Brooks）讲述了他的经理们的经验，他们认为，例如，如果5个开发人员可以在6个月内完成一个项目，那么他们可以通过使开发人员数量加倍而将交付时间减半。
或考虑经理人同样不成熟的思想，他们认为，如果一个开发人员在规定的期限内不工作，不能努力工作或交付足够的东西，那么他们可以雇用另一位开发人员，因为他们错误地认为新开发人员可以“仅仅拿起”，另一个则停下来。
我的项目经理在对我们寄予厚望的同时，也产生了一种敬业精神。 必要时，他将为我们捍卫组织的其他成员。 如果您没有为这样的人工作的荣幸，那是一种荣幸。
总而言之，您需要从评估正在创建的文化类型（无论是有意识还是无意）开始。 根据此评估，您将了解要雇用的开发人员的类型。 这就是为什么我说工具，方法论和技术实践是次要的，而不是主要的。
为了使问题成真，如果您要雇用代码猴子，精打细算的人，对组织，产品，服务或其目标没有任何投资的人，那么使用什么工具，方法论，或您使用的技术惯例，或价格昂贵。
如果您有任何机会，那将是纯粹的盲目运气，因为这种开发人员将永远不在乎-这并不完全是他们的责任。
您的团队文化是什么？
首先查看组织的文化，然后查看团队的文化。 是否有利于雇用和保持开发人员所需的质量和奉献水平？ 如果没有，那么就开始进行所需的更改。
你是怎样做的？ 好吧，这很像建立任何其他持续存在的小组。 您需要进行三项关键操作：
- 信任
- 订婚
- 社区
为什么？ 好…
- 如果您不信任他们，为什么他们应该信任您？
- 如果您不关心它们的幸福，如果您将它们视为可以轻松替换的商品，为什么他们会或将积极参与您的愿景？
- 如果没有社区意识，每个团队成员都可以在提出要求时（或在没有要求时）提出自己的意见，并知道他们将被视为专业人士，那么社区就永远不会发展。
- 如果您没有做些小事，例如奖励成功，记住生日和特殊场合（这表明您不仅专注于底线），那么只会激发两件事：恐惧和金钱。
有专业的领导
现在，我将其归结为工程团队。 尽管我们都是专业人士，但来自不同背景，我们的团队领导是团队的关键要素。
他对团队中所有成员的技能和能力都有很好的把握。 他是团队的一员，与团队在同一房间。 他从不与我们分开。 而且，您总是可以接近他。
您可以与他讨论您的挑战和困难，并且知道他会给您一个公正的听证会。 您还知道的是，当需要完成操作时，他会叫您出去。
他的风格是我一直记得的风格。 他没说很多，但是当他说完之后，他就算了。 他是我们中的一员，但他也是老板。 虽然不容易，但是他以最大的专业精神很好地处理了它。
如果项目经理对我们团队或一个人有问题，我们的团队负责人会与他讨论，然后他会与我们讨论。 基于这些性格特征，我们得以继续（通常）自我分配的工作。
这是我们工作得很好的另一个领域。 尽管项目经理将直接向我们分配任务，但它仍然是一个非常民主的系统。 他首先会问谁对某张卡片最感兴趣或最感兴趣。 如果没有人，那么他将分配它。 但是，如果我们自己解决问题，并且他不确定我们是否能完成任务，或者我们是否已经承担过多任务，他会谈论。
热情很高兴，但是请注意，如果您花太多时间而无法完成工作，那将是毫无意义的。 这导致强烈的个人责任感和健康的竞争。
由于这些原因，这位特定的项目经理是团队的出色指南。 我不能很坚定地说他对这个角色的态度有多重要。
使用有效的工具
接下来让我们看一些技巧。 我不会对此过于关注，因为如果我们不谨慎的话，工具通常会成为最终目标。
每日站立
我是敏捷的忠实拥护者，并且每天都做站立运动 。 如果您从未尝试过，或者即使您尝试过，这就是我们所做的。 我们在软件工程室的前面有一块很大的白板，在那块板上有看板 ，就像下面的图片一样。
看板董事会，由https://leankit.com/learn/kanban/kanban-board/提供
- 在最左侧，我们有一组便笺，详细说明了所有尚未开始的工作。
- 在下一个车道中是分配的工作。
- 接下来是正在进行的工作。
- 接下来是测试工作。
- 接下来是质量检查工作。
- 在最后一条车道是已完成的工作。
每天早上，BA（业务分析师），支持人员，软件工程团队和项目经理（可能还会有更多，但随着时间的流逝，我的记忆有些淡淡）聚集在一起。 每人不超过2分钟的时间，我们分别涵盖了三件事：
- 前一天我们做了什么。
- 那天我们要做什么。
- 如果我们被任何东西阻挡。
项目经理会严格控制时间，在必要的时候让人们多说一些话，或者如果站立时间过长，或者谈话需要超过5分钟的时间，则要求站起来后继续对话。说出他们不得不说的话。
这使会议短暂而切题。 每天早晨，没人花超过20分钟的时间来适应之前的24小时。
通过将其作为日常工作，您知道自己必须负责，说出自己做了什么，以及遇到什么困难。 工作无法消失在以太坊中，在任何人都知道发生了什么之前拖了很长时间。
每周回顾
使项目步入正轨的第二项关键技术是每周回顾。 每个星期五早上，同一支团队将聚在一起，我们将就以下方面进行更长久，内容更丰富的讨论：
- 那星期发生了什么事？
- 发生了什么事？
- 正在形成什么问题？
与日常站立类似，这些讨论使您从更广泛的角度了解项目的进展情况。 因为他们是如此包容，而且如此专业，所以我从根本上相信整个团队都有强烈的认同感。 当然，有些人比其他人多，但基本的感觉就在那里。
特别将这两种技术带回工程团队，我们能够克服大多数软件开发团队的核心缺陷之一，那就是团队的工作及其对最终用户的影响之间的脱节。
当然，我们实际上并没有与呼叫中心代理坐下来。 我们与相关团队之间的联系更加紧密。 但是，对于行动所产生的影响，我们始终有着强烈的理解力。 我们可以看到并了解我们所做的工作是否在帮助加快或减慢项目的完成。
那是一个包装
关于管理小型工程团队时如何找到项目管理平衡，我还有很多要说的。 可以运用许多技术，工具和技能来帮助正确地做到这一点。
但是，如果您首先在组织和团队中建立了全面的文化，并在此坚实的基础上使用敏捷的重要方面，例如除了每日回顾外，还要每天站起来，我相信您将要点准备就绪。
据我的经验表明，它不一定要昂贵。 对于它的价值，我们只使用了一块大白板和许多便利贴。 比定期每月订阅便宜。
如果该技术行之有效 ，但是您发现自己需要更多东西，例如软件服务订阅，则可以使用一系列服务之一，包括Leankit ， Atlassian或Kanban Tool 。
此外，以下是进一步阅读的清单，这些清单应该使您对在此基础上进行深入了解：
- 敏捷101（ThoughtWorks）
- 看板的敏捷投资组合计划
- 什么是Scrum？
但是，无论您使用哪种技术，请记住，从根本上讲，这与文化和信任有关。 没有这些，其他所有的东西都是橱窗装饰。
翻译自: https://www.javacodegeeks.com/2018/03/finding-project-management-balance-for-small-engineering-teams.html