这几年和很多企业内部系统的开发团队有交流与合作。有些时候免不了互相吐苦水。开发工程师：开发人员最无奈的就是项目进入反馈修改阶段，用户总是希望改这个改那个。需求工程师：至于需求工程师呢，本来他们就已经
这几年和很多企业内部系统的开发团队有交流与合作。有些时候免不了互相吐苦水。
开发工程师：
开发人员最无奈的就是项目进入反馈修改阶段，用户总是希望改这个改那个。
需求工程师：
至于需求工程师呢，本来他们就已经做好了系统没人用的准备，他们只需要打发好最原始的需求者就好。把这个需求提出人员的意愿整理出来，交给开发部就好。
于是评审会议常常，只有开发和需求工程师参加，用户一般都在局外。于是评审会议变成开发了解需求的计划会议。最后开发出来的系统用户往往觉得太难使用而至于放弃使用。
有时候，会碰到想改变这种情况的项目经理，总会问我，类似的情况是不是有所改善。
这时候，我一般都会给出两个关键字，“用户体验”和“可用性测试”。
其实无论是对于以上描述的情况，我们一般的做法都是把问题尽早暴露出来，问题多不要紧，不要在一个问题上反复无用功就行。
所以在通过需求获取，PO产品经理应该做出一个高保真原型，这里不限于PO，可以从事需求获取的相关人员。通过高保真原型，我们进行可用性测试。没错，你没看错，在开发前我们使用原型进行可用性测试。
（所谓的可用性测试：可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。）
只要通过对5个可能用户进行测试，我们就能暴露80%的问题。我们就能在开发前把修改的工作开始，这样项目压力便不需要压在项目后期。而也不需要面对用户一堆操作上的问题。
即使问题在早期没有暴露，我们在产品初步产出的时候，再进行一次可用测试，那我们就能知道产品需要修改的方向。
这种测试办法非常适合内部用户，特别因为人数不需要多，操作起来很方便。外加有培训的辅助，内容系统一般很容易就能顺利推行。
至于极端情况，用户对于一个问题，反反复复修改，甚至最后改回原来的。我们通过此方法，一样可以曝光真正的问题，用户可能在意的并不是现在修改的这地方。
本站技术原创栏目文章均为中睿原创或编译，转载请注明：文章来自中睿，本站保留追究责任的权利。 