这个栏目主要包含本人感兴趣的技术文档和参考资料。
声明：部分的文档资料来自互联网，其版权为原作者所有。 本站的原创文档遵循 “创作共用 - 非商业、署名、派生” 版权协议发行。
用户反馈 :: Feedback
文档排行 :: Top
焦点讨论 :: Focus
文档资料 :: Document
资源下载 :: Download
关于这里 :: About
探讨到一个问题，在大公司里，抽调几个人组成小团队，全力做好一个产品后，再进行更大范围的普及和维护支持培训，避免没完没了的沟通，提高反映速度，这样效率会不会高一些。
比如流行的 Flickr, Youtube, Delicious 等项目，其实都是少数几个人搭建的。
两个设计师（一个产品经理）和两个工程师（一个项目经理）配合，只要这四个人够强悍，专业技术能互补，再加一位拍板的，应付普通大大小小的事情都没问题，最起码能讨论出有效方案，到了落实环节，人手不够适当考虑再加。
人多嘴杂，经验是不完全靠谱的，一旦说话的人多过了做事的人，项目进度就会受影响。事实证明，产品需求之所以定不下来，往往不是讨论的不够彻底，而是参与的人太多。
产品大了，设计师和工程师最好能独立负责模块，一个人参与到整个产品的支持不合理，让专业的人做专业的事，人手不够这样的理由不成立，而且会影响到同事情绪和工作质量。
专业技术人员，各自做各自的事情，除了规范统一，减少技术沟通，容易考核和明确责任。
实现技术要事先确定下来，直接关系到人手安排。Web 前端技术是最容易被忽视的一块，经历过不少项目都是卡壳在这里，个人分析的原因：
始终不要忘了，直接和用户面对面的，就是这一个个 Web 页面，一切合理逻辑都需要入口。
时间都花那儿去了，大部分是沟通！这也是强化核心团队的主要原因。
参与的事情越多，需要沟通的人就越多，到时候忙不忙就已经不是自己说了算，而且会影响以后的工作量化，比如一个会议直接从下午开到晚上，整天都在忙，忙的很没效率。
大公司跨部门干活是最折腾人的情况之一，貌似很专业，其实效率极其低下。生产火腿肠那样机器级的完美流水协作，在人与人之间几乎不可能，很大程度上与人手、同事的专业水准有关系，磨合也很重要。
事先明确好负责人，拍板和承担责任的事宜。定期通报进度，否则大家都不知道各自在干嘛，引起某些不必要的误会，还有大量的重复性劳动。
项目经理为项目负责，产品经理为产品负责，项目周期和产品质量本身只是理想化的对应关系。实际上，项目周期出了问题就会影响到产品质量，引起不和谐也是必然。关键在于，用户关心的是你这个产品设计，而不是项目技术，所以产品方人员实际上是弱势群体。
关键流程并行，后果很严重，大量返工会拖垮士气。
不要看这写的很有道理，事后诸葛亮，而且下次也不一定能做到，知易行难，何况很多事情不是一个人能够控制的。凡事出了问题先问自己有没有做好，不要随便指责别人，你不了解的客观原因比你想象的还多。
