回憶剛加入騰訊電商的時候，一切都讓初上手的筆者心里很忐忑，這里木有傳統項目的大計劃，木有非常清晰的傳統標準需求規格說明書，各種木有，大家都是短打上陣，迅速奔跑。同時項目小而密集，一周兩次發布，需求如雨而來，與已往所做過的動輒一兩年，再短也得三個月以上的項目相比，實在有點靈巧得超出預期，一度顛覆了筆者對項目這一概念的認知。所幸遇到了不錯的導師，還有很給力的兄弟們。在半年的摸索和試探里，兄弟們被筆者幾經折騰，依然一如既往的支持，感謝導師和團隊的兄弟們。如今半年過去，各種苦澀的糾結，甜美的回味，寫下來與各位分享，懇請各位高手拍磚指點。

　　行文之前，先做個概要的鋪墊，按時間順序，將要展開的內容要點如下：

多看多問，小步演進;明確方向，聚焦重點;

梳理流程，培養習慣;鼓勵溝通，增進效率;

明晰責任，接口清晰;適度計劃，有序敏捷;

理念宣導，水到渠成;開放合作，共同成長。

這些內容都是從初加入團隊至今的體會，也是一路走過來歷程，自然不只是以上的泛泛概要，且看一一展開。

多看多問，小步演進

每一個有理想的青年，在被委以重任的時候，都希望自己立馬能運籌帷幄，氣死諸葛賽過子房，三把火一燒，令旗所至莫不如臂使指。事實上理想很豐滿，現實很骨感，三把火下來，要么是燒得一鍋焦黑，要么是燒得一鍋夾生。

　　多虧導師一再叮囑，要求多看多問，因此筆者就靜悄悄的把自己的火把給滅了，靜下心來好好觀察。這時候問了自己三個問題：

1、 電商整體的開發模式是什么樣的;

2、 團隊目前面對的問題是什么;

3、 項目經理在這個團隊的位置在哪里;

要把這三個問題回答完是一篇很長的文章，在此不多說什么，這里表達的意思在于，當PM們初到一個新團隊時，是以一個中醫望聞問切的方式來介入，還是以目前流行的暴力強拆的方式來介入。特別是傳統IT項目經理出身的同學，必須正視互聯網在項目管理方面的特殊性，需要柔性融入，小步推進，在保持團隊產出的情況下，進一步提升團隊效率。

　　筆者在初入團隊的時候，自然是用的望聞問切：

– 望，望團隊氣氛，所處環境，工作方式;

– 聞，有人可能會問，團隊有可以被聞到的東西吧，告訴你有的，那就是團隊成員身上散發出來的情緒的味道，人家一般不說也不寫在臉，但用心是可以聞到的;

– 問，上面提的三個是問自己的，除此外還要問團隊，比如問團隊自身覺得哪里感覺不舒服，哪里感覺很麻煩，總歸以探知當前痛點為目標;

– 切，表象看過，就得深入的來了解，切就是扎實的去切入一些實際工作，從實踐中來驗證，來發現各種好的要保留的亮點，以及各種要調整的痛點。

　　下面筆者來分享下初期筆者們搞的水果會的故事，這也是個關于望聞問切的故事。

小技巧分享之水果會：剛到組內的時候，初看一輪，很不習慣，發現居然沒有例會，是為望。繼續深入發現新來的同學，不僅是筆者本人，在初期都散發著惆悵的味道，因為距離感消除起來有點難，是為聞。一輪訪談下來，同志們普遍反應例會還是需要開的，只是沒人有空來組織，是為問。初入的頭兩周，沒有例行的固定時間來集中進行各種交流與反饋，讓日常的各項工作很難整體集中統籌起來，此為切。把脈完畢，開始對癥下藥，團隊例會必須開，團隊建設也必須開搞，但是，是分開做?還是合起來做?筆者的答案是合起來，既是團隊例會，又是常規團隊建設。怎么做呢?首先與開發Leader溝通，爭取了些經費，在每期例會上買上一些水果，例會名為水果會，先談正事，后吃水果敞開交流，例會的氣氛活躍了很多，而且正事團建兩相宜。

