从运营转成小产品汪，得感谢老大的支持以及给我的规划~第一个小task练手：）优化配课系统这个工具类的后台，解决负责客服的同事烦恼！

它是个什么东东，干嘛的？

配课系统，简单来说，就是将正确的课配给对应的学生。后台操作后，学生端能看到自己要上的课~完成一次配课，需同时拿到用户YY号/uid以及班级id，再输入系统。

配课流程

第一次做产品优化蛮有些紧张，思维自然有些混乱。第一步找了客服同事A讲解配课流程和使用中遇到的不方便；第二步则是借后台账号自己体验一番，直观感受这酸爽；第三步找经常使用该配课系统的同事B，听她吐槽了解她的问题。

总结了如下问题：

（1）用户uid查询与班级id查询不在一个地方，要来回切换三个界面。且班级id查看较麻烦

ID如何获得的

（2）少量配课时使用用户YY号+班级id；批量配课时则先把用户uid+班级id放入Excel表里，再上传系统。此处存在使用的用户信息不统一，需切换查询的问题。

（3）配课时系统不稳定，反应慢，不能一次性配成功

前三步想来是无问题的，也总结确认了问题，想着能开开心心的针对问题想解决方法了。查询不在一个地方就放一个地方，配课时使用的用户信息不统一就让它统一呗。还有配课时系统不稳定，就问问技术为何不稳定，让它稳定一次性配课成功就好了吧！

这就是当时傻呆傻呆的想法，现在想着也是醉了。。。好在产品经理Kelly姐友情协助，在我做微醺事情前问了我些问题，并给了她自己的意见。

1、用户在怎样的情景下以怎样的流程使用该配课系统。当时大概的回答是：需要单独给某些学生添加课程（比如：封闭班）时使用，流程就是先查用户uid，再查班级id，最后配课（边说边演示流程）。。这，傻呆！

2、以什么维度切入，以课为主还是以人为主。客服收集的资料在Excel表里是怎样整理的。

就这两个问题，本该前三步了解清楚的。。被Kelly姐一问就懵掉了，只能一再去询问经常使用该系统的同事！沟通效率极低！！弄清楚核心问题后便开始设计原型了~

第一版是这样的：

以课为切入点，先选择课再给课添加学员。但和使用系统的同事沟通后，同事觉添加学员跳转界面比较麻烦，希望能再优化。

便有了第二版：给同一批配课、给不同批人配课，这两种情况分开处理

（1）给同一批人配课界面

第二版原型-给同批人配课

给不同批人配课界面：

第二版原型-给不同批人配课

第二版虽然很好地将情况分开处理，方便了需求方。但技术工作量翻倍！

综合需求方的实际需求以及技术的开发量，第三版（也是给到技术的版本）终于被折腾出来了！和第一版思想契合度还挺高~

第三版-给到技术的原型

啰啰嗦嗦写到900字，前文傻呆样必得有后文经验教训总结~写成结尾：）

（1）首要确定场景。和另一位产品经理聊的时候，我说了一个困惑，很多时候场景太多，需求方自己都会有些混乱，如何是好？PM该做的就是帮需求方梳理业务，分类业务，抽离出模型来，再和需求方进行场景的确认。

以此次配课系统为例，各种业务抽离出来便是两类：给同一批人配不同的课，给不同批人配不同的课。个人观点是用汉字表示不太好，用字母、数字来表示下：

I给同一批人配不同的课即是：给A配1、2、3课

II给不同批人配不同的课即是：给A配1、2、3课；给B配1、2、4课。

用符号表示后，清楚看到II包括了I，场景以II为主来思考设计。

（2）其次是观察用户的使用行为（流程），按用户的流程去体验并找出核心元素与内在核心逻辑。

配课系统的核心是把课配给对应的学生，故需要用户id、班级id。即配课=用户id+班级id，需同时满足。同时满足这一点也是三种情况来的：

a.用户id和班级id同时加载（后台系统中现有的批量配课即是如此，Excel里用户id、班级id同时上传配课）

 b.先获得课程，再往课程里添加用户

c.先获得用户，再给用户添加课程

抽离出这点后，我脑袋里第一反应是淘宝购物的流程。先搜索物品加入购物车/立即购买，再填写收货人。和这个配课系统逻辑蛮像的，便借鉴了。以b形式切入，课程是有限的，用户是无限的。

（3）确定前两点后，核心功能点就差不多了，开始画原型？这个问题。。不太复杂的产品可以直接上原型，比较复杂的还是先流程图啊功能大纲啊，再原型吧！目前觉产品复杂时先流程图、功能大纲，可以更好梳理好思路，避免原型遗漏或者逻辑错误。当然画原型时也会想到新的情况，补充完善功能逻辑吧~

（4）功能上：得时刻记着人都是会犯错的，常见错误下用户仍能愉快玩耍！人是需要反馈的，反馈的功能也不要忽视掉了，让ta有安全感和对产品的可控感。

交互上：此次配课系统无涉及太多，以用户习惯、逻辑顺序等来思考？这方面得好好补一下了！

（5）其他：

a.功能优先级和时间节点，这两点得时刻谨记

b.与技术合作，共同认可的模板还是得有的。比如说我们团队，功能大纲+原型+逻辑展现，具体情况与展现可灵活处理

c.与其说自己去掌握好技术，更好的与技术沟通。不如说学着怎样做好项目推进，找到对的人去做ta擅长的事情，推动进展。推不动，看谁最痛，找ta即可

d.得看到真正的需求啊！配课系统最初我只看了表面，查用户id、班级id不在一块很麻烦而且还需手动记录，就想优化这一点！这就傻了，真正的需求是这样的么？把它们放在同一个界面就能解决核心问题了？

差不多写到这里吧，遗漏得应该不多。。快凌晨2点了，困T^T，PRD之类的鬼这次无涉及到，木有很规范走一次。。技术还无开始跟进，应该不会撕逼太严重吧~~小实践还是蛮多收获的~~产品不易做，思维能力慢慢跟上！

文末附上感谢名单：

首先肯定得谢谢老大给机会，且合理的先给了我小实践的锻炼。然后是Kelly姐无私帮助，伟炜的思维指点~最后就感谢下自己吧，哈哈^_^