Топ за месяц!🔥
Книжки » Книги » Разная литература » Мама, я тимлид! Практические советы по руководству IT-командой - Марина Перескокова 📕 - Книга онлайн бесплатно

Книга Мама, я тимлид! Практические советы по руководству IT-командой - Марина Перескокова

33
0
На нашем литературном портале можно бесплатно читать книгу Мама, я тимлид! Практические советы по руководству IT-командой - Марина Перескокова полная версия. Жанр: Книги / Разная литература. Онлайн библиотека дает возможность прочитать весь текст произведения на мобильном телефоне или десктопе даже без регистрации и СМС подтверждения на нашем сайте онлайн книг knizki.com.

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 26 27 28 ... 40
Перейти на страницу:
Конец ознакомительного отрывкаКупить и скачать книгу

Ознакомительная версия. Доступно 8 страниц из 40

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

3

Когда и зачем вам нужны стажеры (и когда не нужны)

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

Один из руководителей, с которым я беседовала, поделился впечатлениями о ситуации, когда им резко понадобилось увеличить команду: «Мы писали код вчетвером, объем работы увеличивался, и нам нужно было вырастить команду в два-три раза. Мы быстро наняли четырех сотрудников, и я с грустью отмечал, что, если бы мы продолжали работать вчетвером, мы бы закрывали задачи быстрее, чем ввосьмером. Со временем мы перестроили процессы под большую команду, наняли еще людей, и производительность выросла. Но в первое время было довольно тоскливо».

Итак, случаи, когда ни в коем случае нельзя нанимать начинающих специалистов:

• Ваша команда зажата в жесткие сроки выполнения задач, и вы не можете позволить себе даже временное снижение производительности.

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

• Ваша команда делает сложный проект, и нет подходящих задач, на которых можно тренировать неопытных людей.

А теперь ситуации, когда взять стажеров будет полезно:

• У вас много несложных задач, и ваши опытные сотрудники сильно заскучали.

• В команде есть человек, который хотел бы стать руководителем, и ему нужно тренироваться управлять людьми.

• Имеется небольшой запас времени для выполнения проекта, и есть возможность обучать начинающего специалиста.

Теперь, когда мы прояснили условия для найма стажеров, зададим главный вопрос: зачем они вообще нужны? Действительно, совершенно непонятно, зачем заниматься «благотворительностью», не проще ли нанять опытных сотрудников, чтобы они сразу начали работать на всю катушку? У меня есть несколько мыслей по этому поводу.

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

Когда вы нанимаете человека на старте его карьеры, вы, как правило, получаете очень лояльного сотрудника. Для многих молодых людей первая работа превращается в некое подобие семьи. Начиная с низшей должности и постепенно вырастая, они «прикипают» к команде и компании и не особо стремятся искать новое место.

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

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

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

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

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

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

4

Bus factor и рассеивание зоны ответственности: все про всё vs узкая специализация

Многие знакомы с понятием bus factor[12] («фактор автобуса»). Оно означает количество участников проекта, после потери которых («попадания под автобус») вы не сможете завершить проект в срок. Это очень важный фактор, который надо учитывать при распределении задач. Значение bus factor, равное двум или трем, — неплохой показатель для команды. Если bus factor равен двум, то проект встанет при потере (например, одновременном уходе в отпуск) двух сотрудников, то есть временное отсутствие одного сотрудника мы сможем легко пережить.

Поддержание bus factor на должном уровне — задача, которой необходимо уделять внимание. Есть множество приемов, которые помогают сотрудникам делиться рабочей информацией: ревью выполненных задач коллегами, документирование работы, групповые обсуждения. Не буду останавливаться на методах, в каждом проекте они свои в зависимости от специфики задач и команды.

О чем мне действительно хочется поговорить — это о концепции «универсального солдата». Многие руководители пропагандируют идею, что при работе над проектом каждый сотрудник должен уметь выполнить любую задачу. Основные аргументы в защиту этой идеи таковы:

• Если ваши рабочие инструменты в порядке и вы документируете то, что делаете, любому сотруднику на проекте не составит труда доделать задачу за коллегу.

• Когда все могут делать всё, у вас нет незаменимых людей, вы можете безболезненно пережить увольнения или временное отсутствие

Ознакомительная версия. Доступно 8 страниц из 40

1 ... 26 27 28 ... 40
Перейти на страницу:

Внимание!

Сайт сохраняет куки вашего браузера. Вы сможете в любой момент сделать закладку и продолжить прочтение книги «Мама, я тимлид! Практические советы по руководству IT-командой - Марина Перескокова», после закрытия браузера.

Комментарии и отзывы (0) к книге "Мама, я тимлид! Практические советы по руководству IT-командой - Марина Перескокова"