国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

之前我們講到了商業(yè)目標和用戶體驗之間的平衡《如何平衡商業(yè)目標和用戶體驗？》，這屬于產品和用戶之間愛恨糾葛，現在來探討下一個“平衡問題”，產品開發(fā)人員團隊內的一些自我平衡問題。

一個產品團隊的人力、需求優(yōu)先級、技術成熟度、成本預算等多方面問題都會與時間節(jié)點進行沖突，時間節(jié)點是產品永遠繞不開的話題，產品不可能在有限的時間和人力里面去開發(fā)無限的功能，產品也不可能不受時間控制，準備完全充分了再上線（如果足夠成熟有錢，倒也不是沒有這個可能性）。

產品始終會向前推進，在一輪一輪的需求評審中，每個矛盾點大都會化解，最后達到一個平衡。需求評審中，產品和開發(fā)人員都會相互妥協(xié)，產品妥協(xié)于時間，開發(fā)妥協(xié)于飯碗（誤）。

這就促使產品經理在整理需求，制定下一個版本計劃時，需要有對團隊人力和能力的足夠認知，劃分優(yōu)先級，能有決策力并且能夠說服團隊，規(guī)劃產品井然有序上線，并不能一口吃成一個胖子。

1. 優(yōu)先級 | 當我們在談論優(yōu)先級的時候我們究竟在談論什么？

大多數時候，接手一個產品，就會發(fā)現它不可能是一個完美的產品，基礎功能缺失，核心體驗亟待提升。即使是較為成熟的產品，也會存在一些歷史遺留問題和新的商業(yè)探索方向各種優(yōu)先級問題。

1.1 各種各樣的需求

以下簡單列舉了一些需求的分類，

• 外部需求：需要配合其他部門的時間節(jié)點上線，掌握權可能不在自己的手里；
• 基礎需求：包括：歷史遺漏問題，bug修復，客戶端和服務端的技術優(yōu)化，基礎功能完善等；
• 運營需求：往往和產品本身體驗是綁定在一起，并非割裂；
• 體驗升級：提升用戶體驗，功能再優(yōu)化；
• 全新需求：商業(yè)新探索和產品新方向。

當然以上的需求只是簡單列舉了一下，還可能有更多更復雜的需求，如何功耗需求等等。透過需求的表象看本質，評估對自身的影響和優(yōu)先級，也不是所有的需求都需要接，或者是馬上著手做，這個就看如何和其他部門協(xié)調了。

1.2 驗證需求真?zhèn)?/h3>

如果該需求無法驗證真?zhèn)?，無法判斷是否是優(yōu)先，那么就要采取2種手段，方式一內部討論和評審，沒有人比整個團隊的成員更加了解自己的產品了，討論往往會達成一些共識；方式二聯合用戶研究小組進行定性或定量研究，有助于內部的思考。

所以當我們在討論優(yōu)先級的時候，就是在決定產品的未來，將遠的未來，只談長遠宏觀或只談現狀，都是沒有意義的。

1.3 判斷需求優(yōu)先級

優(yōu)先級的排序和下版本需求規(guī)劃，就是在做決策的過程，而如何科學地做決策？

可采用的方式是，從幾個維度對該需求進行打分，得到總分進行排序。打分的算法不一定是對外的，是幫助自己做判斷和思考的，打分也必然是一個相對主觀的過程，而這個主觀的考量依靠的是自身對產品的了解程度，經驗，以及市場敏銳度。所以也會由于自己的判斷失誤，讓團隊耗費了大量的時間去開發(fā)，最后數據并不一定樂觀。

2. 敏捷開發(fā) | 到底什么才算是敏捷？

“快速試錯，快速迭代”是這個時代的特征，所以很多團隊引進了一個敏捷開發(fā)的概念，敏捷開發(fā)主要以提升項目周期為核心，使團隊結構責任更清晰，項目進度更具有把控性，團隊配合更緊密，工具升級提升效率，以下將分別探討。

