今天终于静下心来,好好考虑了这个项目的现状.
存在的问题还是很多的,而且似乎短期内看不到减少的迹象.
1. 开发团队的规模和稳定.决策层采取的低调路线决定了这个项目的规模难以继续扩大,今后的一段时间内仍然必须忍受缺少人手的痛苦.另一个是人员的变动, 因为在校生毕业的关系,可能不得不停下来一两个月.现在看来,这几乎是一个月后即将发生的灾难. 唯一避免的方案是临时招人. 这无论如何对项目都是一个拖延了.
2. 项目的架构和开发人员的水平. 现在的项目同时处理微观数据和宏观数据,所以将可用性和查询效率搅在了一起.一些关键的数据既要满足底层用户的操作,又要供管理者分析使用, 在效率上难以兼顾. 这其实是将两类系统纠缠在了一起. 以后肯定是要分开的. 技术上,不断有新问题碰到. 但是短期内无法增加人手,所以只好先自己摸索了.
3. 基础数据的获取. 因为需要用到其他几个系统的数据,而这些数据是从第三方得到的.现在已经发现得到的数据有问题,所以从长期看来, 考虑直接从其他系统中获得原始数据,从而生成项目所需的基础数据.
另一个方面,这个项目得以生存的最大原因在于整合用户的几个系统的数据,最终为管理者提供统筹全局的数据分析功能, 为普通用户提供一个简易但实用的协作工作平台. 目前两者都没有满足 :(
-----------------------------------
有关需求的变更:
今天的一个电话再次让我认识到需求的善变性. 客户推翻了经过我们再三确认的需求, 这使得现有的架构几乎都要重新设计. 我们无法拒绝客户, 但也无法立即满足,所以只好是推到以后再进行完善.
这次的变更让我怀疑需求确认的重要性.虽然我们在一开始已经再三的询问客户,也在不存在歧异的情况下得到了明确的答复,但当软件在不断演进,客户对系统的理解逐步加深, 他们最终还是出尔反尔,推翻了自己开始想要的东西. 所以
对于需求,只有获取,没有确认. 或者说,可以运行的软件才是最有效的确认需求的工具,甚至,是唯一的工具.
现在终于体会到精益开发中提出的
推迟变更重要需求的说法(当然,这需要一系列配套的工具和方法的支持). 换句说法,其实就是要
和客户一起交流演进的软件的需求.
本文地址：http://com.8s8s.com/it/it34135.htm