当你成为一个项目的管理者的时候，你应该如何去做好项目管理呢？

工作中有时难免会遇到团队部分职能缺失、人手不足等问题，为了整体项目能够更好的推进。我们除了完成本职工作以外，还会主动去承担一些其他职能的工作，如产品经理、运营、项目经理等角色以便目标达成、想法落地。

前段时间，本人有幸为自己之前负责设计的产品担任项目经理&产品经理&体验设计师，进行产品“体验改版”。该产品属于「后台运维监控」产品，负责大规模、批量化的集群运维及服务部署、服务升级等操作，是在企业中衔接基础硬件与上层服务的高复杂性、高专业性产品。改版内容则集中在前端框架与技术的重构、产品结构与信息的组织、交互流程与界面视觉的优化上。

首先介绍一下常见的改版方式：

（1）老版正常在线上使用，起过渡作用，重新搭建框架建立一个新的平台。功能逐步建立、完善，完成后迁移用户。

• 前提：需要有相对整体和成熟的设计方案，让大家对未知结果的投入达成一致；
• 风险：风险大，耗费资源相对较大，时间周期较长；
• 优势：可以从头思考、梳理，能从根本解决一些问题，优化的体感更强。

（2）在老版的基础上进行优化，整体架构保持不变，局部体验优化。

• 前提：业务合作中常见的设计合作模式，局部功能优化，跟产品同步迭代；
• 风险：较难从根本上解决遗留的体验问题；整个产品体验较差，局部体验改善容易被忽略；
• 优势：风险小，投入的资源相对较少，结果可控，见效时间快，较容易达到预期。

本次我所负责的产品改版选择的是「第一种方式」，风险相对较高。前期设计侧通过用户调研、痛点分析等设计方法的数据收集，已具备相应的数据支撑，明确改版的必要性；然后通过产出一版整体优化的设计demo来诠释设计思路，与业务方对目标达成一致，明确本次改版的关键内容和为用户解决哪些痛点。

鉴于业务内容的保密性，这里不对设计过程做过多讲解，本文旨在以设计师角度，如何看待项目管理的工作、职责，以及在整个过程中的收获和对设计本身的价值。

一、项目管理需要做什么？

一般项目经理（PM）在一个项目中的职能主要包括以下：

• 负责项目时间管理与进度把控；
• 协调资源来推动项目进度按计划进行；
• 平衡和适当的策略调整解决时间成本、资源间的相互制约；
• 确保项目干系人之间的顺畅沟通。

当承担多个角色时，工作职责和协作的范围边界就会被扩大。一般体验设计师需要重点关注在“需求对接”、“设计输出”、“前端开发配合”这三个部分，同时参与“项目计划”、“测试走查”这些环节。当站在PM角度，设计师除了关注本身的设计工作外，还需要关注整个流程中各环节参与者的配合与产出。

前期负责项目的用户调研与数据分析、项目落地的节奏计划、用户需求的收集与对齐整理；中期实现阶段关注设计、前端、后端的交付时间及质量；后期对测试bug的优先级进行规划与解决方案确定，直至完成上线交付。

作为设计师还要负责所有需求的设计产出。由于在这个项目中设计师身兼多职，因此会将需求PRD、交互&视觉的设计在一个demo中同时产出，节省前端的需求了解和查看成本，也缩减设计者多文件输出需求的时间。（当然具体工作分配要看项目投入的人力情况）

挑战对设计师来说是一定存在的，但是这样的机会确实也需要具备相应的前提：

（1）业务理解与熟识程度

• 对你所负责的产品、业务具有较深入的认识和了解；
• 了解用户使用中遇到的问题，并能针对问题提出有效的核心解决方案，而非单纯的美观。

（2）信任

• 在平时的合作中与业务方建立的信任；
• 合作同事间的信任与配合意愿。

（2）机遇

• 一般团队会有专业的pm和产品经理，但有些产品团队，人员配备不足；
• 产品体验方面得到上层重视，自上而下推动.

（4）老板支持

• 老板给予后盾与配合（自己的老板和业务方老板）。

二、经验教训

在设计师担任项目管理和产品工作的过程中，初期遇到很多挑战。本身开发技术对设计师来说就存在门槛，由于知识背景、工作内容的差异，以及前后端工作配合流程的不熟悉，导致工作评估不准确、项目延期等现象。

总结下来，以下四点「经验教训」希望可以给有相似经历的设计师以借鉴。

2.1 经验：规则制定，“丑话”说在前面

前期确定统一的“完成”标准和项目合作规则，这点很重要，不妨先把“丑话”说在前面。比如我们项目组在启动时就确定好了各参与者都需要遵守的合作方式，以确保进度的把控和必要的风险沟通。

但是，项目第一周期（根据需求优先级整个项目的开发周期分4个周期）完成后，就出现了延期现象，虽然延期在很多项目中不可避免，但还是期望能够及时的发现问题、总结问题、反思工作，让问题不像滚雪球一样越滚越大，因此就第一周期的问题进行深度分析与解决方案的思考。

延期的原因主要有：

（1）工作评估不充分，计划太理想

• 现象：计划时间无法完成计划的工作，评估的时间不够准确
• 结果：计划的时间起不到约束作用

（2）“完成、进度100%”的标准定义不明确

• 现象：了解工作进度时，可能统计已完成，但又会占用时间去测试、优化、调整；实现效果与需求不完全一致；
• 结果：进度评估不准确。

