一、与作者交流的总结

说来也是惭愧,没有太多的经验,先给大家贴两张图,看看大家能不能发现问题:



在最开始的时候,都处于Gaurav Gupta让我给材料的过程,因为我不是缺这个就是缺那个,根本说不清楚问题。然后交流的效率不是很高。我们能通一次邮件解决一次问题,是从我开始这样回邮件开始:

首先我是在邮件正文中加以问题描述,然后在附件中附录了以下信息:


当我有意识到我并没有提供专业和必须的信息时,我尽可能的让Gaurav Gupta能够了解到发生了什么。简单点来说,就是根据我的描述和文件,我确保能够恢复我当时所遇到的问题场景。也因此,我们后来的交流异常的畅快。


思考:我为什么最开始没有做到???  后来,我是怎么做到的???在我以后,如何向别人专业的描述一个问题场景???在请求别人帮助时,哪些材料是必须要提供的???  PS:比如说,SDE信息,这里面,你觉得应该包含什么内容???


二、与小组开发人员的交流

当时在组内遇到了一个关于自动生成代码的权限问题,我一直都跟大boss有不同的意见,但是,我一直没有说。然后,给安排的活儿,也没心去做。搞得这个问题一直存在,并且在jeddict这块还是个比较严重的问题。 后来,我想了好久,也是因为大boss有天下午过来跟我说了一下他对目前开发的想法,然后,晚上11点多了,还是决定跟他说说我的想法。

然而:为什么会发生这样的状况???事实证明,我的那个想法,才是对的,我为什么就是不说,然后耽误开发进度,也让问题一直存在???

我后来思考了,有以下的因素,导致了我最开始的不说,和我后来的说:

1,我不自信,因为大家都对大boss很信服,基本上就是让我们做什么,就做什么的那种。我理论上认为自己对,但又潜意识的觉得大boss不会错。

2,问题在那儿就在那儿呗,反正又不是我一个人的问题,大家这不都暂时解决不了嘛,我先忙完我手里的活儿,让大家折腾惦记去吧。(虽然有点无耻,但我深刻的反思了一下,确实有这个因素)

3,感觉这不是我该想的事儿,包括联系国外的作者,交流等等一系列的事儿,感觉都应该是大boss去做。还有一个就是,担心被无情的否决了,显得自己无极限low!

4,因为是属于新的架构技术研究,时间上没有对我很苛刻,我过得很舒服。

以上,都是我之前选择不说,沉默,甚至附和的原因。

5,既然我已经在这个小组里了,那么每出现的一个问题,我都有责任要去解决它

6,与其自己在这儿坚持自我,大家在那儿坚持大我,那还不如去说服或者被说服,至少心里没有“二心”,整个小组能够更加拧成一股绳的在做事儿

7,我认为,我真的没有理解错!


思考:以后,在发生我不认可别人的时候,我要怎么办???如果那个人是我一个很有权威的上司,我又该怎么办???  我想,交流还是必须的,但我可能需要想想办法提升和改善我的交流表达,更专业,更为让双方都接受!


三、思维方式的转变

也是在研究这个Jeddict的过程中,小组里一直有权限访问的问题,然后一直顺着自己当前所遇到的问题,和自己提出的需求去跟作者提问。但是,我后来一想,好像是我们的需求有问题,而不是人家的产品有问题。在这个过程中,我主要思考了两点:

1,做产品的时候,首先要思考的是,这个产品应该是什么样子,而不是我们能做成什么样子。  我们之所以提出那样的提问,就是因为我们一直陷入了自己当前所遇到的问题,而忽略了它正常的生产逻辑是什么。以至于,我们提出的要求,已经不合理了!

2,Jeddict的作者,至少是我现在还无法去比的。他所在的那个层面的技术人员,毕竟目前是比我们小组强,所以,我们能考虑到的问题,他们很有可能比我们想得更周全更多。为什么,我不先承认是我错了,而不是对方的疏忽和遗漏???  

 承认是自己错了,然后再结合到第一点去思考,最后,问题就被解决了! PS:通过和作者的进一步沟通,以及查阅权威说明(我的意思是,我再去看了相关技术栈定义说明,和一些文档),事实证明,确实是自己错了!


四、个人总结

Jeddict这个工具,包括和作者进行沟通,一直我都在做这个事儿,我自己的收获很多,但我怎么样,才能让其他的人,也收获到我的东西???

在这个过程中,发现自己也是一个比较执着的人,这些天,真的也是反常了。天天做测试,天天 根据作者的指引和解疑写代码。最终,还算是不负大boss所托,小组成员也都各有收获,挺好的!

posted on 2017-07-02 21:48  何红霞  阅读(166)  评论(0编辑  收藏  举报