項目管理是件很靈活的事，望聞問切能讓筆者們一開始就是以團隊的需求來作為切入點,進而打開符合團隊長期利益的持續改進之門。同時各種以人為本的小技巧或許能收到奇效，大家盡可以揮灑創意，做到更好。

明確方向，聚焦重點

　　在開始這部分的時候，先提幾個很實際的問題在前面：

– 團隊天天很忙，但各方仍然說沒支持到，怎么辦?

– 需求從很多方向來，可做可不做，怎么辦?

– 各種零散咨詢，支持要求滿天飛，怎么辦?

這些問題現實中在老團隊里很普遍，作為一個運作了很多年的團隊，我們團隊其實挺苦逼，除了電商主平臺外，其它各項業務都有支持，你來我往好不熱鬧，但是團隊成員只有那么多，頗有疲于奔命的架勢。

在經過第一輪的望聞問切后，可以發現以團隊目前的人力情況，只能對現有的主平臺進行全力支持，否則確實是力有不逮。因此團隊內部已經高度一致的希望把支持的業務進行聚焦，重回到主平臺的支持和基礎技術框架本身的持續改進上來，只是一直沒有想好來怎么進行切割聚焦。

這對團隊而言是一件迫在眉睫的事情，得不到好的處理，就會把團隊拖到一個個泥塘里，在這個泥塘里，各個上游無法得到充分滿足，自己苦于奔命，下游測試與運維也一樣深陷其中。這個時候，需要幫助團隊一起來進行團隊方向的確定，然后找各級老板溝通，重新定位團隊的位置與目標，進行適當的業務切割。

　　有人問，你說聚焦就聚焦啊，太水了，木得干貨，那咱就上干貨，團隊在打算聚焦時，進行了以下考慮：

1、目前支撐的業務中，是否都與公司及部門戰略相合?

2、公司及部門戰略顯示不適宜由筆者們支撐的業務，是否可以整體逐步移交出去?

3、公司及部門戰略顯示應由筆者們支撐的業務，是否可以把高度定制化部分移交出去?

4、這些移交是否會對公司及部門的長期利益造成損害?

前三點，是團隊在進行業務篩選時的一些要點，而最后一點是團隊決定是否移交的終極原則。如果違背第4條，奉勸大家就不要提移交了，這必須是團隊份內的事。因為有產品經理們和技術Leader的長期積累，聚焦方案出來得比較快，同時非常幸運的是，團隊的聚焦嘗試得到了各位領導的大力支持，最終某些業務被全移交，某些業務定制化部分被移交，很順暢的實現了再次聚焦。

如果一個團隊已經處于疲于奔命狀態，那么一定需要審視下自己的業務，關注下團隊是否還是聚焦在自己的主業務上，精力是有限的，畢竟團隊里的兄弟都不是葉問。

　　梳理流程，培養習慣

　　團隊初步融入了，業務也聚焦了，問題仍然有，比如：

– 需求仍然飛舞，開發排期依然困惑無比，怎么辦?

– 開發兄弟做了很多工作，但外界仍然一再的問，你們到底在做什么，怎么辦?

– 產品經理每每要想知道進度就只能找到對應開發兄弟時常催問，怎么辦?

– 測試天天反饋說，這轉測的也太隨機了，忽而來一個，忽而又來一個，沒有個計劃也沒個通知，怎么辦?

– 運維說你們的發布太亂了，太隨意了，怎么辦?

– 其他各兄弟部門說，想要跟你們合作，需求到底要腫么提，提了你們會不會做，怎么辦?

其實這一堆的問題，都是涉及到流程的問題，具體而言，就是需求找誰提，需求達到什么標準可以排期，測試什么時候介入，信息在哪里公布等等。

