oye pandora

by Josh Temple

通过乔什·坦普尔

我尝试了Pandora出色的功能优先级排序方法。 这是我学到的。 (I tried Pandora’s brilliant method for feature prioritization. Here’s what I learned.)

潘多拉(Pandora)的方法和3美元的便签纸如何使利益相关者的管理变得轻而易举。 (How Pandora’s method and a $3 pack of sticky notes made stakeholder management a breeze.)

一军 (Army of one)

Like many data professionals at small and mid-size companies, I’m a data team of one at Milk Bar. As the first data hire, I’ve had the rather terrifying privilege of building our data stack from the ground up. I’ve spent the first few months of my time here building data loaders, modeling our data in BigQuery and dbt, and deploying and training our teams on Looker. Now that our data stack is functional, it’s time to plan for next quarter.

像中小型企业的许多数据专业人员一样，我是Milk Bar的一个数据团队。 作为第一批数据租用者，我享有从头开始构建数据堆栈的相当恐怖的特权。 我花了前几个月的时间在这里构建数据加载器，在BigQuery和dbt中对数据建模，以及在Looker上部署和培训我们的团队。 现在我们的数据堆栈已经可以使用了，是时候为下一个季度进行计划了。

The value of business intelligence and analytics is quickly becoming apparent at Milk Bar, and more people are coming to me with feature requests. My backlog is filling up faster than I can knock out features, and I need to be sure that the projects I tackle next quarter are truly essential to the business. I read about Pandora’s product prioritization process a few months ago and I thought it was brilliant, especially for small, resource-strapped teams, so I decided to give it a try.

在Milk Bar上 ，商业智能和分析的价值正在Swift变得明显，并且越来越多的人向我提出功能要求。 我的积压工作要比我淘汰所有功能快的多，我需要确保下个季度处理的项目对业务确实至关重要。 几个月前，我读到有关Pandora产品优先级排序过程的信息，我认为这很棒，特别是对于那些资源匮乏的小型团队来说，所以我决定尝试一下。

潘多拉法 (The Pandora method)

The credit for this system goes to Tom Conrad, 10-year CTO at Pandora, who developed the approach. I encourage you to read this article from First Round Review, which describes Pandora’s process in detail, but I’ll summarize it here:

该系统的功劳归功于Pandora的10年CTO Tom Conrad ，他开发了该方法。 我鼓励您阅读First Round Review的这篇文章 ， 该文章详细介绍了Pandora的过程，但在这里我将对其进行总结：

1. The team leader collects ideas for features that are “no-brainers” from across the company. These aren’t supposed to be flashy, R&D-esque projects — they’re supposed to be ideas that the company would be stupid not to tackle during the next quarter.

   团队负责人收集了整个公司“不费吹灰之力”的功能构想。 这些不应该是华丽的，类似R＆D的项目，应该是他们认为该公司在下个季度不会解决这个愚蠢的想法。

2. Each idea is condensed into a single slide that describes the impact to the business and how success will be measured.
   每个想法都压缩到一张幻灯片中，该幻灯片描述了对业务的影响以及如何衡量成功。
3. Each idea is also assigned a dollar-amount cost based on the estimated amount of engineering time required to build it. Pandora decided that $5 would be equal to one month of one engineer’s time. Since my team is much smaller, my cost ratio was $5 for one day of my core development time.
   根据构想所需的估计工程时间，还为每个构想分配了一笔金额的成本。 潘多拉认为5美元相当于一位工程师一个月的时间。 因为我的团队要小得多，所以我的核心开发时间一天的成本比是5美元。
4. The team leader holds a meeting with relevant decision makers. Conrad recommends that you choose leaders who aren’t too tied to one function and understand company-wide priorities, like the CEO and CFO.
   团队负责人与相关决策者举行会议。 康拉德(Conrad)建议您选择不太依赖某个职能并了解公司范围内优先事项的领导者，例如首席执行官和首席财务官。
5. The team leader talks through each feature and answers questions, then tapes a printout of each slide to the wall. The team leader divides the total “budget” of the team’s time among the decision makers in the form of sticky notes — each sticky note representing $5.
   团队负责人讨论每项功能并回答问题，然后将每张幻灯片的打印内容粘贴到墙上。 团队负责人将团队时间的总“预算”以便签的形式分配给决策者，每个便签代表5美元。
