Я технический референт, но потерял лидерство по техническим решениям

Эта строчка разрушила мое доверие к руководителям вашей фирмы:

Больше никакой разработки через тестирование и модульных тестов.

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

Это плохое программирование, плохой бизнес и выдает непонимание системного мышления. Таким людям нельзя доверять. Они не способны надежно принимать правильные решения в ЛЮБОЙ области бизнеса.

Без системного мышления лидеры в долгосрочной перспективе навредят вам.

Уберайся немедленно.

Помните, что кодирование не существует в вакууме. Даже далекий от идеала код может решить реальные деловые или гуманитарные проблемы.

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

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

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

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

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

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

Я участвовал в этой битве более двух раз.

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

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

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

Это не ваш продукт, в основном вам нужно соответствовать или двигаться дальше.

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

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

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

Держите свои деньги там, где ваш рот. Оставлять.

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

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

В качестве альтернативы свяжитесь с вышестоящим и попытайтесь найти способ заставить все работать на приемлемом уровне. Хотя, возможно, они работают с людьми, которые скорее должны переворачивать гамбургеры в McDonalds — это видно во многих крупных компаниях. Однажды меня наняли обучать разработчиков VB C#. Учебная программа на один месяц сжата до 3 дней («мы не можем позволить им не работать в течение месяца, и все они опытные разработчики»). Ну, опытные разработчики не знали разницы между массивом и хеш-таблицей/словарем на фундаментальном уровне, поэтому все время было потрачено впустую. Это уровень в некоторых компаниях.

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

Я бы сосредоточился на разных вещах. Потому что:

Больше никакой разработки через тестирование и модульных тестов.

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

Нет таких требовательных проверок кода.

Это тоже понятно. ИМХО уровень требовательности нужно повышать постепенно, чтобы люди могли осваивать новые навыки.

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

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

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

Но больше всего меня тревожит другая часть:

У нас была встреча (без меня так), и мы отказались от некоторых методологий, которые вы рекомендовали.

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

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

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

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

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

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

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

Я вижу несколько проблем, которые могут возникнуть с этим диссонансом (тот факт, что вы думаете, что они наняли вас для одной цели, по сравнению с реальной причиной):

1. Отсутствие целей:

   • Они сказали вам, что они ожидали от вас?
   • Вы спросили, что они хотели?
   • Вы пропустили что-то, что они сказали вам?
   • Возможно, вы слышали: «Нам нужен качественный софт!» когда они имели в виду «Мы хотим программное обеспечение, которое люди используют!».

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

   • Как вы сообщили об этом?
   • Ты ехал слишком быстро?
   • Все ли знали о последствиях, потому что всегда есть компромисс?
   • Вы объяснили, что кривая обучения повредит производительности?

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

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

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

Но если и есть что спасти, так это доверие и терпение. Если что-то,

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

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

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