Many times is thought that when starting a new start up project, we must be quick in gather the requirements, quick in development process, quick in test process… etc. We must devote specially attention and time to the requirement process. This step is the more important, and this step is decisive for the success or failure of the project.
I thought some fast tips for starting a new start up project:
Gather information about the customer company:
Objectives, services, products. Is a USP? (Unique Selling Proposition).
Define the targeted audience for the new application (age, social sector, etc).
Access to the application (devices, resolutions, etc)
What likes/dislikes of the other applications.
Define the limit for the plan project: final date, resources
This few points seem fast, but it is a round trip with the customer of many meetings before starting the new project. In each meeting the customer will define new features and flows, and the original idea will mutate.
Mutate a started application can be very difficult, or not viable, for that reason define this points before of start is the best way of avoid the failure.
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.
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 🙂
Articulate a developer workteam is not should a easy task. Again… in the start up projects all is fast and should be practice for get the final product to customer quickly.
First, we need choose a methodology for organize the work. All the team should know in details all process of work. The way most choosed usually is the Scrum. Why scrum? because es very easy of apply even the dumbest person can work with scrum methodology and not needed many roles. An simplified way of Scrum should be have:
A Product Manager: He has contact with the customer. Manage the available resources. Document their needs and guide to the workteam to the final product.
A Project Manager: Define the scope of the each iteration. Defines the roles and controls the process are complies as: documentation, responsabilities, delivery times, etc.
Testers: He test the quality of each element of the system. Defines the standard and the process of quality. He controls that each part complies with the correct programming methodologies.
Developer team: Generally, all does this. The mentioned roles, they haven’t much time for programming, but usually participate in the developer process.
A system of comunication is essential. Forums, internal messages system (chat), tracker system (fundamental) and a series of regular meetings. The meetings of team is particulary important, this allow to the all team analyzes, shares, talk about the problems or detours and take some decisions together. Any member of the team should can request a meeting for talk about contingences, new ideas or new challenges.
The motivation is the heart of the team. Many enterprises leaving aside this aspect, instead apply more control systems focusing the motivation in the member with the highest roles. But the point is that all the team must be motivated, with energy and especially considering what the customer wants.
This point has become the most sensitive for some development companies. They are dedicating considerable time and resources for obtain motivated teams. Is very common see games rooms, training events, special benefits, extensive and comfortable places of work with high technology in the development companies.
Personally, I think like any worker -in a ideal world- each member of the team must have a competitive salary, be heard and love what do.
In the market of the development of applications for start up business, the estimation of the projects is one of the most crucial tasks. It depends largely the success or failure of all the project. Detours, delays, incidentals and other external factors affect the development time and in the start up world there is not time for a complete planification of project.
However, it’s our duty devote time and effort required for find a way of standardize the estimation process. Why standardize? for reduce the effort whenever a new customer appears. The standardization processes allows invest the effort once.
There are many techniques for the estimation. But, I have some shortcuts for start up projects that usually consider:
Define some available resources:
Size of workteam.
Capacity of the members of team -each member of the team should have a different weighting of the time effort-. For this reason we have take a standard time unit, and weighting each member according to their abilities, e.g. 1 hour for Technical Leader = 1.4 hours for SSr. developer.
Divide the project in small tasks, as small as possible.
Add 5% for testing tasks. Each part must be tested and revised.
Add 2% for documentation of the most important elements.
Add 5% for planification and organization of the workteam (meetings, analysis of the system flow, etc).
Add 10% for contingency and possibles delays.
Once we have define this, we create a small guide for follow each time we have to estimate.