精心打造Team的组织架构

只要能承受这个风险成本，让我做ps也无所谓，反正一样干活，不就多干几个月的事儿嘛～嘿嘿

OneEyeWolf 写道：
个人也比较倾向这样的小团队， 而且需要有长时间的磨合，这样人的团队意识 荣誉感 和 互相包容能充分发挥出来

DBA，美工，JS程序员，这么多可以推卸责任的对象啊。。。

PS：今天一大哥把我气着了。。。。
分的活给他他分了分匀给了另外两个新来的程序员（新手），自己去炒股去了。。。

OneEyeWolf 写道：

任务分工还是很重要的，不过现在招人真的比较费劲，我这半年一直在招，想招个满意的java开发人员都非常困难！

怎么可能不需要文档呢？？？？？？？？？？
除非是那种做完一个项目再也不想发展、不想对软件进行维护的公司

在国内来说，什么技术啊什么团队啊什么项目管理啊，都不重要。
最重要的是接单，先拿下单子，随便找几个人做好，不出什么大问题，也不管什么维护不维护的。

所以除了技术，我们还应该学会跟客户打交道。
圆于技术前途堪忧。

如果是所有成员在项目中都是从头至尾全职的，而且工期很赶，像抛出异常的爱所说的团队我认为是合理的。但是其风险较大，假设，这四个人某日有一个在上班的路上被车撞死，或者下班回家的时候被天上掉下的花盆砸死，又或者喝水的时候不小心呛死，那么这个项目的结果会是怎样的？？？做过项目管理的应该知道人力异动其实是很大的风险。
如果是一个相对大些的公司或者组织，有专业的分工，效率可能会更高，因为他们都是同时跑几个项目，比如界面设计这件工作，想必同一个项目里面不用总是去画界面吧？那么就让界面设计师们同时负责几个项目，充分利用人力。
所以，还是要看具体情况，单纯讨论分工模式而忽略当时的环境是没太大意义的罢。

嗯，突然想到风水这个词。。。。。。

PS:风水：这就是为什么我会算命的原因。。。


汗。。。如果连老板一块砸死不就更好。。。

一家对日外包公司，有两百多人在作同一个项目的一小部分，
已经作了至少四年了，还没有作完。
我记忆最深的是到年底时我要求要进工具组，
我的组长。。不知道为什么：升了我的职，但没让我去工具组。。。
我当时年青，合同到期后就走人了。


那家公司的文档制度非常的好，不可能写错程序。
我基本上四个月以后程序都是一次写好不用调的。

强，要做到估计得：
1）文档要精细到伪码地步
2）设计时每一个细节都考虑到

一直有个疑问，有工夫把设计搞到如此细致，干吗不顺便把程序写出来，楼上的直接调试测试估计效率更高。