标签：发展 之间 com 云效 地方 app 如何 system 角色
进销存可以说是数据管理系统之中的较为大众的系统
在通过"类敏捷模式"开发后,项目做成了 难度不算高
1.沟通
前期项目需求的沟通可以叫作无纸化办公,因为客户不太懂软件,销售人员需求获取不明确
我极力推荐他使用故事方式与我沟通,即用户故事 User Story
假设销售人员有一个可以拿出手的样板系统,我们称之为 "Application Model"
拿这个样板的进销存系统与客户对接,这样的话,用户大多的反应可能是这样的:
"嗯嗯,这个功能对"
,"嗯嗯,我们也有这个类型的数据"...等等
所以在对接完毕之后,对我们可以开发以及软件质量程度,都可以在"Application Model"上进行了初步的验证和对接.
销售或者售前再继续跟客户对接比较具象具体的内容.
如你们具体都需要哪些数据管理,大概流程是怎样的.有什么特别需要注意的地方.
如果客户那边有完整的需求,就不用这些问题了,而是直接拿需求回来即可.
将需求确立下来,比较稳妥的方式是在客户那边有相关计算机专业或是对软件有很长时间使用话语权的人对接,这样会节省将近200%的时间有木有?
接下来销售/售前经理需要跟公司对接需求以及具体情况,报价之类的不在本篇详述.
需求评审,大家开个会,是什么具体需求,用到哪些技术,能不能实现,实现难度大不大?等等,总之就是几个字 ----
能不能做
确定能做之后,开始分析需求->确认人员->确定任务->代码实现->测试交付
很难想象,客户每次基本都不按自己说的需求来,尽管签了合同,通知了再加功能可是收费的哦,
其还是没有觉悟,兀自增加功能或者原功能的调整.那么整个需求从我们项目初期就要做好打算,我们要持续迭代更新了.
与传统软件开发的计划驱动不同,敏捷开发模型需要的是价值驱动,价值的提交.每个可运行版本就是一个小的程序精品.
而作为用户方面,其不确定性的需求导致其从用户角色变为"使用产品及反馈意见的客户".而这里的使用产品,并不是说我们这次
代码里面的alert或者console,或者system.out不删除,我们的宗旨是每个交付版本即时我们预料的最终版本.只有这样,才能做到最好.
如上图所示,传统开发模式瀑布模式,是要从需求,整个设计文档,一套标准化下来.
敏捷就比较敏捷了,他是每次都给到客户一个可运行的版本,之后按新的需求,按照投资的增加,或者技术的发展对整个软件程序进行更新迭代.
那么在把"需求","产品计划","开发计划","迭代计划"(还有其它的不一一列举了)都制定好之后,我们做的就是将软件进行持续的迭代测试部署就好了.
2.开发
开发是以打代码为主,在产品总监经理PM将产品需求跟项目经理沟通后,项目经理再将整个的开发流程计划进行部署安排.
常见的项目管理工具有禅道,阿里云云效,ones.ai等.
每个人员适合做什么,怎么做,大概会做得如何,这点在团队中的项目老大是要必须清楚的.
在业务还需要梳理以及人员之间要进行配合时需要进行有效的沟通.
有效沟通包括,当面沟通,文档传送,以及图片示意.
在人类的大脑中,在古代原始社会就有了一些图形图案记录人们打猎的场地,部落的规矩等等.
而这种图形图案也是要一眼就会起到提醒的作用,人去理解图形(好的图形)要比去阅读一段超过300字的流程说明要轻松地多.
开发伴随着代码的提交,问题的检出,最终进行程序的测试部署,在测试与开发设计文档进行对比测试后,方可转由其它人员进行与客户的交付对接.
而在敏捷开发模型中,这仅仅是刚开始.
3.迭代
这里的迭代,有的是功能的加强,有的是新的需求,有的是对程序需求完全(差不多)确定后,对程序整体的优化.
先吃饭~
后更新~
Work Breakdown Structure
标签：发展 之间 com 云效 地方 app 如何 system 角色
原文地址：https://www.cnblogs.com/ukzq/p/12496776.html
