[译]你需要一位英雄：项目经理-CSDN博客

2019独角兽企业重金招聘Python工程师标准>>>

你需要一位英雄：项目经理

/**
 * 谨献给不知什么时候能再见的小黑
 *
 * 原文出处：https://www.toptal.com/qa/you-need-a-hero-the-project-manager
 * @author dogstar.huang <chanzonghuang@gmail.com> 2016-04-23
 */

勇敢的、在内心有一个应用想法的、且在银行有一点钱的企业家啊，这篇文章是专为你而准备的。你在鸡尾酒餐巾写下的图表将会影响整个世界，装满钱的大卡车已经派往你的房子。为了确保他们能按时到达，这里有一些可使产品周期运转顺畅的简单建议。

为什么在首位需要一位项目经理

"计算机程序是人类制造的最复杂的东西"，道格拉斯·克罗克福德说道。可能你没听说过这个名字，但对于程序员来说他真的相当有名。他现在是一位贝宝资深软件架构师，并且开创了各种很酷的技术，此部分已超出本文的范围。他是知道很多关于如何工作于大型项目的人。

就我个人而言，我已经编程了13年，甚至现在，从某种程度上讲，每一个项目都把我带进了未知领域。有太多太多不同的技术，并且新技术正以如此惊人的速度在创造中，以致于我从来都不觉得我完全可以知道发生了什么。纵使每个项目都有其独特的挑战，这里仍然有一些常量：

项目面临时间压力
预算比我想的更少
我比客户想的更贵
我没有像客户想的那样完全倾听
客户没有像我想的那样解释完整

很明显，我们需要一位保姆。一位可以介入建立基本规则，让每个人保持诚实，并确保我们没有忘记重要东西的人。一位可以促进各方相互沟通的人。

这个人，这位英雄，就是项目经理。

为什么项目经理在一个箱子里？他是一只猫。猫爱箱子。

当我开始写这篇文章时，Toptal没有提供与项目经理的联系，但现在有了。协作！我只能想象阅读以下建议的当权者意识到了他们缺少了一个很好的机会。

为什么一个程序员产生不了好的项目经理

除了项目管理协会的认证外，项目经理能带来的最重要的东西是经验。因此，要有很多程序员才能产生相当不错的项目经理；我们比其他人更有技术项目的经验，我们分析的头脑擅长于编目信息以及设置具体的目标。

上帝才知道，你支付给我们足够多了，所以看起来期望我们可以管理自己而不是强制你也为其他人的时间支付更合理，对吧？

好吧，对于初学者，你是为我们写代码而支付。

当我们从编程发呆中走出来，要去决定优先处理什么，或者讨论这周实际上要准备完成多少时，没写代码。接着它至少需要10分钟才能回到刚才的“空间”，尤其是如果在刚刚的会话中紧张过度的话，很可能是在争论特性优先级。呜呼，我知道，但这全部都是关于最有效使用昂贵的资源。

最重要的是，我们真的会只见树木，不见森林。如果你从这篇文章中没学到任何东西，那么请记住这一点：当我花了整天时间在盯着一些具体的bug时，我的大脑失去了对更大蓝图的追踪。

当我修复了这些bug，大脑会奖励我，并且我会认为已经完成了很多事情，现在可以玩玩视频游戏了。当有人提醒我首页还是有问题时，真是让我大吃一惊，因为我已经花费了整整一天在把整个项目的每一小块的详细的知识都填充到了我的大脑，还排序了剩下哪些是忘记的。这就是我的大脑是如何工作的，以及其他很多的程序员也有类似的心理。

当我们从编程发呆中走出来做项目决定时，没写代码。

为什么一个客户产生不了好的项目经理

那么，如果我们程序员不想负责项目经理做的事情，那么它势必会落到客户的头上。这是你的钱。这是你的愿景。不管怎样，你最终都会为全部的事情负责。

然而，你也有很多牌。

很多客户像我们其余人一样都是平凡地进行日常工作，有的甚至饱受拖延或健忘之苦。尽管这当然不是在描述你，请找一位专业记事者（Professional Rememberer）在身边以便你可以抽身回到更重要的工作，让整个项目活下来。

