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

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

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

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

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

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

Итак, вот мое обновление с тем, что я сделал. Мне потребовалось немного времени, чтобы собрать кусочки вместе. Команда проекта решила продолжить тестирование закодированного пользовательского интерфейса (с использованием инструментов Visual Studio 2012), так что, по крайней мере, я буду чему-то учиться и избавлюсь от болезненных ощущений от повторения. Нам пришлось убедить моего босса в этом подходе, но все члены моей команды поддержали меня. Кроме того, некоторые недавние беседы с менеджерами о том, как распределяется работа в группе, помогли мне понять, что корень проблемы неустраним. Хорошей работы не хватает, и вряд ли это изменится. Так что я также рассматриваю другие вакансии. Я хотел бы отметить несколько ответов как ответ, потому что многие из вас дали отличные идеи, и я чувствую, что включил несколько в свое «решение». и в моем мышлении. Спасибо сообществу Stack Exchange.

Как долго вы были разработчиком программного обеспечения до получения этого задания?
около 6 лет в этой работе. До этого два года на младшей должности на другой работе.
и это должно быть ручное тестирование? Может быть, вы можете написать несколько автоматических тестов?
Не могли бы вы описать, кто еще входит в команду проекта? Ответы, вероятно, будут другими, если вы единственный человек в команде и нет никакого другого тестирования, и руководство решило, что это будет ручное тестирование, а не, скажем, ситуация, в которой у вас есть 5 разработчиков, 2 QA тестировщики, непрерывная интеграция и модульные тесты повсюду, и... вы.
У нас нет отдела контроля качества, мы обычно полагаемся на наших бизнес-клиентов для тестирования (это внутренние приложения). Есть трое парней и я. Это проект MVC, новая технология для всех нас. Остальные были вовлечены в первую фазу проекта, а я нет.
Благодарю за разъяснение. Этот последний момент является ключевым - это, вероятно, не о вас , а скорее о том, чтобы вытащить короткую соломинку, поскольку вы не были глубоко вовлечены в первую фазу. Черт возьми, подумайте обо всем, что вы можете найти, глядя на это свежим взглядом! :)
Много хороших предложений ниже. Спасибо всем за участие. Я собираюсь попробовать некоторые из этих идей, и я дам вам знать, как это получается. Не стесняйтесь публиковать больше идей. Прямо сейчас я думаю попробовать предложить кому-то другому выполнить ручную часть тестирования под моим руководством, или, если это не удастся, попросить чередовать обязанности. И попробуйте автоматизировать часть этого. Я также собираюсь обновить свое резюме и деятельность в сети, на всякий случай.
Уволить себя технически не значит уйти, и это тоже может быть очень весело.
«У нас нет QA» — это довольно глупо с вашей стороны, вы думали убедить их нанять тестировщика? Я имею в виду - хорошо, может быть действительно сложно выяснить, сколько тестировщиков будет лучше всего для проекта, хорошо. Но иметь хотя бы одного тестера — это просто беспроигрышный вариант — попробовать действительно стоит.
Ну, я ненавижу дождь на вашем параде, но иногда вам приходится сгибаться и выполнять черновую работу - это не все радуги и единороги. Хотя я бы предложил разделить работу между членами команды, чтобы каждый сказал 2 месяца на QA
Если бы вам разрешили писать модульные тесты, 6 месяцев ручного тестирования можно было бы значительно сократить!
Что я делал в прошлом, так это ждал истечения срока действия контракта и не продлевал его. ... и скажите об этом за месяц или около того, чтобы они не предполагали, что вы это сделаете. Кроме того, в этом состоянии человек МОЖЕТ выйти из игры и по-прежнему получать неудовольствие, ЕСЛИ у него есть достаточная причина.
Цените новости о ситуации. Сложная ситуация. Удачи.

Ответы (8)

Оставлять.

Серьезно уходи.

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

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

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

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

