完成我在IBM的最新项目的工作后，我们一直在进行总结回顾和经验教训。对我来说，这次项目一个主要的变化就是引入了项目管理的相关理论以及方法论。当我作为一名设计师开始工作时，我并没有太多的技能，而且设计也是我比较擅长的领域。所以我想我会分享这方面的经验，还有我接下来的一些计划。
我最近读了两篇文章，并且这两篇文章对我产生了较大的影响。一个是David Byttow 杰出的作品Effective Technical Leadership。大卫从研发的角度来看待领导力，但他所提出的许多观点是广泛适用的。开发或设计等技术职位领导需要什么？作为领导者，除了常规开发人员或设计师之外，还有什么责任？
我认为另一篇高度相关的作品是Erika Hall的Let's Stop Doing Research 。Erika关注于高效率的研发实践，但有一个领域交集，在于优秀的设计需要一个高效率的整体环境。设计师需要成为优秀的设计师，但他们也需要创造可以完成伟大设计的环境。我们必须能够建立一个基础框架，并且保障研发与设计工作的一致。
挑战
我不相信作为设计师的项目管理与其他角色的项目管理有着根本的不同。尽管如此，从设计师的角度来看，值得一提的是应该把项目管理知识放在比较重要的地位上。
1.跟踪和优先级
现代产品设计涉及许多保真度级别的大量工作。有多个版本，各种功能，不同类别的用户，早期概念，原型，风格指南，客户演示，以及研究活动。能够跟踪正在进行的所有工作，所有要做的工作，以及它与实际交付的关系是至关重要的。作为设计主管，我需要跟踪我们的研发任务的细节。当然作为一个开发利益相关者，只需要知道设计在当前里程碑/迭代等方面的工作内容。因此，在内部需要跟踪设计团队的详细工作以及在外部将设计进度与项目进度结合项目目标进行跟中。
这里当然还有优先级的问题。如果确定了新的工作项，下个星期是否可以完成？其他工作项对新的工作项会有什么影响？为了回答这些要求（而不是不断的灭火），你需要清楚地知道你有什么工作，需要多少时间，以及你为什么要这样做。没有这个清晰度，你就会像无头苍蝇一样。一旦进入多任务并行阶段，在执行过程中，可能有太多因素会对生产力产生巨大的影响。而且，这也带来了风险。良好的跟踪使优先级定义更容易，并通过将并行工作保持在最低限度，工作效率将会更高。
2.参与和确认
良好的项目管理对于在正确的时间从合适的人获得正确的投入也很重要。对于一个给定的工作项，你需要引入合适的人做出来完成。特别是在交互设计这样一个需要大局观的领域，非常多的细节需要考虑。你如何确保参与到具体工作中的团队成员都精准工作，而不用事后再做补救动作。
适当时间点原则：为了保持团队的畅通和进步，在适当的时间点把应该拉入团队的人全部拉进来非常重要，这样可以很大程度保障不用事后补救。尤其需要说明的是，很多时候我们认为不应该被拉入团队进行相关讨论的人员，往往他们就是导致需要事后补救的导火线。
Mr.Right原则：这条原则是指让项目利益相关者，客户乃至用户在合适的时间点验证正在进行的设计是否正确。这需要在你认为主体设计框架成型，并且所有交互进入可理解的情况下，将相关领域的技术专家（也可能是研发团队成员）拉入效果评审，并且听取他们的建议。这样做可以确保以后不需要浪费很多时间来进行修改，同时还可以保障不用浪费时间去完成一些没有价值的工作。
正确告知方式原则：这条原则意味着不仅要听取人们对项目的意见，而且要关注怎么将信息传递给其他人。例如，给大家展示一个Balsamip线框图，然后告诉大家里面的字体真的很丑。这种解决方案的意义在于，让所有的项目干系人都很够非常清晰的看到某个问题点。同时，这样大家可以明确了解你当前的工作进展，以及当前工作项所涉及的领域规模。不能仅仅说“我们正在完成这个工作项”，而应该表达“我们站在免费用户的角度，正在审视当前这个早起移动端设计的优劣点”。
下面是我在设计团队中看到的一些现成问题，我认为引入项目管理思维将能够解决这些问题。
· 如何跟踪工作（为自己和他人）
. 如何定义与利益相关者的优先级
. 如何让其他人可靠并有目的的参与
. 如何快速一致地验证我们的方向
我们之前有哪些工作是无用功？
以我最近的项目举例，之前我的项目管理能力（后见之明）非常可悲。我们会保留一个wiki的工作清单。我们将这个分配给每个人。如果有人问要干什么，我会把人们指向一个wiki页面。
我也常常更新那个wiki页面。但是它缺乏很多细节，因为它只是一个电子表格。往往具体工作细节或者需求在另外一个地方。如果某个成员需要了解具体需求，那么就要跑到另外一个地方去寻找需求。这个方式可以从某种宏观程度上看到工作进度，但是能够让整个项目更加有效率的每日进度/每日任务或者需求细节就无处可寻。
这种工作方式，虽然能够保证我们好歹有活干，但有这还有很多需要改进的地方：
1. 它并没有提供一个保持我们的跟踪最新工作项的好方法。
2. 很难建立设计工作和项目目标之间的联系。
3. 无法在精准的时间点给项目干系人一个反馈。
4. 除非我们完成了整个工作，否则项目干系人只能傻等。
5. 必然的，任何其他人无法及时介入当前项目，因为所有东西都是一团乱麻。而且设计团队也只能从其他团队获取到非常有限的支援，因为无法向其他团队做到工作项透明。
那么我们做了哪些改进呢？
我们在上一个项目周期中，作为设计团队所取得的根本性进步，对于我们执行中的工作而言，已经变得更加透明。当然，这一直是我们的目标，之前我们已经在做迭代，设置里程碑和建立路线图，但是我们没有找到真正的方法论。在最新的项目中，我们已经将我们的计划和跟踪转移到了Github + Zenhub的组合上。对我们来说，它已被证明是轻量级和开放性的完美结合。结果是我们可以追踪每个工作项，而且比以前更精确。
图一
Github是一个用于存储代码和管理工作项目（问题）的开发工具。Zenhub是Github的一个插件，可以在一系列泳道中显示您的工作项目，您可以通过把工作项在不同泳道中来回拖动来追踪进度。我知道很多团队设计团队已经使用Git + Zenhub或类似工具，并且通过这个方式与他们的开发团队合作。我所主张的是，即使你的开发团队没有将他们的代码存储在Github中，也可以直接用这个来做项目管理。
我们使用Github来跟踪我们的整个ToDo List。由于创建问题非常简单，我们在跟踪工作方面比过去更好。因此，我们正在追踪我们作为设计团队所做的各种工作，从构建视觉系统到原型设计到研究活动。它每天都在变化，而不是偶尔变化。
我们将迭代周期定义成一周，并且向迭代列表中注入工作项。这意味着我们了解作为一个团队我们上周完成了什么，本周我们在做什么，以及下一个要做的重点。其他利益相关者可以看到完全一样的报表。如果缺少工作，他们可以解决问题，同时我们可以分类。
图二
我们在Git中确定问题的规模，以便大致了解我们所做的工作。我们的问题规模不是说需要花费多少小时，而是用故事点这种相对值。换句话说，“这个工作项是大于还是小于标准值”。而不是利益相关者告诉我们应该花多少时间来完成一些工作，我可以参考相同规模的类似工作。我可以看到我们上周完成了72个工作点，下周我们有61个点。这表明我们可以从积压工作中获得更多的工作，或者如果在最后一分钟有新的需求，我们可能会将他们装入本次迭代。如果我不能将这些需求加入本次迭代，我可以清楚地了解为什么，以及我们可以有一个非常直接的讨论，哪个工作是最重要的。
我们有明确的任务，随着工作的进展，在人们之间来回传递任务进度信息。设计师目前正在进行一些工作是显而易见的。其他团队人员可以通过链接获取草图文件，或我们直接提供任务的截图显示进度。我们可以过滤哪些是进行中的工作，或者在调研部分关闭之前还要进行多少次采访。我可以很容易地找到所有进行中的视觉设计任务。
我们可以通过在评论中直接@其他利益相关者，这样他们直接参与到设计工作中，并且我们可以直接沟通。他们反过来可以把他们正在做的工作与我们正在做的工作联系起来。代码或开发任务可以与设计任务相关联，以帮助明确谁在做什么，并与进度保持联系。假如对某个问题感兴趣？大家可以订阅它。设计师不需要在向项目的利益相关者进行进度汇报，因为这些利益相关者可以自己追踪。
开始改变
任何项目回顾的关键是要找出什么是你的工作，什么不是。千万别做无用功。例如，Spotify有一些关于他们的产品团队如何工作的精彩视频，但是如果您认为“成功”意味着复制他们，我认为您将注定要失败。他们的团队所做的大部分工作就是根据他们之前一个月的工作进行优化。他们是A / B测试他们的方式从而得到一个更好的项目模型。根据你自己的项目团队来进行适合自己的流程优化。
您团队的正确流程取决于您项目的成熟度。你的项目必须长大，而不是复制别人的行为。我的团队相当于青少年时代。我们是某人的哥哥，还是别人天真的孩子。所以如果你的项目管理存在问题，或者你看到了糟糕的项目管理的症状，但不知道从哪里开始改变，也许我的例子可以指出一个或两个有用的步骤。
我看到很多设计团队管理不善，或者依赖于他们的产品团队现有的管理模式。他们不必真正思考什么样的管理模式最为妥当。他们在项目运行平稳的时候运行顺利，但是出现问题时往往将直接崩溃。特别是今天，Design和UX设计是对产品设计负责的时代，太多的设计团队正在试图实施重大的文化变革。如果我们理解这样的方法来可以有效地运行项目，那么我们就能够更好地为成功的设计创造环境，我们也能够在关键领域输出领先的设计成果。如果你的项目运行顺利，你知道为什么吗？如果不是，你知道你可以做些什么来改善它吗？
如果你的时间表受到利益相关方的挤压，他们认为应该“只需要几个小时”；如果你被告知没有时间进行调用；如果你经常被要求加入额外的工作，并且不得不偷工减料，那么看看你是如何管理自己的工作的。像这样的模型可以帮助你更清楚地谈论你已经有了什么承诺，做了多少工作，以及你的工作在未来的冲刺中的样子。这并不意味着你永远不需要做比你想要的更多的工作，但这意味着你正在谈判什么工作最重要，而不是“适应”。新工作的影响变得更加明显。
如果你明白这个价值，那么希望我使用这些工具来管理我们的工作项目的具体例子会给你一些类似的指导。
下一个改进的想法
目前我们正在跟踪的工作是相对顺利的。也就是说，这是一个待办事项列表，偶尔通过链接和评论相互关联，但主要是一大堆任务。它也分布在几个不同的仓库中，因为与项目规模有关的各种原因，我们有几个仓库（设计，UI，后端，原型等）。因此，项目团队应该清楚地了解与故事相关的任务，并与客户价值相关联。我们经常尝试编写用户故事样式问题（“作为用户___我可以____这样做”），但是很快就会被与实现它们相关的小型工作项目的数量所压倒。
Zenhub最近发布了一个更新，包括史诗规划，允许创建更高层次的任务（Epics），我们可以将一些零碎任务规整到Epics中。因此，我的下一个里程碑计划是与我们的产品管理团队合作，更好地将我们的高级史诗融入到我们细致的计划流程中。意图是使用我们已经拥有的设计活动，开发工作项目，复制和营销项目。我希望这将大大提高我们跟踪跨部门任务的能力，并估计实施史诗剩下的项目工作。
图三，图片来源Zenhub.io
汤姆罗奇——IBM用户体验、互动设计师，游戏玩家和极客，英国剑桥移民到德克萨斯州奥斯汀。主张为自己说话。
汤姆罗奇为KITA专栏作家，本文未经许可，禁止转载。
网友评论