The classic scheme of the department is as follows - people sit in the office (well, or as it is now at a remote location) for a time-based payment (8 hours a day) or in hourly bodyshops. Get to work within 30 - 120 minutes. A person is hired through hh or similar sites, the candidate goes through hr'a, technical security where they try to draw up a competency matrix. There are many candidates in Moscow with any level of knowledge, in the regions this is a problem.If there is no technical university nearby, but you want to run a business, go to the nearest millionaire and pay local salaries. The latter is especially unpleasant for a startup. It is good if on the project where the person was taken exists and there is documentation on solutions with a description of data flow schemes, etc., but I have never met this. There are scraps, chaotically kept notes, meeting minutes with reasons for decisions, but systematic development documentation is like a double eclipse of the moon. Why do you need documentation with diagrams and justifications? When an architect sketches a model for a future project, he is a bearer of unique knowledge that no one else has. This is a serious problem, if a specialist gets sick, dies, leaves, then his competencies will also go away with him.Restoring competencies without documentation and a knowledge carrier is such a non-trivial task that it is easier to rewrite everything anew (both are big money). Introducing a new fighter or an old one from another project into a project is six months of mentoring and distracting the attention of those already working. At the same time, the new unit is also of limited functionality by and large. The problem statement system can branch, split into subtasks, and merge back from unexpected places. The task may not pass through leads or architects, which adds trash and frenzy in attempts to expand the architecture or cram in the unstoppable.At the same time, the new unit is also of limited functionality by and large. The problem statement system can branch, split into subtasks, and merge back from unexpected places. The task may not pass through leads or architects, which adds trash and frenzy in attempts to expand the architecture or cram in the unstoppable.At the same time, the new unit is also of limited functionality by and large. The problem statement system can branch, split into subtasks, and merge back from unexpected places. The task may not pass through leads or architects, which adds trash and frenzy in attempts to expand the architecture or cram in the unstoppable.
Problems with the classic scheme
Human resources are limited in availability and are practically not amenable to operational change. Hence the problem of downtime and overtime.
It is not profitable to keep narrow specialists. Such specialists are a unique source of knowledge, but maintenance costs are high and tasks are rare. Hence the problem of downtime and stagnation in competencies.
People in teams specialize in current tasks and begin to degrade if they do not make an effort on themselves or are not forced to do so.
Finding a person with the necessary competencies is difficult or even impossible for the allocated money and time.
Lack of documentation describing the project for quick onboarding for a beginner.
The need for mentors.
The problem of expanding the functionality without a deep analysis of such a possibility, and such an analysis is possible only by the bearer of broad competencies in the project - an architect.
The problem of dropping out the holders of unique knowledge on the project.
The problem of the moral atmosphere in the team and personal relationships that influence the adoption of important decisions.
The problem of non-transparency of finances for the customer and performers on remuneration.
The problem of increasing the status of the performer and the type of tasks performed.
Is it possible to somehow level these problems without changing the development management paradigm (model)? The short answer is no! In the future, such a model will slow down the work, and with an increase in business and bureaucratization of processes, it can generally force the transfer of development to outsourcing. Is it a good thing to outsource development? - The short answer is yes, if it will speed up and facilitate product development! Can outsourcing be internal for the company? - Easy. And external? - it's harder here, right, security is all ... but possible! What about internal and external? - You can and here's how to do it.
The service is
- The communication system of the customer and performers.
- Provides dynamic connection of specialists with the required competencies.
- Carries out settlements with the customer and contractors.
- Promptly shows the project status and task progress.
- .
- .
- .
- .
- .
- . , , , .
- . . “, , , ” — . “ ” — , , , , . “” — , , , . “” — . “ ” — , , . “ ” — , , , .
- . . , . .
- . . , , .
Each of the higher-level roles forms a pool of decomposed subtasks for the lower-level ones, specifies the criteria for performing and the cost of completing the task. The superior role cannot directively assign an executor or assign itself to a subtask.
When decomposing a task, the lower-level role must receive confirmation of its solution from the higher-level role that set the original task.
The subordinate role, after receiving the problem, can send it for review to the director with justification of the errors or inaccuracies found, or open a dispute with arbitration and voting.
The superior role can take on any subordinate task if it is not its (task) director.
The completed task is in a special pool for review and approval. The task can be reviewed by the current role (but not by the performer) or one higher and lower.
For the completed and approved task, the performer is charged the payment specified in the task (minus the service commission for the transaction) and rating points.
For a completed review with a reasonable indication of an error or deviation from the review criteria, points are awarded, and they are written off from the reviewed person. Disputes based on the results of the review are resolved automatically by a general vote of the roles that participated in the review.
The transition to a superior role occurs automatically upon reaching a certain number of points for the performer. Thus, you can go through the entire hierarchy up to the manager without solving a single problem, but gaining points in the review of other people's problems.
Each task and task decomposition tree is accompanied by the creation of a set of documents justifying the choice of a solution and briefly describing it. Each task that is not a branch of an existing one, that is, expanding the functionality, should begin with approval from the manager and then go through approval by roles up to the final executor.
The task is automatically considered unfulfilled if it was taken into work, but the deadline has ended and no justification has been sent from the contractor to extend the deadline.
The uncompleted task is set back to the task pool for execution, and the executor is fined in the form of points write-off.
The set of a certain negative level of points leads to the automatic blocking of the performer for the selected competence.
The lack of completed tasks or reviews within a certain period of time leads to an automatic decrease in the overall score.
When the score drops below the threshold level of the role, the status of the performer is transferred to the lower role.
Scheme of order movement from customer to finished product
The customer starts a project in the service describing a business task (this is the primary information). Contributes to his account in the service the minimum amount of funds necessary for economic and marketing expertise, or if it already exists, then for the preparation of a technical task by the leader (development, architect). Economic expertise and technical justification includes expert opinions on the economic feasibility of this product. Economic feasibility is a study of analogs, demand, available resources, practical feasibility presented in the form of a document with recommendations. The task goes to the next stage when there are sufficient funds on the customer's account in the service. The customer can provide his expertise or TK (technical assignment, project architecture) for approval. If the agreement is not passed,then the task (project) cannot be taken into development. The customer can exit the service at any step or freeze it in the service for a fee. The customer has read access to all documentation and source codes for the project, to the assemblies of the application package or resources, to the progress of the project and tasks, pay sheets to performers.
Development is carried out in accordance with the rules established at the start of the project, this concerns the language of preparation of documents and descriptions, an agreement on the formatting of the code and self-documenting comments. The priority in writing classes and functions is given to the most simple and clean code. In every case, when possible, the code is covered by Unit tests. In development, there should be specialists who ensure the work of version control, automatic assembly, remote connection of performers to the necessary equipment on the side of the service or customer.
The introduction of performers into the service is possible after receiving the competency matrix. The competency matrix can be obtained in services specializing in testing in an automated mode. Accredited services provide an API with which you can get a matrix for an applicant. Depending on the results obtained, starting roles and competencies for which specialized tasks will be visible are set for the performer's account. To summarize, the performer registers with the service and receives a link to the competency testing service and passes them. The test results fill the competency matrix and the account is given the opportunity to take tasks, conduct a review, read the documentation available for its role.
It is recommended at the first stage to introduce into the service the executed executors on the existing base of the “office”. Check work with the customer in real projects. Carry out an advertising campaign in specialized communities and social networks with theses - “Complete transparency and honesty, no secrets. Work on what you want, where you want from and when you want. Nobody orders you. Earn as much as you can carry, no limits for everyone and forever. "
Issues requiring separate study
- Safety.
- Payment and settlements with the customer and contractors.
- Legal issues before contracts with the customer and piecework payments to performers, cross-border transfers.
- Copyright protection.