惜文读书笔记 产品经理 【原创】产品经理笔记8:企业级SaaS服务软件需求管理流程

【原创】产品经理笔记8:企业级SaaS服务软件需求管理流程

一、引言 企业级的SaaS服务软件开发流程和2C的软件有个不一样的地方就是,软件的使用者包括客户和用户。而客户…

软件需求管理流程—惜文读书笔记

一、引言

企业级的SaaS服务软件开发流程和2C的软件有个不一样的地方就是,软件的使用者包括客户和用户。而客户和用户反馈的问题和需求对于产品版本升级有重要的指导作用,如何对更好的管理使用者的反馈是产品经理需要面对的问题。

 

二、问题分析

1.产品概述

公司的产品是一款面对学校的SaaS校务管理系统。系统的客户是学校,用户是学校教师和学生家长,系统的管理员一般为学校的信息化负责人。系统由管理后台、独立APP和微信小程序几部分组成,部分学校还采购了智能硬件。项目组使用jira作为项目与事务跟踪工具。用户可以通过拨打400电话、联系项目成员等方式反馈系统使用过程中存在的问题和需求。

2.存在的问题

项目实施后,产品进入维护阶段。在产品初期,用户反馈的问题没有统一的受理渠道,也没有建立完善的“反馈—处理—跟踪”机制,导致问题没有得到及时有效的解决,影响产品的稳定和项目质量,给项目和产品带来很多未知风险。具体情况如下:

流程

存在的问题

导致的后果

接收问题

目前有用户拨打400电话、客户主动联系公司人员、内部人员发现上报等几种问题反馈的渠道,没有统一接受问题的机制。

    • 出现的问题存在重复反馈的情况;
    • 不同岗位的人员沟通也会导致信息的失真。
    • 上报责任未明,不是所有的问题都有人上报

分析问题

对问题的轻重缓急没有定义。

暴露的问题是单体样本还是群体样本?

会造成多大破坏性未知?

有些问题自己人都不知道到底是需求还是bug

    • 未定义问题的紧急严重程度,容易出现未把最主要的问题优先处理
    • 对出现问题可能会造成的风险未制定应急预案
    • 客户的需求未给产品升级提供有价值的参考。

反馈问题

不同类型的问题没有明确唯一责任人,不知道该找谁,找到了也不知道是否找对了人。门禁机出现叫声到底是硬件还是项目的问题?

    • 责任未明,内部沟通反馈问题效率低下
    • 多人转达,反馈信息失真

处理问题

找到了对应的人,但问题没有得到及时的处理,大家都很忙。

    • 未给出处理时间导致问题处理效率低下 ;

处理结果

处理的结果是否符合预期?

处理之后是否问题得到根本的解决?

处理之后是否让相关人员知晓?

    • 问题处理之后没有专人对处理结果进行验证,对处理结果未知;
    • 处理问题的经验建立知识库。

三、解决方案

1.基本原则

  • 用户反馈的任何问题都需要有记录、分析、处理结果和回访反馈。
  • 新增需求需要明确开发意义,项目方面要考虑投入产出,产品方面需要考虑通用性和可推广性。
  • 任何改动都要人负责,项目经理对项目负责,产品经理对产品负责。

 

2.适用范围

智慧教育SaaS产品线

 

3.涉及部门岗位

岗位

职责

客服负责人

    1. 接听400电话,受理反馈问题,并在jira(项目与事务跟踪工具)新建工单
    2. 初步分析判断问题属性并分配给相关问题负责人
    3. 负责反馈问题处理后的电话回访

项目相关人员

包括市场、售前、公司高层。主要接受客户反馈的问题,并且通过钉钉、微信或邮件等文字性的方式反馈给项目经理。

项目经理

对门禁机使用故障进行判断处理;

产品经理

    1. 负责对反馈的需求进行价值判断
    2. 负责对价值需求进行需求分析并形成文档

测试

    1. 负责对软件bug进行判断分析

研发

    1. 负责对反馈问题的接收和工作安排

技术支持

    1. 门禁机故障问题排查和现场调试维修

 

4.需求管理流程

1)流程图

软件需求管理流程——惜文读书笔记
软件需求管理流程

 

2)主要流程说明

序号

流程名称

步骤说明

操作岗位

输入资料

输出资料

1

400电话反馈问题

