软件需求开发最佳实践——阅读笔记二

      想让用户代表能够更好地参与到完整性评价中来,就必须采用“业务导向”的组织结构,而是不让用户将一大堆技术动作翻译到自己的业务场景中去。这就需要我们用通俗的语言来和用户交流,来获取用户的需求。

      在做项目的时候我们首先要了解项目的背景:了解项目的建设背景、开发意图、目前的进展情况。了解项目的建设目标、包括建设周期、覆盖范围、达到技术、业务基了解项目的实施的阶段划分、阶段性目标。只有这样我们擦能够对于项目有一个整体的印象,一个整体的规划。

      然而,处在一个飞速发展、变革的时代,不可避免的带来对信息系统的频繁的变更要求。怎样快速响应业务变更,这需要项目组在业务需求表达上,用一种更为有效的表达方式,在业务需求组织上,用一种更为改进的方法。过程改进是提升醒目的形象,提高服务水平的内在要求。但传统业务过程缺少业务量化,身在庐山不知山,决策更多是依靠拍脑袋、头脑风暴、开会研究等方法,采用的是举例说明方式,用眼睛看,用身体体验评估效果,往往是问题发生后的被动响应,属于经验决策。怎么依靠统计数据进行科学决策,这需要项目组从业务需求开始,就对业务管理进行量化管理。

  “学会用数据说话是技术人员走向成熟的一个要点”。这让人兴奋,但是又无从下手。我们习惯对时间感性,对数字感性,“大概”“差不多”是我们的特色,对一个事物的识,我们习惯知道个大概就好。不过,为了能做出个优秀的项目,进行这方面的训练很有必要。这就需要我们对于项目的各个方面进行量化管理。 

  我们要设身处地的从用户的角度出发来理解项目,要做一系列的用户场景来帮助程序员理解用户的需求,开发系统的社会价值是什么?开发的系统给用户带来了哪些方面的便利?用户对于使用系统还有什么不方便的地方?这都需要我们来思考。用户体验是衡量系统是否成功的一个很重要的因素。对于我们初学者来说,更要注重用户体验。

           

 

                                                                                                                                   

原文地址:https://www.cnblogs.com/liguoshuai/p/6063336.html