管理所有使产品团队保持目标的任务和活动，即使是组织最严密的产品经理，也可能是艰巨的工作。
虽然您的工程师会愉快地整天在Github中进行挖掘，但它不是用于项目管理新功能交付的好工具。
无论您对生产率的偏好如何，都需要保持对所有努力的记录，以使您的利益相关者满意。
在阳光下尝试了每个待办事项列表应用程序之后，从“ 记住牛奶”到Todoist ，我还没有发现任何东西能够胜过Asana的团队任务管理灵活性。
您听说过Asana，对不对？
如果您还没有阅读过，请阅读《 Asana指南》，以快速入门：
Asana指南：教程，帮助和功能文档·Asana
了解Asana如何处理文档，建议的Asana使用方式以及视频，以帮助您的团队充分利用… asana.com
Asana在哪里适合产品经理的工具包？
Asana应该是跟踪产品团队成员正在从事的业务任务的场所，而其他业务成员正在a）促成，b）受其影响或c）需要具有可见性。
Asana不是开发票的地方； 通过标准的Sprint /看板交付流程（在Github或Jira或任何地方），可以更好地管理它们。
Asana也不是管理单个任务列表的地方。 没有人需要看到您和您的团队正在做的所有小事情（除非您有一位对老板有压迫感的微型经理）。
Asana擅长的地方是保持团队所有开放环可见，并使人们对其交付负责。
拥有就是一切
Asana的团队已经对生产力科学进行了大量研究，因此您不必这样做。
乍看之下，该应用程序的限制功能之一实际上是功能最强大的功能。
只能将一个团队成员分配为特定任务或项目的所有者。
如果管理得当，这意味着您可以让团队的合适成员负责特定活动的交付。
尽管其他人可能会参与完成任务，但拥有一个所有者意味着如果没有完成，则有人需要负责。
制定一些基本规则
为了使Asana不会成为免费的工具，为您希望如何管理项目和任务创建一个结构很重要。
Asana非常灵活，因此，除非您预先设置一些基本规则，否则它将很快变得笨拙且难以管理。
毕竟，您希望您的团队继续使用Asana。 尽一切可能使他们变得容易。
这是我喜欢布置的方式：
项目。 项目是基于产品/工作流程的“高级”存储桶
任务。 每个存储桶都有一个需要完成的项目/任务列表，每个项目/任务的负责人拥有/交付日期。
任何需要多个动作才能完成的任务都应被视为“项目”，其中每个动作都有子任务。
创建任务时，如果您能够：
- 使用合适的项目名称为项目创建任务
- 输入项目的顶级描述
- 分配项目的所有者（负责交付的人）
- 添加截止日期（这应该是您期望项目完成的日期）
- 为需要完成的所有操作创建子任务，以便在截止日期之前完成
- 为所有子任务分配所有者/截止日期
- 将所有利益相关者/感兴趣的各方添加为关注者，以便他们随时了解最新进展
对于开发交付品（例如，新功能/缺陷等），所有任务都应通过Asana进行管理，直到创建相关Github（或Jira）票证/里程碑并将其添加到Sprint为止。
拼凑在一起
这是系统各个组件如何组合在一起的思维导图：
传入。 这是您业务部门中任何人对产品团队提出的任何请求的存储桶。
授予所有人访问该项目的权限，并让他们使用它来添加任何功能请求，产品创意，错误，问题或其他他们认为有趣的内容。
不要设置任何规则。 您给人们的自由越多，他们给您可以合作的想法的可能性就越大。
只需记住定期（至少每周一次）对列表进行分类，然后将项目移至路线图或缺陷列表。
如果不需要在路线图中的请求也不是需要修复的缺陷，那么请确保您返回提出请求的人员，以告知他们。 没有人喜欢提出他们的想法，只是发现他们被忽略了。
OKRs。 您团队的目标和主要成果； 您要完成的“工作”超出了构成路线图可交付成果的任务。
这是不断改进的项目； 可以帮助您提高团队效率的扩展目标，每季度一次。
路线图。 我已经详细介绍了产品路线图。 这不是您的发布计划，而是您的团队要交付的能够为您的产品和业务增值的项目。
创建一个带有“现在”，“下一步”和“以后”列的委员会，以开始优先考虑您团队的工作。
保持较高水平，并确保可交付成果的标题反映出对客户的好处。
您可以在此处阅读有关设置路线图的更多信息：
建立产品路线图，以帮助您的团队保持目标
如果您不担心最终的去向，那就出发没有地图的旅程吧。 如果您要尝试… medium.com
我曾经将Trello用于路线图，但是Asana的新Boards功能使将所有内容保存在一个系统中确实很容易。
填充路线图后，为每张卡创建子任务，其中包括要完成的下一个动作（至少）以使其继续前进。 确保分配了所有者并设置完成日期。
对于“后期”列中的某些交付项，操作可能与“弄清楚我们要如何处理”一样宽松。 不过，对于“现在”列中的可交付成果，您应该有一个看起来像发布/交付计划的任务列表（例如，“…使功能登台登台”，“…完成用户测试”等）。
缺陷。 使产品团队以外的人员可以轻松跟踪他们提出的任何缺陷或问题。 与其给所有人访问Github的权限，不如在Asana中简单列出所有出色的东西。
将缺陷分配给将要拾取它们的团队成员，并将提出该缺陷的人员添加为关注者。 鼓励缺陷的所有者使每个人保持最新状态。
测试。 一旦有新功能和错误修复进入分阶段，就需要对其进行测试。 创建一个带有“准备测试”，“进行中”和“完成”列的面板，并让开发人员在完成所有新功能/错误修复后为它们添加卡。
鼓励您的开发人员编写“用例”，并将其包含在描述中，以使测试人员尽可能地容易。 如果您的测试人员在测试时发现错误/问题，请通过您的Incoming项目让他们提出。
文档。 总会有文件要写。 无论是产品规格，需求文档还是用户手册，都需要为每个需要完成的作品创建任务。
您可能要包括的其他一些项目是：
产品策略。 “我们的产品将运往何处？”的大门票尚未列入您的路线图，但仍需要考虑。
用户反馈。 如果您有在产品团队中管理反馈的过程，请为此创建一个项目。
下一步
鼓励您的整个业务将Asana用作主要的生产力工具。 使用它的人越多（您可以赋予它更多的结构），则它越有可能粘住。
每个产品团队都是不同的。 仅仅因为此设置适用于一个团队并不意味着它将完全相同地适用于另一个团队。
定期与团队一起检查您的系统，并不断进行调整和改进。
不要从胶印中追逐完美的工作流程。 最重要的是让每个人都使用该系统。 您可以根据自己的需要找出最佳方法。
