項目管理

2015年，在App項目管理領(lǐng)域，仍沒有太大的進展。我悲觀的認為，App項目管理，已經(jīng)到了糟糕透頂?shù)牡夭健?/p>

從事傳統(tǒng)項目管理的工作人員，并沒有與時俱進，還在把舊的項目管理方式直接套用在App項目管理上。主要體現(xiàn)為傳統(tǒng)項目管理只涉及到產(chǎn)品經(jīng)理、開發(fā)和測試三個團隊，開發(fā)完畢介入測試，測試完畢隨時可以發(fā)布上線，如果一個團隊延期，另一個團隊可以做下一次迭代的工作。

但是App開發(fā)就不同了，涉及到產(chǎn)品經(jīng)理、Android、iOS、服務(wù)器、測試共計5個團隊的協(xié)作，有時還會牽扯進H5前端團隊，那就更復(fù)雜了。

App區(qū)別于傳統(tǒng)項目的另一點就在于它有發(fā)版時間限制。2周或4周的迭代時間，到了最后一天就必須要提交APpStore審核或發(fā)布到各大Android市場，一般不能延期，否則不光影響技術(shù)團隊，市場推廣團隊也會受到影響。哪個做不完或者測不完，就只能等下次發(fā)版再上，那就是一個月之后了。

既然迭代周期是固定的，App項目管理所關(guān)心的，就在于如何能在有限的時間內(nèi)完成盡可能多的需求，而不是每天糾結(jié)于“敏捷白板上的小紙條哪里格式不對了”這種形式主義的東西。

如果有可能，我真心想把每個公司所使用的項目管理工具（比如Wiki）廢棄了，工程師們往往是在項目完成后才更新Wiki上的項目狀態(tài)，而做不到即時更新。我只能在每次App發(fā)版后才看到大量項目的狀態(tài)變更。那我還要這種工具干什么呢？而過度的要求工程師實時使用Wiki來更新項目狀態(tài)，那無疑是重流程的軟件公司的打法，不適用于互聯(lián)網(wǎng)高速發(fā)展的文化。越是大公司，這種官僚文化越嚴重，迭代速度遠低于創(chuàng)業(yè)公司。因為互聯(lián)網(wǎng)公司現(xiàn)在錢很多，很多軟件公司的項目管理人員都跳槽到了大型互聯(lián)網(wǎng)公司，無形中就把這種文化也帶過來了。

說真的，我不喜歡循規(guī)蹈矩。我喜歡時刻去改變?nèi)L試，直到找到一條切實的解決方案，所以我經(jīng)常會到一線去，和團隊一起加班一起熬夜。在4年的App項目管理經(jīng)驗中，我觀察到的是，對于10人左右的小團隊，每天可以在晨會上把產(chǎn)品、Android、iOS、Server、QA的進度都過一遍，控制在10分鐘以內(nèi)。而對于40人左右的中型團隊，這時一般會按照Android、iOS這樣的技術(shù)工種細分為多個小團隊，每天晨會問技術(shù)經(jīng)理團隊的項目進度，他一般不會知曉團隊中每個成員的工作狀態(tài)，所以這樣的晨會是很沒有效率的。這時需要把團隊按照需求拆分為若干虛擬小團隊，每個需求的虛擬團隊都由產(chǎn)品經(jīng)理、具體的iOS開發(fā)、Android開發(fā)、Server開發(fā)和測試人員組成，采取產(chǎn)品經(jīng)理負責制，每天組織各自的晨會并發(fā)會議紀要。

項目管理人員手中應(yīng)該有一份所有人的名單，減去產(chǎn)品經(jīng)理日報中涉及的人力輸出，那么剩下來的人力，要么是請假了，要么是在做技術(shù)需求，還剩下來的人，就是真的沒事做了，浪費掉了。

這時團隊每個人的工作狀態(tài)就都一目了然了。我們不苛求每天都把人力充分使用，但至少要做到啞巴吃餃子——心里有數(shù)。

那種靠每周發(fā)周報的項目管理方式，屬于事后補救，難道我們要在一周之后才知道人員利用率不高而導(dǎo)致的項目風險嗎？這對于兩周發(fā)一次版本的App而言，多少有些可笑了。

我們不可能安排一個開發(fā)人員一個迭代只做一個需求，也許這個需求兩天就做完了，難道剩下的時間全都用于修bug嗎？這種敷衍的說法，用于哄弄那些不懂技術(shù)的老板的。剩下的時間應(yīng)該去做更多的需求，那么就會有人問什么時間修bug？兩周的迭代周期要怎么安排比較合理？

下面我給出兩周的迭代周期圖，這在我所從事的一家大型互聯(lián)網(wǎng)公司一直堅持到現(xiàn)在，兩年多了一直風雨無阻：

由上圖我們可以看出，