如果你已经工作过，或者监督过类似规模的技术项目，你真的需要为项目找一位好的项目经理。如果还没有，请不要低估能够预测可能会发生的问题的人的价值。时间估算终归是时间估算，而bug往往会在意料之外突如其来。对于另一个（如果只是业余的）应聘者的花费是值得的，可以有一个人在身边并且知道流程中哪部分需要，或者很可能需要，最多关注。

就以质量保证（QA）为例。合适的QA是任何项目中想得到自己想要的必不可少的东西，但它从来都没得到应有的重视。一位好的项目经理会最大化有限的QA资源，还为你质量保证了你的程序员。有时候，我们会越界；有时候，我们会犯错。你需要一位技术熟练的人充当监督的角色，以确定你的程序员是否仅仅有一个休息日，或者是否他或她实际上与项目格格不入。早期远离人员问题可能意味着项目的生死存亡。

最后，即使是你，哦我至高无上的客户，有时也需要一点点检查或者平衡。这是我最难写的，因为我们计算机程序员没有因我们率真的本性而闻名。我只想说，我已经做过很多这样的项目：客户坚决认为每件事都是优先级最高的并且每件事都必须完成。我毫无疑问这一点是对的，这些可怜的客户，并没有掌控好一天中小时的数量。最终他们没有得到他们期望以及/或者不期望的正向结果，并且我觉得这样的后果是可以避免的，如果客户把评估工作量的权威委托给一位项目经理并且婉转地但坚定地保持对项目的进行检查。在大多数技术项目需要时做出冷静的判断很难，而这又是你的想法，你的钱。电脑也不会关心你或我是否哭、是否对它尖叫。（我知道这点是真的因为我试过了。）

产生一位好的项目经理的非完整技术清单

不管你是决定忽略前面的1000多个字且自己管理项目，还是准备聘请某人但想知道更多关于此流程的东西，这份清单都能帮助到你。我从来没有（正式）当过项目经理，所以我不能说哪个工具给定哪个项目使用，但我通过这些技术取得很好的成功：

里程碑

当开始一个新项目时，很多人直观地知道把项目划分成稍微更易于管理的块很重要，而每一块值得工作数周到数月不等。在项目最初，有一个启动会议来展示这些里程碑是很好的。对于如何到达他们有点模糊是没关系的，最重要的事是保持在每个里程碑后进行检查以便从大家增加对项目的了解中收益，确保项目里程碑仍然（大致地）和最初相信那样吻合。

时间评估

我们程序员绝对讨厌评估因为我们都知道他们是错的，而且还会用来和我们作对。他们是错的没关系，因为根据定义，他们是基于一把的未知。他们会用来和我们作对也是没关系的，因为我们的工作是相当轻松的而它无伤大雅。

所以每次开始工作于一个新的里程碑时，随意要求评估。你应该期望每个主要的特性伴随着一两行大致地评估了此特性需要花费多长时间。我通常会作出乐观的评估，然后质疑它。通常情况下，这个额外的时间占了看不见的陷阱。

用户故事

用户故事是应用中某个单一功能的简要描述。他们作为重要特性的纪录是有用的，并且应该是一口大小、可以适合索引卡并通常伴随着少量的绘画。更为重要的是，他们充当着客户想要什么和程序员需要告诉电脑做什么之间的桥梁。对于你，对于客户来说，他们都是足够简单的，在几分钟内就可推敲出来，但细节对于我们程序员则是水很深而不能轻易涉足入内。

对于用户故事的快速认识，我找到了这些由Mountain Goat Software 和Roman Pichler提供的高品质的简洁指南。关于更多关于“敏捷项目管理”的整套理念，请试下这篇由Paul Barnes发布的Toptal博客：对敏捷项目管理的终极介绍。

布局（样板）

这不是一篇为什么你需要一位设计人员的文章，因为我觉得大部分客户已经明白，但值得重复，因为如果把一个具体的、深思熟虑的设计摆在你的程序员面前的话，你会看到生产力大大提升了。每一次我们需要做出一个设计决定时，我们需要离开这个“空间”，并且每一次因为没有提供最终草稿而需要返回以及改变某些东西时，好吧，你在做数学题。。。我不是在抱怨，因为设计是有趣的，但以我的经验，这是可以避免的、额外收费的时间的头号资源。

