In software engineering become independent the people of the processes is not an easy task. Even more in  start up projects. We can know some methods and practices that we are likely to lead to success, but we are never entirely sure and that’s because every project and every workteam is a world in itself. However, we can always limit to the maximum the errors and failures following simple practices and processes that will help us not to trip over the same stones.

Why document?

One of the advantages of having trained leaders in the workteams is that we can count on your experience. They will remember cases and situations that led to the triumph of their teams and recognize those practices that led to fail. One of the problems is that in the development market and start up solutions, the workteams are disassembled and technologies and processes become obsolete quickly.
When a challenge arises or a new project appears, the first thing we do is look for documentation about it. Seems that there is always someone who has taken the trouble to share and document information. We have to document in detail our successes and to apply it despite the time, techonologies and workteams. We analyze and write what led us to a happy ending, or failure to learn from it. But also for others who continue to the project, or who entering the team to have everything needed to adapt and continue working -which means cost savings when it comes to bring in a new member-. It’s very common to see people coming and going every day in the development companies, and is more common to see companies lose the control of their projects by this constant employees flow.

When making decisions in a team, forms of work are chosen or agreements are made, is important to write and document a methodical way. All agreed and discussed at each meeting must be captured to take it as reference and guide for our daily work. Is very easy that the words are carried by the wind, and the responsible persons are hidden behind this fact. When the agreement is documented we have a record and evidence that sometimes it helps to keep the wheels on the road.
This documentation of agreements and meetings is also valid for customers, they also must be able to refer to everything discussed and agreed in an easy way and anytime.

How to document start up projects?

The customers want efficient and simple products, but mainly they want it fast and at low cost. Document takes time, therefore increases directly on the cost of the final product. Find the balance between a relatively detailed documentation and the time available to apply is one of the challenges of development of agile applications companies.

There are many methodologies to implement at low cost but in any case it requires a number of practices in the development process and a series of complaints from developers too :). In any case you will need:

• An initial documentation to clarify the proccesses of documentation of projects.
• A control process that ensures that all member of the teams follow the documentation process.
• A quick and easy way to write processes, meetings, agreements, technologies used, way to application and activities taking place.
• A tool easy to learn and does not require lot time of maintenance.

This is how a policy of documentation in your workteam will allow you the projects become independent to the people, learn from your mistakes and repeat your success.

Now, as always for closing I leave a new auditory adventure 🙂