在充分了解需求后评估工作以及明确了“完成”的标准后，项目管理者会对整体环节的把控更加心中有数，也对可能会出现延期的部分留有空隙。

2.2 经验：策略及时调整，有限时间内干更有意义的事

承诺的交付时间是确认的，因此，我们只能以deadline倒推。在剩余的时间内，我们能完成什么，从而有针对性的做排兵布阵。如果把时间比作一个盒子，当盒子空间固定，若要塞进更重要的东西，则需要将不那么重要的东西去除，否则盒子会爆裂。

同样项目管理中需要及时调整计划，在有限的时间内干更有意义的事，否则工作一直做不完，一直延期，产出的质量和项目目标都不如人意。

我们需要及时根据优先级调整策略，对需求区分主次，甚至在某个需求中再拆解，如高级功能暂缓，先保证基础功能的使用等。

2.3 经验：核心体验提升才是对用户更有价值的事情

看了那么多改版产品的反馈，第一时间的不适应必然存在，尤其对中后台运维产品来说“稳定”是用户的诉求之一。但紧抓核心体验，从功能层面解决用户问题，最后一定是正向的评价与结果。如果新体验的价值不足以掩盖旧体验的缺憾和切换成本，那么对用户的价值也就微乎其微，甚至毫无价值，就如下面的价值公式。

虽然「老版」用户使用具有一定的熟悉度，也有“小众”“临时性”的功能，但是「新版」可以从以下5个核心亮点出发，解决用户使用中的体验问题，从功能层面解决使用问题，这些优化对用户是更有价值的。

2.4 经验：积极协作，配合协调

1. 当项目出现风险，要及时找相关人甚至是上级寻求帮助，及时沟通、主动汇报；
2. 过程中遇到分歧及时沟通，避免问题越滚越大，影响效率；
3. 一定要在充分理解需求的前提下展开工作（设计理解PD需求，后端理解前端需求），否则后期返工代价很大。

三、成长收获

我承担这项工作的意义是什么？设计师能做好项目管理及产品工作吗？

接受这项任务时我也有疑惑，就像工作初期以及一些师弟师妹咨询的困惑一样：我现在做的很多事是产品应该做的，本应该产品输入的信息需要我去协助他们甚至帮他们完成，这正常吗？我应该这样做吗？我做产品方面的工作对我专业有什么价值？

我的答案是：有价值！如果你是用户体验设计师，那就需要具备产品的思维，适当的产品工作与思考会帮助锻炼产品思维，并且随着工作的深入，设计能力与产品能力的交集会逐步扩大！

在《用户体验要素》一书中提到用户体验分为五层要素，分别为：表现层、框架层、结构层、范围层、战略层，将这五层的工作内容进一步解读，会发现「结构层、范围层、战略层」属于产品的职责范畴，它们对应的价值目标也存在交集，因此必然有些工作是交织在一起的。

3.1 产品思维

1. 产品思维让我保持产品大局观，从业务的根本去理解当前手头工作的意义，以业务目标为导向；
2. 从产品角度拆分功能、流程，明确做什么不做什么，确立最小功能集合，平衡投入产出；
3. 设计需要价值导向，在专业价值的基础上结合业务价值，更好的完成价值自证。业务目标明确的前提下，设计的重点会非常明确，知道发力点是什么。

3.2 大局视角

1. 视角的转化，从页面中的一个icon的美观，一个组件规范、一个合格的页面到整个项目的质量。
2. 会把用户真正需要的价值放在首位，在开发过程中，也会为了产品的性能、时间保障等，牺牲部分体验的追求。

3.3 组织协调

1. 项目过程中任何环节出现问题，都需要第一时间站出来解决，或者找别人寻求帮助；
2. 各方资源的沟通协调，以保障最后的目标实现。

3.4 流程配合

1. 更清楚前后端、测试的合作流程、以及各个节点的时间配比；
2. 对一个项目开展的基本要素以及可能遇到的问题也有了更深入的认识，便于以后的工作交流。

四、总结

最后，在此总结一下设计师主导“技术产品”的项目管理工作的优势和劣势。

4.1 优势

（1）交互人性化

• 站在用户角度思考交互行为和体验，而非技术角度。
• B端产品的体验要求：高效、安全、简单，通过设计减少用户学习成本，简化交互流程，使界面、信息易懂、易用。

（2）全局考虑，设计一致性

• 从设计师视角出发，通盘考虑页面展现形式和层级关系，可以将页面进行类型划分，便于产品的一致性与交互统一。
• 对功能入口及操作设计整合与规划，而非随意添加。

（3）体验意识传播

• 在业务中为体验发声，关注体验的重要性，从而进一步驱动技术优化。

4.2 劣势

（1）业务理解难度大

• 产品的专业名词、技术概念理解成本较大；
• 需求业务逻辑强。

（2）技术了解不足，各角色沟通成本较大

• 设计本身是一种感受、体验，可以不是科班出身，都能通过界面或操作感受到好坏；
• 开发技术对设计师存在门槛，设计师无法评判好坏并真正理解；
• 沟通缺少共同知识体系，很有可能向技术妥协。

（3）时间把控不准确

• 设计一般处在需求实现的前部分，会按照要求的截止时间完成工作，尽量节省出时间给后台开发；
• 前后端开发的时间不可控，对设计师存在技术黑盒。

以上，是我个人基于本次工作的一些经验与收获，期望对有需要的设计同学有所帮助。

作者：阿里TXD，公众号：TXD技术体验设计（ID：TXD-UED）

本文由 @阿里TXD 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。