В вопросе конкретно сказаноHow can I get out of this situation without leaving my job?
@enderland: Если бы кто-нибудь спросил вас: «Как я могу недорого слетать из Нью-Йорка в Сан-Франциско без самолета?», что бы вы ответили? // Видите ли, иногда люди задают не тот вопрос. Это то, чему в какой-то момент своей карьеры учится каждый опытный специалист по программному обеспечению. Если вы профессионал в области программного обеспечения, я надеюсь, что вы тоже узнаете об этом.
@ Джим Г. Возможно, можно было бы рассмотреть вертолеты, катание на птицах или НЛО. ;)
@JB King: Вертолет из Нью-Йорка в Сан-Франциско? Серьезно?
Я готов рассмотреть возможность того, что уход - единственный хороший вариант, но сначала я хотел бы убедиться, что не упускаю из виду другие варианты. Моя нынешняя работа связана со многими другими вещами. Может, есть НЛО, о котором я не знаю?
@Eden: Эй, если ты готов провести шесть месяцев в поисках своего «НЛО», то, может быть, это не так уж и плохо. Я просто знаю, что шесть месяцев ручного тестирования не будут хорошо смотреться в резюме разработчика программного обеспечения. Потенциальные работодатели на будущих собеседованиях при приеме на работу будут задавать вопросы и удивляться, почему именно вас (среди нескольких других разработчиков) выбрали для шестимесячного ручного тестирования.
@ Джим Г., идея заключалась в том, чтобы брать нетрадиционные ответы. Я полагаю, что Airwolf сможет добраться из Нью-Йорка в Сан-Франциско.
@JimG Я тоже задаюсь вопросом, почему меня выбрали, потому что я такой же хороший разработчик, как и многие другие в моей команде, и даже лучше, чем некоторые.
@Eden: Для целей нашего разговора я не сомневаюсь, что да. К сожалению, на данный момент имеет значение только мнение вашего босса. Вот почему я думаю, что вам нужно ответить.
+1, меня не волнует, не является ли это строго ответом на заданный вопрос; это правильное решение проблемы, которая была представлена. Шесть лет — это долгий срок, чтобы работать только на второй работе — вы должны делать это только в том случае, если ваша работа неуклонно продвигает вашу карьеру. Шесть месяцев ручного тестирования для разработчика — это серьезный регресс в карьере; вы саботируете свое будущее, если делаете это.
@Eden Они взяли твой степлер и перенесли тебя в котельную. Вы уверены, что до сих пор получаете зарплату? Начните смотреть вокруг немного больше. Вы можете быть удивлены тем, что там. Любая работа, где они просто предполагают, что вы будете круты с этим, — это та, где они предполагают, что люди остаются только ради инерции. Они не устанавливают планку очень высоко. Кроме того, Blue Thunder, а не Airwolf. Airwolf был вымыслом.
+1 Честно говоря, если бы я брал интервью у ОП, я бы НИКОГДА не нанял их на должность разработчика после 6 месяцев ручного тестирования. ОП нужно бежать!
@suslik: это именно моя точка зрения. Я просто говорил правду. Тем не менее, этот ответ был сильно отклонен. Иди разберись.
@ДжимГ. На этом веб-сайте полно людей, которые задают такие вопросы, как «У меня была тупиковая карьера последние X лет, как мне выбраться из нее сейчас?» и вы не можете легко возвести этот круг в квадрат. 6 месяцев в IT — это очень много. Я не понимаю людей, которые минусуют этот ответ. Если бы ОП спросил: «Как мне зажечь мокрое бревно без спичек?» правильный ответ: «Извини, приятель, ты, наверное, не можешь». Это то же самое, когда руководство пытается заставить вас пройти 6 месяцев QA, неважно, что они вам говорят, вы бежите!

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

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

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

Здесь нет идеального — да, 6 месяцев ручного тестирования для человека среднего уровня (6 лет для меня звучит как средний уровень) — неэффективный компромисс. Однако ожидание в течение 3 месяцев, чтобы нанять дешевого стажера, может задержать продукт до такой степени, что он не будет соответствовать требованиям времени выхода на рынок в конкурентной отрасли, поэтому, если бы мне пришлось потратить в 4 раза больше денег (при условии, что стажер зарабатывает четверть того, что вы зарабатываете...), я бы сделал это, если бы это давало надежду на 10-кратную прибыль (а она могла бы).

Мысли для шагов...

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

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

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

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

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

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

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

Здесь есть очень хорошая пища для размышлений.

Хорошо, я думаю, что из другого ответа очевидно, что один вариант остается. Однако, учитывая, что вы сказали это

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

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

Что вам нужно сделать, это предложить либо

  1. Кто-то еще делает это тестирование
  2. Вы сможете сделать это с помощью автоматизированных тестов и т. д.

Найдите кого-нибудь еще для тестирования

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

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

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

  1. Нанять кого-то временно
  2. Пусть другой член команды, которому платят меньше, выполняет работу
  3. Делегат в отдел контроля качества

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

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

Выполняйте задание... но не вручную

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

