02.准备工作

一灰灰blog技术管理技术管理约 5410 字大约 18 分钟

在中国传统文化中,有一句古老的谚语:“凡事预则立,不预则废”,这句话强调了在任何事务中,事前的规划和准备的重要性。对于我这样管理经验尚待提升,且未能拥有显著天赋优势的个体,面对新的挑战,提前进行细致的规划和准备显得尤为重要。

当前,我们正面临一个崭新的项目挑战,这个项目不仅要求我们团队展现出卓越的专业能力,更要求我们在组织和协调上达到新的高度。值得注意的,是甲方对我们团队的组长角色(包括产品、前端、后端、测试)提出了面试考核的要求,这无疑对团队的专业素质和综合能力提出了更高的标准。

在此,我必须指出,尽管这一要求在初次提出时,可能给人带来了一种被质疑或不被信任的错觉,但从专业角度看,这实际上是对项目成功完成的一种保障,也是对团队成员能力的一次全面审视。通过这样的面试考核,我们能够确保团队的每一个成员都具备足够的能力和专业知识,以应对项目中可能出现的各种挑战。

作为项目团队的一员,我们应该(但是我并不想)积极地接受这一挑战。 为了应对这次的面试,我提前做了一些准备,当然并不算充分;对于技术上倒是没有什么好担心的,个人则主要从项目背景和管理方法论上做一些调研。

1. 背景调研

原先,我并未打算详细阐述项目背景,因为目前我参与的这个项目,与典型的IT项目存在显著差异,并且涌现出许多意料之外的挑战。鉴于这些挑战在后续的分享中可能会以各种形式不断显现,我认为有必要阐明下此项目的具体形态。当然由于某些特殊原因,我将对于项目的相关背景会做一些脱敏处理;

业务类型: 垂直行业的ToB领域的电子商城

项目归属: 我所在的公司的兄弟企业的核心支柱

原运营方: 外部分供方

任务目标: 将项目从外部分供方完整的迁移到新的项目组,并按约定实现合同约定的各专项任务

当然再开始之初,上面这些背景中我只知道上面的业务类型 + 任务目标,其他的就不太清楚了;从现在往回看,这个背景中,最值得说的是这个项目的多方关系

项目组织关系

项目关系图
项目关系图

这个组织关系看起来有点怪,商城这个项目的所有权在孙公司B-1手中,他们自己又有产研团队,为啥不自己接,而是让我所在孙公司A-1来接产研呢?

两方面原因:

  1. 孙公司B-1 尝试自己承接,没接下来(题外话:这个项目业务及代码的复杂性确实有些离谱)
  2. 集团总部的直接任务下发,我所在的孙公司A-1的使命就是承接集团的信息化工作

再说句题外话,我所在的孙公司A-1愿意接这个项目吗? 答案是否订的,核心原因就一点,没有利益(即不赚钱,还责任多)

从项目的组织关系就可以看出,这个项目的工作模式好不起来,如何协调多方利益是个非常大挑战(还好我不是项目经理,不然我就直接投降了),对于技术管理而言,难受的就是外部协作沟通,后面会准备一篇专文来说我这一年的愉(bie)快(qu)体验

项目业务背景

一个垂直领域面向企业端的电子商城,再开始之处,对于这个商城我所有能获取到的信息就是借助搜索引擎找到的商城主站,本想体验一下这个商城有哪些功能板块,具体的业务形态,结果不让注册、未登录的用户只能看到商品详情,连价格也看不到...,所以再实际进场这个项目之前,我对它的了解两个概念 “TOB" + “电子商城”

以我个人的实际体会来说,建议大家再到一个新的项目组做技术管理之前,做好背景调研是一个非常重要的前置工作,比如大家都是这个领域的新手、你怎么快速脱颖而出? 若只有你是新来的、你怎么让别人信服你? 很,但是又很幸运,项目组内了解过这个项目的产研不过两三人,且了解得都不算多,所以我的小白表现并不算突出