1. 開發(fā)只有第1周周二到第2周周三共計7天時間。
2. 測試團隊要在開發(fā)人員提測后立即介入，而不是等到所有項目都完成后統(tǒng)一測試。
3. 開發(fā)人力不足，一般是第1周加班；測試人力不足，一般是第2周加班，但沒有定式。
4. 第2周周三晚上為Code Complete，周五晚上為Code Freeze，這兩個點很關(guān)鍵，直接決定了是否要加班以及是否會延期。

當一個Task的開發(fā)時間，從3天（粗略評估）被壓縮到2天（精準評估）后，多出的1天時間做什么？

首先是看還能不能消化更多的需求。

其次，就是重構(gòu)，做技術(shù)需求。App領(lǐng)域有太多的技術(shù)需要升級，我分析過100多款國內(nèi)比較知名的App，發(fā)現(xiàn)各自的瑕疵都還是有很多的。Android的技術(shù)工作會更多，比如每次迭代要擠出1-2天時間來修復(fù)線上千奇百怪的崩潰。

最后，就是研究新技術(shù)。要時刻了解市面上的新思想和新技術(shù)。

上述這若干文字，都是在詮釋一個詞，節(jié)奏。

團隊多了自然就會有溝通上的障礙，從而導(dǎo)致效率大幅下降。而我的觀察是，只要讓所有團隊踩準了節(jié)奏，App和Server團隊同一時間聯(lián)調(diào)而不是互相等待，按時提測而不耽誤測試人員的進度，提前介入測試而不是前松后緊，當所有的團隊能夠踩住這幾個節(jié)奏，那么我們就能在有限的時間內(nèi)按時完成足夠多的需求。

2016年，我們應(yīng)該重點關(guān)注App的項目管理，多開幾次會各個公司分享一下經(jīng)驗，總結(jié)出一條好的方式來。

技術(shù)篇

接下來的篇幅，不限于Android或iOS。

2015年，各大互聯(lián)網(wǎng)公司開始經(jīng)營自己技術(shù)團隊的微信公眾號。以下是我收集到的幾個（排名不分先后哦），歡迎讀者補充更多的技術(shù)團隊公眾號：

• 淘寶：TaobaoTech
• 天貓：tmalltech
• 手淘：AlibabaMTT
• 微信：WeMobileDev
• QQ空間前端：QzoneWeb
• Bugly：weixinBugly
• 京東：JDTechEd
• 美團：meituantech
• 攜程：ctriptech
• 去哪兒：QunarTL
• 途牛：tuniutech
• 當當：當當Tech

此外還有技術(shù)社區(qū)的公眾號（排名不分先后哦）：

• InfoQ：infoqchina
• CSDN：mobilehub
• OSChina 開源中國：gh_430521f7587e
• 51CTO技術(shù)博客：blog51cto
• CocoaChina：cocoachinabbs

通過持續(xù)關(guān)注這些公眾號，尤其是無線相關(guān)的內(nèi)容，可以大致知道業(yè)界最新的技術(shù)趨勢，比如Android插件化編程，比如iOS瘦身。

2015年，對無線領(lǐng)域的技術(shù)分析正式擺上了臺面。之前肯定有公司也在小規(guī)模的做這個事情，只是不能多做宣傳罷了。

競品分析的手段一般分為幾種：

1）iOS的代碼是無法反編譯的，但是Android卻可以，大多數(shù)App做了代碼混淆，但也有的App直接裸奔就發(fā)到了市場上。即使代碼做了混淆，我們也能從關(guān)鍵片段中看出端倪來。關(guān)于這個技術(shù)我不能再講下去了，否則就要教壞小朋友了。目前看起來，對Android進行加固是一個好的辦法，也有一些公司從事這個領(lǐng)域，但還沒有廣泛應(yīng)用起來，比如說愛加密和梆梆。

2）所有的apk或ipa文件，都是壓縮包，我們將其后綴修改為zip格式，就可以解壓并看到其中的文件了。通過分析這些文件，我們可以學習到優(yōu)秀的公司是如何解決App體積大小、性能優(yōu)化新技術(shù)，一般的話，一個新的思想或新的技術(shù)，都會伴隨一個配置文件在App包中，比如ABTest。

此外，我們知道，Android App中的動畫，會放在Apk包res/anim目錄中，當我們喜歡某款A(yù)pp的動畫效果時，按圖索驥，直接可以在上述目錄中找到相應(yīng)的動畫文件；但是，當我們在ipa包中也看到類似的動畫文件時，那十有八九是這款A(yù)pp的iOS版本中，存在一個動畫引擎，iOS程序員可以把Android團隊的動畫文件直接復(fù)制過來就可以使用了。

