Должен ли я сообщить руководству, что намерен уйти из-за плохой практики разработки программного обеспечения?

Вы на самом деле в состоянии изменить это. Вы лидируете примером.

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

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

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

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

Должен ли я сообщить руководству, что рассматриваю возможность ухода из компании из-за такой практики?

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

Или, по крайней мере, пусть они знают, что я расстраиваюсь?

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

Судя по звукам (плохих) практик, это похоже на небольшую компанию. Я бы сказал, выскажите свое разочарование таким образом, чтобы улучшить компанию. Сказав что-то вроде: «Привет, мистер менеджер, я заметил, что мы не следуем некоторым передовым методам. Это может повлиять на мою эффективность и эффективность других членов моей команды. есть какие-то передовые практики?» Если на этом этапе ваши идеи остаются без внимания, и вы планируете уйти, сделайте это тихо, пока ищете другую работу, и сообщите об этом должным образом (обычно за 2 недели в США).

Вы также упомянули, что менеджера не было, а замены не было. что, если бы вы могли быть заменой? Я знаю, ты говоришь I am not very experienced yet. Но демонстрация вашей компании того, что вы увлечены тем, чтобы вести команду к лучшим практикам, имеет большое значение , особенно в небольших компаниях. Если вас беспокоит отсутствие опыта, вы можете попросить об обучении. По крайней мере, вы можете обсудить путь своей карьеры, чтобы перейти на руководящую должность. Конечно, используйте этот вариант только в том случае, если это то, что вам нужно.

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

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

Трекер проблем можно сделать таким же образом — если ваша VCS поставляется с ним, используйте его, в противном случае установите веб-трекер и покажите людям, как его использовать.

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

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

Ваш вопрос на самом деле двоякий:

1. Если вы сообщите руководству, что собираетесь покинуть компанию.
2. Как улучшить/внедрить лучшие практики.

Теперь на эти два ответа было много на этом сайте, но вот основы.

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

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

Я нахожусь в аналогичном положении (и я действительно рассматривал возможность публикации этого для предложений), за исключением того факта, что у меня действительно есть проблемы с убеждением МОЕЙ СОБСТВЕННОЙ КОМАНДЫ И МЕНЕДЖЕРОВ использовать инструменты контроля версий и управления проектами. И хотя это может быть не совсем то, что вы ищете (я ответил в конце поста), возможно, это поможет вам понять, почему некоторые компании такие.

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

В моем случае ситуация расстраивает, поскольку:

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

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

в) менеджер часто назначает встречи с отдельными членами моей команды, чтобы назначить новые задачи (изменить функциональность и дизайн) в проектах, где работает вся команда, или снять их с проекта на неопределенное время и не уведомить остальных команды (или меня в данном случае) и внести изменения в Trello/Freedcamp

Я пробовал все, что мог придумать:

• Настроили команды BitBucket, но в итоге мы все испортили, потому что некоторые отказываются фиксировать и отправлять свой код.
• Я пытался настроить инструменты управления проектами (Trello/Freedcamp), но, как я уже упоминал выше (c), они кажутся бесполезными.
• Члены команды забывают или отказываются изменять статус своих задач или заполнять новые задачи при необходимости (ошибки, возможные проблемы и т. д.), потому что считают это пустой тратой времени (ведь если они могут хранить свои записи в Sublime Text или Notepad, это нормально), поэтому вся команда не знает об этих вещах (и это вызывало много проблем в прошлом). Не говоря уже о том, что никто из дизайнеров UI/UX ничего не заполнял НИКОГДА (у художников нет на это времени, говорят они), в результате чего разработчики работали над функциями пользовательского интерфейса, которые в любом случае собирались удалить или изменить. Иногда менеджер отправляет некоторые электронные таблицы или электронные письма определенным членам команды, оставляя остальных в стороне.
• Мы настроили Facebook Workplace для улучшения коммуникации и создали группы для всех проектов, команд, отделов и т. д. Но единственная используемая группа — это жареная.
• Некоторое время мне фактически приходилось вручную получать архивы приложений на моей рабочей станции и вручную проверять каждую строку кода для слияния изменений. Кроме того, я пытался каждое утро разговаривать с моими менеджерами и после каждой встречи, которую он проводил с членами моей команды, чтобы получить все задачи, чтобы заполнить их самостоятельно. Все это привело к тому, что я тратил половину своего времени на проверку работы других людей вместо того, чтобы делать свою, таким образом, b) выше.
• В итоге я организовал встречи со всем управленческим персоналом и объяснил ситуацию, и в результате мы решили проводить стендап-встречи каждый день и одну встречу в конце недели, чтобы заставить всех делать свою работу, но в конце концов , это не сработало.
• Я даже написал практическое руководство, основанное на здравом смысле, которое даже включало как использовать BitBucket, Trello и другие инструменты, которые мы используем, но люди просто проигнорировали его.

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

Теперь, чтобы ответить на ваши вопросы:

1) Должен ли я сообщить руководству, что рассматриваю возможность ухода из компании из-за такой практики?

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

2) Или, по крайней мере, пусть они знают, что я расстраиваюсь?

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

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

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

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

