我司目前產(chǎn)品組、設(shè)計組蕉斜、開發(fā)組逾柿、測試組各有自己的老大，每個項目都是從各組里抽人做宅此，但項目組成員并不集中辦公（各人還是在各組自己的工位上机错，受自己的直接領(lǐng)導(dǎo)安排工作），產(chǎn)品經(jīng)理很難把控設(shè)計進度父腕、開發(fā)進度和測試進度弱匪。這樣是不好的。
我希望的工作環(huán)境是這樣：產(chǎn)品經(jīng)理兼項目經(jīng)理璧亮，直接領(lǐng)導(dǎo)項目組的設(shè)計師萧诫，并且與設(shè)計開發(fā)和測試組項目成員坐在一起辦公。
提問：你所在的團隊啟動一個新項目時枝嘶，團隊辦公環(huán)境是怎么樣的帘饶？

xiaodou：
按產(chǎn)品線劃分會相對好點，但是會造成某段時間部分開發(fā)或者設(shè)計資源限制躬络，比如最近主要工作是做推薦算法尖奔，可能前端開發(fā)事情比較少，就會浪費穷当。

從公司角度講提茁，橫縱結(jié)合的方式比較好，比如餓了么的大前端團隊馁菜，行政上所有前端歸到這個部門茴扁，資源調(diào)配由前端大老板決定，又會將人員拆分到各個業(yè)務(wù)線汪疮，每個業(yè)務(wù)線有一個小老板峭火，跟對應(yīng)產(chǎn)品線的同事坐一起，密切配合智嚷，也可能被臨時調(diào)配協(xié)助其他組的工作卖丸，不會造成資源浪費（其實是活動頁面太多，前端更本閑不下來）盏道。

目前為止看到這是比較好的架構(gòu)稍浆。

leon：
我司產(chǎn)品很多，就按產(chǎn)品劃分項目組，每個項目組配備各自的前端Dev和設(shè)計衅枫，各組集中辦公嫁艇，有個老大會負責(zé)各組之間的人員調(diào)配，可以想象成有一座座小島弦撩，小島之間有船只調(diào)配人員物資步咪。

由于我司產(chǎn)品多為工具類且輕運營，所以服務(wù)器人員單獨成組益楼，運營單獨成組猾漫，另外還有一個前端架構(gòu)組（負責(zé)將各項目組共用的模塊集成為庫），這三個組服務(wù)于所有產(chǎn)品項目組偏形。

原則應(yīng)該是静袖，以產(chǎn)品為中心，資源利用最大化俊扭，溝通效率最大化队橙。

做為PM，這個架構(gòu)我還是挺滿意的哈哈萨惑。

ftium4：
我的前司工位移動比較便利捐康，所以會把同一個項目組的人工位調(diào)整到一個區(qū)域，這樣回頭就能一起討論庸蔼。

cloudlei：
我們公司經(jīng)歷了按專業(yè)部門坐——按業(yè)務(wù)項目坐——回歸按專業(yè)部門坐一系列歷程解总。

創(chuàng)業(yè)期，公司小姐仅，也就半層樓花枫，大家走來走去非常方便，技術(shù)開發(fā)設(shè)計都是按各自部門坐在一起的掏膏。

后面公司慢慢壯大了劳翰，辦公場地也大了，開始按業(yè)務(wù)項目劃分來坐馒疹，也就兩三條業(yè)務(wù)線佳簸，分開坐效率還是很高的。

再后來更大了颖变，業(yè)務(wù)線也多了起來生均，團隊專業(yè)氛圍的營造和專業(yè)技能的提升成為一個難題。打個比方腥刹，當(dāng)時一個業(yè)務(wù)項目大概會有兩個左右的設(shè)計師马胧，在項目中很容易被當(dāng)做工具，忽略了其個人成長方面的需求衔峰，事業(yè)部老大并非UI專業(yè)漓雅，也很難提出專業(yè)意見录别，而UI老大苦于團隊一直分散在各個角落，管理成本增加很大邻吞。

所以這個時候我們又按事業(yè)部各自坐在了一起，但是一般都會有專門對應(yīng)的業(yè)務(wù)線葫男，所以一條業(yè)務(wù)線的同學(xué)還是非常熟悉的抱冷，溝通效率比之前減少的也不多。

也許等團隊再大些梢褐，就可以分散開了旺遮，比如那個時候可能是一個事業(yè)部需要七八個甚至十幾個UI，這個時候事業(yè)部坐到一起盈咳，UI的成長由事業(yè)部自己負責(zé)耿眉，也可以走通。

所以用哪種方式?jīng)]有絕對鱼响，是根據(jù)團隊現(xiàn)有狀況來實施的鸣剪，是項目溝通效率和專業(yè)氛圍/成長/管理博弈的結(jié)果。

最后丈积，無論是分開還是合在一起筐骇，我認為保證權(quán)責(zé)的流程和規(guī)則才是最核心的點。

