- PVSM.RU - https://www.pvsm.ru -
Недавно мне посчастливилось начать работу с одной относительно немаленькой компанией (~100 человек), где, как выразился наниматель, “по-отдельности все хорошие специалисты, а вместе работать не получается”. Ну, думаю, я как раз специализируюсь на создании команд, дай, думаю, помогу чем смогу. Пообщались на собеседовании на тему общего понимания цели компании, об условиях, в которых возможна успешная совместная работа, о максимальном использовании компетенций сотрудников и о вовлечении в общее дело. Казалось бы, мысли у нас с нанимателем сходятся, но сам держу ухо востро — знаю о негативной репутации компании у потенциальных соискателей в городе. Ну что же, тем интереснее будет задача!
В компании уже пробовали внедрять scrum, по-началу он заработал, но потом что-то пошло не так и он сошел на нет. В итоге вернулись к иерархии вроде такой: руководитель направления, замы руководителя, руководители групп тестирования, разработки и аналитики с ручной раздачей задач и узкой ответственностью каждого сотрудника.
Первым делом, естественно, требовалось провести диагностику — почему собственно не сработал scrum. Выбрал два способа диагностики: опрос и исследование через незначительное изменение.
Опрос показал разделение людей на неравные группы:
Суть исследования сводится к тому, чтобы потыкать и посмотреть на реакцию.
Под удар попало в основном незначительное улучшение быта: кухня, стартовый набор новичка, кружки с корпоративной символикой, наушники, витаминки, канцелярия. Данные изменения обосновывались руководству необходимостью работать над корпоративной культурой: поднимать репутацию компании в городе и поднимать лояльность сотрудников с помощью проявления заботы. «Потыкивания»намеренно выставлялась напоказ для того чтобы вызвать более интенсивную реакцию как руководящей верхушки так и рядовых участников.
В процессе внедрения незначительных изменений столкнулся с интересными фактами:
В ходе исследований я понял, что проблемы подразделения, куда меня занесло, находятся вовсе не в подразделении, а в во всей компании целиком — в бухгалтерии, в хозяйственной части, в высшем руководстве, в рядовых сотрудниках. Проблема просто ровным слоем распределена по всей компании. Тогда я понял, что копать нужно в сторону такой вездесущей субстанции как корпоративная культура. Я попытался формализовать проявление корпоративной культуры и ее суть как советовал Эдгар Шейн. Я постарался описать артефакты (внешние проявления) корпоративной культуры, заявляемые ценности и докопаться до базовых представлений участников компании. Т.к. это был мой первый анализ корпоративной культуры, прошу отнестись к его результатам снисходительно.
Артефакты:
Провозглашенные ценности:
Базовые представления:
Изображение ниже иллюстрирует моё отношение к внедрению scrum в описанном выше контексте.
Недавно наткнулся на подборку разного рода манифестов [1], связанных с разработкой ПО. Тогда, посмотрев их все, я утвердился во мнении, что основой любого agile фреймворка является максимальное использование компетенций каждого сотрудника. Тут надо сделать небольшое отступление, чтобы мы все одинаково представляли себе agile. Agile это не только способ управления задачами и требованиями и его суть не в итерациях. Его суть в непрерывной адаптации всего ко всему: требования, коммуникации, инструменты, процессы и т.д., — не даром где-то рядом с термином «agile» стоит термин «самоорганизующаяся команда». Так вот достичь непрерывной адаптации можно только в особых условиях, с особыми отношениями в коллективе:
Agile возможен только в условиях, где каждый человек важен. Если это не так, то даже применив все практики scrum, ты получишь всего лишь инструмент управления задачами, но это не будет agile. Agile не подразумевает какую-то определенную статическую структуру или замороженные процессы, нет, ни в коем случае. Если вдруг ты с радостью обнаруживаешь, что изобрёл идеальные процессы и структуру компании — не пройдет и пяти лет как вам пора будет на свалку. Естественно, речь идет только о разработке ПО, на заводах актуальность процессов теряется значительно медленнее (это предположение). Agile это состояние группы, в котором она постоянно меняется для адаптации к постоянно изменяющимся условиям. Состояние agile заключается в понимании, что как только вы остановились в развитии и перестали экспериментировать, то сразу начинаете становиться неактуальным и не за горами тот день, когда ваша компания развалится.
А теперь вернемся к изучаемой компании. Как только тебе отказали два раза без внятного, на твой взгляд, объяснения причин, как только на тебя пару раз повысили голос, как только тебя оставили один на один с твоими рабочими проблемами и не помогли в критической ситуации — ни о каком agile больше речи не идет. Ведь вы больше не станете открыто говорить о проблемах (потому что проблемой являются люди, которые вас спрашивают о проблемах), вы не станете проявлять инициативу (вы уже попытались, но были, как минимум, проигнорированы), вы не поможете своему коллеге (ведь он не помог вам), и больше ни о каком развитии компании или отдельной команды уже не может идти речи. Увы — вы уже плохо пахнете и местами покрылись трупными пятнами.
Так что… применяя scrum, не забывайте об agile!
Автор: Владимир Ряшенцев
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/270848
Ссылки в тексте:
[1] подборку разного рода манифестов: https://habrahabr.ru/post/193232/
[2] Источник: https://habrahabr.ru/post/344444/?utm_source=habrahabr&utm_medium=rss&utm_campaign=344444
Нажмите здесь для печати.