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

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

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

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

4

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

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

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

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

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

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

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

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

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

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

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

5

Наращивание команды: если возможно, двигаемся постепенно

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