向上管理
向上管理是软件团队负责人的重要能力,有效的向上管理可以帮助你与上级建立互信关系,获得他们的支持和认可,更好地理解他们的期望和优先事项,从而更好地完成工作任务。此外,向上管理还可以帮助你在组织中获得更好的能见度和认可,为你的职业发展打下基础。我接下来根据一些场景,分享一些向上管理的理念。
领导安排的任务很难完成,如何处理?当你的上级领导给你一个任务,了解后觉得不可能完成,或风险很高,不要直接和领导说不可行或相关风险和困难,这样会让领导觉得工作态度不对,给你的任务是让你克服困难来完成的,不是让你来质疑反对的,让领导觉得你在推脱,影响领导对你的信任。最好,先理解清楚老板的任务目标,下去后再仔细收集任务的相关信息,思考解决方案,如果的确不可行的就拿出相关证据,准备好材料和你已做的相关努力和领导汇报,并向领导求助。如果任务是可行的,但有较高的风险,则需要从不同角度出发分析出多套解决方案,给出相关的利弊分析和推荐方案,好让领导定夺。如果是任务完成的时间有问题,做好任务量的详细分析和团队人员的现有任务情况,给出理想或时间,或者调整现有任务的优先级,又或者把该任务再分解出优先级更高的子任务,在截止时间内完成这些优先级高的子任务,把这些方案汇报给领导,让领导依据充分的信息来做决定。如果要完成任务,所需的资源是你无法协调到的,则也向领导求助。领导是内行人,沟通相对简单方便,如果是外行则需要用更多的比喻来沟通。为了更好完成领导的任务,不仅只是了解任务目标,还需要了解相关背景、利益相关方信息和更深层次的目标,这样才可能提出更好的解决方案来直接满足深层次的目标。 如果最后出现,不管怎么努力,能沟通的都沟通过了,领导最后还是决定让你自己想办法克服各种困难完成任务,你也只能承诺最大的努力去完成,不要去违背领导的意愿,在后面做的过程中要更加高频给领导汇报该任务进展,好让其能及时把控。此时,我们也不要有太多的抱怨,每个人都有自己的局限性,领导可能看得更透,该沟通的都沟通过了,领导必然有自己的考虑,坚决执行即可。万一最后任务失败了,你也不会承担主要责任。 总之,领导给你的任务看上去无论多么困难或不可行,你要先详细了解该任务,深入分析和充分准备后,再与领导充分沟通,一旦做出决定后坚决执行。
要经常主动地向领导反馈沟通。很多人怕和领导沟通,担心事多或打扰领导,只有领导主动询问或要求时,才会和领导沟通反馈。这样会让领导不能及时了解你负责的任务信息,潜藏的风险也不能及时发现。同时,你也不能及时了解领导的期望及其对任务进展的反馈,容易出现目标没能及时对齐,出现更多的问题。逐渐和领导之间信任与协作的问题越来越多,领导就会对你更多的关注和意见,反而事情更多。 怎么和领导及时沟通?每天通过日报进行汇报你的工作进展,主要汇报项目或任务完成的百分比,然后细说具体的进展,最后明天的计划。有求助的除了在日报里说明外,更需要和领导直接沟通。领导一般比较忙,一般下只关注百分比,除非对这个任务特别关心时,才会看具体的内容。每周还需要发周报给领导,周报内容和日报相似,但概括性更高,然后和领导约一个时间当面沟通,让 领导了解更多他关心的信息,同时也会得到领导反馈意见,及时调整,和领导目标对齐。月汇报和周汇报类似,只是概括性更强。工作中出现风险,除了自己努力尝试解决外,也要及时知会领导。工作中重要事情,多向领导报备。对拿不准的事情,准备好候选方案和相关分析后,向领导请示。也许有人觉得,这样会太打扰领导了,其实不然,很多领导都希望能充分了解下面的事情,而且很多汇报也都是文字类,领导可以灵活安排时间来看,甚至不看,只有重要的事情才会和领导当面沟通或打电话,这样基本没多少打扰。这样长时间下去,领导对你越来越信任,后面沟通和协调资源也都会越来越容易。总之,让领导对你或你负责团队做的事情了如指掌,协作时犹如臂使,而不是像一个黑盒子,需要领导不断地询问探索,毫无掌控感。
领导是外行,如何沟通协作?领导是内行,沟通协作起来要方便得多,但如果是外行,沟通成本会大为增加,但我们的领导是无法选择的,除非你换公司或换团队。外行作为领导有其优势,他们更能跳出技术思维的局限看清目标,也有新的视角,一旦获得外行领导的信任,你的自主性也就更大,相互配合起来更默契。 话又说回来,没有绝对的内行,软件开发的技能很多,领导很难掌握所有技能。你的领导可能对后端很有经验,对前端人员而言领导就是外行,即使领导是全栈,对 CI 人员而言领导是外行,还有大数据、人工智能等等,所以没有绝对内行外行之分。和外行领导沟通,不要采用技术专业术语,只说各种方案的人力、时间成本、所需资源、可能存在的风险和交付质量等,不需要讲推断过程,如果你的领导有质疑,就通过打比方的方式给其解释。如果领导给任务的交付时间和资源很紧张,交付风险很大,你向其尽力解释后,领导在没法给你更多资源的情况下,还不对要求做调整,你只能表达尽力去做了。只要你是尽力的,即使后面结果不好,领导也没有理由向你追责的。还有一种情况,是领导给的任务不可行,你进行了充分分析后没办法做到,给领导也尽力做了解释后还要求你去想办法,你也只能去再多找找资料再想想办法,万一想出来。即使想不出来,过一段时间,领导看不到进展,也会相信是不可行的。一般通过多次磨合后,逐渐建立起信任,领导就更尊重你的反馈,作出适当的调整,更合理的决定。
还有一些注意事项,不能越级汇报,只能越级投诉。如果有多个领导管你,出现了任务安排发生冲突,就给后面安排任务的领导说明情况,从而让他们先协调好。还有不要在公开场合质疑领导的决定,要私下沟通。发现问题,也不能默不作声,你有义务提供更多的信息和建议。如果该说的和该做的都做了,领导没有采纳,最后的结果明显是没有采纳你的意见而失败的,你几乎是没有责任的。否则,默不作声,导致失败的结果全体都得负责的。不管怎样,领导一旦决定后,是否认同都要坚决执行,不允许背后各种抱怨,阳奉阴违。如果领导的要求,超出你的岗位职责之外,比较过分时,那就委婉地拒绝。我们和领导是建立在工作基础上的相互尊重、相互支持的协作,不存在谁高谁低。只要把上面做得差不多,在一个常规的公司里,和领导的协作不会存在多大的问题。
不同部门沟通协作
作为软件开发团队的负责人,平时需要和各个部门外的人协作,经常会遇到推诿扯皮、责任转嫁、拖延等不配合问题,不可能事事找大领导协调,也不能每次靠和各个部门积累的人情关系去解决,迟早会用光,更不能放任不管,最后爆雷同归于尽。最好能清晰明确各个部门的职责,建立各部门认可的协作流程,这样能解决大多数问题。但在很多小公司,各个部门的具体职责常常模糊不清,并经常变动,相应的流程也很难建立起来。我根据我以前在小公司负责研发团队的经验,分享一下协作中出现的典型问题和解决办法,希望能有所借鉴。
我先说一下背景。我原先从事的小公司里,与研发主要协作相关的部门有销售部和技术部。销售部顾名思义负责市场的销售,会把客户的需求传达给研发。技术部负责售前和售后,由于我们公司原先主要从事的是硬件相关系统集成,逐渐才转到软件为主,所以技术部的人所具备的技能只会硬件设备集成相关的能力,只能在软件使用问题上做技术支持。研发部门主要就是软件开发人员和测试,有两个研发部, 我是其中一个研发部的负责人,直属领导就是老板。老板是销售出身,也对技术不了解。这种部门结构中,最明显的是缺少了产品经理的角色,负责把市场需求转化成研发需求。 我和另外一个部门的研发负责人曾多次向老板劝说,后来老板却从技术部找了一个人做产品经理,只不过不合格。可想而知,该产品经理无法做好需求,往往连基本的业务逻辑也走不通,所谓详细需求也都是从各个竞品抄过来拼在一起,根本不符合逻辑。因此,研发和产品经理相互扯皮指责,严重影响开发进度,开发中也不断返工,交付后使用体验很差。这样事情太多了,后来我这边和产品经理协商,他只提供客户的大致需求和一些资料,我这边的研发来做需求分析,这样矛盾才缓解了很多,交付的质量和效率也有了显著的提升。后来该产品经理跳槽了,公司再也没有补充新的产品经理,从此研发负责需求分析,市场负责收集客户需求,老板负责产品规划。另外技术部没有软件运维能力,我们也尝试过让技术部负责软件的部署安装,基本问题的排查,但效果也不好。一方面技术部多数人不愿意学习 linux 命令,个别人会了一些去尝试做的,经常犯错,出现问题又得研发用更多的时间去排查,还加上这些愿意学习的人容易跳槽,导致一直积累不下来,最后还是不得不由研发负责软件运维,他们只负责给用户进行使用上的技术支持。以上情况的形成,除了领导们对软件工程认知有限,更关键的是小公司资源有限,不愿意花更高的成本去招聘合格产品经理和技术运维人员,在微小公司里面很普遍,具有代表性。在此背景下,我会分享一下和销售部门、技术部门的协作时流程和常见问题处理。
研发和销售部门协作时的流程和常见问题处理。销售经常会给一个粗略的需求,让研发评估开发时长、可行性等,显然,对研发而言是没法准确评估的,但和销售一起做需求分析是不值的,毕竟多数项目或需求不一定要做。我一般面对这个情况,会给一个开发周期的范围和风险高低,例如,回复 1 个月到 1 年。 如果销售觉得这种信息不够,需要详细准确地评估,就让他去补充需求,并向老板申请让研发和市场一起做需求,只有老板审批通过后,研发才能专门安排人花大量时间和销售一起做需求分析。在做需求分析时,研发要积极主动,需要多关注这些需求目标、解决的问题和使用场景,提出更合理的建议,否则,只是简单做到需求满足开发逻辑的话,很可能导致交付后,客户觉得不好用,又产生大量的返工,虽然责任上没在研发,但更多的工作量还是研发来承受。需求分析做完后,评估开发周期超过了销售要求时,可以和销售商量一下是否砍掉一些功能,或者让他和领导商量一下和别的开发任务优先级调整,这些还不行的话,尝试调整解决方案并充分说明相关的风险。确定要开发的话,销售向领导申请同意后,研发这边才安排开发,申请时需要销售前期的需求分析的输出文档作为邮件的附件,作为开发时的依据,减少后面的争议。开发过程中,如果需求要做一些改变,非必要不要接纳,尽量放在下一个迭代开发周期,非得变更,则评估出相关影响,让变更发起者提交给领导进行审批,审批同意后研发才接纳变更。后面交付时,销售和客户都满意还好,如果和他们期望的有出入,则可以作为后期的需求进行迭代开发,如果是追责,可以把原先需求分析文档和各个阶段的审批作为依据来沟通。 以上就是大致和销售协作项目开发的过程,要把握的原则是,研发和销售都是执行者,只有领导才是决策者,也是最终结果的承担者。销售和研发只能从自己的专业角度给出充分的信息和建议,一旦领导做出决策,两方都是坚决执行,没有必要去相互对抗。
一般给研发的需求,不合理的应该分为三类。第一种技术上完全不可行,例如,让你开发一个根据人的意念来控制手机操作的软件,你只能给出结论现在技术做不到。第二种现有技术团队做不到,例如,让开发一个类似 chatGPT 的人工智能,只有 10 个人的普通开发团队显然是不可能胜任的,这时就不能说技术上做不到,毕竟 chatGPT 已经有了, 最好是说要做到这些所需的资源和存在的风险,要招聘成百上千的人工智能工程师和相关世界著名的专家,要花多少亿买显卡等等,让他们一看这些所需资源就自然而然明白不可行。如果对方不信,还坚持要做,领导也同意让这么几个研发去做,那么也只能尝试去做了,一般过一段时间没有进展,就会停止的。第三种要求时间或资源不满足,例如,一个需求开发,根据研发现有的资源评估最少需要一周完成,但销售说客户要求必须 2 天时间内交付,这时说明 2 天内交付的概率和风险,以及造成的后果,研发和销售都没有好办法,就让领导沟通决策,如果领导决定要求研发 2 天内完成,那就坚决努力地去做,如果完成了当然好,如果没有并且整个研发团队也都是在尽力去做的,那么没人可以去追责研发。
在和技术部门协作时,对方经常把自己职责范围的事情甩锅过来,这也是部门间协作常常发生的事情。技术部门负责向客户进行软件使用问题的解答和技术支持,技术人员接到客户的问题后,自己看也不看,就会转给研发说有 bug,让研发来解决,你问他他说自己排查过了。研发和客户详细沟通后,发现就是用户使用问题,并给客户进行了解答。偶尔发生,可以认为是误判,但次数多了就明显是甩锅。面对这种情况,研发和技术部协商了一个规则流程,当技术把客户问题转给研发时,要详细说明他做过什么尝试,然后才研发才去接手。累计在连续的 12 个月内超过 3 次误判,则研发就停止对该技术人员的任何技术支持,因此造成的后果也由该技术人员承担。我们加了这样的规则流程后,这种甩锅的事情明显减少。
以上是我以前负责研发部门时协作方面的一个分享,由于内容有限,不可能把协作中的各种问题及其应对都分享出来,但上面的也具有一定的代表性,希望有所启发。总之,部门间协作,我们需要遵循规范、明确职责,共同致力于达成目标。这不仅能够提高效率,还可以减少错误发生的概率。因此,我们应该积极思考和实践,以期能够建立和优化相互协作流程。当然,在遇到紧急情况时,也需要果断行动,不能因流程形成阻碍,本末倒置,但也要事后补走流程。