关于互联网思维与技术团队的一些总结

==========2017.7.4更===============

真正在底层工作的人员 跟站在高层的人看到的东西都是两个东西。

真正的从底层走到高层才能看的更精准  。

同样的  从底层走到高层的人  也没有一直处在高层的远见与见识。

我信奉公司处于什么阶段用什么样的人，没必要一开始就弄高精尖的人和事，毕竟成本不一定是你能承受的了的。

==============================================

现在的互联网经济可以说是日新月异，从P2P到O2O，互联网金融，互联网保险，还有最近大火的共享经济，可以说是百花齐放。。。

然后其中的隐患也是相当的巨大。

==============================================

所谓的互联网思维，敏捷开发与快速迭代来适应瞬息万变的市场需求，

很多适合市场部制定一个需求，就要求研发部门在很短的时间内上线运营。。。

我相信慢工出细活，所谓的敏捷开发，快速迭代所带来的后果，一定是前人挖坑后人埋，从一开始的架构上没有考虑系统的扩展性就迅速的投入开发，上线运营，

一旦当项目正式运营，再想重构项目的成本是非常巨大的，很少有人会去真正的重构，只是在现有的架子上 修修改改。。缝缝补补。。

当项目臃肿到一定的地步的时候。。。。也就是瓶颈所在了。

再说重构，没有一个对业务了如指掌的人带领这个项目，重构是很难进行下去的。

日益增长的业务需求，到后期达到一个量级不进行合理的拆分。。我想。。。后果可想而知吧。

敏捷开发，快速迭代没什么不对，但是在动手开发前一定要合理的规划业务，当业务达到一个量级的时候合理的拆分，必要的时候该重构就重构，毕竟谁都不会一开始就把所有的东西考虑全面。

还有最重要的就是人员迭代。。。leader要考虑到团队中的人员是不是在你把控的范围里，一但脱离了把控我想主动权就在他的手里了。而去同一模块的业务要保证最少两个人去负责，整个团队的人员配置也要在饱和的状态下多出来2-3人，做技术的大家都知道，离职是很正常的事情，不要因为一两个人的离职而导致项目的延误甚至崩盘。

整体项目的技术应用也要自己的规划，不要把所有的新的技术都应用在项目里，没有完整的生态环境代表的就是少量的文档跟一堆没有踩过的地雷。再者对于团队的新人来说，学习成本跟技术能力都是提高了很多。。

如今的技术现状已经完全满足了开发的必要条件。不要一味的去追求高大上的东西。。。毕竟项目运行要以稳定为主。