中后台产品向来不会受到很大的重视，基本定位就是能满足业务需要就行了，体验好不好无所谓，直到运营，服务，销售忍无可忍时，才会去做一次大的改造与改版，但过程往往非常痛苦，投入成本巨大，对于需求分析师来讲，哪怕有一点点可以去做C端产品的机会，他都不会愿意接中后台产品的设计角色。
但现实非常的残酷，互联网在改变了C端体验之后，正在以飞快的速度渗透到B端，以Salesforce，钉钉为代表的SaaS平台，简洁的用户体验，正在抢占大量的市场。就企业内部来讲，随着90后，甚至00后逐渐步入工作岗位，这些人从小就接触互联网卓越的体验，当他们入职后，看到一个老到掉牙的系统，他们可能会认为是否踏入了一个正确的公司，甚至自此离职也是可能。
所以，作为负责这样产品的需求分析师，或者产品经理，如何做才能做到“卓越”呢？
人与人之间的沟通，最核心的要点，不在于你使用什么样的沟通技巧，关键在于你是否能够站在对方的角度考虑问题，如果你能做这样，那么即时你不会开口讲话，你一样可以达成非常好的沟通效果。
站在对方的角度考虑问题，很大程度上也就是同理心的表现，这点对于需求分析师来讲尤为重要，分析师优先要将自己转换为用户角色，去体验她的日常工作场景，她遇到的困难与痛点，所以首先，忘掉自己是一名需求分析师，你就是用户。
很多需求分析师一上来就和用户聊细节，聊具体的实现，这会极大的阻碍需求设计的结果，需求分析师首先需要去了解的是业务场景，说起来容易，做起来很难，有人说，那什么是场景？
场景就是用户需要完成某件工作任务的过程记录，并不是某个软件功能。比如：我每天上班的第一件事是处理昨天晚上用户发来的咨询邮件，确保这些客户的服务及时有效，这就是一个场景，分为几个核心要素：
目的：客户服务及时有效
参与者：用户，我
什么时间：每天早上上班后
任务内容：处理用户前一天发来的咨询邮件
优先级：第一件事
... ...
做中后台产品，不像C端产品，可以做大量的用户调研，做N版原型，用户打分来判定最终选择一个最佳方案；这里的用户往往是运营，营销，服务等公司内部部门的员工，而每个部门的员工能力水平参差不齐，不管是对业务的理解，还是对用户的理解都是。
一个脑袋不清晰的用户需求绝对可以把系统带入到万劫不复之地，如果需求分析师不假思索的全盘接受，就只会让系统越来越负责，越来越难用。
如果遇到一个用户脑袋想不清楚，那么就此赶紧打住，与他的Leader沟通换人。
极简是一种态度，对工作对生活对设计都是如此。
永远记着一句话，如果一件事情你觉得复杂了，那么别人大概率会觉得同样复杂，你设计后做出来的东西自然用起来很难用，用户很想骂娘。
运营一般可以分为三大类：
用户运营，以网站或者产品的用户的活跃、留存、付费为目标，依据用户的需求，制定运营方案甚至是运营机制。用户运营已经扩展到针对不同类型的用户进行有针对性的运营策略的阶段
产品运营，
活动运营，通过开展独立活动、联合活动，拉动某一个或多个指标的短期提升
内容运营，指通过创造、编辑、组织、呈现网站内容，从而提高互联网产品的内容价值，制造出对用户的黏着、活跃产生一定的促进作用的运营内容
参考文章：https://www.digitaling.com/articles/17811.html
推荐一本书：《从零开始学运营》
UX，需求分析师需要具备基本的用户体验设计思维，应该知道哪些模式是正确的体验，哪些是错误的体验，比如什么地方该使用按钮，什么地方该使用下拉菜单，什么地方不该显示message box等等。
多学习几本关于用户体验的书籍是正确的思路。这里推荐几本书，大家可以百度/Kindle:
Don’t make me think
用户体验的要素
UCD火花集，本书收集了UCDChina上线以来推出的13个话题，内容涵盖了产品设计的全部流程，按顺序集结到第一到第十三章中，讨论了如何研究用户、如何将用户需求应用到产品设计中、如何传达和协作。在第十四章，几位设计师分享了生活中的UE故事。第十五章，列举了一些实例和实践者的观点。本书适合有一定工作经验，从事产品设计、产品策划、交互设计、视觉设计、用户研究、前端开发、网站运营，以及所有与互联网有关的从业人员阅读
可以在豆瓣上查看：http://book.douban.com/doulist/432027/
需求调研时，需要识别并与用户确认最多的是变化点，以及变化频率，比如用户需要在订单查询界面上增加一个按钮，只有A部门的人员可以看到，那么问题来了，B部门的人员能不能看到，如果不能为啥不能呢？下一个需要看到的团队是哪个?这里就是变化点。
只有理解了变化点，才能去设计一个扩展性良好的系统，而变化点的识别能力恰恰是一个需求分析师新手与老手比较大的差异点之一，越早理解这点，就越早的踏入需求分析师这个行当。
业务往往是很急的，很多时候，我们需要考虑一个最小代价的方案，来尽快让业务跑起来，需要一个Quick Win，可以快速一个星期甚至更短的时间就上线。
Quick Win的设计极大的依赖设计师本人对业务和系统自身能力的理解，所以需求分析师需要懂得系统的实现逻辑，然后从这些逻辑里面挖掘到最低的改造成本，这点往往需要与系统设计师一起来完成。看到这里，是不是觉得需求分析师简直是万金油啊，什么都得懂，答案是对的，需求分析师就是要懂得更多，业务广度比深度更重要。
A部门提出需求后，需求分析师需要能快速的识别这个需求对上游部门的要求，以及对下游部门的影响，一些逻辑还需要得到多方的讨论确认才能最终定稿，否则等系统做出来，将会给大家造成很多Surprise。
最后一条，不要相信权威，特别是大领导，这也是很多需求分析师不能达到人生至高境界的瓶颈之一，特别是对于中后台产品而言，敢于坚持自己的想法，并以业务+技术的态度说服领导，才是需求分析师的本职。
关注微信
