Active phase of software development

Cooperation with developer

The best way for professional engagement and interaction is when both parties are “in the process.” in other words, you as a client must participate directly in making important decisions and in the software development process, you should know the stage of the project its execution and understand all the features of its implementation.

Honestly, this is more expensive way for you. You (or your collaborator) will spend plenty of time for sketchy knowledge of web-technologies, which are necessary for the project implementation, you must regularly contact the representative of the development team, and you should think through all the problems, which are team facing on the project. But as a result, you will not have any surprises, there will be more optimal control over budget spending, better understanding of the technical capabilities of the system as a whole.

Another option is to relay the terms of reference and simply respond to the project manager's messages or to business analyst. This approach will allow you to do your own business, but gives a lot of questions to developer that in further can affect on the properties of the system. For example, the developer can choose more expensive method of implementation, which could lead to cost over-run budget, but will make the system more stable working.

For example, let's say you have chosen the option of working with an outsourcing development team on a hourly rate basis (time and material).

In this case, project manager and business analyst will divide set of tasks from terms of reference among different specialists and create for each of them their own tasks in management system (for example, Jira). You just need to agree with a team that you will have an access to this system - this will allow you to see what stage of project is implemented and gives you an opportunity to formulate a report.

Usually, the developer planning his work in a such a way, that the entire software development should be divided into 2-3 week periods (sprints), during which should be developed certain functionality, and at the end of each such sprint he can turn out whether the goal was achieved, was it good or not, and what should be corrected in development plan. Your task here is to participate in formulating the goal of the sprint, also take part in analyzing the result and adjusting the project plan.

Documentation of software development process

If the information on the basis of which the software development process is limited by client’s scenario patterns or prototypes, then developer firstly should execute some extra work:

• Analyze your wishes and understand what web technology is necessary to conduct in the development process
• Design the general architecture of the system, system modules, what information and how these modules will be exchanged
• Decide which external systems can be involved in business processes and how they will be integrated.

As you can see, even for Agile's development there is a place for design and planning. All taken decisions should be documented in the form of protocol description, interaction patterns and other schemes.

I have an experience communicating with a client, who didn’t understand how exactly the processes in his system were built. The document formulated by him on the basis of interview was 40% invalid towards the real processes. During software development process we have realized that some information is invalid and started to make changes to the newly created documentation …

Why has it happened? Because the previous team hasn’t documented any changes in approaches. They didn’t report it to the client or client just kept it in perspective.

That is why, all further taken decisions should be documented and all document versions should be updated. Besides, all the documents usually downloaded to shared network resource, where you can track changes in versions. You must either have access to such a resource or copies of such documents.

The key element: your agreement with a team will make all the difference of documentation quality and whether it will be at all. Very often, developers are limited with minimal documentability and it allows them to have more time for development. Changing the team you will have critical deficiency of system information. As a result, the new team will take a long time to learn the code and figuring out how it works. This will cause their working efficiency decrease and the budget increase for support.

To be continued. Next time we will speak about transferring project from one contractor to other.

• How to cooperate with “comers”? A piece of advice for a client :)
• A few words about choosing developers.
• Pricing methods & Project models.
• About transferring project.