在本文中，我将分享我在选择用于开发产品功能的想法时的经验，并告诉您如何保留主要的开发载体。
我们正在开发一种自动计费系统（ASR）-计费。 学期
我们产品的使用寿命为14年。 在此期间，该系统从最初的工业关税化发展到了由18种相互补充的产品组成的模块化系统。 程序长寿的最重要方面之一是持续开发。 为了发展，需要思想。
主意
资料来源
有5个来源：
- 公司信息系统开发人员的主要朋友是客户 。 客户是决策者，项目发起人，流程所有者和执行人员，内部IT专家，普通用户以及大量不同兴趣的个人的集体形象。 对我们而言，重要的是，客户的每个代表都可能是思想的提供者。 在最坏的情况下，我们只会得到有关系统问题的负面反馈。 充其量，在客户方面，有一个不断改进思想的人，可以提供有关客户需求的结构化信息。
- 我们的卖方和客户经理是第二个最重要的改进思想来源。 他们与行业代表进行了大量沟通，并积极主动地从潜在客户那里收到有关开票功能的第一手要求。 卖方和客户必须了解其功能的所有重大变化以及竞争对手的最新软件更新，以便能够证明不同解决方案的优缺点。 如果某些计费功能成为事实上的标准，正是这些员工最先感到，否则，该软件将不被视为完整的软件。
- 产品负责人是我们的高级经理之一或经验丰富的项目经理。 他牢记公司的战略目标，并根据这些战略目标调整产品开发计划。
- 架构师 ，是一个了解所选/二手技术解决方案的可能性和局限性及其对产品开发的影响的人。
开发，测试团队。 直接参与产品开发的人员。
上诉分类
从来源我们收到原始数据-信件，票证，口头要求。 全部
上诉分为：
- 进行“如何做到？”，“如何工作？”，“为什么不起作用？”，“我不理解...”之类的咨询。 此类呼叫转到1级支持热线。 在其他类型的应用程序中可能会重新获得咨询资格。
- 具有“不起作用”和“错误”含义的事件 。 由2和3支持热线处理。 如有必要，可以将修补程序的快速修复和发布立即从支持转移到开发中。 可以将其重新训练为变更请求，然后将其发送到待办事项列表。
- 要求改变和发展 。 绕过支持热线进入产品积压。 但是对于他们来说，有一个单独的处理过程。
有关上诉的统计数据-释放后不久，上诉数量在短时间内增长了10-15％。 此外，当有大量用户的新客户端进入我们的云服务时，就会发生大量呼叫。 人们学会使用软件的新功能时，需要咨询。 即使是系统开始工作时的小客户，每月也容易消耗超过100个小时的咨询时间。 因此，在连接新客户时，我们总是保留时间进行初步咨询。 通常，我们甚至会强调特定的专家。 租金价格当然不能偿还这些劳动力成本，但是随着时间的流逝，情况逐渐趋于平稳。 适应期通常需要1到3个月，因此大大减少了咨询的需要。
以前，我们使用自写解决方案来存储呼叫。 但逐渐转向Atlassian产品。 首先，我们开发了开发工具，以使在Agile上的工作变得更容易，然后得到支持。 现在，所有关键流程都存在于Jira SD中，并且由Jira的各种插件以及Confluence提供。 自行编写的解决方案仅保留在对公司活动不重要的流程上。 事实证明，我们的任务现在是跨领域的，可以在支持和开发之间转移，而无需从一个系统跳到另一个系统。
从该捆绑包中，我们可以获得有关所有任务，计划的和实际的人工成本的数据，为客户使用各种收费选项，并生成内部需求的文档并向客户报告。
变更请求处理
通常，此类请求以功能需求的形式出现。 我们的分析师研究请求，生成规范和顶级ToR。 它会将规范和工作说明传递给提交此批准请求的人-我们必须确保我们与客户说相同的语言。
收到客户的确认，我们已正确理解彼此，分析师将请求写入产品积压。
产品管理
积压的订单累积了更改和开发的传入请求。 每六个月召开一次技术理事会，由董事，维护，开发，销售和系统架构师经理组成。 董事会以讨论形式对积压的应用程序进行解析和优先级排序，并协调5个开发任务以在下一个版本中实施。
实际上，技术委员会考虑到应用程序中记录的需求来响应行业和市场的需求。 无关紧要的所有内容都保留在积压中，无法进行开发。
变更请求和财务分类
开发是昂贵的。 因此，如果更改请求是来自客户而非员工的，我们将立即告诉您可以选择哪些选项。
变更请求分为以下几类：行业需求或企业的个人特征； 大量的新功能或少量修复。 小补丁和单个请求的处理没有任何多余的装饰。 在与客户一起进行的项目工作中，会针对特定客户计算并实施个别请求。
如果这不是一个巨大的行业需求，并且功能范围很大，则可以决定开发一个新的单独模块，除主要功能外还将出售该模块。 如果收到客户的此类请求，我们可以承担开发模块的成本，免费或部分付款给客户提供该模块，并将该模块公开发售。 客户在这种情况下承担了部分方法上的负担，并从根本上进行了模块的试点实施。
如果这是行业的巨大需求，则可以决定在基本产品中包括新功能。 在这种情况下，成本完全落在我们身上，新功能出现在程序的当前版本中。
向老客户提供了更新。
也可能是几个客户有类似的需求，但并没有吸引大量产品。 在这种情况下，我们可以将规范发送给这些客户，并提议在他们之间分担开发成本。 结果，每个人都会取胜：客户以低成本获得了功能的实现，我们丰富了产品，一段时间后，其余的市场参与者也可以使用这些功能。
开发者
Development每年准备两个主要版本。 在每个版本中，都保留了时间来执行从技术委员会收到的5项任务。 因此，对于流体，我们永远不会忘记产品的开发。
每个版本都通过了一组适当的测试和文档。 此外，此版本已安装在相应客户的测试环境中，而客户又会仔细检查所有内容，并且只有在将该版本转换为正式产品之后。
除发布系统外，还有一种快速修复错误的格式，这样客户端六个月内不会出现错误。 这种临时格式将使您能够快速响应突发事件并履行声明的SLA。
以上所有这些主要适用于公司部门和本地解决方案。 对于专注于SMB细分市场的云服务，客户没有参与此类产品开发的广泛机会。 SMB的租赁格式甚至不建议这样做。 这不是公司方提出的明确要求形式的变更请求，这里只是通常的反馈和对服务的期望。 我们试图倾听，但产品庞大，一个客户希望从其旧的历史系统中带来一些熟悉的东西的愿望可能与整个系统的开发策略相矛盾。