我注意到,在一系列软件/技术公司中,特别是在B2B /企业公司中,销售/营销与工程/产品管理在地理位置上相距甚远,这在一系列软件/技术公司中经常出现高管人员对期望的错位。我们称之为 软件开发熟食柜台问题. 这里有一些症状,根本原因和一些减少相互沮丧的想法。

在房屋收益方面…

高管,特别是来自组织非技术部门的高管,将其角色视为思考新的方式来增加收入和增长。他们是对的。机遇,客户要求和可能的合作伙伴关系不断出现。但是,很容易忘记 几乎所有新产品都需要工程设计 –加上公司内其他许多人的参与–产生收入。

同样,销售和业务开发团队(尤其是在企业公司中)因进行大笔交易而被聘用并获得报酬和奖励。实际上,我们会解雇没有达成重大交易的企业销售人员。 (一等奖是凯迪拉克…)  重大交易可占本季度收入的很大一部分,并且通常包括对特殊功能或定制服务的要求-因此强烈希望销售团队能够准确地交付要求的产品。

与产品经理或开发团队相比,收入方面的高管和销售团队在开发渠道上花的时间要少得多。实际上,许多收入方面的领导人都不知道目前正在建设什么。这使我们进入了这一推理链:

  • “我不记得开发流程中的内容。”
  • “我对工程/产品的了解不多,除非他们迟迟未能兑现承诺。看起来不像他们’re working that hard…”
  • “这是一个巨大的机会,目前价值$ M加上后续收入。”
  • “因此,工程学应该立即开始我的工作就顺理成章了。”

当请求/需求最终到达时,它可以像三明治订单一样在本地熟食店柜台听起来:

BigCustomer到周五需要我们的企业ERP产品,附带定制报告的副订单,而且API繁重,请用内部部署代替标准云托管,并保留每个用户的许可证模型—因为我们将有特殊的定价条款。

假定但尚未说明的是,我们有闲置的工程师躲在软件熟食店柜台后面,等待组装任何客户的订单,并且不需要延迟/取消其他任何工作来启动这一新事物。还假设:每个预算或大笔交易的人都将批准其请求。  (“工程总是可以引进承包商。”)

我很夸张。收入方主管和销售团队了解优先级,策略和资源限制。但是他们不一定对开发的内部运作感兴趣。

在房屋的技术方面…

在产品开发区的过道上,我们不断地迷恋建造和发布物品的复杂性。关于交付日期的收入方面的问题可以通过关于Scrum与KANBAN,SAFe与AgileFall的冗长教程来解决。随着听众在演讲中走开。 (这就像听发烧友争论LP与CD音质的争论;或者设计师批评字体字距紧缩;或者厨师涌向粉红色的喜马拉雅盐和草食牛肉。对局外人来说并不那么有趣。)

我们以这种方式思考我们的产品开发过程:

昂贵,复杂且基于复杂的可重用架构。即使我们的任务只是为午餐提供午餐,我们也会消耗大量的燃料。 国际空间站 船员。我们关注平均速度,而不是特定的可交付成果。而且我们看不起比我们少痴迷的人。

什么’s Happening Here?

请注意,这是信息不完整,沟通不畅和 反对重要观点。请求者专注于他们的下一个新事物,并且在不知不觉中将工作量降到最低。工程部知道它已经超负荷使用了,并希望忽略中断。  我们经常互相交谈。 什么 to do?

我已经成功地帮助产品/工程团队构建了一个非常简单的工具来应对潜在的沟通挑战。这是一个一页的页面,显示当前正在构建的内容;排队等待功能定义/设计的事情;排队等待客户/市场验证。产品/工程从左到右阅读,但是销售/市场营销可能从右到左阅读。

产品/工程方面的几乎每个人都认为,收入主管和销售团队知道此列表中的内容。但它 爱因’t necessarily so。每周一次对此简单,高级图表*的执行人员审查会提醒每个人实际的情况,这使我们之间的对话更加细微。

产品在制品图经常提醒您正在发生的事情。产品和工程负责人现在可以提出更好的问题:

  • “如果我们将这个伟大的新想法直接应用到开发中,我们应该推迟或取消哪些“开发中”项目?”
  • “当我们进行可靠的设计和功能定义时,我们会取得更大的成功,因此应该在开始编码之前发生。这个新产品碰撞了什么设计工作?”
  • “客户没有购买我们以前看似好的主意,因此几周的市场验证可能会节省数月的开发工作。”

这有助于培训整个执行团队提出更好的问题并与之搏斗 要么  decisions instead of  demands.  我们正在从事最重要的项目吗?我们应该首先验证许多好的想法中的哪一个?我们可以同时高效地构建或启动多少个新功能?扎实的设计工作是否可以帮助我们更好地确定开发工作的规模?取消部分完成的项目的费用是多少?

因为 软件熟食柜台后面没有工程师 等待他们的下一份工作完成。

当然,这还不是故事的结局。一旦我们都认识到产品/开发队列的存在,就可以添加:

  • 尽早对主要投标进行技术/产品审查,以寻求好的解决方案。客户经常要求做错事情,或者误解产品架构,或者不知道可以解决问题的现有功能。尽早获得良好的产品投入可以使我们免于因错误的增强功能而导致浪费时间的三重匆忙实施,从而使有用的工作排挤了。
  • 在大多数客户需要的地方灵活地设计产品。回顾以前的销售情况,我们可以发现一些需要在选件或配置选择中建立的区域,从而避免了许多最后一刻的客户需求。

等等。有很多方法可以改善产品开发过程。

声音字节

在产品/工程方面,我们经常假设收入方面正在跟踪我们的每次更新,并且对我们的内部流程着迷。不太可能。 好的决策取决于过度沟通和明确地权衡取舍。

 

*在本文的任何地方,我都谨慎避免使用“路线图”一词。让’知道房子的收入方面希望路线图成为五年铁定的承诺,同时又一些敏捷的开发人员否认路线图的存在,因此我们重新打包。