在团队中使用层级结构,是否阻碍了个体与外界的沟通?
极少有底层程序员或新手能和产品经理做深入的沟通的,所以中间放上师傅这一层,让其代为问问题,徒弟旁听,不但不会阻碍,反而会促进。
这样徒弟可以更快地学会问答技巧或熟悉业务,真正学成了,师傅才懒得在中间“阻碍”呢,呵呵。
师傅又要懂业务,又要懂技术,又要带徒弟,是否要求太高了?
的确不低,但是如果不要求这三个师傅如此,就要要求全组如此,更难;当然可以要求让程序员们可以不懂业务,但这样的程序员怎么放心让他干活呢。
但实际上,这点要求算不上什么,和“多才多艺”二字沾不上边。所以这种人其实很多,只是他们没被赋予这种职能而已。
师与徒高手不愿意带徒弟怎么办?
所谓求什么得什么,如果企业给个人能力高的人发高薪,而不给能带团队的人发高薪,屋子里边坐着的一定是一堆不愿意带徒弟的高手;反之则反。
另外一个角度,139团队不只是一个学习团队,而首先是一个生产团队。师傅带徒弟,一定程度上有上级带下级的感觉。还没有一个上级不希望自己有更多手下的,也没有上级希望自己手下都是饭桶的。
所以制度合适,人自然改变。
招聘了徒弟,没有师傅愿意带怎么办?
以往人是招聘来塞给某人“你负责他的成长的”,现在应该是有师傅说“忙不过来了,给我招聘个徒弟吧”。师傅要参与徒弟的招聘和试用。
徒弟不听师傅的怎么办?
试用期就走人。
时间与效率师傅一个顶仨,照顾别人是否降低效率?
要做好时间管理,就是师傅找徒弟随时,徒弟找师傅预约(“我有问题……”“好,等15分钟……(继续干活至一段落为止)”)。
一个人看那么多人的代码,会不会很花时间?
高手看新手的代码,10分钟就能看到一大堆错误。
师傅看徒弟的代码,5分钟就行;每天早上做了设计,中间还有前后关键点,没什么可看的。
今天看到的问题,明天不可再见,早晚一天无问题可见。师傅是培养徒弟干活的,不是给徒弟擦屁股的(在试用期就要考核这个,不怕起点低,但一个人连培养价值都没有,还能干啥)。
专家与杂家大家需要了解的东西太多,生产率是否降低?
我见过的最高的几个高手,都是以更广泛地了解业务和技术为特点的。
我见过一个13个人的团队,9年来人换了好几批了,从来都是每人只负责的功能,都是“专家”。产品最后有25万行,被一个高手花一年半改为1.3万行。问为什么原来的代码那么多,答:“原来的专家走了,没人能看懂其代码,所以只能大面积拷贝粘贴。”这样的专家,要他何用。
有些人希望只专注于自己的工作,怎么办?
目光这么窄的人,能做好自己的工作才怪;所知这么窄的人,能委之重任才怪;一直自己干活的人,能管理部门才怪。很多人苦苦钻研技术,希望能力提高然后被提拔,实在是缘木求鱼。道理一讲就通。
如果还讲不通,迟早会发现不想当将军的士兵,连厨子都做不好的,呵呵。
绩效与成长师傅学不到东西怎么办?
师傅之上还有师傅;师傅人数少,可以送去培训……师徒制度里边没有关于师傅怎么学习的内容,但如果理解“有问题处无答案”,这类问题很好解决。
教会徒弟,会不会饿死师傅?
如果我是老板,我会喜欢下金蛋的鹅,胜过金蛋,因此给鹅更多钱。
如果我是师傅,我会喜欢卖金鹅蛋,胜过卖烤鹅腿,因此能值更多钱。
如果我是徒弟,我会羡慕下金蛋,胜过我就是个蛋(好惨啊)。
徒弟的能力超过师傅怎么办?
我的编程能力超过我师傅的时候,他做部门经理去了,因为我们部门的所有师傅,都是他的徒弟,不选他选谁。
能力的不总是等于编程能力,而是一种在不同年龄不同层次有不同定义的东西,只有这种东西才能叫做能力。
上面这句话套用金刚经语法,就是“如来所说能力,则非能力,是名能力”,刚开始很难理解,但理解了就发现是一种很通用很有效的思维方式。
比如把“创新”带进去,就会得到乔布斯的创新观:我们苹果所说的创新(价值观创新),是不能被模仿的创新,所以才叫做创新(换言之能被那么容易模仿的,还谈不上什么创新);你们模仿iPod,我就做iPhone,你们模仿iPhone,我就做iPad;你们模仿iPad,我就得胰腺癌……
因为何为“能力”,怎样根据“能力”确定师傅和徒弟,根据什么“能力”来考核师徒,是139团队和松结对编程的核心,所以多说两句。
点击下载免费的敏捷开发教材:《火星人敏捷开发手册》
总结以上是内存溢出为你收集整理的敏捷开发“松结对编程”系列之七:问题集之一 .全部内容,希望文章能够帮你解决敏捷开发“松结对编程”系列之七:问题集之一 .所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)