在做產品的這段時間里,聽到最多的詞不是交互、架構、設計這種逼格很高,嚇死人的詞,而是——時間。
時間是一種看不見摸不著的東西,但是我們都能感覺到他的流逝與不可逆。去推進、去監督、去設立時間節點、聽起來似乎應該是項目經理該做的事情,可事實上,大部分公司都會把這一份職責也加之產品經理身上。產品經理也有理由去承擔下這部分的工作,因為在整個產品產出過程中,產品經理應是最懂產品每一個細節的人。
每一次產品開發都是一次時間緊任務重的挑戰
老板總是很任性的,要求你在很多短時間里就將產品設計并制作出來。通常工期都會比較緊張,或者說這是為老板之人的一種戰略也不一定。。就是工期緊,好讓下面的人有緊迫感?好吧,完全是一種一項,對猜測不負責的。
時間是把抵在腦袋上的槍
上線時間,洋氣一點叫deadline。再洋氣一點叫“帶的來恩”。
OK,當無數個會議結束后,需求已經確定!這時候我們會得到,一個比較明確的上線時間或者模糊的預測上線時間。
明確的就是領導確定下來的,一般不能改變,且不在我們能控制范圍之內。這通常與公司戰略、拉融資、等等因素相關。也包括老板的心情!
還有一種叫預測上線時間,此類時間的主動權放在了我們自己或者項目經理手中。但我們該如何去預測一個產品的上線時間呢?一般有經驗的產品經理會根據以往的經驗來進行預測。但如果你和我一樣是菜鳥怎么辦?那就扔鞋或者擲篩子吧~~哈哈 開玩笑。這個當然還是有方法可循的。
在做過兩個產品小功能模塊后,讓我知道了在產品產出過程中溝通的重要性。
人與人在信息流傳遞上,是很容易出現差錯的。就像我們小時候玩的游戲,由第一個人說一個詞傳到第十個人的耳朵里可能就變成了另外一個詞。
你也許會說,你可以去找他們的負責人啊,進行一對一的溝通不需要中間的傳話筒;OK,這樣是可能會降低出錯的概率。但你并沒有考慮進,這個人一天的“時間”里會接受多少這樣的信息傳達。也許一不小心你的需求就會在他的任務清單里變成了,重要但不緊急的項目了。
溝通先行
那么在預估他人時間的之前。我們可以先搞定自己的“時間”。
首先我們需要將此次產品的需求了解透徹,最好能夠整理出一份文檔,里面包含一些產品背景,解決了什么問題,如何解決等文字說明,要實現哪些功能。你可以叫他MRD BRD PRD什么的,其實這些都是形式,重要的是你是不是可以讓自己和其他人明白,你們接下來要做的事情。
在去找他人溝通之前,你需要給自己一個時間節點,這時可以適當的“逼迫”自己,設定較為短的時間可以讓自己盡快投入到產品的設計中去。其實包括我在內,大部分同學都是一群拖延癥重度患者啦。你們懂的。
談話的形式最好是找到負責人,進行一對一或者少數人的交談,和他們講明白這個產品可以實現哪些功能,大概會有多少個頁面等,是在原版的基礎上進行迭代,還是開發新產品等等開發前期需要知道的前提。
如果你的談話對象是UI,最好在談話之前到網上找一些競爭對手或者目標效仿網站一并發給設計,再去談的話就可以更加輕松了。這時UI一般會根據平時自己做頁面的情況與這次設計的復雜程度,給出一個大概的時間。
如果你的談話對象是技術,你也可以去把競爭對手的網站發給他,告訴他們競爭對手上的哪些功能也是我們需要的,問一問有沒有技術難點,詢問一下他們手頭上是否有其他并行工作,是否是全身投入到這個產品中來,當然如果你是個懂技術的PM的話,那真是極好了,可以直接跟他們說,需要什么樣的技術架構來實現。當然他們也會給你一個時間~
與測試的溝通可能就相對簡單一些了,可以先去了解一下同城他們做測試的一個流程,并詢問他們常規測試一般時間。
壓縮與預留
OK,現在幾方陣營的時間已經交到你的手上了。那是不是就可以相加得出時間了呢?其實還早。還需要一部壓縮與預留。
壓縮時間是盡量去壓縮每個環節上面的時間,根據你對這個團隊或者個人能力的認知,來壓縮他們的時間,盡量做到前緊后松,這是最理想的狀態。要壓縮多少時間,就要看你的感覺與協調能力了。
預留時間則是要給產品的deadline一個緩沖的時間,不知道大家知不知道墨菲定律,如果事情有變壞的可能,不管這種可能性有多小,它總會發生。產品開發也是一樣,所以我們需要給哪些,不可預知的事情一個緩沖的時間,通常如果做預測時間對外公布的時間,都會與真正心理預期的上線時間有所不同。
尾巴——節奏感
從對時間的把控,可以看出PM的節奏感。無論是快速迭代,還是傳統的開發,節奏感都非常重要。可以說,過快的開發會讓用戶忙于更新而不能去熟悉產品,而過慢的開發進度又會被變化莫測的市場所淘汰。
其實這很像劃龍舟,如果大家的力氣都在一個時間一起爆發,那力量肯定是不容小覷的,但如果有哪個人的節奏錯了。別人做完動作,他還沒有開始,那不僅會拖慢速度,嚴重的更會讓自己的團隊喪失資格。
所以通常我們都會在龍舟上看到一個慷慨激昂喊號子的年輕人,而在產品開發的過程中,這個人就是產品經理。
那~下次我們要不要一起喊產品號子!