? ? ? 作為一只’前端猿’,隨著工作年限的不斷增長，對需求和團(tuán)隊管理也逐漸有了越來越多的認(rèn)知。而很多萌新猿最容易焦頭爛額的根源就是需求，當(dāng)然年輕的BA/PM們也需要在猿視角翻看一波，成為更受猿喜愛的Leader?，F(xiàn)在就把這些認(rèn)知分享出來給大家作為一個避坑避險成長小日記吧。

一.學(xué)會剝光需求，笑看“祭天”活動

? ? ? ? IT圈的我們都知道，一個產(chǎn)品從業(yè)務(wù)口拿到需求開始，到項目經(jīng)理交付產(chǎn)品/項目為止，期間大概要經(jīng)過產(chǎn)品/項目原型的設(shè)計，多輪需求評審，最后確定終版需求，開始UI設(shè)計，猿們著手處理研發(fā)相關(guān)工作，再經(jīng)過一輪輪的測試和bug處理，才能正式投入生產(chǎn)環(huán)境使用。這條流水線上，每一個節(jié)點處的角色都免不了和需求打交道。那么，作為一個和需求密不可分的猿，“需求一變更再變、變無可變又回起點”最后凌亂不堪的事情屢見不鮮，我們首先要嘗試避免這種情況。

? ? ? 在獲取需求的階段，要學(xué)會固化需求、透明需求。舉個例子：小猿曾經(jīng)遇到過一個身份比較特殊的產(chǎn)品經(jīng)理，在做需求評審的時候，明確說了某個功能一定要添加一個信息脫敏展示的環(huán)節(jié)，當(dāng)然小猿也在本子上很認(rèn)真的記錄了下來，并按要求做了前端開發(fā)。第二輪測試環(huán)節(jié)時，客戶做了一次初步驗收，很不幸，甲方領(lǐng)導(dǎo)特別不能接受那個信息被脫敏而不是整段展示，認(rèn)為擅自篡改了他們的本意，于是很生氣。前面說了，產(chǎn)品經(jīng)理的身份特殊(此處作為小說內(nèi)容暫不可見，備好銀子可以期待),但是總要有人對’甲方爸爸’的不高興負(fù)責(zé)，作為新人的小猿就被推了上去，領(lǐng)導(dǎo)對團(tuán)隊和外部宣稱：因為小猿的理解錯誤，導(dǎo)致了甲方的不滿。好慘不慘的是，這時候的小猿并不清楚這些內(nèi)部關(guān)系，所以看了自己記錄的需求確認(rèn)自己沒有做錯后，不留余力的據(jù)理力爭，試圖證明自己沒有誤解需求，也沒有做錯。甚至拿出自己評審時候的本子給他們看，但是沒有人看，甚至當(dāng)時私下里還跟小猿說脫敏需求他們也記得很清楚的后端們在會議上也都不肯出聲了，那時候的小猿才知道自己被“祭天”了，甚至氣的大哭一場。

? ? ? 可是以后的工作還是要做，需求評審還是要參加，除非小猿不在這個圈子里玩了，否則不可避免的圍繞需求展開工作，或許大家都會遇到過這樣的事情，BA/PM通過郵件或其它形式發(fā)給大家的需求文檔上寫的模棱兩可，而你自己又不能說明你記錄的需求確實是在需求評審會議上獲取到的需求，所以只能認(rèn)栽生悶氣?？墒俏覀兇_實固化了需求的，為什么還是沒用呢？我們固化需求當(dāng)然沒錯，但還需將固化的需求透明化，才不會被卷入糾紛。后來，小猿就養(yǎng)成了評審?fù)瓿?，立刻在會議上做好重要人員的需求確認(rèn)工作，也就是通知大家自己獲得的需求是什么，讓自己獲取的需求得到需求發(fā)布方的無誤確認(rèn)，還有個好處就是后期測試人員也不能質(zhì)疑是小猿獲取的需求有誤才導(dǎo)致的邏輯沖突類型bug，測試只能直接去找需求發(fā)布方(BA)尋求解決方案,省了很多麻煩事。

? ? ? 所以學(xué)會在評審過程中，逐條固化需求，并將自己的疑問也一一記錄，如果可以,當(dāng)即提問搞清需求并做好正確記錄，在BA講解完全部需求后，將自己整理出來的需求筆記按主次輕重做好排列，發(fā)到項目小組的群里，公布給所有與會人員，尤其提到BA和PM，請各位確認(rèn)自己本次會議獲取的需求有沒有遺漏或偏差，如果有立刻就要追問并做好矯正工作，不僅有利于后續(xù)的開發(fā)，也有利于后續(xù)的需求變更被甩鍋時的自我防護(hù)。

