Русский
Русский
English
Статистика
Реклама

Управление изменениями

Практики работы с требованиями

24.03.2021 12:04:07 | Автор: admin
image

Возможно, прочитав эту статью, вы поймаете себе на мысли, что я пишу о банальных вещах, которые всем известны. Но за 10 лет я сменила всего лишь 3 IT-компании, в двух из которых эти банальные практики не использовались в полной мере, от этого процесс разработки ПО сильно страдал. Помимо моего личного опыта, на написание статьи меня подвигли рассказы знакомых аналитиков, которые работают в сфере IT и практически все сталкиваются с проблемами организационного и коммуникационного характера, которые нужно и можно решать.

Последние 3 года я работаю системным аналитиком в группе компаний InfoWatch и в этой статье я хочу поделиться с вами практиками работы с требованиями, которые мы используем. Компания занимается разработкой Enterprise-продуктов для снижения рисков информационной безопасности, защиты и анализа корпоративных данных. К таким продуктам выдвигаются высокие требования, касающиеся их надёжности, производительности, отказоустойчивости, а так же требования для сертификации. В силу особенностей рынка информационной безопасности наши решения не являются облачными, а устанавливаются on-site у клиента. Поэтому мы работаем в режиме выпуска больших релизов несколько раз в год. Чтобы прийти к назначенной цели и сократить сроки релиза, мы работаем по принципам, заложенным в методологии Agile. Для старта разработки мы не готовим абсолютно детальные системные требования, а начинаем с высокоуровневого описания самых важных аспектов новой функциональности. То есть, принимаем решения, которые больше всего влияют на объем и сложность доработок и дают команде разработки необходимую информацию для старта работ по проектированию архитектуры и написанию кода (для небольших фич). Затем, по ходу разработки, постепенно детализируем требования и доводим их до уровня детализации, достаточного для написания подробных тест-кейсов. Такой подход позволяет не тратить много времени на старт работ и снизить риски того, что требования придется значительно перерабатывать, если выявятся какие-то новые технические ограничения.

Если ваш процесс разработки схож с нашим, или вы хотите перейти к такому комбинированному процессу, скорее всего, вам подойдут описанные ниже практики. Но даже если у вас другой процесс, есть вероятность, что представленные практики окажутся для вас полезными. В любом случае, предлагаю вам ознакомиться с ними, особенно, если вы работаете системным аналитиком в IT-компании.

Требования к разрабатываемому продукту основная зона ответственности системного аналитика. Практики, описанные ниже, направлены на упрощение работы с требованиями и, как следствие, на упрощение процесса разработки продукта:

  • документирование и версионирование;
  • оповещение об изменениях;
  • ревью;
  • митинги/собрания/статусы;
  • обсуждение/решение открытых вопросов;
  • протоколирование обсуждений;
  • валидация нового функционала;
  • презентация нового функционала.

Документирование и версионирование требований


image

Удобно, когда описание продукта в виде функциональных и нефункциональных требований зафиксировано в одном документе, требования разбиты по функциональным областям, взаимосвязаны группировкой, переходами через ссылки и т.п. Когда любые изменения в рамках описания фич или по результатам исправления дефектов находят свое отражение в соответствующей версии требований.

Версионирование требований такое же, как и у самого продукта позволяет видеть прирост функционала с каждым новым релизом. А также получить быстрый доступ к информации о том, как эта функциональность работала в предыдущих версиях и по каким причинам была изменена.

В некоторых компаниях для получения такой информации необходимо потратить много времени, так как нужно пересмотреть все задачи, которые связаны с той или иной функциональностью, вникнуть в их описание, просмотреть комментарии. Кстати, более быстрый способ получить нужную информацию попросить разработчика посмотреть изменения в коде, но в этом случае потребуется не только ваше время, но и время разработчика, что обойдется дороже вашему работодателю. Описание требований в одном месте позволяет не только найти интересующую информацию, но и сразу понять контекст.

Мы используем Confluence это удобный инструмент, который можно немного подкрутить под себя. О нашем опыте использования Confluence подробно рассказывает мой коллега в своей статье Как мы используем Confluence для разработки требований к продукту. Интересно то, что у многих IT-компаний этот инструмент есть, но не все используют его для документирования требований к продукту.

Оповещение об изменениях в требованиях


image

Оповещение всех заинтересованных лиц о внесении изменений в требования хорошая практика, которая так же позволяет мониторить, когда и по какой причине требования были изменены. Если выше я говорила о том, что важно отражать в требованиях все изменения по результатам исправления дефектов, то здесь речь идет об оповещении команды об этих изменениях.

