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