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

тл;др

Это не техническая проблема, это проблема людей. Относитесь к этому как к таковому.

Я ничего не меняю!

Вы действительно плохо начали, и это не имеет ничего общего с кодом.

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

Люди не любят перемен. И им это очень не нравится от «новенького».

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

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

Что делать?

1. Перестаньте думать «я против них». Если вы не планируете уйти, вы являетесь частью этой команды. Это не те «ужасные разработчики» против «я суперзвезда», и если вы сообщите об этом своей команде, у вас будут проблемы. Никто никогда не будет уважать ваши идеи. Неважно, работает ли команда как отдельные личности. Это все еще команда, и вы даже описываете ее как таковую.
2. Узнайте, оправдываются ли ожидания. Соответствует ли команда ожиданиям/желаниям руководителя? Если это так, вы не найдете ни у кого особой мотивации для улучшения. «Если это не сломано, не чини это». Но если команда изо всех сил пытается достичь целей по производительности, у вас есть другой подход к этому и вы можете представить все так: «Эй, мы не укладываемся в сроки — вы, ребята, хотите попытаться изменить это? помогите нам сделать это».
3. Вы не менеджер, ваш босс. Похоже, вы хотите управлять всем процессом самостоятельно. Это отлично работает - для менеджеров/руководителей команд. Получение информации от вашего босса очень важно.
4. Люди больше заботятся о результатах, чем о смутных чувствах. Ваш руководитель будет гораздо больше заботиться о вашей точке зрения, если вы действительно продемонстрируете, почему то, что вы говорите, лучше, чем текущее состояние. Не только «потому что так сказал интернет!» но на самом деле через демонстрацию.
5. Попросите людей о помощи. Найдите способы укрепить доверие в команде. Обращение за помощью/руководством — очень простой способ сделать это. Даже если это незначительно, сделайте это со своей командой. Они будут уважать вас гораздо больше, если вы действительно покажете, что прислушиваетесь к их мнению.
6. Подавать пример. Люди, которые не хотят меняться, обычно не воспринимают новую информацию и говорят: «Вы знаете, что вы правы, я никогда не считал, что то, как я это делал, было хуже, теперь я просветлен и должен изменить свои пути». Люди меняются, меняя мелочи, медленно, устойчивым образом. Вы можете продемонстрировать это.
7. Выбирайте битвы с умом. Ваш пример звучит так, будто ваша основная проблема заключается в том, что в команде есть люди, которые плохо справляются со своей работой. Разве это так плохо , если код неэффективен? Влияет ли это на конечную производительность? Или сосредоточить следующий проект на итерациях, а не на водопаде (обратите внимание, что если вы сосредоточитесь на гибких методах, а не на водопаде, вам лучше привлечь к этому своего босса).

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

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

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

Я бы определенно не стал начинать с низкого уровня — «этот код неэффективен» или тому подобное. Это просто вызовет большую оборону для очень небольшой выгоды.

Смешивать и сочетать agile-проект и водопадный проект безумно сложно. Специалисты водопада хотят заранее установить интерфейс между вашими проектами (формат файла, макет таблицы, API и т. д.), а затем уйти и написать в этот интерфейс. Вы хотите просто начать работу с максимально простым интерфейсом, частями, которые, как вы точно знаете, вам понадобятся, а затем прийти к ним и сказать, что вам нужно что-то добавить или изменить, и заставить их отреагировать на это. Для вас это ответственно, гибко и быстро, потому что вы не тратите вечность на споры о дизайне в то время, когда вы не можете знать ответы. Для них это ковбой, дергающий их, постоянно меняющий землю под собой. Это рецепт катастрофы.

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

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

В прошлом я пытался придерживаться следующих принципов, и, похоже, это сработало хорошо:

• Я заставил себя начать с «периода спокойного обучения»: в течение нескольких месяцев или около того,

  Молчи и учись. Не судите ничего. Интегрируйте себя в команду и компанию. Будьте продуктивны. Завоевать доверие и репутацию. Покажите свою компетентность.

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

• Если вы замечаете проблемы или сталкиваетесь с вещами, которые, по вашему мнению, не оптимальны,

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

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

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

• Через некоторое время ваши наблюдения (или заметки) помогут вам

  Получите четкое представление о том, каковы основные проблемы. Найди их (только!)

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

• Решайте только одну проблему за раз. Используйте имеющиеся у вас данные и попытайтесь

  Разработайте предложение по улучшению этой проблемы,

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

• Никогда не указывайте пальцем. Станьте ценным другом каждого члена вашей команды.

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

Добро пожаловать в мир бизнеса.

Изменения требуют времени. В крупной компании могут пройти десятилетия, если то, что у них есть, работает достаточно хорошо (и действительно могло быть ведущим в отрасли много лет назад, когда они приняли эти методы). Работая в IBM, я до сих пор использую некоторые инструменты, бэкенды которых восходят к эпохе «зеленого экрана», потому что они ДЕЙСТВИТЕЛЬНО работают, тесно интегрированы с другими инструментами (и, следовательно, их трудно заменить по отдельности), и потому что никто не нашел достаточно средств и времени, чтобы инвестировать в переход таким образом, который не связан с неприемлемым риском.

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

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

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

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

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