Важно понимать, что требования это те данные, которые для своей работы используют команды разработки, тестирования, технических писателей и что любые изменения в требованиях необходимо поддержать в реализации, тест-кейсах и документации.

Если не оповестить об изменениях вовлеченные команды, скорее всего, придется столкнуться со следующими проблемами:

  • реализация может не соответствовать требованиям;
  • ожидаемый результат тестирования может не соответствовать требованиям и реализации;
  • документация может не соответствовать реализации.

До недавнего времени наша команда аналитиков оповещала всех заинтересованных об изменениях в требованиях следующим образом: после внесения изменений в требования, оставляли комментарий к задаче, отправляли письмо, которое содержит ссылку на задачу, ссылку на требования и краткое описание изменений. В конце прошлого года мы автоматизировали этот процесс: доработали issue-tracker (используем JIRA) и теперь после внесения изменений в требованиях мы в задаче, в рамках которой эти изменения были внесены, нажимаем кнопку Оповестить об изменениях, выбираем заинтересованные команды и делаем краткое описание изменений:

Скриншот 1
image

Письмо, которое автоматически генерируется после нажатия на кнопку Отправить оповещение, имеет следующее представление и содержит всю необходимую информацию:

Скриншот 2
image

Помимо письма в задаче остается комментарий с аналогичной информацией.

Ревью новых требований


image

Обязательным является ревью новых требований лидами всех команд, которые участвуют в разработке фичи. Речь идет не об изменениях в рамках дефектов, а об абсолютно новом функционале, описание которого вы делаете. Получить фидбэк крайне полезно, так как могут возникнуть правильные вопросы, которые помогут детально раскрыть возможности нового функционала. Когда ты долго развиваешь мысль в одном направлении, выявляешь потребность, проблемы, вырабатываешь разные концепции и описываешь решение в рамках продукта, глаз может замылиться, и может показаться, что есть очевидные вещи, которые не обязательно фиксировать в требованиях. Ревью помогает, в том числе и за счет вопросов от специалистов, которые погружаются в тему посредством той информации, которую получают в требованиях, понять какие моменты необходимо уточнить или раскрыть. Также ревью помогает отточить ясность формулировок, внести изменения, чтобы они всеми однозначно трактовались.

Для этого мы так же доработали issue-tracker, добавили отдельный тип задачи Ревью, которая запускается ответственным аналитиком по каждой фиче на всех руководителей команд. Руководители самостоятельно или, делегируя своим подчиненным, делают вычитку требований, задают вопросы или вносят уточнения через комментарии и согласовывают внесенные изменения.

Скриншот 3
image

Митинги/собрания/статусы


image

Ежедневные встречи команды, которая работает над фичей отличное мероприятие для небольших команд, при условии использования частых спринтов. В противном случае, ежедневные встречи будут отнимать время у всей команды и не будут нести никакой пользы. Однако полностью от встреч отказываться не стоит, нужно просто правильно определить частоту их проведения. И тогда можно будет держать руку на пульсе, понимать в правильном ли направлении движется команда в реализации задуманной концепции, а так же выявить на ранних этапах проблемы, которые возможно решить или ограничения, которые необходимо согласовать.

Естественно, что при разработке требований необходимо общаться с командой, так как можно узнать много полезного. Важные моменты, которые происходят где-то в черном ящике могут сильно повлиять на концепцию новых возможностей продукта, общение с коллегами помогает обратить внимание на моменты, которые интересны для их ролей. Например, общение с тестировщиками позволяет учесть в требованиях альтернативные сценарии, которые планируется проверить и важно, чтобы они были изначально заложены и учтены в разработке, а не обнаружены на этапе тестирования.

Обсуждение/решение открытых вопросов


image

Общение голосом хочется выделить в отдельный пункт, так как считаю важным именно живое общение, потому что в новых реалиях нет возможности обсудить вопросы лицом к лицу.

Чаще используются мессенджеры, они хорошо подходят для личной переписки, в которой можно для выражения своих эмоций использовать смайлы, гифки и т. п. Но для рабочей деятельности это не совсем приемлемо, и в итоге остается сухой безликий текст, который сложно интерпретировать получателю, ведь восприятие этого текста зависит от настроения человека, его личного отношения к вам, вовлеченности в диалог и прочих факторов, которые от вас не зависят.

