八月末。北京已经散去夏天的炎热，剩下的，是深深的余悸。
七月，注定不是安稳的一个月。公司战略调整，进驻了新的产品和空降了新的CTO，导致原有的作业流程被重置修改。说的直接一点，整个技术一团糟。
在这个前提下，开始了轰轰烈烈的长征。
七月的北京，热。也许有这个因素吧，整个心都浮躁不安，一遍又一遍地咒骂这该死的天气和不给力的空调。
新产品团队上任，推翻了之前的设计，信心满满的打算给boss交一份满意的答卷。
“嗯。不错，很好啊。二十天后上线吧”。
嗯，很好啊，开始砍需求吧。
和产品经过几轮的混战，终于在原型上达成了一致：只改一级页面，二级页面搬用之前版本。业务逻辑不变。
看来，改个好看的UI，比较让人满意。
和正常流程一样，需求评审结束后，分配好任务就进入了开发阶段，只有十五天的开发时间，留出来的测试时间非常少。如果真的和正常流程一样，那就是需求确定，开发完成，测试通过，上线万事大吉。
不用说，也知道其中出了岔子。产品改需求，加需求，设计跟不上开发节凑，等等问题。上文也提到，产品团队是新介入这个项目，还没有对业务摸透，导致频繁更改原型，我想，这也是开发和产品之间的主要矛盾。
改需求是其一，其次是加需求。项目前期，需求评审结束后，产品就已经不在这个版本添任务了。但是呢，项目后期又出现一些不得不加的功能，本来前端APP开发就是一个小步快跑，快速迭代的过程，拿一个普通的迭代周期，做一个大的版本更替，时间自然是不够的。加班赶进度自然也是家常便饭，周末两天加班连续三周，我已经头晕眼花。
尽管如此，项目还是在将近二十天的时候，赶了出来。即将结项。如果就这么完了，那也不存在拖垮的后果。产品在项目前期积压的需求，一下子爆发了出来，原因是需求方等了这么久，还没有看到排期，急了。
得，占用测试周期，加需求吧。虽然已经超出了预期排期，但毫无办法，这就是产品势弱，技术更弱的阶层公司。
加需求是其二，再次是测试。
—————————————————我是分割线——————————————————
现在已经是十二月，这篇文章就在草稿箱里呆了将近四个月。上面那个版本是怎么上线的呢，嗯，用了一种比较强硬的方式，测试通过后直接提审，和产品说其他需求等下个版本。
经过了这几个月，我已经没有以上的那种无力感，不会想着他们怎么怎么不对，而是在现有的资源上合理的计划需求。之前的时候不知道是不是因为天气炎热的影响，会抱怨别人做的不好，没有认真想想身为一个技术，怎么样才能最快最好的实现他们的想法。为此得好好反省反省。
经过了一段时间的混乱和交战，我的团队也逐渐稳定，虽然也考虑项目时间周期问题，但不是第一位，首先要考虑的是，怎么样更好的满足用户需求，有些产品设计遗漏的地方，我们会根据实际用户体验一点点完善，自己也在做学RP，只有把一款产品做细、做精致，才能体现出整体技术团队的成果。
每个团队的处事方式都不一样，我要做的，就是让我们的小团队融合到大团队里，做一颗不可或缺的心脏。
我们在工作生活中，总会遇到一些事情，这些事情往往和不合规矩或者和想象中不一样，我们也许会不知所措，也许会抱怨，也许会得过且过。但是，何不换种思维方式呢，这些事情都是一个个台阶，当我们顺风顺水的时候，需要这样的事件来提升自己，经历过后，站的会更高，看的会更远。