? ? ? ? 這樣的方式，既不會和BA有尖銳的對立感，也不會影響團(tuán)隊氛圍，悄無聲息的證明自己沒有誤解需求,甚至分享出來的需求記錄大家后續(xù)都可以做參考，還會被認(rèn)為是個細(xì)心負(fù)責(zé)的好小猿。從那以后小猿再也沒有被“祭天”過了。

? ? ? ? 因此，學(xué)會固化需求、透明需求是遠(yuǎn)離紛爭大鍋的好辦法，即便沒有責(zé)任問題，也有利于自己后續(xù)的版本更新參考和梳理，甚至對后續(xù)的維護(hù)者也有很好的快速了解和高效交接的幫助作用。

二.與“需求變更”握手言和

? ? ? ? 我們都知道，固化需求的前提是每個需求都能夠清晰明了，但作為猿是躲不開需求模糊的。這個時候，哪怕BA都要煩死你了，也要拿出“放學(xué)別走”的氣勢死纏爛打的追問。遇到不清晰的需求就要有’不給結(jié)論絕不分手的堅定意志’，不要去猜著做開發(fā)，“厚臉皮”精神會為自己鋪下更平坦的開發(fā)之路。BA也不要想著讓猿帶著“差不多”的邏輯去工作，產(chǎn)品原型上的每一個細(xì)節(jié)都值得深挖，并逐清晰化，否則留下的坑都是自己的坑，耽誤的工期，都是BA/PM后面交付時要踩的雷。

? ? ? ? 猿和BA之間就像是一場交易。猿肯定是乙方，作為乙方，不明確的需求請不要接到自己手里，明確后再接手開工也不遲。甲方是需求持有者，乙方是需求接收者，測試是第三方需求驗收機(jī)構(gòu)。第三方驗收完成做過了一系列交接工作，項目結(jié)束以后甲方再說有問題那么乙方自然是’合理合法’的不需要承擔(dān)責(zé)任。在真正的交易中，驗收交接完再要修改或者重做都是要重新計算銀子的。理清這些關(guān)系，作為猿，我們只需要全方位提升個人能力，和BA之間就不會剪不斷理還亂，自然也用不到抱怨和郁悶。

? ? ? 當(dāng)然，人腦是有局限性的，BA/PM在做產(chǎn)品設(shè)計的時候也會有預(yù)想不到的地方遺漏在需求文檔和產(chǎn)品原型之外，所以需求變更必不可少。這種變更是很明確的設(shè)計欠缺導(dǎo)致的變更， BA們也是會意識到自身問題的。而很多人抱怨白干了的需求變更實際上大多數(shù)是由于開發(fā)初期沒有清晰的理解需求導(dǎo)致猿們跟著那些模糊的邏輯進(jìn)行了編碼才會導(dǎo)致 ”白干了,干錯了”的現(xiàn)象存在，這完全是可以通過’拿捏需求’來避免的。

? ? ? ? 拿捏需求的辦法有很多，最重要的就是理清業(yè)務(wù)間的關(guān)系。比如說：我們大多數(shù)程序猿寫寫代碼會莫名其妙的停下來開始自言自語嘀嘀咕咕，不明白的人會覺得像個神經(jīng)病，自己跟自己講話。但實際上我們這種行為就是在針對眼下的需求邏輯進(jìn)行自我梳理，我們潛意識里就是試圖通過對外界的靜物(比如對著電腦)不斷描述自己的問題，來使自己回想出現(xiàn)這個問題時，都做了哪些步驟哪些事情，你會發(fā)現(xiàn)在那嘚吧嘚吧突然就會停下來，因為你好像找到了一點突破口，然后再回到代碼里或者業(yè)務(wù)點，慢慢把這個突破口扒開，干掉，問題就解決了，需求里的業(yè)務(wù)邏輯也瞬間了然于心。

? ? ? ? 所以，拿捏需求很簡單，可以通過自言自語的方式理清思路，也可以是其它的辦法，比如在關(guān)鍵時刻請別人幫忙分析一下難點，嘗試解決問題的這個過程中總會有一個點，讓你醍醐灌頂恍然大悟，有了清晰的業(yè)務(wù)邏輯，再進(jìn)行開發(fā)，工作簡直是一帆風(fēng)順。

