What can help a project manager to work with programmers?

The previous article was quite popular. I promised to continue and keep my word. I share my personal opinion and do not pretend to the truth.

In this part we will talk about working with programmers.


')

1. Instead of crutches, a foundation is needed. People, not methodologies

From the experience of introducing various methodologies, Agile drew the following conclusions
1. It seems quite understandable that many seemingly use typical tips. Belief in a silver bullet, genie from a bottle is common to most people, project managers are no exception.

2. In recent years, all sorts of flexible techniques that only lazy people haven’t written about have become a popular solution. About this quality of people will be detailed below.

3. However, in practice, implementation most often instead of the expected order from chaos does not automatically increase the controllability of the development process. As a rule, due to the fact that a certain framework is taken stupidly, but it does not take into account the underlying causes of downtime. Of course, there are some successes - as is the case with separate nutrition, for example. But in the case of separate meals, people just start to watch what they eat, and this often helps along with placebo. And metolodoli can give effect, if before it was just just chaos.

4. As the developers' answer to all this, the famous English manifesto “Programming, Motherfucker! Do you speak it? ”And its Russian version .

5. Ultimately, the water wears away the stone. I will not argue that programmers in the “spend an hour on [censored] chatter” style have gotten the programmers, but there is some degree of influence here. The most routine pieces in the development of standardized and automated - and more and more beautiful articles from Yandex , Badoo and so on began to appear, as the development process is built. Where a lot of attention is paid to technical tools that really play into the development process, as opposed to endless dancing with a tambourine.

I want to note that with programmers who are smart and want to work, it is easy enough to interact. You explain to the person why the functionality is needed, and discuss user stories. Some architectural moments. And then man realizes what he needs, accurately and beautifully.

At the same time, the time spent searching for such programmers pays off handsomely. Than than you just type random people and will try to build with them some kind of “development” using “methodologies”. If there are good people, they will write the tools for themselves, or take them ready.

Frames decide everything, they wrote about this a hundred times, but the rake is still fresh and polished with new foreheads.

2. Requirements and input management as an effective way to simplify tasks

I would like to immediately note that I do not believe in theoretical knowledge. You can read a hundred books and pass on PMI, MBA and many other words, but fill up all the projects. Or you can do projects like pies, without owning valuable "knowledge."

It will be about the skills that are developed in the process of practice. I want to give only a couple of examples so that it is clear in which direction to think and what effect this can give.

Case 1. E-mails are sent, the link in which leads to the landing page. There is a task for a young project manager to limit the form of a landing page from spam.
An example is taken from another working group on how to make such protection for 8+ hours.
And here comes a more experienced person, and offers to carefully examine the initial conditions. Landing is intended only for opening from e-mails.
Consequently, in the first version it is enough to put a certain key in the URL that will cause the form to show on the landing page in the links from the letters. And with a direct entry form does not show.

Come up with - one minute, do - 15 minutes. Against 8+ hours. No comments.

Case 2. A project manager appeals to me. It is necessary, they say, to conduct a survey on the project. There was some kind of polling engine, is it possible to fasten it, or write your own.
Questions are being asked consistently.
- How many times do you need to conduct a survey? Answer: once
- Will the fields change: Answer: no, they will not.
- How many are participating in the user survey. Answer: a dozen.

In a minute I issue a decision - to make a form on Google Docks, and put a link on the project. Implementation - minutes, versus days for scrolling the polling engine, debugging, take-out and so on.

This also applies to the skidding of content with statics (HTML), if it does not change more often than once a month, instead of creating an engine and WYSIWYG, and many other things.

Having mastered the refinement of the initial condition and keeping the thought “how it can be done easier and faster” in your head, you can speed up development significantly. And teach this to your programmers.

3. Disclosure of personal potential instead of routine communication

Programmers, like any other creative person, are unique. After all, you would not begin to communicate with Azimov in the role of a publisher as you would communicate with Tolstoy. And with Pushkin, too, would have conducted their dialogue.

Each bright personality has its pros and cons. Often, at the same time, programmers, as complex and incomprehensible to non-technicians, are trying to classify in a certain way. And apply standard techniques, phrases, questions.

It all starts with the sample questions at the interview about "who do you see yourself in the company after 5 years," and can continue the whole period of work of a person in the company.

This is possible, but it seems to me that it is not very suitable for working with talents.

For example, I have a talented programmer, a former designer and layout designer. Enough unique experience, and therefore with him in the process of communication and setting tasks you can not worry about what he will do ugly. And I pick up tasks that most accurately allow him to open up. It seems to me that this motivates him - and for good reason he is already developing entire projects in my department.

And there is a programmer - special on OOP. He is very reliable, and always checks everything. But he likes to complicate things. And with him you can communicate without worrying that a non-working functional will fall into the release.

As a result, when a project arrives, it can be divided into blocks that best relate to the abilities of the team, which obviously affects the efficiency and productivity.

Each programmer has his own abilities, his own past, and an individual approach, in my opinion, something that can increase your productivity with the team at times. It is much better than to drive everyone into one open-space, so that people more often hurt and interfere with each other with noise, despite the fact that different “certified guys” recommend it. Demarco wrote about this 20 years ago and is still relevant.

4. Do not go after all - it often ends in failure

Stepan Demura, an ambiguous but bright trader, once said that if you stand in the market just like a crowd, you will definitely lose.

Oddly enough, this rule also works in project management. The more will be around the fuss, in the tops - the herd instinct, the less I advise you to follow the instincts.

We once, like everyone, rushed to do the city portal. And they were beaten by competitors. Although, it would seem, everyone does, and everyone should succeed.

Alas, there is a simple analogy that says that resources are almost always less than their potential customers, and there is competition.
Here is a tent with milk, and 100 people walk every day. The tent is successful, and there are competitors 2,3,4, ... N. And as 100 people went, so it goes. But the profits of each decrease with the advent of new ones, and ultimately everything is ruined (one of the variants of the scenario).

This is what happens with new niches in the business (remember the same couponers).

There is another example where this recommendation works a little differently.
Yesterday, everyone is sitting on NoSQL, today they are sawing on jQuery, tomorrow SVG + HTML5, the day after tomorrow 3d for FaceculusRift.

In the end, following the fashions on technology, you get a zoo project, where technology is harder and harder to make friends with. There are many examples.

In contrast, one well-known hotel booking site, working on [censored] mammoth Perl. I haven’t written in Perl for 10 years, and I’m still waiting for the legendary Pearl 6. It was an awesome language (and still is). As far as I know, hedgehogs prick, spit, but continue to eat the cactus. And the project grows and develops without suffering from sharp falls, “and then we rewrote everything in Java (substitute your language) and bought 1000 more servers so that every hour would not fall.”

Such unobvious things that start with thinking and managing their choices would seem to have little to do with development. But obsession begins with thought, and where obsession is, there is fanaticism. Which leads to strategic Fails.

They say that the design to correct the error is 1000 times cheaper than the production. And in thinking - infinity times. Only few people think about it, judging by the unfortunate startups everywhere.

5. Learn to program

They say that a fisherman fisherman finds out from afar. Even if you didn’t read anything and just scrolled down, you’ll already benefit.
If you learn to program, you will bypass hundreds of thousands of young guys and girls who dream of a high salary in IT, but only want to manage.
Because they love and recognize their own in any environment, and if the programmer’s head is technically savvy, then it gives +1000 (IMHO) to the skill of respect.

But, according to research, authorities are better listened to.

I will attach a good link (one more ) and a video of outstanding and famous people, why you should learn how to program.



In the comments I propose to share your findings from experience, some cases that you consider interesting.