12个IT应该不惜一切代价避免的陷阱

简介:

从告诉所有人他们是你的客户到建立云策略,这些“行业最佳实践”无疑会断送你在IT上成功的机会。

是什么导致IT机构失败?往往是因为那些本该深谙此道的人采纳了所谓的“行业最佳实践”,然而他们失算了,大概是因为他们从来都不用亲历亲为。

从建立内部客户到实行计费到坚决要求投资回报,从全局来看,这些建议看似有理。但这只是些皮毛,你发现这些保证IT成功的秘诀往往是失败的方子。

1.告诉所有人他们是你的客户

想失败吗?只要确保每一个IT中人告诉每一个IT外行:“你是我的客户,我的工作就是要超越你的期望(或者更糟,‘让你开心’)。”

IT部门外的员工并非IT部门的客户,而是IT部门的同事,他们以平级的身份与IT部门合作,为了整个公司的利益着想。

把内部客户这个想法合法化使IT陷入从属的地位,在这样一种境况里,IT部门里的每一个人必须要让同事开心,而不管这么做对企业有没有意义,更不用说这是否能鼓动公司的实际客户购买更多的产品和服务。

2.制定服务水平协议并把他们当合同一样对待

想要搞破坏吗?那就制定正式的服务水平协议,坚决让“内部客户”签字,并把它们当作合同一样对待。

如果你真的想IT失败,你只要每次在“内部客户(又是这个词儿)”暗示IT是否忠于职守时,你只要争论你是否每次都符合服务水平协议。这是对人敬而远之的方式。

如果你更喜欢成功,那么你要记住关系的建立需要信任,只有把同事当实实在在的人看待,信任才会产生,只有他们喜欢你,才会和你一起解决可能出现的问题,而这个合同的目的并不是定义关系,而是要定义当信任荡然无存、事态极其严重时会发生什么。

3.讲小白用户的故事

你懂的,经典的笑料,比如“屏幕上的涂改液”、“我就直说了吧,你的电脑不启动是因为停电了”,还有,“我让他把打印机的插头反过来插一下,可是这是三针的插头(偷笑)!”

当其他的IT员工讲这些段子,尤其是指名道姓时候,尽管笑吧。或者如果你想确保让IT部门出洋相,你自己也可以给他们讲这些段子。这就是段子横飞,没有人彼此互相尊重的可怕场景。

如愿以偿了吧。

4.实行计费

这是劝阻人们使用信息技术的可怕方式:实行计费。不是别的计费,正是那些细化成本中心里每一个收费类别的发票,从CPU周期,到SAN和NAS存储(当然是分开计费),开发者工时,客服电话,每隔10分钟就记账。

争论账单的准确性,确定哪个企业部门应该支出这笔钱,没有什么能比这个更能鼓励合作了。

5.坚决要求投资回报

想确保项目得不到资金吗?坚决要求IT的管治过程需要明确的,有形的财政投资回报。这么做一定能保证IT失宠,能帮助业务部门更快地取得更好成绩的技术得不到资助;还有能促进客户满意度,以IT无法证明的方式增加销量减少销售成本的项目,却在高管的办公室里被窃笑。

6.为IT项目制定任务书

想要让企业/IT异常的方子吗?如果用软件交付来定义项目,那么当软件符合要求和规格时,IT的任务就完成了。

这样的话,当企业管理层抱怨软件不能实现它们要求做的事时,你完全有理由争辩说软件所做的就是它被要求做的,因为它完全符合规格,难道不是吗?如果这个方法行不通,软件不符合要求,你又可以争辩说要求时错的。这是谁的错呢?当然是签字同意的业务经理。

又或者,你可以用可行的办法:从你命名项目的方式开始,用业务成果(“提高销售效力”)来定义每一个人,而不是软件(“实现Salesforce.com”)。

7.指派项目赞助人

项目管理圈里众所周知的一件事是每一个项目都必须有一个项目赞助商,不然成功的机会渺茫。但你想确保项目失败吗?指派一个。

赞助商,真正的赞助商而不是名义上的赞助商,那些打心底想让项目成功的赞助商。如有必要,他们愿意冒险来确保他们的项目成功,你认为那些被指派的赞助人会这么做?反正我是不会。

8.建立云计算战略

这是确保IT失败的极好的办法:建立云计算战略。这样的话你就可以推出结论。你知道你必须在云端,而战略的目的就是要让这一切发生。

无论你想什么,都不要想得比这还宏大。不要考虑以服务条款定义的受控的技术架构。毕竟,这么做会导致你认为这些服务就是你要的,而云可能是提供它们的好办法。