Поэтому я предпочитаю решать вопросы в дискуссии голосом, то есть созвониться и обсудить, о чем-то договориться. Звонок поможет выяснить, правильно ли вы поняли контекст, сразу задать вопросы и получить ответы. Голос передает интонацию, позволяет расставить правильные акценты, обратить внимание на то, что действительно важно. Плюс, общение голосом экономит время всех участников и позволяет сконцентрироваться на конкретной теме, так как общение голосом (а не в чате), требует проявить участие и понимание для решения вопроса.

Протоколирование обсуждений


image

Для всех абсолютно привычно и обязательно фиксировать обсуждения решений с заказчиком, в виде ТЗ, которое неоднократно вычитывается до запятой и согласовывается всеми заинтересованными сторонами. Я хочу обратить внимание на то, что помимо официальной документации в разработке ПО, письменная фиксация договоренностей может быть полезна не только в рамках общения заказчик разработчик, но и внутри компании/команды.

Мы практикуем протоколирование общения команды при обсуждении концепций решений и функциональных возможностей системы. Так как при работе над фичей может возникнуть несколько вариантов решения, из которых необходимо выбрать один, естественно, возникают вопросы к команде, которые, собственно, и обсуждаются на встречах.

Как правило, протокол мы ведем в формате вопрос-ответ. Так же в протоколе обосновывается, почему выбран именно такой вариант решения, фиксируется, кто эти решения принимал и кто их согласовывал. Но важно понимать, что это наш внутренний документ, используемый в работе, который ничем и никем не регламентирован. В протоколе фиксируется обсуждение на конкретную тему и в конкретную дату, то есть он нужен для того, чтобы понимать, почему те или иные решения были приняты или отклонены, какие вопросы в целом возникали и какие из них закрыты, а какие требуют исследования для получения ответа. Это важно, потому что в режиме многозадачности, всю эту информацию держать в голове сложно, плюс, все заинтересованные члены команды должны быть в курсе и иметь доступ к этой информации. Также, по прошествии длительного времени, можно перечитать этот протокол и найти в нем ответы на вопросы, или, возможно, у вас появятся новые мысли исходя из ответов. Или же вы лишний раз убедитесь в правильности выбранного решения.

Валидация нового функционала


image

Под валидацией понимается проверка реализованного функционала на соответствие бизнес требованиям. До начала функционального тестирования, ответственный за фичу аналитик проводит валидацию: проверяет, реализован ли основной сценарий и соответствует ли поведение системы ожиданиям. Это важная практика, которую необходимо использовать именно до передачи функционала на тестирование, так как если основной сценарий не выполняется, то нет смысла проверять другие кейсы. Для выполнения валидации прописывается приемочный сценарий, содержащий шаги, которые необходимо выполнить и ожидаемую реакцию системы, чтобы в конечном итоге решить бизнес задачу, ради которой функционал разрабатывался. В рамках валидации можно выявить, в первую очередь, невыполнение основного сценария, неудобство пользовательского интерфейса, а так же грубые функциональные дефекты. Если основной сценарий выполняется, то считается, что фича прошла валидацию и может быть передана на тестирование. Тестирование уже более детально, в соответствии с тест-кейсами выполняет проверку реализованного функционала.

Презентация нового функционала


image

Еще одна классная практика, на мой взгляд, это презентация функциональности перед написанием тест-кейсов или выдачи фичи в тестирование. Презентация проводится для исполнителей, которые не погружены в контекст так, как их руководители, потому что не участвовали в этапах проработки решения. Как правило, это краткий рассказ о том, какие основные и альтернативные сценарии для решения проблем реализованы, какие настройки в продукте нужно сделать, какие технологические особенности есть у данного решения и какие ограничения. В результате формируется общее понимание новых функций продукта и снимается ряд вопросов, которые могут возникнуть у человека, не погруженного в контекст.

После тестирования функционала, перед официальным выпуском технического релиза мы проводим презентацию и демонстрацию нового функционала для сотрудников подразделений, которые занимаются внедрением продукта у заказчика. Это дает возможность получить обратную связь, предварительно обозначить особенности и ограничения, анонсировать дальнейшее развитие функционала. Важно, чтобы у всех было общее понимание нового функционала и не было ложных ожиданий.

Выше я описала небольшой список практик, которые мы c коллегами используем в своей работе. Я считаю их полезными, поэтому делюсь ими и хочу порекомендовать вам, выстроить процесс по работе с требованиями с применением данных практик. В следующих статьях мы планируем рассказать про содержательную часть работы с требованиями более подробно о том, какими практиками мы пользуемся для выявления потребностей/проблем заказчиков и формирования решений, которые будут их закрывать в полной мере.

