跳槽過來一個多月了，但是對很多需求都覺得不合理。比如說要在一個10*10的區(qū)域做熱區(qū)，讓用戶用手指去點擊；比如說優(yōu)先顯示視頻的簡介，簡介為空就顯示用戶名稱；再比如說視頻在列表頁顯示一個名稱，點開之后又顯示一個名稱。。。這樣的例子筆筆皆是，我看不慣。問其原因，只說是別人提的，人家讓這么做，咱們就得這么做。我覺得產(chǎn)品經(jīng)理不是一個傳話的使者，更應(yīng)該是一個調(diào)節(jié)各個環(huán)節(jié)的聯(lián)結(jié)者。在面對需求的時候，我們應(yīng)該去問問用戶，他們真正需要的是什么，為什么要這么做，這么做又可以帶來什么好處。只是聽到一個需求就去做，沒有任何思考，那產(chǎn)品經(jīng)理也就沒有什么存在的必要了。
今天寫這些，是發(fā)現(xiàn)了一些問題，自己記錄下來，防止自己以后犯錯誤
第一，需求要保持一致性
今天就出了這么一個神奇的事，某產(chǎn)品狗和前臺程序猿及后臺程序猿說的需求不一樣，結(jié)果比較可樂，后臺程序猿做好接口后給前臺，發(fā)現(xiàn)不會用，不知道說的是什么。然后再把產(chǎn)品狗從辦公室里拽出來，說一頓，結(jié)果產(chǎn)品狗說忘了更后臺說需求變了。一句忘了后臺兩年的工作量白費了，周六日的加班就是浪費時間。。。這，不能忍。
第二，做產(chǎn)品是一個做減法的過程
項目上線時間，往往都是給定的一個固定時間，幾乎每次都要面對任務(wù)中時間緊，每天都在和時間做賽跑。所以適當(dāng)?shù)膭h減需求，在這個時候就顯得很重要。跳槽后的這一個多月，我看到的不是縮減需求，而是不斷的疊加，產(chǎn)品狗不停地給程序猿增加各式各樣的需求，從需求實現(xiàn)的難易程度到需求的變化上，都是一個很大的量級，然后程序猿怒了~~~
產(chǎn)品狗要懂得創(chuàng)新提需求更要懂得砍掉需求，一些不著急的需要優(yōu)化的可以暫緩，放在下一個版本中進行開發(fā)。開發(fā)過程中，增加的需求，根據(jù)優(yōu)先級放進去，研發(fā)有壓力，就砍掉一些不那么重要的，以保證研發(fā)的進度。
第三，提前做好準(zhǔn)備
這次開發(fā)，就遇到了沒有做好準(zhǔn)備的問題。前臺程序猿在搭界面的時候，后臺接口沒有準(zhǔn)備好，UI效果圖沒有準(zhǔn)備好，切圖更是想都不要想。然后就用各種色塊搭的界面，不得不崇拜一下前臺程序猿哥哥的實力。那么問題來了，在需求解讀會上，商量接口的規(guī)則，因為前臺先行，所以后臺需要配合。后臺做起來就非常麻煩。前臺再根據(jù)切圖和標(biāo)注，各種修改已經(jīng)做好的界面，又是一堆活。。。結(jié)果，都怒了~~
項目進行進行過程中，可以根據(jù)項目進度，把工作量按周進行拆分，每周確定這周要做的，后臺的接口、UI的效果和標(biāo)注圖都提前給出這周需要用的，前臺就可以留出時間完善UI界面，還可以優(yōu)化代碼，提高實現(xiàn)的效率。
PS:要做好PRD文檔的更新和維護，有細(xì)化的需求或修改的需求要及時補充上去。
今天就出了這么一惡心事，兩個程序猿把產(chǎn)品狗從辦公室拉出來說問個需求，產(chǎn)品狗自信滿滿的說你們?nèi)タ碢RD。程序猿翻出文檔讓產(chǎn)品狗找，找了一圈沒有，再一圈還是沒有，最后發(fā)現(xiàn)沒更新上去，更不可思議的是。。。產(chǎn)品狗已經(jīng)忘記要設(shè)計成什么樣子的了！
