19
2021
10

一位SAP关键用户对系统项目管理的吐血总结

时间:2021-10-19 05:51栏目:麻豆福利 点击: 204 次
前言:

大家好!我是微天。本人曾在一家新零售企业任职SAP系统关键用户两年多。以下是本人踩过n多坑后,关于这份工作的沉淀总结。

一方面是为了自我总结少走弯路,一方面也分享给大家,让大家对这个工作岗位有所了解,若读者是做系统相关的项目,或是正在经历系统项目变革,都可以读读这篇文章,该文章适合关键用户、需求分析师、系统分析师、业务分析师、商业分析师(BA)、项目主管、项目经理、产品经理、业务经理以及所有和系统软件有接触的普通用户阅读。若有总结不到位的,欢迎各位在评论区补充更正。

这里先说明一下这个岗位的工作。据百度百科定义,关键用户是指在项目实施过程中,代表甲方提出业务需求,全程参与整个项目实施,负责对最终用户进行培训,及实施后系统维护的人员[1]。

1. 需求分析必须掌握的方法论

遵循马斯洛需求理论[2],5w2h分析法[3],用户故事[4]的3C模型和INVEST原则(不清楚的同学可以到文末点击链接进一步了解)。

2. 用户需求调研2.1 需求调研的最基本问题(5w2h)

当我们接到需求后,我们会采用访谈、会议等方式进行调研,可以从以下几个问题着手:

why:为什么提出这个需求,需求来源是什么?(用于判断需求靠不靠谱,必须确保需求的来源一定要是第一手的,因为获取需求的链路过程会曲解需求)what:需求的价值是什么?(需求评估时参考)who:谁来负责?谁去管理?(需求功能做出来后谁去操作,权限设置时参考)when:希望什么时候上线?(需求排期时作参考)where/which:希望在哪个系统模块操作?(功能设计时参考)how:用户希望怎么操作?(设计原型时参考,涉及字段及功能界面、业务逻辑)how many:功能做出来后有多少用户使用,数据量去到多少?(性能考虑及测试时作参考)2.2 引导用户需求,合理规避有时间和技术研制的需求

提出需求的用户由于个人经验的局限,且对系统的底层逻辑不是特别了解,所以,作为需求分析师,有必要去引导用户提出更加合理的需求。以下几个问题或许会有帮助:

当前业务是怎么走的,是否一定要通过系统解决?(过滤不必要的开发需求)这个需求会不会有其他应用场景?(用于设计增删改查功能、编写测试脚本时作参考, 也可作为功能复用性设计时的参考)其他部门会不会也有类似的使用需求?(需求提出人不一定能回答,但也要提醒其纳入考虑范围,或许其能提供相关线索,用于功能设计时考虑产品的复用性)涉及需求、流程变更的,会不会影响到其他用户?(其他部门用户是否同意,防止功能开发出来后无法投入使用,从而浪费人力物力)新功能上线前是否有历史单据及流程环节需要特殊处理?(若有,上线前评估时需考虑)是否能提供业务相关部门人员的名单?(用于组织跨部门会议、邮件确认及项目汇报,包括不同部门不同层级,下至基层业务,上至部门负责人)这些需求的优先级顺序是怎样的?(若排期太紧时,优先实现基础功能)新需求功能及流程是否足够便捷且易于理解?(若需求功能及流程过于复杂,可能不会被业务同事理解,高层管理难度也加大)能否确认需求,以减少需求变更?(若不能,让业务需要重新评估)3. 组织跨部门会议

跨部门会议需要提前确定会议目的,说明会议背景,明确会议内容及参会人员,约好会议室,协调各方时间,提前准备会议资料,提供待讨论方案,会议过程中要做好会议记录,把握好会议时间,还要学会控场,如讨论内容跑偏时要及时提醒,出现争执时要协调沟通,人员不配合时要请求支援,保证会议尽量出方案出结果,会议结束后要将会议纪要整理好后发与各方确认。完全可以说组织一场高效的跨部门会议,其实是一门大学问。而这之间最容易被忽略的,应该就是参会人选的确定:参会人员必须包括各个层级的相关人员,不能只找各部门的负责人,因为很少部门负责人会了解业务细节,也不能只找基层业务,因为他的关注点很可能只局限在他个人的岗位上。

跨部门会议中,需求分析师首先要演示用户故事,内容包括业务背景,业务问题,业务需求等信息。然后推动会议进行,协助出具系统解决方案。可以从以下问题着手:

