在本文中，我將分享我在選擇產品功能開發創意方面的經驗，並告訴您如何保持主要開發向量。
我們正在開發一個自動結算系統 (ACS) - 計費。 學期
我們產品的使用壽命為 14 年。 在此期間，該系統已從工業評級器的第一個版本發展為由 18 種相互補充的產品組成的模塊化綜合體。 項目長壽的最重要方面之一是持續發展。 發展需要想法。
思路
來源
有5個來源：
- 企業信息系統開發人員的主要朋友是 顧客. 客戶是決策者、項目發起人、流程所有者和執行者、內部 IT 專家、普通用戶和大量不同程度感興趣的人的集體形象。 對我們來說重要的是，每個客戶的代表都可能是創意的提供者。 在最壞的情況下，我們只會得到有關係統問題的負面反饋。 充其量，客戶方有一個人不斷提供改進的想法，提供有關客戶需求的結構化信息。
- 我們的 賣家和客戶經理 是改進想法的第二重要來源。 他們與行業代表進行了大量積極的溝通，收到了潛在客戶對計費功能的第一手請求。 商家和賬戶必須了解其功能的所有重大變化和競爭對手的最新軟件更新，能夠證明不同解決方案的優缺點。 正是我們的這些員工最先感受到某些計費功能是否成為事實上的標準，沒有這些功能就不能認為軟件是完整的。
- 產品擁有者 我們的一位高級經理或一位非常有經驗的項目經理。 牢記公司的戰略目標，並據此調整產品開發計劃。
- 建築師，了解所選/使用的技術解決方案的可能性和局限性及其對產品開發的影響的人。
開發和測試團隊。 直接參與產品開發的人員。
命中分類
我們從信件、票據、口頭請求等來源接收原始數據。 全部
申訴分類：
- 協商 意思是“怎麼做？”，“它是如何工作的？”，“為什麼它不起作用？”，“我不明白......”。 此類電話會轉到 1 級支持熱線。 可以將協商重新訓練為其他類型的上訴。
- 事件 意思是“不工作”和“錯誤”。 由 2 條和 3 條支持線處理。 如果需要快速修復和發布補丁，可以直接從支持轉移到開發。 可以將其重新分類為變更請求並將其發送到待辦事項列表。
- 變更和開發請求. 繞過支持熱線進入產品待辦事項列表。 但對他們來說，有一個單獨的處理程序。
有這樣的點擊率統計 - 發布後，點擊率會在短時間內增長 10-15%。 當一個擁有大量用戶的新客戶來到我們的雲服務時，也會有突發的呼叫。 人們正在學習使用新的軟件功能，他們需要建議。 即使是一個小客戶，在系統開始工作時，每個月也很容易消耗 100 多個小時的諮詢時間。 因此，在連接新客戶時，我們總是預留時間進行初步諮詢。 通常我們甚至會挑出一位特定的專家。 當然，租金成本並不能抵消這些勞動力成本，但隨著時間的推移，情況會趨於平穩。 適應期通常需要 1 到 3 個月，之後對諮詢的需求會大大減少。
以前，我們使用自己編寫的解決方案來存儲調用。 但逐漸轉向 Atlassian 產品。 首先，轉移了開發，以便更容易地在敏捷上工作，然後是支持。 現在，所有關鍵流程都在 Jira SD 中，而且還為它們提供了各種 Jira 插件和 Confluence。 自行編寫的解決方案僅保留在公司活動的非關鍵流程上。 事實證明，我們的任務現在是端到端的，它們可以在支持和開發之間轉移，而無需從一個系統跳到另一個系統。
從這個包中，我們可以獲取有關所有任務、計劃和實際人工成本的數據，為客戶使用各種計費選項，並生成滿足內部需求的文檔和給客戶的報告。
處理變更請求
通常，這些請求以功能要求的形式出現。 我們的分析師研究請求，生成規範和頂級 TOR。 將規範和 TOR 轉移給提交此請求以供批准的人 - 我們必須確保我們與客戶使用相同的語言。
在收到客戶確認我們正確理解對方後，分析師將請求輸入產品待辦事項列表。
產品特性管理
積壓工作會累積收到的更改和開發請求。 每六個月一次，由主管、維護、開發、銷售主管和系統架構師組成的技術委員會召開會議。 在討論形式中，理事會分析積壓的應用程序並確定其優先級，並商定在下一個版本中實施的 5 項開發任務。
事實上，技術委員會考慮到應用程序中記錄的需求，響應行業和市場的要求。 所有無關緊要的事情都留在積壓中，沒有達到發展。
變更請求和財務的分類
開發是昂貴的。 因此，如果變更請求來自客戶而非員工，我們會立即告訴您我們可能有哪些選擇。
變更請求分類如下：行業特定的需求或企業的個體特徵； 大量新功能或小修復。 小修復和個人請求得到處理，沒有任何多餘的裝飾。 作為與他合作的項目的一部分，為特定客戶計算和實施個人請求。
如果這不是一個巨大的行業需求並且功能量很大，那麼可以決定開發一個新的獨立模塊，該模塊將在主要功能之外出售。 如果收到客戶的此類請求，我們可以承擔開發模塊的費用，免費或部分付款向客戶提供模塊，並將模塊放在公共領域進行銷售。 在這種情況下，客戶承擔了部分方法上的負擔，實際上是對模塊進行了試點實施。
如果這是一個巨大的行業需求，那麼可以決定在基礎產品中包含新功能。 這種情況下的費用完全由我們承擔，新功能出現在程序的當前版本中。
為老客戶提供更新。
也可能是幾個客戶有類似的需求，但並沒有拉動大眾產品。 在這種情況下，我們可以將規範發送給這些客戶，並提出分擔他們之間的開發成本。 最終，大家都贏了：客戶以低成本獲得功能的實現，我們豐富產品，過一段時間其他市場參與者也可以獲得功能供他們使用。
DevOps的
該開發每年準備兩個主要版本。 在每個版本中，為執行從技術委員會收到的 5 項任務預留時間。 因此，在營業額的背後，我們始終不忘產品的研發。
每個版本都經過一組適當的測試和文檔。 此外，此版本安裝在相應客戶的測試環境中，客戶依次仔細檢查所有內容，然後才將版本轉移到生產環境中。
除了發布系統之外，還有一種快速錯誤修復的格式，這樣客戶就不會在六個月內忍受錯誤。 這種中間格式將使您能夠快速響應第一優先級的事件並實現規定的 SLA。
以上所有內容主要適用於企業部門和本地解決方案。 對於專注於 SMB 細分市場的雲服務，客戶沒有如此廣泛的機會參與產品開發。 SMB 的租賃格式甚至不建議這樣做。 沒有公司方以明確要求的形式提出變更請求，只有通常的反饋和對服務的期望。 我們嘗試傾聽，但產品非常龐大，而且一個客戶希望從他的舊曆史系統中帶來一些熟悉的東西可能與整個系統的開發策略相矛盾。
來源： www.habr.com