.net - ventajas - Justificación de la máquina del desarrollador
visual studio c++ (16)
A menos que esté contratando desarrolladores incompetentes o sus desarrolladores están haciendo demandas extremadamente ridículas, el retorno de la inversión es casi siempre de órdenes de magnitud mayor que el costo de una estación de trabajo. Incluso una máquina de alta potencia con un monitor de 30 "es barata en comparación con el salario de un buen desarrollador, de todos modos. Es tan fácil complacer a los desarrolladores con unos pocos artilugios brillantes. Si no lo haces, ¡la empresa de al lado lo hará!
Todo lo que obtienes de tu desarrollador se canaliza a través de sus herramientas. La menor insuficiencia en esas herramientas se multiplicará mil veces a lo largo de la vida de esas herramientas (se espera tener que actualizarlas en dos años). Estas deficiencias matan la productividad de su desarrollador e incluso pueden generar mucha frustración. ¿Por qué querrías escatimar en el recurso más importante para tus desarrolladores? Apuesto a que si miras profundamente, encontrarás mucho mayor desperdicio en otros lugares de tu empresa.
Buscando buenas técnicas para justificar la máquina "genial de lo normal" para los desarrolladores. La compañía para la que trabajo compra los mismos sistemas con poco poder de $ 500 para todos, y busca la manera de probar el ROI o los argumentos para usar. Lo siento, no dije esto en la pregunta inicial, la pila es VS 2008, SQL 2005/2008. Como los deberes dictan, somos administradores de SQL así como también desarrolladores de Web / Winform / WebService. Por lo tanto, es muy típico tener 2 sesiones VS y al menos una sesión SQL abierta al mismo tiempo.
Averigua cuánto tiempo pasas en el ciclo de edición -> compilación -> depuración, luego sume eso en el transcurso de un año. Luego, estimule (con una inflación justificable) lo que una buena computadora haría con ese número. Multiplique la mejora de tiempo por su tarifa por hora y presentela como un caso de negocios.
Dígales que pagará la diferencia entre sus máquinas baratas y la máquina que desee. Si confía en que aumentará significativamente su productividad, recuperará fácilmente el dinero en bonificaciones de rendimiento / aumentos salariales.
Además, si coloca su dinero donde está su boca, entonces es probable que no cumplan con su obligación de hacer que pague porque causará demasiados problemas en la contabilidad.
Una de las razones por las que las empresas estandarizan las máquinas para comprar es evitar las disputas que se producen cuando el empleado A obtiene una cosa y el empleado B obtiene algo mejor. Si pagaste, entonces nadie se va a quejar de que tienes una PC mejor.
Si todavía dicen que no, al menos sabes dónde estás parado. No te toman en serio y no toman en serio el rol de desarrollador. Desempolvar el CV.
Danimal tiene una buena fórmula allí. Puede incluir en ese caso de negocio una hoja de cálculo que muestre la máquina base en comparación con lo que un desarrollador "promedio" necesita y desea para su empresa. Cosas como Ram, velocidad de CPU, aplicaciones preinstaladas, GPU, etc.
Esto es simplemente ridículo, los desarrolladores son muy caros de contratar y pagar, el hardware es muy barato.
Darle a todos una máquina decente en su escritorio más un servidor bien especificado (8G RAM debería estar bien) en la sala de servidores es lo mínimo que debe esperar.
De lo contrario, ¿cómo van a poder ejecutar una cantidad decente de máquinas virtuales a la vez?
Estrictamente hablando, su máquina de escritorio no importa demasiado, siempre que tengan un servidor de desarrollo decente (estoy asumiendo que esto no es desarrollo de juegos, etc. aquí). Sin embargo, dos pantallas es una buena idea.
Expresado como código:
AnnualSavings := DeveloperCostPerHour * (AnnualWaitHours(OldPC) - AnnualWaitHours(NewPC));
if AnnualSavings > (MachineCost(NewPC) - MachineCost(OldPC)) then
ShowMessage(''Time to pony up for a new machine!!'')
else
ShowMessage(''Sorry bub, gotta keep the old clunker.'');
Las pruebas, al menos, deberían realizarse en un sistema lo más cerca posible del entorno en el que se lanzará. La mayoría de los desarrolladores hacen al menos algunas pruebas en su escritorio, por lo que esa es una razón para no ser peor que su entorno en vivo.
Si su entorno en vivo es un sistema de $ 500 sin potencia, entonces, ese es su entorno. Tal vez deberías trabajar en eso? Es difícil decir qué otras cosas debes mencionar sin tener idea de qué tipo de desarrollo estás haciendo. ¿Solicitud? ¿Servidor? ¿Un lenguaje interpretado o un lenguaje compilado?
Lo que digo es "La respuesta a la productividad del programador no es dar a todos máquinas lentas"
Ofrézcase como voluntario para la mayor cantidad de espectáculos de perros y pony que pueda (oportunidades para mostrar lo que le ha hecho a personas importantes como el VP, etc.). En algún momento su máquina se atascará. Preguntarán por qué todo tarda tanto. Explique que tiene una computadora dolorosamente lenta. También señale cómo va a arriesgarse a perder una fecha límite debido a eso. Señale cómo el disco duro nunca deja de pulirse.
Jugando los números, señale qué tan caro es su tiempo en comparación con el costo único de actualizarlo ahora.
No olvide incluir múltiples dispositivos de visualización en su solicitud: tener una segunda pantalla para tener el código en uno, depurador en el otro (por ejemplo) es invaluable. O para codificar en una pantalla con la referencia del lenguaje en otra.
¿Tienes un servidor central donde se hace la construcción? Si es así, argumentar a favor de una estación de trabajo de desarrollo "mayor de lo normal" puede ser difícil.
Ser capaz de reducir los tiempos de construcción en un factor de 2-3, sin embargo, es una razón lógica para comprar un hardware más grande.
OTOH, si una empresa está tan preocupada por lo que están gastando que solo reciben los especiales de Walmart (que están bien para el trabajo "normal" (mecanografía, correo electrónico, programación, presentaciones)), van a asustar a ... de sus personas técnicas reales, como usted, que realmente quieren hacer su trabajo, y que tienen un trabajo más complejo que, por ejemplo, el asistente administrativo.
Puedo contribuir desde mi propia experiencia por qué una máquina más fuerte sería útil:
- Probando el código bajo diferentes configuraciones. Esto requeriría ejecutar alguna solución de virtualización. Tales soluciones requieren una máquina fuerte.
- Ejecutando una caja de arena. Muchas veces la aplicación desarrollada requiere una base de datos, un servidor web u otro producto complementario. Nuevamente, dicho software puede requerir una máquina fuerte.
- Desarrollo paralelo. A veces, puede ser muy útil ejecutar varias instancias del entorno de desarrollo. Para hacer eso, multiplica el requisito del sistema de una sola instancia.
Sí, te escucho
La justificación básica es siempre la misma para mí: máquina más lenta -> desarrollo más lento; Máquina más rápida -> Desarrollo más rápido.
Aunque si tu jefe está demasiado enfocado en los números, Microsoft tampoco está ayudando.
Requisitos de configuración de Visual Studio :
Requisitos del sistema para instalar Visual Studio 2005
Procesador
Procesador Pentium mínimo: 600 megahertz (MHz)
Recomendado: procesador Pentium de 1 gigahertz (GHz)
RAM
Mínimo: 192 megabytes (MB)
Recomendado: 256 MB
Ser barato en hardware es estúpido. Las personas son mucho más caras de encontrar, contratar y retener que el hardware. La diferencia en el costo entre hardware mínimo y grande generalmente es equivalente a unas pocas semanas de salario del programador. Debería ofrecerles a los desarrolladores una máquina de gama alta de su elección y al menos 2 pantallas. Si su empresa no le brinda las herramientas para que usted (y, por lo tanto, ellas) tenga éxito, no valen su tiempo.
Si eres un dron asalariado que trabajas horas locas y haces todo lo que se te pide, no pierdas el tiempo exprimiendo la sangre del nabo. La compañía te está explotando, lo permites, y no hay ninguna razón para que cambien. O gasta tu propio dinero (comprándote un poco de tiempo adicional cada día), encuentra de alguna manera que la situación actual te causa dolor en el piso de arriba, o aguántalo.
Si, por otro lado, está trabajando una cantidad razonable de horas o se le paga por hora, debe poder justificar la solicitud, ya sea a través de horas reducidas (= costo reducido) o mediante una mejor productividad (= cosas que se hacen más rápido). Debe decidir cuál es la organización más interesada y presentar su solicitud en esos términos.
Identifique (y cuantifique si es posible) cómo la máquina con poca potencia impide su productividad y le ralentiza. Luego, aplique eso a CUALQUIER horario reducido para el mismo trabajo O para más trabajo realizado en el mismo tiempo.
¡Buena suerte!
Supongo que probablemente no trabajes para una empresa de software, como yo, probablemente seas parte de un grupo de software dentro de una empresa de fabricación / hardware, o tal vez una institución financiera o educativa, etc.
Para mí, trabajar con / para este tipo de empresas, generalmente no es que la empresa quiera negarles a las personas las herramientas que necesitan para hacer su trabajo, sino más bien una cuestión de no entender "por qué" los desarrolladores necesitan mejores máquinas que los vendedores.
Tal vez intente usar una analogía que tenga sentido para la (s) persona (s) que sostiene (n) el talonario de cheques. ¿Por qué los vendedores llevan a los clientes a un restaurante especializado en carnes cuando McDonald''s está justo al otro lado de la calle? ¿Por qué los mecánicos gastan dinero extra para comprar herramientas Snap-On cuando Wal-Mart vende destornilladores de la marca Buffalo? (seguro, tengo algunos destornilladores Buffalo en casa, pero no soy mecánico)
Una buena es:
Tiempo extra por compilación X número de compilaciones por hora X horas en día laborable X días en el mes X número de desarrolladores
Esto resalta cuánto de su (caro) tiempo se desperdicia esperando a que la máquina termine. Puedes hacer lo mismo para las pruebas, etc ...
en parte debido a la productividad y la capacidad de respuesta de la máquina para un desarrollador que de lo contrario jugaría justas de presidente durante las compilaciones; sino también porque un desarrollador va a instalar las aplicaciones más grandes y necesitadas de recursos que verá fuera de un servidor de producción.
Visual Studio ocupa mucho disco, RAM y una gran cantidad de CPU. Eclipse (me dicen) es lo mismo. Cualquier desarrollador por qué está haciendo algo útil también tendrá control de fuente, versiones de desarrollo de sistemas de producción (por ejemplo, un DB local contra el que desarrollarse), etc. Todas esas aplicaciones también ocupan mucho RAM y CPU.
¡A menos que esté desarrollando remotamente en un servidor en alguna parte, necesitará toneladas de recursos solo para instalar la mitad de las aplicaciones infladas que quieren que use!