PHP项目管理

Whether we like it or not, unless we are doing a hobby project just for our own amusement, even the most technical among us are really just project managers who can code. And, as a project manager, we can experience the heartbreak of project failure.

不管我们是否喜欢，除非我们只是出于娱乐目的而做一个业余项目，否则即使我们当中技术最强的人实际上也只是可以编码的项目经理。 而且，作为项目经理，我们可以体验到项目失败的伤心欲绝。

There are many ways in which a project can fail. It can fail because deadlines are not met, budgets are exceeded, the results are not what was required, etc. But, it can also fail emotionally; the project may have succeeded but people’s expectations aren’t met and there’s no sense of satisfaction or a “job well done.”

项目失败的方式有很多。 它可能会失败，因为未满足截止日期，超出了预算，结果不是所要求的，等等。但是，它也可能在情感上失败； 该项目可能已经成功，但是人们的期望没有得到满足，也没有满足感或“工作做得很好”。

So what can you do as a technical project manager to minimize your chances of adding “leader of a failed project” to your resume? The answer is: pretty much what non-technical project leaders do.

那么，您作为技术项目经理可以做什么，以最大程度地减少在简历中添加“失败项目负责人”的机会？ 答案是：非技术项目负责人几乎可以做什么。

管理期望 (Manage Expectations)

It’s fine to think that reality is important, but everyone in the business world knows that what people think happened is always more important than what really happened, and the same is true for projects. Even some of the most successful projects can suffer from a failure of expectations that forever eclipses the good work that was done and the benefits received. And if the failure of expectations is serious enough, it can even undermine and derail other projects that were doing okay. So how do you manage expectations?

可以认为现实很重要，但是商业世界中的每个人都知道，人们认为发生的事情总是比实际发生的事情更重要，项目也是如此。 即使是一些最成功的项目，也可能遭受失败的期望，使他们永远无法完成已经完成的良好工作和所获得的收益。 如果期望的失败足够严重，那么它甚至可能破坏和破坏其他一切正常的项目。 那么，您如何管理期望呢？

First, make sure everyone is very clear on what the project is going to do, what the benefits will be, what is going to be required from the users, what resources are needed to support it, what other projects it might depend on, and what it is going to do. I know I listed that last point twice, but it’s really important! Many times users hear what they want to hear, and it can take more than a memo or a quick conversation to set this straight.

首先，确保每个人都非常清楚该项目将要做什么，将带来什么好处，用户将需要什么，支持它需要哪些资源，它可能依赖于哪些其他项目以及它会做什么。 我知道我列出了最后一点两次，但这确实很重要！ 很多时候，用户听到了他们想听的内容，这可能不仅仅需要备忘或快速对话即可确定。

Be especially careful about what upper management says about the project, both right out of the gate as well as later on as the project progresses, and move quickly to correct any false claims that are made before they can become accepted wisdom and “part of the project scope right from the start.”

特别要注意高层管理人员对项目的评价，无论是在项目后期还是在项目进行中，都应谨慎对待，并Swift采取行动纠正所有提出的虚假主张，使它们成为公认的智慧和“一部分”。从一开始就是项目范围。”

At the same time, move just as quickly and politely to deal with any negative talk you hear about the project. The idea is not to squelch mutinous talk (although getting a list of names is not a bad idea, you know, for later) but rather to find out if it’s a misunderstanding, mis-statement of the facts, or if this is something that could turn into a problem later and should be dealt with promptly, either by modifying the project specs or taking another look at the basic assumptions.

同时，以同样快和礼貌的态度来处理您听到的有关该项目的负面言论。 这个想法不是要压制mu不休的谈话(尽管获得名称列表不是一个坏主意，以后再知道)，而是要找出这是否是对事实的误解，错误陈述，或者这是否是事实。可能会在以后变成问题，应该立即进行处理，方法是修改项目规格或重新考虑基本假设。

不要传统，要迭代 (Don’t Be Traditional, Be Iterative)

In a traditional, waterfall type project, you develop a project plan that starts at the beginning and goes on to the end and stops with an overall time and dollars estimate. Don’t do that. Instead, use an iterative, agile project model where each step ends with a readily testable, highly visible product that people can measure their expectations against.

在传统的瀑布式项目中，您要开发一个项目计划，该计划从开始就一直进行到结束，并以总体时间和预算估算停止。 不要那样做 取而代之的是，使用迭代的敏捷项目模型，其中每个步骤都以易于测试的，高度可见的产品作为结束，人们可以以此来衡量他们的期望。

