模拟高效团队

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