系分项目日记

系分项目日记

这是一本不连续、不完整的系分项目日记，记录了我们项目开展的大体过程与重要事件。我会尽自己所能，从中总结出有用的经验供下一届的学弟学妹们参考，希望对大家有用。

---

3月17日——第一次开会

今天是我们小组第一次正式会面。尽管我们不是组长，[1]但在开会的前一晚我还是用XMind简单梳理了一下自己的思路，并在此基础上整理了一份开会的议程，在开会的过程中果然派上了用场。

[2]在议程的帮助下，会议开展得很顺利。通过讨论和头脑风暴，我们也大致确定了项目范围、分工和筹备期应该进行的工作。除此以外，组员们纷纷表示：希望可以尽早完成项目，不要拖到期末。

总的来说，在开完会后大家都热情高涨，我也不例外。毕竟在上学期组队被划水的队友坑，我至今心有余悸。[3]但是在这次会议中，我了解到各位队友都是比较“有料”而且积极的，这样让我感到一丝轻松。尽管我没有如愿担任产品经理，但既然已经有人愿意担起大梁了，我可以作为一名普通组员“躺”的话，还有什么好挑剔的呢？

小结

• [1]会议要有议程：通过议程明确会议的目的和讨论范围，会议才不会漫无目标，会议的效率才能提升。
• [2]议程应该提前公布：与会人员应提前阅读议程，并思考将要讨论的内容，而不应在会议上临时思考、临时决策。
• [3]组好队伍非常重要：组队的过程是一个双向选择的过程，越早开始组队，就越容易找到靠谱的队友。组队不规范，打码两行泪。

附录

• 会议记录

---

3月23日——第二次开会

根据上周会议的安排，在过去的一周里我兼任设计师和前端，简单学习了Axure原型工具的使用和大体了解了Vue和React框架的使用。实话说，因为我的Coding能力比较一般，对代码的敏感度也比较低，因此我只是简单了解了两种框架的使用和开发者评价而已。

一周过去了，项目经理建议在这一天检验大家的工作成果并通过进一步讨论对项目进行细化。[1]然而架构师回家了，只能通过语音的方式参与会议。期初我们不以为然，觉得不会太影响会议的正常进行，但结果表明：影响很大。

[2]会议上大家都简单地汇报了上周进行的工作，但是大家都只是“了解”了相关的技术，除了设计师做了一部分原型和项目经理创建了Git Project以外，团队没有任何实际的产出，包括产品经理也没有书写过任何文档。看来队伍的开工效率也没有想象中那么高(后记：当然，这也算是正常的，毕竟前期什么文档都没有，怎么开工？当然，产品经理不写文档还是有锅的)

这次的会议进展很慢，尤其是在技术栈选择的讨论上花费了很长的时间也没能确定下来。[3]大家都你一句、我一句，你一个方案、我一个方案地无止境地讨论下去，直到我建议：“前后端各选一个组长，由组长负责拍板。拍板后组长要对选择的方案负责，其他人听从组长的安排开发。”，技术栈才最终确定了下来。

[4]当然，开会的过程中我们也遇到了很多无法确定的问题，比如：“项目结构”和“详细的业务流程”。我便提议将这些问题标记为待定，并指定组员跟进该问题。

在基本问题已确定、需要深入讨论细节问题的时候，[5]我建议前后端分开讨论相应的技术细节和具体分工，便散会了。

小结

• [1]尽量不要语音会议：受制于手机麦克风和扬声器的限制，语音方常常不会听清楚与会人员的发言，与会人员也很难听清语音方的发言，造成很大的沟通障碍、影响会议质量与效率。
• [2]确定工作计划时要包含可考核的指标：如果没有具体到可考核的指标或产出，只是空泛地说“了解React/Vue框架”，那么组员们一般也不会积极地完成任务。更科学的分工应该为：“了解React和Vue框架，在此基础上起草一份简单的报告，作为框架选择的依据”。
• [3]在众说纷纭时的决策方法：
  • 共同制定选择标准：如果团队没有确定一个选择的标准，却在一昧地提出方案的话，决策是无法达成的。因此，在头脑风暴以后大家需要确定一系列选择的标准，如：实现难度低的方案优先/能够锻炼能力的方案优先/可拓展性强的方案优先……
  • 寻找拍板人：如果在确定了标准后，团队仍不能作出最终决策的话，我们就需要推举一个可以拍板的人。这个人应该比别人有经验、有能力、有担当的，而并不一定总是项目经理和架构师等。
• [4]适时地将某些问题标为待定，但一定要安排特定人员跟进：在开会的过程中，我们可能会讨论到一些不在议程中，却又很重要的问题。对于这类问题我们不必当场做决策，因为大家此前都没有认真思考过这些问题，当即做的决策质量都不会太高。因此，合理的做法是将这些问题标记为待定，并指定人员负责跟进和汇报结果。
• [5]适时开小会：在细分问题的讨论上，我们并不需要所有人都在场，只需要所有“相关人士”到场即可。因此，在项目的早期的会议多为全员会议，但在此之后就不必要开全员会议了，应以小组会议为主。否则团队就很“官僚”，一点都不“开发”，只会消磨大家的热情，也影响了会议的效率。

附录

• 会议记录

---

3月24日——意外画出用例图

根据昨天会议的安排，我和项目经理一同讨论了项目的业务流程细节。在讨论的过程中，我们无意间把项目的“用例图”和“领域模型”的数据结构部分捣鼓出来了。之所以说是“无意间”，是因为我们并不了解“用例图”和“领域模型”到底是什么，也不知道应该如何画图，只是参照往届优秀项目的相关图表依葫芦画瓢地捣鼓而已。

