Некоторые ошибки, которых следует избегать

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

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

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

  1. не хватает времени, чтобы сосредоточиться на чем-то одном и хорошо его изучить, что усиливает их чувство демотивации, заставляет их скучать и им хочется покинуть компанию.
  2. отсутствие радости от успешного выполнения чего-либо, постоянный отказ от проекта, который они, наконец, понимают и любят, или отсутствие признательности за то, что они начали.
  3. изо всех сил пытаются понять проекты, уже начатые другими командами, и не чувствовать мотивации брать их в свои руки, особенно если отсутствует культура написания хорошей документации и следования лучшим практикам.
  4. чувство потери времени, плюс демотивация на «продолжайте делать хорошо», которая вводится постоянными изменениями функций, которые команда уже выполнила.

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

Менеджеры постоянно меняют свое мнение

Давай сделаем это. Нет, давайте сделаем это вместо этого. О нет, нет. Раньше было лучше.

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

Незавершенное доказательство концепции

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

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

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

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

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

Несколько советов, которые помогут с этим справиться

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

Менеджеры постоянно меняют людей из одного проекта или команды в другой

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

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

Отсутствие определенного процесса адаптации и недостатка документации.

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

Проект начат без четко определенной архитектуры или не соответствует передовой практике.

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

Отсутствие должного общения с другими командами

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

Отсутствие уведомления

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

Добавление людей для сокращения времени разработки

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

Несколько советов, которые помогут с этим справиться

  1. Спросите людей, готовы ли они изменить проект или команду, и вначале вовлеките их в обсуждение.
  2. Четко объясните мотивацию изменения.
  3. Понять, обладают ли люди нужными навыками, необходимыми для новой команды или проекта.
  4. Сообщите об изменении с достаточным количеством уведомлений.
  5. Подготовьте определенный процесс адаптации, чтобы облегчить изменение.
  6. Если вы хотите ускорить выполнение задачи, попробуйте временно привести в команду человека, который уже разбирается в этом вопросе.

Менеджеры не создали команду, в которой все участники могут легко заменять друг друга

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

Несколько советов, которые помогут с этим справиться

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

Последние мысли

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

Разработчики должны сделать следующее:

  1. Напишите дополнительную документацию.
  2. Следуйте передовой практике.
  3. Примите изменения как новый вызов, который может принести новые навыки и возможности.

Менеджеры должны делать следующее:

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

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

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