大部分设计者在Adobe Photoshop，Adobe Illustrator，或者Sketch中提供布局（compositions），也称之为 comps。如果你正在自己做，你可以使用诸如Balsamiq或者InVision
这样无数的在线工具的其中一个。这个comp不需要有和最终成品一样的颜色或者风格（因为这些以后会很容易改变），但请花一些额外的时间确保全部的UI元素都展示并列入在内。

站立会议

漫长的会议有时是不可避免的，但你真的不想让你的程序员负荷过载或者占用他们过多不必要的时间。我有些客户看起来期望我能记住在一个两个半小时会议里说过的每件事；他们非常失望。站立会议通常限制在15分钟之内，按照惯例这期间都是站着的。站着是为了确保每个人都参与进来，同样也是为了保持会议简短。

在站会期间，每个人围绕成一个圈并进行扼要的状态汇报，以便全部团队成员同步其他人的最新进度。关于站立会议，更多请见：ExtremeProgramming.Org。如果你们都是远程工作或离岸开发并且不想每天让每个人上Skype，你可以试下诸如15Five这样有趣的工具作为变种的站立会议。15Five让团队成员可以在他们方便的时候提供输入，并且它会提示调查问题以便梳理出更深入的回应。

清单系统（Ticketing System）

虽然任何人都可以维护一个即时贴和Google Docs（以不同的颜色高亮每个人的任务）这样的系统，但这真的没必要；很多人已经为你尝试解决了这个问题。Basecamp和Trello因容易使用而闻名，而Pivotal则试图把整个“敏捷” 理念封装进一个非常光滑的包。不管你的选择是什么，一个好的清单系统至少应该可以：

创建任务
分配优先级和截止日期
连接任务和子任务
分配不同的决议，诸如“已完成”或“测试失败”
展示指派给特定用户的全部任务

当一个项目经理给你展示了40个标注明亮红色、优先级最高、并且都在同一天截止的清单时，你就能确切地明白这个项目鸟眼视角的价值了。

你不需要使用即时贴追踪开启的Bug。

源码控制

你可能从来都不会看一眼项目版本控制系统中的代码，但源码控制（或者版本）在我们的清单里是最重要的工具之一，是可以想象得到的最伟大的备份系统。

大部分现代项目使用Git，尽管有时你会在已经有一段时间的项目上使用SVN。Github允许你免费托管无限制的公共仓库（所以，它包含了世界上大部分开源项目），而Bitbucket则允许你托管无限制的私人仓库所以是商业项目最喜爱的选择。

不管你选择了哪个版本控制系统，它远程存储了我们的代码以防发生不测，再加上强制我们编写一小段注释来描述我们刚做了什么以便追踪每一次“提交”的代码。这可以防止不同的开发人员覆盖了其他人的代码，我们可以看到在一个给定的时期内全部的修改，我们还可以创建新的代码分支存放不是马上用到的特性。甚至还有一个称为 “blame”的命令，显示了给定的一行代码是谁负责的，以及是何时提交的。

源码控制是最伟大的。

测试驱动开发

这是相对昂贵的实践，这意味着在对于几个自由职业者预算有限的项目里不经常使用。所以你，作为一个先行者，不应该为没做这点而感到糟糕，但我必须在你的面前提到这个理念因为它提供了对抗Bug的终极防护。基本上来讲，你的程序员花费了额外的大量的小时在于编写测试（很小的代码块），以确保应用的指定部分以特定的、可预见的、可重复的方式运作。例如，我可能编写一个测试断言当点击了“登录”按钮，会打开一个带有用户名字段的弹出框。

测试之美就是一旦写好了测试，我可以马上通过一个简单的命令来运行他们。如果写了200个测试，我可以在发布一个新的应用版本后运行他们以确保没有在这200个特性中引入任何的bug。它并完美，但它能尽可能让我们接近保证无bug（至少少量bug）的应用程序。

总结

这是我所知道的关于项目经理的全部。我不确定有多少会通过项目管理协会的调集，但这是我从过去十年中所参与的网站项目中总结出来的全部经验。当然，我推荐你招聘某个人以便能从他或她的经验中获益，但我希望即使你做不了什么也能从这些信息中找到有帮助的。你将是这个项目上最终的权威，所以你对它内部工作了解得越多，你就越有可能带领它走向胜利。

------------------------