项目开发项目管理工具_项目管理工具决定了我们的工作方式-CSDN博客

项目开发项目管理工具

Building product in a way that enables teams to have full visibility of decision making, prioritisation and giving business stakeholders a view of ‘where things are at’ is a goal most businesses strive to achieve.

以一种使团队对决策，优先级具有完全可见性的方式构建产品并为业务利益相关者提供“事物处在何处”的视图，这是大多数企业努力实现的目标。

‘Project Management Tools’ often get used in an attempt to solve this through its use of workflows, addons and reporting & permission structures. What you don’t know, is the more you customise your tooling, the deeper into the web you are falling, and with that the tighter grasp your tooling now has on the ability for your teams to make decisions and pivot on a moments notice.

通常使用“项目管理工具”来尝试通过使用工作流，附加组件以及报告和权限结构来解决此问题。您所不知道的是，您对工具的自定义设置越多，您进入的网络越深，而您对工具的把握就越紧密，这使您的团队能够做出决定并立即转瞬即逝。

This article aims to convince you that when it comes to developing Product and the processes that surround it, less is more and using a tool to explain “How your business works”, is setting yourself up to fail.

本文旨在说服您，在开发产品及其周围的流程时，少即是多，而使用一种工具来解释“您的业务如何运作”会使您陷入失败。

项目管理工具 (Project Management Tools)

An image of the workflow example from the Project Management tool JIRA — https://www.atlassian.com/software/jira/features https://www.atlassian.com/software/jira/features

The reality of all of this is tools are not necessarily the bad guy here if anything it’s the Administrator’s fault in charge of setting the tool up. That said often Project Management Tools are built in such a way that encourages ‘stickiness’ to which makes it an essential part of your business.

所有这一切的现实是，如果是管理员负责安装工具的错误，那么工具不一定是坏蛋。也就是说，项目管理工具通常以鼓励“粘性”的方式构建，这使其成为您业务必不可少的一部分。

The problem is, too often as leadership teams or even as human beings we lean on ‘tools’ to solve our problems. We look for tools to tell us the best way to do things whether this is due to a lack of confidence, lack of time or simply the desire to delegate that responsibility to something else so we can just ‘get on with it’, the issue is these Project Management tools can quickly become a tool that is crushing your productivity.

问题往往是作为领导团队，甚至是人类，我们依靠“工具”来解决我们的问题。我们正在寻找工具来告诉我们做事的最佳方式，这是由于缺乏信心，缺乏时间，还是仅仅是将责任转嫁给其他人的愿望，所以我们可以“继续”这些项目管理工具可以Swift变成破坏您生产力的工具。

The issues arise from our desire to tinker with things and tweak ‘what we have’ rather than stepping back and looking at the big picture.

这些问题源于我们渴望修补事物并调整“我们所拥有的”而不是退后一步去看大局。

一个简单的工作流程 (A Simple Workflow)

Likely the simplest of workflows would be along the lines of Todo, Doing, Done. It makes sense. It’s easy to communicate and provided everything that needs to be Doneis in the Todo pile, we are good to go.

最简单的工作流程可能就是Todo ， Doing ， Done 。这说得通。它很容易沟通，并且只要Todo堆中需要Done所有内容，我们就可以进行。

An image of Todo, Doing, Done with one way arrows

This works great for unidirectional tasks. Tasks that upon completing can be somewhat forgotten about. Most tasks we do in our day-to-day lives are in fact uni-directional. Chores around the house for example, are unidirectional.

这对于单向任务非常有用。完成时可能会忘记的任务。实际上，我们在日常生活中执行的大多数任务都是单向的。例如，房屋周围的杂务是单向的。

This too is the default Workflow state’s of most productivity tools when you take them ‘out of the box’.

当您“开箱即用”它们时，这也是大多数生产力工具的默认工作流状态。

一些简单的调整 (Some Simple Tweaks)

When it comes to building Product, task progression is most often bi-directional. A task may become Done however if we find an issue with it, we place it back into Doing. So add this alteration to our workflow. Simple enough, done.

在构建产品时，任务进度通常是双向的。一项任务可能会Done但是如果发现问题，则将其放回Doing 。因此，将此更改添加到我们的工作流程中。很简单，完成。

An image of Todo, Doing, Done with one way arrows except doing and done now have two way arrows

