項(xiàng)目管理2015年，在App項(xiàng)目管理領(lǐng)域，仍沒(méi)有太大的進(jìn)展。我悲觀的認(rèn)為，App項(xiàng)目管理，已經(jīng)到了糟糕透頂?shù)牡夭健?br /> 　　從事傳統(tǒng)項(xiàng)目管理的工作人員，并沒(méi)有與時(shí)俱進(jìn)，還在把舊的項(xiàng)目管理方式直接套用在App項(xiàng)目管理上。主要體現(xiàn)為傳統(tǒng)項(xiàng)目管理只涉及到產(chǎn)品經(jīng)理、開(kāi)發(fā)和測(cè)試三個(gè)團(tuán)隊(duì)，開(kāi)發(fā)完畢介入測(cè)試，測(cè)試完畢隨時(shí)可以發(fā)布上線(xiàn)，如果一個(gè)團(tuán)隊(duì)延期，另一個(gè)團(tuán)隊(duì)可以做下一次迭代的工作。
　　但是App開(kāi)發(fā)就不同了，涉及到產(chǎn)品經(jīng)理、Android、iOS、服務(wù)器、測(cè)試共計(jì)5個(gè)團(tuán)隊(duì)的協(xié)作，有時(shí)還會(huì)牽扯進(jìn)H5前端團(tuán)隊(duì)，那就更復(fù)雜了。
　　App區(qū)別于傳統(tǒng)項(xiàng)目的另一點(diǎn)就在于它有發(fā)版時(shí)間限制。2周或4周的迭代時(shí)間，到了最后一天就必須要提交APpStore審核或發(fā)布到各大Android市場(chǎng)，一般不能延期，否則不光影響技術(shù)團(tuán)隊(duì)，市場(chǎng)推廣團(tuán)隊(duì)也會(huì)受到影響。哪個(gè)做不完或者測(cè)不完，就只能等下次發(fā)版再上，那就是一個(gè)月之后了。
　　既然迭代周期是固定的，App項(xiàng)目管理所關(guān)心的，就在于如何能在有限的時(shí)間內(nèi)完成盡可能多的需求，而不是每天糾結(jié)于“敏捷白板上的小紙條哪里格式不對(duì)了”這種形式主義的東西。
　　如果有可能，我真心想把每個(gè)公司所使用的項(xiàng)目管理工具（比如Wiki）廢棄了，工程師們往往是在項(xiàng)目完成后才更新Wiki上的項(xiàng)目狀態(tài)，而做不到即時(shí)更新。我只能在每次App發(fā)版后才看到大量項(xiàng)目的狀態(tài)變更。那我還要這種工具干什么呢？而過(guò)度的要求工程師實(shí)時(shí)使用Wiki來(lái)更新項(xiàng)目狀態(tài)，那無(wú)疑是重流程的軟件公司的打法，不適用于互聯(lián)網(wǎng)高速發(fā)展的文化。越是大公司，這種官僚文化越嚴(yán)重，迭代速度遠(yuǎn)低于創(chuàng)業(yè)公司。因?yàn)榛ヂ?lián)網(wǎng)公司現(xiàn)在錢(qián)很多，很多軟件公司的項(xiàng)目管理人員都跳槽到了大型互聯(lián)網(wǎng)公司，無(wú)形中就把這種文化也帶過(guò)來(lái)了。
　　說(shuō)真的，我不喜歡循規(guī)蹈矩。我喜歡時(shí)刻去改變?nèi)L試，直到找到一條切實(shí)的解決方案，所以我經(jīng)常會(huì)到一線(xiàn)去，和團(tuán)隊(duì)一起加班一起熬夜。在4年的App項(xiàng)目管理經(jīng)驗(yàn)中，我觀察到的是，對(duì)于10人左右的小團(tuán)隊(duì)，每天可以在晨會(huì)上把產(chǎn)品、Android、iOS、Server、QA的進(jìn)度都過(guò)一遍，控制在10分鐘以?xún)?nèi)。而對(duì)于40人左右的中型團(tuán)隊(duì)，這時(shí)一般會(huì)按照Android、iOS這樣的技術(shù)工種細(xì)分為多個(gè)小團(tuán)隊(duì)，每天晨會(huì)問(wèn)技術(shù)經(jīng)理團(tuán)隊(duì)的項(xiàng)目進(jìn)度，他一般不會(huì)知曉團(tuán)隊(duì)中每個(gè)成員的工作狀態(tài)，所以這樣的晨會(huì)是很沒(méi)有效率的。這時(shí)需要把團(tuán)隊(duì)按照需求拆分為若干虛擬小團(tuán)隊(duì)，每個(gè)需求的虛擬團(tuán)隊(duì)都由產(chǎn)品經(jīng)理、具體的iOS開(kāi)發(fā)、Android開(kāi)發(fā)、Server開(kāi)發(fā)和測(cè)試人員組成，采取產(chǎn)品經(jīng)理負(fù)責(zé)制，每天組織各自的晨會(huì)并發(fā)會(huì)議紀(jì)要。
　　項(xiàng)目管理人員手中應(yīng)該有一份所有人的名單，減去產(chǎn)品經(jīng)理日?qǐng)?bào)中涉及的人力輸出，那么剩下來(lái)的人力，要么是請(qǐng)假了，要么是在做技術(shù)需求，還剩下來(lái)的人，就是真的沒(méi)事做了，浪費(fèi)掉了。
　　這時(shí)團(tuán)隊(duì)每個(gè)人的工作狀態(tài)就都一目了然了。我們不苛求每天都把人力充分使用，但至少要做到啞巴吃餃子——心里有數(shù)。
　　那種靠每周發(fā)周報(bào)的項(xiàng)目管理方式，屬于事后補(bǔ)救，難道我們要在一周之后才知道人員利用率不高而導(dǎo)致的項(xiàng)目風(fēng)險(xiǎn)嗎？這對(duì)于兩周發(fā)一次版本的App而言，多少有些可笑了。
　　我們不可能安排一個(gè)開(kāi)發(fā)人員一個(gè)迭代只做一個(gè)需求，也許這個(gè)需求兩天就做完了，難道剩下的時(shí)間全都用于修bug嗎？這種敷衍的說(shuō)法，用于哄弄那些不懂技術(shù)的老板的。剩下的時(shí)間應(yīng)該去做更多的需求，那么就會(huì)有人問(wèn)什么時(shí)間修bug？?jī)芍艿牡芷谝趺窗才疟容^合理？
開(kāi)發(fā)只有第1周周二到第2周周三共計(jì)7天時(shí)間。測(cè)試團(tuán)隊(duì)要在開(kāi)發(fā)人員提測(cè)后立即介入，而不是等到所有項(xiàng)目都完成后統(tǒng)一測(cè)試。開(kāi)發(fā)人力不足，一般是第1周加班；測(cè)試人力不足，一般是第2周加班，但沒(méi)有定式。第2周周三晚上為Code Complete，周五晚上為Code Freeze，這兩個(gè)點(diǎn)很關(guān)鍵，直接決定了是否要加班以及是否會(huì)延期。
　　當(dāng)一個(gè)Task的開(kāi)發(fā)時(shí)間，從3天（粗略評(píng)估）被壓縮到2天（精準(zhǔn)評(píng)估）后，多出的1天時(shí)間做什么？
　　首先是看還能不能消化更多的需求。
　　其次，就是重構(gòu)，做技術(shù)需求。App領(lǐng)域有太多的技術(shù)需要升級(jí)，我分析過(guò)100多款國(guó)內(nèi)比較知名的App，發(fā)現(xiàn)各自的瑕疵都還是有很多的。Android的技術(shù)工作會(huì)更多，比如每次迭代要擠出1-2天時(shí)間來(lái)修復(fù)線(xiàn)上千奇百怪的崩潰。
　　最后，就是研究新技術(shù)。要時(shí)刻了解市面上的新思想和新技術(shù)。
　　上述這若干文字，都是在詮釋一個(gè)詞，節(jié)奏。
　　團(tuán)隊(duì)多了自然就會(huì)有溝通上的障礙，從而導(dǎo)致效率大幅下降。而我的觀察是，只要讓所有團(tuán)隊(duì)踩準(zhǔn)了節(jié)奏，App和Server團(tuán)隊(duì)同一時(shí)間聯(lián)調(diào)而不是互相等待，按時(shí)提測(cè)而不耽誤測(cè)試人員的進(jìn)度，提前介入測(cè)試而不是前松后緊，當(dāng)所有的團(tuán)隊(duì)能夠踩住這幾個(gè)節(jié)奏，那么我們就能在有限的時(shí)間內(nèi)按時(shí)完成足夠多的需求。
　　2016年，我們應(yīng)該重點(diǎn)關(guān)注App的項(xiàng)目管理，多開(kāi)幾次會(huì)各個(gè)公司分享一下經(jīng)驗(yàn)，總結(jié)出一條好的方式來(lái)。
　　技術(shù)篇接下來(lái)的篇幅，不限于Android或iOS。
　　2015年，各大互聯(lián)網(wǎng)公司開(kāi)始經(jīng)營(yíng)自己技術(shù)團(tuán)隊(duì)的微信公眾號(hào)。以下是我收集到的幾個(gè)（排名不分先后哦），歡迎讀者補(bǔ)充更多的技術(shù)團(tuán)隊(duì)公眾號(hào)：
　　淘寶：TaobaoTech天貓：tmalltech手淘：AlibabaMTT微信：WeMobileDevQQ空間前端：QzoneWebBugly：weixinBugly京東：JDTechEd美團(tuán)：meituantech攜程：ctriptech去哪兒：QunarTL途牛：tuniutech當(dāng)當(dāng)：當(dāng)當(dāng)Tech
　　此外還有技術(shù)社區(qū)的公眾號(hào)（排名不分先后哦）：
　　InfoQ：infoqchinaCSDN：mobilehubOSChina 開(kāi)源中國(guó)：gh_430521f7587e51CTO技術(shù)博客：blog51ctoCocoaChina：cocoachinabbs
　　通過(guò)持續(xù)關(guān)注這些公眾號(hào)，尤其是無(wú)線(xiàn)相關(guān)的內(nèi)容，可以大致知道業(yè)界最新的技術(shù)趨勢(shì)，比如Android插件化編程，比如iOS瘦身。
　　2015年，對(duì)無(wú)線(xiàn)領(lǐng)域的技術(shù)分析正式擺上了臺(tái)面。之前肯定有公司也在小規(guī)模的做這個(gè)事情，只是不能多做宣傳罷了。
　　競(jìng)品分析的手段一般分為幾種：
　　1）iOS的代碼是無(wú)法反編譯的，但是Android卻可以，大多數(shù)App做了代碼混淆，但也有的App直接裸奔就發(fā)到了市場(chǎng)上。即使代碼做了混淆，我們也能從關(guān)鍵片段中看出端倪來(lái)。關(guān)于這個(gè)技術(shù)我不能再講下去了，否則就要教壞小朋友了。目前看起來(lái)，對(duì)Android進(jìn)行加固是一個(gè)好的辦法，也有一些公司從事這個(gè)領(lǐng)域，但還沒(méi)有廣泛應(yīng)用起來(lái)，比如說(shuō)愛(ài)加密和梆梆。
　　2）所有的apk或ipa文件，都是壓縮包，我們將其后綴修改為zip格式，就可以解壓并看到其中的文件了。通過(guò)分析這些文件，我們可以學(xué)習(xí)到優(yōu)秀的公司是如何解決App體積大小、性能優(yōu)化新技術(shù)，一般的話(huà)，一個(gè)新的思想或新的技術(shù)，都會(huì)伴隨一個(gè)配置文件在App包中，比如ABTest。
　　此外，我們知道，Android App中的動(dòng)畫(huà)，會(huì)放在Apk包res/anim目錄中，當(dāng)我們喜歡某款A(yù)pp的動(dòng)畫(huà)效果時(shí)，按圖索驥，直接可以在上述目錄中找到相應(yīng)的動(dòng)畫(huà)文件；但是，當(dāng)我們?cè)趇pa包中也看到類(lèi)似的動(dòng)畫(huà)文件時(shí)，那十有八九是這款A(yù)pp的iOS版本中，存在一個(gè)動(dòng)畫(huà)引擎，iOS程序員可以把Android團(tuán)隊(duì)的動(dòng)畫(huà)文件直接復(fù)制過(guò)來(lái)就可以使用了。
　　2015年，我終于看到美團(tuán)在App中使用ABTest來(lái)做產(chǎn)品。產(chǎn)品經(jīng)理可以根據(jù)線(xiàn)上A和B兩種策略各自的轉(zhuǎn)化率來(lái)迅速?zèng)Q策哪種策略更適合。
　　也許ABTest這門(mén)技術(shù)，其他公司早就開(kāi)始在做了，只是沒(méi)有聲張而已，在此請(qǐng)不要笑話(huà)我的孤陋寡聞。我把自己在實(shí)施ABTest的一些經(jīng)驗(yàn)分享出來(lái)，請(qǐng)參見(jiàn)下面這篇文章：http://blog.csdn.net/jspandasp/article/details/49339443
　　數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品——我認(rèn)為這才是做產(chǎn)品的方式，而不是靠拍腦袋。稍微高級(jí)一點(diǎn)的產(chǎn)品經(jīng)理，會(huì)收集有利的數(shù)據(jù)來(lái)支撐自己要做的需求，而有意識(shí)的忽略那些不利的數(shù)據(jù)。這多少有些偷奸耍滑，需求上線(xiàn)后的結(jié)果也是聽(tīng)天由命大都結(jié)局不好。
　　產(chǎn)品需求分為兩個(gè)方向，一是剛需，二是交互和UI設(shè)計(jì)。
　　對(duì)于第一個(gè)方向，需要對(duì)這個(gè)領(lǐng)域浸染很多年，才能真正知道用戶(hù)和供應(yīng)鏈上的真正痛點(diǎn)，目前我見(jiàn)過(guò)這個(gè)方向最好的產(chǎn)品經(jīng)理就是楊威。也許以后還能遇到更好的，但是目前就是他了。2015年我有幸見(jiàn)到了他是怎么在幾個(gè)月內(nèi)從謀劃到調(diào)動(dòng)整個(gè)部門(mén)完成了機(jī)票整個(gè)流程的改造，最后做出來(lái)一套逆向報(bào)價(jià)系統(tǒng)。
　　對(duì)于第二個(gè)方向，則多少有些自說(shuō)自話(huà)了。一套好的UI設(shè)計(jì)怎么評(píng)定？首先是老板喜歡，這是因?yàn)橐惶自O(shè)計(jì)不可能讓所有人都滿(mǎn)意，但只要老板滿(mǎn)意，就是好的設(shè)計(jì)，搞定了老板，后面的都好談；其次是風(fēng)格要統(tǒng)一；再次是要時(shí)刻關(guān)注競(jìng)爭(zhēng)對(duì)手的App改版。
　　對(duì)于好的交互設(shè)計(jì)又怎么評(píng)定？首先不能設(shè)計(jì)出“反人類(lèi)”的交互；其次要看PV和UV數(shù)據(jù)，看哪里的轉(zhuǎn)化率低；再次看用戶(hù)反饋，廣泛吸取各方意見(jiàn)；最后看競(jìng)品，取長(zhǎng)補(bǔ)短。
　　無(wú)論哪個(gè)方向，都需要數(shù)據(jù)說(shuō)話(huà)。運(yùn)營(yíng)才是王道，因?yàn)橹挥兴麄儾拍芡ㄟ^(guò)調(diào)整策略得到不同的數(shù)據(jù)，分析數(shù)據(jù)最終做出判斷。運(yùn)營(yíng)人員欠缺的就是不知道如何把需求組織成文檔給開(kāi)發(fā)人員，這時(shí)候就輪到產(chǎn)品經(jīng)理出場(chǎng)了。
　　產(chǎn)品經(jīng)理應(yīng)該學(xué)點(diǎn)數(shù)學(xué)，能根據(jù)運(yùn)營(yíng)妹紙?zhí)峁┑臄?shù)據(jù)，總結(jié)成公式，才是好的產(chǎn)品經(jīng)理。數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品，重要的事情說(shuō)三遍，不寫(xiě)出來(lái)了，心中默念三遍即可。
　　接下來(lái)介紹一款由騰訊團(tuán)隊(duì)于2015年發(fā)布的App尾隨測(cè)試的神器，GT（隨身調(diào)）。
　　2015年的最后一門(mén)技術(shù)，那就是App緩存命中率。
　　從事App開(kāi)發(fā)的同學(xué)可能不清楚緩存命中率的概念。這一般是做在數(shù)據(jù)庫(kù)層面，對(duì)于頻繁訪問(wèn)的數(shù)據(jù)，會(huì)放入緩存中，從而下次訪問(wèn)時(shí)不會(huì)再執(zhí)行SQL語(yǔ)句，極大地節(jié)省了性能，但是也不能把所有的數(shù)據(jù)都放在緩存上哦，沒(méi)有那么大的控件。對(duì)此，我們的妥協(xié)方案是，設(shè)置一個(gè)閾值，大于這個(gè)閾值，緩存的時(shí)間會(huì)長(zhǎng)一些；否則，就只有3分鐘后緩存就會(huì)失效。
　　其實(shí)這個(gè)思想也可以做在App層面，把相同的邏輯搬到App應(yīng)用中，從而減少訪問(wèn)服務(wù)器的頻率。有些公司已經(jīng)在App所使用的服務(wù)器接口層面做了類(lèi)似的緩存策略，但是還沒(méi)有在App中嘗試實(shí)施這種策略。
　　結(jié)束語(yǔ)本人從事App開(kāi)發(fā)4年時(shí)間。當(dāng)初比較貪心，iOS和Android是一起學(xué)的，這就導(dǎo)致了精力要一分為二，結(jié)果哪門(mén)技術(shù)都做不到非常精深，而我又額外花費(fèi)了很多時(shí)間在項(xiàng)目管理上，這也是我所喜愛(ài)的一個(gè)領(lǐng)域。所以上述若干文字，盤(pán)點(diǎn)了2015年App領(lǐng)域的若干新技術(shù)和新思想，但難免掛一漏萬(wàn)，或文中觀點(diǎn)有所偏頗，還請(qǐng)各位讀者多多指教。
　　最后，再奉獻(xiàn)給讀者們一個(gè)建議。微信這個(gè)工具大家經(jīng)常使用吧，我們經(jīng)常收藏朋友圈中別人分享的一些好的技術(shù)文章，但當(dāng)時(shí)看的并不是很仔細(xì)，是時(shí)候把2015年收藏的所有技術(shù)文章重新翻出來(lái)研讀一遍了，我這幾天就在干這個(gè)事情，收獲還是很大的。