身为产品设计师，我从工程师身上学到的产品开发心法

由于我这几年都是就职于 design agency（设计工作室），我们并没有很多 in-house （组织内）的工程师资源，唯一的前端工程师人在伦敦，我从来没机会跟他合作。

因此，我一直以来对接的都是客户端的工程团队，将设计文件寄出去之后不一定有办法实时回馈，如果不在档案或信件中解释清楚的话，对方有很大的机率会误解，所以我交付档案给工程师的时候都比较慎重、详尽。

月，孵，招募程，端程偏 UX Engineer 程。

两位都是从竞争激烈的游戏产业出身（他们之前在植物大战僵尸的公司工作），各自都有将近十年的实战经验，也曾经管理过工程团队，所以对于产品开发熟悉。

最近我也投入自家产品的开发，跟这两位工程师和一位资深互动设计师组成四人项目小组，发现自己简直爱翻跟工程师并肩合作了。

导入产品开发流程

由于设计工作室的性质，我们以往都是根据客户的需求以及时限来推进项目，例如三个月的项目要花两周完成产品策略、四周完成线框图之类的决定都在项目一开始就非常清楚，所以我们虽然有设计迭代（从设计图 A 转变成设计图 B），却没有很明确的产品功能迭代。

工程师将他们的产品开发流程导入到我们的 workflow 中，几项简单的例行事项就让我们的 workflow 越来越流畅，也让我学到许多产品开发的眉角。

Daily Stand Up 每日站立会议

工程师很坚持每天都要有十五分钟到三十分钟的 stand up meeting，让每个人概略报告一下自己昨天做了什么、今天打算做什么。

站立，而不是坐着，强化了该会议打算简短且避免浪费时间的想法。站立会议并不是一个解决问题的地方，而是让一个团队意识到现在的状态。如果需要讨论，适当部门可以安排另一个更长的会议。（摘自 MBA 智库百科）

一开始我很疑惑为何需要如此坚持每一天都要开会，毕竟有时候设计卡关，可能连续几天都在做一样的事情，stand up 的时候反而会感到自己没什么能分享的。

后来发现每天 stand up 让大家永远有机会可以提出问题，或是分享遇到的困难，比较不会因为偶尔一次的大会而感到有问题太小不该问，或是有问题还等到下次开会的时候才问，那都可能已经太迟了，stand up 能够帮助团队迅速注意到症结点。

Sprint planning 冲刺规划会议

我们采用 sprint 的方式开发产品，利用 Asana 当作项目管理的工具。工程师提出一种理念是：在每个 sprint 开始时都重新建立一个 Asana board，目标是要在 sprint 结束时将所有卡片消掉，没消掉的卡片就要在下一次 sprint planning 时决定是否延续此项任务，要不然就做好 documentation（文件纪录）之后摒弃掉，绝对不存 backlog 在这个 board 里头。

另外，在创建任务卡片时也不会一开始就指定负责人，因为设计工作室的接案本质，每个设计师都有可能因为新进的项目而被抽出这个小组、转移重心，所以最重要的策略就是要让任务模块化，卡片可以随时交接，当我重新加入项目时可以将没有人负责的任务捡起来做。

Retrospective 回顾会议

再来说说我最喜欢的项目 — 回顾会议（Retrospective，简称 Retro），在每次 sprint 结束后都会开一次，顾名思义是要回顾这个 sprint 的好与坏，藉此更加精进我们的流程，以下是我们 retro 的架构：

1. 回顾上次的行动项目（action item）

根据完成程度帮自己打分数，我们是用笑脸、木然脸跟哭脸当作评分

2. 做得好的部分

称赞大会，将这次 sprint 里头运作良好的部分提出来。曾经出现过的赞赏是任务量计划得刚刚好、工程师跟设计师沟通良好等；也会提到一些比较随兴有趣的，比如说伦敦的工程师当爸爸了、感恩节要到了。

3. 有待加强的部分

这大概是最重要的环节，只要专注于点出问题是什么，避免直接跳到解决方案，以免时间浪费在试图解决一个问题，却没有正视所有问题（这真的超级难，所以我们经常要口头提醒彼此不要跳到结论）。

4. 解决方案的行动项目

将有待加强的部分全数列出之后，选定几个来想出可能的解决办法，产生的行动项目要指定给某一个人，避免三个和尚没水喝的情况。

我很喜欢 retro，因为这跟个人的自我省思很像，每次反省都能让我们更了解自己、找出问题与解法，进而让流程越来越进步、顺畅。

程某流程困扰，闷，retro 。

工程师说从来没人喜欢过 retro，一直说我真是奇怪的人，但除了我认真相信反省能让团队变得更好之外，我也认为 retro 做得好的话是个近似于 team building（团队建立）的环节，让团队成员更了解彼此在乎的点。

迅速迭代

项并，，往相符。

再一次，因为工作室的接案本质，最终成品往往是送出去之后就没有机会修改了，而送出去的成品代表着我们工作室的声誉，如果交出的质量不够好，客户就不会回购了，导致我们很多时候对最终设计过于小心翼翼。

一开始我们总是在很后期才跟工程师说设计需求，担心他们会做许多白工，工程师后来反倒反映说赶快产出各式各样的原型才比较好进行测试，让我们亲身感受一下我们画出的流程真的使用起来是什么感觉。

他们说，在开发产品初期做任何决策时，我们要扪心自问的第一个问题不是「这会成功吗？」，而是「我们可以从中学到什么吗？」

开发产品时就不能总是将完美当作目标，而是要以学习、改变为最高目标，不畏失败，先推出才有真实的数据跟回馈得以学习。

程鼓励「够」，远迭导馈，论使者或馈，迭，纯臆测象断迭。

友善的工程师

虽视，思程，程善，从程紧系。

1. 沟、沟、沟

 in-house 程，够各谈已远程，沟必，断灌输观念「被卡住 15 钟，」「程疑虑，」「讲垃圾，（欸）」

法尽，愿仔细聆听法，身程见，偏 UX Engineer 甚至供法，画框图沟。

同时，他们也很尊重设计师的看法，当他们在架构后端的时候，偶尔也会丢出一些问题说「这样的数据处理方式，好处是 ooo，坏处是 xxx，我觉得这样做比较符合用户流程，设计师你们怎么想？」尊重设计师专业，不会径行做决定。

2. 合作弹性

对于设计迭代他们也完全接受，因为我们不走瀑布式开发，所以有时候设计师在画图的时候，工程师也同时在写同一个页面的 code，设计经常在变，导致他们时不时会需要这边改改、那边修修，他们完全 OK，我跟另一个设计师常常打趣地说我们完全被宠坏了。

结语

几个月的合作下来，跟这两位工程师在私底下也变成好朋友，很常跟他们在 Slack 私讯（额外发现：工程师真的很爱 meme 跟 gif），也偶尔会跟他们出去 happy hour 喝酒聊天，他们也一直说要教我怎么写 React（真是太看得起我了）。

最近深深感到能够跟他们认识并合作真的是太幸运了，从他们身上能学到很多在设计师身上学不到的东西，觉得自己对产品圈的知识又多了一些。