6. During the first round, the decision makers vote by placing their $5 sticky notes on the feature slides they want to see funded. Afterwards, they can discuss, negotiate, and shift their dollars around in the second round.
   在第一轮中，决策者通过将5美元的便笺放在他们希望看到获得资助的功能幻灯片上进行投票。 之后，他们可以在第二轮讨论，谈判和转移他们的资金。
7. After some shuffling, the features that remain funded are the features the engineering team is responsible for building the following quarter.
   经过一番改组，剩下的仍是工程团队负责构建下一个季度的功能。

The method is similar to capacity-based planning and borrows from Agile principles like story points and weight. It’s meant to solve the fundamental problem that technology teams are often asked to build many more features than they have time for. Capacity-based planning isn’t a new concept, but this method is special because it forces stakeholders with competing priorities to align on the set of features that is best for the whole business.

该方法类似于基于能力的计划，并且借鉴了诸如故事要点和权重之类的敏捷原则。 这是为了解决一个基本问题，即技术团队经常被要求构建比他们所需要的更多的功能。 基于容量的计划并不是一个新概念，但是这种方法很特殊，因为它迫使具有竞争优先级的利益相关者根据最适合整个企业的功能集进行调整。

我期望和希望发生的事情 (What I expected and hoped to happen)

To use this method at Milk Bar, I needed to determine my total available budget for feature development. Historically, I’ve spent about 20% of my time working on ad-hoc requests, 20% on infrastructure and reliability upgrades, and 60% on core development. With 61 working days in the first quarter of 2019, this meant I would have about 37 days for core development. Using my cost ratio of $5 per day of core development, I calculated a total budget of $185.

要在Milk Bar上使用此方法，我需要确定我用于功能开发的总预算。 从历史上看，我约有20％的时间用于处理临时请求，20％的时间用于基础架构和可靠性升级，而60％的时间用于核心开发。 在2019年第一季度有61个工作日，这意味着我将有大约37天的核心开发时间。 使用我每天进行核心开发所需的成本(5美元)，我得出的总预算为185美元。

I collected about 15 data product feature requests from across the company and from my backlog. These ranged from simple dashboard build-outs ($5, or one day of my time) to entirely new data sources that required extensive ETL and modeling ($65, or almost three weeks of my time). The total cost of all the features was well over $400, more than double my amount of core development time for next quarter. This really drove the point home for me. I hate saying no, but I definitely did not have enough time to build everything I was being asked to build, even if I wanted to! I hoped that clearly showing this gap between demand and capacity would give me ammunition to ask for additional headcount for my team.

我从整个公司和未完成的订单中收集了大约15个数据产品功能请求。 从简单的仪表板构建(5美元，或一天的时间)到需要大量ETL和建模的全新数据源(65美元，或我的时间近三周)，不等。 所有功能的总成本远远超过400美元，是我下一季度核心开发时间的两倍多。 这确实使我明白了这一点。 我讨厌拒绝 ，但是我绝对没有足够的时间来构建我被要求构建的所有东西 ，即使我想这么做 ！ 我希望清楚地显示需求与能力之间的差距将使我有弹药要求我的团队增加人员。

Next, I pared down each feature request into a concise slide describing the impact to the business and metrics for success. I don’t think there’s a particular way to do this, but it’s important that the slide is succinct enough to understand quickly when your decision makers need to read through 50 of them. Here’s an example of one of our feature slides:

接下来，我将每个功能请求缩减为一个简短的幻灯片，该幻灯片描述了对业务的影响以及成功的指标。 我认为没有特定的方法可以执行此操作，但是重要的是，幻灯片应足够简洁，以便您的决策者需要阅读其中的50条内容时可以快速理解。 这是我们其中一张功能幻灯片的示例：

After compiling all of the feature slides, I realized that the most likely outcome was that the decision-making team would coalesce around a few high-impact, high-cost features. I’ll call these foundational data features. They are projects like new API integrations or data sources, new Looker explores, and other similarly complex builds. I figured our decision-making team would end up leaving many of the medium-cost feature requests that I considered “nice-to-haves” unfunded.

