Project management. Processing of industry economic information on railway transport Schedule of cooperation with the customer

1.1. Interaction with Customers (Main functions)

1.1.1. Search for orders

7.2.3.1. For questions about product information

1.1.2. Pre-contractual work with the Customer

Regulatory documents

2.2.1.2.1. Pre-contractual work with the Customer STP-1-01

Requirements for a quality management system ISO9000:2000 Section 7

7.2.1.1. Customer requirements for the product, including requirements for availability, delivery and maintenance

7.2.2.4. Determining the feasibility of meeting certain requirements

// Product requirements analysis / Consumer-related processes / PRODUCT SALES

1.1.3. Formation of technical specifications

Regulatory documents

2.2.1.2.2. Procedure for analysis and conclusion of the contract STP-2-01 // Enterprise standards of the Ellat enterprise (STP) / Quality management system documents / Internal regulatory documents / Regulations

Requirements for a quality management system ISO9000:2000 Section 7

7.2.1.2. Requirements not specified by the customer but necessary for the intended or specified use // Determination of consumer requirements / Processes related to the consumer / SALES OF PRODUCTS

7.2.1.3. Product Liabilities, including Mandatory Requirements and Legal Provisions // Determination of consumer requirements / Processes related to the consumer / SALES OF PRODUCTS

// Product requirements analysis / Consumer-related processes / PRODUCT SALES

7.2.2.2. Confirmation of consumer requirements before acceptance if the consumer does not provide a written statement of requirements // Product requirements analysis / Consumer-related processes / PRODUCT SALES

7.2.2.3. Identifying changes to contract or order requirements that differ from those previously submitted (for example, bidding or references) // Product requirements analysis / Consumer-related processes / PRODUCT SALES

7.3.1.1. Determining the stages of the design and/or development processes

7.3.2.2. Applicable legal and regulatory requirements

7.3.2.3. Applicable data obtained from similar previous developments // Input data for design and development / Design and development / PRODUCT SALES

7.3.2.4. Other requirements important for design and development // Input data for design and development / Design and development / PRODUCT SALES

7.3.4.1. Assessing the feasibility of meeting requirements

1.1.4. Conclusion of Agreements

Regulatory documents

2.2.1.2.3. Regulations on contractual work with the Customer (STP-3-01) // Ellat Enterprise Standards (STP) / Quality management system documents / Internal regulatory documents / Regulations

1.1.5. Monitoring the fulfillment of contractual obligations

Regulatory documents

2.2.1.2.3.2. The procedure for analyzing changes and making changes to Contractual documents // Regulations on contractual work with the Customer (STP-3-01) / Ellat Enterprise Standards (STP) / Quality management system documents / Internal regulatory documents / Regulations

2.2.1.2.4.1. Procedure for processing complaints and claims of the Customer

2.2.1.2.4.2. Procedure for eliminating the Customer's comments // Regulations on corrective and preventive actions (STP-4-01) / Ellat Enterprise Standards (STP) / Quality management system documents / Internal regulatory documents / Regulations

Requirements for a quality management system ISO9000:2000 Section 7

7.2.3.2. Processing requests, contracts, orders, including changes // Communication with the consumer / Processes related to the consumer / SALES OF PRODUCTS

1.2. Project work planning (Main functions)

1.2.1. Clarification of the composition of the complex and development volumes

Regulatory documents

// Ellat Enterprise Standards (STP) / Quality management system documents / Internal regulatory documents / Regulations

Requirements for a quality management system ISO9000:2000 Section 7

7.2.2.1. Determination of product requirements // Product requirements analysis / Consumer-related processes / PRODUCT SALES

1.2.2. Project Quality Assurance Planning

Regulatory documents

2.2.1.2.5. Composition and procedure for developing a project quality assurance program (STP-5-01) // Ellat Enterprise Standards (STP) / Quality management system documents / Internal regulatory documents / Regulations

Requirements for a quality management system ISO9000:2000 Section 7

7.1.1. Setting quality objectives for a product, project or contract

7.1.3. Definition of verification and approval activities and acceptance criteria // Planning of sales processes / SALES OF PRODUCTS

7.2.2.5. Recording the results of the analysis and subsequent tracking actions (see clause 5.5.7) // Product requirements analysis / Consumer-related processes / PRODUCT SALES

