经理与设计师的互动：技术任务与反馈
在日前举行的 DevNight Dnepr 上，来自第聂伯河地区的Murka工作室的制作人亚历山大·什塔琴科（Alexander Shatchenko）详细讲述了在开发游戏项目时应该如何设定技术任务。为了App2Top.ru，亚历山大准备了简短的演讲文本版本。
照片：VIKTOR HANACEK
我将自己的工作组织得尽量降低重大修改的可能性，减少开发时间和公司为修正完成任务而支付的费用，这要归功于对任务的细致准备和将其传达给最终执行者的过程。
那么，让我们开始梳理一下为设计师设定任务的人员名单：
- 制作人和游戏设计师在应用程序开发过程中设定基础任务池。
- 技术团队的专家——程序员和QA——设置对某些元素的调整任务。
- 团队领导可以通过指出工作中的问题区域来设定任务。
- 人力资源部也可以就公司的相关问题进行咨询。
- 自由职业者为那些在公司之外打工的人设定任务。
- 设计师自己设定的任务（即设计师脑中诞生，并为提高自己的专业水平或在个人项目框架内而工作的任务）。
谁是最好的任务设定者？
- 第一名属于设计师自己的任务，因为在设计师看来，它们是和谐的，并不存在矛盾。如果在处理自己任务的过程中出现问题，这些问题自然会在设计师的意识中解决。
- 第二名是游戏设计师和技术负责人。他们都与任务紧密相连，且已经拥有一定的设定经验。
- 第三名是人力资源，因为这些任务的验收标准较低。
为确保所有任务设定者对任务设定的标准有基本的了解，我推荐为技术规格书（以UI/UX设计任务为例）准备最少的要求。
UI/UX技术规格书的最低要求
- 屏幕地图
- 每个屏幕的详细描述，按照以下格式：
- 屏幕的目的
- 界面的元素列表及其目的
- UI机制的建议
- 对构图的要求
可以在描述中加入：
- 实现示例
- 模型图
- 可能的文本，指明字符数或文本框的长度
- 成功实现类似任务的应用链接
在处理技术规格书时，任务更可能被接受，而无需进行重大调整和修改。与管理者的冲突将减少，与团队的互动也将变得更为轻松。这些变化将积极影响工作效率。
屏幕地图不仅有助于设计师，也有助于管理者理解界面的工作方式，以及游戏屏幕之间的关系。通过屏幕地图，设计师可以想象整体工作量、UI元素之间的依赖关系，并在概念阶段表达自己的愿望。在演示中（第6-8页），给出了糟糕和优秀的屏幕地图的示例。
优秀的地图
制作优秀地图时应记住：
- 屏幕地图应以简图的方式制作，不应包含现成的示例，更不应包含原型的屏幕截图；
- 屏幕地图不应包含细小、不易迅速阅读的元素；
- 关系的简图应便于阅读；
- 屏幕的显示格式“图标 + 标签”是良好的选择。
下文所述的任务示例是利用地图功能的一个屏幕的描述。每个模型中的元素至少对应一行描述，说明组件的功能及其工作原理。同时给出了机制工作描述的示例。
每个人都有不同的生活经历和观点。因此，每个人对任务的理解往往各不相同。为了避免误解，建议提前协调对结果的理解。特别强调任务设定过程中反馈的重要性。
我建议将过程组织如下：
- 任务设定者召集所有将被吸引进行任务实现的执行者。
- 任务设定者进行任务演示，详细讲述他所期望的结果。
- 任务演示后，设定者应询问：“你是如何理解这个任务的？”
但由于管理者常常忽视这一点，我强烈建议执行者不要推卸对这一过程的责任。设计师应询问：“我理解得对吗？”并复述他如何理解每个任务组件。
第二个问题是： “你将如何评判这个任务的完成标准？” 并不是每个管理者都能回答这个问题。但找到问题的答案，将能明确在这个任务的实现中什么是最重要的。
我希望强调的主要结论是：
- 从一开始就协商任务描述的标准。
- 技术规格书必须清晰、详细，并附有示例及机制描述。
- 屏幕地图是必要的。
- 反馈是必不可少的。
有用的链接：
moqups.com — 模型图服务
cacco.com — 模型图和结构图服务
gliffy.com — 界面、结构、图表
balsamiq.com — 用于创建UI/UX原型
会议参与者提出的问题主要是有关团队的组织以及设计师的工作。对此的回答可以在这里找到： http://progamedev.net
