事项梳理过程
1 一个比较大的系统到底是怎样从用户(甲方)提出需求,到受理方进行需求的拆解,梳理和与用户进行需求确认,沟通然后跟踪,进入开发阶段。
2 系统太大牵扯到的原型就是理解不清了:用户需求确认时需要做原型,每一个版本需要进行迭代,一个开发的完成流程可能会拆解为几部分。
3 那就先说一下为什么需要做一个中台系统?
中台系统其实就是起一个转接的作用。做一个比较:
如果不做中台系统:
按照之前学习的开发模型,瀑布或者是敏捷之类的,我们需要去梳理需求,流程,程序员需要梳理代码,也别是比较复杂的业务设计需要大量的时间进行理解,很是浪费时间。
如果有中台系统:
中台系统有可能只会在特定的企业使用。举个例子;一个公司不管是出于某种目的需要做一个餐厅管理系统A,暂且这样命名;之后又需要做一个餐厅管理系统B或者是更多的餐厅管理系统,但是他们在某些业务方面或者是技术实现方面是相似的,也就是说如果是完全分开做这些东西会多耗费大量的时间,那么就会有比较niu的某些人干脆做一个平台系统,能够支撑其他开发人员进行业务系统的开发,这个平台就是中台系统。用技术人员的话说就是能够按照开发人员的需求进行自主配置用户的需求,然后自动生成一个餐厅管理系统。
心得体会
从后台开发人员转到梳理人员我认为其实就是一个从程序员转到需求分析的角色,这也解决了我很多问题。
1 上学期间老师为什么频繁让我修改界面,虽然他和功能并没有太大关系。(从一个不是很懂得用户触发,无外乎功能和美观,深入就是用户体验)
2 为什么有些东西就是无法跟别人解释的通?可能这就是科班出身的优势:1 有的时候一个名词需要解释很久。 2 程序员或者是开发者不关系业务怎样,直接了当的说你想要怎样的功能,说了一堆真的不理解。
3虽然这段时间并没有学习技术问题,不仅是公司的需要吧,自己也是从另一个角度理解了开发。