给初入管理的IT技术人员建议，不要将默契式管理和人性化管理划等号。

最新推荐文章于 2020-12-27 00:28:02 发布

waders

最新推荐文章于 2020-12-27 00:28:02 发布

阅读量1k

点赞数

文章标签：技术人工作任务 log4j c 测试

本文链接：https://blog.csdn.net/waders/article/details/3514610

版权

学而优则仕在中国还是一个挺普遍的现象，给批判得也很多！但是原话是“仕而优则学，学而优则仕”，见于《论语·子张》，其真正含义并不是我们片面理解的“学习优秀的就去做官”。同样，“仕而优则学”难道是告诉管理者：“做好了官，有余力则学习！”如果你认定等我有余力才学习吗？呵呵，那你永远也没有有余力的一天。

在IT行业，不少管理者都是技术出身，从论语这句话，我们应该学习到：当走上管理岗位，更加要“边干边学”，从工作中学习提高业务知识和管理体系，持续改进，才能进入“仕而优则学，学而优则仕”的良性循环。（看来和CMMi的本质一致的！）

案例一：

某日抽检项目组O工作，检查项目经理L对任务的执行情况了解和把控，抽查本周内项目组成员C的工作任务时，发现项目经理L对C昨天的工作任务T1的工作完成情况并不了解。

为了进一步了解C的工作完成情况，和项目经理L、同事C一起检查昨天C的全日任务T1，该任务是测试业主方的FTP上传、下载接口，而本日的任务T2是开发FTP上传模块。先是询问了同事C在昨天是否还开展了其他任务，答案是没有；接着询问任务T1除了使用java的sun.net.ftp程序包外，是不是还有特别的业务逻辑以及异常处理等处理，答案是异常需要写日志记录；接着还告诉同事C，程序为了稳健性，处理正常的业务逻辑外，还有很多是针对异常的控制逻辑，除了使用log4j写入程序日志，还有什么特别的地方，C的回答是没有。

事后和项目经理L分析，项目组O的工作方式，停留在按模块给成员派任务，成员将任务计划上报，项目经理L和技术经理LL则合并计划，解决人员间的任务冲突！但是任务的时间是否合理，没有进行评估和监控，小组评估法也好，专家评估法也好，总之没有评估监控环节，项目经理L和技术经理LL都缺位了。

另外，工作的执行没有进行督促，没有每日的检查或者抽查，那么小组O里面，谁做到好，谁做得不好，只是拍脑袋；还有，项目组里面到底应该鼓励谁呢，谁是项目组成员的榜样呢？

案例二：

某日抽查某项目新进入成员G的工作，通过他的工作可以看到他融入项目组工作的成效。我询问G的工作汇报给谁，G告诉我汇报给技术经理L。G接着谈到他上周的工作情况，提到了他上周开发过程中存在需求变更。我告诉他这个事情有以下几种情况：

在G开发的过程中，业主告诉“我们理解的需求”需要变动；
上级同事L没有及时将“我们理解的需求”变动告知G；
上级同事L没有将任务的内容清楚告知G；
同事G没有真正清晰地理解同事L的要求；

我询问G，现在回头看上周这个问题，到底是上面那种情况，G的回答是1；我接着询问同事G，他的上级L怎么验收工作成果，G告诉我L将内容交给了项目组中的测试人员。

事后和技术经理L分析，拿到这个事情的判断，L的回答是4，L告诉我是在任务中检查G发现他对业务理解有错误。具体的事实是怎样并不重要，重要的是同事G和同事L对工作的理解、判断的标准是不同的，而且截至到目前为止一周，他们还是没有达成共识的。为什么会造成这样结局？是因为他们两都没有将自己对待事物的分析见解摆出来。如果G有错误理解的地方，L并没有在G刚进入项目组就告诉他这样做是不对的，那么以后情况会怎么样，可想而出；如果G这样的思考没有问题，那么L就得考虑为什么会这样想G？是不是得加强日常的工作沟通，将目标和要求明确告知。

案例三：

同事C完成项目E二期后，进入另一个项目S二期，目前负责带领4个同事开展开发工作，我刚好有天早上经过他的办公地点，发现C正在给同事T评点T昨天开发内容，告诉T那些有问题需要改进，我会觉得C的同事每天的工作成果都是在他的控制下的。

事后我了解到同事C在工作的每一天，都能够将团队成员的工作进行Review，并且以邮件PPT的方式发送给小组，抄送给领导Z，并且在PPT中，讲述了每个人的工作进展，与计划的偏差以及本日的工作目标。当然有的读者可能觉得没有必要吧，每天都发出PPT，呵呵，其实是否PPT形式并不是重要，重要的是内容的质量，从我阅读他的PPT内容后，我觉得他的做法有以下的优点：

C让小组同事、领导、监督管理者了解到小组整体的工作情况；让管理者的眼光更多关注到他的项目；
C让小组的成员都知道，我们的工作成果，每个人的工作好坏，上层的管理者都是知道的，每个人也是可以相互评价的；
C让小组的成员都知道，C的要求是什么，我今天要检查的是什么？写出来的总要比只是说说要有契约精神。培养团队的契约精神，是团队战斗力的一个基石。

（注：后续我还需要去了解C对整个项目计划Plan的更新和跟踪习惯。）

案例总结：

很多从技术转型到管理的读者，都是从人性化的小公司开始做上来的，公司小的时候因为人员少，边界简单，工作大家都看得见，很容易检查到并且调整。当转型为管理者的时候，默契式管理就会成为一个“过去式、怀念式”的理想，当你怀念为什么团队以前小的时候没有这样的理解、处理难题，那就很有可能已经患病不轻。请不要将默契式管理和人性化管理划等号。

我给初入管理工作的IT技术员工的建议：