The creation of software products is a headache for many project managers. You need to correctly set the task for developers, know how to control them, and always be able to promptly make changes or “roll back” a release if a critical error is found in theproduct.
The composition of the team, the order and even the schedule of work depend on this. You can choose waterfall or agile model.
The team will work strictly according to the technical requirement. The result you get in the end will be exactly as you planned it in the beginning.
The team will be able to solve issues on the fly, adjust to the market and change requirements in the moment. The end result you get may be very different from what you expected.
If you need to quickly launch the MVP-version of the product and understand the direction to develop it – choose the agile model.
Deciding on the model you are going to use for the project makes it easier to understand who to hire for the team and how to delegate the tasks. Determine which specialists you need for the project. Keep the main expertise inside the company, and you may outsource it.
A classic development department consists of the following people:
- Project manager: controls the workflow, deadlines, optimizes the work of employees;
- Architect: defines the technology stack, designs the overall infrastructure of the project, its main components, modules and services;
- Frontend and backend developer/full-stack developer: the former are involved in the visual and computational part of the project, and the latter, as a universal soldier, have knowledge of different technologies;
- QA engineer: ensures the quality of the software product from the beginning of development to its final delivery;
- Team lead: decomposes and delegates tasks, conducts code reviews and maintains the team’s morale;
- Designer: defines the product’s appearance, interface and usability;
- Analyst: designs and optimizes processes, manages the implementation of new IT systems and adapts the work system to new tasks;
- System administrator: ensures uninterrupted server operation, configures developer sites and provides technical infrastructure.
Some of them are not necessary if the project is small – for example, an architect or an analyst. The main thing: get professionals you can rely on and who are able to make decisions on specific issues.
Interview users to identify their needs and get as realistic a prototype of the product as possible. Such research should be done “on shore”, before working on the project, so that the final product is viable and to make a product for the request, not the other way around.
Pay attention to the terms of reference. The terms of reference guarantee that you won’t waste your time, won’t overpay and get the desired result. In addition, it provides technical development of the product and will help:
- estimate the task in terms of budget, time and man-hours;
- simplify the handover-acceptance of the project;
- explain to the specialist how the project works and what documentation should be prepared “in the outputs”.
The system administrator is responsible for setting up the technical infrastructure. You don’t have to build a battlefield infrastructure right away – do the bare minimum to ensure the team has a place to work.
- a repository for the project’s code base;
- common tools for organizing the development process, if needed – for example, a free task manager (Jira, Redmine, Trello, etc.);
- work environment: the services and applications on which your product will depend (e.g. Swagger for API documentation).
Make sure that all team members have access to the development tools and working environment.
Construct a project schedule for the entire team to work on. Write out a timeline for each task and determine the final completion date for the project.
When scheduling, take into account shifts in deadlines (e.g., increased deadlines due to bug fixes) and think about how one task depends on the other.
For example, there is no point in developing an order placement until you have developed a shopping cart or catalog. The QA engineer won’t be able to verify the task until he/she puts the item in the cart. It’s better to delegate this task to one person to do the cart and then the checkout.
Delegating is the task of the team leader, who matches the complexity of the task to the level of specialists. He will not give a junior specialist tasks that are too tough for him, or provide the support that will allow him to do the tasks correctly.
Make sure that the developer understands the task correctly. Before the start, get the team together and talk through all the stages of the work: everyone needs to understand what the team as a whole is doing and what their role is in the process.
Throughout the development process, the team leader assists team members with complex technical issues and keeps the big picture of the project in focus. He takes it into account to make decisions about task sequencing and workforce allocation.
Keep deadlines in mind – for example, you can hold daily or weekly meetings with the team. This will help keep your finger on the pulse, keep track of project milestones, and resolve difficulties in a timely manner.
Testing each task improves the quality of the product and keeps you from a flawed release with bugs. Don’t forget about the code review – checking the code the developer has written. Usually the project team leader or one of the senior developers do the review. If there are any controversial points, involve the author of the code.
Before you put it out, do some commissioning work. This is the final stage of development before the launch: the product is prepared to work in a production environment, and the team configures the production infrastructure. Don’t forget about logging systems, backups, and other failure detection and remediation systems.
After that, the product is rolled out into the production environment, and it is finally tested by QA engineers.
Remember that no project is ever complete. Bugs are found even after the product is released. Keep an eye on it even after a successful release and fix defects in time.
Author: Jean Hartley is a professional content writer. She successfully works for a write my paper service and also manages remote projects. Jean has over 3 years of experience in an IT company.
If you like the content, we would appreciate your support by buying us a coffee. Thank you so much for your visit and support.