进入社会后,我们会发现当一个社会人很难,而当一个靠谱的社会人更难。 怎样才算是一个靠谱的社会人呢? 曾经听过这样一句话,描述什么样的人最靠谱——"凡事有交代,件件有着落,事事有回响。 刚开始听这句话的时候,只是觉得非常有道理,但是体会并不深刻,甚至有点狂妄地认为:做到这样有什么难的呢?但是真的到了自己的时候,才明白并不简单。 我尝试用自己的"血"的教训来翻译一下:有始有终,信息同步,不缺不漏,快速推进。 不是要教大家做人哈,只是把自己的一些经验感悟和大家分享。 一、有始有终 字面意思很简单,就是一件事,有开始就一定要有结束。 那么,关键是如何定义始?如何定义终? 始,可能很好定义,比如说从上司或者老板交代你的那一刻起。但是很多时候,事情是有优先级的,一般老板交代你的事情,有两种:一是重要但不紧急;一是紧急但不重要。对于后者来说,就算不重要,也是要马上执行的;而对于前者来说,就不一定了。所以选择何时开始也十分重要,并且前者还需要做到后面要讲的一点——不缺不漏。 如何定义终? 之前我一直认为,这件事情从我手上交出去以后,就算是结束了。这样的想法,更多的是抱有一种各人自扫门前雪的想法,认为事情虽然是我接手开始的,但是我已经交接给了下一位同事,至于事情是否结束,我就不需要关注了。 这样可能会让你省点事,但是对于你责任心的培养,对于你在上司或者老板面前建立信任是非常不利的。只要事情是你接手过的,不管是否是从你开始,你都要一直关注,直至它结束。而这里的结束,不是完成你这一部分就可以了,而是直到事情落地为止。比如一个功能的开发,你的工作并不是写完需求文档,提交开发就结束了,而是直到这个功能通过测试,通过你的验收为止。 二、信息同步 信息同步,就是信息的及时反馈。这里就涉及到一个沟通的问题,要主动积极地沟通。傅盛说过,工作中80%的问题都是沟通产生的。而沟通的本质就是做信息同步。 在和老板的沟通中,你需要同步的东西有两样:进度和风险。老板最关心的是进度,你什么时候能把事情完成。时刻同步进度,能让老板有一种天下尽在我掌控之中的安全感。同步风险,既是跟老板要资源,也是保护自己的方法。 很多同学包括我,有时候都会有一种奇怪的想法:就是当一项任务遇到困难或者阻碍要延期甚至停滞的时候,他们的做法不是跟老板说明风险,而是选择隐瞒,采用拖延策略,尝试自己解决。但是很多情况下,自己是解决不了的,因为自己能解决的话也就不可能会拖延和停滞了。 我猜测这种心里活动,可能是因为不想在老板面前留下无能的印象,所以做出非常努力的姿态。那么,解决不了就不全是自己的锅。但是你可能没有想过,老板只关心结果,不关心过程,完不成又不同步,你的锅更大。不仅要被贴上无能的标签,还要被架上不靠谱的人设。在和老板同步风险的时候,要描述清楚的事情有: 问题出在哪里? 你需要什么样的支持才能解决? 这些支持是否会影响其他项目的进度? 如果会,会影响哪些项目,影响有多大? 如果不会,有了这些支持以后,你能否按时完成? 在和平级的沟通中,不是每一个点都需要同步,你要判断下对方是否会关心这一信息。这可能需要一点经验,需要对公司的业务有足够的了解。 与平级沟通,最重要的是,只描述客观事实,不做主观的判断和情绪上的表达。因为人努力生活、工作的根本原因,除了钱就是要获得其他人的尊重和认可。如果你上来就给对方贴不良标签,肯定会激起对方的防御机制,最后只能激化矛盾。 有一个和程序猿沟通的段子,如果你要和程序猿说,你写的代码有Bug,你不能直接说:"你的程序有bug。"程序猿一听这句话就炸了,因为你这是对程序猿的一种否定,对他们最自豪的东西的一种亵渎。如果你换一种说法,这里的功能怎么不太好用呢,操作没有一点反应(描述事实),这个时候程序猿自己会说:"不会是我写的代码有Bug吧"。 在和下级的沟通中(还没带过人,观察学习得到的),最需要注意的是你不仅仅是要告诉他,他要去做什么,还要保证你们get到的点是一致的。不仅要同步任务信息,还要同步做这个任务的目的,要达到的目标和效果。如果可能的话,让对方复述一遍要做的事情,让他简单的表述一下自己打算如何进行,预估一下可能会遇到的困难和自己能采取的解决方案。 不过,这个在公司里面,可能很难实现,因为这样的领导不多,而能听到任务就能想到如何做,并且预估到问题的机灵下属也很少。但是至少要做的一点是,同步任务详情,也要同步做这件事的目的。因为,你告诉下属目的,而不是告诉他具体如何执行(其实,这样你也很累),他就能发挥自己的主观能动性,有创意的解决问题,你也能顺便对下属的能力做到心中有数。 三、不缺不漏 这个很简单,就是不论是老板、上司、同事给你交代的任务,一定要做到不缺不漏。我们总是高估自己的记忆力,永远记住一句话,好记性不如烂笔头。 当我刚入职的时候,老大就告诉我,一定要建一张自己的个人业务表,这张表格就是你以后记录自己负责的所有事情,推荐其进度的工作簿。 以我的工作表为例,作为产品经理,我的工作表有如下信息:需求优先级、需求名称、需求描述、需求类型、创建时间、需求进度(具体划分看个人)、开发对接人(分前端,后端)。 建立这张表格以后,下一步最重要的就是要维护它。养成凡事记录,每天更新进度的习惯(同步进度周期可以自己看情况)。有时候不仅仅只是更新进度,还要记录一些情况,比如说有一个需求卡住了,迟迟无法更新进度,那么你要去了解清楚问题点在哪里,然后记录下来,方便你追溯(记得去跟上司或老板同步风险)。 有很多时候,我们会遇到老板,上司或者其他同事提出的一些"非常为难"的需求,这个时候你可能会抱着一种侥幸心理:我先拖延一下,说不定过一段时间,他/她就忘记了呢? 然而,往往会被现实按在地上摩擦,然后被老板、同事贴上不靠谱的标签。当我们遇到这些令人为难的需求时,你想的第一件事不应该是逃避,而是要分析清楚: 1. 为什么要做这个需求,从公司的战略发展,产品规划,竞品和用户几个层面考虑。 2.如果要做这个需求,适用的场景是什么? 3.需要哪些资源,需要多少工期,风险是什么,对其他项目会造成什么影响? 当你把这些分析清楚,跟老板说明以后,老板自己会拿捏,如果他一定要做,那你也可以趁机索要资源和工期,这样你也不至于太发愁。如果他说暂时不做了(很少会说不做,哈哈哈),那你同样可以安心了。 四、快速推进 在明白这一点之前,我都没有推进进度的强烈意识。我潜意识地认为,作为产品经理,我只需要出需求、出原型、提交开发以后,我只需要偶尔跟进下进度就行。 但是这样的想法是错的。如果我的工作仅仅是到这一步的话,那就是对我自己不负责任,我自己把自己定位在了只画原型的原型产品经理上,而这是最简单的,也是最low的。如果我仅仅是这样,就会出现当上司或者老板问我某个需求进度的时候,我就是一脸懵逼的,这个时候不靠谱的标签就在我的脑门上贴上了。 一个需求,画原型写文档只是开始,推动程序开发,推动测试验收,直到产品验收落地以后,才算是完美落地,甚至可能还需要继续跟进这个需求功能的数据表现。只有这样,我们才能在老板问起的时候,能够说清楚这个需求目前的进度、问题点、解决方案和预计完成时间。