会议室开发项目的总结

本来打算在这个项目v1.0发布的时候，再来写这篇回顾，也算是对这个项目的一个交代。但是数据问题迟迟没有搞定，再拖我怕我自己都忘了，所以就尽快把这个写完吧。

在整个项目开发和管理过程中，我们尝试了跟之前不同的一些方式，收获了不少经验，也得到了很多教训。
在项目筹备阶段，我们想采取集中开发的方式，把前后端开发，产品集中到一个会议室，一起讨论需求，确认需求，开发，以至联调。

在项目过程中，我陆陆续续纪录了一些问题和经验，不敢藏私，共享出来，抛砖引玉。

会议室开发模式方面：
1. 会议室开发算是半封闭开发，会相互影响，氛围起来了，效率相对之前有很大提升。就跟上自习一定要去自习室，健身一定要去健身房一样，周围的人都在干同样的事儿，带着每个人也就不想别的事儿了
2. 压力要比外面大，所以周期不宜太长
3. 如果有非常急迫的任务，我们可以考虑做封闭开发
4. 会议室开发能极大的提升沟通效率，比如前后端讨论接口文档.
5. 移动办公是趋势
6. 什么时候在会议室开发，什么时候不在会议室开发？需求讨论，接口文档讨论，接口联调，修改bug都可以会议室开发；其他时候可以不在会议室开发。另外，短时间内频繁的进出会议室也不是一个好的选择，会打断大家的开发节奏（比如遇到一个问题，进会议室讨论，讨论完后，过了20分钟，又遇到一个问题，在进会议室讨论），这时候你可以选择一段时间内都待在会议室里（移动办公是一个趋势）。

创新项目需求讨论方面：
1. 对需求和接口的集中讨论会有效提高效率，让产品变得更好，但是不加控制的话，讨论会让项目时间拉长，所以应该对讨论的范围有所限制（比如对于1.0版本不开发的内容不讨论，对于用户使用频率很低的功能不过深讨论）
2. 需求讨论和设计本来就应该占据项目周期很多的时间，所以现在的时间占比（将近2周）是可以接受的，对于孵化／创业的产品，2，3天出需求和原型是不可接受的，我们宁愿多花一些时间去考虑，而不是多花一些时间去动手
3. 做到第三周，砍掉了很多功能，整个结构都清晰了，回顾一下，我觉得我们还是在v1.0开发了过多的功能，尤其是在没有真实用户介入的时候，我们替用户假想了很多需求。
4. 讨论应该先圈定一个范围，在此之外的不予讨论，以免发散过多，讨论不可控
5. 讨论也应该是敏捷的，第一轮确定项目方向，第二轮在方向的指引下确定范围，第三轮在细化需求，避免在第一轮和第二轮讨论过细的逻辑。（讨论需要有一个主持人的角色，把控节奏）
6. 在项目中途，ios因为开发离职所以替换了一个新的开发，新的开发进来后，马上对我们之前头绪很乱的多用户这部分提出了意见，所以才有了现在简洁的1.0版本。这让我意识到，如果我们在项目期间，能够时不时的找不了解这个项目的人进来review，或者会有旁观者清的收获（其实很多公司都在做这个事情，比如发布核心用户版本）

其他方面：
1. 项目负责人可以做项目日记，这个很有用处（我在项目快开发完的时候才意识到）
2. 创新项目的第一版时间过长，影响士气
3. teambition是个好东西，但是以前用的不对，不能只是研发用，要整个项目用，因为它是一个项目管理工具，而不是部门管理工具。
4. 提高沟通效率：减少对im，邮件的依赖。对于rtx上5分钟说不清楚的问题，直接找人面谈；对于需要3人以上讨论的问题，直接找人面谈
5. 稳定的项目能让大家更加有归属感