7.3.1.2. Defining review, verification and approval activities for each design and/or development stage // Design and development planning / Design and development / PRODUCT SALES

1.2.3. Formation of private technical specifications for the development of components of the complex

Regulatory documents

2.2.1.2.7. Project implementation technology. Stages and order of work (STP-7-01) // Ellat Enterprise Standards (STP) / Quality management system documents / Internal regulatory documents / Regulations

1.2.4. Project work planning

Regulatory documents

// Ellat Enterprise Standards (STP) / Quality management system documents / Internal regulatory documents / Regulations

Requirements for a quality management system ISO9000:2000 Section 7

7.1.2. Determine the need to establish processes and documentation, provide product-specific resources and infrastructure // Planning of sales processes / SALES OF PRODUCTS

1.2.5. Coordination and operational control of work performance

Regulatory documents

2.2.1.2.4.3. Corrective Action Procedure // Regulations on corrective and preventive actions (STP-4-01) / Enterprise standards of the Ellat enterprise (STP) / Quality management system documents / Internal regulatory documents / Regulations

2.2.1.2.6. Regulations on work planning (STP-6-01) // Ellat Enterprise Standards (STP) / Quality management system documents / Internal regulatory documents / Regulations

Requirements for a quality management system ISO9000:2000 Section 7

7.3.4.2. Identifying problems and developing proposals for follow-up actions // Design and development analysis / Design and development / PRODUCT SALES

7.3.7. Design and development change management

1.3. Development of design, software and operational documentation (Main functions)

1.3.1. Development of documentation for the hardware of the complex

Regulatory documents

2.3.3.3. Work plan for the hardware development and production department

1.3.2. Development of the software part of the complex

Regulatory documents

2.3.3.4. Work plan for the software development and production department // Programs and action plans / Organizational and administrative documents of the company / Regulations

1.3.4. Analysis and approval of design results

Regulatory documents

Requirements for a quality management system ISO9000:2000 Section 7

7.3.3.1. Meet design and development input requirements

7.3.3.2. Provide appropriate information for production and service operations (see 7.5) // Design and development output / Design and development / PRODUCT SALES

7.3.3.4. Identifies product characteristics that are essential for its safe and proper use // Design and development output / Design and development / PRODUCT SALES

7.3.5.1. Matching Output Data to Input Requirements // Design and development verification / Design and development / PRODUCT SALES

7.3.6. Approval of design and development results // Design and development / PRODUCT SALES

Education, Development, Trainings

Key words:

1 -1

So, where does a relationship with a client begin??

How does the client arrive? Either he applies himself, or someone recommends him to us as a company that wants to automate.

Where do we start? We don’t immediately rush to the phone to make an appointment - we We are starting to collect information about this company.

To do this, you can use open sources (media, Internet, website, reviews, etc.). We collect everything that can be collected - any information.
Then comes the most interesting thing - information from unofficial sources. We are trying to find some acquaintances, friends, former colleagues, etc. in order to find out everything we can about this company.

What is this for? To work efficiently, in order to develop first contact tactics based on the information received.

Then the first contact occurs. On it we, first of all, let's find out:

What does the client need?
Is he adequate from the point of view of his understanding of the order of the market value for this work and do you agree to pay? for what he needs? This is a very important question. Naturally, at the first meeting no one names any specific amounts, but the order of numbers or a certain interval where the project will most likely fall may be named. The attitude towards these figures is being clarified. For example, if we roughly estimate that this project costs 3-5 million, and the potential customer thinks that a million is a lot, then we probably won’t succeed with him. In addition, it often happens that the client does not have a clear idea of what he needs: he just wants everything to be good.
Based on this, we can already conclude - Do we need such a client, and do we need such a project?

Establishing Relationships

The second stage is establishing a relationship with the client:

Maybe, best so that informal, warm relations. Of course, this does not always work out.
Anyway, from the first contact we strive to establish with the client exactly partnerships. This is not an easy and quick process. Especially when it comes to large clients (companies with a large turnover, with status) - they always look down on you. They call the automation technician like they call an electrician to change a light bulb: “This one, please.” Here's the money, you're free." We try to fight this attitude from the very beginning and, sometimes, until the end of the project. Our entire technology for building relationships with clients is based precisely on the formation of partnerships.

The result this stage is preliminary decision on working with a given client and formation of a positive image in the eyes of the client.

