一、总论
第一次当产品经理，以为就很简单，甚至可以很摸鱼的干完，但是事实并不是这样的，从结果来看，似乎并不能说，因为有了我，团队得到了一些其他团队所不具有的优势，并且并不需要付出相应的代价。
应该这么说，我天生对于“条理和系统”的追求让我们的团队合作确实相比于其他团队要更加有条不紊的进行，在项目架构上没有出现大幅度修改，我“前瞻”的习惯也让团队没有遇到过十分紧急的技术难题，我良好的记忆力和文档更新速度，也让团队交流的效率大大提高。
但是我对于设计风格和设计需求的“独裁”确实在一定程度上损害了团队的表现。在设计风格方面，作为一个美术生，我显然自视甚高，不过其实我是一个十分没有才华的美术生，所以导致我并没有办法托举整个团队的审美。而在设计需求方面，我没啥“独裁”的欲念，不过我实在是太善于表达，导致组员确实没法正常表达完整观点（当然，可能是他们不在乎），这就导致有有一些需求是没有覆盖到，从后面的经验来看，如果需求没有覆盖全，那么将是致命的。
写这个文章的目的也是为了给以后的工程实践积累一些经验，同时为假期的预习指明一些道路。
二、文档
- 文档单独建库，因为文档库的更新频率要远高于前端库或者后端库。
- TODO 单独成文件，这样可以让组员更加清楚每次的任务。这次我们使用的是 markdown 的任务列表，其缺点在于没有办法直观准确的看到各种 ddl。
- 命名规范和 git 规范单独成文件，方便版本回溯，对于版本控制，本次是采用的是相同权限，自主维护，如果涉及到更多的人，此处可能还需要更新。这个东西应当反复强调，本次对于 API 的命名规范强调的不是很好。
- 涉及文档的架构与前后端架构是对应的，这是一个很好的习惯，因为对应好了可以方便的指导前后端的设计和实现，并且在某些地方没有写清楚的情况下，依然可以完成功能。但是不得不说，这样的设计文档是完全解耦联的，而不是统一的整体。
- 这次文档的更新速度并不快，甚至会出现“人催文档更新”的现象，这是十分不应该的，应当以后注意。
- 似乎美工文档需要写得更加详细，同时需要写得更加有参与感，似乎随便写一写，并不能达到指导美工的目的。
三、美工
- 最大的失败是配色失败，延续了我一贯的配色方案，选定一个颜色后加黑白颜料，失败中的失败！
- 其次的失败是没有品味，俗不可耐！失败！
- 一如既往的胆小怕事，失败！
- 指定的美工规范反而约束了最后的成果，这是因为美工规范过于简单，过于单一，就好像只用两种颜色画画一样，失败！本来美工规范的目的是为了高效的生产 KFC，但是现在变成了高效的生产塑料。
- 考虑到我的美工水平不可能短时间内提高，所以考虑如下两条优化路径：
- 开放美工权限，或者减少美工规范的约束力度，发挥组内所有人的力量。
- 多去逛站酷，基类美工经验。
- 考虑让渡权力，确实我在这个方面干得不好。
四、组会
- 线下会议确实要比线上会议好，线上会议确实容易走神，我自己也走神。
- 会议内容一定要尽快落实到文件里，不能拖延，因为拖延就忘。
- 开会前将自己需要说的东西需要准备一下，甚至是文本形式的。
- 应当与组员充分协商探讨，不得不说，虽然效率会降低，但是效果是真的好。尤其是一些涉及到主题思想，或者说指导精神之类的东西，一定要充分交流，充分探讨，这样才能让这个“精神”真的知道生产，而对于一些实现细节，则可以匆匆略过，回头只需要在文件中详细写明即可。
- 对于意见建议，不要立刻起抵触情绪；对于听不懂的东西，一定要让陈述人再次陈述。
五、合作
- 有幸与非常好非常好的队友共事。
- 应当无条件的信任队友的能力，当遇到问题的时候，应当鼓励队友积极沟通，而不是将问题掩盖下来，决定问题最终摆烂的权力一定要明确必须不能让渡。
- 团队沟通的方式不应当拘泥形式，私聊也可，群聊也可，不能让形式妨碍沟通效率，同时要注意共性问题要发到群里。