下午对BUG导入工具进行了需求讨论。之前,我已经做了应该说非常详细的需求分析,画了USE CASE,写了系统的主要过程,以及备选过程,并且画了用户和系统的交互过程。
应该说,我认为一切都做得比较完美。但是,在下午进行需求讨论的时候,还是提出了一些新的需求,主要不是开发人员提的,而是咨询人员提出的。
可以说:他们提出的需求是有一定道理的,只是从我的角度来看,并不是一个需要在这个工具中实现的需求。并且,有些需求在这个工具中处理并不合适。他们从一个角度看问题,但是这个世界处理问题会有很多种方式,我不确认他们说的是不是用户想要的。如果是的话,那只能说这样的用户非常苛刻。
我们一定要有一个观点,我们所做的工作不是给用户带来麻烦,而应该是尽量的减少客户的工作量,提高客户的工作效率,给客户带来最好的价值。如果我们将精力集中在那么一点小细节,客户有99%的时间用不到,那么我们的软件是很失败的。因为为了这1%,我们让用户在99%的时间内都没有达到应该达到的高效。
以上只代表个人观点。当然,一个东西,从每个人的角度看都是不同的,需要从这些不同的观点中去寻找,去平衡。
几点教训:
1. 评审之前要把相关评审材料发给相关人员。要不然,临时来评审效果不好。可能就是当时来想想。
2. 评审人员要选好。尽量最相关的人来。还要确保他们看过需求。
3. 评审时间需要掌控,时间长了不好。从3:45 - 6:00,一个一个要解释清楚真的比较费时。
我追求效率。
明天得开始制定迭代开发计划了。
应该说,我认为一切都做得比较完美。但是,在下午进行需求讨论的时候,还是提出了一些新的需求,主要不是开发人员提的,而是咨询人员提出的。
可以说:他们提出的需求是有一定道理的,只是从我的角度来看,并不是一个需要在这个工具中实现的需求。并且,有些需求在这个工具中处理并不合适。他们从一个角度看问题,但是这个世界处理问题会有很多种方式,我不确认他们说的是不是用户想要的。如果是的话,那只能说这样的用户非常苛刻。
我们一定要有一个观点,我们所做的工作不是给用户带来麻烦,而应该是尽量的减少客户的工作量,提高客户的工作效率,给客户带来最好的价值。如果我们将精力集中在那么一点小细节,客户有99%的时间用不到,那么我们的软件是很失败的。因为为了这1%,我们让用户在99%的时间内都没有达到应该达到的高效。
以上只代表个人观点。当然,一个东西,从每个人的角度看都是不同的,需要从这些不同的观点中去寻找,去平衡。
几点教训:
1. 评审之前要把相关评审材料发给相关人员。要不然,临时来评审效果不好。可能就是当时来想想。
2. 评审人员要选好。尽量最相关的人来。还要确保他们看过需求。
3. 评审时间需要掌控,时间长了不好。从3:45 - 6:00,一个一个要解释清楚真的比较费时。
我追求效率。
明天得开始制定迭代开发计划了。