# 设计会议

简写 职位名称
UXD UR,ID,UI,VD
UR 用户研究 User Research
UE/UX 用户体验 User Experience
ID 交互设计 Interaction Design
PD 产品设计师 Product Design
UI 用户界面设计 User Interface Design
VD 视觉设计 Visual Design
FE 前端 Front-End
RD 研发 Research and Development
PM 产品经理 Product Manager
PO 运营 Product Operation
QA 测试 Quality Assurance
SH 利益相关者 StakeHolder

# 每日站会

人数建议 时间建议 频率
全组/全项目组 15m 每天(如人数较少或项目少时可以隔天)

采用站立形式,防止时间过长的会议。 一般不超过15分钟,也不必非要卡15分。

# 内容

  1. 昨天干了什么,完成的事
  2. 今天计划做什么,计划的事
  3. 有什么问题或障碍需要沟通、协助

不长篇大论,以同步为主,有问题及时发现。 如有需要进一步讨论的事情,仅必要的相关的参加。 如都需参加另行预定会议。

# 意义

团队透明,保持同步。 及时发现问题,解决问题。

# 评审会

人数建议 时间建议 频率
<7 <1h 项目部分完成后

参见 设计评审指南

让团队审查彼此的工作也是培养团队精神,分享知识,让团队互相看做资源的好方法。在大型组织中尤为重要,因为设计团队经常与自己的团队和项目隔离。 当团队评估他们的团队成员面临和解决的各种设计挑战时,他们可以将这些经验带到他们自己的工作中。

在设计过程的每个阶段进行设计评审和反馈对于成功的产品都是很有用且至关重要,也可以帮助聚焦正在发布的设计是否满足用户需求。同时对设计师的成长提供非常大的帮助。 一个正式的流程和一个高效的环境是做好设计评审的基础,可以让整个团队参与起来,改进我们的设计,做好设计质量控制。

# 专题会/临时会

人数建议 时间建议 频率
项目组/任意成员 <30m 按需

专门用来解决临时问题,或者在大的会议中不能在会上解决的事务,以灵活的时间,少数人员参加用以解决特定问题的会议。 可以采用站会或者目的明确的,短时间的工作会。

# 分享会

人数建议 时间建议 频率 建议参会
整个团队 <1h 每2周或1月,定期召开 ID,UI,VD,SH

团队中的分享会有很多在好处,也是必不可少的,比如我能想到的:

  • 营造良好的学习氛围
  • 使团队更多元化,积累创意的催化剂 (知识多元,思想多元)
  • 兴趣不同,方向不同,从不同的角度和位置看世界(设计)
  • 分享是更深入的学习,因为你需要把分享的东西用你的思维写出来,以你的语言讲给大家听。这个过程其实已经是“费曼学习法”了呢
  • 机会不多的团队间的专业交流(平时都忙于自己的项目,交流的内容也只是工作相关的部分),在分享时选题范围不爱限制,也可以更有前瞻性,或者涉猎更加广泛。通常以个人兴趣向为主,不同的同学可以开扩思路。

……

不要忘了在分享结束的时候感谢分享者的付出,并留下足够的交流时间,有时高质量的讨论会使大家受益匪浅。

# 工作坊

# 用户故事,场景

人数建议 时间建议 频率
项目组 <1h 按需

# 头脑风暴

人数建议 时间建议 频率
全组/项目组 <2h 按需

头脑风暴法又称脑力激荡法,常用来产生解决问题方案,也可以搜索决策方案。通常组织中遇到的问题的80%左右都可以借助头脑风暴法找到解决方案,所以说头脑风暴法对于问题具有强大的威力,是我们进行创新思考的强有力的工具。它简单快速且有效。

水击产生涟漪,石击产生火花。思想与思想的碰撞,会激发新的思想,智慧与智慧的碰撞,会引发新的智慧。一粒种子的萌芽,会收获丰硕的果实,一个火花的点燃,会燃起熊熊烈火。利用集体的智慧,通过互相交流。启发和激励而产生新思想的方法,这就是头脑风暴法。

一个富有成效的头脑风暴不仅可以在短时间内高效的生产灵感,也有利于增加团队的凝聚力,提升员工的集体荣誉感。可是组织一场成功的头脑风暴并非一件容易的事,具体组织方法,由于环境、文化、习惯不同这里不累述,请自行查阅资料

# 团队价值会

人数建议 时间建议 频率
团队成员 <2h 团队初创或管理、运行出现问题,环境架构或服务对象,目标出现较大变化时

团队初创或管理、运行出现问题,环境架构或服务对象,目标出现较大变化时:
需要综合实际情况,通过合理的分析现状和团队的能力、方向、和团队目标,结合公司业务进行分析讨论。
以及时发现问题,指导团队工作方向,阶段性,有计划的布署工作。 团队的价值结合团队的能力,最大化输出于产品的目标,公司的愿景。

# 1对1面谈

