软件项目项目管理流程_软件项目管理101

软件项目项目管理流程

The statistics presented in the graph above are based on a survey of 5500 project management professionals. The survey was conducted as part of a report made by PMI. To understand the graph, let’s look at the topmost line which reflects the number of software projects between 2011 to 2018 that meet the project's original goals. In 2018, 70% of the projects succeeded to meet the business intent. Or from a different perspective, in 2018, around 30% of projects ended and didn’t provide a solution to the business needs. A huge percentage in my opinion. We can further see that more than 40% didn’t complete in the original budget and more than 45% didn’t complete on time. In this article, I give a few insights that I collected over time that will help you avoid falling into these statistics.

上图中显示的统计数据基于对5500个项目管理专业人员的调查。 该调查是PMI所做报告的一部分。 为了理解该图，让我们看一看最上面的行，该行反映了2011年至2018年之间达到项目原始目标的软件项目数量。 2018年，有70％的项目成功实现了业务意图。 或者换一个角度来看，在2018年，大约30％的项目结束了，并且没有提供满足业务需求的解决方案。 我认为这个比例很高。 我们还可以看到，超过40％的项目未按原始预算完成，超过45％的项目未按时完成。 在本文中，我将提供一些我随时间而收集的见解，这些见解将帮助您避免陷入这些统计数据中。

开发相关的东西 (Develop Something Relevant)

One of the biggest wastes of resources in software development is developing products, features, or software infrastructure that nobody needs. Ask any programmer how many times they work on something that nobody used and you will be amazed. We develop things that no one needs very often. Some of it is due to an objective uncertainty of product development, but a big portion of this waste can be avoided.

软件开发中最大的资源浪费之一就是开发没人需要的产品，功能或软件基础结构。 询问任何程序员，他们处理多少次没人使用的东西，您会感到惊讶。 我们开发出没人经常需要的东西。 部分原因是由于产品开发的客观不确定性，但是可以避免大部分浪费。

听您的潜在客户 (Listen To Your Potential Client)

Make sure you know who will use what you are going to work on before you start the actual programming. It doesn’t matter if it’s a client outside the company or someone within your company, you should make sure that they are going to use the product once you finished working on it. Here are a few questions to help you do that:

在开始实际编程之前，请确保您知道谁将使用您将要从事的工作。 不管是公司外部的客户还是公司中的某人，您都应该确保在完成产品使用后，他们将使用该产品。 这里有一些问题可以帮助您做到这一点：

• How are they currently solving the problem? If they already have a different solution to the problem you are trying to solve then they will most likely not need your assistance.
  他们目前如何解决问题？ 如果他们已经对您要解决的问题有不同的解决方案，那么他们很可能不需要您的帮助。
• When will they start using this solution and how often? If they are not eager to start using the product then you should suspect that they might not really want it.
  他们什么时候开始使用此解决方案，以及多久使用一次？ 如果他们不急于使用该产品，那么您应该怀疑他们可能不是真的想要它。
• How many urgent or important issues are they dealing with apart from the current issue at hand? If they have a lot more urgent or important issues then they will most likely not use your product when the time comes.
  除了当前的问题，他们还处理多少个紧急或重要问题？ 如果他们有很多更紧急或重要的问题，那么他们很可能在时机成熟时不使用您的产品。

The questions mentioned above, focus on the potential client's needs instead of the solution you are offering. Try to listen to what they have to say. Don't try to convince them that the problem you are trying to solve is important or that your solution is great. Check out the lean startup or the mom’s test for a much deeper understanding of this topic.

上面提到的问题集中于潜在客户的需求，而不是您提供的解决方案。 试着听他们所说的话 。 不要试图说服他们您要解决的问题很重要，或者您的解决方案很棒。 查看精益创业公司或妈妈的测验 ，以更深入地了解该主题。

通信 (Communicate)

Developing relevant software is all about communication. Communication between the team to clients, between the company’s management to the product management, and between the programmers to the product manager. Behind each feature, there is a programer that codes it. Usually, this programmer doesn’t communicate with the feature’s client regularly. To make sure that he or she doesn't work on something that no one needs, we need to constantly communicate with them and let them know what is the most relevant thing they should do. The following are some practical suggestions to implement:

