项目管理一迭代无处不在

   迭代是数值分析中通过从一个初始估计出发寻找一系列近似解来解决问题(一般是以方程或者方程组）的过程，为了实现这一过程所使用的方法统称为迭代法。
作为程序员，我想大家都很熟悉RUP的概念或都在项目或产品中也实施过RUP。
我在现有负责的产品聚聚呀架构工作所能感受到的，迭代它无处不在。
无论是产品的概念还是在产品的设计，架构和开发。

  任何一次新功能发布整个生命周期都需要迭代。
互联网产品的需求相对于传统软件产品来说产品的功能生命周期很短，需要不断的去创新，发掘，并且以最快的速度去发布才有可能在互联网这块市场上去验证产品成功还是失败。而传统软件服务的对象是传统企业，组织或者是行业标准类的公司。因为组织无论是它的组织结构还是业务规范，商业模式，这种变化来的时间会比互联网产品慢，并不是说这些传统软件不需要迭代，而是迭代的层面的时间会有很大的差异，互联网更多的表现在一个“快”字，从产品的概念到原型，设计，切割，开发现实，测试上线等整个过程都需要快速，有时这个周期只需要一周，特别是像网游类的产品更是。

  在我负责的产品也是如此，运营部门收集到用户的某些需求经过整理后，提交产品部门，产品部门需要经过快速的PK后产生的最终的产品新功能的需求交由设计部门产品图，这个时间会很短一般不会超过一周。就这二个过程也算要一个小小的迭代，设计完稿后才会到页面工程师手里切出HTML出来，然后会给开发人员。
同样，设计师与开发人员之间也会有迭代，在实现的难易度和产品的“价值取向”上会做调整，有时设计出来的东西很好，但从产品的全局来看未必了，就如产品的性能和用户的体验有时感觉是一矛盾体。程序员实现功能后会与测试部门的同学进行迭代。

  在整个过程中好像没有看到架构什么事！其实不然，架构是需要从产品需求的提出就需要切入在整个的周期里面，如果把架构划入实现的阶段那是很悲哀的事，架构师基本不知道为谁而做？也不知道做出来是什么样子，更不知道将来会是什么样子，更不要去谈什么扩展了。但事实上很多公司会这么做。
架构师就像“全科医生”什么都需要懂，更重要的是每一次的“用药”都需要从各个方面考虑然在不伤害根本的前提下再做出相对靠谱的选择。
所以做为一个架构师的能力不是憋的，是需要磨历。
架构师所需要的十项技能：
http://developer.51cto.com/developer/top10Architect/