馬賽克：
我前東家曾經(jīng)做過feature team模式的嘗試江滨，應(yīng)該就是你期望的模式铛纬，作為一家老廠當(dāng)時“轉(zhuǎn)型”做的轟轟烈烈，甚至還由創(chuàng)始人之一親自牽頭唬滑，最后無疾而終告唆，默認失敗。剛好以前也思考過失敗的原因晶密，再簡單列一下擒悬，提供另外一個思路給大家參考：

1.
模式的改變徹底影響了過去繼承下來的習(xí)慣，存在很強的陣痛性惹挟。在之前茄螃，我司方式是產(chǎn)品提出需求，產(chǎn)品部門確定后交互同學(xué)跟進连锯，交互完成后進入UI的同時归苍，開始召集研發(fā)進行需求評審，評審?fù)瓿珊筮M入排期运怖，完成開發(fā)后產(chǎn)品確認拼弃，確認后測試進入，測試通過后由研發(fā)上線摇展。這個流程牽扯很多部門吻氧，幾乎每個部門都有自己的排期，所以推動一件事無比艱難，feature team當(dāng)初就是想打破這種大企業(yè)病盯孙÷成可是要輕易改變一家公司沿襲了N年的習(xí)慣非常困難，就算是創(chuàng)始人親自抓也沒用振惰，簡而言之就是：統(tǒng)一行動容易歌溉，統(tǒng)一思想非常難，這就為后面很多事情埋下了隱患骑晶；

2.
觸動了部分利益痛垛。當(dāng)然這里的利益更多是抽象的廣泛意義上的利益。比如我們后來FT的模式是根據(jù)不同項目桶蛔，選擇由產(chǎn)品負責(zé)或者由開發(fā)負責(zé)（技術(shù)性強的產(chǎn)品無法負責(zé)）匙头，然后根據(jù)項目大小直接抽出對應(yīng)的交互、設(shè)計仔雷、測試蹂析、運營等來進行專項支持⌒嗄可是這種模式就客觀上摧毀了原來部門隸屬的模式识窿，造成反而群龍無首的尷尬情況，看起來是調(diào)動了每個人的積極性脑融，但是會存在一個很現(xiàn)實的問題：到底聽誰的喻频？如果需求排期出現(xiàn)沖突，部門領(lǐng)導(dǎo)的需求和自己FT的需求如何抉擇肘迎？久而久之甥温，堅持FT就會架空原部門領(lǐng)導(dǎo)，部門形同虛設(shè)妓布，放松FT就會造成新事物在本來就不穩(wěn)定的初期更加不穩(wěn)定姻蚓，F(xiàn)T形同虛設(shè)。

3.
考核困難匣沼。大廠總是需要考核的狰挡。上面提到2的問題，還有個尷尬就是释涛，考核是需要部門老大來做的加叁，但是新模式下部門老大又幾乎不清楚你在FT做了什么，并且還會無法及時響應(yīng)老大的需求任務(wù)唇撬。從人之常情出發(fā)它匕，這方部門考核難度增大很多。另一方面窖认，不同F(xiàn)T本身目標不同豫柬，難度不同告希，放在一起考核無法做到完全的公平，而且有的FT項目等待周期非常長烧给，又很容易形成“肥差瘦差”燕偶。

4.
人員有限。由于把所有需求拆分為FT方式创夜，造成需求優(yōu)先級的概念被嚴重影響杭跪，每個被拆分的FT都成了同一水平的項目，而可用的產(chǎn)品驰吓、開發(fā)、設(shè)計和測試資源就那么多系奉，一人身兼多項就又會變成以優(yōu)先級來處理檬贰，這里如何分配優(yōu)先級全靠FT負責(zé)人個人能力，不再是以前集體討論缺亮。所以客觀上很容易又回到原來的工作模式翁涤。

5.
理想很豐滿，現(xiàn)實很骨感萌踱。創(chuàng)始人當(dāng)時為了強推FT葵礼，兩個合伙人之一親自掛帥，并且宣稱要打破匯報層級并鸵，部分重點項目直接向他匯報鸳粉。當(dāng)時我負責(zé)的一個項目就是向他匯報≡暗＃可是現(xiàn)實卻很殘忍届谈，創(chuàng)始人也很忙，要么經(jīng)常聯(lián)系不上弯汰，要么匯報的時候給人很敷衍在聽的感覺艰山，實際上無助于項目本身，唯一的好處就是在“忽悠”資源的時候可以扛大旗咏闪。

上述是我認為我廠當(dāng)時FT模式失敗的核心原因曙搬。

cicada：
@馬賽克 看哭了……我也傾向于這事兒沒有最優(yōu)解，只能搞動態(tài)平衡鸽嫂，為每一年的年度目標去做平衡性的調(diào)整纵装。

我自己可以縮小團隊規(guī)模，控制需求數(shù)量溪胶，但完全取決于我的個人能力搂擦，以及個人投在一線花費的時間，沒可能復(fù)制哗脖，別的公司哪怕明知道存在大量的需求浪費也無計可施瀑踢。