其实这并不一个严肃的文章，只是对于日常经历的闲聊而已。（其实本简书文章都是闲聊233）
产品演进而非规划是极其重要的，用MVP试错也是老生常谈的道理。规划固然重要，但是规划更多是方向而非细节，面对广大的用户群，其组成与需求都是会不断变化的，演进的过程就是一个基于现状、合理推演、验证想法的过程。尤其是在涉及社区的产品，哪怕是像素级拷贝另一款产品，也不能一蹴而就完全将对方成熟的社区复制过来，而是需要一步步与用户共同进化，配合运营改进产品。
其实演化与规划并没什么可谈的，常识性问题。演化的另一个好处就是符合互联网敏捷开发的模式。规划更像是常见于外包企业的瀑布模型。不过在校园的产品团队中，依然遇到大家总是盲目规划而非演化的困境，聊聊感想。
优秀的学生互联网团队实在太难产生了，学生团队的问题就是大家都是学生，不专业、学业压力、管理能力与实践不足这些问题都对团队有消极影响，尤其团队规模变大时。优秀的学生互联网团队假如脱离学校只有更优秀，毕竟他们战胜了那么多负面因素，不优先的学生互联网团队无法脱离学校，只能依附于学校被学校成就。我和其他学校的互联网团队也有过短短的交流，中大的互联网团队也面临着同样的问题，团队文化薄弱、凝聚力差、大多数人没有贡献也没有成长、低效以及不专业。但和华科联创与冰岩的同学聊的时候，得知他们团队运营状态如此良好确实很令人惊讶，确实是很棒。
在近日的一次新产品的评审会上，几位新人抛出了idea，老人们负责猜idea好不好，不断的做出臆测与假设，又不断的抛出新的idea，甚至开始考虑要做怎样的一个社区。我就只能表达现在的想法太多了。在还是讨论一个idea的时候，就开始不断开脑洞，还想力求市场上没有竞品、开阔一个全新领域，这种想法自然是荒谬的。学生团队的日常就是自我感动，在一个话题风向变成自我感动的群聊中，那些对于自我感到嗤之以鼻的人也就不会发声了。我觉得那些过多的猜想都是没有必要的，先做出最核心与基础的功能推广一下看看效果，然后再在地基上添砖加瓦，在没有任何验证的情况下通过多轮讨论造出一只臃肿的怪兽，无论对于产品还是开发都会是一种负担，且不论成品效果如何，在漫长的开发周期中没有丝毫的正反馈就像是背负巨石在黑漆漆的山洞里爬行，直勾勾的望着虚无、期待光明，最终困死在绝望之中。一次次短暂燃起的热情像是一根根地划火柴，在点起篝火前只能带来片刻温暖，随之被更加刺骨的冷所覆盖。我总觉得自我感动、盲目乐观的本质是认知能力的不足，是智识缺陷。有时看人群陷入狂热总有一点点清高之感，但又警惕自己是不是也陷入了自我感动？
我一开始很赞同敏捷开发，想做出一点推动，想建需求池。不过只是一厢情愿，我现在觉得敏捷开发对于团队的要求很高，需要高度的默契，以及高度成熟的工作流程，明确的反馈与责权绑定。对于学生团队而言，可能循规蹈矩的开发模式反而更合适，每一部分的同学完成自己的那一部分，沟通成本大多发生在交接时而不是永远在讨论、耗尽能量。当然肯定会出现的事情是一部分同学清闲而另一部分同学忙碌，产品拖设计、设计拖开发、开发拖产品。但是严格规划时间，合理控制需求量，这些负面是可以尽可能避免的，毕竟合作的性质就是如此，每位同学主力工作在不同的时间段是无法避免的。敏捷开发的好处对于学生团队其实是不重要的，快速决策、得到反馈、某种意义上降低沟通成本。“能用就行”，这就是最大的原则了。选择什么样的开发模式，还是选择任何组织架构，一定要结合实际明确优劣。强行敏捷开发，看上去只不过是所有人都在快节奏中手忙脚乱修修补补而已。
当你处于一个环境中，才会觉得改变环境多么的难。其实也没有那么不堪，不必抱怨，一些小小思考而已。
