大部分人都经历过或者听说过这样的场景
确认过需求，产品也做出来了，运营人员在使用过程中，发现在某个界面需要添加一个按钮（或是别的什么小功能），用户体验会更好，于是找到技术人员
运营：我就加一个小小的按钮，应该就是几分钟的事情，你居然推三阻四说要排期，要等一周？黄花菜都凉啦！
技术：前期需求已经确认，你突然说要加功能，这个按钮涉及到适配、界面布局、边界属性、数据接口等等，你都不懂还好意思说分分钟搞定，你行你来啊！
感受到火药味了没？
运营人员有错吗？技术人员有错吗？
双方都没有错，这种“一触即发”的紧张感，是由于双方语言体系和思维模式的冲突造成的。换句话说，运营不懂技术，技术也不理解运营。
神图说明一切
有人会说：哪有人既懂运营，又懂技术？肯定有这样的人，只不过“懂了”之后，除开工作岗位变得更加重要以外，仅仅从基础沟通层面，能有哪些好处？
我跟大家分享两个发生在我身上的真实案例（为避免对号入座，部分细节做模糊化处理），我在零售行业工作，会跟各个部门的人打交道，这其中有运营部门，也有技术部门。
第一个案例
今年6月份，技术部门根据数据推送及用户反馈，迭代升级了数据推送方式，为了推广这项功能，制作了一份功能说明书，私下先发给我看。说明书首先介绍了这个功能，主要实现数据从PC端到移动端的自动转移，第二，介绍了原来在PC端如何操作，并附上了3张小图，这两部分就占了说明书的一半，看到这里，我已经有点不耐烦了“到底在说啥啊，新功能是啥？”，耐着性子看第三点，终于说到新功能怎么用了，然而两段绕口令一样的说明，直接击垮了我最后一点耐心。
如果不是因为私交关系好，我早就掀桌子了，一个简单又实用的功能，说的那么复杂，分分钟不想用了。经过沟通，我们把这份功能说明书缩减为三句话，第一，告诉用户，我们开发了移动端推送数据的功能，第二，告诉用户要做什么（自行管理对应的数据推送群），第三，该功能的上线时间。
仅仅共同修改说明书这件事情，花去了2个小时的时间。也就是说，我们花了2个小时，让更多的普通用户能够理解并使用这项功能。
第二个案例
前不久，技术人员设置了一套小程序模板消息，通过小程序关联公众号后，可以实现公众号粉丝精准营销，如会员的消费提醒、福利领取提醒、福利使用提醒、相关活动的提醒等等，并且不会产生额外的费用。对于运营来说，应该是一个非常好的功能。
技术人员来跟我聊如何在运营部门实现这个功能的接入。“哐叽”一下先扔过来一份18页的功能说明PPT，前两页就直接把我看晕了。
触及服务通知、传统H5运行环境、读取服务器……这些语句显得有点难懂
说了一大堆的限制条件，运营还会用这个功能吗？
还是那句话，如果不是因为私交关系好，我早就掀桌子了。我看到最后一页，再结合我以前有过的公众号运营的经验，大致理解了这个项目的解决的痛点和实施方案。然而，我明白了，并不代表使用这个功能的运营能明白。于是，我们又花了一下午的时间，调整了功能说明PPT的内容逻辑，删减了技术类的专业术语。
现在，我们回到最初的那个问题，如果一个运营能够有一点点技术的概念，双方沟通起来，是不是更加顺畅？
运营不需要是技术专家。运营需要知道技术的可能性和边界。只有这样，才能提出切实又切中要害的功能点。
运营，就是产品思维，从用户价值出发，满足用户需求，它代表了用户。
而技术思维则是从功能实现出发，寻求技术架构和开发成本的平衡，代表实现。
技术问题有时候比狭义的产品问题更基础。比如你的应用或者网站，访问慢，又老挂掉，这时候，产品使再大的劲儿也无济于事。如果你是一个广义的产品或者产品运营，就应该了解哪些问题更基础更重要，在做规划时候，应该留出空间，让大家解决这类型的问题，而不是一味的加功能，做活动。
网友评论