这是我参与「第四届青训营」笔记创作活动的第9天」

『第四届青训营」 random一个好了 团队笔记产出

近期，随着第二轮任务点的逐渐显露，也因为身为队长的我还未能及时整理出具体项目任务点，组内有成员提议发起一次组内会议，讨论具体的项目内容。

组长迟迟不愿意举行群体会议讨论，原因有以下几点：

• • 会议讨论点不明晰，没有会议主持人，队长并不清楚谁有着足够的问题量或问题的深度足够支撑会议讨论。目的性不够强的会议，或许会消耗成员的精力。
  • 常见的情况分为两种人，一类或许可以通过口头交流，彼此之间信息的交流，加快自身思路的扩展，利用会议帮助自身打开和整理思路。另一类则会因为频繁、无太大建树的会议而感到疲惫，降低活动参与积极性。
  • 会议内容持久化记录的重要性：问题量不够，主题不明晰的会议，使得团队成员不方便对自身相关问题提前投入注意力，不便把握会议内容主干。

为举行高效的团队会议提出的几点建议：

• • 积极参与的态度。作为团队8人中的一份子，都应该抱有积极的参与态度，在团队讨论的过程中贡献自身的活跃度，促进团队正向讨论，当然极特别情况除外。如果自身是否因为生活或工作原因，参与项目流程的时间受影响，可以向组长提出，让项目任务组织者了解团队内成员的情况，合理安排团队成员的任务量。
  • 占用群体资源的提议首先自查。项目中出现的任务应当首先自行分类，细化任务点问题范围，做到有针对性的询问。
  • 在开发周期短、任务量大的前提环境下，组员可以进行角色互换，代入组长的角度进行思考，在平常环境下，组员也当有这方面的意识。对项目全局有一定了解，帮助思考可能存在的问题。在项目中某一块区域深耕问题，提出解决方案，或是根据自己过程中产生的疑问提出议程，从被动接受任务改为主动发起任务，这也能帮助自己快速进入状态。
  • 创建议程表，负责各块任务的成员将自身任务领域中遇到的问题罗列在公共的表上，方便合作成员与项目组织者增加对该领域的认知，组织新的任务点或决策。

小组项目任务安排：

  情境：

• 以项目结项为导向：鉴于团队成员的项目经验水平不一，团队整体开发经验不足，过多的集中于一个具体项目之内进行开发容易产生任务点难以安排，导致代码冲突等问题，分工的指导原则之一为：任务领域分散，将成块的领域分配给成员进行产出，避免彼此间任务领域有所交集。

• 项目开发周期短，短期内难以比上其他迭代多次，成熟的开源监控SDK项目，故而可以以成熟开源项目为标准靠齐。同时结合情境一，一个任务领域安排完后，会有成员空闲。针对该情景，团队尽量实现并行开发，而该点的实现有现成条件，构建受控项目的同时，我们可以根据最终目标（成熟开源SDK项目）的标准，根据估算，选择性的选取其中足够时间实现的指标点，构建数据展示终端应用。

• 结合情境二，为避免结项时没法及时产出内容，一小队率先根据成熟开源SDK项目的API实现受控项目（为项目兜底），期间产出后端数据表，前端测试样例方案（用什么元素完美承载受控源，出色体现出不同载体间数据的差异，方便图表展示【差异不大的数据没有针对性】）。

• 8人团队中剩余的成员作为一小队，负责团队核心任务，团队原生监控SDK的实现（游击队），指导受控项目的测试样例方案，根据网络文档，开发自研SDK。

• 后端，无，根据数据表搭建项目。