So as previously identified, provided we have confidence that everything that needs to be Done is in the Todo column, we are good to go.

因此，如前所述，只要我们有信心要Done所有事情都在“ Todo列中，那么我们就很好了。

Often in Product companies, the people responsible for setting the Priorities and ‘What needs to be done’ are not necessarily the people who do the work. So here we suggest someone take ownership of the Todo column. We assign a Product Owner, Team Lead, but someone has ultimate ownership of the Todo column. That way, if the business needs something Done before something else, it moves that item to the top of the list, the Team is told to “always take from the top of the Todo column, problem solved.

通常在产品公司中，负责设置优先级和“需要完成的工作”的人员不一定是从事工作的人员。因此，在这里我们建议某人拥有Todo列的所有权。我们指定了产品负责人，团队负责人，但是某人对Todo列拥有最终所有权。这样，如果业务需要先Done ，则将其移到列表的顶部，团队将被告知“始终从Todo列的顶部开始，问题已解决。

One final thing we want to change comes from the team responsible for the Doing column. You see the states of Todo, Doing, Done simply don't offer enough visibility of what actually happens when it comes to delivering product.

我们要更改的最后一件事来自负责“ Doing专栏的团队。您会看到Todo ， Doing ， Done根本无法提供交付产品时实际发生的情况的足够的可见性。

We need to add another workflow state between Doing and Done, its essentially a state where things need to be verified that the requirements are done, tested in a staging environment, and ‘pushed to production’. For this state, let's just call it Testing and due to the nature of Testing it may be deemed incorrect, so should then be able to move back into Todo.

我们需要在Doing和Done之间添加另一个工作流状态，它本质上是一种状态，在此状态下，需要验证是否已完成需求，在临时环境中进行测试并“推送至生产”。对于这种状态，我们将其称为“ Testing ，由于“ Testing的性质，它可能被认为是不正确的，因此应该能够移回Todo 。

So now we have 4 Workflow States:

所以现在我们有4个工作流状态：

An image of Todo, Doing, Testing, Done with two way arrows

Todo: A prioritised list of all work to be done.
Todo ：要完成的所有工作的优先列表。
Doing: Work that is in flight.
Doing ：正在Doing工作。
Testing: Work that is ‘done’, but needs to be quality checked, and pushed to production.
Testing ：“完成”的工作，但需要进行质量检查，然后投入生产。
Done: Work that is successfully in the production environment.
Done ：在生产环境中成功Done工作。

Simple enough, nothing too crazy.

很简单，没有什么太疯狂的。

“我们不会那样做。” (“We Don’t Work Like That.”)

So when it comes to building a product, unless you are in a garage-style start-up environment, you will typically have people responsible for the design portion of the product, and the development portion of the product. These team will operate closely but have clear distinctions in terms of their delivery expectations. Perhaps the design team start with ideas, pass them on to the development team, perhaps they work side-by-side, either way, they both have work Todo.

因此，在构建产品时，除非您处于车库式的启动环境中，否则通常将需要负责产品设计部分和产品开发部分的人员。这些团队将密切合作，但在交付期望方面有明显的区别。也许设计团队从想法开始，将它们传递给开发团队，也许它们并肩工作，无论哪种方式，他们俩都有工作Todo 。

So it turns out the Design team don’t need a Testing state, and also their work is never Done as they are set the responsibility to continuously update their product so the ability to be Done is simply not possible. For the sake of bringing them on board with the overall objective of total business visibility and transparency, we concede that the Done column is fine, that can just loop back into the Todo column if needed, but we will give them their own workflow without a Testing column.

因此，事实证明设计团队不需要“ Testing状态，而且他们的工作永远都不会Done因为他们被赋予了不断更新产品的责任，因此根本无法Done 。为了使他们参与总体业务可见性和透明度的总体目标，我们承认“ Done列很好，可以根据需要循环回到“ Todo列，但是我们将为他们提供自己的工作流程，而无需Testing栏。

So now we have both teams, using a productivity tool that shows ‘How they work’ with the help of their team’s Workflow. We know what’s Todo, Doing and whats ultimately Done. Fantastic right?

因此，现在我们两个团队都使用了生产力工具，借助他们的团队的工作流程来显示“他们的工作方式”。我们知道Todo ，正在Doing事情以及最终Done 。太好了吧？

父亲时间 (Father Time)

So as time progresses, ‘small tweaks’ take place, they all make sense and are easy to communicate. Responsibilities regarding the ownership of Workflow states are delegated to the teams in the spirit of ‘squadification’, and everything is seemingly fine.

因此，随着时间的流逝，发生了“小调整”，它们都是有意义的，并且易于沟通。关于工作流状态所有权的责任本着“团队精神”的精神委托给团队，一切似乎都很好。

Then something happens. Something wasn’t delivered on time, something failed in production, someone, somewhere ‘dropped the ball’. It turns out to be a problem with the ‘way we work’, ‘we are too silo’d’, ‘we need to operate as one big team’. So we look at our tool and say “Where can we optimise?”.

然后发生了一些事情。某些东西没有按时交付，有些东西生产失败，有人在某个地方“丢了球”。事实证明，“我们的工作方式”，“我们太孤岛”，“我们需要作为一个大团队来运作”是一个问题。因此，我们查看工具并说“我们可以在哪里优化？”。

Bingo. The problem is, we need the ability for a single feature, to be passed through all our teams so we can track everything as a single object. The problem was when the Design team was Done it should appear as a Todo for the Engineering Team. Sounds simple, communicate the change. Mention ‘we have fixed the issue’ to those that sounded the alarm. Done.

答对了。问题是，我们需要将单个功能传递给我们所有团队，以便我们可以将所有内容作为单个对象进行跟踪。问题是当设计团队Done它应该作为工程团队的Todo出现。听起来很简单，传达变化。对于那些发出警报的人，提及“我们已解决问题”。 Done 。

变化的滑坡。 (The Slippery Slope of Change.)

If there is one constant, its change. Change is inevitable, change is good, and change should always be considered. As I have outlined above, all these changes we make to our workflows are small, simple and made sense then. They suited the team perfectly then, and the reality is they worked perfectly.

如果有一个常数，则它会改变。改变是不可避免的，改变是好的，应该始终考虑改变。正如我上面概述的那样，我们对工作流程所做的所有这些更改都很小，简单而又有意义。他们当时非常适合团队，而现实是他们完美地工作。

What we have now in respect to our Workflows and Productivity as a company is the considerations that were made in regards to alterations to our Workflows, Prioritisation & Responsibilities were made by people who may not exist in the company anymore. Those who do are now Senior and understand the context in which those decisions were made so don’t need to question them, and new staff are having to operate under these constraints don’t stop to ask “Why?”.

关于公司的工作流程和生产力，我们现在所考虑的是更改工作流程，优先级和职责由公司中可能不再存在的人员做出的考虑。现在担任高级职位的人员并了解做出这些决定的背景，因此无需质疑它们，新员工不得不在这些限制条件下进行操作，他们不会停下来问“为什么？”。

An image of a heart symbol with a circular arrow around it

“大复位”。 (‘The Grand Reset’.)

So at some point, someone suggests we do a ‘reset’. We scrap everything. We start again with a clear understanding of how we work, where our current process doesn’t, and we strip back all the ‘process’. We remove all the Workflows we set up in our tools, all the permissions and prioritisation rights. All the uni-directional, bi-directional tasks flows are removed and we get down to the real requirement. Transparency, ownership, simplicity.

因此，在某个时候，有人建议我们进行“重置”。我们报废一切。我们从清楚地了解我们的工作方式，当前流程不存在的地方开始，然后剥离所有“流程”。我们将删除我们在工具中设置的所有工作流，所有权限和优先级权限。所有的单向，双向任务流都被删除，我们可以满足实际需求。透明，所有权，简单。

And the thing is… this often works. The entire business is re-aligned, re-energised that the new way of working is better, it’s fast, it’s clean and the intention is clear.

事情是……这经常有效。重新调整了整个业务，充满活力，使新的工作方式更好，更快，更干净而且意图明确。

However, our mindset also needs to change.

但是，我们的观念也需要改变。

打破循环。 (Breaking the cycle.)

Up until this point, we haven’t done anything drastic. It feels like it, but all we have done is gone back to A Simple Workflow.

到目前为止，我们还没有做任何大动作。感觉就像这样，但是我们所做的只是回到简单工作流程。

