我希望大家是什么样子的

  之前在乐视的时候我问过我们飞哥:你希望大家是什么样子的。飞哥人特别好,因为在饭桌上,他把所有的人都说了一遍,说需要你,也需要他。需要各种各样的人。我在乐视过得蛮滋润,我可以按照自己希望的样子进行发展。这是建立在我这么多年磕磕碰碰,有了很多思考和自己想做的事情的基础上。但是我也很想知道,我怎样能领导让更满意。很多刚毕业的同学,更想得到很多的引导。所以我现在就在思考这个问题。

  我希望大家有很多想法,大家一起拿出来探讨。我希望大家可以遇到事情或者有什么思路可以自己主动找我商量,我觉得这是对我的尊重和认可。我希望我有什么问题或者团队有什么问题,大家看到了或者想到了能告诉我,大家一起想办法。乐于分享,有团队精神。我希望这些是团队的共性。这和每个人的性格没有关系,更多的是一种团队合作沟通的技巧。

  性格方面,我觉得遵从天性就好。如果非说要有点共性,那么我希望是感恩之心。可能其他人有自己的生活方式,但就我自己的经验而言,这在整个人生中,工作上、生活上都是成功的关键。为什么我家娃都马上要上小学了,我家男神来我们公司附近,我可以团队聚餐不去,一定要和男神一起吃饭。关系好是因为两个都是知道感恩的人,感恩上苍,感恩彼此,愿意为对方多付出一点让对方更幸福。结果,自己收获了更多的幸福。我有很多的朋友,干什么事情都不愁没人帮忙,那是因为自己这样的气质,周围聚集的也都是一些仗义的人。仗义的基础就是感恩之心。世界上最遥远的距离是每次我需要你,都不知道你在哪里。爱情不一定会败给物质,却一定会败给我需要你的时候你都不在。工作也是一样的,背道而驰路会越走越窄。

  之前在乐视有次开会,我家微微一笑很倾城的男神老大说刚刚面试了一个女孩子特别满意。满意到什么程度呢,跟晓静似的。但是老大看了我一眼,看我听了不是特别高兴,就继续说这个女孩子什么学校的,有多么优秀。我也就是听听,不太高兴因为我觉得我家男神老大跟王子一样,特别完美的一个人。完美的人其实有很多,但是我从来没有觉得他们是一类人。在我心里,独一无二,不会觉得跟谁很像。我对自己也是一样,我觉得自己是独一无二的,听自己崇拜的人说自己只是一类人,多少有些失落。所以现在我自己带团队了,我有时间会去发掘每个人的个性,相信每个人都是优秀的、独一无二的。

  

沟通

  沟通分为团队内的沟通和团队间沟通。

  团队内沟通对于重要的事情,如果不是一句话两句话能说清楚的,就算文字、消息沟通过,最好也要口头沟通一下。因为信息接受者有可能因为事情多忘了或者理解的不对。口头沟通为主,消息主要记录和留证。为什么这么做呢?程序员大多数是听觉敏感型的。心理学按照感官敏感度将一般人分为视觉敏感型和听觉敏感型。视觉敏感型的人对视觉的东西更敏感,精力更集中,记忆也更深刻。更擅长处理图像。听觉敏感型对声音更敏感,更擅长语言文字。而我们从小到大学校学的东西基本是语言文字。能来咱们公司的,都是被读书坑掉的一代,听觉敏感的居多。

  团队外,我们是一个team。团队外的人不管找谁询问任何事情,都绝对不能因为不是自己负责的模块而怠慢。自己处理不了,可以带人家去找可以处理的人。我们需要给团队外的人的感觉是:找谁都是一样的,不用有所顾忌。

  技术、沟通、态度哪个更重要。这实际上是一个很没有价值的问题,因为这三者其实是一个东西,叫能力。任何一个不好,都是能力问题。我在东软的时候,是很受欢迎的小翻译。真的因为我是一年就过日语一级的天才,所以日语好的不得了吗?怎么可能,人家都是专业学了很多年,日本留学回来的。但是其他的翻译是字面翻译者。我是技术出身的,我理解他们实际上是在说什么,所以更好沟通。其实不懂日语都可以沟通。我在日本出差的时候,我一个同事不会说日语,有个日本的“矢野”不会说中文。他两天天都不用翻译,就用手比划,纸上画,无障碍。技术是什么,比如对咱们来说JAVA是技术,好吧,但是别忘了JAVA最根本是一种语言,是用来表达实现东西的。技术很牛逼,写了一堆漂亮代码,但是做了系统边界外的事情,后患无穷,还不如不写。所以沟通要更关键一些。而有效沟通的最好方式就是态度。

 

我自身要做的事情

  我应该是规划者和决策者,不是执行者。我更不需要是最好的执行者。比较喜欢的美剧是《神盾局特工》和《罪恶黑名单》。不管什么剧,指挥官绝对不是电影里最身手不凡,耍枪耍的最帅的。也不是任何一方面的专家。他是将整个团队凝结到一起,让大家可以成为最酷最帅的执行者的那个人。他的职责是制定靠谱的任务。

  从战略和架构上,我需要定义好系统的边界、定义好系统的核心思想。这样,系统就有了方向感,随着时间推移,系统就能形成自己的灵魂。咱们邮件的签名:我们的职责是:打造可靠、高效的交易系统。这就是系统最抽象的核心思想。

  我要帮助大家提出问题。比如每个需求的时候,大家都应该问自己5个Why:这件事情有没有超越这个系统的边界?这是根据当前模型和代码中的一组特定关系作出的权宜之计呢,还是反映了底层领域的某种轮廓?我们做这件事情的收益是什么?如果需求比较大,那么每个阶段的里程碑是什么?有没有更好的解决方法?

 

重构

  相信团队里现在很多人有这种疑问。我们现在做重构,做好了,又有变化,怎么办?我的回答是:重构就是需要是一个持续改变的过程,要保持鲜活,要拥抱变化。《极限编程》的核心思想就是要拥抱变化,要迭代。持续变化不可怕,风险是可控的。可怕的是长期不维护,大家对实现细节都淡忘的代码突然要有一个改变。《领域驱动设计》里有一段话:

  通过重构得到更深层理解是一个持续不断的过程。人们可能会发现一些隐含的概念,并把它们明确地表示出来。有些设计部分变得更有柔性,或许还采用了声明式的开发风格。开发工作一下子到了突破的边缘,然后开发人员跨越这条界限,得到了一个更深层的模型,接下来又重新开始了稳步的精化过程。

  重构设计的原则说:至少要有两个步骤的前瞻性。所以,两个步骤之后还是要变。从模型到代码,都是一个精化过程,不要怕变。

 

  重构模块的划分。这一块确实是经过大家很多的思考得到的,一段时间内是稳定的。比如核心现在划分为正向、逆向、查询、命令。这是怎么划分的呢?正向和逆向是我们的业务。我们的业务再怎么变,抽象出来也逃离不出这个范围。业务执行操作。所有的操作都可以抽象为查询和命令。查询和命令为什么要分开呢?水平切分,避免副作用。这也是分布式服务和微服务的本质。

    

  今天太晚了,未完待续……

 

跑题时间

  女孩子心里想的就是:愿得一心人,白首不相离。男孩子:……

略心塞

posted on 2018-01-10 23:45  编程一生  阅读(2537)  评论(9编辑  收藏  举报