一、版本文化
根据我们多年的互联网项目开发经验，影响产品发布时间的主要原因有两个：1.产品经理频繁变更需求；2.技术方案频繁升级。因此，对于产品需求变更、技术方案升级、视觉调整要学会克制，合理的规划每个版本要实现的需求、使用的技术方案和视觉元素。
二、迭代文化
尽可能的将需求细化并落实到具体的任务和人上，将任务和BUG放入版本中进行迭代。一个版本可以拆分成更小的迭代版本，每个迭代周期（一周或者两周）处理某个迭代版本中的需求和BUG。采取快速迭代，定期发布的机制保证需求和技术升级不会过度而影响项目上线进度。
三、讨论文化
去中心化，严禁一言堂的做法，让所有团队成员都参与进来。产品经理需要规划版本需求，需要向团队讲解版本的开发需求；开发团队根据产品需求确定技术方案，并描述技术方案；测试团队要根据产品需求理解产品功能点，并描述对功能点的理解和可能存在的测试风险。
四、云办公文化
快速迭代的前提是明确的任务和随时可以进入工作状态的环境。所以不能受时间和空间的限制，做到随时随地可以工作可以讨论。用Tower进行任务分配和BUG反馈。Tower在PC、Ipad、手机上都可以方便预览。将代码托管到Github上，随时随地可以提交代码。
五、质疑文化
研发可以质疑产品需求，测试可以质疑产品需求，产品经理可以质疑技术升级，测试质疑技术升级，产品和研发可以质疑测试。保持三权分立，各自相互质疑又相互协作，需求的变更根据研发的开发工作计划，技术升级需要考虑产品需求多少，功能点的梳理和测试的时间需要严格按照版本需求说明和BUG数来执行。
六、Deadline文化
Deadline不是拍脑袋定下来的，是由产品需求，技术方案和测试时间共同确定。在汇总产品、技术、测试、运维给出时间后，对Deadline给予百分之二十的调整加减幅度。一旦到了Deadline需要在3天前停止需求的开发，全力解决BUG。没有开发完的需求可以砍掉的一定要砍掉保证Deadline这条红线