用户通过拨打400电话反馈APP和校牌使用问题,由客服中心接听电话并在客服系统中记录问题情况

客服

客户电话

JIRA

2

客户直接反馈项目成员

客户方直接联系公司人员反馈问题;接收人员将问题以钉钉、微信或邮件的形式反馈给项目助理

项目相关人员

问题情况文字反馈

3

公司内部反馈

公司内部人员遇到项目出现的问题通过钉钉、微信或邮件的形式反馈给项目助理

公司内部人员

问题情况文字反馈

4

反馈问题录入JIRA系统

将反馈的问题根据要求的格式录入到JIRA系统

项目经理/客服

问题情况文字反馈

JIRA反馈问题链接

5

反馈问题判断

先了解问题具体情况,对问题进行初步排查,判断问题属于咨询使用类问题还是软硬件故障。

客服

JIRA判断记录

6 

问题分配

判断需要协调处理的问题类型,并分发给相应的负责人

客服

JIRA分配任务

 7

故障问题判断

判断问题是否是后台问题,属于硬件故障到现场进行故障维修

技术支持

JIRA故障判断记录

 8

需求分析

判断需求价值,对有价值需求进行需求分析及评审

产品经理

JIRA需求价值判断

 9

Bug问题判断

判断反馈问题是否属于bug,确认为bug分配给研发

测试

JIRA记录bug判断

 10

反馈问题解决及将记录

问题确认属性及解决方式之后,需要向问题提出人员反馈处理方式

客服

JIRA处理方式

 11

反馈问题回访

问题解决之后对反馈问题进行回访,用户反馈问题客服电话联系,客户和内部直接反馈的由被反馈者回复处理结果。

客服

问题接受者

 

3)关键控制点

  • 用户反馈问题需要在24小时内得到响应并进行回复;
  • 门禁机故障导致无法刷卡和APP开门的问题优先解决,4个小时内无法解决的先采用断电敞开方式解决;
  • 软硬件问题暂时无法解决的,优先确保门禁卡刷卡可用。

 

5.流程KPI

团队成员的项目维护阶段的工作表现纳入年度绩效考核得分。

指标名称

指标定义

计算方法

指标值

问题反馈及时性

各种渠道反馈的问题可以第一时间进入处理流程

超过4小时未及时反馈问题进行记录扣分

1

问题反馈有效性

各种渠道反馈的问题需要全面的反馈问题各种细节;

反馈问题不完整导致沟通成本提高的进行记录扣分

1

软件处理及时性

一般性软件故障需要在24小时(时间)内完成修复

未按照要求及时处理扣分扣分

2

硬件故障处理及时性

硬件设备故障需要在24小时达到现场,48小时内完成设备的维修

未按照要求及时进行维修的进行记录扣分

2

需求受理

需求都需要进过价值判断,5个工作日内反馈给客户需求处理方式。

未按照要求及时进行维修的进行记录扣分

1

 

总结

是否应该为项目管理和产品管理设计流程和绩效。一直都是管理层争论的焦点。我个人认为是否要对工作方式进行约束关键是需要就事论事。对于团队成员经验和能力都有待提高的团队,我个人比较倾向性于团队共同讨论和制定工作规范,这样一来可以加深彼此对工作流程的了解,也可以更好的促进团队成员之间的协作,最关键的是不同团队之间对于工作流程的沟通和约定,是很好的经验交流和相互学习的机会。

 

参考书籍

《给经理人的第一课》:一个重要提高产能的方法,便是找出哪些生产或管理活动具有较高的杠杆率。将工作流程简化可以提高杠杆率。

《硅谷之谜》:怎样才能提高生产效率呢?泰勒最看重的是优化流程和标准化管理。

《创新者的窘境》:同样的流程和价值观,在某种环境下构成某个机构的能力,但在另一种环境下则决定了这个机构的局限性。

《态度:四十封启明家书》:专业素养意味着遵守流程和行为规范。

本文来自惜文读书笔记(www.xiwen520.com),转载请注明出处
Jordanmax

作者: Jordanmax

惜文读书笔记是面向职场人员的读书笔记网站。为您提供互联网、经营管理、投资理财、教育书籍原文摘录,并且分享职场基本技能、项目管理和产品经理相关知识和经历。

发表评论

电子邮件地址不会被公开。

返回顶部