Despite the similarities, technical projects are not like building a bridge. The main unknowns for bridge building are the soil characteristics you’re putting its footings into. Once that is assessed, much of the uncertainty is taken out. Technical projects may not have more variables, but they’re spread out through the life of the project and you never really get to the point, until you’re done (maybe), where all of those variables are known. Waterfall is based on the fact that unknowns will be assessed and compensated for going it. For various reasons, tech projects don’t seem to work that way and so waterfall is a poor model.

尽管有相似之处，但是技术项目并不像建造桥梁。 桥梁建筑的主要未知因素是您要立足的土壤特性。 一旦进行了评估，就消除了很多不确定性。 技术项目可能没有更多的变量，但是它们在项目的整个生命周期中散布开来，直到您完成(也许)知道所有这些变量的时候，您才真正达到目的。 瀑布基于以下事实：将评估未知因素并对其进行补偿。 由于种种原因，技术项目似乎无法正常工作，因此瀑布技术是一个糟糕的模型。

The main problem with waterfall, however, is that it works to focus people on some nearly final ‘test’ stage. It’s not designed to support situations where testing starts almost on day one. As a result, problems, even major problems, won’t be identified until the project is pretty much complete.

但是，瀑布技术的主要问题在于，它可以使人们将注意力集中在几乎最后的“测试”阶段。 它并非设计用于支持几乎在第一天就开始测试的情况。 结果，直到项目完全完成，问题才得以发现，甚至是重大问题。

Agile, on the other hand, is all about iteration: work for two weeks, produce something that is real and have users test it, then repeat. There’s no Power Point presentations or marathon team meetings, just something people can log into and play around with. That’s what gets their attention, don’t you know.

另一方面，敏捷就是迭代：工作两个星期，制作出真实的东西并让用户对其进行测试，然后重复。 没有Power Point演示文稿或马拉松团队会议，只有人们可以登录并玩耍的东西。 这就是引起他们注意的原因，您不知道。

While you’re doing Agile, I would also suggest doing Scrum. They don’t have to be done together but I think it’s a good idea. You know what people like? They like things that are short; it starts, it happens, it’s over. Bang. That is the essence of Scrum – frequent, very short, no time to get comfy or to beg off, project team meetings where we talk turkey and we talk fast. It prevents anyone from forgetting about the project and what it’s doing, and doesn’t take up a ridiculous amount of time from their day.

当您在做敏捷时，我也建议您做Scrum。 他们不必一起做，但我认为这是个好主意。 你知道人们喜欢什么吗？ 他们喜欢矮小的东西。 它开始了，它发生了，它结束了。 砰。 这就是Scrum的本质-经常，很短，没有时间去取悦或乞讨，召开项目团队会议，我们会说土耳其话，而我们要聊得很快。 它可以防止任何人忘记该项目及其正在做什么，并且从一天开始就不会花费大量的时间。

And what does all of this do for you? Agile and Scrum allows you much more visibility into how you are doing on the overall project estimate. With serious user testing going on regularly, you get an early heads up on things that might have to be added to the app and things that can be pulled out. If there are major problems, you can begin the redesign very early in the process. This makes you proactive, which is sort of like having nice hair; it always pays dividends and puts the project in a positive light.

这一切对您有什么作用？ 敏捷和Scrum使您可以更直观地了解总体项目估算的工作方式。 通过定期进行严格的用户测试，您可以尽早了解可能必须添加到应用程序中的内容以及可以撤消的内容。 如果存在重大问题，则可以在此过程的早期就开始重新设计。 这使您更加主动，有点像染发。 它总是派发红利，使该项目具有积极意义。

范围蠕动的邪恶 (The Evils of Scope Creep )

More projects are doomed by scope creep than anything else. Scope creep causes projects to be late, over budget, and failing to meet to the subjective expectations of the guest audience. So, don’t let it happen. Like enjoying time with your in-laws though, I know it’s easier said than done.

范围蔓延注定了比其他任何项目更多的项目。 范围爬行导致项目延迟，超出预算，并且无法满足来宾观众的主观期望。 所以，不要让它发生。 就像和您的公婆一起度过时光，我知道说起来容易做起来难。

In its most common form, scope creep occurs when someone brings up a point and introduces it with the words “but this was the way we wanted it from the beginning.” And they’re probably honest; they may have genuinely thought that feature X was going to perform function Y and that in fact was the main reason for the project’s existence in the first place. And so, because it was suppose to be in the application from the start, you add it in. Sometimes the impact of this is inconsequential, but most of the time it isn’t. And this can happen not just once in a project’s lifecycle, but it may happen over and over again. So what do you do?

