当要组织一群人，完成一件事时，首要考虑的是什么？
考虑的是这群人，还是这件事？
昨天晚上，卡着点提交材料，在11点59分发现上传的视频有问题紧急替换，最后成功提交，在刚刚看到材料通过了审核，也就意味着这个项目度过了一个节点。
能不能走到下一个节点我不好说，但能一步步走到这里，已经是非常地庆幸了。
我们选择的赛题是轨道交通智慧客流分析预测。我选择的队友，两个技术人员，是同班同学，一个是大学期间最好的搭档，一个是一直敬佩的同学；两个类似产品经理角色的同学，一个是，和我性格完全相反的实验室学妹，，一个是带我捞过奖的交通运输专业的大佬。
于是我们五个人，来做这个项目，看起来就是恰到好处的。
我很想留大段篇幅去夸我的神仙队友，但这并不能达到反思的目的。
回到开头的问题，当要组织一群人完成一件事的时候，首要考虑的是，如何去将这件事情拆分成一个个可实现，可评估的子任务，然后分发给这群人。
对应上赛题，我们要开发一个系统，实现对历史数据的可视化分析，基于历史客流，我们要实现对未来的客流预测。
从这个系统上来讲，很自然地会划分成三个模块，前端，后端，机器学习。
从参加比赛的角度上来讲，我们需要给出一份介绍我们系统的材料，文本：概要，详细方案；PPT；视频。
于是我们的任务非常的清晰：在项目经理的帮助下，技术人员完成对需求的理解，开发出相应的成品，再参与进材料的准备当中。
在第一次线下开会时，我们邀请了指导老师，但在老师来之前，我们就确定了分工：
前端技术人员：负责前端开发，文本美化，PPT制作；
后端技术人员：担任队长，负责后端，大数据部分开发；
机器学习技术人员：负责算法模型，答辩，视频配音；
项目经理（19级学妹）：负责软件工程相关的所有文档，如需求分析，绘制UML图，整理文档；
项目经理（交通运输专业）：负责需求分析
现在再来看，当时的分工到最后已经有所调整，最后是由交通运输专业的同学制作了PPT。
当时也很快就明确下来，项目开发是持久战，需要有每周例会，例会上需汇报任务进度。
需要有版本控制工具，如Git，需要有协作工具，我们选择了语雀作为知识库来沉淀文档。
但差不多在三月份的时候，有些东西就脱轨了。
我清晰地记得我在二月底担心项目进度偏慢，在语雀上开辟了任务进展的文档，让团队成员填写任务，并划定DDL。
在二月份的线上会议中，我们基本是轮流汇报任务进展，但到三月份的会议里，我们已经丢掉了做会议记录的习惯，也从轮流汇报任务进展，到讨论问题，也就意味着我们对每个成员的进度失去了把握。
三月份回到学校，我们逐渐忙碌于其他的事情，大挑，春招，考研，准备夏令营，满课的同学满课。
于是，当我作为负责人，无法在ddl前完成任务，那么也就难以去要求其他的同学也能在ddl前给出成果。
清晰的任务划分，任务用时，任务截至时间，以及对这个有效推进，在服创这样的任务开发里，缺一不可。
如后端方向：
-
了解业务；
-
根据业务进行数据库表设计，索引设计，导入数据（或者编写数据库样例数据）；
-
搭建技术框架，设计后端架构（基本就根据框架规范来设计）
-
和前端同学确定接口设计
-
实现代码
-
测试
-
后端代码部署
这七大点，现在看回来非常简单，我其实不能理解为什么我把这个东西是拖到了三月下旬才完成，也有可能是头一回接触80w条数据觉得比较懵，在直接存多表联合后的表还是查询时进行多表联合，纠结了比较久。
而且由于春招压力，对大数据的构想没有足够的底气，于是先跑去实现了大数据的流计算基本逻辑（即系统的2.0版本），后实现后端（系统的1.0版本），极大地拖慢了前端同学的开发进度。
并且在实现后端代码的时候，才开始关注前端的可视化图表实现，于是前端的同学一边大改前端，一边加新的功能，一边实现和后端的对接，耽误了比较长的时间。
团队的开发在于，团队的每个成员都是要协作的，一个任务的拖慢即有可能影响另一个同学的进度，进而整个项目被阻塞。
一些清晰的任务安排，如绘制甘特图，利用看板，可能会对整个任务完成以及任务协作能体现得更为充分。
而刚刚也提到了，我们团队，在一开始，重视的是文档沉淀，而非用看板来管理进度，也是后面项目失控的原因之一。
说了很多废话，概括下来，其实就是
- 一次专注一件事情，做到100%，比同时做两件事情，都只做到60%要好
- 任务的安排，时间的限制，应当更为清晰，同时要明确得知道团队的成员如何协作，A的任务完成度对B的任务完成度的影响。