Last week our team gathered for a training for the first time. I personally don’t perticularly like the word but I couldn’t find a better one. So, this training was on how to put, distribute and monitor tasks avoiding the sticks and stones, which is the most topical issue now. What the discussion was about and how loveful customers relate to it - please see below - now! 

Shortly speaking 

Highload development, as well as web-development, is a complicated process, with many sticks and stones. You’d better take it for granted as you cannot do anything about it. The thing is - how to make the best of the pioneers’ experience for newbies. The head of our Highload Projects Dept. Grigoriy Kazakov gives some practical advice.

Put me in my place 

1. Order not for show. You should structure all the project documentation, for the purpose you could find it easily and refer to it any moment. The same advice is applicable to a corporate portal and manager’s desktop - just organize every task in its group and every file in the corresponding folder. 

2. When giving out a task you should build it upon handwritten or printed text - technical solution or abstracts therefrom. You may also work out your personal version of the technical solution or task. 

3. Before you include an abstract in the technical solution or a task description, define its degree of importance. There are three of them: 

A. obvious. E.g. to implement payment option storage it is impossible without ability to enter/store/output/edit data; 

B. false obvious. Writing abstracts, we sometimes forgot to mark some of them. Several months later, forwarding them for implementation, we saw that some of the obvious decisions had become non-obvious; 

C. implementing algorithms relating to the specific task type. This type requires detailed description with examples. It’s better to spend a couple of minutes than trying hard to remember what exactly was meant here. 


1. A may not have a detailed description. A simple abitily to enter/store/output/edit data should be enough. 

2. B. and C. require detaled description in the task/documentation.

4. Add various schemes, diagrams, images to the project documentation. Thus you make it more comfortable for yourself as well as for the client. I think you would agree that it is far more pleasant to see images and diagrams than volumes of 8pt text. 
5. Organize any complex logic in a business scheme. If you are a task manager, you should find out everything about the business process, make notes and schemes. They’ll be of great help in case of misunderstanding between yourself and the client.

Necessary skills for a task manager

1. Organize the task and its workflow in your mind. After that, share the tasks between the developers. 

2. It is good when the manager keeps in mind every detail of the task description and co-ordinate them with every programmer’s abilities. It reduces the risk to overdue a hotrush project and come across dubbing. e.g. For developing a mechanism for calculating rankings, try to add a note ‘develop a separate task and a procedure for re-calculating the rankings’. 

3. Sense the developers. Exactly like this. The most important skill for a manager is to see potential problems in the task and make the developers see it. 

4. Monitor the status of the project during the development process and after the task is completed. You should monitor even the most experienced developers. There is a chance to refer flaws to the tester just in time. e.g. a wrong component is used - “input” instead of “select” or “select” instead of “autocomplete”. 

5. Share your experience, methods with the specialists if you are the head of the department. If you google an article, save it on your computer. Maybe you do not need it anymore now but there is a chance you or your co-worker will. Create something like an archive with “articles to use”. This is how we easily found a lot of information on sql-dependancy, xml-dependancy, ms sql fulltext search, etc. for the Sberbank project. 

6. Divide tasks into parts. If the technical solution is structured, the parts correspond with the abstracts. 

7. For control and self-control purposes, paint over or cross out the implemented parts in the list of requirements.

Oh, just give it to someone! 

 Do not lay everything upon yourself - just delegate the tasks. This i how we do it in our Highload Projects Dept.: 
1. we give the least complicated tasks to the newcomers 

2. tasks of medium complexity (development of functionalities without having to make quotations) are for experienced developers 

3. advanced tasks (development of functionalities + quotation) are performed by the exparienced developers along with the head of the department. P.S. As was mentioned above - some words about two so-called antagonists - loveful clients and developers. It is the pecularity fo the programmer’s job that they know practically nothing about the client they develop a feature or fix a bug for. The work scheme is almost always the same: the project manager told > the manager showed > the programmer developed. The second part of our training was dedicated to break the information blockade and explain how to work as a team to make the formula “a happy client= a happy developer” come true. You may see the results in our Portfolio.

Author: Grigoriy Kazakov, Head of Highload Projects Dept.

Back to the list

Name Quote 0
Message Text*
Spam bot protection (CAPTCHA)