以最常见的形式，范围蔓延发生在有人提出一个要点并用“但从一开始就是我们想要的方式”一词来介绍它时。 他们可能很诚实。 他们可能真的认为功能X会执行功能Y，而实际上这实际上是该项目存在的主要原因。 因此，由于应该从一开始就将其添加到应用程序中，因此可以将其添加进来。有时，这种影响并不重要，但在大多数情况下并非如此。 这不仅会在项目的生命周期中发生一次，而且可能会一遍又一遍地发生。 所以你会怎么做？

First, whatever else, you have to be diplomatic. You may feel like leaping across the table and grabbing someone’s throat, you have to remain calm and keep the balance of power on your side. Go back to your initial project statement and show that the request was never discussed, much less identified as an integral part of the application (that’s where having a very clear and detailed statement of the project is critical).

首先，无论如何，你都必须外交。 您可能会觉得自己像跃过桌子，抓住别人的喉咙，必须保持镇定并保持力量平衡。 回到您最初的项目声明，并显示从未讨论过该请求，更不用说将其确定为应用程序的组成部分了(在该位置，非常清晰，详细的项目声明至关重要)。

Second, to limit the number of times scope creep comes up, you should make sure that your users are doing a good job at their iteration testing. Scope creep is most damaging when it occurs later in development where a lot of retrofitting which is more or less invisible to the user has to be done. Iterative testing, rather than just talking about how the project is going, is a much better way to ground the user in just exactly what the system does.

其次，要限制出现范围蠕变的次数，应确保用户在进行迭代测试时做得很好。 示波器蠕变在开发的后期出现时最具破坏性，在这种情况下，必须进行许多用户几乎看不见的改装。 迭代测试，而不只是谈论项目的进展情况，是使用户完全了解系统功能的一种更好的方法。

Ultimately, the problem is two-fold. First, you may not have been detailed or specific enough in terms of what the app will and will not do; both sides need to be spelled out. Second, you need to keep in mind that your users probably are not paying 100% attention when you talk or when they read something you have written (even when they are in a meeting for the specific purpose of hammering out what the app should do). Don’t expect that because you have explicitly spelled things out that people will know. A good technique is to lay out your plan and then have them tell you what they think the system will do and what they can expect from it. Record the session – you can use it at the trial.

最终，问题是双重的。 首先，您可能对应用程序的作用和不做的事情不够详细或不够具体； 双方都需要阐明。 其次，您需要记住，您的用户在交谈或阅读您写的内容时可能不会全神贯注(即使是在开会时，他们也很想了解应用程序应该做什么) 。 不要期望那样，因为您已经明确阐明了人们会知道的事情。 一项好的技术是列出您的计划，然后让他们告诉您他们认为系统会做什么以及可以从中期望什么。 记录会话-您可以在试用版中使用它。

Sadly, there is no cure for preventing scope creep. The best you can do is to try to prevent it, and when it rears its ugly head, try to head it off as best you can. In the end, there’s a good chance you’re going to have to do what your user wants, but don’t just do it; make that an addendum to your project. Spec out the steps required to do it, the time it will take, the impact that will have on everything else, and then get approval from your user base that they really want this done.

可悲的是，没有办法防止示波器的蠕变。 您可以做的最好的办法就是防止它，当它抬起丑陋的头时，请尽力将其抬起。 最后，您很有可能必须做用户想要做的事情，而不仅仅是做它。 将其添加到您的项目中。 指定执行此操作所需的步骤，所需的时间，对其他所有内容的影响，然后获得用户基础的认可，他们真的希望这样做。

提防奇怪的东西 (Watch Out for Weird Stuff )

Watch out for weird stuff. I don’t mean weird requirements, but things that may be new to your team or your environment. For example, if you are building an application that accepts credit card data, do you really understand PCI? Or, maybe you are going to switch from CodeIgniter to Lavarel. You are going to need some extra time (even beyond the normal curve). Keep an eye out for things that might trip you up.

提防奇怪的东西。 我的意思不是怪异的要求，但可能对您的团队或您的环境来说是新的。 例如，如果您要构建一个接受信用卡数据的应用程序，您真的了解PCI吗？ 或者，也许您将从CodeIgniter切换到Lavarel。 您将需要一些额外的时间(甚至超出正常曲线)。 留意可能会使您绊倒的事情。

摘要 (Summary)

The bottom line is this: project management is a game you can’t win. If you come in way under budget and time, it’s as if everybody is going to think you’re a sandbagger and won’t believe your estimates again. Keep your eyes on what’s important. Be specific, be nice, be agile, and hope for the best.

底线是：项目管理是您无法取胜的游戏。 如果您受到预算和时间的限制，似乎每个人都会认为您是个沙堡，不会再相信您的估计了。 留意重要的事情。 要具体，要友善，要敏捷，并希望最好。

Image via Fotolia

图片来自Fotolia

翻译自: https://www.sitepoint.com/php-project-management/