Communicating with Vendors

Question

We are a small software team (as far as programmers go) and have a team of vendors on the other side of the world that program for us. We own the product, and simply dictate to them some of the tasks to work on. I am one of the lead programmers and also the project manager of this particular project, so I am a programming and fulfilling requirements as well as outlining them.

I am having difficulties communicating with the vendors exactly what is expected of them. Let me start by saying we are fairly new at this and I don't have a lot of experience leading a team of vendors, especially when it is difficult to communicate verbally in English, and they work during my night and then I come into the code they pushed while I was asleep. Problem is, I end up spending a lot of my day just checking what they did, and fixing bugs and cases they didn't think of. They're not thinkers, they do exactly what I tell them, and nothing more or less. Most of the time, I feel like it would just be easier to do it myself.

My question is how do most teams like this communicate? Right now we have weekly telephone meetings and I email them nightly the progress I made, as well as what is expected of them. When I think "how to communicate with other programmers" the answer seems to be UML. That's what it is. I certainly am very familiar with UML, learned it in school, but have never really used it on the job. It's just not something we do, in fact generally the requirements for a task are in my manager's head. I can get those into a spreadsheet or a flowchart, but never an official diagram.

Is UML something teams like this actually use? In all reality, I feel like I learned a lot in school that no one actually does. If so, which diagrams are the most useful/used? From my knowledge, in this project where we are revamping something that exists in the system already from the ground up, I feel like the following would be a good approach:

• Create a quick ER diagram containing any added/updated/used entities in the project.
• Create a detailed use case model, clearly defining and numbering each use case.
• Create a sequence diagram for the complex use cases (as well as their alternate flows) to show exactly what is expected each step of the way.

I feel like this would be a good start. We don't really do a good job of capturing requirements currently, we kind of just start coding based on something we drew up on a whiteboard. Obviously this needs to change as well, to avoid getting a week into a project and realize that we forgot something.

What are your suggestions/experience? Unfortunately we're sort of flying blind and just don't have anyone experienced enough in these situations to go to. I want the project to be a success, but I can't keep having the vendors (understandably) making mistakes because I assume they know X or Y. How can I utilize them more effectively?

Answer 1

Having been in your situation on a few occasions, I've found that UML diagrams and the like are not a good way to go. They tend to be overly complex, and much more difficult to communicate about - now your audience not only has to understand what you said in english, they also have to be familiar with UML diagrams and know how to apply them to the work they're doing.

The goal is not to come up with what you consider to be cleaner/more concise/more accurate ways to write down your instructions, but to make sure that your instructions are more easy to understand/follow for a non-english speaking audience, that is the product of a different educational system. With that in mind - UML diagrams will only help if your target audience is capable of understanding them better than spoken/written english.

The following approaches/ideas have worked for me:

• You're stuck being a project manager. You might have to accept this means an entirely different set of skills, work, etc... that you'll find yourself using - a different job description from being a software developer. You might also have to accept (and explain to any overlords you may be reporting to) that this is a time consuming job - you can avoid having to rewrite their code, but there's other work you'll have to do instead, which will impact your job as a software developer

• Make sure that you're regularly speaking with the people actually writing your code - try to eliminate the intermediary level(s) of management.

This might mean going for a more involved micro-management approach (say, daily agile-style standups, where you do video chats with the dev teams in groups of less than 7, and have them each report on what they've done today, what they're stuck on, what they'll do tomorrow). Or it might mean trying to get the lead developers to show up to your weekly meetings, and getting them involved in the discussion about what code they've written/they're about to write. Maybe you can put them on your chat contact list, and, when you code-review their work, ask them directly about code they've written; cultivate a friendly relationship.

The goal is to open up communication channels more - so that the people who are actually writing the code understand that (a) you're holding them to a higher standard, (b) you actually care about them, and the work that they're doing and (c) making yourself available more easily/quickly for any questions they have when they interpret your instructions.

• Learn to speak "their" version of english. More frequent communication should help with this - expose yourself to as many different people on the otherside, all speaking about things that you're intimately familiar with, and try to pay attention to/pick up idioms, expressions, etc... that they are using - and then to use them when describing your requirements.

• Add unit testing to your list of requirements. Have them write a unit test framework, and write unit tests for each story - it's often easier to send over an extra unit test and ask that it be green, than to explain what you want; maybe not everyone involved speaks english, but everyone involved should, theoretically, speak code.

• Make sure that you include UAT with each story description, not just requirements. Use a standard pattern - "As a {user description} i want to do {some action} which results in {specific description of result}". Ask them to provide you with tests that show the code actually does what you asked it to do - again, it may be faster/easier to modify tests and send them back, than to re-explain yourself

• Most outsourcing outfits are extrinsically motivated; they're in it for the money. For development work, especially if it requires any creativity, that's a major downfall. Either split the work up so that anything you send to them is the kind of work that's easy for people who are only in it for the money to do (work that doesn't take creative thinking is ideal), or get them to be more intrinsically motivated.

For that last bit - the low hanging fruit include switching to video chat for all your communication; learning about things like holidays, birthdays, etc... and mentioning them on calls; making it a point to highlight particularly well done work individually, and with a bit of delay - and highlighting bugs/issues as soon as they're discovered, and with a can-do-team-approach tone of voice ("here's a bug - can we get this fixed?" vs. "who wrote this? sam? dude, your code here was awesome!"), etc... If you do manage to get to know the devs, it should help - find out what they each like about the work you're sending, and see if you can help them to do the bits they like.