"...or how to avoid the most common mistakes when cooperating with a software development company?"
We all have grown up with a marble hard motto: “The customer is always right”. And probably he is, in a grocery store. Once you take this as an instruction for software development cooperation it leads you to local and at times to devastating disasters. DDI Development has canvassed sales and project managers, programmers and testers from several teams in order to outline the most common annoying as well as destructive mistakes that can disrupt further cooperation.
“I want my online store to have a cart, PayPal integration, and neat design. How much is that gonna cost?”
The only way to receive an exact price estimation is to provide a comprehensive document with all features of your future product thoroughly specified. Until then it’s going to be pure guesswork. Imagine yourself in a vehicle store asking for the car which has wheels, a windscreen, and some bumpers. Your fair price estimation might be in a range from $20K to $1,5 million. Two ways are available here: you either write the documentation yourself, which is time-consuming and yet beneficial in advance, or we will compose the specification together for money. The outcome document is the only objective matter to understand how much is it supposed to be paid for converting your ideas into reality.
“Decide the way it is supposed to work yourself. You are professionals, and I totally trust you… Yes, that’s great! I like it, but let’s add some changes here, there, and over there.”
Please, make up your mind. Service providers can be trusted either as a doctor, who decides your treatment, or a tailor, who captures each one of your wishes. Not both at a time. Adaptations are great if they stick to market changes as it evolves. Unfortunately, it’s a common case when client’s requests unpredictably change with any constructive logic behind. He doesn’t know what the outcome must be, so he ends up examining all possible options. It prolongs a development course, disrupts programmers’ motivation, requires more money, and eventually a result is worse than the initial version.
“Come on, it’s just a button! I’m not an expert, but a cousin of my friend’s grandmother’s sister told me that this task can be completed in a couple of hours.”
The Google start page has the input box and two buttons, which doesn’t make it simple. The scope of a functional part might never be obvious for a user though it takes a lot of effort and time when developing its backend. A good project manager is going to clarify all the points, describe the relations between time and tasks, as well as warn about the risks of rapid and yet unreliable development. You can speed up the programming of some time-consuming feature, but in the present case there won’t be any guarantees to keep it stable.
“Currently, we don’t have the budget that would fit your quote, but we promise you a great promotion and feedback. You can add a great project to your portfolio. You’ll inevitably get a great revenue later if you start working with us now.”
If you’re looking for the technical co-founder who is going to work on a sweat equity basis, you should be tolerant to deep revisions of your project aligning it with your partner’s view. Moreover, it will be hard to find programmers ready to gamble on their time and money since the majority of startups fail: there must be reliable guarantees of a return. Whereupon hiring an experienced team means providing decent payments regardless long-term benefits. Usually, the job offers containing promises instead of revenues are declined.
“You have 50 specialists in your team. Then complete my 600-hour project in a fortnight, will you?”
One woman can have a baby in nine month, but nine women can’t have a baby in one month since that. No matter how many employees a company has, it would be a harmful practice to throw more than five-six specialists to deal with a single project. Adding more people usually resolves into coordination issues. So a reasonable division of labour supposes engaging a person per task, in which case we’re going to have two designers for UX and UI respectively, one or two backend developers, a frontend specialist, and a tester, besides a project manager. You have to keep in mind that these people are not usually working on your project simultaneously as well as on a full-time basis. Front and back end development starts only when a design is finished. Moreover, workers may have meetings and other arrangements that eat up their office hours.
“We look for an excellent expert having experience with Zend, .Net, Ruby, Python, Objective C, Java, CakePHP and Symfony, Spring, С++, Erlang, well-versed in UX/UI design, making iOS and Android applications as well.”
Even though versatile experts are beneficial for development companies, each specialist covers his own niche. You don’t ask a pilot to design an airplane and vice versa you don’t want an aircraft designer to pilot your flight, although they both relate to aviation. These high expectations resolve into a mutual slippage: a company loses a potential partner, whilst a client enhances chances to come across dishonest providers quick on any promises. If you want to immerse in technical aspects, it would be better to conduct a research and consider technologies to be utilized in your project. Once you’ve done it, find an adept rather than a jack of all trades.
“$500 is the budget to do my social media project. Period! NO TIME WASTERS PLEASE!”
Do you usually buy French brand perfumes on the corner of a street? In a high-crime neighborhood? Yes, next to those weird fellow who seems to be distributing marijuana. Even though risking on your little money may be successful, there are precious few trustworthy freelancers able to successfully develop your fancy product for food. Once you’ve decided to hire someone cheap, three scenarios are the most likely to happen. The first: you’re going to get the rigged piece of software asphyxiated by bugs. The second: a hired developer will abandon you haven’t finished the work. The third: you will eventually get your product after numerous deadline breaks as well as price increases, and you won’t be able to draw away since the money was paid and the time was lost. Basically, you could have reached a launch date faster if you had been ready to pay the same amount right from the beginning. A tight budget isn’t a death sentence to your idea. A wise decision is to reduce a number of requested features and apply to a decent company. You can always build some basic website for an affordable price, release it as the version one, and start your business. Qualified developers always take care about scalability and your software will keep updating as your business grows. More on price estimations you can find in our article “How much does a website cost?”
“Hello, how is my project going? Have you completed the module? I’ll call you in a couple of hours to find out what has been done by that time. And I’m planning to call you this evening and tomorrow morning!”
That’s great if you do care about the development process. The “trust, but verify” principle is welcome in cooperation unless it’s exaggerated to a degree when it distracts a workflow and brings tension. There is a number of measures available to track changes and control development. Usually, development companies offer to use software project management services that help you to be in touch with the situation. These powerful systems allow to set tasks and milestones, leave comments and communicate, as well as receive notifications about the latest updates. DDI Development, for instance, can work with any project management tool a client would require. Moreover, a lot of companies store the functional releases of products they are currently developing on a Git repository so that client would have access to the code. As a rule, all communication responsibilities are taken by project managers who give voice calls and compose reports after another milestone has passed. Our company also lets clients communicate directly with developers, which is the part of our transparency policy. So there are numerous ways to ensure that everything is going well. Unfortunately, a hurried rate of phone calls, hourly messaging to programmers on any tiny reason, everyday clarification of release dates are the common mistakes full-on clients do. And these are the best ways to discourage a developer and make him believe that the project is not going to be completed at all.
“Damn, it’s obvious that this button is supposed to be on the right! And it must be green, not yellow. What were you thinking?!”
The only thing obvious here is that the times of sorcerers and witches have long gone. However, still some people consider mind-reading the part of provider’s responsibilities. There wouldn’t be the need to add this paragraph unless this was the common case. Let’s acknowledge the fact that even a comprehensive specification might have a number of omissions. If you encounter differences between the initial image in your brain and practical outcome, try to take it easy. Are sure that this particular solution doesn’t fit your project? Sometimes a specialist’s view is something worth your trust as far as this guy is the professional able to justify his decision. Negotiate the point with your in-house teammates and weigh up the options. Is the gap between expectations and outcome critical for you? Are you ready to postpone the release date and possibly spend more money? Then it’s better to explicate each tiny piece of your requirements and consider revising presumably vague descriptions in advance.
“I want it done fast, cheap, and in a quality manner!”
Everyone does. We wouldn’t be humans if we didn’t. The thing is whether you realize the fact that you have to sacrifice something. Do you want it done rapidly and cheap? There is an extremely slim chance to meet quality standards. Is it supposed to be a robust product completed within short terms? Be ready to dip into your pocket. Do you seek quality having a limited budget? Don’t expect to reach your goals soon. Well, you get the idea.
Since we have covered the issues that annoy developers in client’s behaviour, the next step is to show the most common mistakes development companies do. Stay tuned and you’ll find out more about our path through mistakes to experience.