IT部门存在的意义，谁是IT的客户

今天看到这么一篇文章，转过来给做IT的朋友。我们必须审视自己存在的理由和意义，不仅要分清最终的客户，还得和同为IT的协作者、IT客户做好服务。你尽力让你的客户开心了吗？

知道你们这帮IT点进来是冲着美女图，有兴趣的朋友继续读一下英文文章吧。

Who are we and why are we here?

Why does IT exist? By IT, I mean the traditional Information Technology department that supports the computer needs of a business. That can include programmers, desktop support, networking, data analysis and anything else traditionally in the "computer professional" biz.

I ask the question because I think some people, usually the prima donnas who think they are so much smarter than everyone else, have a tendency to forget why we exist. I mention the prima donnas specifically but it happens to so many in IT. I have been guilty of it on occasion (and I hope I'm not a prima donna).

We aren't here to show everyone how smart we are. You just wrote the most amazing function that does some awesome processing. So what? It's nearly unmaintainable and is waaayyyyy over engineered. Tell your buddies about it but I don't want it.

You have just found the coolest tool or the newest language or the most amazing algorithm. So what? How does it help? Better yet, how will it be supported?

So why are we here? We are here for a single reason. To support the business. How we support the business will change based on job function. If you are not directly and actively making your customer happy, you are not doing your job.

The major dysfunction that I see in IT shops is that IT blames the customer (and who is your customer?) for their problems. Worse yet is when IT considers the customer to be too stupid to keep up with all of the nifty new functionality or when IT does their best to ignore those stupid new requirements (Ugh! Scope creep!).

IT's job is not to force "solutions" or "best practices" down the throat of the business. IT's job is to guide, and at times convince, the business of technical direction and deliver the service or software dictated by the customer. If there is a better way to do something than what the customer has asked for, IT must convince the user of that, not just take it upon themselves to deliver what they think the customer wants. Dialog and facts and an acceptance of doing it as requested when required.

Notice the trend here about the customer?

Who is your customer?

It's seems to have fallen out of favor in recent years but when I got started in IT, making the customer happy was job #1.

As far as I am concerned, part of doing your job is knowing who your customer is and making that customer happy. For some functions it is easy to identify the customer. Say, desktop support. The customer is anyone in an organization who is using a computer.

I work in the programming/database/data side of the business. It sometimes gets more difficult in that area.

If you are a developer, who is your customer? In many cases, your customer might be the end user, especially if you develop operational systems such as order entry. In other cases, such as when you develop products for sale to external customers, your customer might be product development. In a data warehouse or reporting environment, the cus tomer can run the gamut from executives to product development to sales teams.

If you are a DBA, you customer base gets broader. You are responsible for the integrity of the business's data as well as keeping those databases up and running. I know many DBAs who consider only a certain line of business to be their customer, the end users who retrieve data from specific databases.

As a data architect, I am responsible for standards and pushing for best practices in the organization. I know a few data architects who don't think they have customers and that their position is some kind of an elite overlord of all things database (not unlike some DBAs).

What I think many DBAs and architects forget is that they support the development efforts of the organization also. That means that the developers are the customer. In many cases, the developers are an architect's most important customer.

As a data architect, I work directly with the developers on a daily basis. My job is really part data architect and part development DBA (and part configuration management and part technical documentation and part tester and etc). That means that the service I provide to developers is one of the biggest services I provide to my organization.

I also work with DBAs on a daily basis. Discussion of best practices, data design approaches, implementation plans, etc.

It behooves me to have a good working relationship with my customers and not be the confrontationist (I just made that word up but it fits a few people I know). Now, I also enforce certain standards and some of those standards aren't, shall we say, appreciated by my customers. In these cases, I do my best to explain the need for those standards. I try to make following the standards as painless as possible (via training and hands on support). I also try to document standards as simply and plainly as possible.

I am uncomfortable with the antagonistic relationship between DBA/Developer/Data Architect that I see, and have experienced, on occasion. It seems to be a bad cliche these days but everyone is, or should be, on the same team. On one of my previous jobs, the DBAs refused to speak directly to the developers and forced them to go through intermediaries (and management allowed this!).

I can sum up this post with two bullet points:

• IT exists to support the customer
• In a technical job, you customer may very well be another technical professional

What is your job function and who is your customer? Do you do your best to make your customer happy?

LewisC

原文地址：http://it.toolbox.com/blogs/oracle-guide/the-purpose-of-it-and-who-is-your-customer-32102