Помните, что ваш босс заботится о вещах, отличных от вас. Вы хотите поставить вещи в его условиях.

  1. Предложите подход, при котором вся ваша команда занимается чем-то вроде 4 дней разработки и 1 дня тестирования. Как-то разделить работу между всеми разработчиками.
  2. Разработка автоматизированных тестов.

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

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

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

+1: не вручную. Нет причин проводить повторное тестирование вручную. Изучите Selenium и помогите команде разработать веб-страницы, чтобы тесты были стабильными. Если команда разработчиков не будет поддерживать автоматизированные тесты, пора уходить.
@kevincline Честно говоря, это должен быть ответ. Кажется, что все несправедливо классифицируют QA как бездумных клавиатурных сокрушителей, когда это может быть гораздо больше. Использование инструментов для автоматизированного тестирования, написание сложных сценариев тестирования, определение стратегий тестирования и управление сборками и развертыванием тестовой среды — это высокотехнологичная и высокооплачиваемая работа. Не следует сбрасывать со счетов то, как использование этой возможности для изучения этих навыков может улучшить свои способности как разработчика программного обеспечения, а также улучшить свою карьеру.
Большая часть этого ответа хороша, но оскорбления тестировщиков программного обеспечения неуместны, имхо.

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

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

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

Путь «дорогого разработчика» действителен только в том случае, если есть другая работа по разработке; если у компании есть финансовые проблемы, они могут пойти на уступки, сократить вашу роль и нанять гораздо более дешевого QA/тестировщика или даже аутсорсинга.

Решения могут быть:

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

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

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

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

Отличные решения, особенно с учетом описания окружающей среды в ОП, которое похоже на ситуацию, в которой есть немного бесхозяйственности и много места для предложений и способов превратить это в позитив. Если ОП может добиться каких-либо действий по любому из ваших предложений, не говоря уже обо всех них, это очень хороший опыт в общении, конструктивной аргументации, управлении ресурсами и т. Д., И какой хороший набор опыта можно обсудить на будущих собеседованиях при приеме на работу. , должен ли ОП в конечном итоге двигаться дальше, а не что-то вроде «Мои таланты были потрачены впустую» (что все еще может быть правдой).
Хорошая мысль о лучшей истории интервью, если вы сначала попробуете несколько вариантов...
К сожалению, принятие одного для команды может повредить вашей карьере. Сейчас вы являетесь частью команды, но через 6 месяцев все будут думать о вас как о «тестере».
@thursdaysgeek — балансировать между личными и командными целями всегда сложно, особенно в среде Agile/Scrum. Я ожидаю, что моя команда ставит «пользовательский» результат выше своих личных целей, что обычно означает «командный результат». Моя команда знает это и доверяет мне, чтобы гарантировать, что ни у кого не останется только «ростков на тарелке» (если использовать нашу командную фразу) и никаких обещаний «пустыни». Чтобы было ясно, я бы никогда не предложил просто «взять одного для команды», если вы не получили от своего босса какого-либо письменного рычага влияния на вознаграждение / выгоду, которую вы получите. Узнал, что на собственном горьком опыте.
@thursdaysgeek - Я также хотел бы предположить, что способность продемонстрировать способность вести переговоры по убедительному взаимовыгодному бизнес-кейсу лицом к лицу с вашим менеджером является важным аспектом многих карьер. Когда я нанимаю, повышение сплоченности в команде разработчиков имеет такое же значение, как и технические навыки и способности; отличные технические навыки не имеют для меня значения, если они сочетаются с беспроигрышным, конфронтационным или пассивно-агрессивным подходом к обсуждениям.
@GuyM - ты говоришь и компетентно, и рационально. Беспроигрышный вариант — лучший результат, но бывают случаи, когда руководство не интересует ничего, кроме собственных краткосрочных целей. В некоторых из этих случаев, но не во всех, все еще можно найти беспроигрышную ситуацию. Однако у вас есть и хорошие моменты, методы, помогающие в работе с нефункциональными командами.

Нет причин проводить повторное тестирование вручную. Изучите Selenium и помогите команде разработать веб-страницы, чтобы тесты были стабильными. Если команда разработчиков не будет поддерживать автоматизированные тесты, то пора искать лучшую позицию.

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

@gnat: хорошо, ты должен получить половину репутации за это.

Отправьте менеджеру ссылку на эту статью:

Пять основных (неправильных) причин, по которым у вас нет тестировщиков

Вот один из пунктов статьи:

