Integrated Workflow. Solving the problems of a growing IT company. Part 1
Hi, community!
I have not written materials for a long time, I read more and more strangers. But here, there was a free minute ( while the wedding photos from the CDs merge with the three iMacs, due to the lack of a drive in my beech :), and I decided to post material about our workflow. We are a young company Fruitware from sunny Moldova, and I myself combine the positions of commercial and executive director, although I am the most experienced, strangely enough, in web programming.
Our company has come a rather significant way, a year and a half long, from a “garage” studio of 5 people to a serious organization of 40.
I will tell you honestly - to increase by 8 times - this is not the most painless process, and we have been febrized more than once. But, learning more from our mistakes and a little bit on others, we built our work order, starting from technical equipment and up to project management.
')
Our main tool is Redmine with an installed CRM system. There we store projects and consolidate information about each in his wiki. There is a card for each client, and several for the organization. Each new order is fixed by a transaction for the sales funnel, and each payment is preceded by a generated invoice. We also use Redmine milestones to organize work on sprints, in tasks we set down the planned time and indicate the actual labor costs. The same data is used to verify the work of employees and payroll and bonuses.
We store all the code in GIT, we post it on our own dedicated server in Germany (Hertzner). For each of our developers a separate ftp account is open for logging any problems.
As for the GIT management interface - at the moment we are using gitosys with the n98-gitosis-admin interface, but we are looking in the direction of GitLab .
There are corporate standards for writing code, the corporate IDE (PHP Storm) and a set of practices for work.
In essence, this gives us normal work standardization, the ability to easily approach any developer and, on his computer or laptop as usual, make changes to the code, run code review, or help with debugging.
The most important thing in our process is the staff list with all the duties. It greatly helps in the work and in determining areas of responsibility.
The hierarchy is quite simple - at the top of the pyramid work: executive, commercial, technical and art director . Under the technical director is the development department, which include:
Each department has its own head - a person who combines a manager and a technical specialist.
In addition to the development department, we have an art and design department that works under the art director, a customer support and care department and a sales department that is headed by a commercial director.
The hierarchy seems to be sorted out, now let's move on to the most important - the process of working with the project.
Let's start with the fact that we are familiar with the new order and our task is to understand the customer’s problems and offer a solution in the field of advertising, design or it. To do this, a business director, art director, system analyst and account (he’s the manager) must be taken to meet or negotiate with the client. Together we form a commercial offer or vision of the project with a clear description of the problem, what the client expects from us and what we are ready to do for him. Based on this document, the heads of the relevant departments determine the scope of work, and form the budget. At this stage, the budget can be approximate or final (it all depends on the size of the projects and its X-factor).
Further, after receiving the principle consent, the project formulation is formed - a more complete description of the functional. On the basis of the statement, the cost is detailed and after receiving the advance payment, the most important thing begins - the writing of the TK. TK is written by the system analyst together with the head of the relevant department in order not to go beyond the budget.
Then two documents are drawn up according to the TOR - an estimate with a list of large tasks ( without time limits ) and a list of tasks with high details ( no more than 4 hours per task ).
The final implementers, the client account, the system analyst and the heads of the departments involved ( including QA ) meet and discuss the project so that everyone understands the tasks before them in the same way. After the meeting, both the estimate and the list of tasks are specified.
A sprint planning stand-up is being held - here only the executives, the manager, team leader or his department head replacing him and, if necessary, a system analyst. Then in Redmine the milestone is set for the first sprint, the final verifiable readiness indicators of the first version are determined, they are described in the wiki milestones, tasks from the list are added to the Redmine and assigned to specific performers with an estimated deadline.
Then everything is familiar in many familiar scenarios - day stand-ups up to 15 minutes - what did you do yesterday, what are you planning to do today, what problems have arisen.
Sprint ends with a stand-up with a review of what was done, showing the manager of the resulting product. The head of the department before this meeting makes a mandatory code review. Then, if necessary, a retrospective look at the sprint and discussion of the problems that have arisen.
After the first sprint, everything repeats until the project is fully prepared. If necessary, intermediate results are shown to the client.
Of course, I want to introduce a lot more, without making the process for the final performers more difficult. In the near future:
And much more.
Thank you for your attention, I will be glad to answer your questions.
PS “Why Part 1?”, You may ask. Because if the article causes a positive reaction, then I will open the maps - I will share the staff schedule, tell you about the setting of the redmine, give PHPStorm configs and much more.
I have not written materials for a long time, I read more and more strangers. But here, there was a free minute ( while the wedding photos from the CDs merge with the three iMacs, due to the lack of a drive in my beech :), and I decided to post material about our workflow. We are a young company Fruitware from sunny Moldova, and I myself combine the positions of commercial and executive director, although I am the most experienced, strangely enough, in web programming.
Our company has come a rather significant way, a year and a half long, from a “garage” studio of 5 people to a serious organization of 40.
I will tell you honestly - to increase by 8 times - this is not the most painless process, and we have been febrized more than once. But, learning more from our mistakes and a little bit on others, we built our work order, starting from technical equipment and up to project management.
Redmine
')
Our main tool is Redmine with an installed CRM system. There we store projects and consolidate information about each in his wiki. There is a card for each client, and several for the organization. Each new order is fixed by a transaction for the sales funnel, and each payment is preceded by a generated invoice. We also use Redmine milestones to organize work on sprints, in tasks we set down the planned time and indicate the actual labor costs. The same data is used to verify the work of employees and payroll and bonuses.
Git
We store all the code in GIT, we post it on our own dedicated server in Germany (Hertzner). For each of our developers a separate ftp account is open for logging any problems.
As for the GIT management interface - at the moment we are using gitosys with the n98-gitosis-admin interface, but we are looking in the direction of GitLab .
IDE and standards
There are corporate standards for writing code, the corporate IDE (PHP Storm) and a set of practices for work.
In essence, this gives us normal work standardization, the ability to easily approach any developer and, on his computer or laptop as usual, make changes to the code, run code review, or help with debugging.
Staff list
The most important thing in our process is the staff list with all the duties. It greatly helps in the work and in determining areas of responsibility.
The hierarchy is quite simple - at the top of the pyramid work: executive, commercial, technical and art director . Under the technical director is the development department, which include:
- web development department
- front end development department
- quality assurance department
- mobile development department
- research and development department
Each department has its own head - a person who combines a manager and a technical specialist.
In addition to the development department, we have an art and design department that works under the art director, a customer support and care department and a sales department that is headed by a commercial director.
The working process
The hierarchy seems to be sorted out, now let's move on to the most important - the process of working with the project.
Let's start with the fact that we are familiar with the new order and our task is to understand the customer’s problems and offer a solution in the field of advertising, design or it. To do this, a business director, art director, system analyst and account (he’s the manager) must be taken to meet or negotiate with the client. Together we form a commercial offer or vision of the project with a clear description of the problem, what the client expects from us and what we are ready to do for him. Based on this document, the heads of the relevant departments determine the scope of work, and form the budget. At this stage, the budget can be approximate or final (it all depends on the size of the projects and its X-factor).
Further, after receiving the principle consent, the project formulation is formed - a more complete description of the functional. On the basis of the statement, the cost is detailed and after receiving the advance payment, the most important thing begins - the writing of the TK. TK is written by the system analyst together with the head of the relevant department in order not to go beyond the budget.
Then two documents are drawn up according to the TOR - an estimate with a list of large tasks ( without time limits ) and a list of tasks with high details ( no more than 4 hours per task ).
The final implementers, the client account, the system analyst and the heads of the departments involved ( including QA ) meet and discuss the project so that everyone understands the tasks before them in the same way. After the meeting, both the estimate and the list of tasks are specified.
A sprint planning stand-up is being held - here only the executives, the manager, team leader or his department head replacing him and, if necessary, a system analyst. Then in Redmine the milestone is set for the first sprint, the final verifiable readiness indicators of the first version are determined, they are described in the wiki milestones, tasks from the list are added to the Redmine and assigned to specific performers with an estimated deadline.
Then everything is familiar in many familiar scenarios - day stand-ups up to 15 minutes - what did you do yesterday, what are you planning to do today, what problems have arisen.
Sprint ends with a stand-up with a review of what was done, showing the manager of the resulting product. The head of the department before this meeting makes a mandatory code review. Then, if necessary, a retrospective look at the sprint and discussion of the problems that have arisen.
After the first sprint, everything repeats until the project is fully prepared. If necessary, intermediate results are shown to the client.
Benefits
- We solve the problem of control of the project - a possible failure of the terms - 1 day, the maximum - one stage. And the notification is the earliest.
- All information is stored in one place - redmine. There is always the opportunity to quickly penetrate into someone else's project or track its status without plunging.
- All files are versioned, the danger of overwriting each other's work or losing any edits tends to zero. Separate FTP access allows you to see who uploaded incorrect files to dev.
- A powerful server allows you to work with many projects simultaneously.
- Unified development tools make it easy to help someone else, work in pairs or conduct code-review.
- Clear areas of responsibility allow you to localize the problem, find the one who made the mistake (and not the switchman) and prevent its recurrence.
- The development process is transparent for managers and, if necessary, may become transparent for the client.
Future
Of course, I want to introduce a lot more, without making the process for the final performers more difficult. In the near future:
- Implementation of automatic deployment on virgins (capitalist or factories)
- Automating the process of creating a new project - from creating a repository for the project in redmine to closing tasks through commits in gita.
- The introduction of detailed analytics with automatic calculation of the coefficients of the effectiveness of a particular employee and the economic efficiency of a particular project.
And much more.
Thank you for your attention, I will be glad to answer your questions.
PS “Why Part 1?”, You may ask. Because if the article causes a positive reaction, then I will open the maps - I will share the staff schedule, tell you about the setting of the redmine, give PHPStorm configs and much more.
Source: https://habr.com/ru/post/201318/
All Articles