Monday, October 23, 2017

Organization of the development department from scratch

Slides: link

Introduction

What is the basis of the post?

I base my post on more than 10 years of experience in organizing various types of activities and groups:
  • As a foreman of the brigade of installers, I organized networking activities
  • As a teacher, I organized the activities of students to achieve the goal of pursuing the course
  • As a customer, I organized the work of contractors
  • As the head of the testing department, I was engaged in organizing work to achieve the required level of quality of projects in the development
  • Now as the head of the development team, I am engaged in the organization of works on the creation of projects.



I tried to make a squeeze out of my observations and conclusions drawn from them. I want to warn: the topic is extensive and the materials are written a heap, so I'll tell you the key things. If you have conflicting questions, doubts and turbulence as a result, that's good. Ask me them by mail or through social networks.

Define the concepts

Organization is a process, an activity to create and improve the interrelations between parts and elements in order to bring order to processes and improve their effectiveness.

No matter what activity - the principles of organization are laid the same. Yes, each group has its own characteristics (specificity of activities, culture, ways of implementation), which the head takes into account, but the essence of the organization as an activity does not change.


Why is it so difficult to start from scratch?
On an established project, much has already been determined: processes have been established, regulations have been established, people have been hired, and tasks have been prioritized. We are already in the process and take into account the circumstances.

At the start, you start from scratch. Eyes run up, you have to do so much and it's unclear how to start, where to put priorities, what tasks to choose. At this stage, you are already waiting for results from the program, but nothing is ready yet.

The first relief:

In fact, with all the problems of growth and development, it's easier to grow. Since energy is spent less than when stabilizing and maintaining a balance. But there is a high share of uncertainty and risks.

Where do we start?

First we need to understand where to develop. You need a clear understanding of the goal, in order to know more precisely where you will move and how you will understand that you are going in the right direction? The goal defines the criteria for achieving.

What's next?

To determine the goal, talk with your manager and the heads of departments with whom you will work. Find out what they expect from you. Have your manager expect these expectations.
For navigation in space, in addition to a clear understanding of the goal, it is important to understand where you are right now. What means do you have? What do you have? What is the budget? What means of production? How many people are there? What time frame?

How to move towards the goal?

Tasks and their implementation - the main way to move to the goal. As soon as you begin to understand the path, you can estimate that with the current means for you is realizable and what is not.
Remember the project triangle? Money, time, demands, and in the middle quality. This is what you manage in terms of tasks. You can ask for more resources, reduce the quality of tasks, throw out tasks, ask for more time.
Restrictions are an important indicator. They allow you to focus on reality and execute a project. They give definiteness, they gather people into a pile and give them the opportunity to do something. Without these frames, you will be like amorphous amoeba.
What is the power of limitations? They give control points. In fact, your task as a leader is to feel these limitations, to catch them, to look at them in terms of their importance and understanding of what can be done with them.

You discussed the tasks, discussed the stages ...

Act iteratively. For project management, many use the Agile methodology. Why did they take root so? In fact, they make it possible to bring together the leadership and subordinates, make the processes more transparent and give the opportunity to receive feedback.
Why is it important? You create a zone of trust, but do not lose control of the project. You give people the opportunity to choose things (solutions), but at the same time lower them tasks from above and watch out for the result.
The choice of methodology does not affect management. There are basic principles that exist in any production. Does not matter the industry, standards, people and stuff. These nuances, of course, change the appearance and make adjustments to the processes, but people are still people.

When is the formation of the department?

Formation of the department occurs as projects are implemented. Do not immediately describe in detail every millimeter of the path. So you will not do anything. Excessive planning drowns projects. Ideally, if the process is fixed and detailed, it is necessary if necessary. As you enter new people, you:
  • fixing arrangements;
  • fix and approve plans;
  • Establish job duties and regulations.
In my opinion, it is worthwhile to think about the formation of the department as the portfolio of projects grows. While you only have one project, you only need to pull it. You are still too weak to formalize processes and recruit people.
On the other hand, planning, regulations and job descriptions create a framework and allow for the recording of agreements. They make it possible to reduce the zone of confusion in the minds of people.

Matrix vs Hierarchy vs Agile

In my opinion, the organization of the structure depends on the context, the customer, the specifics of the product, but it does not change much. In our case (the Gett company) on the face is a combination. When there is a matrix in the hierarchical structure in which there is an agile of a team whose members are subordinate to the development manager who submits to the director.
It's like burning a fire - balance is important: too much wood - and you can not light a fire, it's not enough - the fire will quickly die out and give a little heat.
I proceed from the idea that it is better to lack and shortage. This gives a certain mobility and clarity. On the other hand, this approach deprives you of reserves that can be useful on a rainy day.

Stages of department growth: Employee.

While you are alone, maybe you do not need more documentation and everything else. You would have the project done. Ask people only in case of flooding with tasks. The lack of tasks is worse than their excess. When there are not enough tasks, productivity is lost, people begin to engage in nonsense. They believe that they are paid for doing nothing, and when work comes, it is difficult for them to return to their previous channels.
When to recruit people? My recipe is this: If you work more than 2-3 months - you need an assistant. When you work for 1-1.5 weeks, people should not be taken.

Stages of department growth: Team.

The team begins to form after 3-4 people. Then the leader is revealed. But remember that the more people, the more difficult it is to negotiate. What 2 people agreed for 1 hour, 3-4 people will agree 1-2 days. Contact is already lost, conflicts and misunderstandings arise. The more people, the less you will program and the more you will communicate.
When you have more than 6 people under you, you can forget about programming in general. Up to 6 people you most likely will not have the need for testers, designers, analysts. All this you will manage to do by the team.
At the stage of 6-7 people there is a need to formalize the processes, clarify the agreements, introduce regulations. Why is this necessary? Very simple. To protect the vocal cords. When you start telling the same thing from time to time, and people will ask the same questions - it means that it's time for regulations, and you need to start recording processes. Do not be afraid to make a mistake. You will be told immediately about the poorly developed processes.

Stages of department growth: Department.

The department is a structure in which there are more than 6-7 people. There may already be several teams in it. As you grow, there is a need to distribute work among people. Perhaps you want to make dedicated specializations.
These specializations will be needed when you have too many profile tasks, and you will need to allocate the resource to reduce the non-core load from the team: drawing the design, interface creeping, working out requirements, working with feedback from users.
You will need helpers in the leadership. Remember that effectively the leader manages 5-7 subordinates. If more people, he begins to lose focus of attention.

Life cycle of the team

In fact, we can distinguish five stages of the life cycle of the department:
  • Origin. Only the idea arose and the first person appeared.
  • Growth. The team is growing. The main thing here is not to stop the process. But do not give him too much growth.
  • Stability. The team is stabilizing. Be careful. You can lose the tempo. Team periodically need to throw in new Challenges.
  • Stagnation. Search for what you drag down. Change. Solve problems.
  • Dying. The command is bent. What to do? Update the command. Change the command or leave.

Management Position

It is important to remember that you, as a leader, are neither a friend, nor a brother, nor an enemy. You are a person who is higher, has resources and power.
Your position is to create conditions for the group to be able to move unhindered to the goal. All you have to do is identify problems, assess risks, make decisions, and facilitate them in a group.

Problems:

In my opinion, in the process of organizing the department the problems are as follows:

Loss of control

Loss of control is a normal situation. In fact, you can not control everyone. And as control grows, control is lost. It is important to organize a structure that will stabilize itself. With your participation of course. The more you control the structure, the weaker it becomes. Remember about 5-7 focuses of attention? That's the level and will be the performance of your organization, if you keep everything under control.

Informal leaders and opposition

...This is normal. Each team has its own chat room, where the dice are washed (first of all to you), there are always dissatisfied with you. There are always people who do not like something. If they start spoiling everything, then get rid of them by any legal and available means. With hayters, the question is subtle, if it does not destroy you, and you do not lose credibility - leave. This does not mean that you need to show cruelty and tyranny. It is important to be able to listen and hear them. When they are not pressed and listened to, they lose influence over the situation. And they can give valuable ideas for development that will allow you to achieve great success.

Riots

This is when your activity does not bring satisfaction, and the team is already ready or going against you. In fact, this is already a running version, and, perhaps, you will not do anything.
The very trap is the loss of the head in the process of work. And illusions are the worst thing. When you are wrong and there is a crisis, you face a tough reality, and, in fact, reality itself gives you feedback and limits you in choosing. Worse, when everything is going fine, or you think everything is going fine.
This is what leads to riots, not reaching the goal, losing influence. Because in this situation you do not really control anything.
It is very important at the same time not to forget about the main question: Am I not doing shit?

Assholes and psychopaths

These are people from whom you need to get rid of immediately. Usually they smile at you, and people behind you set people against you and abuse others.
Who are they?
It is necessary to distinguish simply people with a bad mood and habits from pathologically ill.
  • Assholes:
    • Maybe a person has a bad mood
  • People with pathologies:
    • Psychopaths - a pathological disruption of the brain
    • Sociopaths - antisocial worldview and behavior

What prevention can be:

  • It is necessary to find out the situation, analyze the connections between people, the mood in the team, the influence of the person on decisions and motivation
  • Track dismissals and loss of productivity
  • Carry out face-to-face bets, analyze.
  • Fix arrangements
  • Regularly monitor performance
  • Reduce emotional communication
  • Speak with the surrounding decisions
  • Do not be an asshole

Conclusions

  • Winners are not judged. Do not be afraid to make mistakes. If you succeed, you will be forgiven for your mistakes.
  • Work with management - these are those who give you resources, forgive your mistakes and give new projects.
  • Do not strive for empty power. Empty power is when you have opportunities, but there is no purpose. Such power is easy to lose.
  • Trust, but in case of problems, fix the arrangements. All changes must be recorded
  • The most terrible thing is the courts and labor inspections. Do not enter into a deal with a conscience - do not wash.
  • The department in the form in which you made it, will cease to exist after your departure - this is the norm. Do not make a monument out of him.
  • Work should not be the only joy in your life.

Literature

I want to advise you literature, that would develop the topic of the post:
  • Cognition in the wild - a book of the cognitive psychologist about how the administration of a military ship is organized (crew management, navigation, team psychology). It's no secret that software development is very similar to construction and shipping. Therefore, this book will help you understand the concepts.
  • Being geek is the book of the Netscape development manager, which passed from engineer to manager and describes this experience. The book tells different stages of growth (interview, communication with colleagues, etc.).
  • Jeffrey Pfeffer, Power, influence and politics in organizations is a very cool book about what management, politics, influence and power are. About how they are received, how they are lost and what to do about it.
  • Ethnogenesis and the Biosphere, Lev Gumilev - a book by a famous researcher is a story about how nations are organized. Who are passionate individuals, how the group develops, what stages of life it has and what they are connected with.
  • Snakes in Suites - a book about psychopaths and sociopaths in the work environment. About why they are many in modern companies and environments. About what they are dangerous, how to identify them, screen out and what to do if you work with one of them.
  • The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn't - a book about how to build relationships, about what dangerous assholes and unpleasant communication. What to do about it?

Tuesday, September 26, 2017

Организация отдела разработки с "нуля"

Видеозапись моего выступления:
Интернет версия слайдов моего доклада

Введение

На чем основан пост?

Свой пост я основываю более, чем на 10 летнем опыте организации различных видов деятельностей и групп:
  • Как преподаватель я организовывал деятельность студентов по достижению цели прохождение курса
  • Как бригадир бригады монтажников я организовывал деятельность по реконструкции сетей
  • Как заказчик я организовывал работу подрядчиков
  • Как руководитель отдела тестирования я занимался организацией работ по достижению необходимого уровня качества проектов в разработке
  • Сейчас как руководитель команды разработки я занимаюсь организацией работ по созданию проектов.
Я постарался сделать выжимку из своих наблюдений и сделанных на их основе выводах. Хочу предупредить: тема обширная и материалов написана куча, поэтому я вам расскажу ключевые вещи. Если у вас в результате возникнут противоречивые вопросы, сомнения и бурление - это хорошо. Задайте мне их по почте или через соцсети.

Определимся с понятиями

Для начала определимся с понятиями.
Организация — процесс, деятельность по созданию и совершенствованию взаимосвязей между частями и элементами с целью внесения упорядоченности в процессы и повышения их эффективности.
Не важно какая деятельность - принципы организации заложены одни и те же. Да, у каждой группы есть свои особенности (специфика деятельности, культура, способы реализации), которые руководитель учитывает, но суть организации как деятельности при этом не меняется.

Почему так сложно начать с нуля?

На устоявшемся проекте многое уже определено: сформированы процессы, установлены регламенты, наняты люди, созданы и от приоритезированы задачи. Мы уже находимся в процессе и учитываем обстоятельства.
На старте же вы начинаете с чистого листа. Глаза разбегаются, нужно столько всего сделать и неясно, с чего начать, на что поставить приоритеты, какие выбрать задачи. При этом на данном этапе от вас уже ждут результатов, а ничего еще не готово.

Первое облегчение:

На самом деле, при всех проблемах роста и развития, расти проще. Так как энергии тратиться меньше, чем при стабилизации и сохранении баланса. Но при этом есть высокая доля неизвестности и рисков.

Основная часть

С чего же мы начнем?

Для начала нам нужно понять, куда развиваться. Нужно четкое понимание цели, чтобы точнее знать, куда вы будете двигаться и как вы поймете, что вы идете в нужном направлении? Цель определяет критерии достижения.

Что следующее?

Чтобы определиться с целью, пообщайтесь с вашим руководителем и руководителями отделов, с которыми вы будете работать. Узнайте, что они от вас ожидают. Провалидируйте у своего руководителя эти ожидания.
Для навигации в пространстве, помимо ясного понимания цели, важно понимать, где вы сейчас находитесь. Какими средствами вы обладаете? Что у вас есть? Какой бюджет? Какие средства производства? Сколько людей есть? Какие сроки?

Как двигаться к цели?

Задачи и их выполнение - основной способ движения к цели. Как только вы начинаете понимать путь, вы можете оценить, что с текущими средствами для вас реализуемо, а что нет.
Помните проектный треугольник? Деньги, время, требования, а посередине качество. Это то чем вы управляете с точки зрения задач. Вы можете просить больше ресурсов, снижать качество задач, выбрасывать задачи, просить больше времени.
Ограничения - это важный показатель. Они позволяют сосредоточиться на реальности и выполнить проект. Они дают определенность, собирают людей в кучку и дают им возможность что-то сделать. Без этих рамок вы будете как аморфные амебы.
В чем сила ограничений? Они дают точки управления. По сути ваша задача, как руководителя, чувствовать эти ограничения, улавливать их, смотреть на них с точки зрения их важности и понимания того, что с ними можно сделать.

Вы обсудили задачи, обсудили этапы…

Действуйте итеративно. Для управления проектами многие используют Эджайл методологии. Почему они так прижились? По сути они позволяет сблизить руководство и подчиненных, делают процессы более прозрачными и дают возможность получать обратную связь.
Почему это важно? Вы создаете зону доверия, но при этом не теряете контроля над проектом. Вы даете возможность людям выбирать какие-то вещи (способы решения), но при этом спускаете им задачи сверху и следите за выдаваемым результатом.
Выбор методологии не влияет на управление. Есть базовые принципы, которые существуют в любом производстве. Не имеет значения отрасль, стандарты, люди и прочее. Эти нюансы, конечно, изменяют внешний вид и вносят корректировки в процессы, но люди-то остаются людьми.

Когда же происходит формирование отдела?

Формирование отдела происходит по мере реализации проектов. Не нужно сразу описывать подробно каждый миллиметр пути. Так вы ничего не сделаете. Чрезмерное планирование топит проекты. Идеально, если закрепление и детализация процессов происходит по необходимости. По мере ввода новых людей вы:
  • закрепляете договоренности;
  • фиксируете  и утверждаете планы;
  • Закрепляете должностные обязанности и регламенты.
На мой взгляд, задумываться о формировании отдела стоит по ходу роста портфеля проектов. Пока у вас только один проект, вам бы только его потянуть. Вы еще слишком слабы, чтобы формализовать процессы и набирать людей.
С другой стороны, планирование, регламенты и описание должностных инструкций создают рамки и позволяют фиксировать договоренности. Они дают возможность снизить зону неясности в головах у людей.

Матрица vs Иерархия vs Эджайл

На мой взгляд методика организации структуры зависит от контекста, заказчика, специфики продукта, но при этом не сильно что-то меняет. В нашем случае (компании Гетт) на лицо комбинация. Когда в иерархической структуре есть матрица в которой есть эджайл команды, члены которых подчиняются руководителю разработки, который подчиняется айти директору.
Это как с разжиганием огня - важен баланс: слишком много дров - и вы не сможете разжечь костер, недостаточно - костер быстро потухнет и даст мало жару.
Я исхожу из идеи, что лучше испытывать недостаток и нехватку. Это дает определенную мобильность и четкость. С другой стороны - этот подход лишает вас резервов, которые могут пригодиться в черный день.

Этапы роста отдела

Сотрудник.

Пока вы один, возможно вам и не нужно больше документации и всего остального. Вам бы проект сделать. Просите людей только в случае завала задачами.  Недостаток задач хуже, чем их избыток. Когда не хватает задач, теряется производительность, люди начинают заниматься ерундой. Считают, что им платят за ничего неделание, и когда приходит работа, им сложно вернуться в прежнее русло.
Когда набирать людей? Мой рецепт следующий: Если у вас работы больше, чем на 2-3 месяца - вам нужен помощник. Когда у вас работы на 1-1,5 недели, брать людей не стоит.

Команда

Команда начинает формироваться после 3-4 человек. Тогда выявляется лидер. Но помните, что чем больше людей, тем сложнее договориться. То, о чем 2 человека договаривались за 1 час, 3-4 человека будут договариваться 1-2 дня. Уже теряется контакт, возникают конфликты и недопонимание. Чем больше людей, тем меньше вы будете программировать и тем больше будете общаться.
Когда  под вами будет больше 6 человек, про программирование вообще можете забыть. До 6 человек у вас скорее всего не будет потребности в тестерах, дизайнерах, аналитиках. Все это вы будете успевать делать командой.
На этапе 6-7 человек уже возникает необходимость формализовать процессы, прояснять договоренности, вводить регламенты. Зачем это нужно? Очень просто. Чтобы беречь голосовые связки. Когда вы начнете рассказывать одну и ту же вещь из раза в раз, и люди будут задавать одни и те же вопросы, - это значит, что пришло время регламентов, и вам нужно начинать фиксировать процессы. Не бойтесь ошибиться. О плохо проработанных процессах вам скажут сразу.

Отдел

Отдел - это структура, в которой больше 6-7 человек. В нем уже может быть несколько команд. По мере роста возникает потребность распределять работу между людьми. Возможно вы захотите сделать выделенные специализации.
Эти специализации будут нужны, когда у вас будет слишком много профильных задач, и нужно будет выделить ресурс на то, чтобы снизить непрофильную нагрузку с команды: рисование дизайна, прокликивание интерфейса, проработка требований, работа с обратной связью от пользователей.
Вам потребуются помощники в руководстве. Помните, что эффективно руководитель управляет 5-7 подчиненными. Если людей больше, он начинает терять фокус внимания.

Департамент

Департамент состоит из 15 человек и более. В нем уже присутствуют 3-4 команды. Возникает потребность в архитекторах, команде эксплуатации.

Жизненный цикл команды:

По сути можно выделить пять этапов жизненного цикла отдела:
  1. Зарождение. Только возникла идея и появился первый человек.
  2. Рост. Команда растет. Тут главное не стопорить сильно процесс. Но и не давать ему слишком большого роста.
  3. Стабильность. Команда стабилизируется. Будьте осторожны. Вы можете потерять темп. Команде периодически нужно вбрасывать новые челленджи.
  4. Стагнация. Искать что вас тащит вниз. Изменяться. Решать проблемы.
  5. Умирание. Команда загибается. Что делать? Обновлять команду. Менять команду. Уходить.

Руководящая позиция

Важно помнить, что вы, как руководитель, - и не друг,и не брат,и не враг. Вы - человек, который находится выше, обладает ресурсами и властью.
Ваша позиция состоит в том, чтобы создавать условия для того, чтобы группа могла беспрепятственно двигаться к цели. Все, что вы должны делать, - это выявлять проблемы, оценивать риски, принимать решения, фасилитировать их в группе. Все.

Проблемы:

На мой взгляд, в процессе организации отдела проблемы следующие:

Потеря контроля

Потеря контроля - это нормальная ситуация. На самом деле, вы не можете контролировать каждого. А по мере роста контроль теряется. Важно организовать структуру, которая будет стабилизировать сама себя. С вашим участием конечно. Чем больше вы контролируете структуру, тем слабее она становится. Помните про 5-7 фокусов внимания? Вот на таком уровне и будет производительность вашей организации, если вы будете держать все под контролем.

Неформальные лидеры и оппозиция

- это нормально. В каждой команде есть свой чатик, где перемывают кости(в первую очередь вам), всегда есть недовольные вами. Всегда есть люди, которым что-то не нравится. Если начинают портить все, то избавляйтесь от них любыми законными и доступными средствами. С хейтерами вопрос тонкий, если это вас не разрушает, и вы не теряете авторитет, - оставляйте. Это не значит, что нужно проявлять жестокость и тиранию. Важно уметь их слушать и слышать. Когда их не прессуют и слушают, они теряют влияние над ситуацией. А еще они могут дать ценные идеи для развития, которые позволят вам достичь больших успехов.

Бунты

- это когда ваша деятельность не приносит удовлетворения, и команда уже готова или идет против вас. На самом деле, это уже запущенный вариант, и, возможно, вы уже ничего не сделаете.
Самая западня - это потеря головы в процессе работы. И иллюзии - это самое страшное.   Когда вы ошибаетесь и происходит кризис, вы сталкиваетесь с жесткой реальностью, и, по сути, реальность сама дает вам обратную связь и ограничивает вас в выборе. Хуже, когда все идет нормально, или вы думаете, что все идет нормально.
Это то что приводят к бунтам, не достижению цели, потери влияния. Потому что в этой ситуации вы точно ничем не управляете.
Очень важно при этом не забывать про главный вопрос: а не х**ню ли я делаю?

Мудаки и психопаты

- это люди от которых нужно избавляться сразу. Обычно они вам улыбаются в лицо, а за спиной настраивают против вас людей и абьюзят окружающих.
Кто они такие?
Стоит отличать просто людей с плохим настроением и привычками от патологически больных.
  • Мудаки:
    • Возможно у человека плохое настроение
  • Люди с патологиями:
    • Психопаты - патологическое нарушение работы мозга
    • Социопаты - антисоциальное мировоззрение и взгляды

Какая может быть профилактика:

  • Нужно выяснять обстановку,
  • анализировать связи между людьми, настроение в команде, влияние человека на решения и мотивацию
  • Отслеживать увольнения и потерю производительности
  • Проводить очные ставки, анализировать.
  • Фиксировать договоренности
  • Регулярно отслеживать производительность
  • Сократить эмоциональное общение
  • Проговаривать с окружающими решения
  • Самому не быть мудаком

Выводы

  • Победителей не судят. Не бойтесь ошибаться. Если вы достигните успеха, то вам простят ваши ошибки.
  • Работайте с руководством - это те, кто дают вам ресурсы, прощают ваши ошибки и дают новые проекты.
  • Не стремитесь к пустой власти. Пустая власть - это когда у вас есть возможности, но нет цели. Такую власть легко потерять.
  • Доверяйте, но в случае проблем фиксируйте договоренности. Все изменения должны быть зафиксированы
  • Самое страшное - это суды и трудовые инспекции. Не вступайте в сделку с совестью - не отмоетесь.
  • Отдел в том виде, в каком вы его сделали, прекратит существование после вашего ухода - это норма. Не делайте из него себе памятник.
  • Работа не должна быть единственной радостью в вашей жизни.

Литература

Хочу посоветовать вам литературу, что бы развить тему поста:
  • Cognition in the wild - книга когнитивного психолога о том как устроено управление военным судном (управление экипажем, навигация, психология команды). Не секрет, что разработка софта очень похожа на строительство и судоходство. Поэтому эта книга поможет вам разобраться с понятиями.
  • Being geek - книга руководителя разработки Netscape, который прошел от инженера до менеджера и описывает этот опыт. Книга рассказывает разные этапы роста (собеседования, общения с коллегами и прочее).
  • Джеффри Пфеффер, Власть, влияние и политика в организациях‎ - очень крутая книга о том что такое управление, политика, влияние и власть. О том как их получают, как их теряют и что с этим делать.
  • Тайна пассионарности, Льва Гумилева - книга известного исследователя история о том как устроены нации. Кто такие пассионарные личности, как развивается группа, какие у нее этапы жизни и с чем они связаны.
  • Snakes in Suites - книга о психопатах и социопатах в рабочей среде. О том почему их много в современных компаниях и айти среде. О том чем они опасны, как их выявлять, отсеивать и что делать, если вы работаете с одним из них.
  • Не работайте с мудаками - книга про то как строить взаимоотношения, о том чем опасны мудаки и неприятное общение. Что с этим делать?

Wednesday, June 22, 2016

Как вырастить в себе автоматизатора и прокачать в себе навыки разработчика.


Ссылка на презентацию

О проблеме:

Я пришел в айти в зрелом возрасте, у меня гуманитарное образование. До айти я полтора года преподавал студентам и школьникам.
Автоматизации я научился в процессе работы. Поэтому вопрос обучения мне знаком не по наслышке. Когда я пришел в банки.ру, я подумал, что смогу брать людей с непрофильным образованием и доводить их до нужной мне квалификации. Но увы я столкнулся с тем, что не все могут или хотят обучаться, что у людей есть объективные границы роста. Тогда я в первые задумался о том какие навыки нужны для развития и что именно требуется для достижения успеха в автоматизации.

Подготовка к докладу:

В ходе подготовки к докладу я понял, что недостаточно рассказать о своем опыте или об опыте своих подчиненных. Так как 6 человек - это маленькая выборка. Поэтому я сделал опрос из 30 общих и специализированных вопросов и опубликовал его через Гугл формс.
Я планировал получить данные от трех групп: тех кто не справился с обучением автоматизации, кто попробовал и его история закончилась успехом, а так же тех кто только планирует начать.
Результаты опроса я объединил со своими нараработками и сейчас я планирую вас с ними познакомить.

Кто такой автоматизатор тестирования:

Для начала давайте определимся с тем что входит в обязанности в инженера по автоматизации тестирования в сфере веб-разработки программного обеспечения.

Общее для всех типов автоматизаторов является:

  • Работа с системой контроля версий (например, Git)
  • Знание тестовых фреймворков (для php - Codeception)
  • Работа с IDE (например, Idea, PHPStorm, PyCharm)
  • Работа с данными:
    • Подготовка тестовых данных
    • Создание и обработка отчетов
    • Работа с логами
  • Организация кода
  • Описание архитектуры

DevOps практики:

  • Подключение и обновление компонентов
  • Непрерывная интеграция
    • Работа с xUnit
    • Сборка тестовой среды
    • Настройка CI:
      • создание и настройка планов
      • Автоматизированная сборка артефактов

Автоматизация фронтового тестирования:

  • Автоматизация бизнес логики;
  • Формирование локаторов.

Автоматизация бэкенд тестирования:

  • Тестирование базы:
    • Валидация данных
    • Тестирование производительности запросов
  • Тестирование запросами:
    • Валидация ответа через схему
    • Проверка скорости ответа
    • Проверка времени исполнения

Базовые требования для работы инженером по тестированию:

Какие требования к работе инженером по автоматизации? Для начала опишу какие личные качества и образование нужны для работы автоматизатором:

Личные качества

На основе опроса 31 человека были выявлены следующие личные качества успешного инженера по автоматизации:
  • Аналитический склад ума
  • Способность видеть систему в целом
  • Усидчивость.

Образование

Когда я посмотрел результаты опроса, то меня поразили две вещи:
  1. Среди успешных автоматизаторов ¼ людей - это люди без технического образования
  2. ⅓ людей с техническим образованием не смогли стать автоматизаторами.
Причин для этого могло быть несколько:
  • Прозанимавшись недостаточно долго они не получили ожидаемый результат и бросили обучение;
  • В процессе обучения они потеряли интерес к обучению автоматизации;
  • Возможно они низко оценили свои результаты и посчитали, что недостигли нужной им цели;
В результате я пришел к выводу, что техническое образование не является гарантированным критерием для успешного обучения.
При этом важно понимать, что фундаментальные знания существенно упрощают и ускоряют процесс обучения специалиста по автоматизации.

Какими навыками должен обладать инженер по автоматизированному тестированию?

Я разбил обучение автоматизации (на следующие уровни):

Новичок.

Начинать лучше с изучения следующих навыков:
  • Теоретические знания:
    • Понимание основ тестирования
    • Понимание предметной области
    • Булевая алгебра
    • Комбинаторика
    • Теория вероятности
    • Статистика
  • Практические знания:
    • Умение декомпозировать задачу
    • Английский (на уровне чтения документации)
    • Знание структуры веб-приложения и умение работать с запросами
  • Навыки работы с кодом:
    • Понимание языка локаторов (для тестов интерфейса)
    • Умение работать с IDE и понимание его достоинств и ограничений
    • Работа с системой контроля версий (commit, add, push, pull).
    • Умение запускать тесты локально
  • Программирование:
    • Знание основ языка программирования на котором происходит автоматизация: JS, Java, Python, PHP и bash/powershell.
    • Базовое владение языком (синтаксис, типы данных, основные операторы, исключения, логирование, input/output)
    • Владение процедурным программированием:
      • Линейная автоматизация тестового сценария с обработкой исключений и валидацией результатов
    • Понимание алгоритмов на начальном уровне

Продвинутый.

Когда вы достигли предидущей ступени вам стоит продолжить обучение в следующем направлении:
  • Теоретические знания:
    • Английский (на уровне письменного изложения своих мыслей)
    • Теория графов
  • Программирование:
    • ООП
    • Продвинутое понимание алгоритмов
    • Принципы организация кода (DRY, SOLID, KISS)
    • Понимание стандартов языка: PHP(PSR), Python (Pythonic, PEP8)
    • Работа с базой данных для генерации тестовых данных
  • Работа с окружением:
    • Знание основных тестовых фреймворков
    • Продвинутая работа с системой контроля версий. Знание таких команд как: merge, rebase, работа с ветками, пулл-реквесты.
    • Работа с CI:
      • Подключение тестов
      • Сбор результатов
      • Обновление пакетов
      • Оценка покрытия
      • Разница между средами (staging, test, production)
  • Практики разработки:
    • CodeReview
    • Рефакторинг
    • Использование методов статического анализа

Эксперт:

  • Практики разработки:
    • Проектирование
    • Разработка через прототип
  • CI:
    • Скрипты накатки
    • Деплой
  • Программирование:
    • Функциональное программирование
    • Оптимизация кода
    • Юнит-тесты
    • Расширение покрытия за счет доработки тестируемого приложения

Про разработку и автоматизацию:

Разница между экспертом в автоматизации и профессиональным разработчиком не так уж и велика. После того как вы изучите то, что я описал выше вы можете себя попробовать в разработке:
  • блога
  • мобильного приложения
  • разработка админки для базы данных
  • Интернет-магазине
  • Yet another bot for Telegram
Для тех кто хочет оценить себя как разработчика есть матрица компетенций разработчика:

Какие технологии изучать?

По результатам опроса наиболее популярные фреймворки:
  • TestComplete
  • Appium
  • Codeception
Драйверы:
  • Selenium WebDriver
  • Selenium


Что стоит изучать - вопрос открытый.
Корпоративные инструменты для тестирования автоматизируют большую часть работы и за счет простоты освоения пользователь теряет глубину понимания. Популярные фреймворки активнее развиваются, доступны и позволяют поднять уровень программирования.

Где можно получить эти знания?

Остается главный вопрос: откуда черпать все эти знания и где тренироваться?
Существуют два пути, которые лучше черодовать:

Теоретический:

  • Изучать синтаксис языка
  • Читать блоги
  • Читать книги (список литературы будет в конце доклада)
  • Читать мануалы
  • Изучать другие языки программирования

Практический:

  • Набиванием шишек или личным опытом
  • Выполнять простые упражнения
  • Участвовать в code review
  • Рекомендации опытных коллег
  • Сертификационные центры и сайты (список будет в конце)
  • Инструменты по статическому анализу кода
  • Состоязания (типа, hackerrank)

Что может помешать вам в ходе обучения?

  • Отсутствие положительной обратной связи долгое время может оттолкнуть вас от выбранного пути, но увы в начале вероятность таких ситуаций велика.
  • Не умение правильно планировать время:
    • Неверная оценка сложности задачи (например, сложный язык программирования)
    • Плохая декомпозиция задач
    • Плохая приоритезация
  • Плохая концентрация на задаче
  • Страх выглядеть глупым и неопытным
  • Отсутствие веры в себя и в свои способности
  • Нежелание отказаться от привычных моделей поведения (тестировать руками)

Как практиковать обучение и оценивать результат?

Разбивайте цель на проекты и задачи.

Задачи должны быть небольшими и занимать от 1 часа до 4. Таким образом за половину дня вы сможете сделать что-то завершенное и получить результат.
Очень важно фиксировать успехи и вести план.
Даже если вы будете вычеркивать из него по ⅓ в неделю - это вас подстегнет и вдохновит продолжить.
Так же это позволит вам в какой-то момент оглянуться назад и увидеть насколько большой путь вам удалось пройти.

Уделяйте процессу обучения время.

Очень важно заниматься обучением каждый день. Для фиксирования времени вам может помочь плагин wakatime для IDE. Он фиксирует время, проведенное в IDE и позволяет вам понять сколько времени вы уделили тому или иному проекту, языку или участку.

Вкладывайте деньги

В обучение, в покупку книг, инструментов, оплату средств разработки. Это замотивирует вас зарабатывать больше и покажет вашу замотивированность в росте работодателю. Что вы действительно готовы чем-то пожертвовать ради вашей цели.

В любом случае ваше обучение - это жертва.

Вам потребуется отказаться от чего-то ради обучения. Не важно что это будет: поход в кино, прогулка, ужин с друзьями, футбол или пивасик.

Сколько времени уходит на обучение?

Наименьшее количество времени на вход в автоматизацию занял у тех, кто изначально ограничил количество изучаемых областей (необходимыми), выделял на это время, силы и деньги.
При этом важно не забывать про человеческий фактор (IQ, умение сосредотачиваться, правильная организация обучения, декомпозиция и постановка цели, мотивация и умение выделять время).
Голые данные из опроса говорят о том, что:
  • Среди тех кто занимался меньше 3 трех часов в неделю в течении года и меньше было наибольшее количество неудач;
  • Более 50% успешных автоматизаторов потратили на обучение меньше года, но этом потратили на свое обучение минимум от 3 часов в неделю (78 часов за полгода) до 5 и более часов (от 130 часов за полгода).

Стоит ли рассчитывать на внешнюю помощь и как строить этот процесс?

Наставник не является гарантом успеха. А возможно в некоторых случаях он является помехой. Среди успешных автоматизаторов очень мало кто пользовался услугами ментора. Более того, среди ⅔ тех кто пытался обучиться и не смог были люди, кому помогали из вне.
Среди вашего окружения мало кто сможет нормально вам помочь не сделав за вас основную часть работы. При этом хорошо сделанная задача вашим коллегой научит вас гораздо меньшему, чем плохо сделанная своими руками задача. Умение правильно строить процесс обучения, ставить задачи по возрастающей - это отдельный навык.
Другими словами рассчитывать на помощь из вне не стоит. Это мешает вашей мотивации. Но это не означает, что стоит избегать советов, критики и ревью вашего кода. Такие вещи могут подстегнуть вас и направить по верному пути.

Заключение

Рекомендации:

  • Недостаточно просто хотеть стать автоматизатором, купить книжку, найти онлайн курс или подыскать наставника. Это все способствует вашему обучению, но не определяет его.
  • Недостаточно иметь подходящие личностные качества и знания.
  • Самое важное - это выделить время на то, что бы освоить этот навык, потратить на него время и силы, а затем начать внедрять его в жизнь. Понимать зачем это вам нужно и как вы это планируете в дальнейшем использовать.

Итоги:

  • Часть людей из тех, что оценили себя негативно - активно используют автоматизацию в работе и при этом на очень приличном уровне. Изучите эффект Даннинга-Крюгера;
  • Рядом с вами куча разработчиков, которые вам охотно помогут и немножко по-отечески потроллят;
  • Вдохновение - это дорогая и редкая вещь. Расчитывать на него не стоит;
  • Путешествие в 1000 миль начинается с первого шага.

Примечания:

Литература:

  • Новичок:
    • 57 задач для изучения разработки
  • Продвинутый:
    • Continuous Delivery. Martin Fowler
    • Искусство автономного тестирования с примерами на С#. Рой Ошероув
    • PHP. Объекты, шаблоны и методики программирования. Мэт Зандстра
  • Экспертный:
    • Совершенный код. Макконнел
    • Рефакторинг. Улучшение существующего кода. Фаулер.
    • Чистый код: создание, анализ и рефакторинг. Роберт К. Мартин

Курсы и сертификация:

Сертификация: (complete)

Ссылки: (complete)

Ссылка на опрос: http://goo.gl/forms/eVEJIOHXdf7HPlzN2