开发相关软件全都与沟通有关。 团队与客户之间，公司管理层与产品管理层之间，程序员与产品经理之间的沟通。 每个功能的背后都有一个编程器对其进行编码。 通常，该程序员不会定期与功能客户端通信。 为了确保他/她不会处理任何人都不需要的事情，我们需要不断与他们沟通，并让他们知道他们应该做的最相关的事情。 以下是一些实用的实施建议：

• Schedule periodic events to synchronize between the different roles of the organization. I think that 2 weekly meetings of half an hour with the developers will work for most cases.
  安排定期事件以在组织的不同角色之间进行同步。 我认为在大多数情况下，每周两次与开发人员进行半小时的会议是有效的。
• Build a workflow where a task is not considered done until the project/product manager approves it.
  建立一个工作流，直到项目/产品经理批准该任务，该任务才被视为已完成。
• Don’t let programmers be the final call on what to develop next. Programers are busy solving technical challenges. Hence, they don’t have a lot of time to understand what are the most needed features.
  不要让程序员成为下一步开发的最终决定。 程序员正忙于解决技术难题。 因此，他们没有太多时间来了解最需要的功能。
• A good project/product manager should take part in the management program. They should be able to open it and understand what are the upcoming tasks. In my opinion, not having a project manager that constantly looks on the team tasks is a great recipe to develop something that no one needs.
  一个好的项目/产品经理应该参加管理计划。 他们应该能够打开它并了解即将执行的任务。 在我看来，没有一个项目经理经常关注团队任务是开发没人需要的东西的好方法。

按时完成开发 (Complete Development On Time)

Software development inherently has a lot of uncertainty. It is hard to estimate how much time a task will take, what tasks we don’t know about, and how future findings will change the requirements. Yet, we don’t build our product in a void, which means we have to give time estimations to our management or to our clients. How can we improve our time estimations? We need to put more time into it, but not too much time. We need to find cheap mechanisms that will allow us to better predict how much time our development will take.

软件开发固有地具有很多不确定性。 很难估计一项任务将花费多少时间，我们不知道哪些任务以及未来的发现将如何改变需求。 但是，我们不会在虚假的情况下构建产品，这意味着我们必须将时间估算给我们的管理层或客户。 我们如何改善时间估算？ 我们需要花更多的时间，但不要花太多时间。 我们需要找到便宜的机制，使我们能够更好地预测我们的开发将花费多少时间。

现实点 (Be Realistic)

When asked to give time estimation, programmers often give overly optimistic estimations. Here are a few reasons why:

当要求给出时间估计时，程序员通常会给出过于乐观的估计。 原因如下：

• Wanting to look good — Saying a task will take a long time in front of other teammates or in front of the managers can be perceived as weakness or inability to deliver.
  想要看起来不错-在其他队友面前或在经理面前说任务要花很长时间，这可能会被视为软弱或无法交付。
• Programers are under pressure to give an unrealistic estimation. The managers often don’t believe them. When programmers say that something will take a significant amount of time they know what they are talking about. Don’t push them to say unrealistic estimations because this is what you want to hear.
  程序员承受着做出不切实际的估计的压力。 经理们通常不相信他们。 当程序员说某事将花费大量时间时，他们知道他们在说什么。 不要强迫他们说不切实际的估计，因为这是您想听到的。
• We are not always at our best. When programmers try to estimate the time a task will take they usually think of times where they were at there best performance.
  我们并不总是处于最佳状态。 当程序员尝试估计一项任务所花费的时间时，他们通常会想到自己达到最佳性能的时间。
• Take into consideration leave days, vacation days, training, and sick days, etc. Programmers won't do it for you so help them to think of those factors.
  考虑休假日，休假日，培训日和病假日等。程序员不会为您这么做，因此请他们考虑这些因素。

Except for the obvious solutions of considering all of the above, I want to give a rule of thumb. Multiply the time estimation by a constant number. The number changes between people but I would say to add at least 50% to the time estimation. If you don’t trust me, ask programmers in your surroundings what should be the magic number and you will be surprised by the answers.

除了考虑上述所有问题的明显解决方案外，我想给出一个经验法则。 将时间估算值乘以常数。 这个数字因人而异，但我想说要至少增加50％的时间估算。 如果您不信任我，请询问周围的程序员什么是魔幻数字，您将对答案感到惊讶。

达到要求的质量 (Meet The Required Quality)

Low-quality software is expensive. It creates endless problems, from system downtime, unworking features to a bad reputation, and much more. Creating high-quality software is challenging. It requires a lot of knowledge, time, and budget which is often limited. Sometimes it is fine to sacrifice our product quality to save time or money but we need to be very cautious about it.

低质量的软件很昂贵。 从系统停机，功能不正常到信誉不佳等等，它都会带来无尽的问题。 创建高质量的软件具有挑战性。 它需要很多知识，时间和预算，而这通常是有限的。 有时为了节省时间或金钱而牺牲我们的产品质量是很好的，但是我们对此必须非常谨慎。

The Tradeoff Triangle — One Can’t Have Them All

权衡的三角形-一个不能全部拥有

过滤方法 (The Filter Method)

The filter method is a name I use for a basic concept — Our workflow should contain stages to improve our software quality. Each one of the stages is like a filter that prevents low-quality software from moving to the next stages of our workflow. There are many mechanisms that we can use as a “filter”, here are some:

过滤器方法是我使用的一个基本概念的名称-我们的工作流应包含改善软件质量的阶段。 每个阶段都像一个过滤器，可防止劣质软件进入工作流程的下一个阶段。 我们可以将许多机制用作“过滤器”，以下是一些机制：

• Code Review — Letting different people in the team review the same code.
  代码审查-让团队中的不同人员审查相同的代码。
• Define tests — Whether automatic or manual, we should test our code before releasing it to clients.
  定义测试-无论是自动还是手动，我们都应先测试代码，然后再将其发布给客户。
• Penetrebility test — Defining the test we make to be sure that our project meets the security standards.
  渗透性测试-定义测试以确保我们的项目符合安全标准。
• Gradual releasing — First release the product inhouse, then to beta testers and only then to the clients.
  逐步发布-首先在内部发布产品，然后发布给Beta测试人员，然后才发布给客户。

The list I gave above is partial, but the idea is clear. We should define what our quality standards are and how we are going to meet them. Once we put our strategy on paper, then it is much easier to make sure it happens.

我在上面给出的列表是不完整的，但思路很明确。 我们应该定义什么是质量标准以及如何达到这些标准。 一旦将我们的策略付诸实践，确定它的实现就容易得多。

尽早发现问题 (Find Problems Early)

Another important concept is that you should catch your defects as soon as possible. Whether it be design problems or bugs, you want to become aware of it as soon as possible. The chart below, which was created by IBM System Sciences Institute, demonstrates this nicely:

另一个重要的概念是您应该尽快发现缺陷。 无论是设计问题还是错误，您都希望尽快意识到。 由IBM系统科学研究所创建的以下图表很好地演示了这一点：

The Cost Of Fixing Bugs Depending On Discovery Stage

根据发现阶段修复错误的成本

According to their research, solving problems after releasing the product costs 100 times more! The message is loud and clear. Your quality strategy should focus on the early stages of the development process when it is cheap and easy to fix them.

根据他们的研究，发布产品后解决问题的成本要高出100倍！ 信息是清晰的。 您的质量策略应着重于开发过程的早期阶段，即便宜且易于修复的早期阶段。

结语 (Wrapping up)

I discussed three of the main pillars of software project management — developing something relevant, doing it on time, and with high-quality. Each one of them is a whole world and I covered just a fraction of them. Yet, implementing even one of the principles I went over will improve your chances to have a successful software project. It takes time and effort to apply them, but it will be totally worth it.

我讨论了软件项目管理的三个主要Struts-开发相关的东西，按时进行并具有高质量。 他们每个人都是整个世界，而我只介绍了其中的一小部分。 但是，即使执行我所遵循的原则之一，也将增加您成功完成软件项目的机会。 应用它们需要花费时间和精力，但这是完全值得的。

翻译自: https://medium.com/swlh/software-project-management-101-3035ef521d47

软件项目项目管理流程