Deliverables

Deliverables are things that can delivered.   There are two fundamental ways to look at projects.

as a group things that have got to be done (tasks); or
as a group of things which have got to be delivered.

As the delivery of a thing invariably involves a task the distinction may seem irrelevant but there is an important difference between tasks and deliverables which makes deliverables a widely adopted alternative to tasks.

If you have a deliverable in your hand then you have a result. No ifs no buts. If someone does some work then maybe you have a result maybe you do not. 

If you want to report progress, the theory goes, it is much more meaningful to report the number of things delivered than the amount of work done.  You might have done half the work forecast in the plan but actually have progressed hardly at all. If you have delivered half the things promised in the plan then there is a much greater likely hood that you are half the way through the project.

Another advantage of using deliverables is that deliverables can be specified much more easily than work. To some extent a manager does not care how a deliverable is created as long as it meats its specification. 

Also staff generally prefer to be left to their own devices when it comes to the how. They would rather be judged by what they produce than how they spend their time.

Having said all this the difference between tasks and deliverables is often one of semantics. Almost any task can be stated as a deliverable and any deliverable can be made into a task by adding the word 'Make in front of it.' (Make a football etc..)

Some methodologies - notably Prince2 - force you to describe both deliverables and the tasks which produce them.  This often produces a meaningless duplication.

The language does not matter. What does matter is that it is clear what is to be produced and how it is to be judged that that thing has been delivered. You can do this with tasks but it is much more convenient to do it with deliverables.