Если у вас есть вопросы или вы хотите поделиться своим опытом, пожалуйста, оставляйте свои комментарии.

Автор: Венера Аббясова AbbyasovaVenera

* Все картинки для статьи взяты из открытого доступа в сети Интернет.
Подробнее..

Перевод Как создать метрики для Управления изменениями

13.11.2020 18:10:19 | Автор: admin

Первое о чем стоит подумать при определении ключевых показателей (KPIs) - это для кого они предназначены.

Кто те заинтересованные лица, кому вы будете предоставлять отчеты? В описываемом случае мы хотели измерять последствия процесса улучшения, который планировался. Отчеты использовались менеджером процесса Управления изменениями (change manager), операционным менеджером (IT operations manager), офисом управления проектами и менеджерами процесса Управления уровнем обслуживанием (service level managers).

Мы поговорили с заинтересованными лицами, чтобы понять, что для них важно, и определили четыре критичных фактора успешности (critical success factors, CSFs) для процесса Управления изменениями (change management):

  1. Защита бизнеса от негативного влияния последствий изменений

  2. Поддержание скорости изменений, необходимой бизнесу

  3. Предоставление знаний и информации о новых и изменяемых услугах, требуемых ИТ сотрудникам и бизнес персоналу

  4. Рациональное использование ИТ ресурсов

Ваши факторы успешности (CSFs) могут значительно отличаться от озвученных, но вы должны быть готовы покащать их список вашим заинтересованным лицам. Еще один неплохой вариант, способный помочь найти ваши факторы успешности (CSFs), - примеры из книги ITIL Service Transition (но их тоже не стоит бездумно копировать).

Факторы успешности (CSFs) не могут быть точно измерены, но то, что более важно, они представляют собой фразы, с которыми согласны ваши стейкхолдеры, иони описывают результаты, ожидаемые от процесса Управления ИТ изменениями (change IT management).

Следующий шаг - определить не более 3 ключевых показателей результативности (KPIs), которые могут помочь понять достигнуты ли все критические факторы успешности (CSFs). Ключевые показатели (KPIs) однозначно не доказывают, что фактор успешности (CSF) достигнут, но помогают продемонстрировать, как хорошо выполнеятся то, что направлено на достижение фактора успешности (CSF). Вполне допустимо иметь один и тот же ключевой показатель (KPIs) в нескольких факторах успешности (CSFs), но важно, чтобы показателей не было много.

Пока мы обсуждали ключевые показатели (KPIs) для процесса Управления изменениями (change management) осознали, что необходимо улучшить качество данных об изменениях. Ранее каждое изменение помечалось, как успешное, и сотавалось таким до тех пор, пока его не возвращали на доработку, но это не давало нам информации достаточной для внедрения факторов успешности (CSFs). Мы решили оценивать каждое изменение на основе признаков:

  • Было ли изменение полностью реализовано без необходимости возврата на доработку?

  • Было ли изменение реализовано в заявленные при планировании время и ресурсы?

  • Вызвало ли изменение инциденты?

  • Обеспечило ли изменение результаты, на которые рассчитывал заказчик?

В результате были определены коды закрытия изменения, чтобы различать полностью успешные изменения и те, которые имели одну или несколько проблем. Мы также добавили новый код закрытия инцидентов, чтобы обозначать инциденты, причиной которых было изменение.

И теперь мы смогли определить ключевые показатели (KPIs), поддерживающие наши факторы успешности (CSFs)

CSF1 - Защита бизнеса от негативного влияния последствий изменений

  • Уменьшать количество и долю изменений, которые вызывают инциденты

  • Уменьшать общее влияние на бизнес от инцидентов, вызванных изменениями

CSF2 - Поддержание скорости изменений, необходимой бизнесу

  • увеличивать число и долю изменений, которые были реализованы за плановое время и с привлечением планового объема ресурсов

  • увеличивать число и долю изменений, которые обеспечили ожидаемый заказчиком результат

  • увеличение уровня удовлетворенности от процесса Управления изменениями (change management) у проектного офиса и конечных заказчиков

CSF3 - Предоставление знаний и информации о новых и изменяемых услугах, требуемых ИТ и бизнес персоналу

  • увеличение доли изменений, по которым были предоставлены материалы в базе знаний для техподдержки (service desk)

  • увеличение уровня удовлетворенности от процесса Управления изменениями (change management) у ИТ персонала и конечных заказчиков (я бы сюда поставил пользователей, но автору виднее)

