💛 🏤 🔱 团队负责人如何评估项目 🍌 🤪 🖐🏼

Timlids经常重视项目，但并不是每个人都做得很好。这在很大程度上取决于团队负责人本人的个性以及他对团队的了解。从“通过类比”方法到PERT，有许多评估项目的技术。但是今天，我将讨论如何使用计划扑克和其他技术来更准确地评估并带来更大的收益。

在讨论具体方法之前，有必要详细介绍该过程的主要困难。

评估始终有两个方面：团队和客户。在他们之间，团队负责人或经理被迫寻求对立利益的平衡。高估估算是不可能的，因为客户将拒绝支付更多。低估也不值得。在这种情况下，您将不得不违背团队的步伐，冒着过度疲劳，倦怠以及代码未经检查就投入生产的风险。

评价任务研究的深度是一个哲学问题。任务可以讨论很长时间，然后整个冲刺的评估将被延迟。但是，如果您不深入研究本质，则可能会错过一些会影响截止日期的重要事项。

弱者和强者的行为方式不同。如果强大的开发人员喜欢这项任务，那么弱者将无法按时完成任务。相反，强者将使任务比弱者更快地完成任务。考虑到工作速度的差异，评估中可能会出现不同的“社会”错误，例如，弱者会在什么时候“窥视”强者评估任务的时间，并设置相同的截止日期，以免解释为什么他的“评估”会更长：他打电话给周，我能不能说要三点？我会说至少一个半……”。

当整个团队参与评估时，所谓的计划扑克有助于解决此问题，因为他们不知道任务将是谁，并且他们盲目地评估了任务，而看不到同事提供了什么。

作者：Hkniberg，来自英语维基百科-从en.wikipedia移至Wikimedia Commons。公共领域每个人都

在脑海中扫描一项任务。如果团队成员陈述的术语非常不同，则讨论开始。在这些时候，通常结果是，团队没有注意到必须作为任务的一部分实施的任何功能。此后，每个人都会重新投票。然后没有人声称有人估计错了-每个人都参加了。即使存在错误，也没有人会浪费时间去寻找有罪感的东西，关于哪些新因素已经出现并改变了一致性（以及将来如何考虑它们）的讨论将更具建设性（我在上一篇文章中对此进行了论述）第5段）。

对项目进行更准确的评估有助于向客户提出其他问题。但是在这里您可以轻易走得太远。某些开发人员之所以要求评估，并不是因为他们用大量的澄清信件轰炸了客户。从客户关系的角度来看，最好将其他问题的数量减到最少，这会增加任务的不确定性。

有关如何避免错误的一些提示

为了尽量减少评估中的错误，我遵循一些简单的规则。

在阅读ToR之前，我会先与客户进行介绍性通话。在这次电话会议上，我请您从宏观角度讨论问题：谁将是最终用户，他们将如何应用结果，将涉及哪些设备（具有此类权限），后端（如果已经存在）如何？之后，您可以开始阅读TK。

阅读ToR，我为客户列出了一系列问题。在研究任务时，您应该尝试对整个项目进行“编码”-想象一下它的外观。问题清单应确保在收到答案后可以进行可靠的评估。
这里的主要思想是问题不应逐步提出，而应一次提出。通常，最好准备一份准备好的问题清单，以免拉长信件的对应关系。尽管如此，文本传达的信息要少得多。在通话中，如果可以澄清情况，则可以在屏幕上翻阅。

如果由于某些原因无法打电话，我正在寻找Google文档，我将在其中添加这些问题，客户会在时间到时回答。与个人聊天或邮件相比，这是在任务上进行交流的更有效方式。随后可以将该文档发送给将参与该项目的开发人员-他们不必再次提出相同的问题。

顺便说一句，希望项目负责人回答客户方面的问题，而不是仅仅扮演受损电话角色的前董事秘书。这将减少项目参数在运行期间直接更改的风险。

如果可能，我将开发人员带到该领域。了解产品在现实中的使用方式有助于点“和”并提高得分。例如，正在开发用于收银机的软件。而且您的开发人员已经坐在计算机上15年了，他们没有看到收银台。您将他们带给最终用户，要求在某处而不是在该商店进行购买。他们看到玛莎姨妈坐在那里，她用手指同时按下两个按钮，无法辨认出显示器玻璃上的字母。结果，有关项目的许多问题都自行消失了-字体变大，增加了操作确认。很难想象我会想到这样的事情。通过个人访问获得的真实感将为开发人员再加油一年。
不幸的是，不可能在所有项目中都沉浸其中。

