大家好，我是康斯坦丁·庫茲涅佐夫，我是RocketSales的首席執行官兼創始人。 在 IT 領域，當開發部門生活在自己的宇宙中時，這樣的故事很常見。 這個宇宙的每個桌面上都有加濕器，一堆用於顯示器和鍵盤的小工具和清潔器，而且很可能還有它自己的任務和項目管理系統。
這有什麼問題嗎？
也許對某些人來說這沒什麼。 但我們遇到了問題。 我們構建並自動化銷售系統、實施 CRM、創建業務雲基礎設施。 除了開發和生產部門之外，客戶項目通常還包括營銷人員、銷售人員、會計師和其他員工。 我們開始思考如何組織有效的項目管理流程。
如果開發和生產過程是在像 Jira 或 GitLab 這樣的平台中組織的，那麼 除了開發之外，沒有人了解什麼是什麼。 要將第三方員工連接到項目，您需要與他會面，解釋上下文，在某處修復任務，然後在工作聊天中控制準備程度，通過聊天獲取結果，並將其添加到 Jira。 每次都是如此。
開發與公司其他部門隔絕，他們不知道如何讓我們參與，我們也不知道他們是否需要我們的投入。
幾年前，我們發現了 Asana 平台。 在本文中，我想告訴您我們如何組織開發和生產管理流程，以便：
- 整個公司在一個單一的生態系統中工作，
- 每個人都有足夠的功能，
- 可以以時間和金錢來估算每個項目的成本，
- 與客戶的合作是長期的：不是在一項任務的框架內，而是在一個不斷積壓想法的整個項目的框架內。
關於體位法的一些認識
我花了 10 年的時間尋找方便的項目管理軟件。 Trello、Jira、Planfix、Megaplan、Bitrix24 和其他數十種任務跟踪器尚未通過強度測試。 然後我找到了體式。 一切順利。
我們認為，它是最好、增長最快的任務和項目管理平台。 如今，Asana 在受歡迎程度和用戶滿意度方面處於世界領先地位。 評級 g2 的圖表證明了這一點。
我們是 Asana 粉絲，我們甚至獲得了能夠向客戶實施它的認證。
我簡單描述一下從銷售到項目實施的流程
由於我們銷售 IT 服務，因此我們的渠道相當長，最後會流向生產部門，有時還會流向開發部門。
銷售部門執行標準操作：審核、批准商業提案、簽署合同、將交易轉移到生產。 生產部門可以不接受合同：合同中必須包含預算、投入生產的日期、實施項目的預計時間資金。
得益於 amoCRM + Asana 捆綁包，當將交易從銷售部門轉移到生產部門並返回時，工作不會在任何地方中斷。 銷售部門的職責範圍用藍色表示，生產部門用橙色表示，開發部門用粉色表示。
重要的是，與設計部門不同，開發部門並不參與每個項目。 有時系統設置不需要自定義解決方案。
因此，當經理接受生產項目時，銷售經理一鍵轉到 Asana（屏幕截圖）。 Asana 中的 amoCRM 自動創建項目。
帶有項目地圖和商業報價的任務（任務）會在公共客戶項目板上自動創建。 當前正在生產的所有客戶端都顯示在此處。 在這裡，指定負責的經理，設置截止日期，選擇工作類型，並更改任務狀態。
經理可以在任務中啟動任何建議的自動業務流程：
- 查找/創建客戶項目+在那裡附加任務
- 使用有關交易的信息填寫任務
- 從當前任務創建交易
該項目充滿了 amoCRM 中指定的所有數據。 根據服務類型，立即創建一組子任務以實施實際工作塊。 項目經理仍然需要分解詳細的任務，分配責任人和期限。
該委員會有助於開展新項目。 但控制其當前狀態和存在風險的項目並不方便。
我們如何對客戶任務和項目進行分組
從所有項目的公共面板中，經理將項目添加到另外 3 個面板中：
- 客戶的個人董事會；
- 活躍客戶組合；
- 經理的投資組合。
讓我們弄清楚為什麼我們需要每個實體。
在您看到的屏幕截圖上 客戶的個人董事會。
為什麼是這個板？
我們過去常常根據任務來思考。 任務完成了，又去幹別的了。 事實證明，我們為客戶所做的工作完全符合他的要求。 但我們希望建立長期關係，因此我們從處理任務轉向與客戶合作。
我們確保為客戶寫下所有改進的想法。 即使這是客戶不小心拋出的一個想法，我們也會修復它並完成它。 任務積壓就是這樣形成的，與客戶的工作並沒有結束。
這個板上有什麼？
我們的體式與多項服務相關：
- CRM系統（用於與銷售部門互動），
- TimeDoctor（用於記錄時間），
- ERP 系統（用於在單個界面中聚合所有數據）。
我們為 Asana 添加了一個快速資源控制面板。 您將鼠標懸停在任務上，可以查看誰在該任務上工作了多少，他們獲得了多少獎金。
生產部門的工作是按小時估算的，因此嚴格跟踪每個員工在解決客戶任務上花費的時間對我們來說很重要。
板子的用途是什麼？
結果，在ERP系統中我們看到 項目報告。 交易狀態、項目參與者、項目預算、工作時數和截止日期。
我們可以預測類似開發項目的成本，KPI 計算變得絕對透明，並且不存在開發僅需幾個小時的幻想。 如有必要，我們始終有一個界面可以向客戶展示以進行報告。
Asana 公文包
此功能已在 Asana 中實現很長時間了。 但我們並沒有立即欣賞它。 起初，我們只是將經理的所有項目收集到項目組合中。 事實證明，Denis Kiselev 在公司任職期間曾與 61 名客戶合作過。
知道這一點很酷，但不足以證明花在收集上的時間是值得的。 我們在投資組合上得分。 當我們將 Asana 中的一個項目等同於 CRM 系統中的一筆交易時，一切都發生了變化。
以前，經理訂閱了所有項目並在收件箱（通知源）中收到所有更改的通知。 每次狀態更新時，提要中都會顯示一條新評論，從最新的評論開始。 週一，經理坐下來按順序執行收件箱中的任務。 沒有討論優先事項，有時重要的任務沒有完成。
現在有一個員工組合和一個項目部門組合。 在第一個中，經理管理他的項目，在第二個中，經理可以控制所有員工當前的工作量。
設計作品集
在屏幕截圖中，您可以看到按員工排序的項目。
項目經理每週更新一次每個項目的狀態。 寫下上週做了什麼以及下週計劃做什麼。 設置三個標籤之一： 受到控制，處於危險之中，存在問題。
經理可以快速評估：
- 設計部門目前的客戶數量，
- 每個經理工作中的項目數量，
- 逾期的項目任務數量，
- 問題的存在以及參與項目的需要，
- 項目截止日期、花費的時間、漏斗階段和項目優先級。
投資組合還可以幫助我們進行報告。 更新項目狀態後，已完成和計劃工作的報告會自動發送到與客戶的聊天室。
員工檔案
就連項目部負責人也有自己的作品集。 如果，啪啪啪，他將自己移除，新人將看到他控制下的所有項目，並且他必須繼續跟踪。
生產線員工還讚賞投資組合工作量規劃的便利性。 在“加載”選項卡中，Asana 會考慮截止日期來分析任務量，並在員工計劃的任務量無法承受時發出警告。 您可以更改截止日期並調整詳細信息，而無需離開此選項卡。
Bug 解決和定制開發
一個單獨的團隊負責我們的開發。 作為業務流程的一部分，它接收兩種類型的任務：
- 漏洞，
- 新發展。
檢查錯誤、評估嚴重性並轉移到技術支持服務的工作中。
開發任務要么來自公司內部積壓的產品，要么來自項目經理（如果客戶有相應的請求）。
一般來說，開發過程是這樣的。
任務落在 Asana 的開發板上。 她在這。
任務設置者選擇“Bug”或“Feature”的類型，設置關鍵程度，指示受任務影響的客戶、公司內部部門。 當任務符合內部規定的所有要求時，主管點擊任務上方頂欄中的閃電圖標，啟動自動業務流程“開發中評估”。
開發部門負責人收到有關新評估任務的通知，該任務本身在評估期間被移至同名的單獨委員會。
評估後，經理將任務移至與計劃完成月份相對應的衝刺。 任務總是同時在多個板上：
- 在項目經理的個人董事會上，
- 在支持板上
- 在開發板上。
控制任務的所有參與者和員工都會看到進度、接收通知並直接在任務評論中進行討論。 任務完成後，項目經理或負責的技術支持專家將其“帶到”自己身邊，以便繼續進行項目工作。
當我們將開發和生產部門與團隊一起返回到單一環境時，會發生什麼？
首先， 客戶項目變得更加長期。 由於積壓訂單不斷補充，平均支票數量有所增長。
其次， 項目質量大大提高，因為開發部門可以隨時向市場、銷售、會計等提出問題。 我們有機會及時連接團隊的必要能力，並提供完全不同級別的解決方案。
三， 員工、經理和客戶在計劃和完成的任務中獲得完全的透明度。 我們學會了管理項目，意識到這是一個絕對的技術過程，人為因素幾乎可以完全排除在外。
第四， 團隊變得更有凝聚力。 此前，員工們對神秘的開發和生產部門在做什麼一無所知。
現在，看看系統的開發過程和技術設置：
- 銷售部門在其中找到如何銷售的想法和靈感，
- 營銷人員定期為帖子、文章、定位和廣告文本獲取有用的內容，
- 管理者分析顧客的需求和行為，調整策略。
事實證明，這是一次三贏的轉型，我們、我們的客戶和我們的合作夥伴都贏了。 如果您在評論中分享您的意見，我將非常高興：我的文章中有什麼有用的內容以及您在開發中使用哪些項目管理方法！
來源： www.habr.com