模拟高效团队

探讨到一个问题，在大公司里，抽调几个人组成小团队，全力做好一个产品后，再进行更大范围的普及和维护支持培训，避免没完没了的沟通，提高反映速度，这样效率会不会高一些。

比如流行的Flickr, Youtube, Delicious等项目，其实都是少数几个人搭建的。

人手

两个设计师（一个产品经理）和两个工程师（一个项目经理）配合，只要这四个人够强悍，专业技术能互补，再加一位拍板的，应付普通大大小小的事情都没问题，最起码能讨论出有效方案，到了落实环节，人手不够适当考虑再加。

人多嘴杂，经验是不完全靠谱的，一旦说话的人多过了做事的人，项目进度就会受影响。事实证明，产品需求之所以定不下来，往往不是讨论的不够彻底，而是参与的人太多。

产品大了，设计师和工程师最好能独立负责模块，一个人参与到整个产品的支持不合理，让专业的人做专业的事，人手不够这样的理由不成立，而且会影响到同事情绪和工作质量。

专业技术人员，各自做各自的事情，除了规范统一，减少技术沟通，容易考核和明确责任。

技术

实现技术要事先确定下来，直接关系到人手安排。Web前端技术是最容易被忽视的一块，经历过不少项目都是卡壳在这里，个人分析的原因：

   1. 不合理的项目周期，高质量必须投入高成本，技术本身不成熟，尤其是兼容性。
   2. 不合理的人手安排，人才少，近两年发展的新技术，整体水平不高。

始终不要忘了，直接和用户面对面的，就是这一个个Web页面，一切合理逻辑都需要入口。

时间

时间都花那儿去了，大部分是沟通！这也是强化核心团队的主要原因。

参与的事情越多，需要沟通的人就越多，到时候忙不忙就已经不是自己说了算，而且会影响以后的工作量化，比如一个会议直接从下午开到晚上，整天都在忙，忙的很没效率。

大公司跨部门干活是最折腾人的情况之一，貌似很专业，其实效率极其低下。生产火腿肠那样机器级的完美流水协作，在人与人之间几乎不可能，很大程度上与人手、同事的专业水准有关系，磨合也很重要。

冲突

事先明确好负责人，拍板和承担责任的事宜。定期通报进度，否则大家都不知道各自在干嘛，引起某些不必要的误会，还有大量的重复性劳动。

项目经理为项目负责，产品经理为产品负责，项目周期和产品质量本身只是理想化的对应关系。实际上，项目周期出了问题就会影响到产品质量，引起不和谐也是必然。关键在于，用户关心的是你这个产品设计，而不是项目技术，所以产品方人员实际上是弱势群体。

关键流程并行，后果很严重，大量返工会拖垮士气。

总结

不要看这写的很有道理，事后诸葛亮，而且下次也不一定能做到，知易行难，何况很多事情不是一个人能够控制的。凡事出了问题先问自己有没有做好，不要随便指责别人，你不了解的客观原因比你想象的还多。

工作上的事情搞不定，只好在blog上牢骚几句，嗯，总结乃成功之母……

好团队  是成功的一半。。。