　　工欲善其事，必先利其器，工具是非常重要的，有的人用微軟的Project，有人用Excel，也有人只用白板。電商一直用的是公司自研的研發管理平臺，老實說這個平臺工具并不算是較完美的工具，但是結合現實靈活運用好，也能給團隊帶來較大的幫助。因此結合研發管理平臺，解決以上的問題團隊用了以下的辦法：

1、 所有需求都必須提到研發管理平臺，需求都必須經過產品組的產品經理接入，解決需求來源的問題;

2、 所有需求都必須產品經理與對應開發評審過后才能流轉到需求就緒，產品組必須在組內對需求評級，這樣有效解決了排期難的問題，排期目標變得明確;

3、 排期權收歸項目經理與開發Leader手上，把控入口，讓開發及后續執行流程得到保障，也有效避免了所謂的黑活;

4、 排期與評審時，開發、測試、產品三方共同參與，解決了測試直到轉測才知情的問題，也有效促進了各環節的積極溝通與協作;

5、 向外界約定，所有進度與需求信息從研發管理平臺獲取，借助研發管理平臺實現信息透明。

事實上所出的措施并不多，但產生的效果是很顯著的，目前團隊的常規排期會，每周只需不到半小時的時間，測試與開發協作也順暢了很多，需求流程清晰，各方也不會再困惑于怎么提交需求。由于所有的信息都在研發管理平臺上流轉了起來，信息高度的被集中，同時具備了可信度，且隨時可探查。任何人想知道團隊在做什么都變得很簡單，打開團隊的研發管理平臺，都在那里，最大限度的利用工具做到信息的公開透明。

流程并不需要很復雜，流程在這里的作用是讓事情有章可循，讓工作順暢有序，好的流程不帶來麻煩，只帶來有序、效率和透明的工作信息。不是因為規范而需要流程，是因為效率，秩序和溝通而需要流程。

小技巧分享：應用研發管理平臺在實踐中最痛苦的莫過于，讓每一條信息的狀態與實際情況進行同步。剛開始的時候，大多數人都是不習慣去系統里同步狀態的，筆者團隊也有這樣的苦惱。為了改善這種情況，啟用了個無傷大雅的懲罰措施，每周例會審查時，如果有人沒有及時更新，那么就必須捐十塊錢到團隊的水果基金。開發leader和團隊成員一視同仁，在此感謝兄弟們，在筆者屢次找兄弟們要水果基金時，兄弟的積極配合，欣慰的是，現在收基金越來越難了，因為這代表著同步狀態已經成了一種習慣，再次感謝兄弟們的配合。

象征性小捐獻也好，類似小紅花小蔫花也罷，真實目標是在流程執行過程中促進習慣的養成，最終產生新的習慣來主動驅動流程，使之融入團隊的血液之中?；ヂ摼W人都是主動，積極，有獨立思想的人，催工的鞭子并不適宜揮舞在這里。在這里好的團隊是不用催的，好的團隊是兄弟們都會主動的習慣性把所有好的，或不好的消息傳遞過來，然后大家伙一起去解決，或一起去歡呼。

　　鼓勵溝通，增進效率

　　筆者也是個老程序員，仍然清晰的記得以下幾個比較鮮明的場景：

– Boss問，為什么做成這樣子，答曰產品讓干的，Boss批曰，豬腦啊讓干啥干啥;

– 做了個牛逼的產品正等表揚，這天Boss發了嘉獎郵件，木有自己名字，悲憤不已，心頭升起小小的幽怨，不滿積攢中;

– 又見兄弟慨嘆懷才不遇，Boss有眼無珠，悄悄然裸辭遠去，心生悲涼。

稍年長后回顧，真的是Boss無眼么，真的是產品不靠譜么，非也非也，只是自己放棄了表達的權力，被動，被動，一再被動，從而真的就把自己藏到墻角里去，于司于已，兩不落好。

每個悶騷的程序員心里都住著一個哲學家，筆者最愿用裝滿餃子的茶壺來比喻開發的兄弟們。他們都很有才，但是他們都很沉默。無論多么不合理的需求，他們都習慣性的輕微抵抗后，就開始埋頭專心的想著去怎么實現。無論做出的產品多么牛逼，在慶祝郵件里即便沒有列上他們的名字，他們也只會默默的在心里感慨下苦逼而已。很多人說，這跟效率有關系嗎?筆者要說，大有關系，非常有關系!