Как бы ни было сложно найти тестировщиков, они все равно дешевле программистов. Намного дешевле. А если вы не наймете тестировщиков, тестированием займутся программисты. И если вы считаете, что это плохо, когда у вас есть тестировщики, просто подождите, пока вы не увидите, как дорого обходится замена этого звездного программиста за 100 000 долларов в год, который устал от того, что ему говорят: «потратьте несколько недель на тестирование, прежде чем мы выпустим». " и перешел в более профессиональную компанию. Вы можете нанять трех тестировщиков на год только для того, чтобы покрыть гонорар рекрутера за замену программиста.

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

Я был бы осторожен с этим подходом; хотя вполне вероятно, что это правда, компания получит экономическую выгоду только за счет увольнения всех разработчиков, занимающихся тестированием, и найма более дешевых тестировщиков. Возможно, они пытаются избежать увольнения хорошего сотрудника, для которого нет работы в ближайшие полгода, в надежде, что дела пойдут лучше.
Кроме того, я не уверен, что хотел бы оскорбить интеллект моего босса. На мой вкус это кажется немного пассивно-агрессивным. Я не говорю, что это плохая идея, но я бы определенно предложил более легкий подход.
@GuyM : ИМХО, в этом случае принуждение разработчиков работать тестировщиками выглядит еще хуже (скорее всего, это будет одно из неверных решений того же руководства, которое довело компанию до необходимости увольнений - и будущее такой компании редко бывает шустрым, не лучше ли уволиться после 6 месяцев рабства тестировщиком?
@ jmort253 jmort253: я бы определенно предложил более легкий подход , не могли бы вы привести пример такого подхода? Я не имел в виду оскорбление (конечно, не надо тыкать своим начальством нос в этой статье), но, поскольку Спольски хорошо известен и уважаем, с его мнением можно считаться.
Привет, Стив. Конечно. Совет верный, и уважаемый профессионал подчеркнул важный момент. Однако, исходя из опыта, пытаясь убедить людей принять мою точку зрения, говоря: «Послушайте, такой-то говорит X, поэтому мы должны сделать X», иногда это может иметь неприятные последствия. С учетом сказанного, использование аргументов Спольски для формулирования и адаптации ваших собственных аргументов может работать лучше, чем размещение ссылки в почтовом ящике вашего босса. Надеюсь это поможет! :)
Успешно справился. Прямо на деньги.
@SteveV - это зависит; Я видел компании, у которых были краткосрочные проблемы из-за проблем с денежными потоками, которые были решены в этот период времени, а некоторые из них рухнули. Многое зависит от плюсов и минусов компании в долгосрочной перспективе.
@GuyM: можете ли вы представить себе такую ​​компанию, которая пытается сэкономить на счетах за уборку и просит разработчиков поработать дворником несколько месяцев, пока финансовое положение не улучшится?
@SteveV - Такой аргумент «соломенного человечка» не очень полезен в этом контексте. Есть много компаний, которые сейчас сталкиваются с проблемами денежных потоков и инвестиций, которые заботятся о своих командах и борются с вариантами. Имея выбор между увольнением сотрудника и поиском альтернативной работы, которая может не полностью соответствовать его набору навыков, я бы выбрал последнее, но подробно обсудил с ним, а не пожимал плечами, делал их роль избыточной и затем нанимал более дешевых людей. . Не каждая фирма может просто нанимать все больше и больше людей для покрытия ролей, в то время как другие используются недостаточно.
@SteveV - и серьезно отнеситесь к вашему обсуждению соломенного человека на секунду; Сократил бы я контракт на уборку, чтобы сохранить рабочие места для персонала и, возможно, для компании? Да. Поручу ли я разработчику быть чище? Нет. Я бы попросил персонал сделать все возможное, чтобы офис был чистым и опрятным, и, возможно, мчался вокруг себя, чтобы убедиться, что он презентабельный, прежде чем клиент/инвестор войдет в дверь, а может быть, и каждую ночь. Чтобы ты делал?
@GuyM: мне кажется, что это ты хватаешься за соломинку ;). Оригинальный пост ничего не говорит о финансовых проблемах компании. Кроме того, в нем говорится: «Нет отдела контроля качества, обычно полагающегося на наших бизнес-клиентов для проведения тестирования» . Похоже, это не временная неудача, просто так работает компания; у них нет QA, поэтому они всегда ищут какого-нибудь беднягу, который будет заниматься тестированием (и можете быть уверены, что это никогда не будет один из менеджеров)
@GuyM: Поручу ли я разработчику быть чище? Нет. ---------- Вот, пожалуйста, это ответ на ситуацию "разработчик становится тестировщиком". Как я пытался сказать, такой подход неприемлем. ---------- Я бы попросил персонал сделать все возможное, чтобы поддерживать офис в чистоте и порядке, и, возможно, бегать вокруг себя, чтобы убедиться, что он презентабельный, прежде чем клиент/инвестор войдет в дверь, и, возможно, каждую ночь. Чтобы ты делал? ---------- Наверное, тоже самое (но я не менеджер, я разработчик)
Я действительно предлагаю несколько вещей. Во-первых, сообщение менеджеру о том, что решение краткосрочной проблемы с ресурсами заключается в реструктуризации или увеличении численности персонала, может иметь неожиданные последствия, и стоит подумать, какими они могут быть, прежде чем делать предложение, и что это может означать для вас лично. Во-вторых, если у вас не было хорошего объяснения звонка руководству, который вы считаете неверным, возможно, стоит попросить объяснения, прежде чем делать предположения. Хорошие менеджеры ответят и приложат больше усилий в следующий раз. Не работайте на плохих менеджеров.
@GuyM по моему личному опыту, «прямая» тактика, подобная предложенной в этом ответе, действительно сработала. Вероятно, это тот случай, когда действительно имеет смысл прямо указать руководству на устоявшиеся профессиональные практики , чтобы они поняли, что писают против ветра.

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

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

