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?