开发团队外部沟通协作

向上管理

向上管理是软件团队负责人的重要能力，有效的向上管理可以帮助你与上级建立互信关系，获得他们的支持和认可，更好地理解他们的期望和优先事项，从而更好地完成工作任务。此外，向上管理还可以帮助你在组织中获得更好的能见度和认可，为你的职业发展打下基础。我接下来根据一些场景，分享一些向上管理的理念。

       领导安排的任务很难完成，如何处理？当你的上级领导给你一个任务，了解后觉得不可能完成，或风险很高，不要直接和领导说不可行或相关风险和困难，这样会让领导觉得工作态度不对，给你的任务是让你克服困难来完成的，不是让你来质疑反对的，让领导觉得你在推脱，影响领导对你的信任。最好，先理解清楚老板的任务目标，下去后再仔细收集任务的相关信息，思考解决方案，如果的确不可行的就拿出相关证据，准备好材料和你已做的相关努力和领导汇报，并向领导求助。如果任务是可行的，但有较高的风险，则需要从不同角度出发分析出多套解决方案，给出相关的利弊分析和推荐方案，好让领导定夺。如果是任务完成的时间有问题，做好任务量的详细分析和团队人员的现有任务情况，给出理想或时间，或者调整现有任务的优先级，又或者把该任务再分解出优先级更高的子任务，在截止时间内完成这些优先级高的子任务，把这些方案汇报给领导，让领导依据充分的信息来做决定。如果要完成任务，所需的资源是你无法协调到的，则也向领导求助。领导是内行人，沟通相对简单方便，如果是外行则需要用更多的比喻来沟通。为了更好完成领导的任务，不仅只是了解任务目标，还需要了解相关背景、利益相关方信息和更深层次的目标，这样才可能提出更好的解决方案来直接满足深层次的目标。 如果最后出现，不管怎么努力，能沟通的都沟通过了，领导最后还是决定让你自己想办法克服各种困难完成任务，你也只能承诺最大的努力去完成，不要去违背领导的意愿，在后面做的过程中要更加高频给领导汇报该任务进展，好让其能及时把控。此时，我们也不要有太多的抱怨，每个人都有自己的局限性，领导可能看得更透，该沟通的都沟通过了，领导必然有自己的考虑，坚决执行即可。万一最后任务失败了，你也不会承担主要责任。 总之，领导给你的任务看上去无论多么困难或不可行，你要先详细了解该任务，深入分析和充分准备后，再与领导充分沟通，一旦做出决定后坚决执行。

       要经常主动地向领导反馈沟通。很多人怕和领导沟通，担心事多或打扰领导，只有领导主动询问或要求时，才会和领导沟通反馈。这样会让领导不能及时了解你负责的任务信息，潜藏的风险也不能及时发现。同时，你也不能及时了解领导的期望及其对任务进展的反馈，容易出现目标没能及时对齐，出现更多的问题。逐渐和领导之间信任与协作的问题越来越多，领导就会对你更多的关注和意见，反而事情更多。 怎么和领导及时沟通？每天通过日报进行汇报你的工作进展，主要汇报项目或任务完成的百分比，然后细说具体的进展，最后明天的计划。有求助的除了在日报里说明外，更需要和领导直接沟通。领导一般比较忙，一般下只关注百分比，除非对这个任务特别关心时，才会看具体的内容。每周还需要发周报给领导，周报内容和日报相似，但概括性更高，然后和领导约一个时间当面沟通，让 领导了解更多他关心的信息，同时也会得到领导反馈意见，及时调整，和领导目标对齐。月汇报和周汇报类似，只是概括性更强。工作中出现风险，除了自己努力尝试解决外，也要及时知会领导。工作中重要事情，多向领导报备。对拿不准的事情，准备好候选方案和相关分析后，向领导请示。也许有人觉得，这样会太打扰领导了，其实不然，很多领导都希望能充分了解下面的事情，而且很多汇报也都是文字类，领导可以灵活安排时间来看，甚至不看，只有重要的事情才会和领导当面沟通或打电话，这样基本没多少打扰。这样长时间下去，领导对你越来越信任，后面沟通和协调资源也都会越来越容易。总之，让领导对你或你负责团队做的事情了如指掌，协作时犹如臂使，而不是像一个黑盒子，需要领导不断地询问探索，毫无掌控感。

        领导是外行，如何沟通协作？领导是内行，沟通协作起来要方便得多，但如果是外行，沟通成本会大为增加，但我们的领导是无法选择的，除非你换公司或换团队。外行作为领导有其优势，他们更能跳出技术思维的局限看清目标，也有新的视角，一旦获得外行领导的信任，你的自主性也就更大，相互配合起来更默契。 话又说回来，没有绝对的内行，软件开发的技能很多，领导很难掌握所有技能。你的领导可能对后端很有经验，对前端人员而言领导就是外行，即使领导是全栈，对 CI 人员而言领导是外行，还有大数据、人工智能等等，所以没有绝对内行外行之分。和外行领导沟通，不要采用技术专业术语，只说各种方案的人力、时间成本、所需资源、可能存在的风险和交付质量等，不需要讲推断过程，如果你的领导有质疑，就通过打比方的方式给其解释。如果领导给任务的交付时间和资源很紧张，交付风险很大，你向其尽力解释后，领导在没法给你更多资源的情况下，还不对要求做调整，你只能表达尽力去做了。只要你是尽力的，即使后面结果不好，领导也没有理由向你追责的。还有一种情况，是领导给的任务不可行，你进行了充分分析后没办法做到，给领导也尽力做了解释后还要求你去想办法，你也只能去再多找找资料再想想办法，万一想出来。即使想不出来，过一段时间，领导看不到进展，也会相信是不可行的。一般通过多次磨合后，逐渐建立起信任，领导就更尊重你的反馈，作出适当的调整，更合理的决定。

        还有一些注意事项，不能越级汇报，只能越级投诉。如果有多个领导管你，出现了任务安排发生冲突，就给后面安排任务的领导说明情况，从而让他们先协调好。还有不要在公开场合质疑领导的决定，要私下沟通。发现问题，也不能默不作声，你有义务提供更多的信息和建议。如果该说的和该做的都做了，领导没有采纳，最后的结果明显是没有采纳你的意见而失败的，你几乎是没有责任的。否则，默不作声，导致失败的结果全体都得负责的。不管怎样，领导一旦决定后，是否认同都要坚决执行，不允许背后各种抱怨，阳奉阴违。如果领导的要求，超出你的岗位职责之外，比较过分时，那就委婉地拒绝。我们和领导是建立在工作基础上的相互尊重、相互支持的协作，不存在谁高谁低。只要把上面做得差不多，在一个常规的公司里，和领导的协作不会存在多大的问题。

