我司目前产品组、设计组、开发组、测试组各有自己的老大，每个项目都是从各组里抽人做，但项目组成员并不集中办公（各人还是在各组自己的工位上，受自己的直接领导安排工作），产品经理很难把控设计进度、开发进度和测试进度。这样是不好的。
我希望的工作环境是这样：产品经理兼项目经理，直接领导项目组的设计师，并且与设计开发和测试组项目成员坐在一起办公。
提问：你所在的团队启动一个新项目时，团队办公环境是怎么样的？

xiaodou：
按产品线划分会相对好点，但是会造成某段时间部分开发或者设计资源限制，比如最近主要工作是做推荐算法，可能前端开发事情比较少，就会浪费。

从公司角度讲，横纵结合的方式比较好，比如饿了么的大前端团队，行政上所有前端归到这个部门，资源调配由前端大老板决定，又会将人员拆分到各个业务线，每个业务线有一个小老板，跟对应产品线的同事坐一起，密切配合，也可能被临时调配协助其他组的工作，不会造成资源浪费（其实是活动页面太多，前端更本闲不下来）。

目前为止看到这是比较好的架构。

leon：
我司产品很多，就按产品划分项目组，每个项目组配备各自的前端Dev和设计，各组集中办公，有个老大会负责各组之间的人员调配，可以想象成有一座座小岛，小岛之间有船只调配人员物资。

由于我司产品多为工具类且轻运营，所以服务器人员单独成组，运营单独成组，另外还有一个前端架构组（负责将各项目组共用的模块集成为库），这三个组服务于所有产品项目组。

原则应该是，以产品为中心，资源利用最大化，沟通效率最大化。

做为PM，这个架构我还是挺满意的哈哈。

ftium4：
我的前司工位移动比较便利，所以会把同一个项目组的人工位调整到一个区域，这样回头就能一起讨论。

cloudlei：
我们公司经历了按专业部门坐——按业务项目坐——回归按专业部门坐一系列历程。

创业期，公司小，也就半层楼，大家走来走去非常方便，技术开发设计都是按各自部门坐在一起的。

后面公司慢慢壮大了，办公场地也大了，开始按业务项目划分来坐，也就两三条业务线，分开坐效率还是很高的。

再后来更大了，业务线也多了起来，团队专业氛围的营造和专业技能的提升成为一个难题。打个比方，当时一个业务项目大概会有两个左右的设计师，在项目中很容易被当做工具，忽略了其个人成长方面的需求，事业部老大并非UI专业，也很难提出专业意见，而UI老大苦于团队一直分散在各个角落，管理成本增加很大。

所以这个时候我们又按事业部各自坐在了一起，但是一般都会有专门对应的业务线，所以一条业务线的同学还是非常熟悉的，沟通效率比之前减少的也不多。

也许等团队再大些，就可以分散开了，比如那个时候可能是一个事业部需要七八个甚至十几个UI，这个时候事业部坐到一起，UI的成长由事业部自己负责，也可以走通。

所以用哪种方式没有绝对，是根据团队现有状况来实施的，是项目沟通效率和专业氛围/成长/管理博弈的结果。

最后，无论是分开还是合在一起，我认为保证权责的流程和规则才是最核心的点。

马赛克：
我前东家曾经做过feature team模式的尝试，应该就是你期望的模式，作为一家老厂当时“转型”做的轰轰烈烈，甚至还由创始人之一亲自牵头，最后无疾而终，默认失败。刚好以前也思考过失败的原因，再简单列一下，提供另外一个思路给大家参考：

1.
模式的改变彻底影响了过去继承下来的习惯，存在很强的阵痛性。在之前，我司方式是产品提出需求，产品部门确定后交互同学跟进，交互完成后进入UI的同时，开始召集研发进行需求评审，评审完成后进入排期，完成开发后产品确认，确认后测试进入，测试通过后由研发上线。这个流程牵扯很多部门，几乎每个部门都有自己的排期，所以推动一件事无比艰难，feature team当初就是想打破这种大企业病。可是要轻易改变一家公司沿袭了N年的习惯非常困难，就算是创始人亲自抓也没用，简而言之就是：统一行动容易，统一思想非常难，这就为后面很多事情埋下了隐患；

2.
触动了部分利益。当然这里的利益更多是抽象的广泛意义上的利益。比如我们后来FT的模式是根据不同项目，选择由产品负责或者由开发负责（技术性强的产品无法负责），然后根据项目大小直接抽出对应的交互、设计、测试、运营等来进行专项支持。可是这种模式就客观上摧毁了原来部门隶属的模式，造成反而群龙无首的尴尬情况，看起来是调动了每个人的积极性，但是会存在一个很现实的问题：到底听谁的？如果需求排期出现冲突，部门领导的需求和自己FT的需求如何抉择？久而久之，坚持FT就会架空原部门领导，部门形同虚设，放松FT就会造成新事物在本来就不稳定的初期更加不稳定，FT形同虚设。

3.
考核困难。大厂总是需要考核的。上面提到2的问题，还有个尴尬就是，考核是需要部门老大来做的，但是新模式下部门老大又几乎不清楚你在FT做了什么，并且还会无法及时响应老大的需求任务。从人之常情出发，这方部门考核难度增大很多。另一方面，不同FT本身目标不同，难度不同，放在一起考核无法做到完全的公平，而且有的FT项目等待周期非常长，又很容易形成“肥差瘦差”。

4.
人员有限。由于把所有需求拆分为FT方式，造成需求优先级的概念被严重影响，每个被拆分的FT都成了同一水平的项目，而可用的产品、开发、设计和测试资源就那么多，一人身兼多项就又会变成以优先级来处理，这里如何分配优先级全靠FT负责人个人能力，不再是以前集体讨论。所以客观上很容易又回到原来的工作模式。

5.
理想很丰满，现实很骨感。创始人当时为了强推FT，两个合伙人之一亲自挂帅，并且宣称要打破汇报层级，部分重点项目直接向他汇报。当时我负责的一个项目就是向他汇报。可是现实却很残忍，创始人也很忙，要么经常联系不上，要么汇报的时候给人很敷衍在听的感觉，实际上无助于项目本身，唯一的好处就是在“忽悠”资源的时候可以扛大旗。

上述是我认为我厂当时FT模式失败的核心原因。

cicada：
@马赛克 看哭了……我也倾向于这事儿没有最优解，只能搞动态平衡，为每一年的年度目标去做平衡性的调整。

我自己可以缩小团队规模，控制需求数量，但完全取决于我的个人能力，以及个人投在一线花费的时间，没可能复制，别的公司哪怕明知道存在大量的需求浪费也无计可施。