现在有3个主要错误。 如果一遍又一遍地做，恐怕您可能会从一个年轻的PO担任前PO的角色。 从
这里开始。
8. 您不能解雇开发团队中的任何人否则整个团队都会被挫败是的，按照该流派的经典，Scrum团队是自组织的，您坐在“宝座”上，优先处理积压工作。 无论如何
实际上，一个自组织的团队不怕讨论问题，诚实地向团队的另一位成员说：“实际上，我们不会在这里聊天”。 例如，如果一个人出现在团队中-一个拖延症患者，他们会进行回顾性讨论，然后意识到“这将行不通”，并用“
This is Sparta ”字样……向他说再见。 （我什至不知道如何继续在这样的团队中工作：）
RO-他是预算的经理，所有者，因此，如果他不投入“自组织”团队的事务并且不监视其“健康状况”，那么这样的故事就不可能圆满结束。 您和团队尝试了不同的方法，但这没有帮助吗？ 然后解雇，警告和所有这些都是您的责任范围。 尽管最佳实践表明团队应该做出这样的决定，但是很少有这样的事情发展到这种心理上的互动水平。
我想谈谈我的实践中的两个案例。 我们的团队有2个不错的例子。
- 第一个例子。 被迫 。 开发人员参与了规划，讨论了功能，得到了支持，被砍伐了，然后他会说：“伙计们，我接受了2个月的培训。” 他回来了，又转了一圈。 但是团队本身什么也没告诉他，不愿意，也保持沉默，并且部分工作停止了，整个团队都完成了计划中的任务，当然，没有太多时间。 我看了很长时间，与开发人员交谈，结果，我们向他告别。 所有人的健康状况都没有发生变化，每个人都说：“是的，正确的决定，但是总的来说，像整个团队一样做出这样的决定会很好”（成熟：）。
- 第二个例子 。 积极的 。 开发人员遭受拖延，目前还不清楚他在做什么。 但是在回顾赛中，团队表示这不好，他们描述了自己团队中此人的利弊。 你知道吗？ 我们意识到我们根本不了解彼此。 开发人员开始以不同的方式工作，他管理很多，写得更好。 那足够复古了。 因此，有时候，如果有一个优秀的Scrum管理员可以帮助开始交谈，那么团队的启发也会来临。
9.任何业务都必须完成。不，没有。 通常，在产品开发中需要完成极为罕见的事情。 当然，如果正确地定义了这个末尾:)
例如，您想出了一个功能，对其撒谎，她生活在想象中，原型很漂亮，并且她的按钮也带有白色边框的蓝色。 幸运的是，有一个拯救生命的MVP不会让您做任何多余的事情。 客户首先会收到最必要的东西，然后才是必要的东西，然后是额外的东西，有时只有灵魂的东西。
许多PO初学者担心他们没有做任何想法（史诗般的），这种感觉使他们执行的任务带来的价值不高，但却花费了大量资源，同时客户会遭受一个问题，即您可能很快然后决定。
关闭完美主义者，一段时间后会感觉很好。 有时候客户会非常满意的，并且有可能在积压订单的末尾完成所有任务（尽管我本人还没有进入产品开发的这个阶段，但是了解这一点有助于轻松地做出决定）。
如果任务具有准确描述的用户故事，则这种方法将自行工作，我将画出它的外观：
10.工作，害怕失去工作您来到新公司/创办了一家初创公司，但同时您也根据过去的经验工作并做出决定。 在新的现实中，肯定会有人/规则/意见会告诉您，这里“
不可能 ”，但是“
不被接受 ”，“根本
不说这个词”。 这成为对产品的人为限制；它通常仅基于推测，主观意见和对他人的恐惧。 但是您不知道这一点，而是在您的产品周围建造混凝土墙，这些墙不允许他开发。
一个例子。 我们的团队花了六个月的时间没有使用该产品的服务器，因为“这样的规则-这里的每个人都在等待一台服务器六个月”，其成本与Ferrari F60 America类似，并且禁止云托管。 好吧，等等-桌子下面的服务器还不错。
抓住机会，尝试一下。 没锻炼吗？ 再试一次！ 或事实证明您不必建造混凝土墙或将其破坏，或者可能发生的最糟糕的事情是，您将发现拆除它确实是不可能的。 但是，在此过程中，您将尽可能地找出问题的背景，并找到更多的解决方案。 是的，很可能会因为尝试破坏无法打破的事物而激怒某人。 没有人会因为尝试为产品和公司尽一切可能而惩罚您，甚至更多，因此他们不会解雇您:)前三遍-当然。 第四，虽然有可能，但您已竭尽所能。
顺便说一下，现在我们托管在云中，并在1分钟内以我们认为必要的数量部署了虚拟机。 而且我还在这里工作:)