Ух ты! Я даже не думал... Как вы думаете, босс @Eden рассматривал этот вариант?
@ДжимГ. Даааааа, если его начальник не рассматривал этот явно очевидный вариант, то либо он плохой начальник, либо пытается заставить Идена добровольно уволиться, чтобы компании не приходилось платить по безработице. Вы должны применять «бритву Хэнлона» и все такое, но говорить разработчику «нет, вы не можете играть с новой блестящей технологией, вы можете сидеть в углу и проводить повторяющиеся тесты» — это просто плохо.
@Tacroy: согласен на 1000%.
Это, пожалуй, одна из возможных возможностей, которые вытекают из этого. Данный ОП может довести себя до положения, когда он может возглавить разработку спецификаций требований. и имеет право требовать от команды разработчиков архитектуры и функциональности, QA-архитектурная роль (которая в этом случае также будет включать в себя некоторое тестирование для проверки требований) может даже продвинуть карьеру вперед. Это предполагает, что BOSS считает хорошей идеей дать такую ​​силу OP. Просто очистка тестовых спецификаций. это просто пустая трата времени.

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

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

Я проголосовал за это, потому что многое можно сказать о том, как сделать себя более ценным в организации. Это не только гарантирует, что у вас будет больше шансов занять должность, соответствующую вашим навыкам, но вы также можете добавить в свой пост, что это делает вас более похожим на командного игрока! :)
Я считаю, что есть улучшения, потому что вы будете смотреть на разработку своего будущего приложения, зная, насколько болезненным это может быть для пользователя. Изучение того, что думают тестировщики и пользователи, никогда не было тратой моего времени. Программистам нужно избавиться от менталитета "Я в зоне и не хочу, чтобы меня беспокоили чьи-либо потребности". Это контрпродуктивно и является одной из причин того, почему так много программного обеспечения трудно использовать и оно так сильно раздражает пользователей. Ваша работа включает в себя гораздо больше, чем только вы и код.
вы будете знать, что ищут тестировщики и как пользователю неудобно работать с плохо разработанным пользовательским интерфейсом -------------- 1) тестировщики ищут ошибки (сюрприз!); плохо спроектированный пользовательский интерфейс — результат работы некомпетентного UI-специалиста и продакт-менеджера; все, что не имеет ничего общего с программированием, поэтому я не вижу, как это может помочь в будущем (если только кто-то не будет искать программиста с амбициями эксперта по пользовательскому интерфейсу и т. д.)
в большинстве мест, где я работал, программисты разрабатывали графический интерфейс. Программисты ищут ошибки иначе, чем программисты, это только показывает ваше невежество, что вы думаете, что не узнаете что-то.
Шесть месяцев ручного тестирования — очень плохое решение для программиста. Этого достаточно, чтобы отучиться от энергичных привычек программирования и терять время против современных технологий.
Как я могу уйти с плохой работы, не увольняясь?
СпросиСетьПолитика конфиденциальности1y, 0v