美文网首页大数据技术
关于服务,产品,项目开发的碎碎念

关于服务,产品,项目开发的碎碎念

作者: 彩色蚂蚁 | 来源:发表于2017-11-30 09:26 被阅读49次

最近有点小忙,更新得慢了,翻出一篇之前没有发在公众号的旧文,凑个数

前排提示一下:下面的内容,是一篇鸡汤文章,本质上,鸡汤这玩意,知易行难,先贤们都总结了五千年了,道理说多了,难免让人觉得一切都是陈词滥调。所以时下毒鸡汤反倒成了一股“清流”。所以,为什么还要写鸡汤?大概还是因为自己的切身体会吧。

数据平台团队,做为底层服务团队,所承担的工作,技术难度不小,稳定性要求也高,而同时,不论是上下游依赖还是周边环境,往往都是错综复杂的。而数据本身和上层业务又紧密相关,应用场景复杂,加上我们团队的能力也的确有限,因此历来都属于用户抱怨的重灾区。。。

当然,这一切只是原因,不是理由,所以,如何直面现实,从观念入手,更好的改进我们的产品和服务,积极的面对项目开发过程中遇到的困难,也就成了我们团队无法逃避的问题。

以下内容,更多的是教训和体会,然后,将感受最深的,抽象成几句话。我们自己做得也并不理想,写下来,和大家共勉。


主观即是客观

鸡汤派:提供服务,当然要秉承用户就是上帝的观念!
现实派:我一向如此,除了上帝犯错的时候 :)

很多时候,当用户抱怨的时候,我们往往会据理力争。因为我们之所以有时候不把用户的意见和抱怨当一回事,很可能是在一些场景下,我们认为,用户的抱怨是没有道理的! 比如:

  • 这种错误都会犯,太奇葩了,就不能好好学习,多谷歌一下吗?
  • 怎么使用,说明文档上都写了,也培训过好多遍了,群里也都说过了,怎么就不能认真学习一下正确的打开姿势呢?!
  • 网络挂了,DB崩了,ZK跪了,别的业务方瞎玩。。。不能出问题都赖我们身上啊
  • 我承认你说的问题,但是你要考虑我们的实际情况!我们一直在努力,做了很多事,一直在改进,当这件事没有那么简单,不要不了解前因后果,上来就批斗我们,我们接受意见,但是你要请给出客观的意见!

好吧,是的,用户的意见,在绝大多数情况下,都很主观。So what? 保持客观,不是用户的职责。主观的感受,就是用户客观的真实体验。

说到底,服务平台的价值产出,你做了多少不重要,产生多少收益才是关键,出了问题,责任是谁的,除了你,其实没有人关心,就算解释了,也不见得能挽回吃瓜群众的“错误印象”。不出问题,才是王道。现实就是这么残酷。

与其据理力争(为自己赢得一个好的舆论环境),不如用产品和事实说话。省点力气辩解,多花点时间,从用户的主观意见中,去挖掘客观问题,争取更快的达到这个目标,才是长久之计。

它山之石,可以攻玉

鸡汤派:产品总是要不断改进,借鉴别人的经验是最好的方式之一!
现实派:然而,它山都是烂泥,如何能够攻玉?

习惯上,所谓技术相轻,我们总喜欢挑别人的问题,用户如此,你也一样 ;)这也经常体现在我们去调研各种技术和产品方案的时候。

如果自觉的做得比别人好,那么:

  • 那个系统,哦,我知道,做得太垃圾了,我们早就不这么玩了!
  • 只是说得很好,金玉其外,败絮其内!

如果感觉差异不大,那么:

  • 看起来很复杂,不过代码结构不漂亮,维护成本太高了!
  • 侧重点不同,那些功能都是没用的,不是我们关心的。

如果好像真的不如人家,那么:

  • 现阶段,我们并不需要。还有,这个地方我们这么做更符合我们的实际需要。
  • 嗯,我们的场景完全不同!

好吧,可能都对!不排除很多情况下,还真的很客观!

不过,古人不是云么,三人行,必有我师。换个角度说,参考和学习别人的系统,你的目的是研究如何改进自己,而不是论证自己不需要改进。

  • 别人做的那么烂,是不是有值得我们警醒的?这么烂能run起来,是不是哪里的业务重点抓得很到位,值得我们借鉴?

  • 别人的不足之处,是不是出于他的业务场景的权衡考虑?事实上,放在自己身上这不是一个常见的理由么 ;)这些场景,我们真的不需要考虑?

  • 同理推广一下,其实,即使不太相关的系统,从业务定位和解决问题的方式方法的角度,很多时候,也是可以学习和借鉴的。

总之,投了时间去看别人的系统,没有收益岂不是很亏? 事实上,绝大多数情况,都会有收益的。挖掘亮点才是关键,至于别人的问题,让别人自己去操心和反思吧 ;)

以终为始, 知彼解己

鸡汤派:莫忘初心!
现实派: 我擦,完全不知所云。。。

