IT项目版本迭代流程

葫芦是技术出身，从java开发到android开发再到技术部经理，思考问题多站在开发的角度，制定的流程也只在开发和测试环节，导致一定的局限性。经过一年多的试探，调整和强化，现有流程已经得到很好的执行，渐渐地需求和设计对项目的进度凸显出来。开发固然很重要，但项目的进度取决于需求，开发和测试，还有设计，需求的变动和设计稿的出活时间直接影响开发的工作。项目流程需要再次升级，这次主要是范围的扩大。

已有的流程是这样的：

之前没有想到用图形化工具设计流程，直接写的文字，既难看又难懂，也是够可以

需求对项目进度的影响可以分为两部分：1.需求实现的复杂度;2.需求提出的时机。复杂度最直接的影响是项目周期，越复杂所用时间越久，有时候甚至某些需求直接实现不了，于是对于需求要有评审过程。开发工程师对需求进行评审，可以评估开发时间，可能遇到的问题可以及时反馈，让产品经理有个大体概念，或者某些需求开发成本较高是否有必要实现，还可以及时发现一些逻辑上的问题，这样需求可以进行合理的调整，避免中途调整需求对整体进度产生很大影响。测试工程师对需求进行评审，则可以评估测试周期，也可以从用户的角度考虑新的需求是否是合理的。第二部分是需求提出的时机，理想的做法是在开发工作开始之前需求完全确认，中途不再提出新需求，实际上中途提新需求的现象时常发生。拿APP迭代举例，服务端需要提供app需要的接口，通常服务端的开发先于app的开发，服务端开发完成，提供测试接口，app对接，然后出app的测试版本。如果在app对接过程中，提出新的需求，而这个需求需要服务端的调整，那么服务端要进行新的开发任务，开发完成后才能提供接口，app在这期间不能拿到新的接口进行测试，极端情况就会使app的开发中断。

设计对项目进度的影响可以分为两种：1.设计稿，即UI;2.运营所需素材。UI目前主要针对app，后台对样式要求不高，由前端工程师根据设计原型自己实现即可。app的开发很大一部分是写界面，根据尺寸或比例进行绘制页面，ui即是依据。UI能否及时提供决定app正式开发的时间。对于素材，app上展示的图文内几乎全部来自于后台添加，图片需要设计人员提供，如果版本开发完成，而后台没有素材添加的话，版本上线只能延迟。

所以新的流程加入了需求及设计进度上的要求：

使用图形表示看上去清爽多了，只有流程的大概，包括一个版本从需求到交付的整个过程，细节部分并未体现，有待补充～