Делайте это по одному небольшому изменению за раз, пока/если вы не будете в состоянии реализовать более крупные изменения. Покажите, а не просто расскажите. Будьте терпеливы и настойчивы. Помните, что вещи такие, какие они есть, потому что они ДЕЙСТВИТЕЛЬНО работают, и научитесь управлять текущей системой достаточно хорошо, чтобы вы могли точно объяснить, каковы преимущества и риски перехода.

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

Пока хорошие ответы, особенно от Роджера, Эндерленда♦ и Кейт Грегори, но я хотел бы добавить к этому.

TLDR

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

Оригинальный ответ

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

Предлагаемый порядок методик:

Standups - Старт очень медленный

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

TDD — они по-прежнему могут заниматься своими делами, но более структурированным образом.

Думаю, это хороший следующий шаг. Трудно и почти бессмысленно выполнять модульные тесты для унаследованного кода (на самом деле, определение, по мнению некоторых экспертов, унаследованного кода — это кодовая база, в которой либо нет, либо мало модульных тестов), но написание модульных тестов для новых методов гарантирует что новые методы на самом деле будут делать то, что от них ожидают — в результате будет меньше ошибок, о которых должны думать разработчики, меньшие расходы для компании (ваш менеджер должен знать об этом), и это формирует поток систем, а не наоборот. Прочтите о разработке через тестирование (TDD) и узнайте, какTDD облегчит жизнь вашим коллегам, и в конечном итоге они это сделают, тем более что они могут делать это самостоятельно и им не нужно взаимодействовать с кем-либо еще, кто это делает. Самая важная часть заключается в том, что модульный тест может быть написан за считанные секунды или минуты, если он сделан заранее, что делает его не таким скучным и на самом деле неэффективным и бессмысленным, если он написан позже.

Изобретите концепцию SOA — избавьтесь от сильно связанных систем

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

Code-review — перенесите знания без необходимости слишком много взаимодействовать с другими

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

Список можно продолжить

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

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

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

Слово «гибкий» используется повсюду, но, как и все это, оно относительно. Вы должны сосредоточиться на некоторых реальных проблемах, которые есть у всех. Сколько времени занимает обработка запросов на изменение? Являются ли изменения неполными, т.е. «Новое исправление появилось в разделе A, но не появилось в разделе B. Почему бы и нет?» Это то, что волнует пользователей. Вы получите больше поддержки от остальной компании, если результаты предложенных вами изменений принесут им пользу. Конечно, возможность реализовывать вещи быстрее может быть лучше для всех.

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

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

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

Не сдавайтесь, но и не ждите, что ситуация изменится за одну ночь. Перед тобой стоит важная задача, мой друг.

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

Человек, который должен это делать, — ваш менеджер. Он тот парень, которого нужно убедить. Попробуйте прагматично апеллировать к эффективности с примерами.

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

(Возможно, дело не в людях, а в политике — иначе кто-то давно бы подхватил их на этих практиках.)

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

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

Мой личный стандарт заключается в том, что я настаиваю на том, чтобы любые изменения, которые я делаю в коде, разработанном другими, где я не занимаюсь архитектурой, не имели абсолютно никаких недостатков (или, если существуют потенциально неосязаемые недостатки, т.е. «это более читабельно?», что они минимальный.) Используя это как мой стандарт, я все еще могу:

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

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

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

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

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

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

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

Но в ситуации «никто, кроме $x, все равно не будет трогать этот код до завершения проекта», вопрос о возможности сопровождения кем-либо и усилиях имеет разные ответы.

Что касается повторного использования кода: одна из философий C++ заключается в предоставлении инструментов для создания универсальных решений. 95% «повторно используемого кода», создаваемого начинающими программистами, не используется повторно. И причина этого в том, что для многих простых задач стоимость «повторного использования» для опытного программиста выше, чем простое списание, специально ориентированное на рассматриваемый код.

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

Вы можете себе представить, как он будет рад, если кто-то другой сможет поддерживать его роман, если он будет правильно задокументирован и параметризован?

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

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

Если вы скажете: «Вот руководство. Мы решили, что будем стандартизировать инструменты Пола. Мы купили/изготовили 20 наборов инструментов, точно таких же, как у Пола, и теперь все будут работать с ними в будущем». Даже если все согласятся с тем, что Пол — лучший мастер по изготовлению органов в компании, мало кто обрадуется такому изменению. Инструменты, скорее всего, не будут работать хорошо для неопытных строителей, и они будут работать иначе, чем их собственные инструменты для опытных.

Даже Пол не будет счастлив, потому что все будут бежать к нему и обвинять его.

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

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

То, что вы должны проверить после того, как проведете там около полугода, это не то, как выполняется работа, а то, как она передается: чувствуете ли вы, что общение/встречи команды происходят таким образом, что действительно существенные колеса не рискуют быть заново изобретёнными очень дорого ?

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

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

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

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

Проблема №1: множество индивидуумов

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

Проблема №2: изобрести велосипед

Действительно это проблема. Общий код должен быть разделен в репозитории компании или команды. Это должно быть решено в ходе нескольких специальных встреч со всей командой.

Проблема №3: ​​нет гибкости

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