在一個產品團隊中,團隊成員的個人定位會因爲工作順序、專業特長等而變得各不相同。那麼,作爲一個產品團隊的管理者,該如何爲不同定位的成員分配任務,將他們正確地分配在適合的崗位?又該如何統籌管理好整個團隊,建立團隊規則呢?以下,筆者將爲大家詳細講述。

產品問答|明確團隊個人定位,有效管理產品團隊

“團隊中的產品經理最近提了幾個問題,趁此機會做一下分享。

這是產品問答的第五篇,主題是:明確團隊中每個人的定位。

問:現在開始管理產品團隊,我想知道如何帶領團隊,如何帶人?

答:

要講團隊和人的管理,先從團隊與人的關係開始。

團隊是由多個人構成,且應該由不同定位的人構成。

開始一、兩個人就可以做的事情,隨着業務發展就需要更多、更專業的人來一起協作,於是慢慢由不同人組成的團隊就逐漸形成。

綜上所述,構成團隊的人有不同的定位,這種定位有時是按照工作順序來確定,有時是按照所需專業來確定,有時是按照面對渠道來確定。

比如:

  • 把蒐集需求和Bug交給一個人做,而相關結果跟進由另一個人做,這就是按照順序確定。
  • 把產品原型設計交給一個人做,而界面設計美化由另一個人做,這就是按照專業確定。
  • 把面對大客戶的產品交給一個人做,而面對散客的產品由另一個人做,這就是按照渠道確定。

這樣區分的維度多種多樣,且有時候是同時考慮多維度的情況。

但不管如何,團隊的基礎,首先就是分工明確。

管理團隊的第一步,是:把團隊中每個人的定位明確清晰

一、確定成員定位

確定團隊成員的定位有幾個參考角度:

1. 個人特長

每個人都有自己的特質、特長——有人內向,有人則外向;有人邏輯嚴密,有人則富有創意。

要做好團隊成員定位,對其進行客觀的評價非常必要。

推薦兩個方法:

職業測試:個人建議使用 MBTI測試 ,可以從心理評測的角度瞭解其大概率的性格及能力傾向(儘量選擇93題版,測評更準確)。

產品問答|明確團隊個人定位,有效管理產品團隊

但是,心理測試有其侷限性,還需要結合實際來修正,這也是下一點要說的。

任務反饋:根據心理測試或通過其他角度的初步評判,安排相關任務,並觀察其執行過程與結果,逐步修正對其定位的判斷。

2. 工作量

評價一項工作的任務量,如果任務量大到原來人員無法及時完成,就要考慮拆分給不同的人完成。

拆分這類工作時,要首先對工作進行分析。

找到這部分工作中最核心的20%,28原則告訴我們,20%行動決定了80%的價值,甚至決定成敗。找到那20%並由原責任人去處理,另外80%的任務交給其他新手。

還有一種情況是原來的工作是多渠道的,隨着業務的發展,各渠道逐漸成長,需要安排更多的人各自負責。這時候也需要對渠道,利用28原則進行分析,將核心渠道留給熟手,分出去的渠道交給新手。

3. 執行覈查

有些任務的性質,需要有人執行,另外的人確認或覈查。

人有思維盲點,自己產出的東西,在產出時建立了完整概念,很難自己檢查出失誤或問題,比如:我寫的文章,很難自己檢查到錯誤。(捂臉,所以會出現錯字或不通順)

這類任務,我們可以將其拆分爲執行和核對兩個階段,分別由不同的人來做。如果有多個執行同類型任務的人,也可以結對,交叉檢驗。

4. 專業專職

產品走上正軌之後,原來打包在一起的工作,可以拆分成不同的專業專職。這種拆分,並非一定通過招聘新人來完成,也可以通過內部選拔培養,將原來的人員拔高爲專業專職。

開始的時候,產品經理會負責從需求調研分析、功能策劃、原型設計、文檔輸出等一系列工作。但後期可以逐漸拆分爲:需求分析、後端產品、前端交互設計等不同專職。

初期團隊管理是圍繞人的,通過對分析、實驗和修正,逐漸形成成員的各自定位

以上講了明確團隊中每個人的定位,有了不錯的成果後,我們需要進行下一步。

二、建立團隊規則

是不是有些熟悉,之前文章也講過類似內容——《進一步參與基礎工作》中有講到構建團隊溝通規則。

這裏要講的團隊規則,包含那一部分內容,且要拔高一層來講更宏觀的團隊管理。

團隊成員定位明確,並得到不錯的效果,我們需要固化成果,實現更好效果。

1. 個人定位到崗位

鐵打的營盤,流水的兵,團隊人員擴充和更替是不可避免的事情。

如果你不想每次人員變動,都對新的小夥伴重新定位,那就需要把對團隊個人的定位,轉化爲團隊的崗位定義

我特別不建議那種照抄式的崗位定義,每個團隊的業務情況、所處階段都不相同,別人梳理總結的並不一定就適合你。經過你深思熟慮、多次迭代的團隊個人定位,裏面也飽含了你對團隊實際情況的考量,那才最適合歸納成團隊崗位定義。

另外,團隊的崗位定義也要保證一定的彈性。畢竟每個人的能力、特質都不相同,用在前一個人身上合適,在新人身上則要做出或增或減的調整。

2. 崗位考覈標準

建立了團隊的崗位定義體系,還需要對每個崗位明確考覈標準,有了標準才能客觀評價每一個成員

主流考覈標準有:

KPI,關鍵績效指標:

是一種可量化的、被事先認可的、用來反映組織目標實現程度的重要指標體系,也是企業績效管理過程中一個實用而且有效的工具,更是績效管理實現過程中的一個重要內容。KPI的本質是一種管理工具,它主要是從結果上來考察績效,不關注過程,一切用指標來說話。

執行流程爲:

  1. 進行人事組織。
  2. 確定影響結果的關鍵性因素,並且確立 KPI 。
  3. 對關鍵績效指標進行檢測,並且進行實時監督。
  4. 對有錯誤行爲的人進行監督,更甚者開除。

OKR,目標和關鍵成果:

這是一套定義和跟蹤目標及其完成情況的管理工具和方法。

主要的目的是:更有效率的完成目標任務,並且依據項目進展來考覈。

分爲幾個步驟:

  1. 明確項目目標。
  2. 對關鍵性結果進行可量化的定義,並且明確達成目標的/未完成目標的措施。
  3. 共同努力達成目標。
  4. 根據項目進展進行評估。

對比兩者,OKR 主要強調的是對於項目的推進,而 KPI 主要強調的是對人事的高效組織。前者要求的是如何更有效率的完成一個有野心的項目,而後者則強調的是如何保質保量的完成預定目標。

OKR相對於KPI而言,不是一個考覈工具,而是一個更具有指導性的工具,說白了,是一個PLAN-DO-REVIEW的cycle。

他存在的主要目的不是考覈某個團隊或者員工,而是時刻提醒每一個人當前的任務是什麼。每個人都有自己的OKR,每個團隊有團隊的OKR,無論級別高低,團隊大小,都需要定製和服從OKR。

這個OKR在每個季度結束之後要做一個評分。評分高低並不直接決定一個員工的晉升和待遇,而更多的是提醒員工,這個季度工作完成的怎麼樣,未完成的工作爲什麼沒有完成,下一階段的工作重心是什麼。

KPI 理論上是必須嚴格按照 SMART 標準制訂的,“是否達到?”甚至“達到比例多少?(小於 100% 還是大於 100%?)”都是要能測量的。

但這就導致一個問題:有些事情值得去做,但在做出來一部分之前無法測量因此無法定製目標,這時候就陷入了先有雞還是先有蛋的問題了。

KPI 還有一個更嚴重的問題,那就是:爲了完成可測量的目標,有可能實際執行手段與該目標要達到的願景正好相反。

舉個例子來說:我們希望用戶更喜歡使用我們的產品,因爲喜歡無法測量,所以把 PV 寫進了 KPI 裏面。但在實際執行過程中,我們可以把用戶原本在一個頁面上就能完成的事情,分到幾個頁面上來完成,結果 PV 達到了 KPI 指定的目標,但用戶其實更討厭我們的產品了。

大家如此應付 KPI, 是因爲 KPI 跟績效考覈掛鉤。如果 KPI 達不到那就會影響獎金,所以就算違背公司利益,違背用戶利益,也要把自己的 KPI 完成了,把部門的 KPI 完成了。

因此,個人更喜歡OKR,也推薦你去學習瞭解一下。

3. 團隊溝通規則

這部分內容,在上一篇文章裏面詳細說明過,這裏只列一下概要,不再展開。

  • 執行標準:對團隊中各類的執行事務,逐步建立規範,可以節省很多時間成本;
  • 工作流程:建立工作流程,可以讓團隊在日常工作上保持有序,提高效率;
  • 交付物標準:清晰可執行的交付物標準,是保證產品交付物高質量的前提;
  • 文件交互規範:規範文件的編輯、迭代、傳遞等交互過程,有助於提高工作效率,也能避免文件遺失。

4. 塑造團隊文化

相對於團隊規則這種硬性的規範,團隊文化屬於較軟的規範。

硬性的規範決定了團隊的下限,而軟性的團隊文化則決定了團隊的上限

團隊文化也較爲個性化,最終決定團隊文化的主要因素是團隊leader的特質和意願。

團隊文化可不是僅僅在牆上貼一堆標語(笑……),更不是找些時間大家一起聚個餐,唱個K,甚至犧牲休息時間去拓展中心(笑……)。

如上做法都是偷懶的行爲,真正的團隊文化是需要你做出表率,帶領團隊逐漸養成的。

我會建議幾個要點,但最終還是要你自己去琢磨和建立。

  • 主動成長,帶領團隊主動學習,主動求索,獲得成長;
  • 樂於分享,有收穫、有感想,積極在內部分享;
  • 敢於承擔,不侷限於本職工作,勇於承擔額外的任務和挑戰;
  • 有效溝通,目標清晰、簡明扼要、跟進反饋的溝通習慣。

團隊文化不能一蹴而就,而是要你作爲主導者,和團隊成員一起慢慢養成。一旦形成良好的團隊文化,就會讓團隊的效能提高很多倍,也能讓每個新加入的成員迅速融入。

以上就是我在團隊管理和人員管理上的個人建議。

引用

《OKR管理體系的基本框架》– http://www.zhenrencai.cn/essay3

作者:十八子殺,微信公衆號:產品狗的思考(Productdoggy)。10年產品人,射手座,愛自由,喜攝影,好讀書,涉獵廣泛,望與同路人勉勵前行。

本文由@十八子殺 原創發佈於人人都是產品經理,未經許可,禁止轉載。

題圖來自@Unsplash, 基於CC0協議

相关文章