2015年，我終于看到美團在App中使用ABTest來做產(chǎn)品。產(chǎn)品經(jīng)理可以根據(jù)線上A和B兩種策略各自的轉(zhuǎn)化率來迅速決策哪種策略更適合。

也許ABTest這門技術(shù)，其他公司早就開始在做了，只是沒有聲張而已，在此請不要笑話我的孤陋寡聞。我把自己在實施ABTest的一些經(jīng)驗分享出來，請參見下面這篇文章：http://blog.csdn.net/jspandasp/article/details/49339443

數(shù)據(jù)驅(qū)動產(chǎn)品——我認為這才是做產(chǎn)品的方式，而不是靠拍腦袋。稍微高級一點的產(chǎn)品經(jīng)理，會收集有利的數(shù)據(jù)來支撐自己要做的需求，而有意識的忽略那些不利的數(shù)據(jù)。這多少有些偷奸?；?，需求上線后的結(jié)果也是聽天由命大都結(jié)局不好。

產(chǎn)品需求分為兩個方向，一是剛需，二是交互和UI設(shè)計。

對于第一個方向，需要對這個領(lǐng)域浸染很多年，才能真正知道用戶和供應(yīng)鏈上的真正痛點，目前我見過這個方向最好的產(chǎn)品經(jīng)理就是楊威。也許以后還能遇到更好的，但是目前就是他了。2015年我有幸見到了他是怎么在幾個月內(nèi)從謀劃到調(diào)動整個部門完成了機票整個流程的改造，最后做出來一套逆向報價系統(tǒng)。

對于第二個方向，則多少有些自說自話了。一套好的UI設(shè)計怎么評定？首先是老板喜歡，這是因為一套設(shè)計不可能讓所有人都滿意，但只要老板滿意，就是好的設(shè)計，搞定了老板，后面的都好談；其次是風格要統(tǒng)一；再次是要時刻關(guān)注競爭對手的App改版。

對于好的交互設(shè)計又怎么評定？首先不能設(shè)計出“反人類”的交互；其次要看PV和UV數(shù)據(jù)，看哪里的轉(zhuǎn)化率低；再次看用戶反饋，廣泛吸取各方意見；最后看競品，取長補短。

無論哪個方向，都需要數(shù)據(jù)說話。運營才是王道，因為只有他們才能通過調(diào)整策略得到不同的數(shù)據(jù)，分析數(shù)據(jù)最終做出判斷。運營人員欠缺的就是不知道如何把需求組織成文檔給開發(fā)人員，這時候就輪到產(chǎn)品經(jīng)理出場了。

產(chǎn)品經(jīng)理應(yīng)該學點數(shù)學，能根據(jù)運營妹紙?zhí)峁┑臄?shù)據(jù)，總結(jié)成公式，才是好的產(chǎn)品經(jīng)理。數(shù)據(jù)驅(qū)動產(chǎn)品，重要的事情說三遍，不寫出來了，心中默念三遍即可。

接下來介紹一款由騰訊團隊于2015年發(fā)布的App尾隨測試的神器，GT（隨身調(diào)）。

2015年的最后一門技術(shù)，那就是App緩存命中率。

從事App開發(fā)的同學可能不清楚緩存命中率的概念。這一般是做在數(shù)據(jù)庫層面，對于頻繁訪問的數(shù)據(jù)，會放入緩存中，從而下次訪問時不會再執(zhí)行SQL語句，極大地節(jié)省了性能，但是也不能把所有的數(shù)據(jù)都放在緩存上哦，沒有那么大的控件。對此，我們的妥協(xié)方案是，設(shè)置一個閾值，大于這個閾值，緩存的時間會長一些；否則，就只有3分鐘后緩存就會失效。

其實這個思想也可以做在App層面，把相同的邏輯搬到App應(yīng)用中，從而減少訪問服務(wù)器的頻率。有些公司已經(jīng)在App所使用的服務(wù)器接口層面做了類似的緩存策略，但是還沒有在App中嘗試實施這種策略。

結(jié)束語

本人從事App開發(fā)4年時間。當初比較貪心，iOS和Android是一起學的，這就導(dǎo)致了精力要一分為二，結(jié)果哪門技術(shù)都做不到非常精深，而我又額外花費了很多時間在項目管理上，這也是我所喜愛的一個領(lǐng)域。所以上述若干文字，盤點了2015年App領(lǐng)域的若干新技術(shù)和新思想，但難免掛一漏萬，或文中觀點有所偏頗，還請各位讀者多多指教。

最后，再奉獻給讀者們一個建議。微信這個工具大家經(jīng)常使用吧，我們經(jīng)常收藏朋友圈中別人分享的一些好的技術(shù)文章，但當時看的并不是很仔細，是時候把2015年收藏的所有技術(shù)文章重新翻出來研讀一遍了，我這幾天就在干這個事情，收獲還是很大的。

本文由 @烏鴉 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。