筆者至今工作也不算太長，以經驗論，相比較而言一個樂于表達自己心情，時常保持心情愉悅的開發兄弟，是最有戰斗力的開發兄弟，也是最不可能默默的跳槽讓你郁悶到哭的開發兄弟;一個樂于分享的開發兄弟，是能最快成長，也最能幫助提高整個團隊戰斗力的開發兄弟;一個能在需求涌來時，敢于且擅于表達正確意見的開發兄弟，就像一尊門神，是個能保證團隊的產出永遠是高質量的開發兄弟。

　　團隊半年里在這方面的做法是：

– 開設雙周分享，每期讓開發兄弟們上去分享自己的心得與體會;

– 在需求評審時，要求至少要問到為什么、有沒有其它更好方案等;

– 鼓勵兄弟們互相間的溝通，鼓勵兄弟們從RTX里走出來，面對面的交流;

– 鼓勵兄弟們就自己的工作、團隊的各方面提出優化建議;

– 例會上，雖然研發管理平臺已經有足夠的信息，仍然要求兄弟們進行自由表達。

每個開發兄弟都是一座富礦，PM們要讓兄弟們不只是會茶壺口微微冒熱氣，PM們還要讓兄弟們勇于把茶壺蓋打開，亮出自己一肚子的熱騰騰細細煮好的餃子，之后就靜待神奇的收獲吧。以筆者團隊的雙周分享為例，每一期的內容和分享時的妙語連珠都時常讓人贊嘆不已?，F在，團隊的目標是，下半年，爭取讓部分開發兄弟走上整個電商的大講堂。

溝通是個很系統的工程，我們沒有辦法可以一下子提高所有人的溝通能力，但是我們可以去鼓勵溝通行為的本身，從而提高溝通的意愿與能力。

　　明晰責任，接口清晰

責任是一件很有趣事情，一旦分攤到很多人身上，大家就會習慣性的將其從自己身上寄托到其他人身上，這與高尚與否無關，就像筆者老家常說的，一龍治水糧滿倉，二龍治水河底干。

　　在筆者的團隊，起初相關矛盾會出現在兩個地方：

– 需求狀態不透明，不能快速哪些需求可以進行排期，哪些需求其實已經發布完;

– 外部向團隊提需求時，可能是找TL，可能是找幾個產品經理中的某一個，也有可能直接是找開發兄弟或項目經理;

這其實導致了一些混亂，第一點解決比較簡單的，需求都可以進行充分拆解，落實到人，一來責任清晰了，二來工作量評估也可以更為準確。再輔以前述的水果會基金捐獻制度，需求狀態的流轉更及時可信。目前流程定下來后，經過一段時間以來的實施，大家已經形成了每天去查看狀態并流轉的好習慣，水果基金的捐款收取難度是越來越高了。

　　第二點就會比較麻煩些，需要團隊內外雙向的互動來推動，最后定了幾條基本的準則：

– 所有需求，都必須由產品組進行對接評估，通過后再與開發側、測試側共同評審;

– 開發人員，開發Leader和項目經理在接到外部需求時，需引入相應產品經理介入跟進;

– 產品組按目前業務方向，對人員進行分工，明確相關責任與接口方向，在各方來提需求時，可以方便的找到對應的產品接口人。

曾經需求來時，開發組就像草船借箭中的草人，每每被劈頭蓋臉的需求直接轟擊，膝蓋都不知道中了多少箭。幾板斧下來，首先是進行產品組，開發組的責任劃分，然后進一步定位好產品接口人，一下子天空清凈，蝗蟲箭雨再也沒有了，需求開始像涓涓流水從產品組緩緩而來。在此感謝產品組兄弟們在前線的辛苦工作與支持。

