记得初中的时候曾经学习过生产力与生产关系的知识。
生产力与生产关系的相互关系是：生产力决定生产关系，而生产关系又反作用于生产力。
生产力决定生产关系表现在两个方面：第一，有什么样的生产力就决定有什么样的生产关系；第二，生产力的发展变化，决定着生产关系的发展变化。
所以根据团队现状，构建和发展一个适合的生产关系才能充分发挥生产力的效用，这是管理职责中非常核心的组织架构工作。
作为技术开发管理者，特别是创业团队，为了使开发工作更有效率，必须设计好项目协作机制，在原则上能够充分体现职责边界的同时，又确保可以协作紧密。另外一个重要的方面就是进度控制。这两项工作的设计，我想用工业流水线的理论来指导是很合适的。把不同的部门看作不同的生产流水线，并针对性的解决各个加工环节之间的障碍，进行周期性/阶段性的组装验收，使得每一个后续操作的质量都在前一个步骤上进行提升，则确保了在最后的总装集成验收环节是可控的，把潜在风险降到最低。
得益于现代游戏开发引擎的特点，全体开发团队成员都可以直接使用开发引擎参与自己相关的工作内容的制作或者集成测试，并充分理解当前项目的技术特点。好处自然有很多：
-
- 提高并行开发效率。
- 充分促进项目参与感，形成良性的开发氛围。
关键内容
-
- 更精细的操作粒度。
- 更明确的执行时序。
- 多条生产线之间的高并行机制。
具体做法
就是把技术开发相关的所有工作进行拆分剥离，使程序员集中精力在代码质量与开发效率上，并促使其以自动化，工具化，配置化思维来对接策划，美术和测试部门的工作。
其他部门负责部分
-
- 导配置数据（策划与测试）
- 创建白模资源（策划或者程序，这一步，如果策划先行，则程序只要拿来调整结构和做一些视觉元素的绑定工作，也可能程序做，具体看大家工作的饱和度）
- 替换正式资源（策划或美术，严格按照美术资源规范行事，由美术负责最终的效果）
- 视觉的优化调整（策划或美术）
- 内外网测试发版本（测试）
- 应用提审发版和在线热更资源 （程序）
程序部门负责部分
-
- 写M：编码的第一步，充分理解需求，建构数据模型。
- 写V：根据策划的视觉展示图，写合理的View层：即视觉信息内分层设计
- 写C：根据Server-Client通信协议以及用户操作流程创建接口
- 构造假数据，模拟正常流程，进行逻辑完整性测试
- 与服务端或者Web平台联调功能逻辑
- bug与调优：很多时候bug的定位都是从客户端发起的，所以需要充分理解职责，快速定位问题，并负责把问题转交到对应的部门或者组内成员
所以程序参与具体资源的制作部分限于创建白模资源或者开发级的正式资源，而不至于因为美术的工作延后而阻塞功能开发。一般来说，策划提前度最高，其次是美术。在一个顺畅的迭代开发模式中，策划可以提前2~3个版本，美术提前1~2个版本。
更多关于程序员高质量编码的一些思考方式，可以阅读之前写过的一篇《谈编码前的程序设计过程》，抛砖引玉。
一些实际的场景
-
- 程序专注写代码，即便有时候要创建白模资源，也是集中某个半天一天，专门干这事。逻辑流的沉浸状态被中断实在是一件损失很大的事情。
- 数值策划必须对自己的数据负责，严格测试。
- 策划必须使用开发引擎，在未交付测试部门前，提前体验系统逻辑。并监督部分美术资源的整理工作，特别是用户交互体验型策划去处理一些界面资源的逻辑。
- 策划必须一定程度的熟悉脚本代码，主要是修改必要的游戏运行时参数设置。
- 策划和美术必须理解美术资源规范并严格行事，程序需要对美术资源做必要的优化指导。
- 美术需要熟悉开发引擎相关部分的操作，模型，动画，特效，UI等资源处理，毫无疑问对于现代游戏引擎来说，这是很自然的工作。并负责最终的美术效果。
在解放程序处理一些“杂事”的情况下，程序必须将精力更多的关注在，逻辑实现的MVC分层设计，逻辑实现的充分测试，将重复操作以自动化，工具化策略支持策划美术与测试的工作。
对于策划的定位，充分挖掘发挥其协调开发与把控进度的职责（根据具体的公司规模与项目规模，可能没有专门的PM），并能有效让其对自己的需求设计工作做到严格充分的思考论证。
从整体来看，分工明确，但同时各自的工作又有交集的部分，可以充分发挥团队的积极能动性，且能根据各自的工作饱和度进行工作量的动态调整，形成互助机制，确保多线满载工作，提高效率。
