I think relatively low social skills is a common problem in software developers. It certainly is in the 200 or so developers that I have managed or worked with in my career so far. I've seen a lot of articles recently talking about this in terms of Autism, HFA or Asperger's. However I think comparisons like that are counter productive, like putting someone with a slight limp in the same category as someone confined to a wheelchair.
Software development skills (i.e. things you can learn, like how to code Javascript or how DBs work) flow from talents (i.e. things that you're born with, like high IQ and an aptitude with technical and logical problems).
People skills are a similar - they develop from natural talents like empathy and rapport.
Just because you don't possess a lot of the natural talent doesn't mean that you can't learn the skills - it's just harder. By the way this is what distinguishes disorders like Autism from just being a poor communicator - someone with full Autism can never develop genuine empathy.
As a developer you don't need to develop a strong communication skill-set. When I say that I'm talking relative to all the other jobs out there. A good sales person can contact someone they've never met out of the blue (something that will inherently annoy whoever they call) and still end up with that person liking or trusting them. A good leader can motivate a hall full of people at once. A good manager can turn a room full of arguing egos into a team getting things done. A good developer doesn't need to do any of that.
What you need to do as a developer is become a competent technical communicator. For that you only have to focus on a few things:
Listen - I really can't stress this enough. I've worked with a lot of brilliant programmers who never really listened to other peoples' ideas. Your idea to solve the same problem might be brilliant, but every time you need to properly listen and understand their idea too.
Explain - This is the other side of (1) - lots of developers have this behaviour pattern where they try to explain something complex and abstract, fail, and then blame whoever they're explaining it to - "you're not smart enough to understand". As the person explaining the problem it is your job to turn it into something that they can understand, not theirs.
Empathise - Put yourself in their shoes: how would you feel if you were them? Is your idea better than theirs? How would you feel if they just dismissed your idea? What could they do to persuade you that theirs was better?
It's always your problem - Regardless of whether the person that you're talking to follows the rules above, you still can and should. They might be a bad listener, but it lies with you to get through to them. They might be bad at explaining it, but it's your problem to try and understand them. They might trample over your feelings, but it's you who can tolerate that and move on. You can always take ownership of communication problems, and developers that do get noticed for their professional attitude.
Keep practising these inside your team and you'll get better at communicating. When talking to people outside your team you also need to avoid jargon.
If you want to go down a business analysis, consultancy or management career path you'll need a lot more than this, but I think that might be off-topic for SO.