What can help the project manager in working 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 be true.

    In this part, we will talk about working with programmers.

    1. Instead of crutches, you need a foundation. People, not methodologies

    From the experience of implementing various methodologies, Agile made the following conclusions
    1. Many seem to understand the obvious solution to the use of standard tips. Belief in a silver bullet, a genie from a bottle is common to most people, project managers are no exception.

    2. In recent years, all sorts of flexible methods have become a popular PR solution, about which only the lazy did not write. About this quality of people will be detailed below.

    3. However, in practice, the introduction of the most often instead of the expected order out of chaos does not automatically increase the manageability of the development process. As a rule, due to the fact that a certain frame is stupidly taken, but the underlying causes of downtime are not taken into account. 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 monitor what they eat, and this often helps, coupled with a placebo. So metropolitan countries can give effect, if before there was simply 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, water sharpens a stone. I will not argue that the programmers in the style of “spend an hour on [censored] chatter” got them, but there is some share of influence here. The most routine pieces in the development were standardized and automated - and increasingly, excellent articles from Yandex , Badoo, and so on, began to appear about the development process. Where much attention is paid to technical tools that really play a part in the development process, in contrast to endless dances with a tambourine.

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

    At the same time, the time spent searching for such programmers pays off handsomely. Rather than just picking random people and trying to build some kind of “development” using them, using “methodologies”. If there are good people, they will write tools for themselves, or take ready-made ones.

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

    2. Management of requirements and input data as an effective means of simplifying tasks

    I would like to immediately note that I do not believe in theoretical knowledge. You can read one hundred books and pass on the PMI, MBA and many other words, but heap up all the projects. And you can make projects like pies without owning valuable “knowledge”.

    It will be about the skill that develops 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. A distribution of e-mail letters is made, the link in which leads to the landing page. The young project manager is faced with the task of limiting the form of landing 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 study the initial conditions. Landing is intended only for opening from mail letters.
    Therefore, in the first version it’s enough to put a key in the URL in the links from the letters, which will cause the form to appear on the landing page. And with a direct approach, do not show the form.

    To come up - one minute, to do - 15 minutes. Against 8+ hours. No comments.

    Case 2. The project manager is contacting me. It’s necessary, they say, to conduct a survey on the project. There was some kind of polling engine, whether it is possible to fasten it, or write your own.
    Consistently ask questions
    - How many times do you need to conduct a survey? Answer: once
    - Will the fields change: Answer: no, they won’t.
    - How many users are participating in the survey. Answer: a dozen.

    In a minute I give out a decision - to make a form on Google Doks, and put a link on the project. Implementation - minutes, against days for fastening the poll engine, debugging, releasing to release, and so on.

    This also applies to static content skipping (HTML), if it does not change more 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 in your head “how can this be done easier and faster”, you can significantly speed up the development. And teach this to your programmers.

    3. Disclosure of personal potential instead of template communication

    Programmers, like any other creative person, are unique. After all, would you not communicate with Asimov as a publisher as you would communicate with Tolstoy. And with Pushkin we would also have a dialogue.

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

    It all starts with template questions at the interview about “who you see yourself in the company in 5 years”, and the whole term of a person’s work in the company can continue.

    It 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. A fairly unique experience, and therefore with it in the process of communication and task setting, you do not have to worry about what he will do ugly. And I select tasks that will most accurately allow him to unfold. It seems to me that this motivates him - and it is not without reason that he is already developing entire projects in my department.

    And there is a programmer specializing in OOP. He is very reliable, and always checks everything. But likes to complicate. And with him you can not worry in communication that the broken functionality will get into the release.

    As a result, when a project arrives, you can divide it into blocks that are best suited to the team's abilities, which obviously affects efficiency and productivity.

    Each programmer has his own abilities, his past, and individual approach, in my opinion - that can increase your productivity with a team at times. It is much better than dropping everyone into one open-space, so that people often get sick 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 follow everyone - it often ends in failure

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

    Oddly enough, this rule also works in project management. The more there will be around the fuss, in topics - a herd of feelings, the less I advise you to follow the instincts.

    We once, like everyone, rushed to make a 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 there are almost always fewer resources than their potential consumers, and there is competition.
    Here is a tent with milk, and 100 people walk a day. The tent is successful, and competitors 2,3,4, ... N appear. And as 100 people walked, it walks. But the profit of each decreases with the advent of new ones, and in the end everyone will go broke (one of the scenarios).

    This is what happens with new niches in 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.

    As a result, following the fashion for technology, you get a zoo project where it is more and more difficult to make friends technology. There are many examples.

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

    Such non-obvious things that begin with thinking and managing your choice seem to have little to do with development. But with the thought begins obsession, and where obsession - there is fanaticism. Which leads to strategic fails.

    They say that on design it’s 1000 times cheaper to fix a mistake than on production. And in thinking - in infinity times. Only few people think about it, judging by the unsuccessful startups everywhere.

    5. Learn to program

    They say that the fisherman knows the fisherman from afar. Even if you haven’t read anything and just scrolled down, you will already benefit.
    If you learn to program, you will bypass hundreds of thousands of young men and women who dream of high salaries in IT, but only want to manage.
    Because they love and recognize their friends in any environment, and if the head of the programmer is technically savvy, then this gives +1000 (IMHO) to the skill of respect.

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

    I’ll attach a good link (another one ) and a video by prominent 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 find interesting.

    Also popular now: