首页 > 代码库 > 如何快速确定需求的技术实现方案
如何快速确定需求的技术实现方案
我们会在哪些地方耗费大量的时间
压缩需求确认时间的矛与盾
做项目的时候,一方面我们希望能够快速明确需求,开始投入开发,使产品能够尽快上线;另一方面,我们又深知需求会随着时间的推移越来越明确,就下意识的拖长这个流程。
需求细节的确认
需求应该确认到多细才合适?如何把握这个粒度?
方案优与劣的选择
这是最难的一个环节。目前仅靠个人经验和记忆力来做出判断,其实是很不保险的。因为有时候自己会不了解自己的局限性,给出的选择在另一方面就会出现问题。
外部接口的测试和沟通
需要注意两个地方: 第一是和其他部门沟通的方式:批量沟通+邮件交流+文明礼貌+严格自检 第二是自己这边,需要做好详尽的单元测试
程序框架、技术的选择
这个相对来说比较容易,只需要开发人员对于框架技术足够了解,知道其优劣,就能快速的做出选择。
搭建新项目的程序框架
直接拷贝已准备好的程序框架
新技术的学习
新项目,千万千万不要轻易尝试新技术。务必要在熟悉掌握之后,才将新技术加入正式项目中。
一些可以帮助明确需求和方案的方法
写分解文档
这个经过自己实践,是非常非常好的一个方法,在写分解文档的时候,你能拾遗补缺,发现细节上的问题,还能整理产品的流程,让自己思路更清晰。 如果是多人开发,那么建议每个人都写一个分解文档,然后汇总核对下,这样能发现很多被遗漏的东西。
讲出来
试想你是产品经理,将自己的理解,讲给产品经理听,或者讲给你的合作开发者听。讲述的过程,涉及语言文字的整理,同样会加深你对需求的理解。
设计数据库
这有助于理清楚数据结构和对象模型
名词定义
先定义好名词,能在交流的时候节省不少时间,这就像设计模式,一个词语就能包含很多信息。
一些常见问题
新事物
总之一句话:凡是涉及新事物,就必须谨慎考虑(新项目、新接口、新同事、新部门) 以新项目为例: 新项目的时间估算不能只看工作量,因为新项目还有很多其他的隐藏工作 比如方案设计、程序结构的设计、数据库的设计、和其他部门打交道等等 无中生有比优化改进要费事得多
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。