共同的信念使我们产生交集，并给我们持续下去的动力

事情还得从4月初说起，我记得那是我刚入职一家公司还不到两周的时候，这天下午，老板突然让我来他的办公室，说有一个朋友的项目可能需要你帮忙处理一下，我问是个什么类型的项目，老板说不清楚，但是这个人很厉害，就当是朋友之间的帮忙。好吧，当时我便应允了。

然后老板把我们拉成了一个群，他叫 kering，简单的招呼后，他给我发来了他的项目文件，我打开一看，仅有4张大图，图中的文案都是英文，而且都是比较生的单词，我一边看翻译一边尝试理清这些图片想表达的含义。

这天晚上，kering 跟我开了一场视频会议，他给我详细的讲述了他们的项目 Comunion 的理念以及整个产品的流程及逻辑，会议完我觉得这是个很有意思的 idea，我觉得，如果开始我是抱着完成老板给的任务的心态，那么此时我就是个人感兴趣的原因来加入。

过了几天，是清明节。当时几个同学和同事一起约着出去吃饭，吃到一半收到了 kering 的消息，问我进度到哪了，因为动工还不到50%，所以迫于心里压力，不好意思回复，只能先退出饭局，准备回去加班，这时，有个小伙伴也准备跟我一起回去。

在路上他问我着急回去干吗？于是我就跟他介绍了我现在正在接触的项目以及相关的概念，听完没想到他也很感兴趣，因为考虑到项目内部隐私的问题，所以我跟他说我先帮你推荐推荐，后来大家也应该知道他是谁了，没错，就是我们的王帅同学。

好了，以上就是我们相识 Comunion 的一些小插曲，下面开始切入正题聊一聊第一个版本我们遇到的问题及总结：

1.因为参与项目的成员都是远程进行，沟通没有中心化公司及时，加上大部分伙伴对区块链接触的不深，包括我自己，导致了第一版本需求评审时很多流程没有确定清楚，最终影响了了第一版的发版，这一点在有第一版的基础上，在第二版上可以改善很多。

2.我在之前的版本中可能过多的考虑到用户体验上交互的问题，从而把很多流程想的业务化，但是我们是个协议产品，目标是希望通过产品将comunion的理念传播出去，通过流程来引导用户理解产品 。

3.产品选型上，这点相信前端的小伙伴也感同身受，因为产品的定位偏技术型，比较极客主义，在 UI 的风格上就比较考究。在对市面上的几种前端组件模板UI样式比较后，我们决定使用 ArchitectUI，但是我们没有提前去了解更多内容，他没有专门的官方文档，并且各种类型的组件糅合到了一起，这就使得前端工作无法正常进行。

当然这点我至今还有点愧疚，毕竟是我推荐给 kering 的，因为单纯的喜欢他的 UI 风格，后来 kering 花了大价钱购买了他。连专业文档都没有的简陋的付费服务是我没有想到的，而且我多次发邮件给该模板创作者也无果。这点得出的教训就是通过 Comunion 协作模式下的任何一个影响任务进程的决定都需要大家的商讨才能确定。

4.在产品后期开始慢慢交付测试的过程中，恰巧我在北京出差，项目的忙碌以及甲方的催促导致我在 Comunion 上的时间减少了，所以第一期的测试工作大部分是由 kering 主导的。

5.第一期测试的记录是用石墨记录的，因为没有测试步骤及用例，有时会影响开发的修复及反馈。这些我会在第二版本中通过测试用例，优先级，测试步骤，期望结果，实际结果，复现程度或者 Log 规范 bug 的管理效率。

6.最后就是结束语了，我一直觉得 Comunion 最重要的就是他的理念，通过 Comunion，一些有着相同目标的小伙伴可以摆脱传统雇佣体系的限制，组合成一个又一个的资源输出体。

也许目前的协作模式还有很多需要改进的地方，但这也是我们不断前进的目标，通过 Comunion，大家可以认识之前可能永远不会有交集的朋友，每个人都可以在自己擅长的领域发挥自己的长处，每个人都有自己的决策权力，所以我希望 Comunion 能坚持走下去，当然我也是。