We need to adjust the way we look at Delivery as a business constantly. Not as an output, but as an input. It needs to be considered and managed much like any other Product. It needs testing, it needs tweaking, it needs to be talked about and communicated frequently with a designated team or individual accountable for maintaining its viability and usability.

我们需要不断调整将交付视为业务的方式。不是作为输出，而是作为输入。需要像对待其他任何产品一样对其进行考虑和管理。它需要测试，需要调整，需要与负责维护其生存能力和可用性的指定团队或个人进行经常性的讨论和沟通。

Group Ownership: Assign a group of individuals responsible for representing their team in the process. They’re responsible for highlighting issues, suggesting tweaks and communicating where needed.

小组所有权：分配一组负责在此过程中代表其团队的个人。他们负责突出问题，提出调整建议并在需要的地方进行沟通。

The group is to meet frequently with a majority rules approach. We all operate the same unless we all agree to do otherwise. If one team changes, we all agree and change accordingly.

该小组将以多数规则的方式经常开会。除非我们都同意这样做，否则我们所有人的操作都是相同的。如果一个团队发生变化，我们都同意并做出相应的变化。

A Single Owner: Assign a single point of contact who has the final say in decisions that impact the Delivery of work and those made by the team above.

单一所有者：分配一个唯一的联系点，在影响工作交付和上述团队做出的决定中拥有最终决定权。

This individual is the point of contact for all business stakeholders when there is a communication breakdown, something fails to be delivered, or messaging is unclear.

当通信中断，某些内容无法传递或消息不清楚时，此个人是所有业务利益相关者的联系点。

They are responsible for ensuring the transparency and prioritisation of work is clear, correct and effective. For every modification, every Addon, every change to the Workflow, this individual is ultimately accountable for its reasoning and success.

他们有责任确保工作的透明度和优先次序清晰，正确和有效。对于每个修改，每个插件，工作流程的每个更改，此人最终都要对其推理和成功负责。

As soon as you assign responsibility regarding ‘How we Operate and Deliver Product as a business’ to those ‘Doing the work’, the ‘Why’ is ever-present. The Delivery of Product is not a single individuals ‘thing’ but everyone’s.

一旦您将有关“ 我们如何将产品作为产品进行经营和交付 ”的责任分配给那些“从事工作”的人，“为什么”就永远存在。产品交付不是单个人的“东西”，而是每个人的东西。

All issues with the process and changes are that of a collective and shared and expressed by all.

流程和变更中的所有问题都是集体的，并由所有人共享和表达。

The reality is, all the Simple Tweaks we made earlier may have been issues and numerous teams had, changes that happen in isolation could have raised larger issues that fall outside those impacted and need to be escalated. When we tie ourselves to a tool, we blame the tool. We look to a tool to tell us how we work and we assume its correct. When in reality, it’s very likely not the case.

现实情况是，我们之前所做的所有“简单调整”都可能是问题，并且许多团队都遇到了问题，孤立地进行更改可能会引发更大的问题，而这些问题不在受影响范围之内，需要逐步升级。当我们将自己与工具联系在一起时，我们会责备该工具。我们使用一种工具来告诉我们我们的工作方式，并假设它是正确的。实际上，事实并非如此。

最后的话 (Final Words)

My plea to you is to not let the cycle outlined in the article from A Simple Workflow to The Great Reset continue. Do not tie yourself into a web of Addon’s and Workflow state management in our tooling that constrains your ability to work effectively. The tools we choose as a business and in life are there to work for us, not tell us how to work.

我恳求您不要让本文中概述的从“简单工作流程”到“大复位”的周期继续进行。不要在我们的工具中将自己束缚在Addon和Workflow状态管理的网络中，这会限制您的有效工作能力。我们选择的业务和生活工具对我们有用，而不是告诉我们如何工作。

Be mindful of all the things you add to your business process to take an Idea from conception through to Delivery to a customer.

请注意添加到业务流程中的所有内容，以将“构思”从构思到交付给客户。

We should be able to explain in one small sentence ‘Why we do this’. The response shouldn’t be based on a restriction in our own process, but the value-add it brings to our business and those working within it.

我们应该能够用一句话来解释“我们为什么这样做”。响应不应基于我们自身流程中的限制，而应为我们的业务以及其中的业务带来增值。