首页 > 代码库 > 如何快速确定需求的技术实现方案

如何快速确定需求的技术实现方案

我们会在哪些地方耗费大量的时间

压缩需求确认时间的矛与盾

做项目的时候,一方面我们希望能够快速明确需求,开始投入开发,使产品能够尽快上线;另一方面,我们又深知需求会随着时间的推移越来越明确,就下意识的拖长这个流程。

需求细节的确认

需求应该确认到多细才合适?如何把握这个粒度?

方案优与劣的选择

这是最难的一个环节。目前仅靠个人经验和记忆力来做出判断,其实是很不保险的。因为有时候自己会不了解自己的局限性,给出的选择在另一方面就会出现问题。

外部接口的测试和沟通

需要注意两个地方:
第一是和其他部门沟通的方式:批量沟通+邮件交流+文明礼貌+严格自检
第二是自己这边,需要做好详尽的单元测试

程序框架、技术的选择

这个相对来说比较容易,只需要开发人员对于框架技术足够了解,知道其优劣,就能快速的做出选择。

搭建新项目的程序框架

直接拷贝已准备好的程序框架

新技术的学习

新项目,千万千万不要轻易尝试新技术。务必要在熟悉掌握之后,才将新技术加入正式项目中。

 

一些可以帮助明确需求和方案的方法

写分解文档

这个经过自己实践,是非常非常好的一个方法,在写分解文档的时候,你能拾遗补缺,发现细节上的问题,还能整理产品的流程,让自己思路更清晰。
如果是多人开发,那么建议每个人都写一个分解文档,然后汇总核对下,这样能发现很多被遗漏的东西。

讲出来

试想你是产品经理,将自己的理解,讲给产品经理听,或者讲给你的合作开发者听。讲述的过程,涉及语言文字的整理,同样会加深你对需求的理解。

设计数据库

这有助于理清楚数据结构和对象模型

名词定义

先定义好名词,能在交流的时候节省不少时间,这就像设计模式,一个词语就能包含很多信息。

 

一些常见问题

新事物

总之一句话:凡是涉及新事物,就必须谨慎考虑(新项目、新接口、新同事、新部门)
以新项目为例:
新项目的时间估算不能只看工作量,因为新项目还有很多其他的隐藏工作 
比如方案设计、程序结构的设计、数据库的设计、和其他部门打交道等等
无中生有比优化改进要费事得多