这周末被安排了评教任务，须要到二级学院进行数据採集。由于我们也是第一次接触这系统，所以第一天先是进行培训。第二天開始跟老师们进行沟通，可是过程并非非常顺心。
1.用户抱怨了？
评教系统的数据由教师录入。所以对于教师来说。他们的工作量非常大。而这两天再与他们沟通的时候，听到的最多的也就是他们的抱怨，例如以下：
问题一：教师排课、上课班、学生授课。这三者必须得按先是给老师排课。其次是给课安排上课班。最后是学生授课这一个顺序。
开发者关注的是功能的控制和实现，可是用户关注的是使用的功能。
所以对于教师来说。假设不给出提示。他们并不知道这个顺序。
![]()
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVvX3l1bg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >
问题二：对于用户来说，能少做一步是一步。
我们应该要遵守能让软件干的坚决不让用户干的原则。比如以下的学期能够自己主动显示，学分、学时也全然可由搜索的课程自己主动显示出来。
问题三：学生授课管理是往虚拟班塞学生。
这些学生可能来自一个班级。可能来自多个班级。
可是加入班级学生的时候，仅仅能一次选择一个班的学生。相同的虚拟班，假设须要再加入多个班级的学生话，还须要又一次返回最原始的状态进行选择。应该避免过多反复的工作！
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVvX3l1bg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" width="900" height="210" >
问题四：首先。课程名称并非按当前学院显示。显示的是整个学校的课程。并且设计下拉框，也不合理。
对于老师来说，假设课程非常多的话。更喜欢模糊查询。 其次，该页面是按学生显示，可是一个学院好几千学生。而对于教师来说。他很多其它的是关注我这班级有没有加入进去，而不是关注详细的某个学生。
了解用户真正所需的数据！
所以。当教学秘书在录入数据的时候，就会抱怨：“这个软件怎么那么难用。那么麻烦”。身为开发者，千万不要去内心里咒骂：“你行不行啊，就那么点操作，你都不会”。其实软件开发上的非常多思路都是与用户交流之后才出现的。能够说用户是软件开发者最好的老师。用户们抱怨，说明我们这个软件还有非常大的提升空间。
2.怎样站在用户的角度考虑？
开发人员和用户个人感觉并没有多大的界限分明。可是往往开发人员习惯性的会从系统功能和性能方面去考虑。而用户想要的是easy使用的功能。可是，开发人员和用户本质上都是人，所以开发人员也能真正的从用户的角度去思考问题。
比如，对相同的操作。怎样设计才不会感觉到繁琐。
3.什么样的软件才干得到用户的青睐？
在跟老师沟通的时候。她说了这么一句话：“如今相机都是傻瓜式相机，你们开发出来的软件还这么复杂，让人们怎么使用，一点都不实际”。身为开发人员，在设计软件的时候。应该把客户的水平当成猪的水平。这样设计出来的软件连猪都会使，客户用起来也舒心。
小插曲：【一鼓作气】
十年春。齐师伐我。公将战。
曹刿请见。
其乡人曰：“肉食者谋之，又何间焉？”刿曰：“肉食者鄙。未能远谋。
”乃入见。
问：“何以战？”公曰：“衣食所安，弗敢专也，必以分人。”对曰：“小惠未徧。民弗从也。
”公曰：“牺牲玉帛，弗敢加也。必以信。
”对曰：“小信未孚，神弗福也。”公曰：“小大之狱。虽不能察，必以情。”对曰：“忠之属也。
能够一战。战则请从。
”
公与之乘。
战于长勺。公将鼓之。刿曰：“未可。”齐人三鼓。
刿曰：“可矣。”齐师败绩。公将驰之。刿曰：“未可。”下视其辙，登轼而望之，曰：“可矣。”遂逐齐师。
既克，公问其故。对曰：“夫战，勇气也。一鼓作气。再而衰，三而竭。彼竭我盈，故克之，夫大国。难測也，惧有伏焉。
吾视其辙乱。望其旗靡。故逐之。”
曹刿是一名不经名传的军事家，却能给人们留下“一鼓作气”这一句名言。可是我们是怎么做的呢？在接到负责人一条评教改到下周的短信之后，就開始变得不紧不慢了。士气一下子就衰弱了。
就像老师说的，给我们多少时间我们就能拖拉到多少时间。
给我们一周的时间，我们肯定一周里都在捣鼓这件事。我们总是把重要不紧急的事情拖到既重要又紧急的事。
假设我们连曹刿这么小的军事家思想都学不到，怎么去学习那些大军事家。我们要做的应该是统筹全局。