While application knowledge and experience is helpful, I've got a methodical approach I use when asked to tune a SQL statement.

Here's the basic approach/process I use to diagnose and analyze a SQL statement..

Analyze the Statement

1. I start by reviewing the WHERE clause, dividing it into clauses that restrict rows and those that join tables.
2. I locate candidate Driving Tables by looking at the "restrict rows" clauses as determining which table has the most restrictive clauses ( i.e. those that will result in the fewest rows). If not sure between a couple of candidates, I pick one.
3. Next I list all the tables in the FROM clause, starting with the driving table, using the JOIN criteria to link from one table to the next. This generates an ordered list of how the database should be accessing the tables, starting with the candidate driving table. This exercise generates all possible ways to join the tables together as well as making sure there are Join criteria for all the tables in the FROM clause.
4. Look for indexes on the driving table and determine which should be used or if a full table scan would be best. If I find a better index than the one the optimizer picks I add an Index hint to get the desired index to be used. If a full table scan is in order, I consider adding a parallel hint.
5. I try to join to tables that have restrictive where clauses before joining to tables that don't have any such clauses.
6. I now have one or more candidate explain plan(s) that need to be tested.

Compare Plans

1. Next I compare the actual explain plan of the statement in question with the candidate plans generated in the above exercise
2. Looking at the actual data (and running some queries to collect metrics) I consider trying different driving tables and join orders.
3. I review and compare each, and subjectively arrive at my best guess plan.

Test it out

1. The most effective hint I've found is the ORDERED hint. This works especially well when you have a lot of tables in the FROM clause.
2. I add /*+ ordered */ after the Select verb and the list the tables in the from clause from first to last the way I listed them in Analysis Step 3. Adding other hints like /*+ Full (driving table alias) */ is also a good way to get the optimizer to use the proper driving table.
3. Run an explain plan using the above HINTs.
4. If the plan looks good, execute it for real. Set Timing On and set Autotrace On (hopefully you have that enabled in your database)
5. Run the old and new statements several times to see how the timings work out. The Autotrace summary of blocks touched is a. good indicator of performance: the fewer blocks touched, the better.

Tuning Hints and Tips

1. There are many other hints and techniques that can influence an explain plan. Keep in mind that a Hash Join is nearly always better than a Merge Join
2. Nested Loop is better only if a few rows are being retrieved.
3. Tuning sub-selects can be tricky. I will often rewrite a statement to replace " IN (Select...) or a NOT IN" with a join to an in-line view and achieve significant performance increase by avoiding executing thousands of Nested Loop index reads with a hash join. Listing more statement rewrite options is beyond the scope of this article so I'll stop at that one lest this article become too lengthy.

Those are the basic steps I follow. Give them a try and over time I'm confident your SQL tuning skills will expand.
Happy Tuning!