技术先行or业务先行

     昨天和一个同事发生争执,两个人都坚持自己的观点,争执不下,最后情绪很激动,说了些话,场面很尴尬。
        
     回头想想,虽然自己的观点没有错,但是也应该心平气和的讨论。在这里向你道歉,为我昨天的态度,如果你能看到的话。

     起因是就一个项目如何开展产生了分歧,这个项目是个小项目,主要是我公司的一个现有产品为第三方提供一个查询和订货的接口,业务和采用的技术都比较简单,目前的问题出在这个项目的参与人员不熟悉现有产品的业务,需要产品开发团队进行支持,但是产品开发人员需要下周才有时间,而且能提供支持的时间很短,可能只有几天时间,这就出现了一个问题,我们这边项目组需要做什么事情来准备下周的业务开发工作。

      同事的观点是现在业务不明朗,现在讨论业务部分没有意义,还不如把技术框架搭起来,做一个简单技术Demo给业务开发人员看,让他们来把握业务需求,然后模仿技术Demo来开发业务。

      我的思路正好相反,对于这种小项目,技术方面是非常简单的,可能的风险出在业务需求的不明朗和将来可能的变化上,我希望项目组先着重把业务需求理顺,即使对产品的部分不了解,也可以将产品接口的部分空出来,由业务开发人员来填充。如果我们现在不拿出详细的需求和设计方案来,下周的时间可能都花费在讨论业务需求上了。

      到底应该技术先行还是业务先行?

      在软件开发过程中,应该技术先行还是业务先行不能一概而论,我的观点是:风险大的部分先行

      对于技术复杂性的项目,例如:嵌入式系统、底层开发、框架开发等项目,技术先行是对的,因为要花大量的确定具体的技术方案,这类项目中,如果技术方案出了问题,对项目的影响几乎是致命的。


       对于业务复杂性的项目,例如:MIS系统、网站这类项目,采用的必然是成熟的技术,除非都是一帮菜鸟开发,技术上的风险应该是很低的,对于这类项目,应该走的路线是,用业务驱动设计,也就是业务先行。

posted @ 2009-04-15 10:07  一味  阅读(3644)  评论(31编辑  收藏  举报