2.1 團隊結構敏捷

團隊結構是否可以更敏捷性，一定程度上取決于公司自身架構，簡單來說分為兩種：一種是職能部門的架構，一種是模塊分組的架構。

模塊分組最簡單的標準配置是：產品經理+ 交互設計+視覺設計+客戶端+服務端+測試，模塊分組的結構一般說來在快速響應上會強于職能部門，基本上就是專人專用，多數的評審只需要經過模塊組內部，雖然效率提升了，但可能會有一定的局限，模塊之間始終會存在一些耦合的情況，另外交互和視覺設計的評審，也需要設計部門進行評審，所以大部分的公司還是以職能部門為劃分。但是需要注意的是靈活性，例如設計部門可以評審把控交互和設計大方向，但是不必在一些細節(jié)上糾結。

2.2 進度把控敏捷

產品經理需要隨時把控項目進度，通常在評審結束后，所有的需求都會拆分為stories。通過在線協(xié)作工具（例如：TAPD），可以實現創(chuàng)建Story、變更狀態(tài)、時間預估、快速編輯信息、分派人員等?？焖倜鞔_團隊成員每人每天的工作量，實現進度的把控。

另外，如果有條件的話，開發(fā)團隊可以選定一個時間進行每日的站會和周會，時間不需要太長，但是可以同步進度，同步信息，分享難點。

2.3 團隊配合敏捷

團隊配合的緊密性在于，不需要等待每一個流程結束后，才開始新流程。

比如不一定要交互出來再做設計，設計做完，才做前端和后臺，版本快完成了再轉測試。所有的工作都是可以穿插交替的，交互的同時可以是設計和前端并行，每完成幾個story，都可以打包轉交互和設計體驗，進而轉測試。團隊配合需要具有靈活性，靈活性仍然需要產品經理來把控。

2.4 工具敏捷

工具是第一生產力，如果公司自己有能力，應該是自己會購買或者開發(fā)完整的協(xié)作工具，把項目所有相關的信息保留在自己服務器上是最穩(wěn)妥的。

如果公司團隊比較小，不妨使用市面上太多的協(xié)作辦公的工具，產品可用騰訊在線的文檔，剛剛提到的開發(fā)進度管理可用TAPD 騰訊敏捷協(xié)作平臺，交互和設計可用figma或者是藍湖一類的工具。

這些都是實時在線，開放權限編輯，不管是需求新增或變更，設計變更，團隊都可以第一時間掌握。

即使是敏捷開發(fā)，但是由于各種意外，例如估算的時間不正確，人手被抽調，技術的評估不準確，甚至是新冠使大家無法正常上班，導致延期發(fā)版也時常有發(fā)生，靈活變動、快速響應才是真的。

3. 外部力量 | 有錢能使BAT為你推磨

所謂外部力量，就是花錢購買現有的技術支持。各種技術已經相當成熟，例如剪輯，敏感詞審核，直播，拍照等相當多的功能已經被網易、騰訊、阿里等集成為SDK或者API進行商業(yè)合作。

SDK和API真香

通過使用購買的SDK可以說能夠使效率翻新幾倍不止，使開發(fā)人員在投入新需求上投入的時間和人力大量縮減，加速新功能的上線。

另外，不要忘記對比各個平臺的SDK的能力和價格，SDK的不足之處就是會被局限，預想的能力不能被SDK支持，后期開發(fā)要么需求被砍掉，要么嘗試曲線救國之法，所以購買前一定要仔細閱讀官方的SDK具體能力和做好風險預估。

現在大多數公司都做了開放平臺提供API接口，和SDK相同，如果有一定的商業(yè)合作資源，或者是足夠的預算，就可以善用SDK或API，提升產品迭代速率。

END：需求是做不完的，人力是有限的，時間是緊張的，我們如何在有限的人力和時間里面，規(guī)劃適當的產品策略，作出較為正確的決策，不妨從多個方面去提升效率。

本文由 @舒季? 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協(xié)議