人数建议 时间建议 频率
2 ≈1h 季度,或按需(团队成员有异常表现或困扰时)

1-on-1 谈话是两人之间的私密性沟通,在这样的环境下,可能会挖掘出很多在其他场合不适合或者无法表达的意见和反馈。通常来讲,1-on-1 谈话在以下三个方面具有非常好的效果:

# 建立并维护关系

Manager 同团队成员之间的关系是团队健康程度的重要指标。关系的内涵,包含互相信任、认为自己得到公平的对待、被认可等等。当团队成员想要同 manager 进行沟通,但并没有相应的渠道,或者 1-on-1 的约定时间总是不停变更,大家会认为倾向于认为「我的优先级在我的 manager 眼里很低」。如果想要传达的信息无法被传达,有些人可能会在完全没有引导的情况下选择进一步的行为,另外一些则可能完全放弃沟通。无论哪种都会带来管理成本的上升和各种不必要的麻烦。

行之有效的 1-on-1 机制,manager 应该让团队成员感受到「我很在乎你和你的想法」,并以此建立互相之间的关系,这样才能减少由于沟通不畅所带来的效率损失。

# 提供反馈和支持

团队成员的工作需要及时得到反馈。当反馈不及时或存在信息不对称时,就无法对工作进行校准,只能机械地继续做正在做的事情。与其用绩效考核的结果向团队成员传达对他的产出不满意的信息,通过实时反馈来自 manager 和其他成员的想法和建议对于改善工作的帮助更大。

如果没有常规的沟通机制,无论是正面还是反面的意见都可能无法被传达出来,进而在被忽视的情况下发酵从而导致更严重的问题。

同时,个体成员现在最关心的问题是什么?遇到了什么样的困难?作为 manager 如何能够给每个人提供更有针对性的帮助和支持?1-on-1 可以帮助 manager 回答这些问题。

1 on 1 时问的 101 个问题

# 对齐目标

企业组织是由一个个具有特异性的个体成员组成的,将成员的工作同团队和公司的目标对齐在一起,对于提升组织效非常重要。在实施 OKRs 的团队中,1-on-1 谈话过程中关于业务的讨论基本都会在 OKRs 所创造的语境下展开,并据此统一和校准目标、进度、标准及预期等等。

# 复盘会

人数建议 时间建议 频率
项目参与者 2~4h 项目成功上线,或项目出现严重问题时,或阶段性项目、个人复盘

复盘的类型可以分为团队复盘。 个人复盘和他人复盘,团队复盘就是指多人,整个团队做到一起来进行复盘,主要应用是工作,项目中的,主要的目的就是通过复盘改进工作方式,从而减少错误,提高工作的效果。

  1. 以学习为目的,吸取经验教训,提出后续改进意见,在经验教训中找出成功之路;
  2. 通过复盘发现问题,规范公司相关流程,落实标准化流程;
  3. 深入分析问题,寻找解决方案,为以后类似问题找出提供基础;

重送绝句
作者:杜牧
绝艺如君天下少,闲人似我世间无。
别后竹窗风雪夜,一灯明暗覆吴图。

# 述职会

人数建议 时间建议 频率
团队成员 30m/p 0.5~1年

# 述职的概念

述职是一种群体性的工作总结、自我剖析、对标学习、互相反馈的会议机制。述职时,不仅谈事(工作),而且谈人(团队);侧重谈过去(总结和分析),也要谈将来(方向和想法)。

# 述职与 1—on—1、业务 review、绩效考核面谈、专业或管理晋升述职的区别

述职与以上动作都有所差别:

  1. 述职是群体 review 的会议, 1-on-1 是一对一的面谈;

  2. 述职不仅对业务目标及结果进行 review, 也对团队和个人成长情况进行 review,需要兼管理顾“事”与“人”;

  3. 述职可以选择结合绩效考核的周期,在绩效考核前后开展,可以作为参考信息,但不直接决定绩效结果;

  4. 述职和晋升述职最容易让人混淆,首先是目的不同。

    • 工作述职是为了学习成长;
    • 晋升述职则是要有理有据证明自己的能力以获得晋升。

    其次受众不同

    • 工作述职的受众是你的上级横向部门同事或合作的客户等,他们是比较了解你平常工作的;
    • 晋升述职的受众是专业评审通道的评委或者是其他部门的 leader,相比较工作述职受众来说,是不太完全了解你的工作的。

    最后开展的方式也不同

    • 工作述职由各团队组织开展,根据部门管理需求安排(如年度/半年度/季度);
    • 专业/管理职级评审的述职要根据公司晋升周期,根据晋升规则开展,与晋升结果相关。

# 述职的价值

  • 是自我觉察、反思,持续改进优化的途径。
  • 是横向对标,向身边优秀伙伴学习快速成长的方式。
  • 相互激荡,促进深化思考和认知迭代。

不累述,请自行查阅资料

——《论语》