不同部门沟通协作

作为软件开发团队的负责人，平时需要和各个部门外的人协作，经常会遇到推诿扯皮、责任转嫁、拖延等不配合问题，不可能事事找大领导协调，也不能每次靠和各个部门积累的人情关系去解决，迟早会用光，更不能放任不管，最后爆雷同归于尽。最好能清晰明确各个部门的职责，建立各部门认可的协作流程，这样能解决大多数问题。但在很多小公司，各个部门的具体职责常常模糊不清，并经常变动，相应的流程也很难建立起来。我根据我以前在小公司负责研发团队的经验，分享一下协作中出现的典型问题和解决办法，希望能有所借鉴。

我先说一下背景。我原先从事的小公司里，与研发主要协作相关的部门有销售部和技术部。销售部顾名思义负责市场的销售，会把客户的需求传达给研发。技术部负责售前和售后，由于我们公司原先主要从事的是硬件相关系统集成，逐渐才转到软件为主，所以技术部的人所具备的技能只会硬件设备集成相关的能力，只能在软件使用问题上做技术支持。研发部门主要就是软件开发人员和测试，有两个研发部， 我是其中一个研发部的负责人，直属领导就是老板。老板是销售出身，也对技术不了解。这种部门结构中，最明显的是缺少了产品经理的角色，负责把市场需求转化成研发需求。 我和另外一个部门的研发负责人曾多次向老板劝说，后来老板却从技术部找了一个人做产品经理，只不过不合格。可想而知，该产品经理无法做好需求，往往连基本的业务逻辑也走不通，所谓详细需求也都是从各个竞品抄过来拼在一起，根本不符合逻辑。因此，研发和产品经理相互扯皮指责，严重影响开发进度，开发中也不断返工，交付后使用体验很差。这样事情太多了，后来我这边和产品经理协商，他只提供客户的大致需求和一些资料，我这边的研发来做需求分析，这样矛盾才缓解了很多，交付的质量和效率也有了显著的提升。后来该产品经理跳槽了，公司再也没有补充新的产品经理，从此研发负责需求分析，市场负责收集客户需求，老板负责产品规划。另外技术部没有软件运维能力，我们也尝试过让技术部负责软件的部署安装，基本问题的排查，但效果也不好。一方面技术部多数人不愿意学习 linux 命令，个别人会了一些去尝试做的，经常犯错，出现问题又得研发用更多的时间去排查，还加上这些愿意学习的人容易跳槽，导致一直积累不下来，最后还是不得不由研发负责软件运维，他们只负责给用户进行使用上的技术支持。以上情况的形成，除了领导们对软件工程认知有限，更关键的是小公司资源有限，不愿意花更高的成本去招聘合格产品经理和技术运维人员，在微小公司里面很普遍，具有代表性。在此背景下，我会分享一下和销售部门、技术部门的协作时流程和常见问题处理。

 研发和销售部门协作时的流程和常见问题处理。销售经常会给一个粗略的需求，让研发评估开发时长、可行性等，显然，对研发而言是没法准确评估的，但和销售一起做需求分析是不值的，毕竟多数项目或需求不一定要做。我一般面对这个情况，会给一个开发周期的范围和风险高低，例如，回复 1 个月到 1 年。 如果销售觉得这种信息不够，需要详细准确地评估，就让他去补充需求，并向老板申请让研发和市场一起做需求，只有老板审批通过后，研发才能专门安排人花大量时间和销售一起做需求分析。在做需求分析时，研发要积极主动，需要多关注这些需求目标、解决的问题和使用场景，提出更合理的建议，否则，只是简单做到需求满足开发逻辑的话，很可能导致交付后，客户觉得不好用，又产生大量的返工，虽然责任上没在研发，但更多的工作量还是研发来承受。需求分析做完后，评估开发周期超过了销售要求时，可以和销售商量一下是否砍掉一些功能，或者让他和领导商量一下和别的开发任务优先级调整，这些还不行的话，尝试调整解决方案并充分说明相关的风险。确定要开发的话，销售向领导申请同意后，研发这边才安排开发，申请时需要销售前期的需求分析的输出文档作为邮件的附件，作为开发时的依据，减少后面的争议。开发过程中，如果需求要做一些改变，非必要不要接纳，尽量放在下一个迭代开发周期，非得变更，则评估出相关影响，让变更发起者提交给领导进行审批，审批同意后研发才接纳变更。后面交付时，销售和客户都满意还好，如果和他们期望的有出入，则可以作为后期的需求进行迭代开发，如果是追责，可以把原先需求分析文档和各个阶段的审批作为依据来沟通。 以上就是大致和销售协作项目开发的过程，要把握的原则是，研发和销售都是执行者，只有领导才是决策者，也是最终结果的承担者。销售和研发只能从自己的专业角度给出充分的信息和建议，一旦领导做出决策，两方都是坚决执行，没有必要去相互对抗。

