zoukankan      html  css  js  c++  java
  • 你为什么不想向上汇报?

    汇报属于构建构建团队信息通道中的一环,也是必要的一环,1V1、项目汇报、部门月会都属于汇报的一种,前面有文章做了全局信息通道的概述:新晋总监生存指南终章——构建团队信息通道

    而在具体的时候依旧会有很多问题,这里还是以一个case开始。

    关于向上汇报

    最近出了一个case,一个leader表示下面的组长不喜欢主动汇报,导致了自己的焦虑和不安;而组长却认为其leader“管得太宽”、“管得太细”不利于团队发展,好巧不巧这两人私交又很好,问题被提出来又没有很好的解决,于是环境中弥漫着尴尬的气息。

    这是一个比较典型的问题,在我身上也发生过,可以发散一下:

    1)为什么我们不喜欢做向上汇报;

    不想做汇报的根本原因有三,首先可能是“不想被人评价”,特别是不对等的评价。

    上下级间天然有巨大的信息差,由于环境、角度因素会导致认知差异,极可能一个更宏观,一个更专业,两者之间没有绝对的对错,却有立场的不同。

    “我觉得我是对的”,而且我有足够的论据佐证我是对的,但这些论点或者论据可能会因为上下级关系或者角度的不同变得有些徒劳,这里举个例子:

    当你在考虑如何压制经理B的时候,你的leader正准备把公司做的更大,而当前人才却有一些掉队,在这个场景下,一旦leader发现你在贪小便宜,关注怎么分蛋糕,而不是考虑怎么把蛋糕做大的时候,考虑点不在一个层面,怎么说怎么错。

    向上汇报更像是做一次考试作文,你已经有文章列表的情况下,要去猜是哪套命题,如果文不对题,再好的文也是浪费,谁叫他给你发工资呢。

    所以,不对等的被评价、无意义只是比拳头大(比势能)的沟通是不想向上汇报的一个重要因素。

    第二个不想汇报的点,可能是“形式主义”,由于结构性的问题导致上层过于焦虑,这种焦虑引发的不安和失控感,需要大量的汇报、沟通来填补,这个时候的汇报可能只是一种安慰剂,但是这种安慰剂需要耗费团队极大的精力去应付,由于疲于奔命的应付汇报,反而导致本领域的事情没做好。

    最后一个重要的原因可能是:我不懂,我没准备好,我对我这个领域的事情依旧不专业,我不是专家,我认知不足,我不自信!

    专注领域认知不足(没有超过leader),是很容易被挑战被质疑的,而信息量、职位不对等带来的错误质疑,是不想汇报的两大重要因素;有时的汇报只是填补上层焦虑的安慰剂,而这个安慰剂的成本却不低,最终的结果就是我不想汇报!

    2)什么时候需要做向上汇报(向上管理),汇报什么内容。

    如团队沟通机制做得好,包括周报、月报、项目报告,已经能足够的涵盖平时的人事物,周常规预警,月常规预警,项目定点预警,汇报内容得益的情况下很难再出现团队黑盒、业务地图黑雾,如果依旧反馈汇报层面问题,往往是沟通引起的目标不统一。

    所以,我认为向上汇报依旧是团队信息通道的一环,机制运行的好,可以很大程度上解决上述问题,比如组长不知道汇报什么,那么把汇报的格式和内容标准化即可,如果这样依旧不能解决,那可能是leader预期不一致或者组长工作不合格。

    向上管理的诀窍是管理leader的预期,最后工作要满足这个预期,不然就要降低他的预期,并且让他接受这个预期,预期不一致就容易被打标签,这是很多人高开低走的一个原因。

    理论知识说了很多,接手一块产品工作快一个月了,最近也轮到我做汇报了......

    demo·如何做产品汇报

    PS:第一次做产品,实际效果也一般,大家看看笑一笑就行,后续会迭代

    前面说了,向上管理是管理leader的预期,我这里的情况是,花了大力气说服了产品负责人(技术的敌人)将一块产品团队交托给我,让我去跑“单元化”(简化DDD)模型,并且为业务架构师打样,正常的产品leader绝不会对此很放心的,于是这里产品leader的预期是:

    1)需要确信,抛开技术管理职责,我有足够精力投入,态度是认真的;

    2)我对这个领域的工作规划至少是“不会崩盘”的,如果能有一些变好的趋势,算是赚了;

    3)是不是作为产品会服从整体产品的安排,说白了就是在产品领域这个事情上将他当成leader,而不是之前的合作伙伴;

    为了打消其疑虑,安排双周汇报,这次汇报中主要工作是:人事物+数据分析。

    一、团队——人

    这里是重新接触了一个团队,需要对这个团队的结构做完整的分析:

    1)当前产品团队的人员组成、组织结构;

    2)当前产品团队服务的业务团队组织结构,以及彼此关系;

    在网上找了很多模型,没找到就自己画了一个定位模型,清楚当前产研在业务团队中是一个什么样的定位,上限最多达到什么样一个定位,有了这个定位便把产研的边界确定下来了,做什么事进退有据。

    3)整个业务+产研团队有哪些端口人物,彼此之间的看法是什么,这里包括合作公司,上下游链条梳理;

    二、团队——事

    1)画出业务全景图以及数据流;

    这个工作有点难,但是第一个版本不用太完善,逐步迭代即可,比如这样的:

    2)找出业务、团队当前核心关注的事项(问题)

    - 当前业务最重要三个问题

    - 产研内部最严重三个组织问题

    - 接下来最该做的一件事

    3)竞品分析,看看友商这个领域做到了什么程度

    三、团队-物

    1)当前团队有哪些资源;

    需要全面梳理,包括预算、资质、各种固件;

    2)当前业务,有哪些核心流程,运行情况如何;

    业务核心流程梳理,业务核心流程对应支撑控制流程梳理,业务流程相关机制、策略梳理;

    团队组织运行相关关键流程,重要机制梳理。

    四、数据建设情况梳理

    梳理团队数据建设情况,收集各部门(本业务团队>财务>其他业务团队>行政)数据需求,梳理完成情况,需要完成的问题点及解决方案。

    五、确定目标及节奏

    以上工作完成后,再跟小伙伴一起做一个SWOT分析,确定接下来一个季度的目标,将做事的节奏确定好即可。

    微信交流一下
    成都天府软件园招聘技术专家
  • 相关阅读:
    [转]unichar和初始化
    一些语言特性整理——预处理指令、volatile、标准预定义宏
    [开源项目]Adium——MAC下IM聚合客户端
    解决安卓7.0以后https抓不到包的问题
    MOSS2010 客户端对象模型开发(一)
    MOSS2010 客户端对象模型开发(四)
    MOSS2010 工作流不能自动启动问题
    MOSS2010 备份与还原小插曲
    Silverlight 5 研究(1)
    MOSS2010之大文件存储方案
  • 原文地址:https://www.cnblogs.com/yexiaochai/p/15045962.html
Copyright © 2011-2022 走看看