? ? ? ? 但如果因為設(shè)計缺失而導(dǎo)致了變更，那不是猿們白干了，因為我們已經(jīng)完整的實現(xiàn)了已有的需求設(shè)計。如果非要說白干了，那也是BA白干了，因為是他們設(shè)計并提供的產(chǎn)品原型。所以，猿們要放平心態(tài)，擁抱變更，工作里的煩心事都會消失。

三.相親相愛猿與猿

? ? ? ? 沒有了對“需求變更”的怨氣，猿的工作開展就會舒服很多?？捎性车牡胤骄陀薪?，猿和猿之間也是有暗自較量的，團(tuán)隊管理者處理不好猿之間的關(guān)系，也會導(dǎo)致項目推進(jìn)狀況一團(tuán)糟。比如猿們工作量的衡量，大概很多人都聽過有些領(lǐng)導(dǎo)以每天或每周提交了多少行代碼作為猿的KPI考核標(biāo)準(zhǔn)，但是非要用代碼行數(shù)多少來衡量的話，那一個簡單的給margin的設(shè)置都可以略過margin:上右下左的簡寫方式,像下面這樣操作代碼: margin-top/margin-right/margin-bottom/margin-left，一下子就干出四行KPI來，但技術(shù)猿們都懂這是最笨的寫法，只是符合管理的KPI要求而已。而好的程序猿追求的都是精簡高效的代碼，實現(xiàn)同等效果，代碼量越少越清晰的猿才是秀兒里的王者。舉個最容易理解的栗子：?

? ? ? ? 小菜一次搬一塊磚，跑了一百次實現(xiàn)了老板要求的搬磚總量，而大咖自帶技能主動組裝了一輛車一次就可以搭載一百塊磚，只跑了一次就完成了老板的搬磚目標(biāo)。這能說小菜跑的次數(shù)比大咖跑的次數(shù)多出很多，所以小菜就是比大咖牛嗎？顯然不能，這是能力問題，不是次數(shù)問題。同理，程序猿的工作量是需要通過實現(xiàn)效果、代碼精簡程度、用時長短等多維度來考核的，不應(yīng)該用代碼行數(shù)多少來衡量猿們的強(qiáng)弱，否則程序質(zhì)量、代碼精簡度和高效工作就都不復(fù)存在了。

? ? ? ? 猿的視角看管理，會看出KPI弊端，也能看出人員流動問題、新老員工協(xié)作問題。

? ? ? ? 在人員流動問題上，Leader應(yīng)當(dāng)盡可能使核心團(tuán)隊保持穩(wěn)定；我們之前提到的輸出清晰的開發(fā)文檔和需求文檔，是有利于人員流動時更明確高效的迅速完成工作交接，使項目不會在一次次的交接中散架子。但人員流動我們不可避免，重要的是一定不要讓新人悶頭干，這很容易在猿們都不知情的狀況下埋上一籮筐的雷，而且大小不一，挖雷過程過分棘手。所以新人到一個項目里兩眼一抹黑，他們需要引路人，最好分配老成員帶動新人，讓他們知道項目是做什么的，什么角色要做什么，新人要做什么，項目的人員結(jié)構(gòu)如何，遇到什么類型問題應(yīng)該咨詢哪個角色的人都應(yīng)該讓新人被普及到，才能保障新人遇到難題時更高效的解決問題，不至于在問題的環(huán)繞下頭暈?zāi)X脹不知所措，只有讓他們進(jìn)入新項目的工作模式后才能迅速上手發(fā)揮新人的光和熱。

? ? ? ? 我以前很不懂為什么很多工作年限多的前輩反而用起新時代產(chǎn)物時畏手畏腳的，甚至表現(xiàn)出抗拒情緒來，后來才知道就是因為他們明白一旦新技術(shù)沒有調(diào)研好，摸著石頭過河會有很大的風(fēng)險導(dǎo)致在項目交付時的一地雞毛;而那些沒經(jīng)驗的新人才會初生牛犢不怕虎的干勁十足極度生猛，項目開工時，就春天里的萬物復(fù)蘇蓄勢待發(fā)一樣，啥技術(shù)新就把啥技術(shù)往上懟，但是往往到最后都成了霜打的茄子，暴露出很多難以解決的技術(shù)新型問題，導(dǎo)致項目進(jìn)度失控。

? ? ? ? 所以，在技術(shù)經(jīng)驗方面，請盡可能的不要簡單粗暴的認(rèn)為“都是增刪改查這種重復(fù)的工作，新老猿們差不多都行”，這種想法并不明智。增刪改查并不是重復(fù)的工作，不同的需求總是會帶著不同的業(yè)務(wù)邏輯，需要的增刪改查所附帶的程序邏輯自然也大有不同，想隨時隨地隨甲方的把增刪改查玩弄于股掌之間絕非易事。增刪改查融于業(yè)務(wù)邏輯和算法中，請不要拋開邏輯和算法讓增刪改查單飛，飛不高的啦。至少，沒有一定的量變、沒有強(qiáng)大的邏輯梳理能力和算法輸出能力，做不到讓需求里的增刪改查信手拈來。當(dāng)然，非要拿最長的工期配最簡單的a加b減c乘d來說事，那也是沒的談了。

四.猿江湖的大總管

? ? ? ? Leader就像是項目里的大總管，在任務(wù)分配和進(jìn)度管控方面，自然是任務(wù)拆分的越細(xì)膩越好。我曾在某項目中參與過任務(wù)拆解環(huán)節(jié)，主要是前端任務(wù)的拆分，并做排期計劃。我會在這個過程中發(fā)現(xiàn)很多對需求的新理解和業(yè)務(wù)邏輯的補(bǔ)充。所以，任務(wù)的拆分也是一個對需求深入探索，對技術(shù)設(shè)計初步預(yù)判的過程，技術(shù)團(tuán)隊管理者尤其需要這樣一個環(huán)節(jié)，唯一的弊端就是Leader要把大量的時間花在任務(wù)需求拆分上，但我覺得leader本身就是為了做好任務(wù)分配、量化工作進(jìn)度的，這不算是額外工作。比如說，單拿一個項目問你一共用多少人天，這樣的工期很難講，但分成多少個模塊每個模塊多少菜單每個菜單多少頁面一個頁面多少功能，這樣一個功能一共用多少人多久完成很容易更精確的計算出來，再反推一個頁面要多少人天完成，一個菜單要多少人天完成，以此類推，估算的整個項目的開發(fā)工期一定是相較于籠統(tǒng)估算出來的時間而言，更精確的。

? ? ? ? 其次，任務(wù)拆分的細(xì)膩，猿們工作起來也更清晰明了的知道自己每天每小時做什么，即將做什么，做過了什么，極大程度的減免了茫然松懈的狀態(tài)和消極怠工的情緒。沒有人偷懶，也就解決了KPI指標(biāo)量化的問題，畢竟誰在多少時間內(nèi)完成了多少任務(wù)一目了然，這些猿的工作能力在Leader的眼中也很清晰的呈現(xiàn)了出來。

? ? ? ? 簡而言之，每個人的工作任務(wù)都細(xì)分到天甚至每小時的程度上，項目井然有序的按流程進(jìn)行，讓大家都預(yù)判自己下一步和下下步甚至下下下步要做什么，便于猿們平衡好工作與個人生活，每個人都有條不紊，才有利于團(tuán)隊氛圍更融洽。所以要做好項目流程規(guī)劃和團(tuán)隊管理，這些細(xì)膩的任務(wù)分解工作很重要。

? ? ? ? 最后，要注重團(tuán)隊的公平維護(hù)，尤其是技術(shù)團(tuán)隊。不要讓忙的忙閑的閑，Leader們也無心關(guān)注調(diào)整，那樣會給技術(shù)骨干造成心理失衡。要知道，會認(rèn)真干活的猿一定是技術(shù)能力成長很快的那部分人才，等他們能力達(dá)到預(yù)期水平還沒有得到提升或崗位狀態(tài)薪資等等的同頻變化時，技術(shù)骨干會因為心理失衡離開。長此以往，團(tuán)隊里沉淀下來的都是垃圾，都愛摸魚都善摸魚，那這個團(tuán)隊即便再吸納進(jìn)來那些會發(fā)光發(fā)熱的新人也很難在這樣的氛圍里旋轉(zhuǎn)起來。

? ? ? ? 好啦，這就是小猿的緊急避險迅速成長職場手記分享。愿每個萌新猿都能學(xué)會與需求共舞，愿每個年輕的BA/PM都能從“猿”視角出發(fā)，去考量項目團(tuán)隊的管理和維護(hù)，愿我們都能做一個更高級的“猿”與更好的Leader。