让设计机构和工程团队一起工作 “产品人员-产品经理,产品设计师,UX设计人员,UX研究人员,业务分析师,开发人员,制造商和企业家 July 07 2017 真正 设计公司,工程,产品开发,产品计划,策略,团队领导力, 注意产品 介意产品有限公司 1041 产品管理 4.164

让设计机构和工程团队一起工作

通过 ON

我认识的一个人将要启动一个大项目,由单独的公司管理设计和开发。很遗憾地说,我见过这种安排的失败远远超过成功,因为我一直被要求修复。

设计机构和工程团队到处都是有才华和经验丰富的人。挑战在于他们具有不同的心态,技能和过程。代理商和工程团队通常都根据其单个产出的质量和数量进行评估。为了克服这一点,这两个群体需要共同努力,以取得比我们单独做的更大的事情。

以我的经验,如果设计机构和工程团队拥有正确的结构,监督和思维方式,他们就能成功地合作。这是我发现的有效方法:

进行验尸

任何产品开发工作的前几周都是棘手的。您正在尝试弄清楚自己在做什么以及如何一起工作。期望总是很高,时间表很短。事后回顾,以为已经发生了一个事件,将正确识别未来结果原因的能力提高了30%。

在3Pillar,我们经常进行事后检查或回顾,以讨论发生了什么问题。通过在项目开始时进行事前评估,我们所有人都可以承认风险而不会指责或悲观。如果设计机构和工程团队提前知道了潜在的麻烦,他们将能够发现并尽快解决。

资源资源
事前模式非常适合开球
扩大卓越:在不花更少钱就能获得更多收益的情况下
死前的力量

清晰了解您的愿景和目标

每个人都需要知道他们正在攀登什么山峰,以及从顶部看会是什么样子。如果他们不是从一个共同的愿景出发,他们自己的喜好和动机往往会驱使他们。愿景应该是一个单一的页面,包括任务,价值观,目标,用户和业务。应该定期重新检查它。

资源资源
设计的北极星
您唯一需要的产品愿景模板

整理日历

这看起来很傻,但是很重要。您需要很快建立一个时间表,以便团队可以开始进行一起工作的动作,并抽出时间进行实际工作。不同的群体有不同的需求,并且工作时间可能不同,因此知道何时有空人员以及何时需要集中精力有助于建立良好的工作关系。

计划和运营会议 设计会议
日常
站立式(15m)
每周
领导层签到(30m)
每周
与利益相关者进行审查(6000万)
与工程学堂(60m)
每次冲刺或迭代 (〜2周)
短跑计划(60m)
回顾与回顾(60m)

资源资源
组建设计团队以最大程度地实现跨团队协作– InVision

计划如何计划

设计机构倾向于研究大创意,然后分解事物。工程师受过训练,可以迭代地处理小型且独立的工作。这两种方法可能导致计划挑战和返工。

作为一个小组,您需要弄清楚如何估算,确定优先级和计划下几个冲刺的工作。它’不会是完美的,但是你不会’不想将设计和工程断开,否则返工会堆积如山。

帮助3Pillar客户的一件事是集思广益并进行整体评估。如果我想做一个改建项目,我可以请承包商告诉我我的想法要花100美元还是超过1000美元。有了这些信息,我可以更轻松地决定在有限的预算下我真正想要做什么。

当我们一起估算时,我们将了解设计人员和工程师的难度,并且可以进行权衡取舍。也许我们可以使用现有的模式或库进行登录,以便我们可以将更多的时间花费在数据可视化上。

资源资源
敏捷最佳实践:工程高级副总裁Jeff Nielsen进行迭代规划
扩展产品团队的经验教训

整理监督

团队负责人应该每周有一个检查站来谈论事情的进展。他们应该以团队的形式工作,以解决任何沟通不畅或性能问题。两个团队的领导者都应该期望会出现沟通错误,混乱和冲突。在3Pillar,我们想说的是,无论团队中有谁,我们都应该一直是#oneteam,而榜样必须由领导层树立。

在项目开始时,了解问题如何升级以及何时无法通过共识解决问题由谁拥有最终决定权也很重要。

资源资源
团队冲突:消除导致团队不和谐的四种方法
詹妮弗·高曼(Jennifer Goldman-Wetzler):“Mastering Conflict” | Talks at Google

获取设计师’专为速度打造的工具

追求像素完美是在浪费时间,太多的设备多样性无法实现这一目标。我们通常使用Sketch或Framer之类的工具来创建设计资产,并且制作了UI工具包,因此我们的设计师不必每次都从头开始。我们还使用Zeplin,以便我们的工程师可以看到代码中的内容。

设计人员还应努力建立一个包含可重复使用的组件的设计系统。这有助于保持一致的质量,加快产品上市和维护速度。

资源资源
策普林
草图
成帧器
Google资料
Salesforce闪电

把东西放在您的客户中’经常动手

想象一下,您是站在史蒂夫·乔布斯(Steve 职位)风格的舞台上,而您将在30秒内推销产品。如果某个功能不是值得在舞台上谈论的东西,那么就不值得在您的MVP中构建。这些都是您应该首先处理的事情,您应该将它们放在客户面前。

我们相信将价值创造的时间减至最少,只有当您将某些东西交到客户或利益相关者手中时,这种价值才存在。在白板,本地计算机甚至开发环境中都没有价值。他们手中的“东西”可以是原型,着陆页,旅程图或工作代码。

资源资源
有效地
视力