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