For the first few posts on this site, I’ve definitely tried to walk you through the process of getting your site or program built (starting from zero). So far, we’ve talked about what types of different developers exist, and how to get them hired on Odesk.
Today, I’d like to address the actual process of getting your development project done. So, once you’ve got your programmer picked out, and you’ve decided you’re ready to move forward, this is the process I recommend you use to get things running.
This article is for people who are managing one (or a few) programmers for the creation of a website or software tool. It is especially for those of you who have never done this before, or, for those who have struggled with it in the past.
Quick Overview of The Process
Ok, here’s a rough outline of my development process:
1. Break it down.
2. Explain your business.
3. Explain your idea.
4. Give a simple job.
6. Start your first stage of work
Unfortunately, most people hire a programmer and then jump directly to step 6. In other words, they want to get their project started, so they just give their new programmer a job and set them loose.
This is a bad idea. But, I’m getting ahead of myself. So, let’s start with Step 1.
Step 1: Break it Down
Before you even have a conversation with your programmer or team of developers (aside from the interview), you need to go through your project and break it down into very small chunks and stages.
This is extremely important, and underlines my development philosophy – don’t skip this. The best way I can explain why, is by using an analogy. Stick with me here.
Treasure Map Analogy
Imagine for a moment that you’re a pirate, and not just any pirate. You’re the Captain. The head honcho. The guy with the eye patch and the talking bird, etc…
On this beatiful pirate day, you’ve arrived at an island where you know there is buried treasure. You used to have a map, but you lost it. To make matters worse, you also recently lost your leg to a stray cannon ball. Not cool.
So, your pirate hearties are looking to you to tell them where the treasure is (and how they can find it).
You’re going to have to explain to your pirates how to find the treasure (since you can’t walk the route and do the digging yourself).
Now, imagine gathering all your hearties around you on deck and simply saying to them…
“Go find ye buried treasure. It’s on the other side of that thar mountain.”
Now listen, your mateys are pretty bright. And, they can probably work their way to the other side of the mountain without the map. But you haven’t really given them enough details to put them right on top of the treasure location.
In fact, you haven’t really explained what they’ve even looking for.
But, what if you said the following?
“Arrr, we be searching for some buried treasure. It be a large case with a black skull on the chest, full of gold and buried deep in the earth.
First, you’ll need to find the seaside rock that looks like a elephant. She be at rest on the west side of the island.
Then, ye should travel due South till ye reach a small stream…”
Ok, I think you get the point – enough priate speak.
Listen, you’re the guy with the mental map of your software project. You know what you want to build, and you have the outline.
Your programmer, no matter how smart, cannot know what the treasure map (your project) looks like unless you explain it to them.
And, if you don’t explain the map to them in a way that they can understand, there’s gonig to be a lot of misscommunication and wasted time/money.
Don’t be that guy.
Thus, you need to break your project down into steps that require no more than week or two of development – MAX. If you’ve never done this before, you may not have a great grasp on how much work that is or isn’t. Don’t worry, you’ll get the hang of it.
Sit down with a piece of paper and outline what the very first stage of your project will look like. Usually, I like this to be pure functionality only. You want your programmer to start by buiding a tool or site that simply functions and implements the CORE of your idea. No bells, no whistles, no extras – none. Nix. NADA.
This is important for two reasons.
First, the simplicity will save you time and money, allowing you see if you have proof of concept (before you spend all the cash needed to make it fancy).
Second, you will allow your programmer to focus on only the most important aspects of your program, reducing the amount of code he or she has to write (making their job simpler.)
Oh, and one more reason. If they get it wrong, it’s easy to adjust on the fly because no one has done that much work yet.
Coding is like writing a novel, it’s easy to change the storyline 5 pages in. It’s pretty tough in chapter 24.
Ok, I’ll try to give you a few examples that we’re all probably familiar with.
If I was building Twitter, my first step would be to create a dashboard where I can post updates. This also becomes my ‘profile’ later on. That’s stage 1.
After that I might make it so there are multiple people, with multiple dashboards. That might be stage 2.
Then, I might make it so they can choose to link to each other by ‘following’, etc…
Each step builds on the one before. But, the core of Twitter is posting Tweets. So, that comes first.
Keep it simple.
Or, let’s say your having a lead generation form built. Step one is creation of the form. Information can be entered in the fields, and when someone hits the submit button – it sends.
It doesn’t tell you that you mistyped something. It doesn’t let you know you ignored a field. It doesn’t check for valid phone numbers, etc…
Right now I’m working with the AdSense Flippers to create a theme that improves Ad click-through-rates. Stage 1 was to ensure that we could record clicks.
That’s the heart of the program. If we can’t record clicks, then we can’t track them. And, if we can’t track them, we can’t optimize them.
Every project is different, so I can’t realistically cover ever scenario. You need to think about this in terms of bare bones. What is it that is most important for your tool or site to do? Get that built first.
Then, it’s time to create the next stage, where small bits and pieces start to come together. You add some complexity, make the tool more useful, etc…
But each stage is small and builds only slightly on the one before it.
Once you’ve got a relatively clear idea of what the different stages of your project look like, you need to write each of them down and post them where everyone involved with the project can view them.
Why do it this way?
This gives your programmer a starting point, an ending point, and an idea of where the future is headed. And, it will allow them to make small decisions (programming choices) that make sense (without having to consult with you). You’ve taken the treasure map out of your head, explained the route and the final destination to them, and given them the tools to get the job done.
If you start by simply explaining the end result and setting them loose, they’ll find their own way there (you are paying them after all), and it might not be pretty.
Ok, let’s move on.
Step 2: Explain Your Business
Ok, now you’ve got your whole project outlined. It’s time to get started, right?
You still haven’t laid enough groundwork for success.
You need your programmer to understand your business. You need them to get what you do.
Back to the pirates.
If, in search of the buried treasure, your pirate friends come across a pool of Crocodiles, a bandit of theives, or the British Navy, they are going to have to make decisiosn on the fly… without you.
You’re back on the ship drinking rum and carving a new leg. (I.E., you’re a busy person. You’ve got other things to do than manage your programmer.)
So, in order for your programmers (pirates) to make intelligent choices (without you) they need to understand how you operate, why you operate, and what your business is about.
Otherwise, they’re in the dark. And they won’t know how to make proper decisions when things come up.
What would the Captain do? Would he kill the theives? Would he go around the Crock infested pond?
You can’t plan for every possible contingency. But if your programmer understands what you do in your business, they’re more likely to get your software built the way you want it.
If you give your programmer a task, and a week later a bunch of work has been done that you hate, it’s your fault – not theirs. Either you hired the wrong guy/girl, or you didn’t give them a good enough map.
You have only yourself to blame.
Explaining your business is part of making sure that doesn’t happen.
Step 3: Explain Your Idea
Ok, now your programmer has an outline for the job, and understands what you do. Believe it or not, you’re still not ready to start the development process. But, you’re really close.
You need to explain exactly what this project is.
Naturally, you should have done a fair amount of this in the interview (to help ensure fit), but now it’s time to get into more details.
Explain exactly what you’ve got in mind, and allow your programmer to give you feedback.
They know things you don’t, and understand the technology and its capabilities in a way that you do not. So, listen up.
If they have questions, talk it through. Get everything out on the table to the best of your ability. And, get that outline you created published online somewhere.
It doesn’t matter if their are three stages or twenty. It’s best if you both have access to it.
Step 4: Give Them a Simple Job
Ok, you’re getting really close to actually starting your project. But you’re still not quite there.
First, you need to give your programmer a 2 – 4 hour job (which may or may not be directly related to the project at hand).
This does a number of things.
First, it tests out your communication. Did they get it? Did you explain yourself well? Was their confusion about the price, timetable, deadline?
Did they do it correctly?
You want to get this stuff sorted out, so that when you release them on your project, you can trust things are moving in the right direction.
Again, this is project specific, but I like to have my programmers do simple things, like build contact forms, setup automatic emailing scripts, build a simple interface, etc…
Anything that will likely be useful to the project later on, but which will allow you to test out the process.
Step 5: Feedback
This probably goes without saying, but once they have completed that first bit of work, you need to make sure you give them proper feedback.
Let them know what they did right and what wasn’t so good.
Be nice, but be honest. Remember, this will dictate how communication works in the future (when it matters most).
Step 6: Give The Stage 1 Work
Ok, now you’ve laid some decent groundwork. You’ve built a solid foundation with a reliable and trustworthy programmer. They understand you, your project, your business, your communication style and your timetable. They are ready to begin, and so are you.
Give your programmer the first task related to your project.
Ask them how long it will take, and keep an eye on their work with Odesk’s built in tool or a seperate time tracker like HiveDesk.
Tracking their time with a tool is important for the following reasons:
- It shows you they are trustworthy.
- It allows you to see exactly how long certain tasks take them.
- It gives you a clear way to pay them
- It gives you a way to cut in and stop work if you see something wrong.
Step 7: Feedback, Round 2
Ok, once your programmer has built the skeleton of your tool, you should again, give them feedback. Let them know what you thought of the work. Test it out yourself and see if there are any bugs.
At this point, things should be pretty straightforward because you’ve spent the time up front to get it right.
Step 8: Repeat
That’s really it.
The rest of your development project will be a series of meetings, work, tracking, payment and feedback. Keep looping over that process until you have something to use, sell, etc…
Remember, the key to a successful software development process (or treasure hunt) is to make sure your programmers (pirates) know what to do when they start working (leave the ship). Do that, and you’ll be happy with the results.