在捣鼓这幅图的过程中，我们也意识到这幅图的重要性——基于这幅图，设计师可以做出符合业务需求和业务逻辑的原型；前端可以基于原型开发实体；后端可以根据数据结构设计数据库、根据前后端的连线设计API。那么我们需要做的工作就非常清晰了。所以说，[1]文档确实是促进团队达成共识和明确目标的有效工具。

小结

• [1]在项目中，文档非常重要：在以往的个人作业，又或是组队的代码作业中，我们不需要做任何文档就可以完成，因此也会先入为主地不重视文档。但是在“项目”中，尤其是在涉及到“业务”的项目中，没有文档的开发就是无米之炊。

附录

• 初版用例图：在现在看来，这幅“用例图”画得非常糟糕且不符合标准。毕竟在画图时，老师还没有讲到这幅图应该怎么画，我们也没有开始自学。但即便是这样，这幅图仍然很好地帮助我们提升对项目的理解。
  

---

3月26日——“篡夺”产品经理

这几天，项目组似乎停摆了一样。大概是因为大家在停工去忙其他事情后，需要重新“打火”——在群里动员并私戳关键人员动工，才能让项目重新启动起来。但因为我们不能频繁地“打火”，否则只会烧坏“起动机”。因此这次要确保打火后可以有足够的燃料和明确的“目的地，这就非常需要文档的指引了。但是原定的产品经理似乎开始“划水”了，不见任何文档产出，私戳他也没有回应，仿佛人间蒸发了一般。为了保证项目进度，我决定“谋朝篡位”——自己担任产品经理并制作文档。

---

4月10日——再次醍醐灌顶

项目搁置了很长一段时间后，我回头看“课程项目实践模板”才突然发现，这个模板其实是严格按照SDLC的顺序来编排的，即——可行性分析与计划阶段（About, Team profile, Investigation, Vision, Product Backlog）、需求分析阶段(Requirement specification)、设计阶段(Design)、实现阶段(Production spcification and guidelines)、(测试阶段)、(运行与维护阶段)，与完整的六个周期相比，本次实践并没有明确要求我们进行测试阶段和运行与维护阶段。

老师都帮我们安排好了开发的时间轴了，但是我们一开始并没有意识到这一点。我们小组只有一个“赶快做完这个项目”的念头，而忽视了遵循软件生命周期的意义——我们的“瞎几把”开发模式确实可以让我们快速地完成一些模块的开发，但是没办法实现整个团队的全面开工。如：前端可以先快速地把登录注册页面做了，然后再告诉后端需要用到的接口，后端根据前端的需求做API。但实际上我们应该先把API设计完，这样前后端就可以同时开工，而不需要前后端进行单方面的等待。这只是一个不太恰当的例子，如果不依据生命周期，将需求分析和设计都完成再开始编码的话，整个开发过程是毫无章法的。

之所以会出现这种情况，项目经理缺乏项目管理经验是一个原因，另一个原因是：作为产品经理，在需求分析的文档还没有完成的时候我就去学Axure做原型设计，在设计阶段还没有完成的时候我就去看Vue。这些都是不合理的！我们在第二次会议——需求分析和设计的阶段都还没有完成的时候就急着确定了我们在实现阶段所用的技术路线，这就像是无根之水，事后也证明当时经过争论、辛辛苦苦地选定的技术路线其实是并不符合我们实际开发需求的——一本正经地做了无用功。

小结

在此建议后来者：我们这门课要学的是怎么“做项目”，而不是怎么“打代码”。因此，我们在前期一定要静下心来完成可行性分析与计划阶段、需求分析阶段和设计阶段再开始考虑编码的问题。我们程序员很容易产生这样的畸形的想法——只有代码才意味着进度，如果把时间放在分析和文档准备，那就相当于浪费时间。但这次惨痛的经验告诉我们：不是的，编码前的阶段不仅不是浪费时间，而且对后续的编码而言非常非常重要。对于一些大佬来说，要直接完成这个项目的代码应该是不难的，他也不需要去认真地做前期的工作就能直接生产很好的代码。但是对于一个团队来说，如果不做好前期的规划，在实现阶段将无法很好的分工。

---

总结

综合所有经验，在此我对师弟师妹们提出以下建议：

• 在组队的时候一定要谨慎。千万不要碍于情面，任由喜欢划水的人和不认识的人加入。否则苦的将是所有认真干活的人。如果实在组不到认识的人，在组不认识的人时应该考虑以下问题：
  • 绩点：绩点太低的人多半对成绩没有要求，更不要奢望他们会认真做项目。
  • 出国：出国党对绩点的要求较高，且更加害怕挂科，因此在做项目的时候往往会比较认真。
  • 实习：对于将要实习的人，一定要谨慎。虽然这类人多是大佬，站在抱大腿的角度也是不错的选择。但是一旦他们忙于实习，没闲暇做项目的时候，自己就只能听天由命了。且不用说：实习大佬们并不太关心自己的绩点，反正好的工作都找到了，接下来只要能毕业就行。
• 项目早期优先制作文档：有了文档，就可以制作原型；有了原型，所有人就有了对项目更好的理解；有了理解，开发团队才能流畅地合作开发(单打除外，单打的大佬不需要和别人合作，也不太需要文档的辅助)。至于技术栈等问题，在文档和原型的制作过程中再由相应的开发人员慢慢思考即可，不需要急着确定。

项目的早期往往队伍最迷茫的时候，当我们不知道应该做些什么的时候，就先写文档吧！有了完整的文档后，就只是两横一竖的问题了。