Software project management tools should build with the end users – the creators – in mind. Keeping individuals productive is more important than generating perfect reports.
软件项目管理工具的创建，需要考虑其最终用户--创建者。让团队成员保持生产力比生成完美的报告更重要。
Productivity software should be opinionated. It's the only way the product can truly do the heavy lifting for you. Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.
效率软件应该是带着偏见的。这是它能够为你完成重任的唯一方法。灵活的软件会导致每个人都发明自己的工作流程，随着团队规模的扩大，最终会造成混乱的局面。
We should find a cadence and routine of working. In cycles, we decide priorities and assign responsibilities. Our goal is to maintain a healthy momentum with our teams, not rush towards the end.
我们应该找到工作的节奏和规律。在工作周期中，我们决定优先级并分配任务。我们的目标是团队保持健康的势头，而不是急于求成。
Our daily work might be filled with tasks but we should understand and remind our teams of the purpose and long term goals of our work. Roadmaps, projects and milestones are all important to keep in mind as we plan our weekly schedules.
我们的日常工作可能充满了各种任务，但我们应该明确并提醒我们的团队，工作的长期目标。在我们做每周计划时，路线图、项目和里程碑都是需要牢记的。
Don’t invent terms if possible, as these can confuse and have different meanings in different teams. Projects should be called projects.
如果可能的话，不要发明术语，因为这些术语会使人混淆，在不同的团队中有不同的含义。项目就应该被称为项目。
Our tools should not make us the designers and maintainers of them. We should throw away or automate the busy work so you can focus on the more important work.
项目工具不应该让我们成为它的设计者和维护者。我们应该扔掉那些繁琐的工作，或者自动化处理，这样你就可以专注在更重要的工作上。
Teams at different sizes have different needs. Tools should be simple to get started with and grow more powerful over time.
不同规模的团队有不同的需求。工具应该是简单上手的，然后随着时间的推移而变得更加强大。
There isn't always a best answer. The important thing is to make a decision, and move on.
很多时候，没有最好的答案。重要的是要做出决定，然后继续前进。
Ambitious goals are the only way to make a significant impact. Companies should focus on them when they define their high level direction. Reserve some space on your roadmaps for unexpected and reactive work that always comes up and allow your roadmap to change if needed.
雄心勃勃的目标是成大事的唯一途径。公司在确定其长远方向时应关注它们。在你的路线图上，为意外情况和紧急事务保留一些空间，他们肯定会出现的，要允许你的路线图在需要时可以改变。
All projects and work should directly correlate to these goals. Review projects and their target dates during roadmap meetings and pull from projects as you plan cycles.
所有项目和工作都应该与这些目标关联起来。在路线图会议上评审项目和它们的交付日期，并在做迭代计划时从项目中提取。
Cycles create healthy routine and focus teams on what needs to happen next. 2-week cycles are the most common in software building. They're short enough to not lose sight of other priorities but long enough to build significant features. Cycles should feel reasonable. Don't overload cycles with tasks and let unfinished items move to the next cycle automatically.
迭代周期创造了健康的流程，并使团队专注于接下来需要发生的事情。2周的迭代周期是软件创建中最常见的。它们足够短，不会耽误其他高优先级的事情，但也足够长，可以交付重要的功能。迭代周期应该感觉合理。不要在迭代周期中放入过多的任务，以至于未完成的任务自动进入下一个周期。
You don't need to save every feature request or piece of feedback. Important ones will resurface and low priority ones will never get fixed. A more focused backlog makes it easier and faster to plan cycles, and ensures the work will actually get done.
你不需要保留每一个功能请求或反馈。重要的东西会重新出现，而低优先级的永远不会被修复。一个聚焦的待办列表可以让你更容易做迭代计划，并确保工作真正完成。
All software has bugs, more than we can ever fix. Include bugs and other fixes as part of your cycles. Invest in tooling as it is a force multiplier if done right.
所有的软件都有 bug，比我们能修复的要多。把 bug 和其他修复工作作为迭代周期的一部分。在工具上作出投资，做的好的话会数倍提升效率。
Each project should have a named owner responsible to own delivery and write the project brief. The same goes for issues. Others should collaborate but responsibility should lie with a single person.
每个项目都应该有一个明确的负责人，来负责项目交付和编写项目简报。对 issue 也是如此。团队可以协作，但责任应该在一个人身上。
Aim for brevity. Short specs are more likely to be read. The purpose of a spec is to briefly communicate the "why", "what" and "how" of the project to the rest of the team. Ideally these short documents force teams to scope out work so priorities are clear and teams avoid building the wrong thing.
力求简洁。简短的规范文档才可能被阅读。规范的目的是将项目的「原因」、「内容」和「方法」简要地传达给团队的其他成员。理想情况下，这些简短的文件会约束团队确定工作边界，以便明确优先次序，避免团队创建错误的东西。
The more popular your product, the more feedback you'll get. Overflowing inboxes are a good sign unless they're bug reports. Don’t worry too much about organizing all the feedback. Collect it and use it as a research library when developing new features. Try to spot trends. Use feedback, even complaints, as an opportunity to get to know your users and ask them to explain why they want a specific feature so you find out their needs. Solve the problem – don’t just build the feature.
你的产品越受欢迎，你得到的反馈就越多。溢出的收件箱是一个好事情，除非它们是 bug 报告。不要太担心要去管理组织所有的反馈。收集它，并在开发新功能时将其作为一个研究库。试着去发现趋势。利用反馈，甚至是抱怨，作为了解你的用户的机会，请他们解释为什么他们想要一个特定的功能，这样你就能发现他们的需求。解决问题--不要只是创建功能。
It's hard to see visible progress when working on large tasks, which can be demotivating. Break down work into smaller parts and create an issue for each one when possible. Ideally you can complete several concrete tasks each week. It feels great to mark issues as done.
在处理很大的 issue 时，很难看到明显的进展，这可能会打击团队的积极性。把工作分解为较小的事项，并尽可能为每个事项创建一个 issue。理想情况下，你可以每周完成几个具体的 issue。把 issue 标记为 done 的感觉很好。
The clearest way to see whether something is complete or not is to show the diff in the code or design file. When the tasks are scoped small, your changes will be small and easier to review, too. Avoid massive pull requests or large design changes.
看某件事情是否完成的最清楚的方法是在代码或设计文件中查看改变。当任务的范围很小时，你的改动也会很小，也更容易审查。避免大规模的代码合并请求或大的设计变更。
Designers and engineers should work together on projects, creating a natural push and pull. Designers bring their skills to explore ideas and push your team's thinking. Engineers can challenge thinking around implementation and will bring the winning ideas to reality. The best creators often have talent for both. Directly loop in other teams when building features they'll use or ask customers they interact with to use.
设计师和工程师应该在项目中一起工作，形成一种自然的推拉关系。设计师利用他们的技能来探索想法并推动你的团队的思考。工程师可以围绕实施方案进行思维调整，并将好的想法变成现实。最好的创建者往往在这两方面都有天赋。在创建功能时，与这些功能的用户们保持信息同步。
It’s important to look back and celebrate what you achieved as a team. Consistent changelogs also communicate to the user new features, the value they get from your product, and your commitment to improving it. It's also an easy way to connect your team's individual work to the collective value they create.
回顾并庆祝团队所取得的成就是很重要的。坚持更新日志还可以向用户传达新的功能，产品提供的价值，以及改进产品的承诺。这也是将团队的个人工作与他们创造的集体价值联系起来的一种简单方法。
- Linear 是一款研发项目管理工具（https://linear.app）。
- 这些文章是 Linear 团队的一系列文章，分享他们产品研发团队的工作原则和实践总结。
- 文章使用 DeepL 翻译，然后人工优化。
- 如果你觉得哪里可以优化，请 提交 issue 或者 提交 PR。
- 文章版权归 Linear 团队所有。