一般给研发的需求，不合理的应该分为三类。第一种技术上完全不可行，例如，让你开发一个根据人的意念来控制手机操作的软件，你只能给出结论现在技术做不到。第二种现有技术团队做不到，例如，让开发一个类似 chatGPT 的人工智能，只有 10 个人的普通开发团队显然是不可能胜任的，这时就不能说技术上做不到，毕竟 chatGPT 已经有了， 最好是说要做到这些所需的资源和存在的风险，要招聘成百上千的人工智能工程师和相关世界著名的专家，要花多少亿买显卡等等，让他们一看这些所需资源就自然而然明白不可行。如果对方不信，还坚持要做，领导也同意让这么几个研发去做，那么也只能尝试去做了，一般过一段时间没有进展，就会停止的。第三种要求时间或资源不满足，例如，一个需求开发，根据研发现有的资源评估最少需要一周完成，但销售说客户要求必须 2 天时间内交付，这时说明 2 天内交付的概率和风险，以及造成的后果，研发和销售都没有好办法，就让领导沟通决策，如果领导决定要求研发 2 天内完成，那就坚决努力地去做，如果完成了当然好，如果没有并且整个研发团队也都是在尽力去做的，那么没人可以去追责研发。 

在和技术部门协作时，对方经常把自己职责范围的事情甩锅过来，这也是部门间协作常常发生的事情。技术部门负责向客户进行软件使用问题的解答和技术支持，技术人员接到客户的问题后，自己看也不看，就会转给研发说有 bug，让研发来解决，你问他他说自己排查过了。研发和客户详细沟通后，发现就是用户使用问题，并给客户进行了解答。偶尔发生，可以认为是误判，但次数多了就明显是甩锅。面对这种情况，研发和技术部协商了一个规则流程，当技术把客户问题转给研发时，要详细说明他做过什么尝试，然后才研发才去接手。累计在连续的 12 个月内超过 3 次误判，则研发就停止对该技术人员的任何技术支持，因此造成的后果也由该技术人员承担。我们加了这样的规则流程后，这种甩锅的事情明显减少。

以上是我以前负责研发部门时协作方面的一个分享，由于内容有限，不可能把协作中的各种问题及其应对都分享出来，但上面的也具有一定的代表性，希望有所启发。总之，部门间协作，我们需要遵循规范、明确职责，共同致力于达成目标。这不仅能够提高效率，还可以减少错误发生的概率。因此，我们应该积极思考和实践，以期能够建立和优化相互协作流程。当然，在遇到紧急情况时，也需要果断行动，不能因流程形成阻碍，本末倒置，但也要事后补走流程。