今天开发者者委员会发现后端开发者 Airel 已经领取任务并参与研发一周后，出现了对任务需求不明确的问题。在当前 V5 版本的开发过程中，为吸取之前版本的教训，开发者委员会已经将产品需求尽可能细化，并且留出了将近一个月的时间进行开发者扫盲。

    按道理不应该再出现此种问题，但出现了问题就要即时解决，为了能够引入更多工程师接入工作，开发者委员会对此事件高度重视。

    各位开发者委员会委员首先针对这个问题进行了讨论，核心讨论内容如下：

    Uta：
    我觉得目前需求传递这个问题在需求方和执行方之间存在着巨大的信息差，不仅仅是在拆任务的方向。我觉得开发者需要对整个产品的需求有个全局的概念，不仅仅是开发者委员层次上的，毕竟不是委员去开发。

    具体有：
    1. 去除全局开发者评审机制，改成小范围评审。
    2. 根据需求的关联性，确定对应的模块负责人。

    跟具体的负责人，确定具体的需求情况。开大会就会出现，大家也不知道到时候是谁来做这个东西，也不会提出一些问题，都会抱着做的时候有问题再说，那评审就一点意义都没有，我以为你理解了需求，他也以为他理解了，但你怎么知道你们两理解的是不是一个东西？

    Kering：
    没错，咱们接下来就重点解决 信息差 问题：
    1.发任务的时候要像发 Bounty 一样，需求信息和标准 写的完整一些。现在 任务信息基本没有，都靠全员评审的时候 说几句，开发者 和 我们之间存在很大的信息差 。

    2.针对具体的任务，跟具体的开发者单独沟通，不开大会，开小会，开发者管理委员会 作为中心化单位存在。

    Uta：
    说到小范围的需求评审，在传统的公司就是拉上相关的负责人，一起开会，会上提出指出问题，需求评审效率很快。

    我们这种协作模式，协调个大家一起参会的时间成本是很高的，如果说我跟每一个负责的人都去陈述一遍需求，然后让他理解的话，那我的时间成本就太高了，可以说我完全没有时间和精力去跟每一个开发者沟通，并且随时有新的开发者介入。

    所以我才尽可能的去完善原型的高交互性和文档的详细性，尽量减少大家的理解偏差，然后大家用原型和文档先了解需求，然后我们在找时间把负责人一起过一下。否则我根本没有必要出这种程度的原型和文档，我在我自己公司是不可能出这种细致程度的。

    传统公司可能是 评审先行，做一个需求清单excel → 开大会评审沟通 → 通过后 → 完善需求文档prd+原型
    我们是 文档先行 → 初版原型+prd → 开发者根据负责的模块熟悉需求 → 开小会细节确认 → 完善终版prd+原型。

    我希望大家能重视起来这个问题。 目前这个版本可谓是关键版本，可以理解为后续迭代的基石，这个版本如果搞好了，后面的版本迭代完全用新人也没问题，只要需求传递没有问题，在代码上我们自己设定审核标准就可以了，在测试网上没问题，我们在同步到主网。 而目前这个阶段就是主网代码的核心部分，大家一定要特别重视。

    Kering：
    Uta 目前的思路是准确的，我们要在任务分配的时候体现，目前体现在产品需求评审环节 ，接下来套方法输出到 任务分配中，想想以后我们在 Comunion 上直接分配任务，那时候也没有成员的概念了，如何让外部的 接活的工程师理解 就是关键了。

    为准确解决这个问题，Kering 召集 泽辉，nigel 和 Airel 与今天晚上准备专门为 Airel 单独介绍任务需求，为后续任务分配时信息发布做一个案例。

    会议结论如下：
    1.任务发布信息要尽可能的详细描述，减少开发者疑问，让开发者通过阅读即可理解任务的要求；
    2.结合开发者个人技术方向和特点 ，分配任务，并与开发者双向确认 ，任务需求清楚，可实现，不延迟；
    3.执行过程中，开发者有疑问 与 master沟通解决，在coding前 输出设计文档。

    —————————-
    记录人：前尘