李迟当官记4：制度

制度

会议

公司的会议还是很多的，但我觉得有很多时间就浪费在会议上。 每周一次的主管例会自不必说，真实，代理主管要求每周一次部门例会，我觉得，总共才4个人，加上代理主管才5个人，这种形式上的部门例会不开也罢，但代理主管坚持自己的看法，我也只好执行了。

在年中时，领导L不知是从哪里学了scrum会议，于是规定每天早上都要召开，一开始说不限时间点，不限形式，后来说必须早上9点钟开，而且要站着开。在项目进行时，还要隔一天汇报一次进度。于是乎，有一段日子，时间几乎被会议、报告占据了。 说实话，我是反对这种会议的，因为不切合实际。现在坚持scrum会议的部门，基本上只有一两个部门了。

招聘

我是后来才知道我们部门是8人的编制的。10月份走了一个人，而在此之前，招了一个人进来，也就是说，这么久以来，都是一个人干两人的活。就是因为人少，我在招人方面一直很松，只要有点经验，不太差，都能通过我的面试的。但领导却一直强调要招精兵，一进来不用教就能干活的那种。有好几个都是在终试被pass掉的。有一个人，笔试成绩太差，但我看他有工作经验，再说那笔试题也不能考出水平，但领导却抓着笔试成绩说事，还说：虽然我知道你想招人，求贤若渴，但也不能招这样的人啊。决定权不在我手，我又能怎么办？

后来，公司要招实习生，我挑了几个，面试通过一个。但最后，却去了另一个部门，做和他能力不搭边的事(不过最最后，还是回到合并后的部门)。那个时候，恰逢公司大换血和组织架构变更，一批老员工走了，来了一批实习生，而又调整成立新的部门，于是乎，来的人优先补充新部门。后来我接触了公司招聘的一些人，有些连uboot命令行都不知道是什么东西的人却是“嵌入式工程师”的岗位，领导(对我)强调的“精兵”政策已荡然无存了。对此，除了对当时的感慨，其它也说不出什么话来。

导师制

不知何时起，公司出了政策，名曰导师制，通俗来说是“师傅带徒弟”。说教的徒弟好的话，师傅有奖。对于此类大饼，我已经免疫了。没有实质性的奖励情况下，这种事情只能消磨“师傅”。——至少，已经把我这个喜欢帮助人的人给消磨得差不多了。这种事其实很浪费时间，以我为例，既要时不时中断事情来说教，又要想“徒弟”的任务(没错，徒弟的任务是师傅给的)，还要有正式的邮件通知徒弟和人事部——要包含任务时限、输入、输出等繁文缛节。对于此事，我在一份公司的调查问卷中特意用左手把自己意见写出来，现在看来，估计已经石沉大海了。

其它

在HP二期培训后，思维导图就十分流行，一直到现在，很多事务，都要用思维导图画出来，讲解。思维导图是好东西，能让人有条理，在全局观，但过度依赖就不好了。其实有些事，画出导图也是浪费时间。对于我所十分熟悉的事，我是不会主动画的，除非领导要求。

从领导会议的说话，从项目的安排，从与同事的交流，感觉到公司对于嵌入式底层的重视程度不够。比如项目计划，对于业务程序，分解得十分细，对于数据接收模块，网络模块，数据处理模块，日志模块，等等，都分得很细。而对于如uboot和内核，则只有一个项，完全不细分。主要原因估计还是对底层了解不多，只有一句话带过。更有甚者，一个项目的样机做出来后，要在一周(或3天)把uboot和内核、根文件系统做好，给应用应用程序调试。我们几个熟悉底层的人多次和领导提出意见，但领导听进去的很少。从公司年会及平时的表现，都能看出，对于在看不见成果的底层工作的人的不重视。一次培训，其它分区的人员在坐车时直接问我：你们搞系统移植的，到底是做什么的。对此，我非常难回答。而在一次会议上，其它部门同事说，内核都有代码了，你们还要搞什么？对此，我也是什么难回答。用句流行的话说，大家认知不同，难以说明白。