担心自己在管理IT部门时犯错误？以下还有八个你可能尚未列入“避免事项清单”的失误值得关注。
图源：dotshock / Shutterstock
作为CIO（首席信息官），你可以从众多渠道获取如何提升工作效率的建议，从here in CIO Survival Guide(best practice)/《CIO 生存指南》（最佳实践）中获得的内容，到CIO.com上的其他资源，要是实在没辙，还可以参考像Gartner（高德纳）、Forrester（弗雷斯特）和McKinsey（麦肯锡）等各类专家的观点。
你读到的大部分内容都列出了首席信息官应优先处理的事项。它们读起来往往像是由“Captain Obvious（明知故问之人）”写的，但这并不意味着这些建议不对。
只是有些老生常谈。
所以，为了提供一些你可能还没听过的建议，以下是IT管理的八大轻微失误，顺序不分先后，这些内容你可能在其他地方都听不到。
别谢我……
一、管理有余，领导不足
领导力就像开车。好的领导不是硬拉着员工走，而是像老司机一样，引导员工自觉地朝着正确的方向前进。领导要做的就是指明方向，激发员工的内在动力，让他们心甘情愿地跟着走，而不是被硬拖着走。
就像那个关于没有腿的狗的笑话，主人每天带它出去“抽两口”，表面上看是主人在拖着狗走，但实际上狗也在享受这个过程。好的领导也是这样，他们懂得如何激发员工的积极性，让员工自觉地朝着目标前进，而不是被动地被拖着走。
简而言之，领导力就是引导和激励，而不是强迫和控制。好的领导能让员工发自内心地想要跟随，而不是被硬生生地拉着走。这种领导方式更能激发员工的潜能，让团队朝着共同的目标前进。
二、领导有余，管理不足
你的职责是推动工作顺利完成。这就是管理的意义所在——确保你所负责的企业工作得以落实。
领导力是实现这一目标的有效工具（见上文“狗”的例子）。但它绝非唯一的工具。信息技术就是一个明显的例子；业务流程优化举措也是如此。如果过于强调领导力，管理者可能会花费大量精力去激励员工，却忘了自己的本职工作是什么。
三、纠结于费用分摊
费用分摊属于“理论上很棒，但……”这类情况。理论很棒的地方在于，通过向成本中心经理收取他们使用的IT资源费用，他们在向IT部门提出需求时会更加谨慎。
但问题出在IT部门解释收费金额的时候。这是因为IT部门有两种计算费用分摊的方式。一种是简单的方法，即根据一些容易理解的指标，如公司总员工数的百分比，或成本中心经理所控制的公司总预算的百分比，将IT预算分配给成本中心经理。
或者，IT部门也可以细化计算，计算每种IT资源的单位成本，监控这些资源的使用情况，然后将使用量乘以单位成本。
别用简单的方法。它吸引人的地方——简单——也正是它毫无意义的原因：因为成本中心经理无法通过减少IT使用量来降低分摊费用，这违背了该理论的前提。
因为这种方法很复杂，你可以预料到它是基于许多无法证实的假设得出的结果。而且，不管争论谁赢了，双方浪费的时间折算成他们的时间成本，就好比是在决定同一笔钱从哪个口袋掏出来一样。
还是放弃吧。
四、试图成为商务人士，而非技术人员
这条建议你肯定听过无数次了。在那些让负责IT工作的人担任CTO（首席技术官）头衔的公司里，这种观点达到了极致，导致了一种奇怪的说法，即职位头衔里有“technology/技术”的高层不应是技术人员。
所以，拜托。别再纠结了。首先，相比之下，成为商务人士更容易。其次，除非你认为公司的CFO（首席财务官）应该是商务人士而非财务人员，CMO（首席营销官）应该是商务人士而非营销人员，否则这整件事都不值得你浪费时间和精力。
不过既然引起了你的注意，那我就说说这个看似“好消息”的坏消息：那些试图成为商务人士而非技术人员的CIO，就像高中里那些拼命想加入Cool Kids Club（酷小孩俱乐部）的被排斥者。他们还是会被排斥，而且现在除了不够“酷炫”，还显得很可怜。
五、把“架构师”用作动词
这只是我的个人观点哦，但我觉得把“architect/架构师”用作动词，并不比用“engineer/工程师”作为动词能更有效地说明你要做的事情。通常，当我听到“我们必须架构一个解决方案”时，我看到的是一个没能加入商务“酷小孩俱乐部”，转而想加入技术“酷小孩俱乐部”的人。
六、滥用“最佳实践”
没错，这是一场注定失败的斗争。当有人声称某件事是“best practice/最佳实践”，而实际上他们想说的是这是一个不错的做法、一个经过验证的做法，或者只是基本专业水准的最低标准时，对他们皱眉头就如同因为有人用“hopefully” 开头表达“I hope”的意思而抱怨一样，都是徒劳无功的事。
既然此事徒劳无功，那我们接着看第七个：
七、从项目管理转向产品管理
项目管理是组织有计划、有目的地让明天不同于昨天的方法。
产品管理是一门商业学科，旨在管理公司某一产品或产品线的发展演变，以保持并提升其在市场上的吸引力。
IT产品管理源自敏捷领域，与商业产品管理充其量只有一种松散的联系。因为虽然提升企业部分技术或应用组合的吸引力有一定意义，但这并非IT产品管理的核心。
IT产品管理的核心在于明确责任和决策权。
这真的与项目管理有很大不同，或者比项目管理好很多，从而值得关注吗？
可能并非如此。这更多的是一种错误的二分法，而非什么新发现。
八、误解工作职责
恭喜你——你没有掉进“轻微失误第四条”的陷阱。也就是说，你不会试图成为一名商务人士。
但要小心另一种极端情况，即试图成为公司的首席技术人员。朝着这个方向发展，你会发现自己试图成为公司的首席业务分析师，这同样是一种错误的职责定位。
当然，CIO需要对技术问题有足够的了解，以便与公司的业务领导和经理进行有见地的交流，从而为整个企业提供战略指导。同时，他们在与IT技术人员交流时，也需要充分理解他们的技术问题。
但CIO的工作到底是什么呢？CIO的工作是构建一个组织——一个与业务紧密融合、高效运作、管理公司所有架构层面的技术组合，并且擅长吸引、招募、聘用和提拔顶尖技术人才的组织。
九、总结
既然你已经了解了这份CIO的轻微失误清单，接下来的问题就是你打算先解决哪些问题。有趣的是，如果你有时间关注其中任何一个问题，当然如果有时间关注好几个问题，那么要么说明你作为CIO的工作状态还不错，要么就是你已经陷入了无可救药的幻想，不过这其实也没什么大不了的。
作者：Bob Lewis（鲍勃·刘易斯）
Bob Lewis（鲍勃·刘易斯）是一名高级管理人员和IT顾问，专注于IT和业务组织的有效性、战略到行动的规划以及业务/IT集成。他是数码人。您也可以在他的博客Keep the Joint Running上找到更多信息。
睿观：
许多CIO（首席信息官）为提升生产力而采纳的主流管理建议，往往适得其反，成为妨碍员工完成工作的“伪最佳实践”。作者以一种反常规且略带讽刺的视角，列举了八大应避免的“轻微失误”，其中包括：在领导与管理之间失衡、为实现理论上完美的“费用分摊”而耗费巨之时日、盲目追求成为“商务人士”而放弃技术本位，以及沉迷于从“项目管理”转向“产品管理”等时髦术语的辩论。因此，CIO应摒弃这些华而不实的管理时尚，回归其最核心的、也最常被误解的职责——CIO的真正工作，并非成为首席技术专家或首席业务分析师，而是要构建一个与业务紧密融合、高效运作、并擅长人才管理的卓越IT组织。
别再纠结于是该当“商务人士”还是“技术专家”了，CIO的真正身份，是一个卓越的“组织建设者”。