I would like to focus on creating a positive image. Based on the initial information collected, we decide which of our employees can be trusted to represent our company at the first meeting with the client. This is a very important point. For example, if we send an excellent specialist for the first contact, but he has an earring in his ear, a greased-in hairdresser, etc., then the client may look and say: “Screw him!” This happens. Or, for example, a neat guy came in, with a haircut, in a suit and tie, but a boy of about 20. And the client looked and said: “This is a boy, what should I talk to him about? How to work with them - they don’t respect me at all, they sent me a boy!” Therefore, collecting this information is necessary, among other things, in order to understand who to entrust the first contact with and how to behave to the contactee, how to build a legend, how to present yourself.

Identifying decision makers

The next very important question is identifying the actual decision makers(the so-called decision makers). This stage consists of two points:

It turns out, who makes decisions according to our project.
And the second point - persons influencing the decision maker are identified.
What does it mean? For example, it is known that decisions in a company are made by the CEO, and he also has a financial director and an accountant. This could be an accountant who does everything the director says and sits quietly in a corner, or maybe vice versa, an accountant who tells the director that this is what needs to be done and the director listens to him. And if we initially discovered that this person has influence on his director, then this is our trump card, therefore, we need to try to establish a relationship with this particular accountant. I conventionally said that this is an accountant - he could be anyone (for example, the head of the sales department or some deputy who is completely trusted by the general director or owner of the company). It is necessary to establish a relationship with the person influencing the decision maker.

The goal, as you can already see, is to identify the decision maker. And the result is a list of decision makers and persons influencing the decision maker.

Our experience shows that you need to try to meet with decision makers as quickly as possible- usually they are either senior management or the owner of the company. This does not necessarily have to happen at the first contact, but if such a meeting does not occur at the preliminary stage, then, as a rule, nothing good will come of our project.

Establishing partnerships

The next stage is establishing partnerships.

We initially do emphasis on two-way responsibility: even in the contract, if possible, we write not the Customer-Executor, but “ First side"(this is the Customer) and " Second side"(this is the Performer). True, sometimes some large government agencies say that the legal department does not allow them to do this, because the documents are checked by the Treasury, the Ministry of Finance, and others. In this case, we prescribe standard wording - “Customer and Contractor”. But if possible, then - “First” and “Second Side”.
We are trying our best to convey that this is a joint effort. Leaders on both sides act as high-level contracting parties - they were the ones who decided to do this automation project. To implement this project they recruit a team consisting of How of the employees of the first parties, such of the employees second side- this is the so-called “ Joint Working Group”, which makes the project. Naturally, each party invests its own resources in the project: material, technological, methodological, financial - because, in general, we are talking about quite large projects.
Supervises the work of the joint working group« Joint Supervisory Commission"- This is the highest regulatory body, usually consisting of top management from both parties.
AND the responsibility of each party is signed so that the customer’s employees understand that not only we, but also they are responsible for the project. We spend a lot of effort and time to convey to the client that we are doing this project together with his employees, and that their work directly depends on the quality and especially on what time frame the project will be completed.

Well result this stage is a fixation(formal or informal) relations equal partners:

Formal fixation is an agreement.
And the informal one can be some kind of official documents, in which we always try to prescribe the “First and Second Parties” and their relationships.

Informing the Customer about the project technology

The next stage is informing the customer about the technology.

On large projects we, without fail, have “ Course of lectures and seminars on introduction to design technology" In this course of lectures, we convey to the customer’s employees how the entire project process will take place:
- How is a project made using our technology?
- Who is responsible for what?
- Who is doing what?
- Why are certain actions being done?
- Why is this or that document needed? What does it give to both sides? (to make it clear to employees that partnerships provide benefits not only to us, but also to the customer).
- At every opportunity we We inform the decision maker about all problems that arise during the work. For this purpose, we have a number of special daily documents - for example, the “Contact Diary” or the “Deviation List”. And even if not every day, but every few days the customer’s management should get acquainted with them. And since, as a rule, excuses are immediately found: I was busy, didn’t read, etc., then, accordingly, it is necessary to constantly remind about this, maybe even simulate some situations that force management to read these documents.

The result of this stage is that all responsible persons of the customer have completed a course of lectures and, most importantly, that management has a clear understanding of how the work is carried out (of course, if it controls the project quite tightly).

