[译]你须要一位英雄：项目经理

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

/**
 * 谨献给不知何时能再见的小黑
 *
 * 原文出处：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）的应用程序。

总结

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

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

• 本做品采用知识共享署名-非商业性使用-相同方式共享 3.0 未本地化版本许可协议进行许可。
• 本文翻译做者为：dogstar，发表于艾翻译(itran.cc)；欢迎转载，但请注明出处，谢谢！