PMI-ACP®认证
适合敏捷开发项目 敏捷项目管理最佳实践
网络课程
PMI-PBA®认证
重视项目商业分析 商业价值与需求分析能力
NPDP®认证
产品管理国际认证 全球产品管理最佳实践
网络课
PMP®认证
单项目管理经典指南 年轻项目经理首选
北京 | 直播 | 录播
PgMP®认证
大型复杂项目全球标准 定位高级项目管理层
网络班
PfMP®认证
链接战略与项目 实现组织资源投资回报
全球直播
软考项目管理
信息系统项目管理师 系统集成项目管理工程师
计划 | 报名 | 经验
版面信息
本版版主
俱乐部导航
联盟·近期活动
社区热点
精彩专题
如何做好项目沟通计划
软件项目质量管理
国际工程索赔与反索赔
推荐信息
社区圈子
联系社区管理员
1. 开发人员实际上并没有真正的理解用户需求:只是做一个Demo去给用户看,但是用户实际上很难判断(因为Demo和实际产品还是有差别的),如果真正的理解了用户的需求,不仅可以理解用户口头描述的需求,而且可以对潜在的、用户可能提出的需求进行挖掘,这样就可以大幅度减少后期的需求调整;
2. 缺乏一个用户和开发人员统一个沟通工具,以文字描述的需求对于用户来说负担也是比较重的(综合理解起来难度大),以用户能够理解的方式、形象化、图形化的描述需求,往往比场景描述更重要(虽然没有场景描述(UseCase)那么严谨)
3. 持续交付也是一个可以考虑的做法:只有产品真正地投入使用了,用户才会真正地对需求进行确认。但是要注意在执行的过程中以”Do one thing, do it best" 为原则,不要什么功能都实现80%,这样的产品用户是不喜欢用的。