《极客与团队》前段时间有看，讲了一个人际原则 HRT，humble，respect，trust。 关键要找对人，原意合作的人，很多事情就简单。 自私傲慢就麻烦，容易官僚主义。

当然人员少而精是有好处的 但问题是 如果项目很大，人员再精也无法完成了 这个时候人数增多是必然的了。 还有“用 Rails + bootstrap 3 天搭建一个项目”这种经历就别说了 这不是做产品 这只是写程序而已，根本不值得一提。。

#2 楼 @iBachue

你批评的很有道理，but 我们不是原生的 bootstrap，是设计过的。

少儿精的团队是什么样子，大家是不是前后端通吃的？是不是浓重的工程师文化？

我也有楼主类似的心态，虽然自己各方面都懂一些，但是工作量摆在那里的，还是挺累的。合作的关键在于大家都很赞同要做的东西。这样才会有热情努力去做事情。如果是做自己没什么兴趣的东西，坐班磨洋工什么的是很难有什么发展的。

推荐看 Rework 这本书

用 QQ 或邮件交流还好，最烦在办公室通讯用吼的搭挡了，恨不得向全办公室宣示他的关系网

#5 楼 @fresh_fish

rework 是本好书啊，每个月都要翻一翻。

#3 楼 @xiaoronglv 其实我的意思是 用六个人天的工作量就能完成的项目根本不算项目。。。 少儿精的团队是什么样子的 这个取决于很多因素了 不一定"前后端通吃"或是“浓重的工程师文化”通常是一种互补的关系

P+D 需求有好的制度，少而精的团队要求人员素质 当然，最重要的是人员素质

一群普通人的合作就像布朗运动，看起来热热闹闹，其实每个人只是为了解决由其他人创造的问题，最终整体效果是零。

优秀和合作应该以内容而非技术分，比如 3 亩地需要植树，找 3 个人分别负责 1 亩，好过一个人抗树一个人浇水一个人用铲子。后者会导致大量协调问题而低效。

2~3 人为宜

#10 楼 @kgen 一看你就没种过树，拍脑袋瞎说出来的吧。

从企业项目／大产品，到客户项目／中产品，到创业项目／小产品，项目的本质会决定最优化的团队组成和协作方式。

乔布斯不是说，5 个 Aplayer 胜过 100 个 Cplayer 和 50Bplayer 吗？作为 Aplayer，一定是个前后端都懂，会 css，会 js，会 coffee，会 html。然后专精某一方面，比如 ror。一个人可以撑起一个项目。并且做到极致。

#12 楼 @Victor 的确没种过树 -_-||| 我只是打个比喻……

我们公司做产品，一般都是 N*10 个人一起动。沟通占据了大多数的时间，对 PM 来说，晚上是真正写 mrd，做原型的时间，比如昨晚我写需求 + 原型到凌晨 4 点钟。对 RD 来说，大多数也是下午或者傍晚才有完整的时间写代码。团队不是固定的模式，沟通交流，配合合作不是目的，只是手段，最终的目的是把事情做好了，也就是要根据做好事情这个放心来调整团队，调整配合方式等，而不是让结果来适应手段。

显然是后者。自己做 PM+developer

找对合适的人合作，宁缺毋滥

产品关键是有人用，有人买单，不是有什么技术。

多人合作一不小心会陷入各种针对工作进度的问题甩责任和撕逼。。。烦的要死