CSF4 - Рациональное использование ИТ ресурсов

  • увеличение числа и доли изменений, которые были реализованы за плановое время и с привлечением планового объема ресурсов

  • уменьшение числа и доли срочных и аварийных изменений

В результате получили довольно небольшое количество ключевых показателей для измерения и отчетности, которые были сфокусированы на интересах и заботах заинтересованных лиц (stakeholders), а также способствовало пониманию нами результативности процесса улучшений, который мы планировали.

А когда вы последний раз пересматривали ключевые показатели (KPIs), используемые в процессе управления изменениями (change management)?
Почему бы не пересмотреть показатели и отчеты по ним, чтобы сделать их более полезными для вас и ваших стейкхолдеров?

Подробнее..

Change Management 3 Колесо изменений и борьба с партизанами

24.09.2020 12:15:14 | Автор: admin

Привет, Хабр! Это мой заключительный пост на тему Change Management, в котором я хочу рассказать о модели Change Well и ее пользе для бизнеса. Мы рассмотрим, чем в партизан отличается от саботажника (в контексте внедрения изменений, конечно), как кувалда может помочь ускорить изменения в организации и чему мы можем научиться у создателей компьютерных игр.

Одним из подходов к управлению изменениями в организациях и не только является модель Колеса Изменений (Change Well) Розабет Мосс Кантер. По замыслу известной ученой из Гарвардского университета, для успешного внедрения изменений мы должны сконцентрироваться на активностях из 10 категорий. Как и среди спиц колеса, из них нельзя выделить более или менее важные. Но если одна или несколько спиц деформированы, далеко уехать будет непросто. То же можно применить и к внедрению изменений.

  1. Первая спица подчеркивает важность общего видения. О распространении единого взгляда на изменения мы уже говорили, обсуждая модель Коттера в прошлом посте. Здесь все принципы остаются такими же.

  1. Символизм отличный помощник при продвижении изменений. Один из ярких примеров символических действий продемонстрировал руководитель компании Haier, на данный момент одного из крупнейших мировых производителей бытовой техники. В 80-х Haier был небольшой компанией, которая выпускала холодильники. Одним из первых шагов ее руководителя Чжан Жуйминя был разворот к качеству. Но заявление так и осталось заявлением, пока директор не пришел с проверкой на завод. Когда ревизия выявила значительное количество брака, директор взял в руки кувалду и начал громить некачественные холодильники, а потом поручил сотрудникам делать то же самое. Работники были шокированы, ведь стоимость каждого холодильника составляла их двухлетнюю зарплату. Это был яркий символ отказа от прошлого и нового подхода к производству, в том числе благодаря которому компания изменилась и стала тем, чем она является сейчас. Кстати, кувалда до сих пор выставлена в музее в штаб-квартире компании Haier.

  1. Постоянное руководство и понятный процесс контроля необходимы при внедрении любых изменений. Для достижения успеха нужно оценивать риски, сравнивать цели, проверять отклонения от плана. Для всех должно быть понятно, как именно мы проверяем прогресс и успешность внедрения.

  2. Обучение необходимо сотрудникам, которые впервые сталкиваются с новой для себя деятельностью. Это могут быть как мастер-классы от приглашенных экспертов, так и внутренние специалисты или информационные ресурсы.

  3. Спонсоры это сотрудники компании с административным весом, которые будут поддерживать изменения на высоком уровне, а Чемпионы те сотрудники, которые раньше остальных начинают работать по-новому, вырабатывают новые подходы и методы. Именно они дают пример другим сотрудникам своим опытом и первыми победами.

  4. Быстрые победы, о которых можно сообщить сотрудникам, подогревают общее отношение к изменениям. Как мы уже отмечали раньше, будет полезно подготовить возможности для быстрых побед еще до начала процесса изменений.

  5. Обмен лучшими практиками и коммуникации способствуют распространению изменений внутри компании. Редко выходит, что все подразделения одинаково успешно внедряют новые практики, у кого-то это обычно выходит лучше, чем у других. Именно они и могут стать источниками лучших практик и проводниками изменений.

  6. Политики и процедуры могут быть как некими очевидными негласными правилами, так и закрепленными на уровне документов корпоративными законами. Именно поэтому стандарты нужно менять, причем делать это целенаправленно.

  7. Контрольные точки нужны для того, чтобы оценить, соответствует ли движение запланированным этапам, а обратная связь от спонсоров изменений помогает понять, насколько происходящее соответствует бизнес-целям компании.

  8. А в финале важно поощрить отличившихся тех, кто помог довести начатый процесс до успеха. Ведь наверняка это не последний процесс изменений в организации, а признание один из важных факторов мотивации.

