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