阳鲜：希望offer快来

wwwWTttt：没想到有这么一大部分年轻人的想法竟然是这样，愿意的比不愿意的还高。什么叫高薪？在这个论坛上有些人觉得二十万就很好了，有些人觉得四十万还只是个基本工资，那这样两种人都拿到高薪了能一样996吗？看来中国对于每天八小时工作制的普及还是任重道远啊，这是多少代人从资本家的压榨下争取来的劳动人民权益啊。强制996不是能不能接受，而是本来就不合法！如果年轻人都不能站起来维护这个权益，那今后的压榨只会越来越重。想问一下牛客网你立个这个话题目的是什么？你们公司是996吗？

又戈月空：在一家互联网公司内部，产品和运营就好像是一对爱恨交织的生死冤家，他们的关系是非常微妙的。 在互联网圈里，还流行着很多这样的段子： 在一个运营的眼里，事情常常会是这样的—— 假如数据特别好，用户上来了：看我们运营多牛啊…… 假如数据特别烂，用户没上来：产品做得太差了，你看用户都不爱用…… 而同理，在一个产品的眼里，事情也可能会是这样的—— 假如数据特别好，用户上来了：看我们产品多牛，有了好产品，猪来运营都能做好…… 假如数据特别烂，用户没上来：运营一天到晚干什么吃的，看别人的产品比我们烂多了，数据都能哗哗往上涨…… 比较流行的一种说法是：产品就像生孩子，运营就像养孩子。其实这个说法还不是特别准确。 因为，孩子生下来后，模子是不能变的，但一个产品上线后，还需要在运营过程中不断迭代和调整。 所以，两者间的关系，产品方向和产品形态要决定运营的思路，反过来，又需要运营根据用户反馈和运营需求来决定产品的调整和迭代。产品负责界定和提供长期用户价值，运营负责创造短期用户价值+协助产品完善长期价值。 这当中，产品和运营间的关系之所以微妙，在于两点。 1．很多产品的长期价值并不是用户一眼就能感知出来的，而是需要经过一段时间的使用和体验才能感知到的。所以，为了让用户得到这个长期价值，我们需要通过运营先去创造出来一些短期价值，以刺激用户愿意先去尝试使用它。 2．很多产品的长期价值不是一蹴而就的，而是必须借由用户的持续使用和反馈，经过长期优化迭代后才能成立的。所以，要是没有用户的使用和反馈，产品很可能永远无法形成真正的长期价值。因而，在产品的长期价值还不是那么确定的时候，运营需要先通过创造一系列的短期价值让用户能够先使用你的产品。 在面向用户的立场上，一旦产品的长期价值已经特别明确和具体了，这时候运营最应该做的事情，就是通过包装、策划、营销等一系列手段去面向用户把这个价值传递出去。这时候，运营所要发挥的作用，有点儿近似于传统意义上的“营销”了。只不过，对一个互联网产品而言，这样的状态，永远是很少的。大部分时候，一个产品都处于持续不断的摸索、调整中，需要运营一起参与去完善它的价值。在这个立场上讲，假如一家公司的产品和运营没法做到一条心，共同“以用户为中心”来做好自己的工作，最终共同为用户提供价值，其实是挺可怕的。

_马可_：一、从“用户体验”去思考这个问题 我们设计一款产品、一个功能不仅要考虑它能带来什么价值，还要考虑它是否会给用户带来负担。 所以，这个问题最简单的思路就是从用户体验入手：我们可以从「撤回」会给用户带来怎样的体验，来倒推为什么微信没有做这个功能。 假设红包可以撤回，会有哪些场景呢？ 1. 个人已领 你兜里有100块，你走着走着捡了100块，你非常开心。你继续走，到家之后发现丢了100块，这个时候兜里只剩100块。 问：你现在什么心情？ 回到微信红包上来，你刚刚领取了朋友的红包，30s后收到一条消息：红包已撤回，66元已从你的微信余额扣除。此时此刻，你又是什么心情？ 这种“得而复失”的愤怒比“从未拥有过”的失落来得更凶猛一些。 对于接收方而言，体验和心情双差。 2. 个人/群未领 微信本身就设置了“如果对方在24小时未领取你的红包，资金会自动退回到发送方账户”的策略，说明微信是支持「发送方」在“对方没看到”或“不想接收”场景下收回红包的。 ——毕竟，发送方的钱已经扣了，接收方一直不收，钱不可能一直冻结着。 抛开24小时系统自动退回的场景，如果对方未看到或不想领，这个场景下，采用和信息撤回一样的策略（2分钟内）对收发两方用户是没有任何影响的。 但如果这个功能被别有用心或是无聊之人利用了，也会带来负面的用户体验。 比如：现在经常有人发一条消息#[微信红包]恭喜发财，大吉大利#，等你点开发现是文字；如果有红包撤回功能，这种人可能会先发一个红包引起你的注意，然后马上撤回。 3. 群部分领/群领完 你在群里发了红包，有3个人抢到了，还有7个没人领，撤回逻辑应该怎么做呢？ 方案一：选择撤回-仅撤回未被领取部分。 方案二：选择撤回-全部撤回。 抛开实现逻辑的复杂程度不说，无论你选择方案一，还是选择方案二，都会让抢红包的人不爽。 按照「损失厌恶」心理，同量的损失带来的负效用为同量收益的正效用的2.5倍。 其次，微信的产品设计理念中，在接收方和发送方有冲突的时候，微信更关注接收方的体验。放在这个场景下，微信是不会让一个发错的红包去损害熟人社交关系的。 交易行为一般是比较正式的行为，如果发错了对方是可以理解的，可以找对方追回。而不是在对方不知情、未允许的情况下，在你执行撤回操作后直接从对方的余额里把钱扣回来——这种交易是一种风险交易，以后谁还会用微信做交易呢？

牛客99999134...：#便利蜂2020春招牛客职播# 本场直播已调整至21点，21点将准时送出牛可乐T恤5件！请关注直播的小伙伴们注意哦~！

Wendy芃乔：自己家庭情况不好，从大一结束后就一直自己兼职赚钱，每月省吃省穿，很多吃的穿的看得买不得。时时刻刻都想存着钱啊，存钱就能让自己吃了

是丸子：小伙伴们快来与我们互动吧~~

【社招/校招可内推网...：拉新——PV UV（日均、阅读量的环比同比）；点击量，点击率；用户数，转化率 留客——用户每日登录次数、按钮点击量、跳转到页面数量 促活——引导跳转、引导打卡、引导报名、引导发帖和评论、点赞数量、评论数量 转化——ARPU、ARPPU、付费渗透率、环比上周、奖励支出，平均每个用户获得数量，虚拟货币的收支、引导充值、引导消费 自传播——转发数量、在看数量

_马可_：1、需求的投入产出 一般情况下，判断产品需求优先级的主要依据是需求的投入产出比（ROI），即产品需求的投入成本与产出价值之间的比例。投入产出比越低，说明产品的效益越大，产品需求就越值得我们开发。反之，则放弃开发。 投入产出比 = 投入成本 / 产出价值* 100% （1）价值 产品需求的价值包括用户价值、公司价值和商业价值三个方面。作为企业，最终看中的还是商业价值。一般产品的用户价值越高，它的商业价值也越高。 （2）成本 产品需求的成本就是实现产品需求时需要投入多少的成本，包括开发人力成本、维持产品正常运行的硬件成本、后期的维护成本以及日常运营成本等。 一般情况下，对产品需求成本的评估只需要考虑开发资源的投入即可。产品经理可以根据经验大致估算一下开发成本，也可以与开发团队共同评估。这个成本值只是一个大概值，因为此时的需求细节还不明确，但是这个估算值对投入产出比也有着非常大的参考价值了。 2、需求的紧急程度 根据需求的紧急程度，我们也可以确定产品需求优先级。这就是我们常用的四象限法则：P0紧急重要、P1紧急不重要、P2不紧急重要、P3不紧急不重要。 https://upload-images.jianshu.io/upload_images/18171853-cee4702baab336f9.png?imageMogr2/auto-orient/strip|imageView2/2/w/42 3、需求的复杂性 一般我们可以用（预计）工作时长来表示该需求的复杂性。但在考虑复杂性的时候还需要考虑实际可调配的资源情况。比如：这个功能是否需要投入较高的运营费用？是否拥有足够的人力去支持该需求的运营？最后，还需要去考虑该项目的风险程度。开发小伙伴是否有能力完成，该需求是否会对已有的其它功能产生影响？ 因此，可以总结为“需求复杂性=时间+资源可调配情况+风险程度”，当然时间、资源可调配情况和风险程度是需要根据项目组的实际加权处理的，在不同的项目中，不同影响因素在复杂性确定中占据不同的权重。

_马可_：1.var （1）var定义的变量在之后可以修改，如果不初始化会输出 undefined，不会报错。 （2）var定义的变量，可以跨块访问, 不能跨函数访问。 （3）var只有函数作用域，没有块级作用域。 （4）var的作用域是函数作用域，var可以用来声明全局变量，也可以声明局部变量。在一个函数内利用var声明一个变量，则这个变量只在这个函数内有效。 全局变量：在函数外定义的变量，作用域是整个代码文件。 局部变量：在函数内定义的变量，作用域是当前的函数内部。 （5）可以重复定义，后面的值会覆盖前面的。 2. let （1）let是块级作用域，函数内部使用let定义后，对函数外部无影响。 （2）不存在变量声明提前，否则会报错。 （3）let定义的变量，只能在块作用域里访问，不能跨块访问，也不能跨函数访问。 （4）不能重复定义，否则会报错。 3. const （1）const定义的变量不可以修改，而且必须初始化。 （2）const一般用来声明常量，且声明的常量是不允许改变的，为只读属性，因此就要在声明的同时赋值。 （3）const与let一样，都是块级作用域，只能在块作用域里访问，存在暂时性死区，不存在变量声明提前，不允许重复定义。

fgy0318：还愿啦~第一次中奖，最近都没有offer.感谢奖品的激励。我会继续投递，直到拿到offer为止。 祝牛客越来越好~mua~