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

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

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

От теста Джоэла: 12 шагов к лучшему коду

9. Используете ли вы лучшие инструменты, которые можно купить за деньги?

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

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

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

Я никогда не работал в такой компании, но думаю, что мне следует бросить это в ринг для переговоров. Кажется разумным. Как крупные компании, такие как MS, Google и Apple, справляются с этим? Если вы говорите «да», укажите диапазон ... Мне сказали, что цифры от 5 до 10 тысяч долларов. Мне кажется, высоко, но я бы с радостью принял это.

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

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

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

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

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

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

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

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

Это удобно

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

Нет абсолютно никакого смысла расстраивать сотрудников.

Не портитесь

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

Я не хочу, чтобы люди были одержимы вечной молодостью, и это касается и оборудования.
^{(Однако с программными проектами я склоняюсь к тому, чтобы максимально приблизиться к последнему выпуску ... Аналогии не всегда имеют место :))}

Конкретные потребности для конкретного оборудования

Я думаю, что следует проводить различие между:

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

Базовый пакет

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

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

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

Бонусы

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

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

Если вы разработчик, которому необходимо одновременно запускать 4 сервера приложений, создавать проекты и постоянно открывать 3 экземпляра Eclipse или Visual Studio, вам, очевидно, понадобится довольно конкурентоспособная рабочая станция. Я бы подумал, что это «основные потребности» для разработчиков , так что это не означает, что маркетинговые парни обязательно должны быть согласованы с этим.

Создайте свой кейс: Hard-Data для победы

Исходя из опыта, большинство компаний понимают ваши потребности, если вы можете доказать, что они законны. Если вы сможете защитить обоснование этого, они выкашлят деньги или попытаются удовлетворить вас. Они платят тебе за работу , поэтому они действительно не хотят, чтобы ты тратил время.
^{(То есть, если они хоть немного заботятся о вашей работе ... если вы не относитесь к делу, я боюсь, что вам не повезло ...)}

Показать прибыль для вас

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

Покажите им прибыль (деньги - корень всего зла ...)

Что касается вышеприведенного примера, мы, например, рассчитали время сборки и возможное сокращение, а также провели сравнение между различными настройками, присутствующими в компании, вычислили среднее количество потерянного времени на одного разработчика в день, а затем заставили их понять, что на человека в течение года приходилось примерно 20 полных дней на неспособность что-либо сделать (поскольку компьютер в основном не отвечал бы, если бы у вас не было хотя бы четырехъядерного процессора и 8 ГБ ОЗУ для этой сборки). Раз количество разработчиков, это огромное количество часов, которые они платят людям, чтобы они ничего не делали, что было намного выше, чем модернизация хотя бы некоторых станций.

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

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

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

Строить планы

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

Краткое примечание о крупных обновлениях для всей команды

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

• он распределяет стоимость в течение более длительного периода ,
• это дает время, чтобы сгладить переходные проблемы («упс, просто понимая, что этот ЦП в сочетании с этой версией ОС фактически создает проблемы при кросс-компиляции нашего продукта X для другой платформы X»),
• это предотвращает застревание всей команды в адском обслуживании ИТ с переустановкой системы, обновлениями системы и обычными проблемами с чистым списком, или случайными неудачами («к сожалению, удалили эту важную резервную копию ...»).

Признать поражение: это не всегда работает на все ...

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

Кроме того, если вам трудно построить ваше дело :

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

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

Ежегодное индивидуальное пособие на оборудование - опасный путь для:

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

• Как насчет общего оборудования? серверы, маршрутизаторы, системные администраторы, лицензионное / корпоративное программное обеспечение ... Если бы я был боссом, я бы продал эти услуги как часть пособия.

• Как насчет идти дальше? телефон, стол, офис, кофеварка, электричество, кондиционер ...

Годовая зарплата инженеров высока, поэтому инвестиции в оборудование - это хорошо. 5-10k $ - ничто, если его использовать хорошо.

Процитирую автора библиотеки Boost MSM :

Время компиляции конечных автоматов с> 80 переходами, которые заставят вас штурмовать офис финансового директора и убедиться, что вы получите блестящий октокор с 12 ГБ ОЗУ на следующей неделе, если он не заинтересован в том, чтобы платить вам, наблюдая за агонизирующим часами компилятором ... ( Убедитесь, что вы просите двойной 24 ", это не повредит).

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

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

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

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

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

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

Удивлены еще?

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

Ли люди также отслеживать гарантии на оборудование? Время потрачено впустую, административная проблема, если нет.

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

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

Я думаю, что годовой бюджет является пустой тратой денег - оборудование не устареет , что быстро. Я думаю, что лучше обновлять, когда производительность резко возрастает до того уровня, на котором стоит переключиться, например, когда двухъядерные процессоры были заменены на четырехъядерные или 6-ядерные, когда Windows 7 заменяла Windows Vista и XP, когда терабайтный жесткий диски заменили диски на 200 или 300 Мб, а когда SSD диски вышли. Все это были значительные улучшения.

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

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

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

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

Я никогда не встречался с таким бюджетом. По долгосрочным контрактам корпорации предоставляют компьютерные комплектующие и заботятся о том, что что-то сломается. Это более рационально, чем давать работникам деньги и ожидать, что они купят за них то, что они хотят. Что, когда у кого-то сломался ноутбук? Несколько дней потрачены впустую, прежде чем он / она отремонтирует его или купит новые детали и т. Д. Когда компания управляет оборудованием, он / она получит замену сломанного ноутбука в течение нескольких часов.

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

Когда компания, в которой я работаю, начала свою деятельность, у нас было персональное аппаратное пособие в размере 1500 долларов. Сотрудники могли покупать оборудование для работы на дому и оплачивать его. Поскольку компания была куплена и продана, мы потеряли эту хорошую выгоду. Наш нынешний ИТ-отдел будет поставлять разработчикам первоклассное оборудование, но оно принадлежит одному из крупных поставщиков (HP, Dell, Lenovo и т. Д.).

Ежегодное обновление не требуется. Я зависит от инструментов против производительности системы.

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

Это в основном хорошо для организации, так как сокращает время разработки.

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

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

Обычно это стоит больше разработчика, чем деньги.