各角色人员客户导向行为标准.docx
《各角色人员客户导向行为标准.docx》由会员分享，可在线阅读，更多相关《各角色人员客户导向行为标准.docx（48页珍藏版）》请在冰豆网上搜索。
各角色人员客户导向行为标准
各角色人员客户导向行为标准
类型
阶段及工作
具体要求
输出/检查
重要
需求阶段
与开发人员讨论原始需求解决用户什么实际问题、带来什么价值，掌握、思考需求、设计文档，从是否真的提升客户价值的角度出发，能发现模块需求存在的问题，如设计需求不合理、不满足客户要求、易用性、异常未考虑、可靠性无保证、需求不细化，需求点遗漏。
并收集和分析出用户实际使用的场景和操作习惯。
TDbug、模块用户场景
设计阶段
了解客户使用的场景和操作习惯、竞争对手资料、同行测试方案，按照客户的使用方式来设计测试，不能局限于设计和需求文档，产出模块测试指导书。
测试指导书、评审跟踪表
编码
能够考虑如何组织用例框架可以让执行人员更好的了解用例设计思路。
TD模块案例备注
联调/集成
测试用例编写时考虑后续的维护性和自动化测试转换、更好地让执行人员清晰理解并高效执行，能够为其他产品线编写类似用例提供素材。
每轮质量分析报告中测试用例质量分析
系统测试
随着对系统的深入了解，能够不断思考负责的模块用例设计是否有需要改进的地方，并且补充优化，提高用例的覆盖率。
案例优化记录表
参考
需求阶段
根据用户需求、系统需求、详细设计需求、需求矩阵、同行测试方案、TD中网上问题、预研验收方案和报告产出需求跟踪表，与开发一起进行需求细化。
TD中bug
为了保证模块测试效率和质量，需用测试工具进行测试时，与开发讨论出测试工具需求，并明确测试工具完成时间点。
需求跟踪表
覆盖了需求矩阵、用户场景的全部内容，测试需求评审一次性通过，无需求遗漏，且对原始功能理解透彻，测试需求分析透彻（通过后续的测试指导书和演讲可验证）。
评审跟踪表
设计阶段
模块测试需求分析全面，覆盖了需求矩阵的全部内容，测试需求评审一次性通过，无需求遗漏。
测试指导书、评审跟踪表
能发现模块需求存在的问题，如设计需求不合理、不满足客户要求、易用性、异常未考虑、可靠性无保证、需求不细化，需求点遗漏。
与开发一起讨论页面易用性、模块关联性、异常处理、可靠性。
TD中bug
开发人员参与演讲评审，85%以上都能够正确回答，测试指导书基本原理都能够说清楚，能够有效指导测试。
评审跟踪表
编码
参考案例checklist、需求跟踪表、测试指导书、网上问题、同行测试方案编写详细测试需求。
TD详细测试需求
个别重要模块或测试难度高的模块，写案例之前要组内评审下测试方法，以免出现案例都写完了后续发现步骤使用的测试方法很不好，有更好的方法。
会议记录
能发现模块需求存在的问题，如设计需求不合理、不满足客户要求、异常未考虑、可靠性无保证、需求不细化，需求点遗漏。
TD中bug
参与代码走读，根据测试用例情况要求开发进行相应的处理，并分析代码未覆盖的逻辑补充测试用例。
会议记录和Tdbug
测试需求覆盖了全部的需求矩阵的需求，评审时无重大问题，且经过评审后的测试需求产出的用例评属于需求遗漏的低于6%。
评审跟踪表
联调/集成
结合代码、AB角检视、开发日结优化测试需求和测试用例，保证测试用例准确性。
案例优化记录表、AB角检视、开发日结记录表
用例条理和结构符合部门规定，且评审问题数低于15%，无重大问题。
评审跟踪表
经过交叉评审后的用例后续外部评审发现问题数低于10%，后续按照评审后的案例未覆盖率低于14%。
评审跟踪表
系统测试
根据各模块的bug分布、bug的级别等信息主动提出模块的测试策略。
每轮质量分析报告
根据代码覆盖情况分析出未覆盖的逻辑并补充测试用例进行测试，代码覆盖率至少覆盖80%以上。
代码覆盖测试结果及分析报告
根据漏测、案例覆盖、网上问题分析各阶段工作，好与不好的地方进行总结和提出改进措施，并在下个版本落实。
最佳实践库
阶段及工作
要求
输出/检查
用例执行
测试中要用到较复杂的测试资源，如脚本、配置、数据包、测试环境、测试工具等，主动做好备份和说明，以便后续人员可以直接复用，提高效率。
testlab、确认记录
执行中发现的用例错误、遗漏等问题，主动提出和用例设计人员、项目经理进行确认，并能提出用例优化的建议。
用例优化记录表
测试中主动发现是否有更高效的测试方法，并和用例编写人员、项目经理及时讨论，确认更好的方法后调整用例步骤，提高测试效率。
用例优化记录表
主动总结执行用例的注意事项，并提供或讲解给下一轮执行的人员，以便交叉测试时，测试人员能达到预定的测试目的，提高测试质量。
TD用例的备注、每轮质量分析报告
主动和开发、项目经理讨论模块从用户场景角度的发散测试点，执行发散测试，并在过程中记录测试点，以便后续人员可以参考补充用例或避免重复测试。
发散测试记录表
bug跟踪
提bug时按规范写好bug描述，精准描述发现问题的步骤，必要时上传相关的附件信息，以便开发人员能快速了解并定位问题。
TDbug
每天关注自己的bug情况，配合开发做好bug重现、确认、回归等工作，直到bug到达最终的状态。
TDbug
所有发现的问题都需要上TD跟踪，不存在发现问题不提bug的情况。
TDbug
能针对模块和版本提出易用性的建议，并跟踪这些问题得到确认或解决。
每轮质量分析报告
质量分析
能够从bug、测试用例、测试执行、程序实现原理、客户实际环境等方面进行科学有效的分析，并能够有效的指导下一步测试。
主动和交叉测试这个模块的人员进行交流，协助并指导做好交叉测试，并跟踪交叉测试的效果。
每轮质量分析报告
每周定期关注自己的漏测试问题，及时做好漏测试分析，并针对漏测试问题由点及面，输出薄弱点测试建议，协助落实补充测试案例。
漏测试分析报告
测试结束后能针对模块做质量分析，从用例角度、执行角度、bug数据统计来多方面分析模块的质量，得出后续人员可参考的测试建议。
版本测试总结
测试过程中及时记录、标记出版本的注意事项和遗留问题，并提交给项目经理添加到发布文档中。
TDbug/注意事项记录表
意识积累
工作中积极关注网上问题、服务日报、案例checklist更新公告等产品在客户使用的信息，学习用户使用的场景，贴近真实客户的现场，并在当前版本或模块中验证，并优化案例。
Tdbug、案例优化记录表
阶段及工作
要求
刚接到技术支持的注意事项
1、询问并记录：
客户重要程度、项目重要程度、问题现象、问题频率及发生时间点、问题场景（如：
正在视频会议，或者下载文件）、产品设备型号、软件版本、网络环境（是单臂部署还是、网关部署，出口线路情况是拨号还是固定IP，前置是否有防火墙等）、升级历史、最近操作。
2、必须要客服备份客户当前配置、所有日志、设备系统状态，且要录入TD进行跟踪。
3、尽可能的进行沟通，使得客服人员能自己定位和解决问题，为公司节约成本。
解决不了的话，至少可以为研发提供准确详细的信息。
不能中断客户业务
客服不方便配合时，首先要自行备份配置，调试时不可中断客户业务，如果一定要中断业务需要征得客户同意。
非总部客服务咨询如何处理
市场咨询时，首先要找是产品经理咨询，其次咨询应找规划经理或主管，要求其走咨询流程，勿直接答复。
若是咨询参数方面问题，请转产品接口人。
网上问题处理优先级
按客户等级进行，普通客户&低端设备，解决问题的优先级可比照VIP降低一点；（需要包括在测试并且未购买的用户）客户那里必现的4个工作日内解决，不必现的7个工作日解决（不含周六；“期望解决”等级的问题一律1个月内解决），解决不了的要给下一步方案。
一个客户同时有多个问题
优先解决最关注的和易解决的。
疑似配置、环境问题
现象有可能和配置、环境有关时，首先要确认排除这些因素；判断为配置、环境问题时，但市场、客服不认可，或自己也不太自信，此时要立即汇报主管。
疑似硬件问题
执行硬件巡检脚本，判断内存、硬盘、CPU是否有问题，并和HQA部门沟通判断处理，并向研发管理委员会说明，以便协调。
硬件检测相关，要让硬件部门的人来操作。
重要客户、重要项目、严重问题（主管以上级）的知会
必须清楚哪些客户是核心VIP、超核心VIP，若属于核心VIP、超核心VIP客户、涉及金额30万以上的项目，要立即知会主管，包括问题详情、给市场和客户的承诺；此处要求技术支持人员不能直接给承诺，如果要给承诺必须经过上级主管同意；处理完客户提出的问题后须执行巡检脚本，确保运行正常，无其他问题。
重要客户、重要项目、严重问题，但自己没查出头绪
0.5天内没查出头绪，向主管、研发管理委员会主任报告；随时评估给市场客服的承诺。
认为是其它产品线的问题
没确切的证据证明不是自己产品问题之前，不允许把问题转给其它部门；即便判断是其它产品的问题（包括其他同事处理的问题），也只能研发内部沟通，不能要求客服去找另外产品的人，并由客户所使用产品的对应技术支持人员主导问题解决，引起不及时则算到所使用产品的产品线；如果问题可能由多个部门产品模块引发，可以要求相关部门协查。
被要求协查的部门，禁止找任何理由不配合，在没有明确问题之前，被要求协查的部门不能以“不是我们产品问题”加以搪塞，应该和主导部门共同商议对策，配合查明问题。
问题必须由主导部门牵头排查。
如果被要求协查部门资源协调不过来，需经过两部门主管协商给出解决方案；问题转产品线、测试的须当天书面通知；
对自己的定位不自信或不太肯定
同上，要立即联系主管。
牵涉到市场运作的，当天向研发管理委员会主任汇报。
客户处出现2次以上但无思路，且疑似硬件
疑似硬件的问题，出现了2次以上，但整个部门都无查问题思路，建议换硬件解决。
若不影响客户业务，征得客户同意可以不替换硬件，继续定位问题。
谨慎做升级操作
不能确定升级能够解决问题，严禁执行升级尝试。
调试时机
尽可能和客户争取现场调试的机会，但要放在客户业务空闲时间。
调试时和客服的配合
不能让客服无限期等待，这样会浪费公司资源。
调试前双方沟通好什么情况下需要对方在或电话联系。
如何TD备注
按模板备注，并能从当前备注看出问题进展、客户的当前状况。
处理人、跟踪人、状态变化，设备上下架等不体现在备注中，处理时间超期时的解释将不予理会；测试重现相关备注，由测试人员发给研发技术支持人员统一进行备注。
修改TD状态
跟踪人、问题进展发生变化，则要立即（当天）修改状态，转客服跟踪要邮件申请；fix后指定审核人2天内不审核要邮件提醒相应的责任人。
勿要求重现一下看看
在客户处调试，应先分析问题、知悉环境，并有解决思路或可以定位出问题的方法；若没有把握重现后能定位问题或收集到定位信息，不能要求重现看看；如果客服提供的信息或者现场信息不足以定位问题，可以要求在客户业务空闲的时候进行重现，但禁止反复要求重现问题，但是没有任何问题定位进展。
换文件的注意事项
1.可以不重启的替换：
新文件先放置在临时目录下，加载起来跑一段时间没有问题，再更新到真实目录下，如果是驱动文件要确保加载过程不会有问题。
2.必须重启的替换:
一定要做好保护动作，防止因为错误的文件（无论有没有在这边测试过），导致客户的设备启动不了了。
确保起来之后，再删除这些保护动作。
3.做文件替换前要想好：
最坏的结果是什么，出现的话怎么补救。
替换文件历史记录保存
1.在/app/appversion里面请添加对应信息。
2.在/app/home目录下新建dev-support目录，下面按每个编号建一目录，其下再新建bak、new目录以及changelog.txt文件。
bak目录保存原始文件，new目录保存替换的文件，changelog.txt里面如下图写明替换、删除、增加了哪些文件以及md5信息（小硬件问题在部门内自行备份）。
3.解决问题后，所换的文件要附在TD上（如有TD记录）。
4.TD上应该备注修改代码的归档位置。
误操作怎么办。
操作前，一定要想好后路，要考虑到各种可能引发的事故，并准备好恢复方案，以便出问题时快速恢复。
疑难问题的定位指引
疑难问题可向以前的技术支持人员请教，并和市场人员沟通多争取时间。
解决不了的问题切忌闷头自己处理。
理论上可行的操作或方案
理论上可行不能保证实际没问题。
需要测试同事测试和上级主管确认后，才能给客户操作；如果需要很多时间，需要和客服的同事做好沟通，向客户争取测试时间。
处理出现概率很低的问题
客户不给查，或条件不允许，可以先规避，后续版本再安排解决。
能查的尽可能去查。
大面积出现的问题
立即汇报主管处理。
处理时间不足时，提前和市场人员沟通。
设备发回来，HQA检测说不是硬件问题
首先沟通他们做了哪些验证，确保按流程检测全面后再申请设备过来；设备申请后定位要快，不能拿来放着。
定位完后24小时内通知IT返还设备。
影响客户业务问题的处理
解决方案要经过主管、开发经理、技术委员长评审（参考“产品故障快速响应机制”）后才能给客户放上去。
如果需要快速解决的，在给客户解决后，事后立即组织评审。
严重问题（主管级/副总级）的处理
每次解决的方案都要邮件评审，换文件等操作都要主管知晓并审核。
注：
影响业务的问题一定属于严重问题。
严重问题在处理完成后
和主管沟通，确定是否普遍性的，并评估是否给相关客户换文件或打补丁。
走“产品故障快速响应机制”中严重问题的规定。
阶段及工作
要求
输出/检查
拜访客户前
规划经理要在年初完成全年规划Roadmap，并根据Roadmap所规划的版本，生成需求概念测试记录，并据此生成方便与客户交流的PPT。
Roadmap文档、概念测试表、PPT
需求概念测试和PPT要注明关注此需求的用户类型或行业，方便归类。
概念测试表、PPT
要和市场技术人员了解项目状况，统一口径。
市场随行人员监督
Roadmap和PPT都需要每个季度重新检视一次，并进行更新和修改。
Roadmap、PPT
拜访客户时
了解客户需求的同时，要思考和确认用户真正的原始需求，不能一味跟着客户所提出的解决方案来思考技术上是否能够实现。
不了解原始需求的需求不能算合格的需求收集。
客户拜访报告（原始需求列）
不能简单直接拒绝客户的需求，可以回来讨论后再决定，或许有其他更好的解决方案。
不被市场投诉
根据不同的客户需求或客户类型，挑选客户有可能感兴趣的新功能，完成需求概念测试。
并记录客户的建议，回来后更新到概念测试表中。
概念测试表
拜访客户的一般交流过程：
1.收集客户的问题和需求，了解我们的设备在客户业务中的作用，了解客户的网络拓扑和业务特点。
2.在解答完客户的问题后，如果客户还有时间，则可以针对客户类型和需求关注点，向客户介绍新规划的功能点PPT，并同时完成概念测试。
概念测试表、市场随行人员监督
拜访客户礼仪：
1.按公司要求，研发人员拜访客户需要穿着西服，领带，衬衫，西裤，皮鞋，以表示对客户的尊重。
2.初次见面的客户，需要主动与用户握手并递上名片。
市场随行人员监督
在告别用户前，都要重复确认一遍用户所提到的需求点，以及我们后续打算如何处理的计划，以及需要确认和沟通的承诺点，以便客户更为确定他的问题不会被遗忘。
市场随行人员监督
拜访客户后
除了完成概念测试报告、生成客户拜访报告外，还需要记录该用户的业务、拓扑、使用场景等，这部分将在客户拜访报告的模板中增加一列：
“客户业务特点”，拜访后需要针对客户的业务特点来思考，客户是否存在一些安全或其他方面的问题，是否有其他的解决方案可以更好地解决用户问题，填入“客户业务特点”列中。
客户拜访报告（客户业务特点列）
如果现场有承诺客户时间点或有其他需要确认的信息，需要在24小时内邮件通知相关人员落实工作，并将拜访纪要发给主管和其他相关人员。
邮件
如果有需要市场人员代为转发或提供资料等工作，也需要在24小时内邮件通知相关人员落实工作，并抄送双方主管。
邮件
每个月的客户拜访报告，竞争对手分析报告，前沿技术分析报告都要最终汇总为每月的产品规划检视报告，形成需求池，同时将需要进行客户接受度概念测试的需求项抽取出来，以便进行下个月概念测试。
规划检视表
阶段及工作
要求
输出/检查
产品规划
产品规划需要根据去年的客户需求收集情况，形成产品竞争力分析报告（客户最关注的Topn功能点），并以此为依据，形成全年规划的Roadmap。
新版本的规划表需要以Roadmap和概念测试表为依据进行设计，需求的优先级别要以客户的需求情况和概念测试结果为依据。
Roadmap、竞争力分析报告（Topn）、概念测试表
产品竞争力分析报告（Topn）需要每个月重新检视一次，并进行必要的更新和修改。
竞争力分析报告（Topn）
已经规划的功能最终的实现是否符合规划预期？
这些功能在用户那里使用情况怎么样？
能不能满足用户要求，好不好用，用的人多不多，有没有形成竞争优势，等等这些需要在客户处得到验证，如果有需要改进的，需要落实到后期的产品规划中。
产品规划表
产品规划项除了按以前的模板注明具体需求来源的客户外，还要注明适用的行业或用户类型。
产品规划表
产品规划项的优先级和取舍，都需要根据用户的实际需求情况和迫切程度思考，这方面可以通过对在产品规划表的“暂不列入此版本的需求项”表格中所描述的具体原因进行检查。
产品规划表（暂不列入此版本的需求项列）
用户需求规格说明书
产品规划经理在产出用户需求规格说明书时，最重要的一点是用户的原始需求，以及用户场景的描述，这两部分也将作为用户需求文档的主要考察项。
用户需求文档
需求设计和规划，不能单纯从研发工作量或实现难度的角度出发，或从市场，客服反馈的角度出发，而是应该深度思考和挖掘用户的原始需求，并从如何更好地满足用户原始需求的角度出发进行规划设计。
用户需求文档
竞争对手分析报告
竞争对手分析报告中，要重视对手功能的用户原始需求，如果不是非常确定的话，需要安排收集工作。
竞争对手分析报告
竞争对手分析报告中，分析时要关注解决方案，及方案给客户带来的价值。
竞争对手分析报告
竞争对手分析工作，也要站在用户的角度上来评价对手的功能和实现，而不是完全从竞争对手的白皮书的描述上照搬，更不是单纯从技术实现的角度出发思考问题。
这方面要求在用户原始需求上能够予以正确描述。
竞争对手分析报告
系统需求规格说明书、预研目标书
不能改变文档结构，章节内容要完整。
系统需求文档、预研目标书
对于系统需求和预研目标，产品规划经理具有需求把关的责任。
预研的目标需求必须是来源于具体的拜访收集需求，竞争对手分析，前沿技术分析或概念测试报告（在预研目标书中增加需求来源要求）。
系统需求文档、预研目标书
预研目标书中的验收标准，必须来源于用户需求中的用户场景，并进行进一步扩展。
预研目标书
产品规划经理需要把关用户需求和系统需求是否能够正确衔接，确保系统需求覆盖用户需求所述，而且不会偏离规划的方向。
系统需求文档
把关系统需求设计中的客户易用性问题，保证系统需求设计在能够满足客户需求、解决用户问题的基础上，以最方便用户使用的角度提高系统的易用性，避免出现可能使用户感到疑惑的设计。
系统需求文档
阶段及工作
要求
输出/检查
新版本的体验工作
产品线内的任何新版本在转系统测试和Beta测试时（流程上规定是B1阶段产品线主管、产品测试经理、客户导向部主管参加体验；B2阶段RDM进行客户导向检查），产品规划经理都必须参与体验，并产出用户体验报告，并把关产品的易用性体验，同时对该版本的易用性设计负责。
产品体验报告
对于其他产品线的新版本，产品规划经理需要参与Beta测试时的全员体验，并站在初次使用系统的新用户的角度，提出产品易用性建议。
产品体验报告
其他
每月收集客户、市场、技术支持、定制的反馈，体现到产品检视报告中，及时更新和变动可行的大众需求，按变更流程合入新版本。
TD需求库
全员创新要有客户需求支撑，审核时也以此为准。
具体来源有BBS的建议，代理商论坛，客服和市场反馈，定制需求，网上问题等。
规划经理需要进一步丰富TD需求库的内容，BBS的建议由SQA录入，而其他需求则由规划经理录入。
在TD需求库中增加“功能所属模块”的字段，方便归类和搜索。
TD需求库
阶段
具体工作
要求
用户需求阶段
编写文档前
用户需求编写要先了解用户的原始需求，是为了解决什么问题的。
用户需求编写要先了解用户的使用场景，包括用户是如何在其业务工作环境中应用我们的系统。
用户需求编写要先了解用户期望的性能指标，以便作为预研工作的指导。
用户需求需要提前与预研人员、架构师讨论需求实现的可行性。
用户需求要先参考竞争对手的实现程度，以及市场对此版本的期望目标，来决定哪些需求点是要做的，哪些暂且不做。
用户需求考虑此需求所针对的用户范围大小，以及市场对此版本的期望目标，来决定哪些需求点是要做的，哪些暂且不做。
编写文档时
用户需求要尽量采用市场，用户等非技术人员能够理解的表达方式，如图，表等工具进行描述，以便减少评审时评审人员的理解难度。
用户需求要避免使用“可以”，“应该”，“尽量”等不确定的表达方式。
要注意错别字，有些人写文档错别字特别多。
编写时请针对每个需求点进行分析，避免遗漏用户需求。
用户需求中的用户场景案例需要特别注意可测试性。
编写文档后
不能改变文档结构，章节内容要完整。
产品规划人员需要对用户需求检视，并填写“规划表覆盖和真实用户需求吻合度”表。
用户编写完成后，需要检查每个需求点是否有遗漏。
用户需求文档提交评审前，需要产品线内开会讨论确认，达成项目组主要成员对版本目标，原始需求等的理解一致。
阶段
具体工作
要求
系统需求阶段
编写文档前
系统需求编写要先理解原始需求为什么要这么做，由系统需求文档对应作者讲诉需求理解给规划人员进行检查。
缺陷预防处进行跟进，找出系统需求写得好的文档和不好的文档，在编写系统需求前期做好培训工作。
系统需求阶段如果有界面需求的话，需要由UED设计师参与进行界面设计，并结合前面提到的提前体验，防止后期体验之后返工。
系统需求阶段，必须提炼出客户的原始需求，明白客户“想”解决什么问题，而不是客户“说”要解决什么问题。
设计前，要先了解目前产品的产品特性，配置方法，并了解同类更好产品的设计思路等，分析目前存在的问题，给出改进方法。
设计前就需要在产品线内部考虑好,并给出方案，征求客服，客户导向部门，有可能的话获取市场同事及实际客户的意见，形成最终的设计方案。
设计后，需要从用户的使用出发，模拟用户使用场景，确保设计的产品，操作逻辑清晰，容易理解，操作方便，界面美观，统一，大方，具备公司及行业特色。
编写文档时
测试工具是否在这个版本中需要？
如需要则在需求文档中体现出来。
升级需注意兼容以前版本，如参数有发生变化，需标注出来。
存在技术困难的新功能，不能仅从技术角度出发来编写需求，有疑问的要和规划经理讨论取得平衡。
需要对测试需求进行描述，我们测试都是按照我们内部的环境和设备进行测试，较少使用客户的环境和设备进行测试，导致了内部测试没问题，到客户那里就很多问题。
预研时明确不支持，或者支持不好的地方，需要在用户需求/系统需求前明确，由版本风险跟踪表做为跟进手段，防止实现得不好导致不符合客户要求。
系统需求文档应该尽可能的详细：
定义清楚每个页面限制，每个功能的详细规格。
系统需求阶段不能有客户价值点的遗漏，而不仅仅是产品功能的遗漏。
性能参数的确定，需要根据预研的结果，而不能定义一个根本不能达到的值。
如果用户需求无法满足的时候，需要考虑其他实现方式。
系统需求编写过程中，在
升级会员 