Organization of relations with the Customer

The next stage is the organization of relations with the Customer. Here I want to tell you about one interesting “trick”: on the project we have such roles (these are not positions, but roles) such as “Contract Manager” and “Object Manager” (most often they can also be combined and with some other responsibilities). As stated here on the slide, these roles correspond to the definitions of “bad” and “good.”

Contract manager- this is “bad”. This could be an individual or one of the top managers. Most often, the function of a contract manager is performed by the project manager (if he is, of course, able to do so). This is the “No” person - he can come to the decision maker and say: “our contract says this, but you are now doing it differently, and because of this, a deviation arises. Let's figure it out." He always points out shortcomings, non-compliance with technology, encourages compliance with documentation- that’s why he’s always “bad.”
A object manager- this is “good”. This is a person who, for various reasons, has developed a good relationship with the decision maker of the customer. Maybe he just happened to like him. Or, for example, they have some kind of connections (family, clan, friendship - whatever). The main thing is that the client is attracted to him.
Our object manager actually manages this object. Please note, this is not a project manager, this is a special person who is engaged in maintains good relationships with customer management, and when some acute problems arise, he smoothes them out.
For example, after the contract manager has reprimanded the client about non-compliance with some terms of our agreements (this may end, in general, in some kind of unpleasant conversation for us), the facility manager comes and begins to reassure the client.
It’s not for nothing that I said that the object manager is called “good”. They usually say that being a “nice guy” is not a profession. But this is our profession. The facility manager is the “good guy.” He may not be a professional specialist in anything, but the client feels good with him - he came, talked to him (maybe about politics, football, etc.), and the client felt good, his attitude changed. Before this, the client was going to reprimand us for something, to punish us for something, but now he already understands everything, it’s generally inconvenient for him to speak badly to us.
This is the object manager function. It is assigned to every fairly serious client.

Of course, everything I’m talking about requires certain resources and costs. And, naturally, it makes no sense to create this entire structure for the sake of a small store - this is all done only for the sake of fairly large objects.

The result of this stage is the appointment of suitable contract and facility managers for a given client, because it is very important to select these people correctly.

Organization of project processes

The next stage is organization of project processes. In my opinion, there are only two of them:

Project progress monitoring;
And making management decisions based on monitoring results.

The most important thing is to convince the customer to work using our technology. This work procedure is explained to the customer both in personal conversations with decision makers and when responsible employees attend a lecture course (it explains how and what will happen on the project - the customer’s employees must attend this course, against signature).

Sometimes it can be very difficult to convince a customer to work using our technology. For example, we had one client - a very large IT company. Moreover, she herself was involved in automation on MS Navision, but for certain reasons she decided to call us to automate them on 1C. So, working with them was a real nightmare - everyone cried, both managers and programmers. Because it was a very large company (we are small compared to them), and they thought that they knew everything and tried to teach us. They constantly said: “guys, you’re doing everything wrong, there’s such and such a technology, you should do it this way.” Naturally, this happened only at the middle management level, the manager (who was the main owner and CEO of the company), of course, understood everything perfectly, and after his intervention everything was decided, but it was very difficult to get hold of him. And at the middle management level there were constant problems, constant attempts to teach.

We are on every project, without fail, We try to convey to the client the idea that in his business he is a professional (and we, naturally, do not interfere), but in matters of automation, we are professionals, so we need to be trusted and not try to tell us what and how to do. Moreover, if they don’t just tell us, but try to force us: “let’s do it differently, because I want it that way.” These are the things we immediately try to stop. Of course, “stop” is a loud word, at least try to explain it quite gently. If we agreed to this project, decided that we were satisfied with it, got involved in this “battle,” then now, naturally, we have to work with it.

Limiting the client's wishes

The next stage is limiting the client's wishes. Everyone has probably encountered this (when the so-called “wants” begin - more, more and more). Here we do it quite simply:

For example, when a client says that this and that still need to be done within the allotted budget and time frame, then sometimes quite complicated things begin. procedure explaining how it all works. We remind the client that we have a budget, allocated people (joint working group), each side of the project contributes its resources. Therefore, if additional work arises, additional hours and additional people are required. Where to get them from?
Or if the client delays the project, then both our people and his people are idle, and they are paid money. Where to get these resources? Not to mention the fact that these people not only receive a salary, but also bring some kind of profit to the company. Naturally, the company does not want to lose this profit. It is explained to the client in sufficient detail, and the client usually responds very well.
We make it clear We provide a detailed digital layout- where, what, to the last penny. And we say that if you want us to do this too, then please it will take so many hours and you have to pay for them. In the end, the client agrees with us and either refuses his “wants” or pays for additional hours. Of course, it happens in different ways - I’m now idealizing the picture a little.

Here I want to give another example of relationships. We worked with one very large company (they were already at the maintenance stage), and there periodically some tasks for improvements arose: for example, to make some kind of sophisticated report or something else. And so, the chief accountant of the company assigned us certain work, and we did it. And when the time came to pay, he said: “In general, I was mistaken, we don’t need all this at all.” But the work was done, therefore, it was necessary to pay. And he says: “No, I won’t pay for it, I can’t go to the president of the company and tell him that I’m a fool and ordered the wrong thing.” Moreover, the company was a very large oil company, the relationship was good both with it and with this person. And we didn’t insist - if he doesn’t pay, he doesn’t pay. Although, because of this, we lost a fairly large amount of money for us at that time (this was 2004). At the end of the year there was a denomination (the Azerbaijani manat dropped zeros). And for all clients who were in our service, we did this recalculation as a matter of routine - no additional money. But we approached this accountant (at that time, literally less than a year had passed since that incident), and said: “Remember, you didn’t pay us? Then we met you halfway. And now - denomination. Let's do this for free?" No questions asked - we issued an invoice, he paid.

Why did I give this example? On the importance of good relationships. If we had then stood up on our hind legs and demanded that this amount be paid to us, then we would have risked losing a good client. And so we maintained our relationship with him.

Who is responsible for explaining this budget?:

This in working order is engaged project manager- head of the joint working group, which, in fact, implements the project.
If he doesn’t succeed, then he connects contract manager, who explains by numbers and says that this is breach of contract, breach of agreement.
In the most difficult cases connects object manager, who tries to explain (of course, without any strict framework) to the customer why he needs to limit his desires.

Usually, if the numbers are described in great detail, then this layout and its explanation is sufficient.

Delivery of work

Delivery of work. Here, in general, there are usually no big problems, because Our work delivery procedure is spelled out in great detail in relevant documents.

But at this stage there is an element of informality ( good attitude), of course also makes life easier for both us and the customer Same.

The goal of this stage is to achieve the delivery of work in full compliance with the rules established in the relevant documents, which are annexed to the contract signed by both the client and us. Accordingly, one can always present that there are such rules.

Post-project relationships

And finally, post-project relationships. This is also a very important component. What should we strive for at the end of the project? By concluding a service contract, of course. But this doesn't always happen. Because there is the concept of “result”, and there is the concept of “outcome” - and these are slightly different things.

Let me give you an example. We had a project with one very serious company, and the result on that project was brilliant for us - it was one of those rare cases when we completely met both the budget and on time, absolutely as originally planned. This was the result. And the result of the project was that the service agreement was not signed. Moreover, the customer said that he would never work with us again. This is the result. In other words, the result is brilliant, but the outcome is very sad.

Why did this happen? Because there were no informal relationships. We had just developed our design documentation technology, and this was the client where all this technology was demonstrated in its full glory. And when we asked the customer: “Okay, you won’t work with us - are there any complaints against us?” And we were told through clenched teeth angrily: “That’s the problem, we can’t make any claims - no matter what you say, you have a piece of paper for everything, and we can’t do anything. We are not happy with this, and we will not work with you anymore. Other companies can be asked to do something additional, but you refuse - this is your budget, this is what you are supposed to do, this is the deadline. Step to the side - and you immediately show us a piece of paper with our signature.”

Therefore, the result was sad. But I emphasize once again that this result was due to the fact that there were no informal relationships.

This article was written based on a report given by the author at the Infostart IE 2014 Conference on October 29-31, 2014.

We invite you to a new conference.

Great events. Technologies and practice of event management. Shumovich Alexander Vyacheslavovich

Procedures for interaction with Clients

During the preparation and implementation of the event, you will encounter certain standard situations in interaction with Clients. Practice these typical procedures. This is a technological moment, and here you must work like a well-oiled conveyor belt, according to a clear algorithm. Standard situations can be considered:

– registration, confirmation of participation. Think about it in detail How The client can communicate his decision to participate in your event (mail, telephone, fax, website, in person) and with what(questionnaire, call, buying a ticket...);

– actions after registration. Report your actions to the Client. Should you send him confirmation? Should (when and how) be reminded about the event? Practice internal actions: compiling lists of participants, maintaining a database. Depending on incoming data on the number and composition of participants, adjust your plans and actions;

– reminders. They may well forget about the event or set priorities differently by canceling participation. In this case, a reminder will serve you well. You will either return the almost lost Client, or find out that he will not come, and you will be able to make adjustments to your plans. This procedure requires precision, consistency and accuracy on your part. Always call back when promised. However, don't be intrusive;

– failure or replacement. Since we are dealing with a service, our Clients may change their mind about participating in the event. Practice the procedure for canceling or replacing a participant. If a participant is replaced, make changes to the database in a timely manner. In case of cancellation of participation, return the money if the conditions agreed upon during registration are met. This is also an important point: refusing to return the money at an early stage can harm your relationship, and the Client will not want to work with you in the future. On the other hand, there comes a time when you have already made the necessary expenses and, having learned about the refusal to participate, you cannot change anything. Let your Clients be informed about this, let them understand your position;

Cancellation received later than one week before the event will not provide a refund. A participant can be replaced at any time. Please inform us of these changes in writing.

(Text from Eventum booklet)

– special procedures. Consider what special situations and special relationships you may have with the Client. Let's say, special conditions of participation for a certain category (for example, for regular Clients or, conversely, participating for the first time).

“If you would like to send a group of employees to the event, we will be happy to discuss special conditions and provide you with a discount.

If you prefer to get to the boarding house yourself, please inform us about this and provide the number of your car."

From the book Competence in Modern Society by Raven John

Accountability Criteria and Procedures From the material we have reviewed in this chapter, it can be concluded that there is an urgent need for procedures that:1. Enable civil servants to take collective responsibility for: – improvement

From the book The Big Book of the HR Director author Rudavina Elena Rolenovna

6. H. Documentary support for the certification procedure - But I won’t give it to you. Because you have no documents. Cartoon “Three from Prostokvashino” The list of documents for certification includes a review or

From the book Show Me the Money! [The Ultimate Guide to Business Management for the Entrepreneur Leader] by Ramsey Dave

From the book Handbook on Internal Audit. Risks and business processes author Kryshkin Oleg

From the book Beauty Salon: from business plan to real income author Voronin Sergey Valentinovich

Active restorative procedures Reaffirming (strengthening) facial massage The massage technique is based on the effect on facial and other wrinkles, restoring the tone and turgor of all layers of tissue. The massage is based on the technique of deep local kneading,

From the book The Managerial Elite. How we select and prepare it author Tarasov Vladimir Konstantinovich

Innovation. Procedures from GUINOT Hydradermie Lift procedure A whole hour of relaxation and bliss for your skin! Long laboratory research at the GUINOT Institute has resulted in a truly unique Hydradermie lift procedure. The result is smoothing of facial wrinkles and instant rejuvenation.

From the book Development of Employee Potential. Professional competencies, leadership, communications author Boldogoev Dmitry

3.10 Evolution of the competitive procedure The first city competition of professional skills of young production organizers was followed by others. Both city and industry. New business games and types of tasks have appeared. The way results are calculated has changed.

From the book The Practice of Human Resource Management author Armstrong Michael

Procedures - capabilities This assessment parameter is somewhat similar to the previous one, but there are also significant differences: we evaluate not so much the propensity for a process or result, but rather the path a person takes in solving his problems. It should be noted that this is more about

Submitting your good work to the knowledge base is easy. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Similar documents

Analytical review of the target audience. Creating and populating a database using Microsoft Access. Development of the interface and functions of the workspace. Construction of forms. Functional requirements for the application. Its testing using the black box method.

thesis, added 11/09/2016

Description of the structure of the training block. Design of its algorithm and linguistic and information support. Organization of its interaction with the database. Graphical interface development. Software implementation of the main functions of the application.

thesis, added 12/20/2015

Characteristics of the agency's activities, structure and functions. Analysis of the current structure of the website for ordering outdoor advertising. Description of the functional architecture and data architecture of the designed automated module. User interface design.

thesis, added 07/22/2015

Content management systems. Real estate agency website design. Information support of the system. Building a logical data model. Website interface development: software, script structure, its computer implementation.

thesis, added 10/27/2017

Development of architecture, individual modules and website for an Internet system for electronic trading of heating appliances. Interface design; software implementation, database creation. Website promotion: selection of keywords, analysis of competitive queries.

course work, added 04/20/2012

Physical data model. Development of the system structure, description of algorithms. Development of a user interaction interface. Layout of a travel agency website, ways to access data. Requirements for the program, stages and stages of development, listing.

thesis, added 05/03/2012

Development of site architecture, data structure and necessary software modules. Taking into account the company's corporate style when creating a design. Implementation of a site administrative editing interface. Conducting experimental testing and debugging.

thesis, added 01/19/2017

Projects are different, and they need to be managed differently. In large projects, where a large number of developers are employed, not to mention business analysts, testers and the project customers themselves, the issue of coordination of actions comes to the fore, overshadowing all other tasks.

It is for this case that the Agile project management methodology was invented.

Its 4 main postulates sound like this:
- individuals and their interactions are more important than processes and tools,
- working software is more important than complete documentation,
- cooperation with the customer is more important than contractual obligations,
- reacting to changes is more important than following a plan.

Focusing on communication and the end result, rather than following a plan and complete documentation, allows for more flexibility and a less bureaucratic coding process. The downside of such a democratic approach is the lack of clear planning, the need to constantly redo already written parts of the code and the regular rush jobs associated with this.

Despite a number of shortcomings, in many cases the agile methodology is indispensable. Therefore, any head of the development department should be familiar with it.

Job responsibilities of the head of the development department

Development of standards and policies in the field of software development in accordance with the general IT policy of the company;
- planning and coordinating the work of the development department;
- development and monitoring of compliance with project schedules;
- assessment of the labor intensity of projects and distribution of development tasks among programmers/developers;
- development process management;
- development of technical specifications for software modules;
- planning and control of department budget execution;
- management of external resources involved in software development;
- development of normative documentation regulating the work of the department and the procedure for interaction with functional units;
- participation in the development of the company's development strategy.

Salary offers and employer requirements

The average salary offer for the head of the development department in Moscow is 150,000 rubles, in St. Petersburg - 117,000 rubles, in Volgograd - 66,000 rubles, in Voronezh - 75,000 rubles, in Yekaterinburg - 100,000 rubles, in Kazan - 75,000 rubles, in Krasnoyarsk - 90,000 rubles, in Nizhny Novgorod - 70,000 rubles, in Novosibirsk - 85,000 rubles, in Omsk - 75,000 rubles, in Perm - 85,000 rubles, in Rostov -on-Don - 75,000 rubles, in Samara 75,000 rubles, in Ufa - 75,000 rubles, in Chelyabinsk - 84,000 rubles.

Applicants applying for the position of head of the development department for the first time must have a higher education (specialized or technical) and at least 3 years of experience in creating software. Knowledge of the principles of object-oriented programming and software development methodology (RUP, MSF) is required; skills in working with a DBMS are required. Employers welcome knowledge of several programming languages. The starting salary for beginning heads of development departments in Moscow ranges from 70,000 to 110,000 rubles, in St. Petersburg - from 55,000 to 86,000 rubles, in Voronezh and Perm - from 35,000 to 55,000 rubles.

City	Income level, rub. (no experience in this position)
Moscow	70 000 - 110 000	- Higher education (technical / IT) - Knowledge of one or more programming languages - Understanding of object-oriented programming principles - Knowledge of software development methodology (RUP, MSF) - Knowledge of English at the level of reading technical documentation - Experience with DBMS - Experience in software development for at least 3 years Portrait of the applicant in range 1
Saint Petersburg	55 000 - 86 000
Volgograd	30 000 - 48 000
Voronezh	35 000 - 55 000
Ekaterinburg	47 000 - 74 000
Kazan	35 000 - 55 000
Krasnoyarsk	42 000 - 66 000
Nizhny Novgorod	33 000 - 52 000
Novosibirsk	39 000 - 62 000
Permian	35 000 - 55 000
Omsk	40 000 - 63 000
Rostov-on-Don	35 000 - 55 000
Samara	35 000 - 55 000
Ufa	37 000 - 55 000
Chelyabinsk	40 000 - 62 000

