IntroductionMy company was looking at using vtiger in order to replace the old, aging in house CRM system. Our old CRM system is consisted of separated subsystems that are functioning on their own with absolutely no integration among themselves. Due to that the subsytems were developed in a haste and has never since been upgraded, it became harder and harder for us to maintain it.
Hence we have decided to use vtiger. We found that vtiger fulfills most of our needs. The module architecture of vtiger means that we can always write a third party module to provide extra functionality we need without touching the vtiger core source code.
And so, there went my quest to write a dongle module to supplement existing vtiger CRM functionalities. I have very limited PHP knowledge, and zero knowledge in the internal working of vtiger module architecture. So I wrote my specs, and went to freelancer.com to find someone who can do the job for me with a reasonable price.
To cut the long story short, my project did go on smoothly. Despite that many warning against the perils of outsourcing, my experience shows that outsourcing can still be cheaper than doing everything in house, with lower defect rates and faster completion time.
- Before I started to even post the project on freelancer.com, I took great pains to compose a spec. I wrote the use case of the vtiger module, the UI specification, the reports I wanted to see and so on and so forth. The specification is so detailed that I specified the URL for each forms, specified the elements, and the purpose of those elements for each forms and even designed the database schema for the backend. The point of this exercise was not to corner the implementer into doing the work my way, but rather to make sure that the implementer really understood my requirements.
- A lot of people hate writing specs; why you are writing something that no one reads, and something that is so ephemeral-- we all know requirements change with time, right? And if your spec is so complete, you might just as well code the whole thing yourself!
- My reply to the above points are as follows:
- Regardless of how whimsical is the one who designated the requirements, changing the requirements in English is still significantly easier than changing the source code.
- Designing the requirements in detail force you to think about difficult issues even before you start writing a single line of code. I suspect that those who refuse to nail down the requirements are clueless about that they want, and they don't want to look stupid when the developers confront them.
- Yes, requirements do change with time, but this is a point that for writing requirements, not against them. It's easier to document the requirement changes and their reasons in English, rather than in code, no?
- As to the point: "if your spec is so complete, you might just as well code the whole thing". This is simply a straw man argument. I expect the implementer has some sense and experience in the domain and I don't expect him to ask me to specify in detail "does a button click works". Furthermore, coding is not just about UI, it has more than what meets the eye. Even if coding was just about the UI, it was still easier for me to "code" in English, rather than code in PHP or any other programming language.
- There were a few bidders, and all their resume looked very impressive with multiple years of experience working with vtiger. But the resumes lie! You would need to interview them. And that was what I did; I interviewed them on their understanding of my spec and quizzed them on their vtiger ability. This was where the fun came in. Despite impressive resume, a few showed great difficulty in understanding the spec, another showed so much misunderstanding on vtiger that even I could detect, and another kept on saying my questions were elementary and he wasn't bother with them. All these kind of behavior didn't inspire confident.
- But luckily I did manage to get a developer who showed mastery in vtiger and understanding of my spec. We hit off quickly. I had full confidence that the project was going to succeed. In fact, if you were not confident about the prospect of an outsourced project, don't continue!
- On the day of handover, we spent a few hours going through the applications, weeded out the bugs and enhanced a few features. Despite that the specs were completely written, and that the implementer showed good understanding during interview stage, when he delivered the thing to me, I still found a few parts that were not done properly. It took us a few real time sessions to hammer out all the issues, and we were done.
- As predicted, the project was a resounding success!
My thoughts on engaging freelancers:
- Contrary to the prevailing opinion, there are well-qualified, smart, fluent in English knowledge workers in India, and their rates do come in cheap-- something like USD 20/hour. The only thing is you need to know how to identify them. I did this by interview them at length, ask them to show a sample of their past works, make sure that they really know their stuff, and more importantly, they show deep understanding of my specs. If they cared to read about your specs and understood them, that meant that they were more likely to commit to your project and there was a higher chance of success.
- There will be a lot of "professional" firms that come knocking your door; they can show you impressive websites and resumes and they can even show you the past vtiger modules they did. But you still have to take the pains to interview them. They might have done their projects but this is not a guarantee that they can do yours.
- Indian slang can be a bit hard to follow for me as a Chinese. And I am sure that my slang can be a bit hard to follow for an European, or an African or anyone else. Which is why I make it a point that all correspondence must be done in writing form. Some would insist that a chat-meeting is more efficient and therefore more preferable. I would say that if you can't write down your requirements clearly, then perhaps you haven't really understood it enough.
- The act of writing your specs down forces you to think deeply of what you want, and reduce the amount of time wasted on requirement clarification, communication and rework. No, this is not Waterfall; and even if it is, Waterfall model is good for this kind of projects!
- Set clear boundaries and expectations for your freelancer, and show empathy. You can do this by giving them good specs, make sure they really understand them, then give them free space to do their work, and only come back to them when the deadline looms near.
- When dealing with a freelancer, make sure you structure your payment in stages. You pay only when a stage is done and you are satisfied with it. And you can easily cut your losses if you found that the freelancer was not performing up to the level you expect.
- Most importantly, go with your feeling! Before you hit off, make sure that you are comfortable with the guy you engage!