I'm technilid What to do?
For more than a year I have been occupying the position of technical leader in my company, and I want to share my work on the topic It makes sense to clarify: I am a 10-person iOS development department at an outsourcer company. In my case, the position implies the optimization of the work of the department, the distribution of tasks between developers and activities related to programming. I'll tell you a little about my experience, best practices and conclusions. The article may be useful primarily to newcomers to a similar position, or to those who are aiming at it. Some practices and principles may be portable to conventional development, to other platforms, or even other specialties.
To understand what exactly I have to do, it makes sense to start with a list of responsibilities. They include:
Here are the main responsibilities; some activities specific to our company have been omitted. Most developers perform a standard set of activities and have a good understanding of them, so I want to focus on the department.
What can it basically be? Obviously, in improving the speed and quality of standard tasks. It would seem that either one or the other is usually the case, but here it is important to build up experience - the company implements a large number of projects, the same tasks are solved in the course of work, and over time you can identify the most successful and logical solutions and teach the department how to use them. This is the global idea of ​​optimization.
')
Let's go over the means that allow it to a certain extent to realize.
Standard activities can and should be documented. Recorded information is better remembered for many reasons:
It makes sense to document everything that is executed repeatedly. These can be guidelines for code, the procedure for making assessments or interviewing, rules for working with repositories or a bug tracker - anything that needs to be done all the time and which new people have to train again and again.
The most difficult task is to teach people to use documentation. First of all, you need to convey to all that information is available. It is necessary to refer to it, instead of retelling yourself.
It is extremely important to keep the documentation up to date, as otherwise working on it will simply be a waste of time. This will not be useful, since there will be no confidence in irrelevant sources of information, they will not be used again, and time will be wasted. In an ideal world, the entire department should participate in the development of general documentation - then everyone will understand what kind of documentation is there, where to look for it, how to share it, and the information itself will be relevant.
I do not urge to plant bureaucracy and cover every small movement with instructions, since it is ineffective. But it makes sense to identify the most basic things, fix them and start communicating to people.
In the case of mobile outsourcing, we have relatively small projects in terms of size and lifespan, on which most of the functionality is similar, or even repeats. In this case, you can create a base of code that is portable between projects. These can be standard utilitarian functions, some controls, separate layers or something else.
If the department has its own history, there, in any case, there are already some developments that are transferred between projects simply as separate files. This option is simpler, but the code is being finalized for the needs of one project, and if reused, its refinement may vary. Allocating the portable functionality to separate repositories makes it possible to more productively develop and stabilize solutions. The use of dependency managers further reduces reuse time, although it increases support time and introduces its limitations.
If there is no code base initially, it may be unusual and inconvenient for developers to make decisions in separate repositories, because “why should I strain myself if it works anyway”? It may be necessary for someone to explain that strategically from the point of view of the company's work, this will be better. Over time, the process becomes a habit, does not create problems and does not cause misunderstanding, because it is taken for granted.
Some standard activities are automated. This simplifies routine actions, speeds up work, reduces the human factor, and sometimes brings opportunities that are not practically realizable in manual mode.
The standard example: automating the build process greatly (sometimes almost to zero) reduces the cost of preparing builds and introduces static analysis or testing into the process (I mean, you can disable assembly without successful static analysis).
Another example: remembering the specifics of the department, we can say that automation gives in to the procedure for starting a project. In our department, we use a template that can generate the initial contents of the repository with the project structure configured for all guidelines, as well as with customized git and continuous integration. Its application greatly simplifies and accelerates the start of new projects.
In general, the simplest case of automation can be considered the creation of various templates for documents, code or anything else.
During development, time is often lost for immersion in projects, since they can be arranged differently, and the same tasks can be solved from time to time in a new way for no apparent reason. Starting on a new project, where everything is once again done in its own way, the developer will spend some time studying the toolkit. If he has more than a dozen projects behind him, there will be no difference - he will already have an idea about how standard tasks can be solved. If there is no extensive experience, time will be wasted. Here you can save by bringing the development to a single form.
To achieve the uniformity of projects, everything that is already listed is applicable: general rules, a base for solving typical problems, automation. Using them, you can make projects to a certain extent similar and understandable to new developers.
It is not worth while unduly zealous - projects do not have to be as similar as two drops of water. Experiments with tools and architecture are important both for thefun of gaining experience and for researching potential innovations. It makes sense to systematically experiment, starting from a single base.
In the ideal picture of the world, you need to monitor whether this or that decision will justify itself. Having crossed a certain threshold, the cost of supporting it may exceed the benefit. The best and only objective indicator here is time. If it is possible at least occasionally to look at the cuts of the cost of supporting the entire set used, for example, by month, this may help to better orient. I, unfortunately, do not have enough time, and I have to determine everything by sight. In addition, some potentially inefficient solutions sometimes become realistic to contain, thanks to suddenly released developers. The real development in this regard may differ from the logical theoretical one.
Increasing the number of tools used and the volume of documentation may make it too difficult to support all developments or even their use. For example, forgetting about one of the 50 rules is much easier than about one of the 5. Finding a balance between functionality and complexity from this point of view is not the most trivial task. I can not say that I could find this balance and ensure the use of developments in full.
I spent a large amount of time creating a developer training system. Having built a high-quality training system, you can solve several problems at once:
At the moment, the system has the form:
Thus, the developers are continuously in the process of growth, and the system is designed to first close the potential holes in knowledge, and then train to solve typical problems, that is, it is based solely on the material used continuously.
Steps include instructions for performing various activities (writing code, project launches, evaluation), and as the steps close, developers will receive appropriate tolerances.
Training begins with an introductory step, which contains code guidelines, instructions for working with the version control system and bug tracker, as well as the very basics of programming. Having come to the company, developers are allowed on projects, having already reported on the knowledge of how we work, and the minimum set of skills, as well as completing a test project and passing a corresponding review in the process, that is, having a complete understanding of the work process.
Developer training is a long process, even within a single system, so a lot of time is needed to study the material and the form of its adoption. The matter is complicated by the fact that the study of information lasts for weeks and months, so it is impossible to quickly form and test the division of material into stages. Adoption of the steps also occurs relatively rarely, which requires maximum attention - you must first use each passing procedure to obtain information about the convenience of the system.
The structure of our company is implemented in such a way that the technical leader does not control the distribution of developers. Participation in the formation of teams has a consultative view: who is better to whom with whom to put, whether this or that team will pull the project, etc.
My responsibility is only to ensure the implementation of tasks that are not related to active projects. If there are relatively free people, they can be given an assessment of the complexity of the applications for sale or, for example, urgent tasks on formally suspended projects, where there is no one to perform them, or the internal activities of the department or something else. If there are no free resources, you need to do everything yourself.
The transfer of tasks is both simple and complex - you need to check who is free at the moment, personally speaking to the developers and project managers. I have not yet managed to come up with anything more effective than ordinary dialogue, even though the instinct suggests that there should be some opportunity to make it easier and more transparent. The only thing that was possible to come up with to simplify communication is a general chat for developers. Sometimes, writing there, you can find out that someone is suddenly free and can do the necessary work.
The process of delegating tasks and monitoring performance is not the easiest area, and I managed to master only its very basics, so there will not be any revelations here. All tasks have a degree of transferability - how effective and safe can its delegation be. You can always give away some simple task that will be difficult to make so that it spoils something. It is always better to be prepared for the worst scenarios, although it all depends on the level of the performer. If the level of the developer is high and there is trust, you can transfer large and complex tasks or even form a common vision on a particular issue. Requirements for the performance of the transmitted task should always be indicated as accurately as possible in order to eliminate elementary errors and reduce the possibility of incorrect interpretation. Also, do not forget about checking the results.
It is clear that as the department grows, it is necessary to expand the structure in which the duties will be further distributed on an ongoing basis, or to divide one whole department into several smaller ones but in my practice this has not reached.
If you take a look at the above and imagine how much time is needed for each of these activities, it becomes clear that the position implies a lot of tasks. This is not a developer’s everyday life, when you have one or two on a normal day, a maximum of five activities of the same type. My standard day includes 5-10, and sometimes 15 tasks, and their type can vary greatly. The brain works in completely different ways when you have to fix a complex bug, learn a new technology, or create, plan, and prioritize tasks. Since most of the time I am not tied to one project, but do several at once, it is necessary every day to quickly load into the head and unload large volumes of diverse information.
Since, by nature, my brain does not have outstanding parameters and by itself does not pull such a load, we have to help it. I am sure that in these smart books on time management, all these practices have already been invented, but I did not devote enough time to study them, since my priority was and still is development in the direction of programming.
Worst of all, in my case, memory is coping, so part of the practice is aimed at replacing brain memory with third-party tools and habits. The second group involves the involvement of other people to carry out activities. Let's start with the last one and move on imperceptibly to the first one.
Delegation About him already said a little. With a shortage of time, you should try to transfer the work to others to the maximum.
Attracting developers at the cultural level . If you form good habits at the department, some activities can be performed even without the knowledge of the technical leader. For example, errors in portable code can be corrected by developers as part of the normal execution of tasks on projects.
Checklists . In order not to forget about the order of actions, you can make lists of them: on a normal working day, on the execution of a particular activity, on a separate task, or on the occasion of a specific event (for example, updating any tool). Over time, the need for checklists disappears, so their compliance is a habit, but at first they can be very useful.
Reminders . When I perform a task, I try to keep myself reminders for every little thing in case I get distracted or forget something in the course of work. It can be “TODO” in the code, notes in a separate document or on a piece of paper. It is necessary to insure to the maximum from the fact that in the process of work something will be forgotten and not completed.
Discipline . You need to complete the tasks in full so that you don’t need to remember them anymore. Statuses in the project management system need to be set in a timely manner, time must be written off immediately after completing work on a task, because after completing a dozen different tasks and having exhausted brain resources, it is easy to forget what you have done today. And if there were a lot of tasks, and they were small, it’s easy to forget about them at all, and then it turns out that working time seemed to have gone nowhere. If the tasks are performed immediately to the full, in your pool of parallel activities there will be far fewer of them than they would be if you had to repeatedly return to the already performed ones.
Communication failure . A lot of responsibilities involve a lot of communication. You can respond to letters and messages in messengers by ending the current activity. The most powerful communication is personal, and it is hardest to queue. When people approach me during the execution of a task, I often have to tell them that I am busy and cannot talk. Otherwise, the context of thoughts will be constantly lost, and after the conversation you will have to remember everything anew. With a certain number of communications, if they are not denied, the performance when performing complex and voluminous tasks will subside, sometimes to almost zero. Expanding a person who approached you personally may not be easy, but with a large number of tasks this is necessary.
In my opinion, the most important tool worthy of a separate item. If you can't keep all your tasks in your head, you need to keep a record of them. It requires something more free than a bug tracker. I use a simple text document.
When a new task arrives, it is simply added to the list so that the order of priorities is preserved, depending on priorities. When the active task ends, I return to the list, select the most priority item and take on it. So time is not wasted searching for tasks.
If necessary, you can estimate how long it will take for each activity in the list and indicate the time frame for their implementation. Such estimates, however, are not always correct, since the tasks arrive in a random order, and it is not known in advance when and how many more of them will appear. However, this can also be fought by laying a certain time a day for a sudden busyness and giving pessimistic estimates.
In a separate section of the list, I have selected items relating to the verification of the performance of the transferred activities. If the task is performed by another person, it is necessary to periodically check the status, otherwise it may just get lost, since very few developers take care not to forget anything.
For some, keeping a simple to-do list may look like a “bicycle”, but this is a simple and real work practice that helps save time and not forget about tasks. At the very least, radically reduce the number of forgotten ones.
It seems to have described what I do and how to cope with all this. You can add a little lyrics about your own feelings from work. Perhaps this will help someone decide whether to do it.
The result is not tangible . If I do projects, then it is more related to the start, and as a result, other people make it. Developer training is not directly traceable. To understand whether a particular solution works, you need to perform the same tasks with it and without it, remove the statistics on the costs of its development and support, and draw conclusions. There is no time for such an audit in our conditions. As a result, it is impossible to track how correct or incorrect my actions are. To present the results of my work in a pure form, respectively, is also impossible. It does not add morality.
Projects are impersonal . When a developer makes at least one full-fledged release of an application, he begins to get a good idea of ​​his behavior. When it comes to just starting an application, reviewing or fixing several complex bugs, it’s impossible to remember projects. Even technologies seem the same everywhere.
Simple tasks are given to developers . Tackling simple things is extremely rare. I really like to do a simple layout of standard screens and adjust pixels and colors, fight with UIKit problems, but lately most of the tasks relate to building application architecture.
Short memory deteriorated . Digesting large amounts of information initially overwhelmed the brain. I began to unload it, and this led to the fact that he basically lost the habit of remembering what is not recorded. Perhaps this is true only for my case.
Changing the context of work has become easier . As it turned out, this moment is amenable to training. The brain is used to constantly switching between tasks and coping with them much easier and faster.
Strange projects / technologies / approaches are easier . Being engaged in individual projects, the developer is limited by them. When you see the same things, embodied in many different forms on different projects, it becomes much easier to ignore the details and understand the general principles.
You can see how the company works . With regard to several projects and all developers at once, you can understand how the entire department and related departments work. This vision sometimes allows you to give the correct answers to non-standard questions about which order of actions will be the easiest for everyone in the sum, to which this or that decision belongs, etc.
You need to set tasks yourself . When you complete a project as a developer, you complete a set of tasks prepared by someone else. In the management of the department there is no TK or skopa works. A department is a project in itself, and I’m both a developer, a project manager, and a product owner. Decisions about what tasks you need to perform - on me.
Need to teach people . Often the same. Sometimes several times. The role of the technical leader is, in fact, necessary for this. If there are developers in the company who can learn from him (we have such, fortunately), this is very cool, and it makes sense to treat them with great attention.
Transferred tasks are rarely completed . Somewhere this is due to mistakes, haste, inattention, somewhere lack of understanding of the common vision, somewhere taste. For the most part, you have to give additional instructions and send tasks for revision, and in the conditions of burning deadlines, you can refine your work completely. I try to make sure that this does not become the “bottleneck” of the process.
The article turned out to be voluminous. I hope she will clarify something to someone. Perhaps someone will add to their practice something from these developments or extract something else for themselves. Naturally, in each company and each department the role of a technical leader will look different, but I have highlighted the aspects that are currently seen as the most significant in my conditions. Thank.
Duties
To understand what exactly I have to do, it makes sense to start with a list of responsibilities. They include:
- Responsibilities of the developer:
- Code writing, refactoring
- Code Review
- Consultation of specialists of other departments on the technical part
- Evaluation of the complexity of projects and individual tasks
- Participation in hiring
- Optimization of the department:
- Increase technical skills of developers
- Determining the order of performance of standard activities
- Working hours ready-made solutions
- Introduction of new employees to the department
- Utilization of developer downtime
- Distribution of tasks:
- Tasks on projects requiring temporary intervention
- Tasks within the department
- Evaluation of projects for sale
- Management consulting on the distribution of developers between projects
Here are the main responsibilities; some activities specific to our company have been omitted. Most developers perform a standard set of activities and have a good understanding of them, so I want to focus on the department.
Optimization of the work of the department
What can it basically be? Obviously, in improving the speed and quality of standard tasks. It would seem that either one or the other is usually the case, but here it is important to build up experience - the company implements a large number of projects, the same tasks are solved in the course of work, and over time you can identify the most successful and logical solutions and teach the department how to use them. This is the global idea of ​​optimization.
')
Let's go over the means that allow it to a certain extent to realize.
Documenting
Standard activities can and should be documented. Recorded information is better remembered for many reasons:
- It is presented in the same form for all.
- Her presentation will always be complete and correct, without a “damaged phone”
- Her study spends time only studying
- It is not lost due to poor memory, or when certain people are unavailable.
- She can always be refreshed.
- It does not get out of sync when changing
- In the process of fixing and refining, all important aspects are thought out in detail.
- Actions within instructions may be subject to automation.
- ... can continue
It makes sense to document everything that is executed repeatedly. These can be guidelines for code, the procedure for making assessments or interviewing, rules for working with repositories or a bug tracker - anything that needs to be done all the time and which new people have to train again and again.
The most difficult task is to teach people to use documentation. First of all, you need to convey to all that information is available. It is necessary to refer to it, instead of retelling yourself.
It is extremely important to keep the documentation up to date, as otherwise working on it will simply be a waste of time. This will not be useful, since there will be no confidence in irrelevant sources of information, they will not be used again, and time will be wasted. In an ideal world, the entire department should participate in the development of general documentation - then everyone will understand what kind of documentation is there, where to look for it, how to share it, and the information itself will be relevant.
I do not urge to plant bureaucracy and cover every small movement with instructions, since it is ineffective. But it makes sense to identify the most basic things, fix them and start communicating to people.
Portable code
In the case of mobile outsourcing, we have relatively small projects in terms of size and lifespan, on which most of the functionality is similar, or even repeats. In this case, you can create a base of code that is portable between projects. These can be standard utilitarian functions, some controls, separate layers or something else.
If the department has its own history, there, in any case, there are already some developments that are transferred between projects simply as separate files. This option is simpler, but the code is being finalized for the needs of one project, and if reused, its refinement may vary. Allocating the portable functionality to separate repositories makes it possible to more productively develop and stabilize solutions. The use of dependency managers further reduces reuse time, although it increases support time and introduces its limitations.
If there is no code base initially, it may be unusual and inconvenient for developers to make decisions in separate repositories, because “why should I strain myself if it works anyway”? It may be necessary for someone to explain that strategically from the point of view of the company's work, this will be better. Over time, the process becomes a habit, does not create problems and does not cause misunderstanding, because it is taken for granted.
Automation
Some standard activities are automated. This simplifies routine actions, speeds up work, reduces the human factor, and sometimes brings opportunities that are not practically realizable in manual mode.
The standard example: automating the build process greatly (sometimes almost to zero) reduces the cost of preparing builds and introduces static analysis or testing into the process (I mean, you can disable assembly without successful static analysis).
Another example: remembering the specifics of the department, we can say that automation gives in to the procedure for starting a project. In our department, we use a template that can generate the initial contents of the repository with the project structure configured for all guidelines, as well as with customized git and continuous integration. Its application greatly simplifies and accelerates the start of new projects.
In general, the simplest case of automation can be considered the creation of various templates for documents, code or anything else.
Uniformity
During development, time is often lost for immersion in projects, since they can be arranged differently, and the same tasks can be solved from time to time in a new way for no apparent reason. Starting on a new project, where everything is once again done in its own way, the developer will spend some time studying the toolkit. If he has more than a dozen projects behind him, there will be no difference - he will already have an idea about how standard tasks can be solved. If there is no extensive experience, time will be wasted. Here you can save by bringing the development to a single form.
To achieve the uniformity of projects, everything that is already listed is applicable: general rules, a base for solving typical problems, automation. Using them, you can make projects to a certain extent similar and understandable to new developers.
It is not worth while unduly zealous - projects do not have to be as similar as two drops of water. Experiments with tools and architecture are important both for the
Efficiency of decisions
In the ideal picture of the world, you need to monitor whether this or that decision will justify itself. Having crossed a certain threshold, the cost of supporting it may exceed the benefit. The best and only objective indicator here is time. If it is possible at least occasionally to look at the cuts of the cost of supporting the entire set used, for example, by month, this may help to better orient. I, unfortunately, do not have enough time, and I have to determine everything by sight. In addition, some potentially inefficient solutions sometimes become realistic to contain, thanks to suddenly released developers. The real development in this regard may differ from the logical theoretical one.
Increasing the number of tools used and the volume of documentation may make it too difficult to support all developments or even their use. For example, forgetting about one of the 50 rules is much easier than about one of the 5. Finding a balance between functionality and complexity from this point of view is not the most trivial task. I can not say that I could find this balance and ensure the use of developments in full.
Training
I spent a large amount of time creating a developer training system. Having built a high-quality training system, you can solve several problems at once:
- Increase technical skills of developers
- Reporting information on the availability of instructions and ready-made solutions
- Providing tolerances for sample activities
- Direction of growth of developers in the right direction
- Rational use of downtime
At the moment, the system has the form:
- More than a dozen steps, from the very basics to hardcore
- The total amount of information about a couple of years of study
- Steps include test items, instructions and theoretical part.
- The step is accepted in two stages:
- Execution of test tasks with code review
- Interview on instructions and theoretical part
- The steps are taken almost continuously, the minimum interval between interviews is one week.
- System tolerances are tied to activities.
Thus, the developers are continuously in the process of growth, and the system is designed to first close the potential holes in knowledge, and then train to solve typical problems, that is, it is based solely on the material used continuously.
Steps include instructions for performing various activities (writing code, project launches, evaluation), and as the steps close, developers will receive appropriate tolerances.
Training begins with an introductory step, which contains code guidelines, instructions for working with the version control system and bug tracker, as well as the very basics of programming. Having come to the company, developers are allowed on projects, having already reported on the knowledge of how we work, and the minimum set of skills, as well as completing a test project and passing a corresponding review in the process, that is, having a complete understanding of the work process.
Developer training is a long process, even within a single system, so a lot of time is needed to study the material and the form of its adoption. The matter is complicated by the fact that the study of information lasts for weeks and months, so it is impossible to quickly form and test the division of material into stages. Adoption of the steps also occurs relatively rarely, which requires maximum attention - you must first use each passing procedure to obtain information about the convenience of the system.
Distribution of tasks
The structure of our company is implemented in such a way that the technical leader does not control the distribution of developers. Participation in the formation of teams has a consultative view: who is better to whom with whom to put, whether this or that team will pull the project, etc.
My responsibility is only to ensure the implementation of tasks that are not related to active projects. If there are relatively free people, they can be given an assessment of the complexity of the applications for sale or, for example, urgent tasks on formally suspended projects, where there is no one to perform them, or the internal activities of the department or something else. If there are no free resources, you need to do everything yourself.
The transfer of tasks is both simple and complex - you need to check who is free at the moment, personally speaking to the developers and project managers. I have not yet managed to come up with anything more effective than ordinary dialogue, even though the instinct suggests that there should be some opportunity to make it easier and more transparent. The only thing that was possible to come up with to simplify communication is a general chat for developers. Sometimes, writing there, you can find out that someone is suddenly free and can do the necessary work.
The process of delegating tasks and monitoring performance is not the easiest area, and I managed to master only its very basics, so there will not be any revelations here. All tasks have a degree of transferability - how effective and safe can its delegation be. You can always give away some simple task that will be difficult to make so that it spoils something. It is always better to be prepared for the worst scenarios, although it all depends on the level of the performer. If the level of the developer is high and there is trust, you can transfer large and complex tasks or even form a common vision on a particular issue. Requirements for the performance of the transmitted task should always be indicated as accurately as possible in order to eliminate elementary errors and reduce the possibility of incorrect interpretation. Also, do not forget about checking the results.
It is clear that as the department grows, it is necessary to expand the structure in which the duties will be further distributed on an ongoing basis, or to divide one whole department into several smaller ones but in my practice this has not reached.
How to master it all
If you take a look at the above and imagine how much time is needed for each of these activities, it becomes clear that the position implies a lot of tasks. This is not a developer’s everyday life, when you have one or two on a normal day, a maximum of five activities of the same type. My standard day includes 5-10, and sometimes 15 tasks, and their type can vary greatly. The brain works in completely different ways when you have to fix a complex bug, learn a new technology, or create, plan, and prioritize tasks. Since most of the time I am not tied to one project, but do several at once, it is necessary every day to quickly load into the head and unload large volumes of diverse information.
Since, by nature, my brain does not have outstanding parameters and by itself does not pull such a load, we have to help it. I am sure that in these smart books on time management, all these practices have already been invented, but I did not devote enough time to study them, since my priority was and still is development in the direction of programming.
Worst of all, in my case, memory is coping, so part of the practice is aimed at replacing brain memory with third-party tools and habits. The second group involves the involvement of other people to carry out activities. Let's start with the last one and move on imperceptibly to the first one.
Delegation About him already said a little. With a shortage of time, you should try to transfer the work to others to the maximum.
Attracting developers at the cultural level . If you form good habits at the department, some activities can be performed even without the knowledge of the technical leader. For example, errors in portable code can be corrected by developers as part of the normal execution of tasks on projects.
Checklists . In order not to forget about the order of actions, you can make lists of them: on a normal working day, on the execution of a particular activity, on a separate task, or on the occasion of a specific event (for example, updating any tool). Over time, the need for checklists disappears, so their compliance is a habit, but at first they can be very useful.
Reminders . When I perform a task, I try to keep myself reminders for every little thing in case I get distracted or forget something in the course of work. It can be “TODO” in the code, notes in a separate document or on a piece of paper. It is necessary to insure to the maximum from the fact that in the process of work something will be forgotten and not completed.
Discipline . You need to complete the tasks in full so that you don’t need to remember them anymore. Statuses in the project management system need to be set in a timely manner, time must be written off immediately after completing work on a task, because after completing a dozen different tasks and having exhausted brain resources, it is easy to forget what you have done today. And if there were a lot of tasks, and they were small, it’s easy to forget about them at all, and then it turns out that working time seemed to have gone nowhere. If the tasks are performed immediately to the full, in your pool of parallel activities there will be far fewer of them than they would be if you had to repeatedly return to the already performed ones.
Communication failure . A lot of responsibilities involve a lot of communication. You can respond to letters and messages in messengers by ending the current activity. The most powerful communication is personal, and it is hardest to queue. When people approach me during the execution of a task, I often have to tell them that I am busy and cannot talk. Otherwise, the context of thoughts will be constantly lost, and after the conversation you will have to remember everything anew. With a certain number of communications, if they are not denied, the performance when performing complex and voluminous tasks will subside, sometimes to almost zero. Expanding a person who approached you personally may not be easy, but with a large number of tasks this is necessary.
Task list
In my opinion, the most important tool worthy of a separate item. If you can't keep all your tasks in your head, you need to keep a record of them. It requires something more free than a bug tracker. I use a simple text document.
When a new task arrives, it is simply added to the list so that the order of priorities is preserved, depending on priorities. When the active task ends, I return to the list, select the most priority item and take on it. So time is not wasted searching for tasks.
If necessary, you can estimate how long it will take for each activity in the list and indicate the time frame for their implementation. Such estimates, however, are not always correct, since the tasks arrive in a random order, and it is not known in advance when and how many more of them will appear. However, this can also be fought by laying a certain time a day for a sudden busyness and giving pessimistic estimates.
In a separate section of the list, I have selected items relating to the verification of the performance of the transferred activities. If the task is performed by another person, it is necessary to periodically check the status, otherwise it may just get lost, since very few developers take care not to forget anything.
For some, keeping a simple to-do list may look like a “bicycle”, but this is a simple and real work practice that helps save time and not forget about tasks. At the very least, radically reduce the number of forgotten ones.
Sensations
It seems to have described what I do and how to cope with all this. You can add a little lyrics about your own feelings from work. Perhaps this will help someone decide whether to do it.
The result is not tangible . If I do projects, then it is more related to the start, and as a result, other people make it. Developer training is not directly traceable. To understand whether a particular solution works, you need to perform the same tasks with it and without it, remove the statistics on the costs of its development and support, and draw conclusions. There is no time for such an audit in our conditions. As a result, it is impossible to track how correct or incorrect my actions are. To present the results of my work in a pure form, respectively, is also impossible. It does not add morality.
Projects are impersonal . When a developer makes at least one full-fledged release of an application, he begins to get a good idea of ​​his behavior. When it comes to just starting an application, reviewing or fixing several complex bugs, it’s impossible to remember projects. Even technologies seem the same everywhere.
Simple tasks are given to developers . Tackling simple things is extremely rare. I really like to do a simple layout of standard screens and adjust pixels and colors, fight with UIKit problems, but lately most of the tasks relate to building application architecture.
Short memory deteriorated . Digesting large amounts of information initially overwhelmed the brain. I began to unload it, and this led to the fact that he basically lost the habit of remembering what is not recorded. Perhaps this is true only for my case.
Changing the context of work has become easier . As it turned out, this moment is amenable to training. The brain is used to constantly switching between tasks and coping with them much easier and faster.
Strange projects / technologies / approaches are easier . Being engaged in individual projects, the developer is limited by them. When you see the same things, embodied in many different forms on different projects, it becomes much easier to ignore the details and understand the general principles.
You can see how the company works . With regard to several projects and all developers at once, you can understand how the entire department and related departments work. This vision sometimes allows you to give the correct answers to non-standard questions about which order of actions will be the easiest for everyone in the sum, to which this or that decision belongs, etc.
You need to set tasks yourself . When you complete a project as a developer, you complete a set of tasks prepared by someone else. In the management of the department there is no TK or skopa works. A department is a project in itself, and I’m both a developer, a project manager, and a product owner. Decisions about what tasks you need to perform - on me.
Need to teach people . Often the same. Sometimes several times. The role of the technical leader is, in fact, necessary for this. If there are developers in the company who can learn from him (we have such, fortunately), this is very cool, and it makes sense to treat them with great attention.
Transferred tasks are rarely completed . Somewhere this is due to mistakes, haste, inattention, somewhere lack of understanding of the common vision, somewhere taste. For the most part, you have to give additional instructions and send tasks for revision, and in the conditions of burning deadlines, you can refine your work completely. I try to make sure that this does not become the “bottleneck” of the process.
Results
The article turned out to be voluminous. I hope she will clarify something to someone. Perhaps someone will add to their practice something from these developments or extract something else for themselves. Naturally, in each company and each department the role of a technical leader will look different, but I have highlighted the aspects that are currently seen as the most significant in my conditions. Thank.
Source: https://habr.com/ru/post/314170/
All Articles