在兄弟們被各種外來的嘈雜折騰得煩不勝煩的時候，我們應去傾聽各種報怨，鼓勵說出真實的心聲，從而想辦法通過厘清責任，重新界定各自的權力與義務，來讓事情重新順暢清爽起來。

　　適度計劃，有序敏捷

　　初到團隊的時候，每每有人問筆者：

– 可不可以快些，更快一些，咱們不是要敏捷么?

– 為什么要去做計劃，難道咱們不要更快的響應么?

– 團隊沒有時間可浪費，難道咱們不能拍完腦袋就立即實現，看看效果么?

等等諸如此類，似乎快就是敏捷，敏捷就是快;似乎因為會變化就完全不需要規劃;似乎一切就是極快的響應，極快的去試，而不需要方向性的指導與評估。那么團隊有沒有可能做到，既不失于規劃，又不失于快速?

先回到筆者團隊的現實，初入團隊內的時候，團隊內的計劃性是比較弱的，強調的是按周排期快速響應各種業務需求。在接手時候，排期已經成了較大的問題，讓所有人頭痛不已，同時較遠期的規劃也變得艱難，在日復一日的埋頭苦干中，沒有空去看方向。因此決定還是進行適度的計劃，來讓團隊在可預期的一段時間內，對即將開始的工作有個大致的預期，同時仍然開啟周常規迭代，來對零散緊急的需求進行響應。整個計劃鏈與常規緊急響應調整后現狀如下：

上圖中，計劃外需求有幾個分支，如緊急且復雜的需求，將按照優先級依據一進一出的原則進入當月的月度計劃，在項目型迭代中進行開發;不緊急且復雜的需求，則放入下月月度計劃。

在這種長短迭代結合的協作之下，筆者團隊可以較有效的使產品保有一定的規劃性，同時又能對日常緊急需求進行及時響應。有適度計劃帶來的秩序和節奏，又不失敏捷的交付與響應。

很難說這種方式是敏捷還是傳統的RUP，這更像是參考兩者后量體裁衣的實踐，沒有包治百病的最優方法論，是為沒有銀彈。筆者在此拋個磚，希望所有團隊都能給自己裁出一身合體的好衣裳。

　　理念宣導，水到渠成

　　“我手執鋼鞭將你打!……”阿Q兄當年有個夢想就是拿著鋼鞭當領導。咱能學他么?好歹也是受過高等教育的，再說了，咱就一普通PM,手上也還真就沒有鋼鞭!是不是沒了鋼鞭事情就沒法推了呢，美帝和我黨用歷史經驗告訴大家，宣傳工作才是一個組織的傳家寶?；氐降孛?，當大家在一個團隊內推行一些措施時，真的感覺不是容易的事情，以下幾個問題是通常會被挑戰到的：

– 團隊運轉得好好的，為什么要按這些措施做?

– 這樣做會有什么好處與弊端?

– 軟性抗拒，應付性的處理下，等不催了就悄悄的停掉。

當然，還會有其它的一些問題，暫列幾個典型的做個樣例，在推行的過程中，發起人推得辛苦，執行的伙計們也接受得辛苦。個人經驗，在一項措施要被推行前，事先的宣導是很重要的，即要在推行前，在團隊內進行一系列的導向性宣傳，且必須真的以團隊長遠利益為出發點。

宣導的目的是在事前清理掉可能的誤會區，這會有效的防止在執行中誤會頻生，引出各種牽強的解釋，甚至引發沖突;同時團隊也有機會在事前做好充分的思想準備，消解可能遇到的阻力，引發愿意嘗試的動力。如果確實是一項好的措施，也確實對團隊有益，那么在事先充分的宣導后，必然可以水到渠成，事半功倍。

　　分享下筆者團隊推行雙周分享的事吧，團隊曾經是有過雙周分享的，但由于忙等種種原因，沒有持續下來?，F如今重新開張，如何來調動大家的積極性呢?我們專注于去發掘分享對大家的益處，一定要是實實在在的好處，這些好處大致如下;