整理完所有功能幻灯片后，我意识到最可能的结果是决策团队将合并一些高影响力，高成本的功能。 我将这些基本数据功能称为。 它们是诸如新的API集成或数据源，新的Looker探索以及其他类似的复杂构建之类的项目。 我认为我们的决策团队最终将放弃许多我认为“精打细算”的中等成本功能请求，而这些请求没有资金支持。

I knew I wouldn’t be able to build out the foundational data features without having to say no to quite a few of the smaller feature requests, and I hoped this process would help our decision-making team arrive at that realization on their own. It would be easier for everyone to decide together than to have to tell some of our leaders that their needs were less important than the needs of another team.

我知道，如果不对很多较小的功能要求说不，我将无法构建基础数据功能，并且我希望这一过程将有助于我们的决策团队自行实现这一目标。 与每个人一起决定要告诉我们的一些领导者，他们的需求比另一个团队的需求更重要，这比每个人共同决策要容易得多。

结果 (The outcome)

I met with our team leads, our strategy manager, and our COO for about an hour. I presented each feature slide and answered questions about a feature’s importance or why it was priced a certain way. Reminding everyone that the purpose was to select the features that were best for Milk Bar as a whole, I turned them loose to discuss, negotiate, and spend their budget. Having our COO and strategy manager in the room certainly helped, because they weren’t tied to a function and were able to mediate and settle disagreements about priorities.

我约了一个小时与团队负责人，战略经理和首席运营官会面。 我展示了每个功能幻灯片，并回答了有关功能重要性或为什么定价一定的问题。 提醒所有人，目的是选择整体上最适合Milk Bar的功能，我让他们松懈地讨论，协商和花费他们的预算。 当然，让我们的首席运营官和战略经理参与进来无疑会有所帮助，因为他们与职能无关，并且能够调解和解决关于优先事项的分歧。

After the dust settled, only 5 of the 15 original features remained funded. I thought this was stunning, since the team leads that I work with had strongly advocated for each feature in our individual meetings.

尘埃落定后， 仅保留了15个原始功能中的5个。 我认为这令人惊叹，因为与我一起工作的团队负责人在我们的个人会议中强烈主张每种功能。

Conrad summarizes my thoughts on the outcome…

康拉德总结了我对结果的看法...

This is incredible, because someone very smart at one point thought, “We would be absolutely stupid not to do this thing.” But really, when viewed in context of all the opportunities for the business, half of the things people thought were important immediately fall away.

这是令人难以置信的，因为某个时候非常聪明的人认为：“如果不这样做，我们绝对是愚蠢的。” 但是，实际上，从所有业务机会的角度来看，人们认为重要的事情有一半会立即消失。

That was exactly what happened.

就是这样。

Our team of decision makers aligned on a few of the highest-impact features, choosing not to fund some of the smaller, “nice-to-have” projects that had been suggested. Some of the features didn’t receive a single vote.

我们的决策者团队针对一些影响最大的功能进行了调整，选择不资助已建议的一些较小的“精打细算”项目。 其中一些功能未获得投票。

This was a perfect opportunity for me to mention that we would have nearly double the capacity for new features if we were willing to hire another data engineer. After going through the difficult process of cutting features that still felt important, our leaders clearly understood the need for additional headcount and even asked me to push up my hiring timeline. I can’t think of a better way to ask for more resources.

对于我来说，这是一个绝好的机会，如果我们愿意雇用另一位数据工程师，那么我们将拥有几乎两倍的新功能。 在经历了艰苦的裁切过程之后，我们仍然感到很重要，这些裁切过程仍然很重要，我们的领导人清楚地知道需要增加人员，甚至要求我加快招聘时间。 我想不出一种寻求更多资源的更好方法。

Overall, in my first experience with this method, I observed some significant benefits…

总体而言，在我第一次使用这种方法的经验中，我发现了一些明显的好处……

• All my stakeholders have a clear understanding of what I’m working on next quarter, how time-consuming each project is, and the priority of every project relative to the others.

  我所有的涉众都清楚地了解了我下一季度的工作 ，每个项目的耗时以及每个项目相对于其他项目的优先级。

