[collect]为什么要跟进?如何来跟进一件事?


=Start=

原文链接为什么要跟进?如何来跟进一件事?

在我们的团队,我们很强调一个人对一件事的跟进能力,换句话说:也就是负责到底的能力。不管你是程序,是QC,是策划,或者还是客服,只要这件事由你发起或者大家商定后由你牵头来做,那你就是责任人,要负责到底。这里的“负责”二字,包括了在解决这件事过程中所需要的:人员协调、计划安排、进度控制、定期审核,内部信息互通,以及最终玩家反馈等诸多方面。

可以这样说,如果你能有机会跟进一件事,那你的个人权利在功能制作这一块就相当于小组负责人一级,组内的所有资源,你都可以使用。这样的机会很难得。

我们不想把每个人都培养成螺丝钉,我们想让每一个人都能把自己的潜力最大程度的发挥出来,所以,我们很强调给于一个人自由选择和自由作事的权利。但是,这是相对的,对于越有能力把握自己和把握整件事的人,我们给予的自由度越大,空间越大,而对于缺乏总体控制力、沟通协调能力以及跟进能力的人,他必须首先锻炼并展示出自己具备这样的能力,我们才会信任并交给他完全负责一件事。

起先,我想当然的以为,所有的人,只要是工作过几年的,都会理所应当具备对一件事负责到底、持续跟进的能力。但是,经过对我身边周围人的观察,我发现,大多数的人都无法作到有效、及时的跟进,而具备这种能力的人就会渐渐成为一个组织的核心。所以,我们从另一个方面来看的话,如果你还一直困惑自己为什么没有成为组织核心人员,没有成为骨干,没有升职,没有加薪,那么,你就要反思一下,自己有没有在有意识的培养自己这方面的能力。

那么,要如何来跟进一件事呢?

大体上,我觉得,跟进一件事,包括这几个主要的方面:

  1. 明确此事所涉及的人,以及每个人所负责的内容
  2. 协调整件事的时间计划,在哪个时间点完成哪些内容,安排各个人之间的前后衔接,尽可能并行的开展工作
  3. 对关键障碍点有清晰判断,在此障碍点的发生时间之前,就应该提前介入,及时排解;
  4. 各个部分完成后,要把整件事由头到尾的所有流程全部走通,走顺,对不合适的地方进行修正
  5. 在此事解决的过程中,要不断把当前进度周知应该了解进度信息的人,这包括:事情相关者,你的上级等。
跟进的过程中,经常遇到的问题可能是:
  1. 对困难估计不足,内容未按计划时间完成;
  2. 时间计划作得太紧凑,未留足够时间作全流程测试;
  3. 想当然的以为某人、某事没问题,没准备预案;
  4. 等等等等

总之,我认为,团队协作,特别是跨部门协作,一个最大的原则是:互不信任!没错,你没看错,我说的就是“不信任”,你需要不断地在各个关键时间点去跟某一方面的负责人去确认他作的进度,以及他作出来的东西的质量,很多的时候,不要相信他说了什么,而要看真正的结果,即使结果,有时光看也是无效的,你必须亲自体验,亲自使用,把自己真正放到使用者的环境下去真实模拟。

既然你是负责人,那么,你就再没有退路,在这件事的任何环节出了问题,都首先是你的问题,都是你没有控制、监督到位。所以,你就有足够的权利去关注好整件事的流程。

==

至此,我们再一起总结一下标题中提出的问题:为什么要跟进?如何来跟进一件事?

1.为什么要跟进一件事?

在工作中,如果你被安排来跟进一件事情,这体现了领导、同事对你的信任和肯定,这是一个难得的机会(但很多人却把这种机会视为负担)。即便前期你没有机会去单独跟进一件事情,但你也应该试着去培养自己的这种能力,因为大多数的人都无法作到有效、及时的跟进,所以具备这种能力的人就会渐渐成为一个组织的核心。如果你希望能升职、加薪,出任CEO,迎娶白富美,走上人生巅峰的话,试着去培养自己及时、有效的跟进一件事情的能力吧。

2.如何来跟进一件事?

明确这件事情涉及到的人,以及各自的责任;
协调整件事情的时间计划;
对关键障碍点要有清晰判断;
尝试快速走通所有流程,然后对不合适的地方不断进行修正;
在跟进事情的过程中,要不断把当前进度周知相关负责人,互通有无;

3.可能会遇到的问题?

对困难预估不足;
时间规划太过紧凑导致无法按时完成;
想当然……;

=END=

,

《“[collect]为什么要跟进?如何来跟进一件事?”》 有 17 条评论

  1. 领导力提升攻略
    https://zhuanlan.zhihu.com/p/26079454
    `
    什么是领导力(从复杂到简单)
    影响领导力的三个要素
    培养领导力的五种方法
      理解情境、凝聚共识。
      持续学习、打造专业。
      平衡利益、赢得尊重。
      创新突破、引领超越。
      携手时间、沉淀人品。
    管理和领导的相同与差异
    领导力的价值(高效、创新)
    `

  2. 技术leader的新项目初始检查清单
    https://wanqu.co/a/5485/2017-08-09-the-tech-leads-new-project-checklist-in-simple-terms.html
    https://insimpleterms.blog/2017/08/07/the-tech-leads-new-project-checklist/
    `
    每次开始一个全新的项目,都有一堆繁琐的“无聊”的事情得关照到:从开启新 git repo、设置 CI,到建立沟通渠道(JIRA、wiki、slack channel),再到与其他团队负责人互相认识。

    Tech Lead 应重在 lead,而不是 tech。花在非技术方面的时间更多,尤其是与人打交道(开会、说话、各种协调、计划等)。
    `

  3. 百度主任架构师谭待:如何让不带团队的程序员负责重大项目?
    https://mp.weixin.qq.com/s/xoNuKKoI0ZxR0n-HL65s4g
    `
    什么是“非职权的技术管理”机制呢?
    首先说一下什么是非职权的技术管理。这个词是我拼凑出来的,简单翻译一下就是:你负责一件事、领导一项技术、负责一个项目,但是所有的项目成员都不向你汇报。

    技术领域为何无法避免“非职权管理机制”?
    不管我们愿不愿意,一个非常可悲的事实是,非职权的管理方式在技术领域是基本不可避免的。原因很简单,职权一定和组织架构强相关,组织架构是公司和部门为了业务设定和优化的。
    我们都知道,互联网上唯一不变的就是变化,当新机遇新时代到来的时候,一定会跟现有的组织架构产生非常大的冲突。
    `

  4. 开发过程中沟通的禁忌
    https://mp.weixin.qq.com/s/G7fmFMRikNpwnWrlGqq3aA
    `
    如果你是非技术人员,我想说:
    请不要对技术人员说“这个需求很容易实现”

    如果你是技术人员,我想说:
    请不要对非技术人员说“这个需求技术上无法实现”

    很多时候,需求的真正限制,只取决于时间或者资源。

    正确的做法,绝不是急于否定需求。而是站在全局的角度:
    1、分析需求的核心是什么?将非核心的干扰先排除掉。
    2、将需求进行有效的拆分,尝试为每一部分找到一个最优解。
    3、根据优先级,分步骤完成需求,降低副作用。
    4、打开好奇心,切勿畏惧技术探索的困难

    还是一句老话,无论是技术还是非技术人员,解决沟通问题的关键,在于看待问题的方式。
    `

  5. 大话项目管理工具之Jira篇
    https://blog.csdn.net/happylee6688/article/details/38926791

    请教JIRA的使用经验~如果项目是外包开发,如何更好的管理我方的需求、缺陷和项目进度?正尝试使用JIRA进行管理,但无使用经验。
    https://www.zhihu.com/question/19621450

    公司推行jira,要求工程师每天log work,监督每个工程师有没有做满8小时的工作,想请教下各位国外IT界大牛是否有必要,是否有这样做的优秀的IT公司?
    https://www.zhihu.com/question/20829309
    https://www.zhihu.com/topic/19585568/top-answers

  6. 从技术到管理——角色转变
    https://mp.weixin.qq.com/s/yGxyKcQ3u2GK5U3nM0IU7A
    `
    五年前开始,我不再以一个纯粹的开发人员的职责来要求自己,或多或少会接触一些开发外的杂事,跟客户了解需求、跟其他开发兄弟协调任务、自己研究电子商务相关的知识、开始关注用户体验、关注ROI、关注SEO。

    接触的越多发现不懂的东西越多,这些东西也不是一头扎进代码里潜心修炼技术的人该做的,包括课外的阅读书目非技术类偏多,从一定程度上影响着我转变,与人打交道,从纯技术开发走向研发管理。

    角色转变是个坎,迈不过去就只能退回去搞开发,当然并不是说开发不好,技术大牛比比皆是。不管自身业务能力出众,还是临危受命充当救火队员,站上技术管理岗之后,第一个挑战就是从关注自己转变到关注团队、关注全局。
    `

  7. 如何跨部门沟通问题(给年轻工作者)
    http://www.youmeek.com/team-communication-issues/
    `
    如何和其他组成员沟通问题
      在去沟通之前,先思考下面问题,思考后再按下面流程跟进问题
        先阐述现在项目遇到了什么问题、问题背景
        阐述找他的原因
        了解他是怎么看待这个问题
          如果对方回答的内容超出你预设的范围,并且影响重大,你需要暂缓谈话,回来内部沟通,否则按计划沟通
    如何解决冲突
      如果对方阐述的点与自己观点冲突,则先收集对方观点,暂缓谈话,回来自行内部梳理和沟通
      梳理方法:
        根据对方的说法进行拆解,分出哪些是合理的,哪些是你认为不合理的
        合理的部分吸取经验,不合理的有针对性的反驳理由,并且尝试给出建议。然后准备好思路,再去沟通。
      沟通过程,对方不听取意见,直接拒绝谈话,则跟他直属直接沟通,说明当前情况,以及哪些是双方共同认可,哪些是冲突点。
      如果他直属上司也拒绝谈话,则让你的上司去跟他的上司沟通。
        你要跟你上司汇报以下内容:
          当前问题背景
          面临问题
          哪些点已经得到共同认可,哪些存在冲突
          冲突的理由,双方各自是以什么的样的观点来看待
    `

  8. 如何开展跨部门协作
    https://mp.weixin.qq.com/s/2gLzMdB2IWdq_QEYizcIqw
    `
    一、确定最高领导者
    二、发起协作请求
    三、沟通,沟通,还是沟通
    1、站在对方角度表述
    2、站在对方角度思考
    3、找对人
    四、冲突管理
    基本原则:任何一项冲突都有可能随时升级成大问题,无论大小。
    五、善用工具
    1、沟通工具
    2、工作任务工具(工具不在于用的多,而在于用的精。)

    六、复盘总结
    `

  9. 技术管理到底管什么
    https://mp.weixin.qq.com/s/QN1OKEFT3DiA82-OAp858Q
    `
    无论是春秋战国时候的丞相,还是三国时候的谋士们,技能大概分成两种:谋略和理事。谋略重在想办法,理事重在做事情。但凡有名的丞相谋士至少有一样特长,两者兼顾的自然是不世功勋唾手而来。

    丞相和谋士就是管理者,并且有别于将军们,他们是技术管理者。

    现代的技术管理者需要的核心技能仍然是这两样,只不过体现形式有些变化。
    谋略:技术架构搭建、新技术演进选型等,解决该做什么和怎么做的问题。
    理事:任务和人员协调、分配等,解决谁来做、哪件事先做的问题。

    第一个问题,虽说技术管理不能直接等价于管人,但实际上管理者大部分时间还是要和人打交道。那怎么处理人的问题呢?我的经验是,我们的目的应该是把事情做好,管人只是一种方式而已。

    第二个问题,技术管理者不写代码好心慌。
    管理者不应该是职级层面的上级,而应该是分工层面的决策和协调者。
    觉得不写代码会心慌的人,说明你把太多精力花在理事上了,谋略给丢了。实际上,在技术架构满足不了业务增长需求的时候,是需要你(和你的架构师一起)去拿出新的架构的;组员讨论几个方案拿不定主意的时候,也是需要你去做决策的。这些都是需要你平时花时间去不断丰富和充实你的技术的。否则一定是一将无能累死三军。
    你并不应该陷入与人沟通和处理杂事的漩涡中,而是应该抽时间出来保持自己的技术敏感度。管理者和普通员工在技术上的区别,在于和技术打交道的方式变了。普通员工是写代码,技术管理者应该是学习技术和思考架构。
    `

  10. 腾讯内部论坛热文:如何做一个小型公司的技术总监
    https://mp.weixin.qq.com/s/QXYi1KLhKcz1hPcJbIMEaA
    `
    资深程序员是团队中最强大的生产力,但往往被不合理的工作安排浪费掉。
    因此作为一个团队的技术的“头”,必须要有明确清晰的认识,把主要的事务性工作剥离出来。并且放弃大量的管理“权力”,以提高团队开发质量和效率为最主要的目标去安排自己的工作。

    一般来说技术总监其实会被要求做事实上是2个职位的工作:主程、项目经理(技术化)。
    因此必须明确此两个职位的工作任务分割。然后把项目经理的工作,安排给另外一个人做,当然其职称可能同样也得叫“技术总监”或“主程”,总之听起来越牛X越好。
    而真正的主程(技术总监)则应该投身于尽量多的技术工作中。而最重要的工作则是开发——生产代码和文档。

    主程的工作:

    一、开发
    开发的工作内容包括有:
    1、提出非功能性需求
    2、设计和修正软件架构
    3、难点代码(关键需求)的开发
    4、救火和杀虫

    二、培训
    培训的工作应该占用30%左右的工作时间。培训是稳定团队人员最重要的手段。也是提高团队开发效率最有效的手段。工具、过程、制度、奖惩,这些都代替不了程序员一行行的去写代码,最直接的方法是让他们做的更快更好,这些需要经验和知识的积累。
    1、代码审查
    2、技术方案评审
    3、学习与讲座

    三、管理
    管理的目标是提高绩效,如果和这个目标无关,而只是和“管理者”这个头衔有关的事情,最好丢给别人去做,包括那个头衔。
    1、绩效评定
    2、需求评定
    3、跨部门沟通
    4、进度审核和任务分派
    5、面试
    6、各种会议

    最后说说项目经理的工作:

    一、进度
    1、指定工作计划
    2、进度检查和告警
    3、工作总结和统计

    二、资源
    1、整合提供各种资源,如找DBA,IT,运维人员,硬件,SVN权限,测试环境,福利,周末的活动……
    2、面试:人员是最重要的资源,不是吗?
    3、资源谈判:往往是和老板谈判,让别人明白现在的真实情况。又一个吃力不讨好的差事,但是总需要人做。

    三、沟通
    1、需求评审:和需求方讨价还价,项目经理真是命苦啊……
    2、组织会议或者用其他方式通知信息给所有人:小喇叭、大喇叭、全服广播、世界频道……

    对于一个小型公司,职权,头衔,收益,往往会更加敏感。但是这些都不是让项目失败的理由。
    一颗叫程序员的种子说:长大了我就是叫管理者的树。这个错误的观念只会让这个种子永远无法发芽。
    软件开发是类似外科医生的行业,而不是血汗工厂,所以不需要手持皮鞭的经理,而需要仁心仁术的神医。
    `

  11. 大龄程序员技术管理路上的悲喜总结
    https://phpjieshuo.com/archives/147/
    `
    本文仅仅是对自己作为一个普通大龄开发者的一些技术与管理的总结。不喜勿喷。谢谢!

    一、系统架构
    二、网站劫持
    三、系统安全
    四、代码规范
    五、工作汇报
    (1)非核心开发员工
    (2)核心开发员工
    (3)主管级别员工
    六、职责清晰
    七、绩效考核
    八、上下关系
    `

  12. 如何写一封不用背锅的邮件?这些套路一定要懂!
    https://mp.weixin.qq.com/s/TC8qGFCQDnyrzkNVuwJxfA
    `
    # 邮件的一般格式
    1.说明来意(直奔主题)
    * 事情(关于X项目免费开发特批的申请)
    * 结果(关于XX严重bug处理完毕的说明)
    * 问题(关于XXX项目出现重大风险的说明)


    2.背景说明(短小精干,突出重点)
    对事件的说明背景要全面覆盖,确保认知是统一的,不要缺失信息,但不能冗长。

    3.存在风险/事件分析
    注意用编号来归纳,注重结果优先。如:
    * 资源投入风险:关于项目的外包资源无法及时投入项目
    * 项目延期的风险:因为XXX原因导致项目延期

    4.我方的解决建议/诉求
    重点注意:
    * 对于问题,特别要注意不要只抛问题,不提解决建议
    * 解决建议要与所列风险一一对应

    5.注明责任人、DDL或行动计划(明确人和时间)
    对于需要其他人负责的事项,需要有明确的责任人,明确的解决时间,或行动计划。

    6.其他技巧
    * 提醒收件人注意,如标题“重大风险”“重要事项!”“请务必关注”等;
    * 善用字号及色彩,如风险事项红色标注,重点关注内容加粗加大,但需注意,不要满篇红色或加粗加大;
    * 责任人及时间重点高亮标注。
    `

回复 hi 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注