Intro
一个学期结束了，我们小组从讨论到实现最终的成果，经历了一些磨难和考验，最终做出了成果，实属不易。在这期间，作为项目的产品经理，我有做得好的地方，也有做的不好的地方。现在我就来分享我们一群新人第一次完整开发一此项目的时候的一些经历。
由于我们只是学生团队，分享的经验都非常的私人，所以请批判性的阅读！
这里我会尽量少的使用“用例图”等生涩的词语，而用了一些简单直白地表述。但是这不代表这些文档技巧不重要，相反的是，这些技巧起到非常重要的作用。但是系统分析与设计的授课内容不是本文的重点，所以请你就放松的阅读就好！
我们的项目叫“Tiny Hippo点餐”，核心功能有三
- 推荐系统
- 多人点餐
- 商家管理
- 团队 Github：Tiny Hippo
- 项目 Github：Tiny Hippo 点餐
总结
为什么一来就总结了？！因为本文长度很长！如果你时间不够的话，请直接阅读总结；如果你时间充裕，请跳过这个部分，下面每个部分都有小结~
- 团队建立阶段：后台团队一定要足够强
- 确定业务范围阶段：调研分析，列出（不超过3个）核心功能并抱着抬杠的心态来扣这些功能的细节。最后留下的功能就是业务范围
- 规划开发周期阶段：以 API 为节点来规划迭代周期，选择适合团队的节奏开发，尽可能少使用其他工具（只建议 Github）
- 开发阶段：再次确认文档是否齐全，以功能为单位来开发而不是以人为单位，少开会，最后聚到一起对接
团队建立
团队的建立我已经在项目管理经验（一）讲了不少，这里就总结一下我认为一个合适的（新人）团队最重要的就是：后台不可以太弱。后台需要扎实的工程实力，太弱的话项目进展起来会很难受。其他的都是一些烂大街的建议，这里就不赘述。
单独强调这个就是因为我们团队的后台真的很强，因此前端团队可以专心实现一些复杂的 UI，而很复杂的逻辑（像是多人点餐）都有顺手的接口直接调用，所以前端就很舒畅！
确定业务范围
项目开始阶段是最困难的阶段。因为这个时候大家还没有进入状态，我们必须潜入表格、图表之中推敲需求——这是最困难的部分
我们要做什么？大概要做到什么程度？核心功能有哪些？这些都是一开始就要确定的问题。由于这个是课程作业，老师给了要求就是做点餐系统（的确够简单），所以“做什么”这个问题没有花太多时间。花了我们很多时间是“做到什么程度”和“核心功能”这两个问题。这两个问题本质是连在一起的，讨论核心功能的时候需要有足够的文档支撑，产品经理需要说服团队成员。
调查 📈
首先是调查。调查文档反应出现在点餐系统的问题在于
- 新客人不知道点什么东西，身边并没有服务员推荐。现有的做法是做一个热度排序，但是我们觉得商家对这个东西掌控程度并不够——商家希望把餐厅打造成什么样，和客人喜欢什么东西，还是有区别的。优秀的餐厅应该有个性
- 多个人同时点餐很麻烦。比如和女朋友去麦当劳吃饭，两个人手机拿来拿去就很烦，分开点又有点不好
- 商家管理自己的电子菜谱不够方便
了解到这些问题之后，我们对应的给出了三个解决方案
推荐系统 👍
商家可以自定义要推荐给用户的内容，形成了一个“小菜单”的形式。用户可以通过这个小菜单简单直接的选择商家配备的套餐。
这个功能比较新奇所以没怎么被挑战。但是这个功能可以发挥的点有很多，这里是餐厅的个性体现。
多人点餐 🥗
为什么不直接语言交流？多人点餐的最大弊端在于他让客户更专注于手机，而不是交流了。和朋友一起出来吃饭本来是很快乐的，就算手机拿来拿去比划比划，也是自有一番乐趣。我在思考这个需求的时候花了一些时间，因为我始终无法说服自己说这个功能是不可或缺的。如果说手机点菜、电子推荐是减少了人力成本，这个功能似乎没有任何必要——我们有时候需要的不是更方便，而是更开心。但是老师后来提示我们，点餐系统主要服务对象是“普通市民”，高档餐厅或者主题餐厅根本不会用手机点餐这种很时髦廉价的方式。普通市民不会注意到这个问题，他们更多的关注是方便与否。所以多人点餐被加入。
那么多人点餐要完成到什么程度？大家乱糟糟的点完之后，我以为是你点的葱油饼，你以为是我点的，但是其实只是不知道谁按错了。大家无法check自己的菜——所以必须要分成不同用户有一个小的购物车。接下来，付钱的问题，多人点餐怎么付钱？分开付是不行的，那一起付的话，怎么确保大家的菜都点完了？这里我们借鉴了王者荣耀选择英雄的方式，大家可以锁定自己的菜单，然后大家说话“我点完菜了！”，再由给钱的大兄弟一个人付款，清空购物车，吹水吃饭！
商家管理系统 📡
很重要的功能，然而程序员很容易忽略这个点。
商家管理系统我们采用了网页端，因为它不需要任何移动端的便捷优势，但是需要Web端的所有优势——毕竟要修改菜品、排列顺序等等，这些都不是小事情！所以我们决定在网页端呈现这个系统。
那么基本的功能：增删改查，就够了！简洁直观，老板也没那么多时间去分析数据（其实是我们没时间开发了）
小结
对这个部分做一个小结。我们确定业务范围的时候主要花功夫在三个地方
- 调研分析，找到痛点，列出三个核心功能：推荐、多人点餐、商家管理
- 抱着尝试推翻这个功能心态和产品经理抬杠，确定这个功能的必要性
- 深入探究细节，把整个流程走一遍
规划开发周期
迭代 👩👩👧👦
每次迭代要多久？我们的答案是：一个月左右。有人会问：不是一个星期吗！可是我们是学生团队，中间回个家，参加个比赛，旅游一下，赶一下其他作业，时间就溜走了。这个时间对我们团队是很友好的。所以我们推荐是一个月一次迭代。
那么，通常三个迭代以内就要做出一个比较完整的成果（可以交的作业）
。每个迭代要怎么分配任务呢？我们给出的答案是：
- 第一个迭代以API的确定为结束
- 产品经理画图写文档
- 前端先快速搞出成果（用mock的数据）来选一些比较舒服的API
- 后台开发数据库，同时积极讨论API的建设
- 我们的第一次迭代会议内容
- 第二个迭代以开放API为结束
- 第三个迭代汇总。汇总就是，大家坐到一起，然后两天之内换掉mock的数据，和服务器对接上！
所以说，整个开发周期是以“API”为主线的，这是我们的经验。为什么要以 API 为主线？这里我没有使用“瀑布”“原型”等等高端专业词汇，我用盖房子来做比喻。盖房子第一步打地基（数据库），第二步建框架（API），第三步添砖加瓦刷墙壁（对接）。为了效率更高，砖瓦墙壁的设计先在一个空中楼阁（mock数据）上挑选好，最后直接对接就行！楼房的骨架就是API，所以API是一个分界点。
我们的API文档
任务分配和记录 📋
每次开完会后要如何保证大家都按时完成了任务？这里答案就是利用协同软件！微信上大家和和气气，就不太好了一些沉重的话题，在KANBAN上表现比较糟糕的就要果断提出并催促他完成任务了！
协作工具选择的建议是，不要使用除了 Github 以外的团队管理工具！大家可以微信上聊聊天，但是工作记录等等都使用 GitHub 是最好的。我们用到的 Github 除了 git 分支管理以外的功能有
- Teams，把成员分组，前后端代码不要随便交叉碰
- Projects，记录每天的工作量，KANBAN
- Github pages，作为团队作业的发布栏目。有好看的排版的话，成员也可以在上面关注项目进展，会议记录等等
我们尝试了很多其它的协作软件，包括石墨文档等业内流行的工具，然而太多的工具只会让团队感到疲惫。就用 GitHub 就够了！
小结
对这个部分做一个小结，在规划开发周期的时候
- 以 API 为节点来规划迭代周期，挑选适合团队的时间长度
- 记录和分配每个人的工作量
- 使用尽量少的团队工具，通常 Github 一个就够了！
打代码啦！
准备 💉
打代码之前确认一下，自己是不是清楚功能是什么，有没有清晰的文档。如果没有，请联系产品，不要直接开始！在我们打代码的时候发现，如果一边打代码一边想自己要做什么的话效率很低！一边打代码一边质疑自己的产品，效率也很低！所以打代码之前请确认文档足够清晰！
分支管理 🔀
个人分支还是功能分支？这次实践中，前段使用的是个人分支，即每个人一个分支，实际使用起来有点难受。因为大家做的功能多少有一些重复的部分，如果只是每次迭代结束的时候合并分支，会出现很多冲突。后台采用的就是功能分支，开发完一个分支之后直接合并到 dev 分支，这样个人分支分出来的时间很短，很快就可以合并到主线。
所以我觉得用功能分支是更舒服的
解决问题 🔨
打代码的时候遇到问题怎么解决？我们的答案是直接找负责人解决！小团队就不要层层传递信息，直接找到负责人，一个电话一个微信打过去，让他5分钟解决问题就行。我们在这里做的就非常好，大家都很直接，问题也可以得到非常快速的解决！
沟通技巧 👬
打代码的阶段沟通是很必要的。在我们沟通的时候得出以下几个经验性结论
- 不要使用首字母缩写或没意义的词来称呼物品、软件或流程。尤其是团队内有一位技术大牛的时候，可能他会比较喜欢卖弄自己的学识，用一些艰深的术语来称呼物品或软件。我对此深恶痛绝，所以每次当有成员用简写的时候，我就会再问一句例如“BCE是什么意思？”。（不过我们团队所有人都很亲和，这一点只是我在和别人交流的时候的感悟）
- 讨论而不是命令。很多leader可能会走到程序员面前说：我们要重构。这样的命令在 hierarchical 的大公司内可能效率最高，但是在小团队内，这样做绝对是灾难！我们每一个改动都会尽量沟通，而保持效率则是通过每位成员心中“不要质疑”的信条来保证决定有效的传达。所以当我突然决定要删掉菜单顶部滑动栏目的时候，前端队长果断的回复我：拒绝！并为我解释她的理由。总共耗时5分钟
- 当面表达你的情绪，而不是积压。打代码的时候情绪会比较激动，尤其是当团队有成员偷懒的时候，如果情绪不有效的释放，到最后可能会有毁灭性的后果！如果你对某位成员不爽，直接给他打电话大吵一架，合理的提出你的不满，然后去吃烤鱼打王者荣耀。
- 这个阶段少开会！到后期我们开会频率明显变低，会议逐渐变成微信群或者单独的快速沟通和反馈。这样效率最高，开会真的挺磨人的
对接 🔗
最后交接项目之前一定预留72 小时来对接，因为可能会遇到很多莫名其妙的问题（像是跨域访问等）。并且 mock 数据说不定会有一些接口大小写不对应的问题，前后端对同一功能理解不同的问题。
在我们的项目中，我们最后花了三天时间坐到一起，从新活到全家，从文化室到新华书店，最后终于对接成功。对接的时候主要问题是①跨域问题；②前端访问API太过频繁（更新菜品后立即刷新页面），数据库承受不住压力就爆掉了。这两个问题的具体解决方法可以看下面两篇由我们的成员写的博客
这样我们就对接成功了！撒花 🎉
部署上线 ☁
最最最后一步，就是部署上线。这里推荐查看后台朋友的博客
最开始我们的服务器很脆弱，没有任何保护，在遭受了一次DDoS攻击之后，服务器掌门人 longjj 决定要加一些保护
小结
对这个部分进行一个小结
- 打代码之前请确认文档是否齐全，自己是不是清楚自己要做什么内容？
- 将任务按照功能分而不是按照人来分。这句话听起来有点矛盾，意思其实就是我们的目标是完成功能，而不是让某个人来完成多少的工作量。一个功能完成就好，不在乎几个人来做，谁想做就去做！
- 少开会！采用尽量高效的沟通方式，比如打电话，发微信，面基等等，用尽量高效的沟通技巧来协作
- 打代码应该是比较快能完成的！
最后
最后感谢每一位团队成员的付出！晚上 11 点叫出来喂蚊子，打LOL的涛涛也没什么怨言；在群里疯狂艾特阿杰和阿仰重启服务器和部署最新的代码，无论什么时间，反馈时间都在一个小时以内；无论改多少次需求阿鹤和阿rururu都没有说过一句不好听的话。还有最后加入的阿爵也非常用心的跟上我们的节奏。我写这篇博客是觉得，团队作业那一点点内容不能表现出我对你们的喜欢和感谢，这次团队协作真的是很愉快很愉快的经历！
有了你们，才有了 Tiny Hippo，谢谢你们！
