如何确定自己在做难而正确的事,而非难而长期且错误的事?

简单记录下最近工作中的一个思考,供大家参考。P.S. 目前还有少量数据工程HC,感兴趣可关注公众号信息并联系我。

难而错误的事

工作十多年, 待过几个公司, 每个公司都有自己的风格文化价值观。

总体来说, 阿里是待过的几个公司中,最看重产出及结果的公司;很多其他公司既看中员工拿到的结果, 也看中过程:过程对了, 结果一般, 很多时候公司也认,绩效也不会差。

阿里不一样, 阿里为过程鼓掌,为结果买单, 好的产出结果才会有好绩效。

以前就在想:这样会不会太短视, 导致大家都追求短期利益, 一定程度上忽略了长期的投入, 会导致大家都不愿意做‘难而正确的事’

记得去年有个离职的同学也和我说他觉得自己做的事是难而正确的事, 觉得公司的环境不太认这样的工作和投入(虽然我当时就觉得他做的事产出肯定有问题)

最近老大的分享终于让我想通了这个问题, 首先要回答的问题是:如何证明你做的是难而正确的事,而非难且需长期投入且错误的事?

Think Big, Start Small

只能先快速出原型,拿到收益,证明可行性, 然后再做大拿到更多收益, 直到将这个事做大, 做成一个长期的事。

当然我们一开始的时候需要想的理想化一些, 但从需要快速某个点快速入手进行验证。这一点类似于Google早年工程师推进工作的方式:Think Big,Start Small,都是一个道理。

业务优先 VS 平台建设优先

例如研发很多时候会抱怨:‘我们成天做业务做需求,没有足够时间将平台做好!希望有时间先将平台做好,之后在平台上再支持业务!’

那到底是业务优先, 还是平台优先?这个问题没有正确答案, 不能走极端,需要迭代推进。例如先快速糙快猛验证模式原型, 验证拿到收益后,再扩大系统建设投入, 之后拿到更多业务收益后,在系统建设上争取到更多业务的信任, 资源后, 再进行系统建设, 以此正向迭代。否则如果短期内拿不到收益, 那就说明不了长期看这是个正确的事, 很可能就是一个自以为的难而正确的事, 其实是难而长期且错误的事。

图:平台建设VS业务开发,需要拿到业务收益,验证模式,迭代推进。

否则,技术长时间仅接业务需求,会导致工程师没有成长,没有能力提升,没有系统性思考;而如果先搞牛叉系统,很大概率是投入比较多,但做出来的系统没人用,因为业务觉得不好用,负责人会死得很惨。例如好多年前我搞过一版用户画像,自己觉得自己搞的数据很牛叉,还挺全, 结果业务方觉得不是自己想要的数据, 不好用也不愿意用, 结果投入人力挺多, 结果就是在自HIGH。

老板想要什么?

从业务的角度, 老板想要的是什么, 这个问题也值得好好思考, 很多时候老板想要的是:业务长期良性的增长, 那光实现业务需求, 或者光做平台就能解决吗?解决不了, 还是需要短期糙快猛的拿业务结果验证模式, 以及长期的系统建设需要结合。

所以, 各位研发, 或者产品同学如果觉得老板似乎在同一时间又在乎短期业务收益, 又似乎更看中长期投入的时候, 你需要按照以上思路来理解, 并且按照上述思路来推进你的工作。这样你才能想明白为什么觉得老板真的是:既要也要还要都要

当然, 以上只是针对当前多变世界的一种应对模式, 很多优秀的公司, 也会在某个方向持续做十几年然后突破爆发, 例如特斯拉,XSPACE都是成立十几年的公司,做的方向也很聚焦。具体思维框架的应用, 也分具体的环境。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注