• We only picked things that really, really needed to be done. Stakeholders were willing to accept the status quo where it was sufficient to save budget for the features they didn’t want to live without.

  我们只挑选了确实需要做的事情。 利益相关者愿意接受这样的现状，即足以节省他们不想拥有的功能的预算。

• I gained more support for hiring more data engineers and analysts.

  我获得了更多雇用更多数据工程师和分析师的支持。

• Stakeholders saw how important their needs were relative to other needs across the company. They were willing to cede features that were more specific to their teams in favor of higher-impact features.

  利益相关者看到了他们的需求相对于公司其他需求的重要性 。 他们愿意放弃对团队更特定的功能，而选择影响力更大的功能。

• Saying no to a feature request can sometimes make a stakeholder feel that they aren’t valued. In this case, everyone enjoyed the process. It was time-efficient and fun. Someone said the idea was “genius,” and our COO told me it was an “excellent meeting and a brilliant approach.”

  对功能请求说不，有时会使利益相关者感到他们没有被重视。 在这种情况下， 每个人都喜欢这个过程。 这既省时又有趣。 有人说这个主意是“天才”，而我们的首席运营官告诉我，这是“一次出色的会议和一种出色的方法”。

有关采用这种方法的建议 (Advice for adopting this approach)

I would absolutely recommend this method, and I can’t wait to do it again at the end of next quarter. Here are my recommendations for using this method.

我绝对会推荐这种方法，我迫不及待想在下个季度末再次这样做。 这是我使用此方法的建议。

• Planning is key. Take your time meeting with your stakeholders and learning about the features they want. You want to form a complete picture of what your stakeholders need from you over the next quarter, and it’s better to ask them than to guess.

  规划是关键。 花时间与利益相关者会面并了解他们想要的功能。 您想完整地了解下一个季度您的利益相关者的需求，最好是问他们而不是猜测。

• Be ready to explain each feature concisely. You need to be able to understand the motivation and planned execution of each feature well enough to describe it quickly and clearly. It’s worth practicing describing each feature slide in less than a minute before your final decision meeting.

  准备简要地解释每个功能。 您需要足够了解每个功能的动机和计划执行，以便快速，清晰地描述它。 值得一提的是，在最终决定会议召开前不到一分钟的时间里描述每个功能幻灯片。

• Be ready to explain why some features were more expensive than others. Some of our team leaders were initially frustrated to see that features they asked for cost more than their entire allocated budget. Make sure you can justify the cost with a legitimate estimate of work and can explain your estimate.

  准备解释为什么某些功能比其他功能更昂贵。 最初，我们的一些团队负责人感到沮丧的是，他们要求的功能比全部分配的预算要贵。 确保您可以通过合理的工作估算来证明成本合理，并可以解释您的估算。

• Keep it light but stand your ground. As the facilitator, try to keep the atmosphere fun and help to diffusion tension or disagreements when they arise. At the same time, be firm with your estimates of work. Ultimately, you only have so many hours in the day, so don’t be afraid to remind your stakeholders that you can’t create more time. If they push back, you have an excellent opportunity to propose additional headcount for your team.

  保持轻便，但要站稳脚跟。 作为主持人，请尝试保持气氛愉快，并在出现紧张或分歧时帮助他们消除紧张气氛。 同时，对您的工作估计要坚定。 最终，您一天只有几个小时，所以不要害怕提醒您的利益相关者您不能创造更多的时间。 如果他们退缩，您将有一个极好的机会为您的团队建议更多的人员。

If you use the Pandora method already, are interested in giving it a try, or have suggestions about how to improve this process, please let me know in the comments!

如果您已经使用了Pandora方法，有兴趣尝试一下，或者对如何改进此过程有建议，请在评论中告诉我！

If you enjoyed this article, please give it some claps (on a scale of 1–50) below! Follow me here for more content about data engineering and analytics in small to mid-size companies.

如果您喜欢本文，请在下面给它一些鼓掌(以1–50的比例)！ 在此处关注我，以获取有关中小型公司数据工程和分析的更多内容。

翻译自: https://www.freecodecamp.org/news/i-tried-pandoras-brilliant-method-for-feature-prioritization-c5fb586ad317/

oye pandora