有一个老规矩是这样的:形式服从功能。服务就是功能。云则是你所需要的其中一些服务可能呈现的形式,如果你不想让IT成功,就要避免这种想法。那么云是必不可少的。

9.用敏捷方法,走传统路子,同时进行

敏捷方法有很多要求。成功的其中一个先决条件是有较高的非正式用户参与度,以至于频繁而微小的路线修正时有发生,开发者每天都能看到进步,且用户接受度测试每天都在进行。

走传统路子有一个要求:更低的小时人工成本。它没有要求的一样东西正是敏捷方法所要求的较高的非正式用户参与度。综合12个时区的差异、语言障碍、文化鸿沟和受制于网络会议处理能力的互动,敏捷方法颇具挑战。

让它凑效不是不可能,只是这不适合胆小怕事的人,更不适合那些初涉敏捷方法的IT机构。

Want to go Agile? Want to go offshore? Pick one.

想用敏捷方法?想走传统路子?二选一吧。

10.以毒攻毒

保证IT失败的万无一失的下一步是坚决让所有人都要多任务工作。毕竟这是一种令人向往的能力,难道不是吗?但这实际上意味着降低了生产力和质量,同时为了要做更多的事儿增加了压力。

如果你忍不住要别人停止手头的工作去做别的工作,那么记住:人类不擅长多任务工作。他们最多只能在两个任务之间来回切换。每次他们切换脑力工具的时候都会浪费掉时间,一个任务所需要的注意力越集中,他们浪费的时间就越多。

想让IT成功吗?让人们完成手头的工作再做其它的事。

11.同时进行很多项目

IT从来就没有足够的人手来处理所有人的需求,所以你尽一切努力让很多项目同时启动,并让员工游走于这些项目之间,这个做法也不是没有道理。

换句话说,你想让所有的项目花更多的时间,更多的钱,却取得不合格的成绩。

如果你想IT建立良好的声誉,制定这样的规定:每一个要启动的项目都必须人员齐备,“人员齐备”在这里的意思是项目永远不需要等某一个团队成员有空了才能启动。

这样做的话,你的每一个项目都能完成,而不至于因为你继续进行多个项目而一个都完成不了。

12.不管对什么要求都说可以或不行

确保IT失败的最后,也是最好的办法是不管对什么要求都说可以或不行。说不行的话,关系就毁于一旦。说可以的话,你就做出了无法兑现的承诺,因为你和其他人的时间都被占得满满的。

如果你想要的是成功,正确的答案应该是:“我们能做到,这就是代价。”

请求管理有一条不可违返的法则,不管请求是项目范围的变更,还是软件改进,或者是给计划中不需要笔记本电脑的人提供笔记本电脑。

不要说不行,也不要说可以。解释你为了符合要求必须要做的事。接下来就是对话而不是争吵。

本文转自d1net(原创)

相关文章
|
编译器 C语言
《C陷阱与缺陷》之“语义”陷阱——数组越界导致的程序死循环问题
《C陷阱与缺陷》之“语义”陷阱——数组越界导致的程序死循环问题
149 0
|
程序员
【编程】程序的局部性原理对代码效率的影响
【编程】程序的局部性原理对代码效率的影响
148 0
|
存储 人工智能 自然语言处理
【C缺陷与陷阱】----语义“陷阱”
那获得该下标为0的元素的指针,如果给这个指针加1,就能得到指向该数组中下一个元素的指针。也就是指针+一个整数得到的还是指针,只不过指针的位置发生改变
110 0
|
存储 设计模式 Java
对内存可见性造成影响的代码
我们在开发过程中,是不是频繁的写一些System.out.println()来验证程序的执行?切记在正式环境将打印语句去除!
113 2
对内存可见性造成影响的代码
|
存储 安全 算法
STL中有哪些副作用或稍不注意会产生性能开销的地方?
可能很多人都不在意,在使用STL容器的时候,潜意识里面将clear()成员函数视为常量时间复杂度O(1)的。但是其实不然。我感觉可能是很多人都知道对于vector而言,clear()之后,修改了size()的结果,不影响capacity()的结果,因而得出clear()只是修改了某个标记,是常量时间复杂度的错误结论。
886 0
无止境的内存优化——停不下的循环
小伙伴们是不是跟我一样,以为之前的内存优化已经完成了?不,这才刚刚开始……让我们一起进入这无休止的循环吧! switch语句和查找表 / Switch statement vs. lookup tables switch语句通常用于以下情况: 调用几个函数中的一个 设置一个变量或返回值 执行几个代码片断中的一个 如果case表示是密集的,在使用switch语句的前两种情况中,可以使用效率更高的查找表。
1125 0

相关实验场景

更多