边界

对，最近超级不爽，于是又想写东西了。

于我而言，愤怒才是第一生产力。

不知道是否是因为最开始的态度问题，这一次入职新公司破冰非常缓慢，几乎快两个月过去了，我还是完全没有进入状态，不管是对产品的了解，还是与同事的关系都是隔着冰山的状态。

最开始期待值极高，接着摔入谷底，不断的暗示自己调整状态，享受被虐的过程。leader前一段时间说我状态好多了，但我依旧觉得这并不是我的正常状态，也许是上一家公司惯我太多。

1.微信办公简直傻逼。

真是难以想象竟然有一家接近300人的公司使用微信办公，新人入职就被拉到各式各样的群里，公司大群，部门大群，小组小群。你因为工作需要申请各种权限时，你需要加一个个的同事，等待对方通过后，再谈事情。然而我只是想增加一个权限，并不想加任何的同事。

在微信里讲重要的事情，信息流一刷都没了，还委屈说我通知了，服气。

深夜往微信群扔文件，扔完再艾特你，于是你第二天看到后先从手机端下载再转发到助手，在PC端再下载下来。怎么不去死。

跟对方说发邮件，丝毫不鸟你，继续微信群扔文件。#好了有些同事也是傻逼。

2.作为员工，我到底要干嘛？

被招聘进去我以为要开始学习技术，作为一名爬虫的产品狗，跃跃一试。

然而审完两天小黄图后，开始让我接手海外A事情，还没接手呢又让我先把国内B事情接过来。于是手忙脚乱的接了。

每天被虐的死去活来，事情多，重复性强，内容管理系统太难用（作为运营驱动型公司，后台难用的一逼，经常间歇性罢工，除了等别无他法，作为一个产品狗哪里遭受过这种待遇。运营的小伙伴安慰说习惯就好了。

果然习惯就好了。

刚刚开始习惯，就又转手把这个交接给别人。开始接某助理留下的坑C，坑只做了一个功能呢，又开始接运营活动。思考运营策略。

倒是很开心，然而变来变去，我也是不太懂。

这是明显的管理加人思维，我们事情太多忙不过来啊，招人吧。

人来了，什么事情交给他做呢，先做这个吧。

哎呀，有点调整，让她换个位置吧。

哎呀还是好多事情啊，大家都好忙啊都在加班啊。

3.产品经理定义数据库表字段。

为什么对这件事情耿耿于怀，因为我在为此事情买单。就在刚刚，已经是深夜，研发还在办公室做两个表同步的事情。然而因为弃用表与新表没切干净，新表又要与关联表同步，出了问题。

至此我有两个疑问，产品助理哪来的自信去定义字段？

其次，产品定义的字段，表名研发都不过问么？都不清楚字段都敢建表？

没关系，就是低头肝。

这种加班丝毫没有任何意义。

当然我也被教育产品经理可以不考虑建表，但是sql语句一定要玩的溜。呵呵一脸。

我会sql，但我并不乐于写好insert语句让你直接去执行。

由此引申各个角色的边界到底在哪里，我从未见过这样行事的公司，可能是见识不够多。

产品和研发的边界

在以往经历的公司，产品和研发各司其职。产品连数据库都不会去连。

作为一个功能型产品经理，关注的是产品的用户和功能，实现逻辑定义清晰，找研发碰，双方觉得这事儿可干，那就肝吧。

遇到好的研发leader，他会帮你理清思路，甚至给你提供更好的解决方案。还会去追问功能的性价比。

我一直耿耿于怀表的这个问题在于，我似乎不是同类，能否写出漂亮的sql语句竟然能成为衡量一个产品是否专业的标准。而其他产品似乎也很自得于这一点，那我想说我第一年工作的时候可是非常专业，毕竟大部分时间都在跟sql打交道。

而研发为什么不动脑子？

研发更像是机器，你告诉我1对着1，2对着2，3对着3，我可以帮你同步。哈？你这个这里有1，那里没有，同步不了哦。

你只告诉我具体的实现方式，但是我脚本写好了到底什么时候执行呢？你这不说清楚就是需求描述不清晰啊。我的天，我的需求背景和目的都是白写的吧。

那我的脚本执行结果之后更新到哪张表里呢？operater写谁呢？（写我行不行啊

永远不知道需求应该细化到什么程度，而陌生人之间的这种摩擦真是太生硬了。

对方觉得你太不专业了，需求这么描述要怎么做。

我？？？？

产品和运营的边界

无数文章讲了产品和运营的区别，身处产品时觉得运营无力，其实是甩锅的想法，究其根源是产品本身有问题。毕竟不能责怪自己对不对。

身处运营会觉得更无力，就像忽然拿到一把枪，装满了子弹，却不知道往哪打。

身边人会用理论派的思维帮你分析，超级nice地帮你理清思路，你要先看好目标是什么，瞄准，扣扳机，看反馈就OK啦。

如果我是别人，我也可以给出这样的建议，其实并没有什么卵用。

身处黑暗，需要找寻的是一丝光芒可以看清楚目标。

又或者简单粗暴，根本不考虑看清，而是反正已身处黑暗之中，当自己是瞎子先扫射一圈。根据命中的反馈再次攻击。

产品的那一套先搞清楚目标用户，解决什么样子的问题，预期目标是什么，完全行不通。或者根本没时间行通。

我们的口号就是：

先肝。

今天翅膀发微博说，我做产品啊，其实就是玄学（靠感觉。

纯银的话是：

正确的产品设计一定能反推出强大的逻辑链，但强大的逻辑链不一定能推导出正确的产品设计。这就是做产品之所以被称之为玄学，也是我认为做产品读书无用论的原因所在。

又想了想，这件事情还是可以解释的。做产品的变量太多，当所有变量都稳定下来，通过结果反推可以得出笃定的结果，当事人却很难穿越重重变量的迷雾。你信赖的每一个理论、方法和案例，都会在东拉一把西扯一把的变量影响下扭曲得面目全非。

运营是否同理？

下周第一个活动上线之后，也许感知会更清晰吧。

今日被隔壁产品总监喷做的调研活动毫无意义，目的是什么呢（产品一味的套路。

作为产品狗我当然是很赞同他的观点的，用户并不能帮你做选择，并且还举了乔布斯才不理用户反馈的例子。厉害啊。

对方希望做一些功能的场景化推介，这就是产品思维，我上了A功能，但是数据不够好看。所以肯定是用户不知道这个功能特别好用，所以这是你们运营的工作没有到位，为什么不围绕这个功能做一些推广呢。你看2C产品都这么想，我之前做2B产品强烈倚赖市场和运营也不是太过分对不对。

反正数据上不去肯定不是我的功能问题啦，这个需求肯定是存在的，如果要说有问题一定是你们的问题。

interesting