Забудем на минуту про единорогов, бирюзовые компании, холакратию и прочие мифические концепции. Они, конечно, где-то есть, но не очень рядом. Представим себе традиционную организацию, имеющую ИТ-департамент, устроенный, как водится, в виде иерархии. Ничего необычного.
Часть этой иерархии – подразделение, где трудятся аналитики. Поймаем одного из них в коридоре и спросим: “Подскажи, дружище, на твой взгляд, чтобы всё в разработке ПО стало быстрее и качественнее, что нужно сделать?”. Во многих знакомых мне компаниях ответ будет примерно таким: “Известно что – разработчиков заменить на нормальных. Наши-то и бизнес не понимают, и код пишут так себе, а учиться и слушать никого не хотят…”.
Подойдём к разработчику с тем же вопросом. Его ответ будет отсылать нас с аналогичными претензиями к аналитикам, но ещё – к тестировщикам. Мол, не хватает у нас тестировщиков, а те, что есть, тестируют не всё, не всегда, медленно, и нас всё время дёргают, от работы отвлекают.
История повторится, если мы спросим тестировщиков. А через некоторое время, после недолгой беседы, к рассмотрению вопроса “где корень зла” подключатся и администраторы. Каждая группа будет кивать на соседнюю, впору рисовать любимую консультантами матрицу NxN:
| …про аналитиков | …про разработчиков | …про тестировщиков | …про администраторов | |
| Что думают аналитики… | Цвет айти и самые умные ребята | Так себе их код, и в бизнесе не понимают, вечно переспрашивают, надо всех заменить на нормальных | Лишнее звено, не нужно ничего тестировать, нужно сразу писать код правильно, а тестирование – это очень дорого | Это вообще кто? |
| Что думают разработчики… | Слишком много спеси, думают, что умнее бизнеса, а сами толком задачу описать не могут | Только мы одни делаем дело, остальные лишь бумажки перекладывают | Мало их, нужно больше, и чтоб сами всё делали, нас не трогали | Админы мешают нам разворачивать наш код, и ресурсов инфраструктурных от них не дождёшься, и конвейер нормальный сделать никак не могут |
| Что думают тестировщики… | Мы бы лучше тестировали, если бы они лучше описывали тест-кейсы, а они даже не пытаются | Всем давно известно, что программирование – это процесс внесения дефектов в исходный код | Если бы не мы, всё бы развалилось уже давно | Наши админы никак не поймут разницы между инцидентом и дефектом, всё сваливают на нас |
| Что думают администраторы… | Это вообще кто? | Разработчики не хотят разбираться, как именно работает их приложение на нашей инфраструктуре, даже схему простую нарисовать не могут | Так себе тестирование, если в среде эксплуатации постоянно дефекты вылезают | Разработка – даже не половина дела, всё держится на нас |
(приведённая выше таблица является собирательным образом, не отражающим какую-то конкретную компанию; все совпадения случайны, хотя перечисленные суждения попадаются с завидной регулярностью).
Понятно, что идеальное решение – отменить группировку ресурсов (простите за цинизм) по функциональному признаку и организовать вместо этого продуктовые команды: полнофункциональные, с совместной ответственностью, самоорганизующиеся и так далее. Такой подход не только полезен, он ещё и реализуем, примеры есть. Однако так же совершенно понятно, что одним пересаживанием по командам всех проблем не решить, уж больно много их накопилось за годы совместной работы.
Вопросы, на которые мне очень бы хотелось собрать побольше мнений:
- Насколько вы разделяете описанную точку зрения? Встречались ли с конфронтацией внутри ИТ-подразделения? Какие слова чаще всего слышите?
- Что нужно сделать, чтобы снизить градус недовольства коллегой и наладить спокойную работу в дружественной среде?
Пускай каждый проходит курс “молодого бойца” – пусть недельки две поработает в каждой роли, что бы было понимание, кто чем занимается.
И побольше вопросов вида: “Все ли понятно в моем ТЗ”, “Как сделать так, что бы тебе было удобнее тестировать и т.д.” и как можно меньше наездов друг на друга, следить в первую очередь за собой любимым (косячат все).