– 雙周分享可以給到大家舞臺，讓大家嘗試去展示自己所長;

– 雙周分享可以讓大家吸收其他人的經驗成果，開闊眼界;

– 分享前的準備，可以有效的總結自己的經驗，促進自己成長;

– 分享能力是個人綜合能力很重要的一環，并且有助于在司內長期發展。

等等諸如此類，實實在在絕無虛假的益處。宣導的一定是可信的，真實不虛的，為團隊成員著想的，這樣團隊成員才會愿意相信，愿意投入精力來做這件事情。目前團隊的雙周分享是很不錯，每期同志們都會積極準備，而且講起來也是各具風采。

　　開放合作，共同成長

這個話題比較大，開放合作是大勢所趨，就像QQ網購在前些天接入了支付寶，騰訊也在去年開始了倡導整個大平臺的開放。雙贏的組織和個人，會得到更多正向的支撐與反饋，從而讓團隊能在更健康的氛圍中持續壯大。

這個部分說不上什么經驗之談，更多的是一份寄語，騰訊電商，乃至整個騰訊，大方面需要各個Group的合作，小方面要各產品組、開發組、測試組、運維組、運營組之間的精誠合作，大家才能一起水漲船高。落實到個人，對開發而言需要去嘗試理解產品經理們KPI的壓力，對產品經理而言要嘗試去體諒開發和測試這些后端兄弟的瑣碎與不易，團隊之間互相理解，互相扶持，大家一起和電商共同成長。

在筆者團隊，團隊也會有一些嘗試，比如開發團隊的大講堂，并不局限于開發技術分享的本身，總是會邀請產品經理、運營、測試來分享他們的工作與體會，從而促進各方的理解與合作。

筆者前述的部分業務高度訂制部分移交各業務部門自己處理，在這件事上，其實也是從合作的角度出發，各自做自己最擅長的事，筆者團隊提供底層技術平臺，業務方按自己的意愿更快速的響應定制，各展所長，在合作中雙贏。

同時，團隊也在致力于運營平臺的建設，最大限度的將相關的運營合作能力開放出來，讓運營可以對程序的結果進行個例的自主優化，該平臺的上線，很多運營的同學給予了極其熱烈的歡迎，這是團隊與運營的合作雙贏。

還有團隊的鼓勵溝通，明確職責與接口，這些都是為了讓個人和團隊更為開放，能夠更地好去分工合作，形成集體的戰斗力。

開放與合作，團隊會一直進行下去，團隊的未來，一定是更開放的，也是更懂合作的。

　　最后的結語

零散的寫了很多，從傳統到互聯網項目，乍一接觸會感覺反差比較大，但骨子里，大家都是希望團隊穩定、效率高，執行有序、質量高，信息透明、互信高。私心里深深以為，這之間距離確實有，但并不會比想象中的更遠。有很多東西都是相通的，比如都應該是以人為本，以計劃為工具，以流程建立團隊風俗，以績效為目標。執行層面粒度與傾向性或有不同，大的脈絡仍然是一脈相承。

最后列些個人感受到差異，給大家參考下。計劃是重要的，但并不是唯一重要的，比如團隊必須隨時響應更高優先級的突發需求;項目不一定是要規劃得大而全整體交付的，大的項目其實是可以拆小來做的，比如保持快速小步的迭代，持續交付;流程不一定是要卡得死死的，其實可以抓大放小，保持團隊的自主性，比如在團隊成熟后，可以嘗試把部分排期權下放;優先級并不是一成不變的，其實每過一段時間優先級可能就轉換了，因此需要時常進行更新調整;再比如團隊是必須珍惜愛護好的，因為互聯網是由無數小型項目串起來的大事業，你將與你的團隊在N多的小項目里一起同行到永遠。

項目管理，其實沒有成法可照搬照抄，不同的團隊，不同大環境，都會有自己不同的實踐選擇，操作上無優劣之分，只有是否最適合自己團隊的考量。在此拋磚一塊，期望得到更多的回應，互相交流促進。