隱性KPI:對項目管理的合理追求
發(fā)布時間:2012/1/17 9:53:00
問題:在產(chǎn)品發(fā)展和項目推進過程中,如何追求項目管理的科學性和合理性,是恰當?shù)?
下文中提到的所有項目管理觀點,全部都以“利于產(chǎn)品發(fā)展”為最高優(yōu)先級的大前提,其他利于團隊團結、公司發(fā)展等細節(jié)都次之。(當然都是可以方向一致、相輔相成的)
在一個產(chǎn)品發(fā)展過程中,根據(jù)架構背景、項目背景、產(chǎn)品背景三個方面的因素,綜合考慮當前項目管理的最后方案,才能保證“利于產(chǎn)品發(fā)展”的目標。三個背景缺一不可,少評估一個,就多一份風險,默默的埋藏在執(zhí)行過程中,并且很難被再次發(fā)現(xiàn)。
將三個層面的背景梳理清楚,才有可能綜合的判斷問題根結,假設:
架構背景:
1、產(chǎn)品、運營、視覺三個方面的跨部門合作;
2、各個部門中的團隊考核標準不同,晉升機制不同,團隊氛圍不同;
3、各個部門中團隊,前期沒有進行過磨合,并且供職于不同領域的產(chǎn)品;
項目背景:
1、產(chǎn)品上線初期的快速迭代優(yōu)化狀態(tài);
2、競爭市場非常激烈;
產(chǎn)品背景:
1、社區(qū)產(chǎn)品,依據(jù)線上情況及需求變動,隨時作出產(chǎn)品動作;
2、產(chǎn)品負責制,說白了,就是產(chǎn)品部門說了算,并對產(chǎn)品最終負責;
“架構背景”所導致的實際問題:
Q1:架構背景不同,導致:團隊之間的思維模式及個人愿景不同(架構無法改變)。
Q2:不同的思維模式及個人愿景,導致:合作過程中的細節(jié)及方向分歧。
Q3:細節(jié)及方向分歧,導致:合作過程中的過度討論及精力消耗,以及最終決策權的實施。
Q4:在消耗精力的討論過程中,反復由產(chǎn)品實施最終決策權,導致:產(chǎn)品負責制的外在表現(xiàn)更強,即產(chǎn)品強勢。
Q5:產(chǎn)品強勢,導致:其他非產(chǎn)品團隊成員的工作歸屬感減弱、工作挫折感增強。
面對可怕的Q5,當其他非產(chǎn)品團隊成員怨聲載道的時候,如何很好的解決這個問題?這也是我們目前要做的選擇。
PS:在架構背景不同的前提下,嘗試統(tǒng)一思維模式,讓不同團隊的個人愿景與產(chǎn)品愿景一致。能做到嗎?
答:當然可以用各種方式統(tǒng)一跨部門、跨地域團隊的個人愿景與項目愿景,比如項目宣講、團隊洗腦。但要質(zhì)疑的是,這種僅限于表層的苦口婆心,是否真正能夠戰(zhàn)勝不同的架構背景?在當前的產(chǎn)品背景和項目背景下,我認為不可能。此類產(chǎn)品及項目背景,決定了該項目屬于創(chuàng)業(yè)項目(大公司也有無數(shù)個創(chuàng)業(yè)型項目),這種創(chuàng)業(yè)項目,不允許讓項目核心成員把精力聚焦在團隊默契培養(yǎng)和遠景統(tǒng)一方面。
如很多同行所說,大公司里搞創(chuàng)業(yè)產(chǎn)品,困難比創(chuàng)業(yè)公司更大。就是這個原因吧。
產(chǎn)品初創(chuàng)期間,沒有一個強有力的默契的大團隊,就已經(jīng)是危險的了。面對這種困難,選一條錯路來與架構背景死磕,就更危險了。
下面看看各種解決方案的優(yōu)劣:
針對Q5的解決方案1:
1、制定明確的需求確認過程,三方或N方共同確認,由產(chǎn)品方面組織,說服各方,正正規(guī)規(guī)的抹平分歧,降低產(chǎn)品強勢的感覺;
2、制定明確的流程控制策略,明確各個環(huán)節(jié)的時間節(jié)點和責任人,并跟蹤各節(jié)點,控制流程進度,拉平產(chǎn)品部門與其他部門的地位,克服產(chǎn)品部門的封閉感。
即,側重法制。
方案1的風險:
風險1:對抗“產(chǎn)品強勢”而做出的流程設計,導致:合作過程中的需求確認更加嚴謹、分歧討論更加頻繁、進度控制更加流程化,即“死板的需求、無謂的討論、機械的流程”。
比如:需求管理無彈性,導致試錯成本增大,讓各方需求提出更加謹小慎微。為需求做減法,可不是以扼殺積極性為基礎。
分歧討論的頻繁發(fā)生導致各參與成員逐漸形成逃避分歧的行為慣性,或者導致各個參與成員在無謂的細節(jié)中浪費大量時間。
進度控制流程化導致任務質(zhì)量與時間節(jié)點之間的矛盾更加突出。
風險2:“死板的需求、無謂的討論、機械的流程”,導致:各個團隊之間的合作關系比較機械,即將合作過程中的社會規(guī)范變?yōu)槭袌鲆?guī)范。
比如:過去我可以跟其他團隊成員,共同完成一個作品,F(xiàn)在,我是讓其他團隊成員為我的產(chǎn)品完成一個任務。
面對靠譜的合作人,我可以因為更高的質(zhì)量,而放寬時間進度,F(xiàn)在,時間進度的死板與分歧討論的挫折感,讓我與他都開始不自覺的規(guī)避違背流程的事情發(fā)生。
最終,冰冷的市場規(guī)范與無謂的時間浪費,導致:迭代速度下降、產(chǎn)品決策效率降低,影響產(chǎn)品健康度。
方案1的適用條件:
1、各方團隊對產(chǎn)品或需求把握能力基本靠譜,即,具有說服他人或被他人說服的基本前提。
2、產(chǎn)品發(fā)展趨于穩(wěn)定。穩(wěn)定的市場份額、用戶群、競品情況,決定了產(chǎn)品已經(jīng)不需要頻繁的大動作,正常的優(yōu)化速度已經(jīng)保證產(chǎn)品可以正常存活。
3、跨地域或跨部門的團隊合作比較頻繁。
針對Q5的解決方案2:
1、在溝通過程中,產(chǎn)品團隊與其他團隊的核心人員建立社會規(guī)范,讓產(chǎn)品與其他環(huán)節(jié)的重要角色成為好基友,
2、避開無法統(tǒng)一的思維模式和個人愿景,而嘗試統(tǒng)一團隊之間的近期目標,以保證近期步調(diào)基本一致。
3、好基友之間在工作過程中產(chǎn)品細節(jié)與方向分歧,仍然實施產(chǎn)品負責制,但基友的關系保證了受挫方的感情基礎不動搖。
即:側重人制。
方案2的風險:
風險1:人制過程,需要實施者有更完整的“情感應對”經(jīng)驗,實施起來很復雜,需要潛移默化的搞之。
比如:甚至針對不同的合作角色,采取不同的溝通和協(xié)作方式,以保證充分發(fā)揮不同合作角色的最大效率和能力。這一點很困難,做不好的話,人制優(yōu)勢盡失。如,有的人適合情感激勵,對同一個工作培養(yǎng)出統(tǒng)一的認同感和成就感;有的人適合流程化的合作方式,到時間就交活兒,少廢話。
風險2:雖然保證了效率和速度,放棄的則是制度化的工作沉淀和規(guī)范,不適宜大規(guī)模的項目團隊或產(chǎn)品!
比如:人制過程必然導致多數(shù)環(huán)節(jié)的責任人不明確,或由“人制實施方”單方面承擔,因此要求關鍵角色能力過關且素質(zhì)靠譜,以保證任務產(chǎn)出質(zhì)量的潛在風險,在周邊團隊和項目進程的忍受范圍之內(nèi),且速度最快。不然,周邊團隊必然怨聲載道。
沒有制度和流程,導致多數(shù)細節(jié)無法回溯和落實責任人,則要求無制度無流程的社會規(guī)范,發(fā)揮更大的作用。
方案2的適用條件:
1、產(chǎn)品需要快速迭代、扛得住激烈的競爭環(huán)境,從而要求項目團隊效率及質(zhì)量優(yōu)先,其他方面次之。
2、產(chǎn)品團隊規(guī)模較小,各環(huán)節(jié)間的溝通及配合復雜度在可控范圍內(nèi)。
產(chǎn)品KPI的介入時機和制定方式,對產(chǎn)品很有影響。而對項目流程的期許,也或許是一種隱性的KPI,需要謹慎為之。
總之,在復雜的架構背景下,根據(jù)項目和產(chǎn)品背景的優(yōu)先發(fā)展,調(diào)節(jié)架構背景所導致的各個變量(考核不同、個人愿景不同、能力差異不同等等),才能確定“最利于產(chǎn)品發(fā)展”的最優(yōu)路徑。
如果在這一個評估過程中,少考慮了一層元素,就會在流程實施中埋進隱患。表面上,流程順利了、產(chǎn)出物質(zhì)量穩(wěn)定了、時間節(jié)點控制更加嚴謹了,但卻很容易為了“順利、穩(wěn)定、嚴謹”,而在過程中付出了更大的時間和精力代價。這些時間和精力代價從哪里來?從產(chǎn)品中來。搞定的是流程,傷害的是產(chǎn)品。并且,這種傷害,卻比較容易在“順利、穩(wěn)定、嚴謹”的喝彩聲和欣欣向榮當中,被忽視掉。
這些都是人性,總是容易犯的錯誤,不是說把控就能把控的。比如說,一個總是能夠高調(diào)滿足階段性KPI的產(chǎn)品,絕對是一個有可能掛掉的產(chǎn)品。而在產(chǎn)品發(fā)展階段,把項目流程搞的“順利、穩(wěn)定、嚴謹”這一個愿景,也很有可能是另一種隱性的KPI,如同PV/UV一樣,默默的在工作過程中影響著執(zhí)行人的思維,從而映射到產(chǎn)品發(fā)展本身。
所以,在解決問題的時候,一定不能只沖著問題表面去解決,仍然要綜合“三大背景”,周全考慮,才能降低風險,解析出最優(yōu)方法。
這就需要沉浸在執(zhí)行細節(jié)中,研究細節(jié),記錄下細節(jié)中表現(xiàn)出的真正問題,對癥下藥,才最安全。(資料來源:項目管理者聯(lián)盟)
更多內(nèi)容敬請訪問:http://m.xyxth.cn/active38.html