系统原有功能是否可以满足?(须提前与IT同事确认,避免重复开发)该需求的重要程度如何?同行业遇到该问题的解决方案是什么?(提前各渠道了解行业信息,学习先进做法)IT解决方案是什么?项目成本是多少?开发难道如何?对系统性能有何影响?(需要多少开发人天?)是否可以按期交付?IT各模块对接人是谁?(即负责人是谁?)模块间接口由谁负责?(这点很重要,容易被遗漏)测试的交付日期是什么时候?项目/产品的预计上线日期是什么时候?若不能按时交付,排期是什么时候?4. 编写BRD/PRD文档

需求文档分为BRD和PRD两类。其中BRD文档是业务部门提供的,PRD文档是IT部门提供的,两者很像,但会有所区别。前者不一定会涉及到技术相关信息,但会阐明业务需求、业务背景、业务价值等,规范一点的会把业务逻辑描述清楚(前提是业务分析师比较专业)。后者不仅囊括BRD上的业务信息,还会包含技术信息,如需求相关字段从哪个底表或视图上取,涉及接口是哪个,接口涉及的字段及字段类型是哪些,等等。要编写PRD文档,除了要熟悉业务知识外,还必须有扎实的技术功底,如熟悉数据库,了解相关底层逻辑,另外,也要有较好的文字功底,并且会画流程图、编写SQL、绘制原型图(可通过墨刀或Axure)等。

不管是哪类需求文档,只要前期的用户需求调研做得好,跨部门会议也进行得成功,需求文档的编写并不难。关键是把需求各要素都阐述明确了,找到相关部门负责人签名确认就行了。

5. 编写测试脚本、测试并输出测试报告

测试主要分为3种,一种是单边测试,顾名思义,就是在一个系统模块里做测试,不跨系统,涉及接口的直接在接口输入模拟测试数据进行;一种是集成测试SIT(Software Integration testing),就是跨系统进行的测试,一般由一个测试团队进行,测试效果较好,接口如果有问题一般都会在集成测试中暴露,也就是说,涉及到接口的功能开发,一定要进行集成测试;还有一种是验收测试UAT(User Accept Testing),一般是协同业务在镜像测试环境(如果有的话)中进行的。

不管是哪种测试,一定要分场景进行测试,也就是说,在测试前,我们还要分场景编写测试脚本,这样测试的时候才不会遗漏场景。比如最基本的增加、修改、删除的操作场景。如果前期需求调研做好了,那么测试时编写测试脚本就不怕遗漏了。

还有就是要关注临界值的测试,这是针对系统逻辑中包含条件判断逻辑的功能测试。

测试完后,要输出测试报告,记录好测试人、测试日期、测试步骤、测试结果等信息及相关截图。

6. 制作操作手册、培训课件、视频并组织培训

操作手册:制作操作手册并不难,用Word就能轻松制作,记得注明编写人、版本及修改日期。另外更新操作手册的时候不要在原有文件上修改,一定要复制一份再进行修改。建议由于操作手册动辄上百页,所以建议一定要建立标题索引。并且转换成PDF文档,防止业务不小心修改了文档。

培训课件:关于培训课件也有要求,培训课件一般是PPT文档,主要讲解业务逻辑及系统逻辑。同理,制作培训课件的要点可参考上文的操作手册。

视频录制:需要强调的是,短视频的录制非常的必要,这能大大减轻运维期间的工作量。虽然操作手册已经很详细了,但是密密麻麻的文字会给人一种大海捞针的感觉,业务一般不愿意看。所以,把系统操作分解成短视频,命好文件名,分门别类,就能轻松应对后面的运维工作了。不过,录制精良的短视频并不容易,一方面是对录制环境要求较高(没人打扰、安静、有好的麦克风),还要会剪辑。

组织培训:难度系数跟组织跨部门会议有得一拼,不仅要培训基层业务(人数众多,难约齐,约齐了也可能心不在焉),涉及权限的,还要培训高层领导(业务繁忙难约)。总结下来,有以下几个点要注意:

明确培训人员名单;做好培训计划(非常重要,每次培训内容不宜过多,建议分多场进行);培训必须要签到(防止业务因未参加培训导致实际操作错误而引起的责任追究);培训必须要实操(系统软件的培训,一定要理论+实操培训才有效果);培训必须要考核(笔试考核+实操考核,不通过者要安排二次培训及补考,合格后才能上岗)。

