关于产品,服务,项目开发的碎碎念
2016-12-28 17:05
197 查看
作者:刘旭晖 Raymond 转载请注明出处
Email:colorant at 163.com
BLOG:http://blog.csdn.net/colorant/
下面的内容,仔细想想,好像是一篇鸡汤文章,而我,最讨厌做烂大街的事,所以,为什么还要写?这,是个问题。。。
本质上,鸡汤这玩意,看着有理,但知易行难,如果不实践,或者没有切身体会,,再多都是陈词滥调。君不见,先贤们都总结了五千年了,时下,毒鸡汤反倒成了一股“清流”
跑题了,为什么要写,还是因为切身体会吧。
数据平台,做为底层服务,技术难度不小,稳定性要求高,而同时,不论上游依赖还是下游业务,都是错综复杂的,数据本身和上层业务又紧密相关,应用场景复杂,加上我们团队能力的确有限,因此,历来都是被抱怨的重灾区。
当然,这一切只是原因,不是理由,所以,在过去的一年里,如何直面现实,从观念入手,更好的改进我们的服务,也就成了我无法逃避的问题。
以下内容,更多的是教训和体会,然后,感受最深的,就抽象成几句话。我自己做得也并不如意,和大家共勉。
本质上,想想我们之所以有时候不把客户的意见和抱怨当一回事,很可能是在一些场景下,我们认为,客户的意见,是没有道理的! 比如:
这种错误都会犯,太奇葩了,就不能好好学习,多谷歌一下吗?
怎么使用,说明文档上都写了,也培训过好多遍了,群里都说过了,怎么就不能认真学习一下正确的打开姿势呢?!
网络挂了,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,就只是口号了
我的感觉是:
上策,自己不是用户,没有需求,创造需求也要上,非得逼自己成为用户。
中策,内部交叉。 开发同学自己不用,部门内部的同学不用么?我的A系统提供的服务,B系统能用么?不用也得逼他们用。。。小白? 最好~~~
下策,对着需求清单, 模拟业务场景,覆盖性测试。。。。
话说,这下策,我自己已经下了大半年了,俨然已经成功转型测试工程师。。。 :(
写到这里,回头再看,还是感觉更像务虚的鸡汤,对别人大概是没有多大用处,无所谓了,权当总结,时刻提醒,也算自产自销不是 ;)
顺道,推销一下个人公众号 “望月的蚂蚁”, 和技术完全无关。。。。 一切有趣的兴趣爱好等为主题。工作生活要平衡不是;)
Email:colorant at 163.com
BLOG:http://blog.csdn.net/colorant/
下面的内容,仔细想想,好像是一篇鸡汤文章,而我,最讨厌做烂大街的事,所以,为什么还要写?这,是个问题。。。
本质上,鸡汤这玩意,看着有理,但知易行难,如果不实践,或者没有切身体会,,再多都是陈词滥调。君不见,先贤们都总结了五千年了,时下,毒鸡汤反倒成了一股“清流”
跑题了,为什么要写,还是因为切身体会吧。
数据平台,做为底层服务,技术难度不小,稳定性要求高,而同时,不论上游依赖还是下游业务,都是错综复杂的,数据本身和上层业务又紧密相关,应用场景复杂,加上我们团队能力的确有限,因此,历来都是被抱怨的重灾区。
当然,这一切只是原因,不是理由,所以,在过去的一年里,如何直面现实,从观念入手,更好的改进我们的服务,也就成了我无法逃避的问题。
以下内容,更多的是教训和体会,然后,感受最深的,就抽象成几句话。我自己做得也并不如意,和大家共勉。
主观即是客观
客户就是上帝呗,我一向如此,除了上帝犯错的时候 :)本质上,想想我们之所以有时候不把客户的意见和抱怨当一回事,很可能是在一些场景下,我们认为,客户的意见,是没有道理的! 比如:
这种错误都会犯,太奇葩了,就不能好好学习,多谷歌一下吗?
怎么使用,说明文档上都写了,也培训过好多遍了,群里都说过了,怎么就不能认真学习一下正确的打开姿势呢?!
网络挂了,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,就只是口号了
我的感觉是:
上策,自己不是用户,没有需求,创造需求也要上,非得逼自己成为用户。
中策,内部交叉。 开发同学自己不用,部门内部的同学不用么?我的A系统提供的服务,B系统能用么?不用也得逼他们用。。。小白? 最好~~~
下策,对着需求清单, 模拟业务场景,覆盖性测试。。。。
话说,这下策,我自己已经下了大半年了,俨然已经成功转型测试工程师。。。 :(
写到这里,回头再看,还是感觉更像务虚的鸡汤,对别人大概是没有多大用处,无所谓了,权当总结,时刻提醒,也算自产自销不是 ;)
顺道,推销一下个人公众号 “望月的蚂蚁”, 和技术完全无关。。。。 一切有趣的兴趣爱好等为主题。工作生活要平衡不是;)
相关文章推荐
- Atitit 软件采购与服务 实现的三种模式 企业软件V1.0模式=传统模式 1,定制开发类型, 主要特点为通用性差,需求独特。通常单项目价格高,多为政府采购或者垄断企业的大单。 2,标准产品轻
- 关于项目开发中的一些问题(回答waitu)
- 心得体会:关于开发效率和项目周期的问题
- 家用保健产品项目开发计划
- 关于软件需求开发和项目的范围管理
- 关于《软件开发的边界——管理成功的项目》
- 关于VS2005与EVC4.2的项目开发过程中的问题点滴
- 关于项目开发
- 关于软件开发项目任务的横向分解和纵向分解
- 【SD2.0大会】林锐:项目经理应介入开发 以免最终产品变“废物”
- 心得体会:关于开发效率和项目周期的问题
- [技术讨论]如何跟项目经理搞好关系,关于ajax的对话和开发工具
- [软件项目管理与测试论坛]技术是什么?技术永远是为产品服务
- 关于软件开发项目任务的横向分解和纵向分解
- 关于项目的开发和管理--与前辈们的谈话
- 关于开发效率和项目周期的问题(转贴)
- 关于产品项目的命名
- 关于公司在研发项目中理解平台和产品的区分看法
- 关于VS2005与EVC4.2的项目开发过程中的问题点滴
- 关于我们的思考——“项目开发”及读《人月神话》有感