(求輕拍） 首先企業內部，是需要一套專門針對項目或者需求進行管理的軟件的。 內部的協作，我認為是主要解決以下三個問題：

信息共享與溝通，包含文檔、聊天信息等；

項目監控與推進；

管理架構到績效架構的制度。

分享一些第三方的系統： 禪道： 上手難度：★，實用程度：★★★ Atlassian系：上手難度：★，實用程度：★★★★★ Slack： 上手難度：★★★，實用程度：★★★★ Tower： 上手難度：★，實用程度：★★★ 產品流程規范 步驟：需求搜集→需求整理，成型→需求評審→立項，需求分發→敏捷→需求迭代 1. 需求搜集和需求迭代：可考慮開產品運營會議或其他形式的需求評審會議，以周為單位總結上周工作以及安排下周工作，同時可上傳到wiki便于查看需求路程。建議產品與運營是需要開會的，同時產品自身應與BD多溝通，畢竟一線人員最懂客戶場景和競品動態。 整個產品邏輯的討論應圍繞核心問題驅動：How to drive it works ！

• Drive的邏輯，我認為會建立在兩個基礎上：數據衡量和可接受故障度；
• 有效的、全面的Dirve，也是需要逐步迭代的；
• Dirve，意味著找到核心驅動能力，意味著求證充分必要性

2.需求整理和成型 代表性文檔：PRD，中保真原型。 其中，PRD著重描述包含但不止于系統架構、系統邏輯、業務背景、可衡量開發目標。中保真原型著重體現系統交互和UI。 3.需求評審和立項，需求分發 舉行快速溝通會議。團隊針對可能產生的問題進行快速溝通，敲定。例如使用Atlassian系產品，可考慮部署jira（其他項目管理軟件）進行需求分發。它可以以群組形式，按照產品→項目（故障、改進、任務）層次，查看某具體項目簡述和需求文檔，并標注項目起止時間和狀態變更。使用wiki（其他知識管理軟件）進行知識管理，例如產品部貢獻產品邏輯，BD部門貢獻客戶對接邏輯。 4.敏捷

• 拆分開發任務，分發到具體人身上，列出預估開發時間，便于監控項目進度。對于人的分發，我比較崇尚游擊隊+正統軍隊式，即對小改動小項目，能靈活安排人快速處理，同時對于多人協作項目，能指定某部分人參與，也可以是指定某個人為該部門在此項目上的直接溝通人，而績效考核，也可以通過每個人的完成任務數和難度來衡量。
• 在業務正確的前提下，嚴格執行PRD和原型制定的可衡量標準。

Q：遇到多個緊急需求擁擠，應如何處理？ 通常遇到多個緊急需求，多數在這個場景下發生：你干著活呢，突然拋過來N個需求 ，說非常緊急，需要立刻完成。這都是建立在需要立刻完成的前提下，都是你幾乎沒辦法騰出時間來逐個解決。 個人感覺還是有辦法衡量一下的，一般來講影響與客戶合作項目或公司流水的，我會認為是最緊急。 其次是老板或高層直接下達的需求，再其次是影響其他部門或其他人的項目的需求。

總結

以上是生活随笔為你收集整理的把“血”注入到产品里的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。