產品的負債（設計/技術負債）及解決思路

       在負責多個功能模塊及接手一個業務線以後，開始發現一些狀況而且發現這種問題不是隻有我這有，而是整個公司，各個業務線都存在的共同問題。簡單描述下發現的問題：

       A、舊的功能模塊須要人工去運營，可是又沒有專門的內部系統運營團隊，結果作越多功能模塊，這種運營維護工做量（業務/技術諮詢、推廣使用等運營工做）就越多，致使新的項目開展效率降下來；

       B、舊的功能模塊設計存在缺陷或者不完善，而後新的項目又不斷開始，結果舊的功能產生問題時佔用新項目的資源去修復維護，功能模塊越多這種維護工做量越大，最終陷入維護工做裏面，沒有時間再去作新的功能，明明作了不少東西，可是產出卻沒有。

       分析過產生以上兩種問題，陷入這種「陷阱」裏面的緣由，主要有如下：

       A、產品設計質量問題：設計存在不靈活存在比較多特殊邏輯、場景/業務流程不完善、沒有考慮運營工做的問題、角色界定不清晰（管理與普通角色混在一塊兒），產品設計自己就須要比較大的運營工做量在裏面，主要是這些問題致使；

       B、業務部門的壓力問題：業務部門有業務部門自身的壓力，他們必然須要將這種壓力轉移到研發部門來承受，因此就會壓研發部門的研發週期，甚至控制研發部門的項目等；

       C、研發質量問題：當時接手業務線後不久，發現團隊的開發人員存在問題，開發人員只是將問題掩蓋而已，沒有從根本上去解決問題，因此問題反反覆覆發生，同時也反反覆覆佔用資源，這種問題最爲嚴重；

       D、項目實施質量問題：當時接手那業務線，一來沒有比較完善的工做制度流程，工做很隨意，想作就作不想作就不作，需求評審不深，技術監督也少，測試跟進也不足；

       項目或者產品存在問題，不管是誰的問題，最終問題都是產品，由於設計是產品（該公司沒有獨立的需求分析師），與業務部門溝通是產品，主導項目進程質量也是產品（該公司沒有獨立的項目經理），帶領團隊也是產品經理該作的事情，因此上面的問題深層次是產品對整個項目的把控問題。

       因此解決方案也是很是明顯：

       A、逐步創建規範的項目管理制度：該評審的仍是要評審，經過工具在線上管理項目過程，以文檔爲主要溝通及承載工具而不是口頭，避免推卸責任；

       B、提升產品人員的要求：當時我接手那組，我是負責整組的統籌工做，下面還有幾位產品專員，提升產品人員對細節、質量的要求，要求產品人員親自去測試作出來的東西，而且提出優化意見，監控產品完成質量，減小問題產生；

       C、規範業務部門的提需求工做：當時業務部門很深度介入到研發的工做裏面，直接對開發人員進行工做安排，當時我打斷這種溝通而且根據每季度能完成的工做量，跟業務部門肯定季度工做計劃，計劃內的咱們會按計劃作，計劃外的，請排隊；

       D、梳理舊系統問題，騰空資源優化嚴重問題：由於規範了與業務部門的工做對接，能夠騰空必定量的資源出來對舊有功能進行優化，對產生比較多人工介入、維護的問題，進行優化，像增長運營後臺、修復系統漏洞減小問題產生；

       E、對有問題的開發人員進行溝通並監控工做完成狀況，若是多次不改，則辭退、更換新的成員：這個問題無法妥協，由於一旦妥協了，整個團隊都會跨了，並且實在是佔用太多資源去修正他埋下的問題，他作越多，問題就越多，還不如處理掉這種員工；

       F、工做從新劃分：以前他們的工做習慣是一個團隊所有人作一個項目，後來我將模塊、負責團隊劃分了下，雖然人很少，可是劃分紅2批，一批負責完善舊系統，一批負責新項目。這樣能夠確保完成業務部門需求，同時修正舊功能，而後每一個團隊新舊項目交替進行，這樣避免一個團隊老是作舊的功能，對此產生不滿。

       從上面的工做安排，其實都是對於人的工做進行從新的劃分，這個須要產品經理牽頭去作，由於產品人員自己就是負責整個團隊的牽頭做用。

       最後大概花了一個季度，基本處理乾淨一些淺層的問題，而後大概花了一個季度去規範工做、處理深層次歷史問題，一共花了2個季度的時間，才能完全讓整個團隊的工做氛圍、文化改變過來，而後後面就很是順暢的產出新的項目，新的功能模塊，整個團隊再也不像之前每天在那修bug處理數據，都作這些事情的目的在哪。