如果条件为“和” /“或”，我不会评估任务。例如，如果建议“进行授权和注册”。将这一点分解为两个任务并分别评估每个任务是没有问题的。这样的评估将更加准确，因为您不会混合使用相似但又不同的实体。分解越好，结果越准确。

“或”甚至更糟，它始终与模糊的TK相同，因此无法建立准确的估计。是否有必要通过社交网络进行授权？如果后端有一些特定的API怎么办？如果您不了解详细信息，则根本无法给出准确的评估。

图片：Michael Dubakov @中

无法完成该任务的40小时评估。这是先前规则的另一个变体。敏捷建议将项目分解为不超过20小时的任务。一个星期的工作不应有不可分割的任务。在很小的一部分中，估计更为准确。

分解任务时，我尝试记录它。它从两个角度同时有用。

首先，它简化了过程。一旦您开始写下有关给定主题的想法，大脑就会乐在其中。顺便说一句，这就是为什么我不建议将分解与估计混合使用的原因，即选择一个任务并立即评估每个任务。最好将整个项目分解成多个组件，对其进行修复，然后立即对其进行评估，以免使您的头脑立即处于两种模式。

其次，分解的“对数”有助于解释未来估计与现实之间可能存在的差异。实际上，您对正在形成的任务有完整的描述-您考虑了哪些选项。例如，您通过登录名和密码以及令牌，令牌续签等考虑了授权，事实证明，客户仍然希望通过社交网络进行授权，只是没有写过。您的“日志”分解将有助于保护团队免受声称您赞赏某事但未按时完成的索赔。

我教团队不要在完成相关任务之前就抓住它们。开发人员将大量时间花在其他功能上。他们会进行授权，因为他们认为需要在某处修复某些东西，并深入研究此副过程。我尝试提出一个反思：我看到了一个伴随的任务-形成一张单独的票。您甚至不必通过团队负责人或经理来运行任务。团队负责人分析任务时，他自己将看到任务并将其发送出去以进行必要的工作。因此，您不必让任何人下班（创建任务并忘了它），并且可以确保评估的准确性。

我正在花时间进行测试。在评估时，许多人会忘记测试人员。但是实际上，任何一项任务，特别是一项艰巨的任务，都必须由在世人员进行测试-他们应该考虑一下，寻找错误。如果他们发现了什么，则错误将归因于已经设法切换到不同上下文的开发人员。他们将不得不再次潜入这个话题。并且此循环可以重复多次。
必须安排测试时间。通常，此评估与开发人员所说的分开进行。

我考虑了结对编程的时间和这项工作的其他功能。结对编程有助于交流经验并激励开发人员。他们坐在一起或在屏幕上翻找，讨论任务和使用的工具，并依次进行一些更改。这种方法为团队带来了回报，但是从客户的角度来看，任务执行的速度不会快两倍。在我工作过的项目中，我们没有经常练习结对编程，但是有些任务很方便做到这一点。我们在评估阶段已考虑到这一点。

同样，您需要花时间向客户进行演示，打电话，来信等。通常，为了适应评估，开发人员必须高效地工作，为此，他需要获得充足的睡眠，正常休息（而不是整个团队在周末的值班时间），并且不能使工作越来越快。因此，评估应始终基于实际的工作实践，而不是基于乐观的预测，即我们将坐下来并“在三年内制定五年计划”。

我正在花时间计算项目。展位分为四种类型：开发，测试，预生产和生产。最好在项目开始时部署这些展台，然后立即放下。如果不这样做，开发，测试和部署的同步将被中断，这可能会变成现实。

我不会从上面和下面进行评估-我称之为特定术语。根据营销规则，当开发人员说“从4到12个小时”时，他的意思是“比12个小时快”。客户听到“ 4小时”。如果任务在11日完成，则开发人员将认为一切都很好，并且客户将不满意。即使任务在4小时15分钟内完成，客户也会感到不满意。因此，即使在团队（公司）内部以最小和最大期限来绘制标签，然后计算平均值（这种方法有一定意义），也只会将最终结果显示给客户。

