请轻轻的来看看此贴。也许你能提供点建议。解决思路

请轻轻的来看看此贴。也许你能提供点建议。

需开发一个系统在公司内部使用。使用部门：A,B,C,D,E
由于遇到开发进度问题难以推进，现提出这样的解决方案：

1、先把A,B部门功能实现先上线，其他部门的功能再慢慢开发。
2、把所有需求都开发完成后再上线。

a、如果用方法 1.有个好处，就是系统已经上线了，A,B部门的人员去使用，使用过程中遇到的问题。不会太偏离需求，马上提，马上改。各个击破的原则。
b、暂时没有想出方法2的好处。方法2的时间周期长。让人看不到头。
c、方法1的坏处就是，如果部门A,B人员去使用过后，使用的数据要能导出到以后使用就好，因为在开发过程中表字段又是可能会变化。导致数据导出有问题。

两种方法的利与弊，大家畅所欲言。各抒己见。请大家谈谈意见。

[解决办法]
开发前就应该做好各方面的评估
但既然已经这样了，只能先上一部分。导出来的数据要留下字段名，以便以后使用。以后如果有改动，已有的字段不要动，大不了新增一个字段。
[解决办法]
答案很明显，只能按方法一开发，不过如果没有很好的过程控制，这个项目不久就会陷入困境！
[解决办法]
同意楼上的

按照方法一来实施，还有一个好处，就是后面开发C、D部门，遇到的问题就会相应的减少一些。关于数据问题，我想这个不难解决吧，只要把相关的文档、注释写好，解决不难吧！
[解决办法]
需要具体问题具体分析吧。

把需求做好，写好可行性分析报告，就好了。然后怎么做，可以像楼主这样统畴安排一下。
[解决办法]
當然是方法一好啊···

[解决办法]
后过也许是无限期拖延吧？？
[解决办法]
一般的都是第一种方法，可以先预留字段，要先把A，B部门要实现什么功能；进行详细的分析，需要什么功能，生成导出什么报表；与C，D部门的需求差异；
[解决办法]
那些老板没做过网络，都以为网络好赚钱啊，都贪图大而全，弄了几个月，什么都没弄出来，或者只是一个花架子，看起来不错，实际错漏百出。

对互联网应用来说，小版本快速迭代已经成为了大家的共识。用最短的时间发布一个包含最少功能但仍然是完整的产品绝对是互联网创新的真理！
大规模的项目，还是分成一个个小功能来做吧，先把一两个功能做好运营着先，别的慢慢再说。
[解决办法]

探讨

不过如果没有很好的过程控制,何为过程控制？

[解决办法]
关键是方案敲定，框架起来；变更和是否合理是很郁闷的事情。

[解决办法]
这个要依赖你的项目大小而定，对于小型项目找几个牛人怎么搞也能给他搞上线了。

大型项目则需要系统的分析设计，用户需求是不稳定的，他想要的和你做出来的东西可能存在很大的差异，前期开发人员就不要上去瞎参合了，需求和设计将总体需求、总体设计摸清楚，如果各部门业务相互独立，则需要设计根据实际的业务场景设计出来各部门（各业务）之间的接口，需求可以根据用户的需求弄些UI或者用例来摸清楚用户具体的需求，并且要让用户有直观的认识，这样用户才能清除自己到底想要什么。


接口（业务接口）设计完毕以后则针对具体业务设计（这里说的是业务设计，不是程序设计），根据业务设计的内容，再设计程序框架，此时开发人员可以参与框架的开发，这个过程是迭代的。

对于整个产品来说我觉得第二种方法比较可行，第二种方法能够保证业务和概念的完整和一致（完整性和一致性是非常重要的），但是为了保证工期和项目的推进第一种方法也是必要的，所以我认为两条路都要走，设计需求应该走第二种方法，开发和实施应该走第一种方法。

项目的开发和产品的开发还是有很大的差异。

以上个人理解，仅供参考！

[解决办法]
1、先把A,B部门功能实现先上线，其他部门的功能再慢慢开发，优点：开发时间短，遇到问题调整起来比较快；缺点：整体上线时间长，模块间的逻辑关系不明确；

2、全部确定需求，再开发，优点：需求明确，各个部门间或模块间的逻辑关系比较明确，不会出现太大的调整(除非，需求和设计做的不细致)，项目的成功率较高；缺点：开发周期较长，成本较高；

建议：采用迭代式开发模式，先明确项目的开发范围，确定各个部门间的逻辑关系及模块间的逻辑关系，根据你项目的大小来划分迭代的需求范围，确定开发范围，迭代式开发模式是大中型项目的首选。
[解决办法]
我给点小建议：
在做之前，你必须对四个部门的业务流程、框架、表结构理清楚，保证数据库以后能供BC部门使用，在这前提下，上线两个部门的应用，再开发BC部门的

查看更多 下一篇