Условно колесо можно разделить на культурный и процессно-инженерный сегменты, но это не отменяет важности каждой из спиц для достижения цели.

Еще одна интересная особенность этой модели заключается в том, что противоположные спицы связаны друг с другом.

Например:

  • Символы и сигналы не могут быть распространены без коммуникаций

  • Тренинги и инструменты позволяют убедиться, что люди смогут реализовать задуманное, а контроль убедиться, что действительно реализуют

  • Чемпионы должны быть награждены и получить общественное признание

Личный опыт

Еще до работы в Acronis мне довелось поучаствовать в проекте внедрения системы контроля безопасности выпускаемого продукта. Проект предполагал новый подход к ревью безопасности кода от участия команды Security в дизайне новых фич, до ручного пентеста и автоматизированного фаззинга непосредственно перед релизом. И внедрить это предстояло в организации с более чем 200 разработчиками, распределенными по миру.

С самого начала было очевидно, что вряд ли все разработчики примут нововведение с радостью, ведь для них это означало дополнительный контроль и добавляло работы. Чтобы сгладить отторжение, мы сначала четко проработали новые процессы и этапы перехода к новым стандартам, разработали набор информационных материалов и серию тренингов для сотрудников. Следующим шагом была официальная презентация, но не всем сразу, а сначала пилотной группе, обратную связь от которой предстояло обработать перед расширением охвата.

Для меня тогда было немного необычно, что иногда вместо настороженности мы встречали полное принятие и желание помочь, некоторых сотрудников новый подход к безопасности вдохновил: они задавали вопросы, давали обратную связь. Мы выбрали несколько человек из разных команд и предложили им стать security-чемпионами, то есть отвечать за security-review в своих командах. Некоторым из них их руководители (читай спонсоры) разрешили тратить часть своего рабочего времени на работу с безопасностью. Этого удалось добиться, объяснив руководителям все плюсы работы в новом процессе: ведь security команда не только предлагала процесс, но и обладала правом вето на выпуск релиза при наличии рисков, а рисками гораздо проще управлять заранее.

Маленькие локальные победы были достигнуты достаточно быстро, потому что пару человек мы начали знакомить с нашими подходами еще до полноценного старта проекта. Процесс постепенно перешел в другие команды и шаг за шагом достаточно масштабные изменения приняли во всей организации.

Весь спектр мотиваций

Но, конечно, не все реагировали на изменения одинаково. При внедрении любого проекте вы всегда встретите тех, кто саботирует новшества. По готовности воспринимать все новое, можно условно выделить 7 категорий участников процесса изменений.

  • В число миссионеров и визионеров входят топ-менеджеры и менеджеры, которые знают, зачем нужны изменения и продвигают их;

  • Активные последователи это Чемпионы. Они готовы работать по-новому;

  • Оппортунисты ищут личные выгоды и стремятся избежать личных проблем. Эти люди с радостью внедряют новые подходы, если они выгодны лично им;

  • Самая многочисленная группа равнодушные. Они предпочитают отсидеться и посмотреть что будет дальше. Такие люди, как правило, уже участвовали в изменениях, которые не увенчались успехом;

  • Бойцы сопротивления могут быть тайными врагами. Не говоря ничего в лицо, за спиной они будут обсуждать изменения в самом негативном ключе. Они кивают, когда выступает руководитель, а потом тихо саботируют весь процесс;

  • Явные противники выступают против изменений открыто. Они отстаивают свое мнение, и с ними очень важно общаться. Именно они могут указать на ошибки, недочеты и другие нюансы;

  • Эмигранты не поддерживают вообще никакие изменения.Они не видят перспектив в компании, и стремятся сбежать в любой сложной ситуации. Работать с ними практически бесполезно.

Когда вы продвигаете изменения, нужно четко понимать, с каким именно сотрудником вы имеете дело. От этого будет зависеть стиль коммуникации, а также методы контроля за выполнением требований. Конечно, проще разобраться, кто есть кто начиная внедрение в одном отделе. И поэтому мы в Acronis предпочитаем внедрять изменения постепенно.

Островной подход к внедрению изменений.

Островной подход к изменениям подразумевает внедрение новшеств в каком-то одном отделе или подразделении. Пилотный отдел можно выбрать произвольно, но хорошо бы, чтобы он в целом был склонен попробовать новый подход. Для того, чтобы явно выделить работающий по-новому отдел относительно других, его можно переименовать или брендировать, например, выдав корпоративные футболки.

