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

Когда я начал работать над проектом, это был полный беспорядок. Было много повторений кода. Я видел 500 одинаковых кодов, скопированных в 20 разных файлов с небольшими изменениями. Кроме того, это было не совсем хорошо организовано: весь код создания пользовательского интерфейса был смешан в контроллерах представления вместе с логикой.

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

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

Иногда я думаю, что если бы не IDE, я думаю, что они написали бы весь код без отступов или форматирования вообще.

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

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

Как я могу решить эту ситуацию, не сосредотачиваясь только на «плохой корпоративной культуре», «неопытных выпускниках» и т. Д., И фактически начать улучшать ситуацию.

Учите и практикуйте то, что проповедуете.

Вы знаете, что это важно. Вы знаете обратную сторону, когда это сделано неправильно.

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

Это необходимо:

• Общественное признание руководством того, что эти предметы важны
• Линтеры, чтобы люди могли собраться вместе, договориться о стиле, а затем позволить компьютерам контролировать
• Ведущие разработчики, которые полностью заинтересованы и готовы учить других
• Встречи, демонстрации, обеды и обучение, и т.д., чтобы научить этим подходам
• Люди оцениваются по качеству предметов, которые вы упоминаете в своих обзорах
• Документированные и опубликованные стандарты
• Вытягивает запросы, имеющие много рецензентов
• Запросы на извлечение не объединяются, пока качество кода не станет высоким
• Частое сопряжение кода
• Групповые коды отзывов для сложных PR

На словах это требует

руководство

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

Я много писал на эту тему на SoftwareEngineering.SE в прошлом и сам был в подобных ситуациях. Поэтому я попытаюсь дать несколько советов и выделить несколько проблем, которые я отметил при чтении вашего вопроса.

Но сначала поговорим о важном аспекте: вашей роли в компании.

Твоя роль

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

В обоих случаях важнее не ваше место в иерархии, а больше:

• Что другие разработчики думают о вас. Если они будут относиться к вам как к раздражающему парню, который задает им глупости, вы не уйдете далеко. Я видел много случаев, когда технические лидеры и руководители проектов не имели абсолютно никакого влияния на команду, потому что команда знала (или думала), что у этих «лидеров» нет технических знаний, необходимых для принятия решений, которые они принимают. С другой стороны, я видел нескольких разработчиков, которых на самом деле слушали их коллеги, потому что они знали, что разработчики умелые и опытные.

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

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

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

Теперь намеки.

Стиль

Однажды я попросил хорошо следовать стилю кодирования и форматированию большинства существующего кода (к сожалению, у нас нет формального документа стиля кодирования). Но это не сработало ...

Конечно, это не так, поскольку это не так, как должно быть.

• Стиль скучный .

• Следующий стиль скучен .

• Написание документа в стиле кодирования скучно ( и чертовски сложно ; даже не пытайтесь делать это, если вы не работали с языком более десяти лет).

• Чтение стиля документа скучно .

• Пересматривать код для ошибок стиля скучно .

• Троллинг о том, что мой стиль лучше, чем ваш, очень интересен , особенно когда нет абсолютно никакого объективного преимущества одного стиля над другим. Серьезно, каждый здравомыслящий человек знает, что правильный способ писать if (x)- это то, как я это написал, а не if(x)или if ( x )!

Следовательно:

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

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

• Не заставляйте разработчиков исправлять 2 000 ошибок стиля.

• Применять стиль автоматически при коммите. Код с ошибками в стиле не имеет места в контроле версий.

• Сделайте это с самого начала проекта. Настроить контроль стиля в существующем проекте сложно или невозможно.

Более подробную информацию о том, что прочитал первую часть этого другого ответа на SE.SE .

Также:

• Не будь слишком строг. Например, написание jslintкода, соответствующего стандарту, довольно раздражает, поэтому его следует делать исключительно тогда, когда это абсолютно необходимо (или если все члены вашей команды с удовольствием его используют). То же самое касается инструментов статической проверки; например, анализ кода .NET на максимальном уровне может быть очень угнетающим и удручающим, но приносящим мало пользы; С другой стороны, тот же набор инструментов на умеренном уровне оказывается очень полезным.

Кодовые обзоры

Теперь, когда вам не нужно беспокоиться о стиле во время проверки кода, вы можете сосредоточиться на более интересных вещах: улучшении (вместо исправления) исходного кода.

Разные люди по-разному реагируют на проверки кода. Некоторые считают это возможностью. Другие ненавидят это. Некоторые слушают все, что вы им говорите, делаете заметки и не обсуждаете, даже если они могут быть правы. Другие пытаются спорить по каждому вопросу. Вам решать, как справиться с каждым разработчиком в соответствии с его индивидуальностью. Обычно полезно:

• Делайте обзоры кода наедине, особенно когда разработчик младший и пишет действительно плохой код.

• Покажите, что ничего личного: вы просматриваете код, а не навыки человека.

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

• Никогда не спорь. Вы здесь не для того, чтобы убеждать, но чтобы предоставить свой опыт.

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

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

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

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

Повышение квалификации

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

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

Помимо непосредственного обучения, убедитесь, что вы достаточно хорошо знаете такие книги, как McConnel's Code Complete , и поговорите об этих книгах со своими коллегами. Предложите им прочитать исходный код проектов с открытым исходным кодом, приведите конкретные примеры высококачественного кода. И, очевидно, напишите качественный код самостоятельно.

Фокус на контексте, а не на людях

Как я могу решить эту ситуацию, не сосредотачиваясь на «плохой корпоративной культуре», «неопытных выпускниках» и т. Д.

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

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

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

Получите ваши метрики правильно

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

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

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

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

Например, давайте рассмотрим, что члены команды допускают слишком много орфографических ошибок в именах классов, членов класса и переменных. Это раздражает. Как вы могли бы измерить это? С помощью синтаксического анализатора вы можете извлечь все слова из кода, а с помощью средства проверки орфографии определить соотношение слов, содержащих ошибки и опечатки, скажем, 16,7%.

Ваш следующий шаг - договориться с вашей командой о целевом соотношении. Это может быть 15% для следующего спринта, 10% для следующего, 5% через шесть недель и 0% через два месяца. Эти показатели автоматически пересчитываются при каждой фиксации и отображаются на большом экране в офисе.

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

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

Вывод

Я считаю, что каждый аспект, упомянутый в вашем вопросе, может быть решен с помощью методов, которые я включил в свой ответ:

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

  Вы должны были применять стиль автоматически при коммите.

• и часто не используют современные языковые функции, такие как средства доступа к свойствам (это относительно ново в Objective-C).

  Оба проверки коды и обучение здесь , чтобы передать свои знания языка.

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

  Оба проверки коды и обучение здесь , чтобы передать свои знания структуры.

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

  Это отличная вещь. Похоже, у вас есть возможность учиться у них.

• Часто они не могут правильно назвать методы или переменные из-за плохого английского

  Обзоры кода должны также фокусироваться на правильном именовании В некоторых IDE также есть средства проверки орфографии.

• Иногда я думаю, что если бы не IDE, я думаю, что они написали бы весь код без отступов или форматирования вообще.

  Конечно, они будут. Стиль скучный и должен быть автоматизирован.

• По сути, я ненавижу код, который они пишут.

  Помните из части обзоров кода: «Цель не в том, чтобы показать, насколько плох разработчик. Цель - предоставить возможности для улучшения ».

• Он плохо отформатирован / организован, а иногда радикально отличается от остальной части проекта.

  Автоматическая проверка стиля .

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

  Чего ждать?! Художественное произведение?! Угадай, что? Некоторые люди (включая вас через шесть месяцев) могут найти ваш код далеко не произведением искусства. Между тем, вы должны понимать, что если рассматривать ваши работы как произведение искусства, а их работу как чушь, то это никому не поможет. Включая тебя.

• Чувствуется, что их все больше и больше не учат или им все равно: они просто делают то, что от них требуется, и уходят домой.

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

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

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

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

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

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

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

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

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

Симптомы:

• «они просто делают то, что требуется, и идут домой»: звучит, они демотивированы. Разве они не были более восторженными, когда пришли?
• «они» против «нас» / «меня» / «я»: недостаток взаимного доверия?
• «Я дал несколько советов: я прокомментировал PR на Git»: тон письменной критики иногда неверно истолковывается как агрессивный или высокомерный, несмотря на конструктивное намерение. Почему бы не обсудить это лицом к лицу?

Вы небольшая команда: используйте это преимущество! Несколько идей для начала:

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

Цитата дня:

Если хочешь идти быстро, иди один. Если хочешь далеко ходить, иди вместе

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

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

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

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

Это было вызвано неопытными разработчиками? Было ли это вызвано тем, что руководство пыталось сократить расходы, нанимая дешевых выпускников вместо более опытных и дорогих разработчиков? Это из-за того, что люди ленивы и злонамеренны или люди побеждены сломанной системой? Сроки заставляют вас делать «то, что должно быть сделано», чтобы заставить это работать, или люди просто тратят свое время и не слишком заботятся о том, над чем они работают? и т.п.

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

Тогда есть управление. Руководство не знает о ситуации или просто не заботится? Узнай Вам обязательно нужна поддержка менеджмента, если вы хотите что-то улучшить. Если что-то, что заняло 3 месяца, вдруг заняло 4 месяца, потому что теперь вам нужно писать тесты, делать обзоры кода, обсуждать на доске с командой решение о хороших решениях, парной программе и т. Д., Вы можете быть уверен, что руководство заметит разницу во времени. То, что меняется от 3 до 4 месяцев, легко наблюдать и измерять. Наличие прочной базы кода, поддерживаемого продукта, хорошей стабильной архитектуры, вещей, которые улучшают структуру продукта, не так легко измерить. Сколько времени лучшие практики отнимают у вас в долгосрочной перспективе, невозможно измерить заранее, может быть, даже по факту. С другой стороны, задержка в один месяц - ежу понятно. Так что имейте поддержку управления на этом. Приготовьтесь совершить жесткую распродажу.

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

Давайте изменим перспективу на мгновение.

Я очень расстраиваюсь, когда они добавляют свои спагетти к моему произведению искусства, и это влияет на мое настроение на работе и производительность.

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

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

Как я могу решить эту ситуацию, не сосредотачиваясь только на «плохой корпоративной культуре», «неопытных выпускниках» и т. Д., И фактически начать улучшать ситуацию.

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

И делать это небольшими шагами.

Если вы внесете слишком много изменений сразу, люди почувствуют разочарование и сдадутся. Изменения требуют времени. Измените свою компанию или измените свою компанию. Удачи!