我只以小时为单位命名日期，而不是以天或月为单位。许多人认为，如果该项目预计耗时96个小时，那么只要只有一个人在上面工作，它将在12天内完成8个小时。这种情况很容易推断给两名开发人员，命名为6天。但是这是错误的。有许多任务相互依赖。首先，开发人员无法开始工作，直到使用所有装配系统和机架创建了项目模板（并且根据客户的意愿创建了2-3天）。其次，当有计划要求时，一切都停止了。第三，有一些阻止您继续前进的错误。换句话说，在工作场所工作96个小时并不意味着100％的时间（每天8个小时）专门用于这些任务。为了在几天之内进行评估，我们可以假设开发者还没有8位，但是，每天6个工作小时（实际数字必须根据实际情况确定）。

我总是问开发人员从计算机上需要花费几个小时的时间（而不是“准备完成需要多长时间”）。这是上一段的结果。与团队互动是评估的一部分，正确提出问题很重要。

我考虑了“团队系数”。通常，昨天的前辈去看提姆犬。他们会根据自己的经验来评估任务，即使他们在团队中处于中间位置。也许长者的工作速度并不快，但是在他之后，几乎没有bug。中间不是这样的素质。因此，在敏捷中存在所谓的“团队系数”，它表明了评估者的乐观态度与特定团队的现实生活之间的差异。它仅在实践中计算：将最后一次冲刺的理论估算值与实际估算值进行比较。团队负责人对团队的了解越多（他对评估的了解就越好），该系数越接近1。

其中，“团队系数”在评估时还考虑了所谓的“开发人员的乐观主义”。总是根据没有错误，饱腹感和表演者的良好心情，环境中没有问题来评估任务。但是现实充斥着突发事件，没有办法保护自己免受这种情况的侵害。在合理的时间段内计算出的“团队比率”可以考虑到这一点。

试图施加团队的影响力，有时在内部评估中，他们从几个小时到故事的重点。他们知道任务将花费8个故事点，因此回想上周1个故事点需要花费8个小时。据此预测劳动力成本。但是，我几个小时就能想到。

我不会引入额外的因素，以免使其他参与者混淆。我经常看到人们在团队级别进行评估，并为此讨价还价。但是评估部门不应储备这些库存或考虑其他无关紧要的东西。事实证明，开发人员在8点钟为任务评分，但保真度乘以2，蒂姆利德再次将评分提高了一倍，以适应团队。而32个小时的经理为客户赚了40个小时（对于一个均匀的帐户，或者仅仅为了讨价还价的目标就是30个小时）。这更像是咖啡渣上的算命。是的，客户看到一个8个小时的任务估计需要40个小时，将决定团队不知道如何做。

如上所述，在团队级别，您只需要考虑团队本身的功能，就谁在评估中施加不可抗力达成共识（并且应该在其中考虑到这一点，因为我们总是评估任务，假设代码编辑者不要求许可证，开发人员不要请病假等）。

坚定捍卫评估的立场。上一段的推论-我始终坚持我的评估。如果我知道该项目将进行6个月，并且他们希望我进行3个月的评估，那么我绝不会说4个月来“请”客户或经理。
应该注意的是，有时会有内部讨价还价。当您知道该项目应该为新年做好准备时，您会不自觉地开始使用评估结果，以应付剩余时间。大脑将这些东西完美地激发出来。即使那里有200个子任务的列表，它们也将以除夕夜的方式收敛。

尽管如此，我已准备好更改评估。这是正常的-项目在进行中，在进行中。形成任何评估，我都知道这是该项目在特定时间的特征。

最后的分词是：不要强迫未按时完成的开发人员就此主题写给经理人长信。首先，他们可能会害羞。其次，经理可能会问一些问题，并再次分散注意力。第三，他的解释信只会在信件中丢失。我通常会要求您对Jira中的任务发表评论。没有活人（经理）的参与，通常会更简单，更快。在汇报过程中很容易找到。还有timlidu plus-所有超出标准的任务都会被评论。同样，研究错误以提高将来的评估质量。

文章的作者：Eugene Wetzel（@imater）

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

团队负责人如何评估项目

有关如何避免错误的一些提示

More articles: