Недавно мне посчастливилось начать работу с одной относительно немаленькой компанией (~100 человек), где, как выразился наниматель, “по-отдельности все хорошие специалисты, а вместе работать не получается”. Ну, думаю, я как раз специализируюсь на создании команд, дай, думаю, помогу чем смогу. Пообщались на собеседовании на тему общего понимания цели компании, об условиях, в которых возможна успешная совместная работа, о максимальном использовании компетенций сотрудников и о вовлечении в общее дело. Казалось бы, мысли у нас с нанимателем сходятся, но сам держу ухо востро — знаю о негативной репутации компании у потенциальных соискателей в городе. Ну что же, тем интереснее будет задача!
Сбор информации
В компании уже пробовали внедрять scrum, по-началу он заработал, но потом что-то пошло не так и он сошел на нет. В итоге вернулись к иерархии вроде такой: руководитель направления, замы руководителя, руководители групп тестирования, разработки и аналитики с ручной раздачей задач и узкой ответственностью каждого сотрудника.
Первым делом, естественно, требовалось провести диагностику — почему собственно не сработал scrum. Выбрал два способа диагностики: опрос и исследование через незначительное изменение.
Опрос показал разделение людей на неравные группы:
- На небольшую часть сотрудников давил сильный негативный осадок. Они выражали крайнюю степень негатива по отношению к руководству и друг к другу.
- Примерно треть просто не верила руководству и в то, что что-то можно изменить. За время их работы в компании они уже пережили пару авралов и не видели от руководства мер, которые помогли бы избежать аврала в будущем.
- Треть не видела проблем, удивлялась, когда я говорил, что они сидят в одном кабинете, с людьми, которые видят БОЛЬШИЕ проблемы.
- И остальные — студенты. Они не знали, что такое хорошо и что такое плохо и потому просто как-то работали.
- Еще было пара человек, которые относились к работе вполне позитивно, активно и с азартом выполняли возложенные на них обязанности.
Исследование через незначительное изменение
Суть исследования сводится к тому, чтобы потыкать и посмотреть на реакцию.
Под удар попало в основном незначительное улучшение быта: кухня, стартовый набор новичка, кружки с корпоративной символикой, наушники, витаминки, канцелярия. Данные изменения обосновывались руководству необходимостью работать над корпоративной культурой: поднимать репутацию компании в городе и поднимать лояльность сотрудников с помощью проявления заботы. «Потыкивания»намеренно выставлялась напоказ для того чтобы вызвать более интенсивную реакцию как руководящей верхушки так и рядовых участников.
В процессе внедрения незначительных изменений столкнулся с интересными фактами:
- Инертностью конкретных должностных лиц — даже после достижения договоренности по своей воле мало кто что-то сделал, всех приходилось активно педалировать.
- Некоторые должностные лица отнеслись к внедряемым изменения откровенно негативно — хотя при разговоре лицом к лицу или согласно кивали или просто молчали.
- Некоторые незначительные изменения вроде витаминок должен был утверждать лично он Сам.
- Некоторые рядовые сотрудники восприняли мои инициативы положительно, некоторые остро негативно.
- Некоторые рядовые и не только сотрудники донесли до меня, что предлагали то же самое что и я, но были, по меньшей мере, проигнорированы.
Предварительные выводы
В ходе исследований я понял, что проблемы подразделения, куда меня занесло, находятся вовсе не в подразделении, а в во всей компании целиком — в бухгалтерии, в хозяйственной части, в высшем руководстве, в рядовых сотрудниках. Проблема просто ровным слоем распределена по всей компании. Тогда я понял, что копать нужно в сторону такой вездесущей субстанции как корпоративная культура. Я попытался формализовать проявление корпоративной культуры и ее суть как советовал Эдгар Шейн. Я постарался описать артефакты (внешние проявления) корпоративной культуры, заявляемые ценности и докопаться до базовых представлений участников компании. Т.к. это был мой первый анализ корпоративной культуры, прошу отнестись к его результатам снисходительно.
Артефакты:
- Мы это пробовали, это не работает — частый ответ на предложения и инициативы.
- Одни правила работы с jira и git для всех подразделений.
- Личное участие в согласовании витаминок и наушников его Самого.
- Запрет распространения негативной информации.
- Нет свободной информации о должностях.
- Отсутствие взаимопомощи.
- Отсутствие инициативы от сотрудников за редким исключением.
- Жесткий график работы.
- Перегруженность руководителей.
Провозглашенные ценности:
- Самое главное — клиент.
- Подчинение.
- Регламент.
- Стандартизация.
Базовые представления:
- Человека легко заменить.
- Люди не хотят работать по своей воле.
- Быт не влияет на производство.
- Сила организации заключается в её регламентах.
- Принимают решения только руководители.
- Сотрудники некомпетентны.
А был ли scrum?
Изображение ниже иллюстрирует моё отношение к внедрению scrum в описанном выше контексте.
Недавно наткнулся на подборку разного рода манифестов, связанных с разработкой ПО. Тогда, посмотрев их все, я утвердился во мнении, что основой любого agile фреймворка является максимальное использование компетенций каждого сотрудника. Тут надо сделать небольшое отступление, чтобы мы все одинаково представляли себе agile. Agile это не только способ управления задачами и требованиями и его суть не в итерациях. Его суть в непрерывной адаптации всего ко всему: требования, коммуникации, инструменты, процессы и т.д., — не даром где-то рядом с термином «agile» стоит термин «самоорганизующаяся команда». Так вот достичь непрерывной адаптации можно только в особых условиях, с особыми отношениями в коллективе:
- Инициативы важны и приветствуются.
- Проблемы отдельного человека — проблемы всей команды.
- Эксперименты всячески поддерживаются.
- Ошибки неизбежны. Мало того, они полезны т.к. с их помощью команда приобретает опыт. Быстро ошибаемся, быстро учимся, быстро улучшаемся.
- Профессиональные цели каждого человека известны и учитываются.
- Доверие лежит в основе отношений в коллективе.
- Свободное выражение мнения.
- Психологическая безопасность (по мнению google это основной фактор успешности проектов и команд).
Agile возможен только в условиях, где каждый человек важен. Если это не так, то даже применив все практики scrum, ты получишь всего лишь инструмент управления задачами, но это не будет agile. Agile не подразумевает какую-то определенную статическую структуру или замороженные процессы, нет, ни в коем случае. Если вдруг ты с радостью обнаруживаешь, что изобрёл идеальные процессы и структуру компании — не пройдет и пяти лет как вам пора будет на свалку. Естественно, речь идет только о разработке ПО, на заводах актуальность процессов теряется значительно медленнее (это предположение). Agile это состояние группы, в котором она постоянно меняется для адаптации к постоянно изменяющимся условиям. Состояние agile заключается в понимании, что как только вы остановились в развитии и перестали экспериментировать, то сразу начинаете становиться неактуальным и не за горами тот день, когда ваша компания развалится.
А теперь вернемся к изучаемой компании. Как только тебе отказали два раза без внятного, на твой взгляд, объяснения причин, как только на тебя пару раз повысили голос, как только тебя оставили один на один с твоими рабочими проблемами и не помогли в критической ситуации — ни о каком agile больше речи не идет. Ведь вы больше не станете открыто говорить о проблемах (потому что проблемой являются люди, которые вас спрашивают о проблемах), вы не станете проявлять инициативу (вы уже попытались, но были, как минимум, проигнорированы), вы не поможете своему коллеге (ведь он не помог вам), и больше ни о каком развитии компании или отдельной команды уже не может идти речи. Увы — вы уже плохо пахнете и местами покрылись трупными пятнами.
Так что… применяя scrum, не забывайте об agile!
Автор: Владимир Ряшенцев
