Организация работ

Поймите, что такое автобусный фактор, и забудьте о нем

1. Что такое бас-фактор (bus-factor)?

 Фактор автобуса — это количество человек, от присутствия на борту которых зависит успех вашего плавания.

 Скольким из вашей команды достаточно заболеть/уволиться/попасть под автобус, чтобы отгрузка не состоялась вовремя?

Пусть все ваши разработчики относительно взаимозаменяемы, но тест-кейсы всегда писала Маша, то bus-factor = 1.

Если только Коля способен решить проблему со смежной командой или только Дима общается с заказчиком, то bus-factor = 1. А вот если Дима и Коля в равной степени делают и то, и то, значит,теряя одного, вы не теряете проект. А если они оба заболеют? Стало быть, bus-factor = 2.

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

2. Как его увеличить?

Уже давно никто не может предложить альтернатив этим двум способам:

1) Уменьшение сложности

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

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

Поэтому заранее заготовленное описание подготовки тестовых данных и хотя бы ключевые сценарии будет весьма кстати.

2) Управление знаниями проекта

а) Фиксация и постоянная актуализация знаний — мало перспективно для маленьких команд, которых то и дело бросают между проектами. А если команду то и дело разбирают на части и собирают заново, то этот пункт совсем мимо кассы.

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

б) использование перекрёстного обучения и других методик управления знаниями

Мне не удалось встречаться с командами, практикующими хоть какие-то методики управления знаниями. Почему так, читайте в п.3

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

3. А надо ли его увеличивать?

Для меня это спорный вопрос. Когда я думаю об этом, в душе воюют наглый демон и самоотверженный ангел.

1) Демон говорит, что, создавая из кучки профессионалов команду, начальство должно подумать о составе. А то, что у начальства не хватает ни опыта, ни знаний это сделать, вообще-то не проблема разработчика/аналитика/тестировщика.

Почему мы, инженеры, можем позволить себе такой подход? Потому что управление людьми — это не основное наше преимущество на рынке.

Потому что в ИТ сложно доказать чью-либо вину, да и редко до поиска виноватых доходит дело. Если в самый ответственный момент проекта вас бросает ключевой человек, то да, виноват тим-лид… Но что он мог сделать? Так как никто заранее не просил тим-лида слать отчеты о текущем бас-факторе, не выделял время на развитие людей, не приводил в команду тренера, то и спросить с него нечего.

Если в команде одни разработчики (что редкость), вы еще можете сделать их кроссфункциональными. Подучить PLSQL человека, занимающегося css тоже реально, хотя и намного сложнее. Но далеко не всякий хороший разработчик настолько крут, что согласится общаться с заказчиком. И, если вы не Google, то даже не пытайтесь этого требовать. Почему? А он уйдет. И у вас будет на две проблемы больше (именно на две, так как написать требования к новому кандидату — та еще проблема)

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

 4. Что вы точно можете сделать

1. В команде должно быть минимум два экстраверта. Если в команде 8-10 человек — то три. В крупной компании накиньте еще парочку. Помните об этом, выбирая людей. Чем больше коммуникаций у команды с внешним миром, тем большее количество людей должно не бояться общения.

2. Напишите начальнику, что вам нужно либо время на обучение, либо люди. Маловероятно, что вам дадут хоть что-то, но письмо однозначно сделает вас победителем при разборе полетов.

3. Обучайте людей и просите их обучать друг друга. Говорите это так часто, чтобы это превратилось в мем. Пусть всех тошнит от фразы «делиться знаниями», но при этом каждый понимает, зачем это нужно. Проще всего говорить с людьми в терминах их выгоды: «Если ты захочешь в отпуск, а нам позвонит заказчик с просьбой поправить ТЗ, то мы позвоним тебе в Таиланд, так как никто больше не читал ТЗ и понятия не имеет где/ что надо теперь править».

4. Чаще отдыхайте и напоминайте об отдыхе другим. Людей у проекта обычно воруют вирусы.. и чужие HR-ы. И те, и те плохо размножаются, если человек счастлив и вовремя ходит в отпуск.

Автор: Гасраталиева Анна

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *