Что такое agile трансформация
Что такое Agile-подход и зачем он нужен бизнесу?
В чем суть Agile с точки зрения здравого смысла и пользы для бизнеса? Давайте без применения специальных терминов разберёмся, что такое Agile, зачем он нужен, из чего состоит и какими инструментами добивается ключевых целей.
Agile («аджайл») — слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?
Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:
То есть, чтобы быть agile, надо уметь быстро и легко двигаться и быстро соображать. Кажется, довольно полезные качества, особенно в бизнесе. Быстро соображать и быстро реагировать — это именно то, что доктор прописал, для нашего времени, иначе просто не выжить: конкуренты сожрут. В мире всё меньше отраслей, где этих конкурентов, нет. Да ещё скорость копирования практически лишает возможности вывести продукт на рынок и почивать на лаврах. Без способности быстро адаптироваться к изменениям, которую даёт так называемая «методология Agile», выживать всё сложнее.
Я не случайно беру выражение «методология Agile» в кавычки, потому что его можно часто услышать, но оно не совсем верное. Если не вдаваться в технические детали, то Agile — это не методология, а собирательное название различных методик и подходов к управлению, которые:
Ничего сверхъестественного, не так ли? Давайте пройдемся по пунктам и разберемся, почему вышеперечисленное важно, для того чтобы быть быстрыми и гибкими, и какими средствами в Agile достигаются эти цели.
Фокусировка на нуждах и целях клиентов
Думаю, не стоит объяснять, почему успешнее тот бизнес, который удовлетворяет нужды своего клиента лучше конкурентов. Интереснее разобраться, какие инструменты в Agile помогают этого добиться.
Самое главное, что фокусировка на клиенте при Agile-подходе появляется не в одной только голове владельца бизнеса (она там и так уже есть), а у всех, кто работает над созданием продукта или сервиса. Каждый участник процесса должен понимать, кто клиент, чего он хочет, какие его проблемы мы решаем своим продуктом, что он любит, чего боится и так далее. Такая всеобщая фокусировка позволяет создавать на порядок более качественные решения. Я неоднократно сталкивался с ситуацией, когда люди, раньше отвечавшие за какой-то маленький кусочек работы, поняв цели клиента, начинали выдавать замечательные идеи, а люди, которые отвечают за разработку продукта, с удивлением за ними записывали. Или — как на групповых сессиях проработки продукта подобные идеи оттачиваются разными людьми и дополняют друг друга, из просто хороших превращаясь в отличные. И, конечно, как они потом реализуются.
«Инструменты работы» в данном случае — это непродолжительные по времени, но насыщенные сессии (встречи) всех участников работы или ключевого большинства, где происходит генерация и тестирование различных идей. Эти же встречи служат для выравнивания понимания и фокусировки: все участники встречи на выходе понимают, что они делают, зачем, и почему это важно для клиента. А демократичный формат воркшопа, в отличие от скучных презентаций, гарантирует большее включение и мотивацию всех участников.
Примеры подобных инструментов — Lean Canvas, Impact Mapping, User Story Mapping и другие принятые в Agile методы описания гипотез и процессов.
Упрощение оргструктуры и процессов
И чем больше организация, тем больше пользы от подобной простоты, потому что сложность имеет привычку расти экспоненциально, а Agile — это хороший способ победить эту сложность или, как минимум, сдерживать ее рост.
Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile — Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.
Работа короткими циклами
В мире Agile не принято запираться в мастерской на три года, чтобы точить там что-то интересное. Очень уж велик риск, потратить море сил и времени на то, что никому не нужно или устарело.
Чтобы подобного избежать, применяется так называемый итеративно-инкрементальный подход, когда:
В качестве самого простого примера такой рабочей модели можно представить себе стандартную для всех компьютеров программу «калькулятор», которая вначале позволяет только складывать два числа, потом мы добавляем туда вычитание, умножение, деление, трансцендентные числа, тригонометрические функции, — и так далее, в порядке частоты применения. В начале функционал невелик, но мы уже можем увидеть, как калькулятор выглядит, насколько удобно им пользоваться, и представить, как развивать его дальше. И, главное, часть клиентов (скажем, школьники начальных классов) уже могут начать им пользоваться.
Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, — это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.
Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или XP, плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.
Активное, системное использование обратной связи
Этот пункт, на мой взгляд, самый важный для любого процесса, так как позволяет со временем, опираясь на опыт, корректировать свою работу, удаляя из процесса и создаваемого продукта ошибки и потери и добавляя что-то полезное.
В любой области деятельности человечества, связанной с созданием чего-то нового, вы найдёте подобную работу через эксперимент. Ракетостроение, самолетостроение, фармацевтика, физика, медицина, строительство, психология, экономика — любая область деятельности начиналась с экспериментов и вдумчивой обработки обратной связи от них.
Agile предлагает системное использование такого подхода везде: в создании продукта (мы выпускаем его на рынок, или показываем заказчику, или проводим испытания и используем обратную связь для его коррекции), в построении процессов (периодически мы «останавливаем» работу и подвергаем анализу сам процесс, чтобы улучшить его, избавиться от потерь и проблем), даже в построении структуры организации и «тонкой» настройки взаимоотношений в командах.
Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.
Повышение полномочий сотрудников
Зачем давать больше полномочий, когда можно дать бумажку с инструкцией? Есть, как минимум, три причины это делать.
Во-первых, люди, занятые умственным трудом, не любят чувствовать себя мартышками (ну, или роботами), и отбирая у человека возможность принимать решения, мы отбираем у него сам по себе умственный труд. А это, безусловно, демотивирует.
Во-вторых, давая больше полномочий, мы даем больше ответственности, и люди вынуждены учиться принимать решения самостоятельно и, главное, нести за них ответственность. Это долго, сложно, но оно того стоит. Работа не остановится, если самоорганизованная команда столкнется с незнакомой, неизвестной ранее проблемой. Да и кто будет спорить, что на работе от зрелых и ответственных, взрослых людей больше пользы, чем от больших детей, неспособных думать самостоятельно?
В-третьих, это всё та же скорость. Если человек может сам, на своём месте, никого не спрашивая, решить какую-то проблему, это сокращает время принятия решений. Не надо больше отправлять вопрос «вверх» и ждать ответа от менеджмента. Это преимущество не так заметно, если у вас работает 3 человека, но если вас 30, или 300, или 3000… В больших организациях, построенных сугубо на иерархическом принятии решений, паралич воли может быть довольно частым явлением.
Популярные способы построения работы в Agile, особенно базирующиеся на фреймворке Scrum, предполагают систему самоорганизованных команд и поощряют лидерство на любых уровнях.
Гуманистический подход
Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?
Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий — можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников — придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать — с этим тоже вряд ли кто поспорит.
И, что приятно, если копнуть в тот же Скрам, то окажется, что все ключевые факторы мотивации работника умственного и/или творческого труда в него уже включены. В каждой итерации («спринте») мы ставим цель, которой хотим достичь; нам даётся возможность решать, как именно достигать цели; в конце мы смотрим, насколько мы стали лучше (или хуже) работать, чем раньше; видим людей, которые заинтересованы в продукте, и их эмоции от знакомства с ним. Особенно хорошо, если эти эмоции положительные.
Вывод такой: счастливые люди лучше работают, а Agile-технологии помогают наладить процесс, в котором люди чувствуют себя счастливее. И первый пункт манифеста как раз об этом: люди и то, как они общаются, важнее всего остального.
Agile — это не конечное состояние, а образ мышления и жизни
Этот пункт о том, что применение Agile в целом — путь, а не цель. Нельзя «внедрить» Agile и расслабиться. Если вы выбираете этот путь, у вас всегда будет что-то ещё, что можно сделать лучше, какой-то ещё вызов, которому надо ответить, какая-то ещё проблема, которую надо решить, ещё одна высота, которую надо покорить… Это движение бесконечно, потому что нет идеального процесса или продукта, развитие и конкуренция не останавливаются никогда, как никогда не прекращается борьба за выживание в природе.
И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile, работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, а работа будет приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.
На этом наше обзорное знакомство с принципами Agile заканчивается. Какие цели ставятся перед Agile в России и каких реальных результатов достигают компании, переходящие на гибкие методологии, можно узнать, познакомившись с отчётом ежегодного исследования ScrumTrek об использовании Agile в России.
Agile-трансформация: всё по-настоящему
Привет, хабровчане. В преддверии старта курса «Agile Project Manager», в создании которого принимал участие, делюсь основанной на собственном опыте статьёй.
Возможности и перспективы agile-трансформации обсуждаются сейчас очень широко, привлекая аудиторию от IT-аналитиков до менеджеров CxO-уровня. Известно несколько западных (пока) школ по достижению так называемого Enterprise Agility – это действительно интересно и даже модно. И как любой hype согласно методике Gartner, по ощущениям, данное направление неуклонно движется к «пику завышенных ожиданий», за которым видимо ждёт «пропасть разочарований» и только потом устойчивое «плато продуктивности».
Вот как это выглядит в общем случае:
Попробуем обобщить предварительные итоги такой трансформации по опыту двух совершенно разных компаний, крупнейших представителей своей отрасли, одними из первых на российском рынке ступивших на стезю полномасштабной agile-трансформации. Непосредственно лидируя отдельные направления в качестве бизнес-архитектора, отвечая за структурирование изменений и разработку целевой модели организации, я пришёл к весьма прагматичным и не совсем ожидаемым выводам, которым кратко поделюсь в данной статье.
Итак, представим, умудренные опытом руководители некой большой компании озабочены повышенными ожиданиями акционеров, ростом конкуренции, перераспределением выручки в пользу цифровых каналов и связанными с этим вызовами. Как всегда, ищутся способы увеличить производительность труда, усилить присутствие бренда на рынке и просто не потерять ставших более разборчивыми клиентов в условиях турбулентности. Прочитаны бизнес-бестселлеры, проведено много часов консультаций, принимается решение последовать актуальному тренду и начать (или ускорить) трансформацию модели управления. Кто-то говорит пора звать «большую четверку», которая всё объяснит, кто-то предлагает внедрять Scrum of Scrum или делать большую общую Kanban-доску…
Первое, с чего стоит начать
— ясное понимание цели, ради которой нам необходимо измениться: какую бизнес-модель компания видит для себя в перспективе и почему для её реализации не обойтись без перестройки организационной структуры для достижения принципиально иного уровня гибкости и осознанности в принятии решений. Это стратегический этап, как обычно в числе прочего характеризующийся оценкой своего положения и конкурентов, выбором ориентиров для сравнения и формированием сценариев будущего с оценкой глобальных преимуществ и потенциальных рисков.
Далее оказывается,
что agile-трансформация крупной компании, вопреки стереотипам, хоть и следует духу agile-манифеста, имеет мало отношения к тому, что общепринято называть agile-методологией. Гибкость зрелой организации начинается не с выделения продуктов и тем более не с определенных церемоний, а в первую очередь – со стратегии управления внутренними инвестициями, а также c совершенно конкретных мер по развитию корпоративной культуры.
Первое проявляется через способность делегировать принятие решений об инвестициях в развитие, перестраивая управление портфелем проектов в пользу децентрализации бюджетов. Одновременно развивается умение каскадировать стратегические цели, устанавливать KPI или OKR, сочетать подходы сверху-вниз и снизу-вверх. Интересны вызовы, например, для команды CFO, – потребность в демократизации финансово-экономического обоснования и последующей оценки эффективности бизнес-инициатив. Суть каскадирования примерно показана на рисунке:
Второе определяется повышением зрелости менеджмента компании — это критично, поскольку, если верить исследованиям, проведенным авторами книги «Лидер и племя», культура команды не сможет держаться выше культурного уровня её лидера (личные наблюдения с этим вполне согласуются). И в целом, необходимо создание условий для вовлеченности сотрудников и мотивации большинства ценить командные достижения выше личных – здесь важно не только обучение, но и ревизия системы компенсаций.
После этого логически следует проработка архитектуры компании, начиная с ключевых потоков создания ценности, приводящая к целевой организационной структуре с соответствующим перераспределением полномочий и бюджетов в сочетании с реформированием коллегиального управления на стратегическом уровне.
Наконец, всё вышесказанное надо запустить в жизнь, невзирая на политику и консерватизм, создавая сотрудникам безопасные условия для перехода.
И лишь на следующем этапе
мы приходим к выстраиванию собственно «кросс-командного» agile: фокусируемся сначала на запуске, потом на взаимодействии конкретных продуктовых команд, следуя рекомендациям LeSS или SAFe (отмечу, что новая версия 5.0 покрывает также большую часть перечисленного выше), либо создавая их производные, как делали мы. Команды можно запускать параллельно, и зачастую они сами принимают решение о своей готовности к применению Scrum, например. Они не всегда оказываются правы, но это точно не основная проблема. Главное не терять из виду фундаментальные основы, без которых трансформация рискует превратиться в игрушку для привлечения талантов.
Конечно, вы на верном пути, если внедряете культуру постоянных улучшений, проводите тренинги для команд, и безусловно стараетесь держать клиента в фокусе внимания. При этом, трансформация не может проводиться «кавалерийским наскоком» и требует внятного экономического обоснования и должной систематизации. Иначе руководство компании попадает в ловушку «видимости agile», когда энергичные заряженные позитивом митинги вселяют веру в успех и помогают переосмыслить мировоззрение (что уже хорошо), но не способствуют структурному подкрепленному надежными данными подходу к реформированию организации и результативному управлению ею в новых условиях. Умение системно и комплексно проводить agile-трансформацию компании с недавнего времени начали называть Structural Agility – это даёт возможность преодолеть инерцию и построить действительно гибкую клиенто-ориентированную, привлекательную для партнеров и инвесторов цифровую организацию, реализующую творческий потенциал своих сотрудников.
Основы Agile-трансформации
Хочу поделиться переводом краткой, но достаточно толковой шпаргалки по Agile-трансформации.
Чтобы достичь успеха в сегодняшней рыночной ситуации, компании должны быстро поставлять клиентам качественный инкремент продукта (product increment – «ощутимый результат работы одного спринта» (например, новая функция продукта, прототип приложения и т.д.) — te-st.ru/2017/07/04/12-terms-of-scrum).
Не менее важно быть гибкими и уметь реагировать на обратную связь, полученную от клиентов. Это означает переход к гибкой стратегии от преобладающего сейчас традиционного подхода к организации, управлению и финансированию работы.
У маленьких компаний Agile-трансформация, скорее всего, не вызовет затруднений, так как внедрение этой стратегии можно осуществить, просто собрав всех в одной комнате и договорившись между собой.
Однако в больших организациях со сложной структурой и тяжелой «наследственностью» в виде устаревшей технологической архитектуры трансформацию нужно тщательно спланировать и организовать, чтобы быть уверенными в том, что усилия и инвестиции, вложенные в процесс изменения, создадут ценность для бизнеса и действительно приведут к тому, что компания станет гибкой и легко адаптирующейся к изменениям.
Agile-трансформация – это работа по реорганизации компании, в результате которой она сможет работать по принципам Agile.
В чем смысл Agile-трансформации?
По большому счету, Agile-трансформация – это история о том, как создавать команды, формировать бэклог и регулярно поставлять инкременты протестированного и работоспособного программного обеспечения. В масштабе более крупной организации – это создание сети слабосвязанных команд, координация зависимостей, работа с негативными последствиями, быстрый вывод продукта на рынок, а также измерение пропускной способности команд, а не их производительности.
Смысл Agile-трансформации – как раз в устранении препятствий, которые мешают выполнению всех этих действий.
Стратегия трансформации
Отправной пункт Agile-трансформации – это понимание, где ваша компания находится в данный момент и куда вам нужно двигаться. Чтобы ответить на этот вопрос, необходимо разобраться с двумя понятиями.
Во-первых, следует учитывать ценностные установки вашей компании в контексте планирования. Что для вас более ценно – предсказуемость поставки или способность адаптироваться к изменениям? Для большинства компаний ценным является и то, и другое, и это приводит к негативным последствиям.
Чем более вы настраиваете систему на предсказуемость, тем сложнее ее изменить. И, наоборот, чем больше вы придаете системе адаптивности, тем она менее предсказуема.
Второе, о чем стоит серьезно подумать, — это в чем заключается ценность вашего продукта для клиента с точки зрения планирования. Стараетесь ли вы понять, что нужно вашему клиенту (мы называем это открытой экосистемой – emergent ecosystem), или же вы сосредоточены только на выполнении взятых на себя обязательств (мы называем это замкнутой экосистемой — convergent ecosystem)?
Наша система координат
Мы построили матрицу 2х2, четыре сектора которой помогут вам понять, где ваша компания находится сегодня и решить, в какую сторону вам нужно двигаться, чтобы получить те бизнес-выгоды, на которые вы нацелены.
Путь к адаптивно-открытой компании часто идет через сектор предсказуемости (predictability) и замкнутости (convergence), затем через адаптивно-замкнутый сектор (convergence-adaptability) и только потом достигает адаптивно-открытой части матрицы (adaptability — emergence).
Весь процесс строится вокруг образования команд, определения модели управления по принципам Agile, а также выбора и принятия в качестве отправной точки тех метрик, которые
важны для компании – они будут использоваться для измерения и отслеживания улучшений.
Ваша стратегия Agile-трансформации в конечном итоге будет зависеть от системы ценностей вашей компании и от системы ценностей ваших клиентов.
10 шагов к Agile-трансформации
Самое важное – это понять, как правильно планировать, чтобы трансформация обеспечила регулярные инкрементные поставки бизнес-ценности. Цель в том, чтобы изменить способ выполнения работы. Возможно, вы уже двигаетесь от практики «большого взрыва» – редких и крупных релизов – к регулярным и небольшим поставкам. Управление трансформацией нужно осуществлять точно так же.
Несмотря на то, что Agile-трансформация одной компании не похожа на другие, обычно все компании проходят следующие этапы:
Шаг 1. Сформируйте команду лидеров
Agile-трансформация потребует внедрения изменений во все элементы бизнеса, и поэтому будет нужна поддержка руководства. Удостоверьтесь в том, что топ-менеджеры с вами заодно и в курсе того, что будет происходить.
Шаг 2. Определите видение конечного состояния
Конечно же, нам нужно понимание того, куда мы идем, прежде чем начнем двигаться. Однако, будучи прагматиками, мы понимаем, что план будет претерпевать изменения, ведь он включает в себя рабочие гипотезы о структуре, управлении и метриках, которые мы будем постоянно дорабатывать в ходе трансформации. Существуют хорошо известные практики командообразования в крупных компаниях и координации этих команд для обеспечения их работоспособности.
Шаг 3. Нарисуйте дорожную карту трансформации
С какой команды, ресурса или группы начать трансформацию? Какое подразделение продолжит этот процесс? А кто его поддержит затем? Мы должны рассказать компании о том, что мы собираемся делать, сколько времени это займет, и что мы рассчитываем получить взамен вложенных инвестиций. Мы называем группы, которые проходят трансформацию, экспедициями, а промежуточные результаты, которых они достигают – базовыми лагерями (basecamps).
Шаг 4. Составьте гибкий план на 90 дней
Команда лидеров трансформации встречается для планирования, оценки успехов, корректировки плана в случае необходимости. Основная цель команды – иметь гибкий 90-дневный план и достаточно нестандартное представление о том, что будет происходить. 90-дневный план похож на гибкое планирование релизов или PI-планирование. В плане будут перечислены все процессы в компании, которые будут затронуты трансформацией в течение следующих 90 дней.
Шаг 5. Проводите промежуточную проверку результатов каждые 30 дней
Наподобие цикличности спринта, вам нужно периодически оценивать продвижение трансформации, проводить ретроспективы и корректировать процесс.
Шаг 6. Адаптируйтесь и учитесь
Пересмотрите видение конечного состояния, основываясь на том, как эволюционировало ваше понимание успеха в процессе Agile-трансформации.
Шаг 7. Связывайте свои действия с результатами
Основная причина, по которой вы начали процесс трансформации – это достижение лучших результатов в бизнесе. Мы начинаем оправдывать инвестиции, формируя гипотезы, проводя эксперименты, демонстрируя результаты и изменяя стратегию в зависимости от того, что мы узнали. С учетом того, что вы не будете заранее знать все ваши действия в ходе трансформации, ваша цель – правильно построить последовательность результатов, которых нужно достичь, а также удостовериться в том, что выполненные вами действия соответствуют тем результатам в бизнесе, которых вы хотите достичь.
Шаг 8. Связывайте результаты трансформации с бизнес-целями
Вам нужно отслеживать улучшения системы вплоть до ощутимых выгод для бизнеса, а также регулярно демонстрировать руководству положительную динамику основных бизнес-метрик. Основная цель – это визуализация явной и очевидной связи между вложенными деньгами и достигнутыми измеримыми результатами.
Шаг 9. Управляйте коммуникациями
Регулярные и прозрачные коммуникации по поводу успехов и трудностей, с которыми сталкиваются лидеры трансформации, создадут позитивную атмосферу и придадут вам энергии. Такие встречи часто проходят в формате общего собрания, круглого стола с руководством и других видов информационных встреч.
Шаг 10. Обеспечьте безопасность всех участников процесса
Расскажите всем участникам трансформации, какие выгоды они от нее получат и какое место займут в новой структуре компании. Обеспечьте прозрачность, ответственность и измеримый прогресс для каждого.
Дорожная карта Agile-трансформации
Для успешной трансформации большой и сложной компании абсолютно необходима дорожная карта Agile-трансформации. Подход «как-нибудь-разберетесь-на-ходу» тут просто не сработает. По нашему опыту, успешные трансформации проходят по вот такой дорожной карте:
С чего начать: сформируйте видение конечного состояния
На начальном этапе необходимо посмотреть на вашу компанию в целом и определить бизнес-цели трансформации. Видение конечного состояния определит сценарий формирования команд, последовательность действий, обусловит модель управления, а также создаст метрики и стратегический инструментарий для определения базового уровня производительности и измерения улучшений.
В итоге компания подготовит первую экспедицию и запустит пилотный проект, который поможет определить базовые лагеря, необходимые для реализации изменений.
Трансформация начинается: пилотный проект и запуск
Эта фаза включает в себя формирование, подготовку и обучение команд – эффективно продвигающихся вперед экспедиций, которые постоянно прогрессируют, переходя от одного базового лагеря к другому. По мере созревания команд достигается конечное состояние, собираются базовые метрики, регулярно измеряются улучшения, и открыто распространяется информация о них.
Поддержание непрерывности изменений
На этом этапе структура, управление и метрики начнут консолидироваться в единое целое, и в компании начнет формироваться внутренний набор лучших практик. В течение этого периода и по мере продвижения процесса трансформации централизованное документирование этих практик станет бесценным для вашей компании. Вам нужно будет создавать обучающие и информационные материалы, «шпаргалки» по процессу трансформации. Также будет полезно разработать методы и стратегии адаптации коучей внутри компании, регулярно проводить организационную аттестацию и работу с негативными последствиями.
Автор: Тим Зак, прирожденный айтишник, уже более 10 лет решает маркетинговые задачи с помощью технологий. Компетенции Тима охватывают стратегическое планирование, UX, аналитику, автоматизацию маркетинга, контент-маркетинг и поисковый маркетинг. Одним из его преимуществ является опыт работы в различных отраслях.