之所以说难,一方面,是因为实际工作中常常因为项目上线时间的要求,导致不会有充足时间去培训。并且业务人员会以忙、时间无法协调为由,加上积怨已久的工作情绪,会抵触培训,对培训不重视,等等。二是因为系统开发出来的功能,有些bug在上线后才会被发现。如果培训没做好,等到上线后,业务乱成一团糟,就会投诉培训不到位,领导不明说,也会觉得你培训有问题。

为了避免上述情况,建议培训开始前就要拿着培训计划,和业务的高层领导打好招呼(阐明培训的重要性),让大佬们重视,以实际行动支持培训工作,倡导万事以培训为重(虽然实际是几乎不可能的)。这里也呼吁大佬们要重视一下(如果你们就是业务的大佬):毕竟培训人员一般都不是位高权重的人员,而是位卑言轻有苦难言的打工仔。不要总在事故发生时,试图将责任归咎于系统有问题或培训不到位,而是要擦亮你的眼睛,不要只听信一面之词。否则,你迟早会失去原本兢兢业业为你们服务的小伙伴,不是一个,有可能是一群,具体可参考文章——《程序员的酒后吐真言》[5] 第22条。

7. 参与上线前评估

这里要关注有两点:一是新旧功能切换前,是否有旧功能历史未走完流程的单据要特殊处理,如果有,要怎么处理;二是上线时间是否和业务、IT协调一致。以上两点解决后,就可申请系统传输了。

8. 运维及迭代优化

一是解决bug,二是提出优化系统的需求变更。这里要注意的是,一定要形成自己的运维文档,因为运维期间,同样的问题你会被重复问n遍。为了高效工作,最好的方法就是对自己解决过的问题总结成一篇运维文档,下次又有业务问题让他先参考文档解决。如何优化系统呢?除了运维期间发现的问题,我们还可以采用调查问卷收集反馈的形式去搜集意见。关于系统用户体验的调查问卷的设计,这里就不多说了,网上大家可以自行搜索并参考。

9. 项目跟进及汇报

这里主要是维护项目跟进表——包括项目名称、各时间截点、各对接人、进度等,尤其是注意项目时间期限及进度,并定期督促IT相关同事跟进,并按一定格式将项目进度汇报给各部门负责人。

10. 其他注意事项 10.1 辨别用户需求的真伪:

观察用户做什么,而不是他/她说什么。用户在提出需求的时候会受到很多因素的影响,在各种压力和利益的牵扯之下,一个人是会说谎的。这里引用一个案例[6]说明:索尼在推出Boomboxes音响前,召集了一批潜在的消费者,组成内测小组,来讨论这个新产品应该是什么颜色:黑色还是黄色?每个人都认为消费者应该更倾向于黄色。这次会议结束后,组织者对小组成员表示了感谢,并告诉他们,每个人在离开时都可以免费带走一个Boomboxes音响作为回报。他们可以在黑色和黄色里面任意选择一个,结果每个人拿走的都是黑色音响。这个案例告诉我们,用户需求调研的时候要借用一定的方法和技巧,多方式做调查,多问多跑,对用户需求进行不同方式的研究。

是否需要设计调查问卷收集不同用户意见?(如问卷星,有助于辨别用户需求的真伪)是否可以运用大数据分析用户操作习惯?(如数据埋点,AB Test等)10.2 留下文字及确认记录:

调研要做好调研记录,需求变更需做好变更记录,跨部门会议要做好会议纪要,完事后要发与相关同事文字确认(邮件或签字)并作存档,避免后期功能开发出来后才出现纠纷。根据沟通漏斗[7]现象,确认是一个非常关键的举措,否则,有可能会做很多无用功。

举个例子,你大费周折好不容易把需求分析出来,推动IT部门各岗位同事配合出具IT解决方案、完成系统逻辑的编写、系统开发、单边测试、集成测试、镜像测试(很大几率中间n次测试不通过需要重来)……一顿操作猛如虎,但给业务验收时,业务却说,这并不是我想要的功能,我想要的功能是……此时,你会做何感想?你的团队会做何感想?

但假如你当时做了记录且确认过,那就好办了:


当前网址:http://couchmentality.com/madoufuli/30397.html
相关内容
热点内容

Powered by 国产精品麻豆1卡2卡3卡8卡 @2018 RSS地图 HTML地图

h福利社 2013-2021 版权所有