所以,这么高深的表述,不是我说的,是《高效人士的七个习惯》里的两个章节内容。

关于这两条,安利一下,真的是本好书,虽然看似也是一本所谓成功学的鸡汤书,如果你要这么认为的话。

不过和其它什么厚黑啊,心理学啊,成功学啊等论“术”的书不同,这本书更多的是论“道”,既然论“道”,那么“术”就需要自己去在实践中寻找的。

关于知彼解己,再解释一下,就是: Seek first to understand, then to be understood

一切考虑出发点,和众多论“术”的书的出发点不同,在这里,你去了解别人,目的并不是为了知己知彼,百战百胜。事实上,Seek,关注的是寻觅,就像你探寻知识一样,understand 是你的目标,绝对不是你用来赢得好感,进而操纵他人的手段。而be understood只是这个目标结果下很自然的副产品。

古人又云了:“将心比心”,姿态上差不多类似的意思。

其它不多说了,看书最佳!我只想说,如果出发点明确了,真的,会有作用,无论产品,服务,还是沟通。这点,或许放在复杂的工作环境中,我做得还不够,需要更多的时间去体会,但在过去的一段时间里,用在“对付” 我家两三岁的小朋友这种简单的case里,自我感觉还是有不少收益。

自产自销

鸡汤派:论如何关注用户体验!
现实派:我吃素的,真没机会自己吃狗粮。。。

好吧,Eat your own dog food, 又是一个颠扑不破,但是从来未被真正执行的真理。

系统为什么那么烂? 开发的同学自己不用啊~~~开发的同学为什么自己不用? 自己不是目标用户啊。。。然后,Eat your own dog food,就只是口号了

的确,如果你真的是吃素的,那强逼自己吃肉就需要方法论了,我的感觉是:

  • 上上策,系统自举,监控系统能自己监控自己的健康不,可视化系统能可视化自己的数据不。发布系统能自己发布自己的更新不。
  • 上策,没有需求,创造需求也要上,不论写Demo还是和业务方合作开发,逼自己成为用户。
  • 中策,内部交叉。 开发系统的同学自己不用,部门内部的同学不用么?我的A系统提供的服务,B系统能用么?不用也得逼他们用~~~
  • 下策,手拿产品需求清单, 脑补业务场景,定期覆盖性测试。。。。

最后,如果可能,从系统开发之初,就一定要带着一个真实业务上线,别管是通过胁迫还是跪求换来的。是不是有点养条宠物狗让它帮吃的意思 :)


写到这里,回头再看,还是感觉更像务虚的鸡汤,对读者来说,没有实际经验教训体会的话,大概是没有多大用处的。无所谓了,权当总结和提醒自己,也算是自产自销不是 ;)

常按扫描下面的二维码,关注“大数据务虚杂谈”,务虚,我是认真的 ;)

相关文章

  • 关于服务,产品,项目开发的碎碎念

    最近有点小忙,更新得慢了,翻出一篇之前没有发在公众号的旧文,凑个数 前排提示一下:下面的内容,是一篇鸡汤文章,本质...

  • 产品碎碎念

    产品碎碎念

  • 2020-12-21 舒缓 1--重新开始

    无力 难受 这一两周的情绪, 察看了自己的碎碎念, 我所有的碎碎念都是关于女儿的,早上起来不来的碎碎念, 看她看手...

  • 关于产品经理的碎碎念

    1、印象里是@伊卡洛斯之翼 首提“产品狗”这个说法,改称“产品汪”则是我开的头。 为什么产品经理会自黑成狗呢?大约...

  • 项目管理 Zero to Hero 软件研发流程 理论 (一)

    序(一点儿碎碎念) 互联网公司研发自己的软件产品,会有属于自己公司的一套整体产研流程。关于项目流程方面,太多的方式...

  • one想丨press one 创造出了文字生命体

    press one◆◆六环:碎碎念 关于press one。最近,项目方纰漏的内容还是蛮多的。社群的发展正在以to...

  • 2019-06-13项目需求实现方案反思

    碎碎念: 公司的主营产品是服务于机构管理者进行机构业务运营管理的,主要是服务于机构进行招生、签单、教务、续费等模块...

  • 为何要在简书上开始碎碎念

    1、为什么要碎碎念 作为pm,除非在高强度的工作下去经历多个项目,不然单靠几年的项目经历,是很难让自己的产品思维提...

  • 产品碎碎念

    1.思维实验,查找与替换。 想象一下,当你参加一个讨论品牌的头脑风暴会议,与其不断的提出关于品牌的问题,不如试着用...

  • 产品碎碎念

    1、我有一个粗暴的观点:产品原型图上90%的需求都是没有价值的。 比如说:压根错误的方向。事后被证实为使用率极低的...

网友评论

    本文标题:关于服务,产品,项目开发的碎碎念

    本文链接:https://www.haomeiwen.com/subject/wjgtpxtx.html