基于我个人的实际经历,我强烈建议在加入一个新的项目团队并担任技术管理职责之前,进行充分的背景调研是至关重要的。这一步骤对于项目的顺利进行和您的个人发展都至关重要。

  1. 行业知识储备:在进入一个全新的领域时,首要任务是积累相关的行业知识和术语。这可以通过阅读行业报告、研究市场趋势、分析竞争对手以及与行业专家交流来实现。

  2. 项目历史了解:深入了解项目的历史发展,包括之前的成功案例和遇到的挑战,可以帮助您更好地理解项目的现状和未来的方向。

  3. 技术栈掌握:熟悉项目所使用的技术和工具,这对于技术管理者来说是基础。您需要了解这些技术的优缺点,以及它们如何适应项目需求。

  4. 团队动态分析:了解团队成员的技能、经验和工作风格,以及他们在项目中的角色和责任,有助于建立有效的沟通和合作。

  5. 业务流程理解:深入理解企业端电子商城的业务流程,包括供应链管理、库存控制、订单处理等,这是确保技术解决方案与业务需求相匹配的关键。

  6. 风险评估:识别潜在的风险点,并为可能出现的问题制定应对策略。

  7. 建立信任:作为新加入的成员,您需要通过展示您的专业知识、沟通能力和领导才能来赢得团队的信任。这可能包括提供有价值的见解、积极参与讨论和决策过程,以及在必要时提供指导和支持。

显然这一块我的工作做的并不合格,但幸运的是,团队中对该项目有深入了解的成员并不多。这意味着,尽管我是新手,但我的不足并没有立即凸显出来。然而,这并不意味着可以忽视背景调研的重要性。

2. 技术管理方法论学习

由于之前的管理经验不够成熟,或者说不成体系,因此再面对这个新的转机时,求助一下外援楼仔(他的公众号就是“楼仔”,干货满满),学习下相关的方法论,当时的目的比较简单,一个是应付甲方爸爸的面试,另外一个则是规划一下后面怎么带队

项目关系图
项目关系图

上图是之前准备的管理经验图谱,接下来会从两个方面进行细说

2.1 团队管理方法论

事先声明:市面上有很多的团队管理书籍及相关理论,以下内容仅个人看法、一家之谈,由于我个人经验有限、知识储备不足,如有错漏,误导之处,还请海涵

首先这里明确一点,团队管理并不局限于自己所在团队内的相关工作,从我们自己所处的阶层来说,可以区分为向上汇报、横向沟通以及向下管理,还有一个对外的沟通这里没有提及,后续补上

团队管理
团队管理

向上汇报

向上沟通对我个人而言是一个非常有挑战的事情,但是它又是对每一个技术管理者而言,不得不面对的事情

就我个人的感触而言,向上沟通主要有下面几个困扰:

  1. 对上层的天然敬畏,就像我们小时候怕家长、老师一样,能绕着就绕着,能不沟通就不沟通
  2. 不知道怎么聊,纯业务/技术的聊天会很干,聊闲话的又不会找主题,拿捏不好尺度和分寸
  3. 听不懂潜台词,这感觉是好多技术人的通病
  4. 不懂如何拒绝或影响上级的决策

上面是一些向上汇报的实际问题,前期的准备也不可能把所有的答案都搞到,或者说即便有标准答案在手,我也不一定执行得起来

因此再这一环节,准备先抓核心,为什么要向上汇报,目的是什么,以什么形式展开,有什么可以注意的事项,所以我准备的方法论比较简单,主要用于规范自己的行为

  • 目的:阶段性成果上报--邀功,寻求上级协助--请外援,大事拍板--不想背锅,获取上级才知道的信息--不当傻子
  • 形式:汇报时以PPT, 简明扼要的文档,准备充分的演讲方式进行; 闲聊时,没啥形式可说了
  • 注意:
    • 大方向的汇报,不拘泥于细节
    • 提问题时,梳理现状,问题是什么,我们给出的解决方案,希望得到的资源是什么
    • 汇报成绩时,有条理的列成绩,有数据效果支撑,有总结,有规划
    • 找老板关系的点汇报,而不是你关心的点

横向沟通

横向沟通主要是指和你同层级的技术管理、另外的团队之间的沟通协作,对于研发团队而言,跨团队的交流非常普遍,比如前后端协作,研发测试,研发产品都属于这一类

横向沟通的目的比较存粹,信息同步、目标拉齐

