When you let a development partner build modifications, in general, this is a good way to work:
- Document all that exactly needs to be built and communicated: This does not need to be an enormous document, rather it should describe the goals and how they will be reached as succinctly as possible. Usually your development partner will construct this document, and you will provide feedback on it. This step is a great way to ensure you have something to fall back on should discussions arise.
For each feature that is being built, it should indicate what the goal is, how that goal will be reached, what a user's interaction with that feature will be like, and how much time and money it will cost. It's also important to agree upon how often you will get progress reports and how much communication is required, and who to contact with questions.
Regarding the code quality, it's a good idea to at least agree that the Magento code inside the
app/code/corefolder is not allowed to be changed, and all changes to core functionality will be made through a Magento extension in either theapp/code/local/orapp/code/community/folder. - Let the functionalities be built: You may not be able to see much during the time it takes to build some functionalities, because it is difficult to present Magento extensions that are in development. However, it is recommended that you request a preview environment and at least have weekly updates on that environment, where all code that is able to be previewed is pushed to the preview site. At the very least, your partner should be able to report to you through e-mail of the progress that has been made, at fixed intervals.
- Test the functionalities: In this step you will have access to a testing system and you can collect feedback. It is important to test as thoroughly as possible and to let your partner know in as much detail as possible what is going wrong. Making screenshots and providing step-by-step reports to reproduce errors helps greatly with that. Screenshots can be easily made with a tool such as SnagIt (http://www.techsmith.com/snagit.html). Many such tools exist. On an Apple computer, pressing command + shift + 3 makes a screenshot that is saved to your desktop immediately.
- Integrate the functionalities in your store: It is a good practice to have a copy of your live site and to test the functionalities in the copy first before integrating them in your production environment. Sometimes, a Magento extension developed by a partner can work in step 3, but still cause problems in your store because of the other modifications present in your site. It's best to agree with your partner on what to do in that scenario beforehand.
Q1. A common occurrence when working with development partners is that the end product does not match the buyer's expectations. Which of the following are good ways to manage that risk?
- Choosing a partner that shows they understand what you are trying to achieve.
- Agreeing on communication schedules and having a single point of contact for both parties, who respond quickly when questions arise.
- Having timely previews of and updates on progress of the development and letting your partner know when things are going the wrong way as early as possible.
- Choosing the cheapest partner because the costs of a failed end product will be less.
- Choosing the most expensive partner because the most expensive partner is always the most professional.
- All of the above.
In general, the better you know what you want, the better is the chance that the end result will match your expectations. Because of that, it pays to research the theme or function you want to have developed and to form a clear idea about it. Try to document what the end result of custom work should be before a developer starts. This can prevent a lot of discussions.
A final note: do not let a development partner convince you that you absolutely need some feature. Most Magento developers have no experience with running a store themselves (though there are exceptions of course), and they do not know your plans and market. Often a technical partner prioritizes technical fanciness above possibly simple revenue-increasing features. That said, good suggestions can always, and should, be placed on your desired features list.