На самом деле это очень крутая и удобная система управления проектами. Есть конкретный манифест, состоящий из 12 интересных принципов, а также 4 основных ценностей, которые, по-моему мнению, отвечают всем признакам адекватности. Естественно, как у любого бренда, у Agile есть своя история, которая берет свое начало на лыжном курорте The Lodge at Snowbird в горах Юты в феврале 2001 года, и бла бла бла…
Если Вы реально поверили в эффективность этой методики по отношению к коммерческому отделу, то лучше закрыть эту статью и дальше искать позитивные комментарии. Полки книжных магазинов полны книг про Agile. В них Вы узнаете всю необходимую теорию, но тут я хочу просто изложить свое мнение об Agile относительно управления коммерческим подразделением.
Начну со своего личного знакомства с Agile. Несмотря на то что я интересуюсь бизнес-литературой - эта модная тема как-то прошла мимо меня. Вот уже несколько лет она является популярной, но это загадочное слово из пяти букв я впервые увидел в начале сентября 2022 года в теме письма относительно планируемого двухдневного тренинга в Волгограде. Во-первых, я работал в подразделении, которое находилось в Омске, поэтому впереди меня ждала командировка, что не могло не радовать . Во-вторых, я естественно “загуглил” Agile, зашел на статью в википедии и с огромным интересом ее закрыл. Я, с одной стороны, был огорчен что мой пытливый ум прошел мимо потенциально интересного инструмента управления, но с другой стороны, я был счастлив наслаждаясь предвкушением структурированного обучения, поэтому принципиально не читал ничего по этой теме.
Тренинг проводился для руководителей Службы Телемаркетинга. На нем присутствовали топовые руководители групп (одним из которых был я), руководитель отдела телемаркетинга и руководитель всей нашей службы. Проводил его корпоративный тренер Светлана, которая сама разобралась в теме и попыталась ее адаптировать под наши реалии.
Забегая вперед, сразу обозначу 2 вводные:
1. Основной прикол Манифеста Agile заключается в том, что он не дает никаких практических советов. По сути тебе нужно самому додумать как это реализовать.
2. Все участники тренинга - руководители коммерческих подразделений.
И вот тренинг начался. Сначала мы обсудили 4 основных ценности. И чудо. Оказывается 99% присутствующих на тренинге интуитивно работали по Agile. Мы были абсолютно согласны с постулатами из разряда “работающий продукт важнее исчерпывающей документации” или “ люди и взаимодействие важнее процессов и инструментов”. Мы чувствовали себя победителями, потому что мы вписываемся в эту картину. Ну ладно, не буду говорить за других, я конкретно чувствовал себя победителем. Но потом мы перешли к принципам и сразу на первом мы конкретно застопорились. И после недолгих споров перешли ко второму, так и не разобравшись с первым. Первый принцип манифеста Agile звучит так: Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения. Если мы пытаемся адаптировать Agile под управление коммерческим подразделением, то давайте определимся с терминами. Кто тут является заказчиком и что является продуктом (вместо программного обеспечения).
Ну вот я допустим руководитель группы продаж. У меня в подчинении 15 сотрудников, которые ежедневно делают воронку продаж осуществляя холодные звонки. Их итог - продажи. Наш клиент - малый и средний предприниматель. Мы продаем услугу. Ну и?
Мнения разделились. Кто то начал рассуждать в рамках того что заказчик - это клиент. И Продукт - это услуга компании. Но у меня сразу же появился вопрос при чем тут я и мое подразделение? Я “топил” за то что Заказчик это мой руководитель, а продукт - это продажи которые делает мое подразделение. Казалось бы я нащупал вектор от которого можно отталкиваться, но дальше все пошло по одному известному женскому органу, потому что следующие принципы плавно приводили к тезисам о самостоятельности команд и бла бла бла… Картинка просто не сходилась в моем “менеджментоощущении”, это скорее было похоже на когнитивный диссонанс.
В конечном итоге тренинг был закончен, по моему мнению, в тупике. С одной стороны мы узнали структуру нового инструмента, с другой стороны мы не смогли идентифицировать отношение всех 12 принципов к нашей ежедневной текучке. Да даже если говорить о каком-то стратегическом управлении, это все равно было мозаикой, которую невозможно собрать. В этом контексте мне очень понравилась и запомнилась фраза руководителя службы телемаркетинга по окончанию тренинга. Дословно не помню, но постараюсь примерно процитировать:
“Цели и задачи любого тренинга для руководителей - дать общепринятую базу знаний, которую Вы сможете применить в нужный момент. Даже если сейчас Вам непонятно, как это применить, мы должны Вам дать эти знания, они Вам пригодятся рано или поздно, может быть даже в другой должности или компании”.
Тема модная, обсуждаемая. Корни ее уходят в IT сферу, но Российская публика почему-то искренне верит что сможет ее применить где-то за пределами разработки. Я долго думал и гадал, искал возможность ее применения, но никак у меня не получалось это сделать, до тех пор пока я ее не наложил на сферы, которые хотя бы немного, даже если очень тесно, связанные с разработкой.
В силу своего разностороннего опыта, я умею “писать” простенькие сайты, что-то вроде корпоративных порталов для того чтобы собрать в одном месте обучающие материалы для сотрудников. Также я за свою карьеру много раз внедрял с нуля CRM системы. И когда я попытался на эти сферы наложить Agile - у меня все сошлось. Победа! До меня искренне дошли принципа манифеста.
Во многих сферах специалисты часто “подшучивают” над заказчиком. Шутки скорее негативные, например дизайнеры нервно “угарают” по поводу бесконечных правок макетов. “Чем меньше заказчик шарит в дизайне, тем больше делает правок”.
В этом месте я искренне понял манифест разработчиков. Часто Вы договариваетесь заказчиком следующим образом: сделай мне что-то, что я не знаю что и я заплачу тебе X рублей. Как итог исполнитель делает бесконечное количество правок, продукт фактически все это время работает (если мы говорим о внедрении CRM системы например), но задача не приходит к итогу. Клиент не платит, потому что ты не сделал то чего обещал. И ты делаешь бесконечное количество правок бесплатно. К тому же часто заказчик очень трудно находит время на обсуждение проекта, а команда его сотрудников, привлеченных к внедрению чаще всего не мотивирована. Компании очень трудно привыкают к изменениям.
Наложив эту методику на что-то связанное с разработкой и постоянными изменениями я искренне прочувствовал Agile. Его придумали разработчики, которые устали от “шаромыжников”, которые не ценят труд и время разработчиков. Ну и естественно я понял что эта методология абсолютно бесполезна в управлении подразделениями и компаниями, которые никак не связаны с разработкой.
Если проанализировать топ вакансий на площадках по поиску работы, мы придем к выводу что самая распространенной из них в управлении является руководитель отдела продаж. После того как бренд Agile распиарили - именно они (в том числе я) побежали скупать книги по этому загадочному методу. В индустрии инфобизнеса появился новый повод благодаря которому вовремя подсуетившиеся специалисты заработали деньги. Даже я выбрал Agile первой темой к своему блогу, рассчитывая на частоту запросов в яндексе. Занавес.
В конце лишь добавлю несколько слов о Scrum и Kanban.
Эти два слова в общем и целом были знакомы им, просто без этих модных англицизмов.
Scrum - по теории этой методологии, это короткие пятнадцатиминутные собрания. Если говорить по существу - это планерки. Для линейного руководителя коммерческого подразделения это модное слово заменяется простым и знакомым инструментом. Только есть принципиальная разница, которая заключается в том, что команда разработчиков, как правило, одновременно работает над несколькими однотипными проектами, поэтому их логика заключается в том, чтобы каждый день взаимодействовать с заказчиками хотя бы по 15 минут. Поэтому они сокращают время собрания, но стараются запланировать их как можно больше. Если команда ведет, например 5 проектов, то они стараются каждый день закладывать 75 минут на Scrum собрания. А вот Российский руководитель отдела продаж ежедневно проводит от 1-2 планерки со своим подразделением, одна из которых обязательно большая (от 40 до 80 минут) в содержании которой есть все от разбора текучки до ситуационного обучения подразделения.
Kanban - это маршрут сделки или заявки. Смотря что делает твое подразделение. Конечно, по Agile это выглядит красиво, на магнитной или картонной доске, с многочисленными стикерами, но если называть вещи своими именами это этапы в CRM системе.
Мое мнение, естественно, не является истинной в последней инстанции, но оно имеет место быть, поэтому оставлю его здесь. Я рад знакомству с Agile, 12 принципов мне помогают додумать критерии по работе с заказчиком
в рамках внедрения CRM или написания сайта, но в управлении коммерческим или другим подразделением (не связанным с разработкой) она не несет никакой практической пользы.