之前一直存著一個疑問：支付寶頁面這麼少，為什麼大家都這麼忙？
有這個疑問的時候，團隊裡的人，包括上海那邊的三個，總共有十幾人。那時候也偶爾會聽到其他人在說流程怎麼不好，流程怎麼改，諸如此類，雲雲。作為一個新人也只是聽聽就過了。那是沒辦法，連流程也不知道，怎麼去建議，怎麼去改。另外，當時也正在做一個升級包，163 個郵件模板j全部做成全新的。情況是一個升級包就改 163 個頁面（回想起來這 TMD 難道不是個項目麼，而且是給一個完全不熟悉這邊的新人），當時也沒怎麼想，只是覺得連個升級包都這麼麻煩，那麼 10 來個前端這麼忙也是理所當然的。
結果。現在團隊已經有很多人。還是看起來特別忙。還是總有人告訴你他特別忙。什麼情況?!
先拋開公司流程，說說自己的流程。事實上，已經很久沒有走完一個公司產品流程。離開業務組已快一年，在架構組一般都是前端內部的項目。項目開發流程都由自己或架構組項目小組規劃，時間的制定也主要由自己制定報主管知悉。也就沒有覺得流程有什麼問題。因為一般我們都會分析項目，比如做樣式庫的時候大概的流程規范是這樣的:
對於這樣的流程，都是按實現項目來做規劃的 。並不會有什麼問題。不過，公司可不是這樣。大家都有著一個共用的流程，這是某個人或某群人在歷史上某個時間為你預先制定好的流程。
至於具體的流程，這個我也不好細說，其實也沒必要那麼細。用三個事來描述吧。事情是這樣的：一，某工友讓我幫 fixed 一個 bug, 他說用的是新版的 Alice（我們的內部樣式[CSS]庫），結果 debug 發現引起 bug 的是上一版的 Alice 引起的；二，某工友突然有事走開，有一個新產品在做，做為項目支持的我，接手了他的工作，兩天要完成 20+ 頁面。三，有一個很有必要的點要改，但不是 bug，沒人想起緊急發布。這樣，這裡有兩個情況：
當然，出現情況一、情況二這樣的狀況，也可以說是自己不夠努力。怎麼說呢，其實即便是使用舊的樣式，不是在支付寶前端團隊這樣有維護樣式庫的團隊，也會做得夠嗆。至於升級到最新版本，加班的話，也不是不可能完成，只是 QA 團隊的測試又怎麼能來得及？然後我們說 QA 也加班加點吧，事情也是可以完成的，但這對於公司和員工這總不是長久之計。
至於情況三。其實我們在一個大環境，在一個有著”為了更好體驗“為口號的團隊，在一個為了客戶更安全穩定而特別看重可用性的公司，還有著很多層的老板關系。這樣一來，這裡可能（可能，是可能）流程算出的分數並不一定和體驗成正比（因為這樣寫，我竟然差點都同意了）。
總結一下，這三個情況其實需要我們去解決的是兩點：
說到這裡。就不得不說一下人了。
想想你平時是怎麼做一件事的。特別是做你喜歡的事和不喜歡的事的情況會有什麼區別。你想你自己的，這裡我說兩個關於我自己的事例。
事例一、在面試支付寶的時候，周愛民老師問，“麼麼茶說你 CSS 不錯，你能說出 5 個 IE 和 Firefox 在 CSS 上的不同嗎？”，當時我說了，這也沒什麼。只是有的 bug 能解決，但很難表述。他說，你這是缺少總結；
事例二、最近一個做產品的同學在知乎上邀請我回答“為什麼國外的如亞馬遜的網頁寬度是用戶選擇適應，而國內的大部分都是固定寬度居中的？”，其實這個問題我也沒思考過，但還是根據經驗說出了觀點，後來竟 TM 都自己要表揚自己了，竟然總結得有條有理（只是找來做個不是特別恰當的例子，具體為什麼這人這麼顯擺請忽略）。
說這兩個事例，只是為了引出兩個點：
是的，我們就是這樣。難道不是這樣嗎？如果你是前端，想想你是不是很多 BUG 能解，但就不能第一眼看出（經常有人問我為什麼有人一眼就能看出來，你為什麼知道，有沒有什麼秘訣）；想想你遇到馬雲，他拋給你一個觀點，你是不是會更加努力去思考，而不是像你老媽突然拋出的一個觀點（比如我媽總說我從忘事忘到大，到後來才想，原來真的有很多東西就是不愛去記住）那樣去思考。
剛剛說流程說到一半，就開始說“人”這個話題了。是的，像你常常聽人說的，規則是死的，人是活的。人能創造這些東西，也能修改這樣的東西。但我並沒有想說這個。而是做這個需要一個深度用戶，去總結，去結合實際深入思考。在架構組，我們大多數情況下只負責一個項目，流程是根據這個項目定制的，想出問題也難。但在一個有快 1000 人的部門，在一個多線開發多產品的，有無數項目的技術部。要如何去深入，去解決流程，不是深度用戶，不根據平時實發情況來思考，也很難解決問題。舉個不怎麼恰當的鴿子，我們寫程序時，都會特別注重重用：
流程也一樣。小組去總結，團隊去總結，再上升到小部門，到大部門。把可以用相同流程的項目歸類出來，制定出一（多）個通用流程，甚至有特殊流程來應對重要的特殊情況。當然，這不是他媽在廢話麼，我相信人人都這麼想。
其實事情並不是在這個點上卡住。而是：
讓我們想想前段時間討論得非常多的，Facebook 讓人羨慕的以工程師為主導的產品開發。他們為什麼要以工程師為主導？產品經理就沒用了嗎？
問題就不直接回答了，但可以肯定的是，一種不升級技術的互聯網產品很難長期保持生命力。就拿支付寶來說，他慢慢出來很多產品，越來越好用，用戶越來越多。如果我們不在升級產品的同學，也升級我們後台的技術支撐，如何去頂住這麼多人流的並發，如何保證機器出問題能順利切流到另外的服務器。
其實說這麼多，也就是為了引出：如果產品經理自己都不能很好理解自己負責產品的生命周期，能全面把握產品在各個點上的分配，比如不知道技術會影響這個生命周期。去告訴他。讓他給你安排，讓你的時間得到保證。
一說到 BCD (Boss Centered Design)大家都會很興奮，仿佛每個人都有一個很無理的老板，仿佛每個公司的層級關系都非常不樂觀。其實事實上並沒有那麼嚴重，通常只是一兩個事發生，甚至是不可避免地發生，然後就有人找個詞來概括一下（當然，也有很惡心的，但我相信這些發展得很好的公司應該會很少）。
說個題外話，為什麼有那麼多人怕老板？因為他們對其有所求。無欲則剛，無求乃尊。如果你關注的是產品，那麼你會去讓你的產品更好，並讓別人知道這樣做會對產品和他更好。而不是單純去怕老板，怕他不給你一碗飯揣。
好，是的，如何讓老板認為這是對他更好的，同時對產品也好？
如果流程裡面分數的算法更合理。假如提升產品的分數是加10 分，緊急發布分數是扣5分。那你的老板會不會讓你緊急發布？可想而知。剛才也說了有時候是“不可避免”地發生所謂的老板為中心。當時我們以為老板不讓發布，其實老板很想提升產品，但他覺得他的老板可能不想。但太多層級了，心思不好猜啊，人人都懂思想是直的，不然很難存活。只能說這種情況很無奈。而一旦有一個標准，那麼人人心中也都有一個桿槓，根本就不用去猜別人的心思。
至於什麼算法是合理的？單單這樣說起來就是個哲學問題了。但當我們有一個現實中的產品，這時老板決策的作用就來了，決定什麼應該加分，加多少分。
另外，對於一個產品，也不會一整年都忙。畢竟我們現在有這麼多人，幾乎都是每個人負責一個產品，或者多個人負責一個產品。讓人員分配好做（升級）產品的時間也是一個問題。
就像你經常會聽說有人說自己很忙，或者表現得自己很忙。其實他們也會私底下說這個季度他們很閒，感覺好像不知道做什麼。是啊，忙的時候覺得沒必要去升級技術，不忙的時候覺得應該好好休息一下。產品壓著人，也牽著人，而不是人去把握這個產品，去提升這個產品。我們又能怎麼做去解救這些盲（忙，“忙”目，盲目）人呢？
有時候覺得團隊有了業務組，有了架構組。架構組可以有測試組來測試前端框架；業務組裡面也可以有專門負責項目技術升級，頁面改善的的人。有很多人可能會問，改善產品本來就是每個工程師的職責所在，為什麼還要去成立專門的團隊來做這些事。很明顯，如果職責不夠明確，做不做都沒問題的時候，再遇到惰性，還是有很多人會選擇不做。而且，我們誰也不能保證公司的每個人負責的那一產品都當是做自己兒女來養。顯然，期待每個人這樣，也不可能。這時，把職責分得更細，加上傳統的責任制，將令產品的提升有更好的保證。
產品需要架構，人也需要。而最終我們要做的是讓人去惰性，把產品當做兒女去養，這對公司和人本身來說都是好事。
好吧，總結吧。寫多了是滿足了自己的表達欲，但看得人也會累的。
關於這篇文章。雖然提出問題，也簡單地提供了解決方案的思路，但我的目標並不是為了說明這個“思路”本身，而是想說明要用什麼樣的方式。也並不是為了說哪個地方不好，而是說遇到我們不想看到的東西可以怎麼去解決。對於涉及到支付寶的問題，也只是個人感受，並不代表大眾觀點。
關於流程、產品和人，只是為了引出這樣一句話：找一個靠譜的人去做事，並做好人的架構。也想對自己說，多去思考，多去總結。人生很短，別浪費了還能思考的日子。