Update from Sync Service

策划/技术策划的职责与工具流程.md

@@ -0,0 +1,190 @@
+上级索引：[[策划索引]]
+
+
+技术策划这个岗位，经常会被误解成“两边都懂一点的人”。
+
+这种说法不能说完全错，但如果只停在这个层面，其实还是太模糊了。因为技术策划真正的价值，不在于“懂一点策划，又懂一点技术”，而在于能不能把需求、实现和生产流程真正接起来。
+
+换句话说，技术策划并不是一个夹在中间传话的岗位，而是一个把内容需求翻译成可执行工作流的人。
+
+## 技术策划为什么会出现
+
+项目一旦变大，很多问题就不再只是“功能能不能做”，而会变成下面这些：
+
+- 内容量太大，手工生产效率太低
+- 重复操作太多，返工和出错成本太高
+- 策划知道自己想要什么，但不知道怎样低成本落地
+- 程序能做系统，但不一定会优先照顾内容生产流程
+- 美术、策划、程序之间对同一个需求的理解很容易错位
+
+这时候，单靠普通策划写需求，或者单靠程序硬接需求，往往都会越来越吃力。
+
+技术策划之所以存在，本质上就是为了处理这类问题：让设计需求不只是“能做”，而是“能稳定地被做出来”。
+
+## 技术策划到底在做什么
+
+如果简单粗暴地概括，技术策划的工作通常围绕三件事：
+
+- 把需求拆清楚
+- 把生产流程搭起来
+- 把内容落地效率提上去
+
+它既不是只管创意，也不是只管写代码，而是更关注“这套内容到底要怎样生产，才能又快、又稳、又方便迭代”。
+
+## 第一层工作：把需求翻译成可实现的结构
+
+很多需求在最初提出时，其实都还是比较模糊的。
+
+例如策划可能会说：
+
+- 我想要一个更方便配战斗参数的方式
+- 我希望关卡摆放不要再纯手工做
+- 这个系统最好能让非程序同学也能直接配置
+- 这个功能最好能快速验证，而不是等完整开发
+
+这些说法都能表达方向，但还不能直接变成开发任务。
+
+技术策划在这里要做的，通常就是继续把问题往下拆：
+
+- 这个需求真正卡住的是哪一步
+- 是配置困难，还是验证困难
+- 是内容量太大，还是重复劳动太多
+- 哪些部分必须程序支持，哪些部分可以通过工具或流程解决
+- 最终应该给使用者留下什么操作入口
+
+也就是说，技术策划首先要做的，不是立刻做工具，而是先把“问题到底是什么”讲清楚。
+
+## 第二层工作：搭工具，但重点不是工具本身
+
+很多人一说技术策划，就会先想到编辑器工具、脚本工具或者自动化工具。
+
+这些当然是技术策划常见的产出，但工具本身并不是目的。
+
+真正重要的是，它到底解决了什么问题。
+
+例如一个工具可能是在解决：
+
+- 批量配置效率太低
+- 关卡搭建步骤太重复
+- 资源命名和引用容易出错
+- 表格和引擎数据同步太麻烦
+- 调试链路太长，验证一次成本太高
+
+从这个角度看，工具只是外壳，核心仍然是工作流。
+
+如果一个工具做出来以后，看起来很复杂，但团队并没有因此更快、更稳、更容易协作，那它大概率就不是一个真正有效的工具。
+
+## 第三层工作：搭流程，让内容生产能放大
+
+技术策划和普通策划一个很明显的区别，就是它会天然更关心“内容是怎么被生产出来的”。
+
+因为很多内容问题，表面看像设计问题，实际上是流程问题。
+
+例如：
+
+- 系统本身没问题，但每次加新内容都要程序手改
+- 关卡逻辑成立，但每做一次都要重复十几步机械操作
+- 策划方案清楚，但不同岗位拿到手后的执行口径不一致
+- 一个小改动会牵连太多资源，导致大家不敢迭代
+
+这时候技术策划要做的，往往就是把这些零散工作整理成更稳定的链路。
+
+常见的方向包括：
+
+- 做统一配置入口
+- 做批处理和自动化
+- 做可视化编辑器
+- 做模板化生产方式
+- 做校验规则和基础规范
+- 缩短从“改一个参数”到“看到结果”的验证路径
+
+很多项目到了中后期，真正拖慢开发的并不是没有想法，而是生产方式太重。所以技术策划的价值，经常体现在帮团队减重。
+
+## 技术策划不是程序，但也不能只停在文档层
+
+技术策划和程序的边界，很多时候容易被说混。
+
+比较粗略地看，程序更偏向系统能力本身的实现与稳定性，而技术策划更偏向内容需求的翻译、工具入口的设计，以及流程层的组织。
+
+也就是说，技术策划不一定负责底层系统全部实现，但至少要能回答这些问题：
+
+- 这个需求为什么要这样拆
+- 为什么这个入口应该这样给策划或美术用
+- 哪些步骤必须自动化，哪些步骤不值得自动化
+- 什么样的工具形态最适合当前团队
+
+如果只会写文档，不理解引擎、数据结构和工具逻辑，那么很多“技术策划”最后还是只能停在提需求。
+
+但反过来，如果只会做工具，不理解内容生产目标，那也很容易做出一堆看起来厉害、实际没人想用的东西。
+
+所以技术策划真正难的地方，不是“会不会一点技术”，而是能不能让技术服务内容。
+
+## 技术策划和普通策划、技术美术，也有明显区别
+
+和普通策划相比，技术策划通常更关注这些事：
+
+- 一个需求怎样更容易被重复生产
+- 一个系统怎样更方便配置和验证
+- 一个工具入口怎样让非程序岗位也能直接使用
+
+和技术美术相比，技术策划虽然同样会关心流程和工具，但关注点通常更偏玩法、关卡、系统和内容工作流，而不是主要围绕美术表现、材质、渲染或资源表现管线展开。
+
+当然，具体项目里这些边界并不总是绝对的，实际经常会互相覆盖。但从工作重心看，技术策划更像是站在内容制作这一侧，去主动借技术解决问题。
+
+## 技术策划经常做的，不只是“提效”，还有“降理解成本”
+
+很多人提到技术策划时，最容易想到的是效率提升。
+
+这当然很重要，但还有一件事同样关键，就是降低理解成本。
+
+一个好工具、一个好流程，不只是让人做得更快，也要让人更不容易做错。
+
+例如：
+
+- 配置项命名清楚，别人一看就知道怎么填
+- 编辑入口明确，少一些隐性前置步骤
+- 校验和报错足够直接，而不是让使用者自己猜
+- 工具只暴露真正需要调的东西，而不是把所有技术细节都甩给内容同学
+
+从这个角度看，技术策划其实也在做一种“面向团队内部的交互设计”。
+
+只是它服务的对象，不是最终玩家，而是项目中的内容生产者。
+
+## 技术策划为什么经常会影响创新速度
+
+很多团队在做新内容时，最卡的往往不是没有方向，而是试错太贵。
+
+如果每做一个想法，都要走很长的实现链路，等多岗位联调完才能验证，那团队自然会越来越保守。
+
+技术策划在这里的价值，就是尽量把验证成本降下来。
+
+例如：
+
+- 让策划能更快搭原型
+- 让参数改动能立即看到结果
+- 让常见内容有可复用模板
+- 让验证一个方案不必每次都走完整生产流程
+
+这并不是说技术策划直接负责创新，而是它往往决定了创新有没有足够低的成本被尝试出来。
+
+## 一个好的技术策划产出，通常会有这些特征
+
+真正有效的技术策划产出，通常不只是“做出来了”，而是能在团队里稳定发挥作用。
+
+一般会有这些表现：
+
+- 别人愿意用，而不是只在演示时能用
+- 降低了重复劳动，而不是把复杂度换了个地方藏起来
+- 缩短了验证链路，让迭代速度明显提升
+- 让内容生产的口径更统一，减少沟通误差
+- 能随着项目成长继续扩展，而不是很快变成一次性脚本
+
+如果一个工具离开原作者就没人会用，或者每次使用都得先口头教学很久，那它大概率还没有真正融入团队流程。
+
+## 总结
+
+技术策划不是单纯懂一点技术的策划，也不是替程序分担零碎工作的人。
+
+它更像是内容生产链路的设计者：把需求拆开，把流程搭好，把工具做成别人愿意用的样子，再让设计、程序、美术之间的协作变得更顺。
+
+说到底，技术策划真正要解决的，不是“这个功能怎么实现”这么单一的问题，而是“这类内容以后怎样才能更高效、更稳定地被持续生产出来”。