Например, одной из моих самых больших проблем была наша система сборки. Это был беспорядочный беспорядок, чрезвычайно подверженный ошибкам и медленный. Полная сборка могла занять 35-45 минут, а итерации разработки/тестирования были медленными. Я переписал систему сборки с помощью Makefiles, но никому не было интересно изучать новый инструмент. По крайней мере, до тех пор, пока я не работал со старшим разработчиком над исправлением ошибки. Мы внесли изменения и запустили сборку, чтобы протестировать ее. Старший предложил пойти пообедать, пока мы ждем сборки. Я попросил его подождать, и когда моя сборка завершилась примерно за 90 секунд, он явно смутился. Я сказал ему: «Это новая система сборки, о которой я говорил вам ранее, вы действительно должны попробовать ее, она экономит так много времени». За то время, которое он рассчитывал потратить на одну сборку, мы сделали полдюжины циклов редактирования/компиляции/тестирования. Нам удалось решить проблему и доставить исправление клиенту на несколько дней раньше, чем было обещано. Ясно увидев, сколько времени и разочарований он сэкономит ежедневно, он переключился на новую систему.

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

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

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

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

Что сказать, уходя

Когда сказать об уходе

Примечание: вы добавили к вопросу, что речь идет о крупной международной компании. Это означает, что существует большая инерция для внедрения изменений. Это сочетается с «менеджером команды ушел» и с «плохой практикой». Поэтому я бы (как бы) забыл о первом варианте.

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

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

Насколько это было плохо? (примечание: это было более 10 лет назад)

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

• Доступ к сети был только через Wi-Fi и превысил максимальную пропускную способность примерно на 200 человек. Я взял кримпер, несколько кат-5 и колпачки в Radio Shack (RIP), чтобы я мог сделать 30-футовый кабель Ethernet, чтобы добраться до порта Ethernet с моего места на длинном столе в стиле кафетерия, за которым я работал. За первую неделю ожидания ноутбука я уже научился надеяться на помощь кого-то, напоминающего специализированный ИТ-отдел. За почти год моего пребывания там эта ситуация так и не была исправлена. На самом деле стало хуже.

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

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

• Главный фактор низкой производительности нашего сайта? Наши запросы насмерть заглушались чем-то вроде дюжины избыточных аналитических платформ, которые использовались, чтобы увидеть, как у нас дела (я мог бы сказать им: не очень). За 11 месяцев моего пребывания там мы так и не смогли заставить кого-то отказаться от одной из глупых вещей, потому что почему-то не было привратника. Подумай об этом. Они душили производительность и, как следствие, продажи, поэтому они могли следить за тем, насколько хорошо они не могут добиться успеха, потому что никто не хотел изучать аналитическую платформу, кроме первой, с которой они когда-либо сталкивались. Вместо этого мы сосредоточили большую часть нашего времени вне встреч на гораздо более важных вещах для очень скромного прироста производительности. Я получил награду за смехотворные неудачи, которых мне удалось добиться в этой команде. Он поставлялся с подарочным сертификатом на 10 долларов в столовой компании, которая была очень похожа на общественную школьную столовую, только без всех !@#$. Чтобы получить награду, потребовалось около 4 часов в пути, чтобы добраться до штаб-квартиры корпорации, которая давно была перенесена за город, вероятно, потому, что кто-то наверху в какой-то момент захотел, чтобы она была ближе к их дому. Подсказка: раньше он находился в довольно высоком здании одноименной марки.

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

• Внутренние разработки были переданы на аутсорсинг крупнейшей офшорной аутсорсинговой фирме на планете (основатель этой компании, по-видимому, был приятелем по колледжу с нужным человеком). Уровень квалификации сотрудников этой фирмы варьировался от фактически неграмотных в коде до начального уровня и полностью и безнадежно не в состоянии что-либо изменить, поскольку неграмотные в коде типы, как правило, поднимались наверх. Они не использовали контроль версий. У них был огромный общий сетевой каталог. Их 200 или около того (не считая офшорных) разработчиков регулярно копировали целые каталоги, в результате чего части сайта, над которыми никто активно не работал, возвращались, видоизменялись и разваливались. Большая часть нашей работы заключалась в том, чтобы согнуть и изуродовать внешний интерфейс, вернув его на место, с ограниченным контролем над HTML, чтобы никто с их стороны не должен был брать на себя ответственность за свою некомпетентность. Я' С тех пор я сравнил истории с другими людьми, имевшими опыт работы с этой фирмой в других компаниях. Хотя их истории определенно не были положительными, они были далеко не такими плохими, и теперь я убежден, что они использовали нас в качестве испытательного полигона для разработчиков, которых они не удосужились проверить, чтобы они могли продвигаться к более разборчивым заданиям в других местах. компании, скрывая своих бесполезных сотрудников за игрой с обвинением, которая была легкой игрой в нашей компании.

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

• Увольнение графического дизайнера, в основном из-за недовольства слишком большим количеством поваров на каждой кухне, что приводит к постоянным изменениям в их работе после дедлайна, было настолько сильным, что в какой-то момент мы действительно закончились. Тридцать фронтенд-разработчиков. 0 дизайнеров. Более типичное соотношение между дизайнером и разработчиком составляет примерно 1:4. Ничего, кроме исправления ошибок в течение нескольких недель. Иногда повторяются одни и те же ошибки (см. выше ситуацию с перезаписью папки).

Поверьте мне. Я старался быть позитивным. Я пытался рассуждать. Я попытался показать лучший способ. Я попытался сформулировать свои запросы о здравомыслии с точки зрения успеха компании, а не абстрактных понятий, таких как «широко признанные передовые методы, применяемые всеми». В конце концов я понял, что только что провел последние 11 месяцев, проходя через 5 стадий горя, например:

• Отрицание
• Злость
• Торг
• Депрессия
• Принятие

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

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

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

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

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

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