Employers expect, first of all, developed organizational and leadership skills from candidates with more than 1 year of experience managing a development department. Job requirements relate to experience in planning, organizing and implementing projects, developing technical documentation, as well as skills in using project management tools. Applicants for the corresponding vacancies in the capital can expect a salary of up to 140,000 rubles, in the city on the Neva - up to 109,000 rubles, in Voronezh and Perm - up to 70,000 rubles.

City	Income level, rub. (with work experience of 1 year or more)	Requirements and wishes for professional skills
Moscow	110 000 - 140 000	- Developed organizational and management skills - Skills in planning, organizing and implementing projects - Skills in using project management tools - Skills in developing technical documentation Portrait of an applicant in range 2
Saint Petersburg	86 000 - 109 000
Volgograd	48 000 - 62 000
Voronezh	55 000 - 70 000
Ekaterinburg	74 000 - 94 000
Kazan	55 000 - 70 000
Krasnoyarsk	66 000 - 84 000
Nizhny Novgorod	52 000 - 66 000
Novosibirsk	62 000 - 78 000
Permian	55 000 - 70 000
Omsk	63 000 - 80 000
Rostov-on-Don	55 000 - 70 000
Samara	55 000 - 70 000		Ufa	55 000 - 70 000	Chelyabinsk	62 000 - 78 000

Additional education in the IT field and experience in setting up a full development cycle are the most typical requirements for applicants with more than 2 years of development management experience. The earnings that such specialists can count on in companies in the capital reach 175,000 rubles, St. Petersburg - 137,000 rubles, Voronezh and Perm - 88,000 rubles.

City	Income level, rub. (with work experience of 2 years or more)	Requirements and wishes for professional skills
Moscow	140 000 - 175 000	- Additional education in the field of IT - Experience in setting up a full development cycle (from technical specifications to commissioning of the project) Portrait of the applicant in the 3rd range
Saint Petersburg	109 000 - 137 000
Volgograd	62 000 - 77 000
Voronezh	70 000 - 88 000
Ekaterinburg	94 000 - 117 000
Kazan	70 000 - 88 000
Krasnoyarsk	84 000 - 105 000
Nizhny Novgorod	66 000 - 82 000
Novosibirsk	78 000 - 98 000
Permian	70 000 - 88 000
Omsk	80 000 - 100 000
Rostov-on-Don	70 000 - 88 000
Samara	70 000 - 90 000
Ufa	70 000 - 88 000
Chelyabinsk	78 000 - 100 000

Large enterprises offer the highest salaries to heads of development departments. Such employers require candidates to have at least 3 years of experience working in organizations of a similar size. Companies with foreign partners give preference to specialists who are fluent in English. The salary maximum in Moscow reaches 300,000 rubles, in St. Petersburg – 235,000 rubles, in Voronezh and Perm – 150,000 rubles.

City	Income level, rub. (with work experience of 3 years or more)	Requirements and wishes for professional skills
Moscow	175 000 - 300 000	- Experience in managing developments within a large company for at least 3 years Possible wish: knowledge of English at a conversational or fluent level Portrait of the applicant in the 4th range
Saint Petersburg	137 000 - 235 000
Volgograd	77 000 - 130 000
Voronezh	88 000 - 150 000
Ekaterinburg	117 000 - 200 000
Kazan	88 000 - 150 000
Krasnoyarsk	105 000 - 180 000
Nizhny Novgorod	82 000 - 140 000
Novosibirsk	98 000 - 170 000
Permian	88 000 - 150 000
Omsk	100 000 - 170 000
Rostov-on-Don	88 000 - 150 000
Samara	90 000 - 150 000
Ufa	88 000 - 150 000
Chelyabinsk	100 000 - 170 000

Portrait of the applicant

Among applicants for the position of head of the development department, the majority are middle-aged men with higher education. There are only 5% of the applicants among the fairer sex, which is typical for the IT field. 58% of applicants are specialists aged 30 to 39 years. 96% of development department heads have higher education. Every third applicant is fluent in English.

Blog embed code

Head of Development Department

Project management skills - this requirement is often found in vacancies for development managers. In fact, there may be much more hidden behind these words than meets the eye. ");