Так, мое подразделение в Acronis в какой-то момент было переименовано из Performance QA в Performance Engineering, чтобы явно показать, что мы уходим от ручного тестирования производительности к более сложным автоматизированным решениям. В производстве, например, можно выдать людям белую униформу и назвать отдел Белым в контраст с остальными отделами, а может быть купить черные футболки и сделать спецов по безопасности Черной командой.

На этапе пилотного проекта обкатываются новые практики. Мы доводим их до состояния, близкого к идеалу. Дополнительным стимулом может быть повышение зарплаты сотрудников отдела, ведь это создаст позитивный конфликт между новым и старым, который будет подталкивать всю компанию к принятию изменений. Далее можно по цепочке реформировать остальные участки, постепенно переходя на новые процессы во всей организации.

Именно так мы строим новые практики работы внутри Acronis. Например, использовать Jira для контроля всех новых фич началось с нашей команды, а затем распространилось и на все команды с горизонтальными функциями. То есть изменения не обязательно должны идти сверху вниз или снизу вверх. Для них возможны разные направления, движения, которые зависят от конкретных людей и процессов.

Заключение

Так или иначе, внедрение изменений в любой компании это комплексная задача. Чем больше организация и масштабнее изменения, тем сложнее их реализовать. Но при должной подготовке, которая включает в себя поиск единомышленников, внутренний PR, подготовку быстрых побед, и с ней можно справиться. Главное помнить, что основной сдерживающий фактор для любых изменений это инертность человеческой психики. Поэтому, чем больше будет вовлечения, тем выше шансы на успех у любых изменений.

Подробнее..

Перевод Рентабельность инвестиций в Канбан. Часть 1

04.01.2021 12:22:00 | Автор: admin

Они хотят увидеть экономическое обоснование, прежде чем мы сможем приступить к использованию метода?! это слова главы отдела, которую я обучал в рамках запланированного внедрения Канбан. У неё были смелые планы по улучшению показателей своего подразделения, но этот вопрос заставил её задуматься.

Команда управленцев хотела знать, какова будет плата за внедрение. Могут ли они позволить себе инвестировать в Канбан? Когда произойдет возврат инвестиций? До этого мы уже потратили некоторое время на изучение того, как в настоящее время проводится работа, так что в действительности вопрос звучал как: можем ли мы не использовать Канбан?. Мы были прагматичны, засучили рукава и приступили к разработке модели того, как Канбан метод позволяет получить измеряемый успех в бизнесе. Я надеюсь, что эти разработки помогут в стремлении использовать Канбан для улучшения вашего бизнеса.

Дисбаланс окупаемости инвестиций (ROI)

Первые несколько статей о рентабельности инвестиций будут сосредоточены на экономических выгодах от использования Канбан. Как только мы позаботимся о верхней части уравнения окупаемости инвестиций, мы обратим наше внимание на нижнюю половину стоимость реализации. Что касается стоимости реализации, то команда в SquirrelNorth экспериментировала с различными моделями, чтобы обеспечить оптимальную комбинацию обучения, коучинга и консультирования для достижения долгосрочных результатов, о которых я расскажу в заключительных частях этой серии статей. Есть причина рассказать об этом в конце, это связано с большой разницей между инвестиционными затратами и экономическими результатами. Инвестиционные затраты сравнительно небольшая сумма по сравнению с выгодами: не сосредотачивайтесь слишком сильно на знаменателе, числитель вот где происходит самое интересное!

Ранние и непрерывные выгоды!

Канбан-подход это всегда ранние и непрерывные улучшения. Эволюционный подход к изменениям поддерживает существующую производительность организации, в то же время позволяя вносить изменения в процессы, которые открывают возможность быстрого старта улучшений бизнеса. (также он хорошо справляется и с социальными проблемами, которые не затронуты в данной статье)Традиционные подходы к изменениям заключаются в банальной установке нового процесса поверх старого. Такое разрушение старого приводит не только к периоду низкой производительности (потенциально длительному) , но и к выходу производительности на плато без дальнейшего продвижения (даже если цели улучшения достигнуты). Канбан метод позволяет избежать социальных и экономических рисков и даёт результаты на ранней стадии и постоянно наращивает их на протяжении всего его использования; т. е. речь идет о постоянных улучшениях.

Традиционная модель изменений в форме J-кривой в сравнении с моделью изменений Канбан

Ранние формы Канбан

