我实在没忍住,要是人家按照你这种方式去改进自己,都不知道死了多少回了。我再次强调,这不是技术员的问题,而是管理问题, 技术员是要在公司的文化和习惯下成长的,你不要指望她能自我进化!离开了社会环境,每个人都是山顶洞人。就是你这种人太多了,才会有那么多人认为技术做到30岁就没前途。世上无完人,每个人都只有有限的精力。专心做技术的你就不要玩他了,你的N多文章都把问题归结到技术员身上,这样是要不得的。。。
你的文章两大死穴如下:
1、本想通篇强调有效沟通,却仿佛通篇强调与领导沟通,实则通篇强调如何霸占领导时间。
2、通篇批评程序员习惯问题,却避而不谈本质的流程规范问题。
要解决你提的哪么多问题,只需要几点即可解决:
1、把握每个技术员的技术水准。
古代还讲求知人善用,现代就更应该充分了解下属技能,管理者肩负着项目按时完成的使命,必须保证充分利用人才,不要轻易安排严重超过开发者能力的任务,但可适当安排轻微超出其能力的任务以督促其不断进步; 同样开发者也不要轻易接下自己毫无把握的任务。那样会使自己失去信心,同事失去耐心。
2、做好项目进度安排与项目跟踪。
项目进度安排和跟踪是很大的一块,此处仅指出最基础的是:
(1)要保证合理安排开发者工作时间,不要累死高手又玩死低手。
(2)做好开发进度收集,可一日一统计,要求开发员明确指出当日已完成模块,明日待完成模块(此时间可斟酌)。
(3)根据开发者进度反馈并结合项目截止日期及时调整计划。
3、做好程序、模块验收机制。
软件开发很少有整个软件同时完成的,大多都按模块分类,一个一个的解决。所以做好模块验收机制就显得尤为重要,结合进度安排,及时的准确的验收模块,能避免开发者完成任务后无所事事的状态,同时也能反馈出开发者的BUG与开发中的其他种种问题。
4、做好程序注释管理与源代码管理(VSS\SVN等)。
团队开发中,牵一发而动全身的,除了公共接口开发人员外,还包括源代码管理。做好了源代码管理,就可保证代码完全在掌控之中,不被开发者“非法”修改。做到我分配你修改,你才能修改。而且修改的同时必须对那些复杂的、含有逻辑的BUG做好注释,但没必要对低级BUG的变更作注释。(什么情况必须做注释视团队能力定)。
权限系统能写的也就那么多,当没有素材可写时,可休息一段时间。不要强撑着写。
每个程序员都很不容易,每个程序员都希望自己能快速成长。。。不要误导他们,求你了。。。