Agile курильщика. Ч1

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

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

Не буду сильно углубляться в терминологии Agile, тема появилась довольно давно, и на это были свои причины ее становления. Чтобы узнать больше – используйте поисковик. Всё, что вам нужно знать – Agile- гибкий метод разработки ПО, который транслируется сейчас не только на работы в области ИТ. На данный момент Agile продвигают в около государственном и корпоративном управлении. Насколько это эффективно или неэффективно, покажет только время, но есть некоторые вещи, которые можно отметить уже сейчас.

1. Agile в понимании госсектора и корпораций

Agile понимают по-разному, или не понимают вообще. Особых прений и саботажа со стороны работников нет. Исходя из собственной практики существует два лагеря сотрудников:

• Сотрудник делает вид и считает, что всё понимает в работе по принципу Agile,
• Сотрудник ничего не понимает и попадает под давление того, кто якобы всё понимает.

Почему это плохо:

1) Низкая мотивация к обучению.

Те, которые всё понимают, считают, что у них или нет на времени на обучение, или им это не нужно. Те сотрудники, которые попали под давление, или считают, что проще спросить у более опытного товарища по службе, или боятся, что их стремление к обучению подвергнет сомнению их профессиональные навыки.

2) Отсутствует проектная инициатива.

Сотрудники попросту бояться предложить иное. Во-первых, паровоз уже идёт. Во-вторых, отстаивать интересы своего отдела может (и будет) далеко не каждый руководитель. В-третьих, рядовой сотрудник, подойдя к своему начальнику, опять же берет на себя риски оказаться в глазах коллег некомпетентным.

2. Ответственность и управление. Люди и взаимодействие определяют требования к процессам и инструментам.

Ни того, ни другого, как видится, нет.

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

Задачи обычно транслируются устно, если в одно предложение – считай, то это уже хорошо, почти целое техническое задание.

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

Почему это плохо:

1) Деньги и время

Цикл разработки увеличивается, стоимость разработки увеличивается, загрузка сотрудников увеличивается, стоимость эксплуатации также не уменьшается.

2) Люди и деньги

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

Вовлеченность руководства (читай прямого заказчика и его функциональных подразделений) и ответственность руководства стремится к нулю.

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