对于技术管理者而言,我们需要提前了解业务动向,知道产品准备做哪些规划,我们现在的资源是否足以应对产品接下来的计划,协作的团队是否可以跟上等等问题;切记在自己啥也不了解的情况下,接了需求,给团队带来无法交付的任务

其次对于技术管理者而言,横向沟通这里还有一个常见的场景就是帮助团队内的小伙伴和其他团队人员的协作,由于身份地位的问题,你组内成员的话语权没有你的大,他们在跨团队的推动中往往会遇到很多他们解决不了的问题,作为一个靠谱的领导者,不应对此视而不见、全部视为他们自己应该解决的问题,该站出来时就得站出来,能抗得住事、帮团队解决困难是建立个人领导力必不可少的要求

向下管理

团队内管理,可以说是技术管理的任务重心,从方法论中学到的核心点在于:

  • 建立权威:让人信服

    • 常见的形式: 早会、日报/周报等机制
    • 目的: 掌握团队的整体情况,了解每个人的工作饱和度,盯紧项目进度,提前评估风险
  • 维持信任关系:

    • 形式:通过1v1的聊天,了解团队内成员的诉求
    • 以身作则,言必行
    • 平等交流,信息透明
    • 日常活动中拉近关系
  • 培养备份

    • 找一个自己的backup,实现互助
    • 多认可,争取权益

2.2 项目管理方法论

关于项目管理的方法论将主要从项目流程管理与风险进度管理进行说明,关于这块的内容就不进行展开,有兴趣的小伙伴请关注第六篇

项目管理
项目管理

项目流程管理

  1. 建立需求池机制

主要目的是方便管理者了解短期、长期的产品项目规划,提前做好资源准备

其次需要针对需求池中的任务进行优先级划分,根据不同优先级来安排研发计划

  1. 做好提前沟通

对于技术管理而言,最好是提前与产品沟通需求说明书,判断是否再团队的可承受范围内,需求是否可以进行拆解,是否合理

这里对于技术管理提了一个要求,有足够的精力识别这些任务,可以判断它的合理性以及预估大致的工期,然后对大方向的讨论控制在私下的与产品的沟通中,避免在需求评审中发生争执,给团队内同学造成不好的影响

  1. 评审机制

建立研发流程中的通用评审机制,如需求方案评审,研发的反串讲,技术方案评审,代码review

通常而言,上面的几个评审中,需求方案评审不可缺少(除非是非常简单,显示样式的小调整,改个显示字段等),反串讲和技术方案的评审,一般是面向业务/技术复杂的多人协作的需求,一般来讲,有技术方案评审的需求,代码review也不建议省略

评审必然拉会,当会议一多,就会占据研发人员的工作时间,牢记一条 "小事大会,大事小会,重要的事不开会"

  1. 排期

需求评审之后,通常我们就需要出排期,但是我们往往只会将开发时间安排进来,一个完整的排期,正常需要

  • 开发
  • 自测
  • 联调
  • 上线
  • 回归验证

一个合理的任务排期,请确保要给自己预留足够的缓冲时间来应付各种突发状况(如请假、临时任务插入打断等)

除了上面排期需要考虑的事项之外,我们在安排进度计划时,需要考虑需求的优先级,将高优先级的先做,往前排,尽量优先保障

  1. 开发上线

发测试 -> 预发 -> 生产

  1. 效果追踪

这一环节通常是我们研发关注的较少的一点,需求上线之后,不出问题我们基本上就不会再花时间留意关注;但是作为一个技术管理而言,如何评估我们的产出、衡量我们的工作价值呢?

  • 再需求or项目上线之后,再跟踪一段时间,看下具体表现情况如何,收集相关数据指标
  • 通过效果的追踪反馈,一方面让我们能更清晰的了解业务,另一方面也可以认识到自己的工作价值

风险管控

风险管理是每位管理者必须面对的挑战,尤其是当遇到理解深度和合作态度各异的业务方时,这一挑战尤为显著。

1. 交付进度风险

  • 时间管理:在项目排期阶段,应当预留合理的时间缓冲,以应对潜在的延误。同时,需实施持续的项目进度监控,确保研发迭代按计划推进,从而降低整体交付风险。

若在项目执行过程中,发现由于评估过于乐观导致无法按期交付,应立即与业务方进行沟通,探讨是否可能调整交付时间表或简化需求。在极端情况下,可能需要重新分配资源或采取加班措施以确保项目按期完成。

  • 倒排期需求处理:对于具有严格时限的需求,需要细致地进行任务拆分和优先级排序。

优先保障高优先级任务的完成,而低优先级任务则相应推迟。确保至少具备最小功能集的按时上线交付能力,以便在意外情况发生时,能够有备选方案减轻损失。

  1. 交付质量风险
  • 功能质量保证:确保交付的功能无重大缺陷,且不会对主流程造成影响,这需要与测试团队建立良好的合作关系。
  • 安全保障:确保交付的功能不存在安全漏洞,保护系统免受潜在威胁。
  1. 其他非预期风险

在项目管理中,总存在不可预测的风险。对此,没有固定的应对策略,但需要提前做好心理准备,并制定灵活的应急计划。

  • 人员变动风险:如裁员或团队重组等情况,需提前规划人力资源的备份计划。
  • 需求变更风险:对于需求的变化,需要保持灵活性,及时调整项目计划以适应新的要求。
  • 突发事件应对:如员工请假、更高优先级任务的插入、多任务并行开发等情况,需制定相应的风险管理策略,以确保项目的顺利进行。

小结

程序员转型为技术管理者是一个重大的职业发展步骤,它要求你不仅要精通技术,还要掌握管理技能。 以下是一些来自于网络的建议,也风险给阅读本文的小伙伴

  1. 提升沟通技巧

    • 学习如何清晰、有效地与团队成员和其他部门沟通。
    • 练习将复杂的技术问题解释给非技术人员听。
  2. 培养团队领导能力

    • 主动承担更多责任,比如领导小型项目或指导新员工。
    • 阅读领导力相关书籍,参加相关的工作坊或研讨会。
  3. 了解管理理论和实践

    • 阅读有关管理的书籍,学习不同的管理风格和理论。
    • 考虑报名参加管理类课程或获得相关证书。
  4. 掌握项目管理知识

    • 学习项目管理的基础知识,包括如何制定计划、监控进度和管理预算。
    • 熟悉使用项目管理工具,如Microsoft Project、JIRA等。
  5. 增强商业意识

    • 理解公司的商业模式、市场定位以及产品战略。
    • 学习基础的商业和财务知识。
  6. 人员管理技能

    • 学习如何激励团队成员,进行绩效评估和职业规划。
    • 了解如何处理工作中的冲突和建立有效的团队文化。
  7. 关注技术和行业趋势

    • 持续学习新技术、工具和方法论,了解它们对团队和业务的潜在影响。
  8. 扩展人际网络

    • 与其他技术管理人员建立联系,交流经验和观点。
    • 加入专业组织和参与行业会议。
  9. 时间管理和优先级设定

    • 学习如何高效地管理自己的时间,平衡管理职责和技术工作。
    • 练习确定任务优先级,以有效达成目标。
  10. 获取反馈和自我反思

    • 定期向同事和上级寻求关于你管理和领导能力的反馈。
    • 定期进行自我反思,识别改进空间。
  11. 实践经验

    • 在当前的编程职位上寻找机会承担更多管理职责。
    • 参与跨部门的项目,增加管理经验。
  12. 心理准备

    • 准备好接受从纯技术角色到更多涉及协调和人际关系的工作的转变。
    • 调整心态,接受你可能不再有太多时间亲自编码的现实。

在项目管理的准备工作中,确实存在众多需要考虑的因素。对于初学者而言,试图同时关注所有细节可能会造成注意力分散,导致无法在任何方面达到最佳状态。因此,识别自己的弱点并集中力量突破最为关键。

基于此,我的准备策略聚焦于两个核心领域:项目背景的熟悉度以及管理方法论的掌握。

  • 项目背景熟悉

提前了解项目的业务环境、组织关系,能迅速发挥自己的能量

  • 管理方法论

掌握项目管理的核心原则和方法论,如敏捷管理、水平瀑布模型或混合方法等项目管理方法(上面没有细说),团队人员管理、梯度建设等

Loading...