В Канбан методе не существует такого понятия, как правильный Канбан, только применения различных инструментов Канбан, соответствующие разному уровню зрелости организации. Этот подход был систематизирован в модели, известной как Модель зрелости Канбан (Kanban Maturity Model KMM), которая классифицирует организационную зрелость по 7 уровням: от 0 до 6.

На каждом более высоком уровне, вводятся более продвинутые инструменты Канбана, которые осмыслены только по достижении этого уровня. Поэтому использования Канбан метода в целом нужно рассматривать как повышения организационной зрелости компании, проходящей серию улучшений, и применение согласованных практик на каждом этапе взросления. К сожалению, нет кратчайших путей к повышению зрелости организации, то есть прямого перехода со 2 на 4 уровень; каждый уровень необходимо проживать по очереди, закрепляя новые ценности и практики, прежде чем можно будет подумать о переходе на следующий уровень.

С учётом этого пути повышения зрелости, большинство внедрений Канбан начинаются с низкого уровня зрелости (уровни от 0 до 1), что раньше до введения KMM называлось Прото-Канбан. Также следует отметить, что большинство организаций так и остаются на этом низком уровне зрелости, если они не вкладывают средства в получение квалифицированной внешней помощи в форме коучинга и обучения (подробнее об этом в следующей статье, посвященной инвестиционной стороне вопроса).
Несмотря на низкую зрелость этих методов, они всё же приносят пользу. Давайте рассмотрим некоторые ранние формы Канбан:

Видимость работа теперь отображается в виде тикета на физической или цифровой доске. Как минимум, мы теперь знаем, каков статус выполняемой работы: она начата, завершена или ещё не начата. Становится намного проще увидеть, над чем работают, и получить базовую информацию о состоянии.

Базовая доска, которая по-прежнему дает полезную информацию.

Сокращение количества конкурирующих задач внедрение доски может показать, насколько все заняты, и помочь в принятии решений о том, на чём сосредоточить усилия ваших сотрудников. Этот фокус потенциально может увеличить количество завершенных работ по сравнению с наличием значительного объёма со статусом в работе.

Сокращение индивидуальной перегрузки повышенное внимание к сокращению числа конкурирующих задач даёт возможность избежать перегрузки ваших сотрудников слишком большим количеством действий. Такой подход поможет снизить количество непродуктивных и дорогостоящих сверхурочных работ и позволит лучше управлять качеством.

Расширение сотрудничества в команде прозрачность, предоставляемая доской, также поможет улучшить сотрудничество между исполнителями. Сотрудники могут собраться за доской, увидеть, кому нужна помощь, и увеличить шансы на совместную работу.

Нам нужно меньше управлять, не сбавляя обороты!

Больше одновременной работы = Больше работы для отслеживания = Больше транзакционных издержек.

Благодаря повышенной прозрачности и ограниченному количеству конкурирующих задач, обеспечиваемой этими базовыми формами Канбан, мы обычно видим первые преимущества для бизнеса в виде сокращения накладных расходов, необходимых для управления статусом и отслеживания большого объёма работы. В частности, резко сокращаются затраты на координацию организации.

Outlook Blue всегда полный календарь, которым трудно управлять при бесконечной параллельной работе.

Цифровые календари становятся всё более скудными без необходимости бесконечных статус-митингов, а потребность в армиях project-менеджеров становится всё меньше, поскольку накладные расходы управления оказываются под контролем. Все эти дополнительные возможности, высвободившиеся в организации, могут быть сосредоточены на других инициативах, улучшении результатов текущих инициатив и развитии квалификации ваших сотрудников.

Количественная оценка прибыли от внедрения ранних форм Канбан

Наши наблюдения показывают, что при самых скромных сокращениях сверхурочных и транзакционных издержек можно привести к снижению затрат на управление с использованием Канбан на 5-10% в течение 6 месяцев после начала использования Канбан.

Теперь мы можем использовать эту цифру в качестве первой части раздела прибыль для нашего расчёта окупаемости инвестиций. Для примера возьмем ежегодные операционные расходы большого отдела в 20 миллионов долларов, что даёт выигрыш в 1 миллион долларов к концу первого года. Это все равно что получить целую дополнительную команду бесплатно! Это уже вполне ощутимая выгода, имеющая материальную ценность. Что ещё может предпринять организация, высвободив 1 миллион долларов? Отличная новость состоит в том, что до конца года мы успеем ещё больше улучшить зрелость нашей организации и наши практики Канбан метода!

Дальше больше!

В следующей статье я исследую преимущества перехода на уровни зрелости 2+ и дам количественную оценку прибыли от использования Канбан в следующие 612 месяцев.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru