Casi correcto, pero creo que la gente de ventas o finanzas tampoco tiene mucho de ese poder de compra. Por eso todos terminan usando las herramientas permitidas por la empresa o los planes gratuitos, y al final hay que vendérselas al jefe.
Hay que convencerlo con argumentos como ahorrar tiempo, hacer que los proyectos sean más transparentes y reducir la libertad.
Es muy probable que esta sea también la razón por la que Excel se usa tanto. Excel también es la herramienta más potente que TI de la empresa suele permitir.
Si trabajas en ventas o finanzas e intentas conseguir permiso para instalar WSL en tu PC, te das cuenta. Las apps web también son populares porque TI de la empresa tiene que conocerlas para poder bloquearlas.
Un gerente de marketing quizá pueda pagar Basecamp con su propia tarjeta, pero si quiere introducir una herramienta autoalojada, el asunto se complica porque tiene que pasar por la política de TI de “nosotros administramos las computadoras y nosotros decidimos cómo se trabaja”.
Excel se usa ampliamente porque, literalmente, cualquiera puede usarlo. A diferencia de una base de datos, lo que construyes aparece en una forma visual directamente visible.
Está incluido en todas las licencias de m365, y durante mucho tiempo las licencias perpetuas también fueron relativamente baratas.
Cuando alguien habla de permitir WSL al equipo de ventas, me dan ganas de preguntar si alguna vez trabajó con vendedores reales. En el 99% de las empresas, incluso los vendedores con conocimientos técnicos apenas pueden enviar un archivo adjunto por email sin ayuda; no sé qué pretenden hacer con WSL.
En general, es cierto. Las empresas no aprueban la compra de un libro individual, pero sí aprueban una suscripción a una plataforma de aprendizaje.
Aprobar todas esas compras pequeñas da demasiado trabajo y, si no se revisan, se acumulan suscripciones sin usar por todas partes o se terminan comprando muchas cosas que no aportan mucho a la empresa.
En mi experiencia, el área de ventas puede tener buenas herramientas a nivel de departamento, pero no tenía mucho poder de compra.
En cambio, marketing parecía tener bastante poder de compra, probablemente porque el trabajo en sí está relacionado con comprar todo tipo de cosas.
Incluso para un jefe, conseguir aprobación para comprar una herramienta puede ser engorroso porque tiene que vendérsela a niveles más altos. USD 80 al mes por usuario es prácticamente gratis comparado con el costo laboral, pero siempre termina siendo una barrera.
Comprar aplicaciones autoalojadas es difícil porque TI tiene que hacerse cargo de los costos de servidores, red y almacenamiento; instalación, upgrades, operación y soporte; inicio de sesión único basado en AD; correo; Slack; backups y recuperación; exportación y migración de datos; y hasta ciberseguridad.
Si una sola aplicación es comprometida, toda la TI de la empresa puede quedar en riesgo, y aunque se apliquen aislamiento o zero trust, la superficie de ataque y los costos de seguridad aumentan.
En realidad, comprar una aplicación autoalojada es la parte fácil; lo difícil es operarla de forma estable todos los días durante el tiempo que el negocio la necesite. En algunos casos, la ley exige conservar los datos durante mucho tiempo.
Aunque sea una herramienta solicitada por TI del negocio, quizá puedan encargarse de parte de la administración técnica, pero muchas veces no tienen tiempo o son desarrolladores, no administradores de sistemas o de redes, y no pueden hacerlo.
Al final hay que usar un sandbox separado de la TI corporativa, renunciar a comodidades como backups y AD, o implementarlo y mantenerlo directamente como shadow IT.
Por eso creo que una de las razones por las que crecieron SaaS y la nube es que permiten externalizar esos costos.
Si tienes que pelear para comprar un libro de 50 dólares, probablemente elegiste mal la empresa.
Dicho eso, algunos desarrolladores crearon con tarjeta una cuenta no oficial para probar Notion internamente, hicieron ahí un documento importante de resumen y compartieron el enlace.
La mitad de la empresa, al intentar verlo, creó cuentas de forma tácita, y al mes siguiente le llegó al CFO una factura de 10 mil dólares.
La historia de por qué no se debe dar poder de compra a los desarrolladores suele empezar así.
Esto no es más que un ejemplo de modelo de precios depredador y dark patterns.
Hay una razón por la que muchas empresas SaaS no ofrecen bien opciones de prepago o límites máximos de costo fijo. Es casi una estafa.
No sé a quién le parece buena idea un sistema en el que te pueden cobrar solo por hacer clic en un enlace. Si la tarjeta tampoco tenía un límite mensual razonable, toda la configuración es demasiado absurda.
Me cuesta creer que esto sea “el comienzo de la historia de por qué los desarrolladores terminan sin poder de compra”.
Que los desarrolladores, o cualquiera, compren herramientas directamente a veces puede convertirse en una optimización local a costa de toda la organización.
Por ejemplo, las herramientas quedan fragmentadas y no se puede encontrar información con una sola búsqueda, o cada equipo tiene que iniciar sesión por separado en herramientas distintas.
Si los equipos administran por su cuenta herramientas que contienen propiedad intelectual de la empresa, se vuelve una pesadilla de compliance cuando se busca cumplir con SOC.
Comprar libros o materiales de aprendizaje me parece bien.
Hablando desde la experiencia de haber decidido más de 100 millones de dólares por trimestre en gasto de hardware, software y servicios de ingeniería: si estás creando herramientas para desarrolladores, primero debes lograr que los desarrolladores actuales las sientan muy útiles y las defiendan con fuerza.
No debes tocar puntos con poder de veto como contratos opacos, lock-in, seguridad de datos y privacidad, integración con inicio de sesión único y autenticación.
El precio también tiene que ser razonable. Un precio que escala linealmente con alguna variable puede no tener sentido en la hoja de cálculo de finanzas. Cobrar por desarrollador al mes es fácil de entender; una licencia flotante para toda la empresa es mejor; y a veces encaja más una tarifa plana ilimitada para toda la empresa.
Incluso con ese último esquema, se pueden trasladar tal cual los costos variables como cómputo y almacenamiento en la nube. Si puedes desplegar directamente en la cuenta cloud del cliente, también se resuelven los problemas de seguridad de datos y privacidad.
Debes ofrecer controles de costos como topes de facturación, límites de uso, restricciones a configuraciones que generen cargos caros y reportes de uso suficientes.
Si lo haces bien, también puedes cerrar contratos multianuales con gasto comprometido. Hay que mantener la confiabilidad del servicio y revisar trimestralmente con los clientes grandes para entender su satisfacción y sus necesidades no cubiertas.
También puedes ofrecer y cobrar servicios profesionales premium, como ingenieros dedicados y soporte. Son muy rentables y a veces son clave para ganar o retener a un cliente específico.
Dentro de la empresa cliente, el producto puede ser polémico y alguien que se oponga puede hacer fracasar su adopción; por eso, si los servicios profesionales se encargan de la integración e implementación iniciales, se reduce la intervención de los guardianes de TI y se llega a los usuarios reales.
Es mejor no empeñarse en vender un producto que el cliente cree firmemente que puede construir por su cuenta. Aunque ese juicio esté equivocado, quizá ganes al principio, pero probablemente termines perdiendo.
El punto 7 sobre construir versus comprar normalmente no es tan blanco o negro. Lo más difícil es cuando ya existe un producto interno y se quiere reemplazarlo o agregarle una función nueva.
El problema es cuándo se evalúa el retorno de inversión de construir versus comprar.
Comprar un producto con costos de integración muy altos es, en la práctica, casi lo mismo que construirlo. La integración requiere tiempo de desarrolladores, y ese tiempo podría haberse usado en otras tareas o en el producto mismo.
Sería ideal que esto se revelara durante una integración de prueba de concepto, pero incluso esa etapa requiere tiempo de desarrolladores para ejecutarla.
Depende de la empresa. En una empresa donde trabajé antes, la política era: “Si necesitas algo que facilite el trabajo, como libros, licencias e incluso hardware, simplemente cómpralo. El costo administrativo de tomar la decisión es más caro, así que la opción predeterminada es aprobarlo de inmediato”.
¿Los desarrolladores se lanzaron a comprar sin control? No; compraron al mismo nivel que antes de la política. En la práctica, la vida se volvió más cómoda.
Era como ver libros, licencias y hardware como consumibles, igual que plumas o papel. Para software local pequeño, como un IDE, en general puede funcionar.
Hace falta asumir que se puede confiar en darles permisos de administrador a los desarrolladores, o que el área de TI de la empresa puede permitir la instalación.
Se puede dar un pequeño presupuesto a todos o administrarlo por equipo o departamento, pero en el momento en que se necesita integración con TI corporativo, deja de funcionar bien.
Me gusta ese enfoque y no digo que sea imposible, pero una ola repentina de compras no es el único modo de falla.
Si lo dejas correr 10 o 20 años, puede verse muy distinto. Se acumulan aumentos de costos lentos e invisibles, y puede convertirse en una cultura donde quienes gastan un poco menos sienten que tienen que comprar cosas para no hacer quedar a los demás como derrochadores.
Hay muchos mecanismos sutiles que incentivan el aumento de costos, así que hace falta algo que empuje en la dirección contraria. Lo veo como un problema aún no resuelto.
Podría funcionar poner un límite de presupuesto generoso, pero aclarar que no significa que haya que gastarlo todo, y establecer una regla de donar a fin de año un porcentaje del monto restante a una buena causa que cualquiera pueda aceptar.
Algo como: “Pueden comprar libros. Solo recuerden que por ese libro la donación a los ponis baja 5 dólares”. Si fueran manatíes, corro el riesgo de terminar trabajando con una Chromebook.
El problema es que los gerentes se meten en todas las decisiones. La gente cree que los gerentes están para ayudar, pero crean más problemas de los que resuelven.
En el mejor de los casos, muchas veces son incompetentes; sería mejor reducir algunos puestos de gerencia y usar esos sueldos como presupuesto discrecional. Todos ganan.
En mi empresa actual hay algunas personas con un rol parecido a RR. HH. que se encargan de estas compras. Les mandas por correo el enlace del hardware o software que necesitas y te lo envían a tu casa.
No tengo que conocer el proceso interno de pedidos y envíos de la empresa, y es el mejor método que he visto hasta ahora.
Tuve una experiencia parecida. Les dieron tarjetas corporativas a todos y los alentaron a usarlas.
Me topé con este problema una vez como empleado. Quería una ThinkPad, pero la dirección insistía en una Dell pésima; al final recibí la ThinkPad.
Fuera de eso, si pedía libros o herramientas, simplemente me los daban, e incluso se podía conseguir un teclado dividido caro.
Ahora que soy trabajador independiente, simplemente compro lo que necesito. En realidad no necesito tanto.
No hay muchas “herramientas para desarrolladores” lo bastante útiles como para gastar dinero en ellas, y hay aún menos que valgan la pena integrar a mi flujo de trabajo. Con el tiempo, esta última parte se volvió más importante.
Así es la vida corporativa.
Me dieron una Dell pésima, se descompuso, me dieron otra Dell pésima, se volvió a descomponer, y luego me dieron otra Dell.
Dicen: “Solo tenemos contrato con Dell”, y cuando preguntas si no deberían, para empezar, no tener contrato con Dell, se hace el silencio y recién entonces empiezan a pensar.
Uno se da cuenta de que cuando la Dell se descompone es el mejor momento de la vida. Tardan 5 días en atravesar capas de órdenes de compra y política de pedidos para enviarte equipo nuevo, y durante esos 5 días no puedes hacer nada por las políticas de seguridad brutales de la empresa.
Así que durante 5 días duermes, te pones al día con tus amigos y vuelves a ser humano.
Amo las Dell. No quiero una ThinkPad.
Para uso personal uso una MacBook.
Si tienes que pedir permiso, entonces no tienes autoridad.
Antes trabajé en una subsidiaria orientada a ventas de una empresa de ingeniería.
Al principio podía invitar sin problema un almuerzo de 100 dólares, pero no podía comprar una tarjeta de 30 dólares para mi computadora.
En cambio, en la empresa matriz era fácil comprar equipo de pruebas de 5 mil dólares, pero para llevar a alguien a un restaurante de comida rápida había que llenar tres formularios.
Hacia el final de mi periodo, en ambos lados prácticamente no se podía hacer nada sin ese formulario.
Muchas empresas exitosas de herramientas para desarrolladores ganaron dinero haciendo marketing a los jefes, no a los desarrolladores. Pasa no solo en tecnología, sino en muchos ámbitos.
Totalmente de acuerdo. En una de las grandes empresas tecnológicas necesitaba un disco duro para cierto trabajo, y era más fácil comprar un arreglo de discos de 5 mil dólares y sacarle el disco que pasar como gasto 200 dólares por un solo HDD.
Comprar cosas fuera de tu área era absurdamente complicado.
Más recientemente, la empresa dijo: “Tienen tarjeta corporativa, úsenla”, y los EVP aprobaban los gastos relacionados con eventos. No era lo habitual, pero me impresionó que supieran que a veces hay que cortar la burocracia.
La próxima vez que haga una liquidación de gastos normal, seguro terminaré peleando con contabilidad porque un recibo de taxi de 20 dólares no incluye origen y destino.
Compro directamente las licencias de software y las meto en impuestos. Es la forma de evitar falsos ahorros.
Gracias a que busqué y compré por mi cuenta herramientas adecuadas y baratas, recibí premios en el trabajo, me volví irremplazable en ciertos proyectos, obtuve aumentos de sueldo y pude elegir en qué trabajar.
Mi licencia de Jetbrains es el ejemplo típico. Me cuesta imaginar refactorizar código sin ella.
Si la empresa deja de recortar costos, tendré más competencia en el trabajo.
En teoría, en el sistema fiscal del Reino Unido también es posible. El formulario de Self Assessment tiene una sección para reclamar gastos relacionados con el trabajo que el empleador no reembolsó.
Un empleador anterior pagaba una tarifa baja por kilometraje, así que solía reclamar la diferencia en la declaración de impuestos.
En cuanto al software, no tengo claro cómo se aplicaría el criterio para determinar si es un gasto permitido.
Yo también he trabajado así durante años.
Como la mayoría de las empresas no compran el software correcto para el trabajo, terminé siendo la persona más efectiva del equipo. Porque, a diferencia de otros, puedo hacer las cosas rápido y de forma eficiente.
En muchas empresas, si te descubren haciendo eso, te puedes meter en un gran problema.
Me da curiosidad cómo puede “meterlo en impuestos” un empleado W2 exento en EE. UU.
Me da curiosidad qué otros ejemplos hay.
Si se puede subir a Azure, AWS o Google Cloud, la cosa cambia
Aunque no puedas comprar ni un lápiz sin aprobación, en la nube de la empresa puedes gastar miles de dólares sin que nadie pregunte
Ahí está la magia de Amazon Marketplace. Puedes comprar servicios que no son de AWS, pero igual aparecen en la factura de AWS y también cuentan para el compromiso de gasto de la empresa
Exacto. Le pedí a un desarrollador que configurara un servidor FTP. Era un buen administrador de Linux y ya había hecho esto varias veces en VPS de 10 libras
Pero esta vez eligió un servicio de AWS que costaba más de 1.000 libras al mes. Cuando llegó la factura de la tarjeta fue un gran dolor de cabeza, y los cargos del mes siguiente ya estaban bastante avanzados
Después de eso tuvimos que imponer controles más estrictos
A mí me pasa algo parecido. Hacer que las personas adecuadas evalúen localstack parece que será una batalla grande y difícil
Pero si compramos la licencia empresarial, solo con el ahorro se recuperaría el costo de inmediato, así que aunque no sea mi trabajo principal, siento la presión de intentarlo
Para ser justos, es porque todavía nadie ha encontrado cómo integrar terraform apply con un flujo de aprobación de SAP
Un modelo de negocio en el que los ingenieros son quienes toman la decisión es perfectamente viable. Solo que se limita a herramientas con las que el ingeniero puede hacer una optimización local sin impacto directo fuera de su alcance
El IDE es el mejor ejemplo. Si una empresa permite que sus ingenieros tomen decisiones individuales sobre IDEs para aumentar su productividad, el impacto global acumulado de esas decisiones puede ser aceptable. Jetbrains lo demuestra
Pero no todas las herramientas son así. El artículo original trata ejemplos que caen en la segunda categoría, como Redis, Terraform y AWS
A diferencia de los IDEs, cuando las decisiones individuales se propagan en bases de datos, gestión de infraestructura o infraestructura cloud, se vuelven problemáticas. La empresa tiene que mantener un stack heterogéneo, y un proveedor no puede cerrar un contrato corporativo significativo solo porque un equipo eligió Redis
Por eso termina haciendo falta cierto grado de estandarización. En ese punto, el impacto de la elección y el tamaño de la licencia crecen, así que no solo los líderes de ingeniería, sino también finanzas quieren tener voz. Y tienen buenas razones para hacerlo
Y en cuanto entra finanzas, hay que justificar la elección en un lenguaje que a la mayoría de los ingenieros les resulta difícil
Mi autoridad de compra funciona así. Le digo a mi jefe: “Si compramos esta herramienta de desarrollo, podemos ahorrar X horas de tiempo de desarrollador”
Solo hace falta que X sea lo bastante grande en comparación con el precio de la herramienta. Este enfoque funciona bastante bien y lo he usado tan seguido que mi jefe ahora lo mira con escepticismo
Hace bien en ser escéptico. Sobreestimar los beneficios, ya sea de una herramienta o de un rediseño, es tan común como subestimar el esfuerzo, y probablemente ambas cosas estén muy relacionadas
Eso no significa que no existan herramientas valiosas. Existen, pero son muy raras
Me pregunto cuánto falta para que tu jefe diga: “Si sumo todas las herramientas que mencionaste en los últimos 3 meses, dijiste que ahorrarían un año de trabajo de desarrollador, así que voy a reducir el equipo en 1 desarrollador y mantener igual el trabajo y el calendario”
Podrían responderte: “El tiempo de desarrollador no es un KPI, y el salario es el mismo si trabajas 160 horas al mes que si trabajas 180 o 200”
1 comentarios
Opiniones de Hacker News
Casi correcto, pero creo que la gente de ventas o finanzas tampoco tiene mucho de ese poder de compra. Por eso todos terminan usando las herramientas permitidas por la empresa o los planes gratuitos, y al final hay que vendérselas al jefe.
Hay que convencerlo con argumentos como ahorrar tiempo, hacer que los proyectos sean más transparentes y reducir la libertad.
Es muy probable que esta sea también la razón por la que Excel se usa tanto. Excel también es la herramienta más potente que TI de la empresa suele permitir.
Si trabajas en ventas o finanzas e intentas conseguir permiso para instalar WSL en tu PC, te das cuenta. Las apps web también son populares porque TI de la empresa tiene que conocerlas para poder bloquearlas.
Un gerente de marketing quizá pueda pagar Basecamp con su propia tarjeta, pero si quiere introducir una herramienta autoalojada, el asunto se complica porque tiene que pasar por la política de TI de “nosotros administramos las computadoras y nosotros decidimos cómo se trabaja”.
Está incluido en todas las licencias de m365, y durante mucho tiempo las licencias perpetuas también fueron relativamente baratas.
Cuando alguien habla de permitir WSL al equipo de ventas, me dan ganas de preguntar si alguna vez trabajó con vendedores reales. En el 99% de las empresas, incluso los vendedores con conocimientos técnicos apenas pueden enviar un archivo adjunto por email sin ayuda; no sé qué pretenden hacer con WSL.
Aprobar todas esas compras pequeñas da demasiado trabajo y, si no se revisan, se acumulan suscripciones sin usar por todas partes o se terminan comprando muchas cosas que no aportan mucho a la empresa.
En cambio, marketing parecía tener bastante poder de compra, probablemente porque el trabajo en sí está relacionado con comprar todo tipo de cosas.
Si una sola aplicación es comprometida, toda la TI de la empresa puede quedar en riesgo, y aunque se apliquen aislamiento o zero trust, la superficie de ataque y los costos de seguridad aumentan.
En realidad, comprar una aplicación autoalojada es la parte fácil; lo difícil es operarla de forma estable todos los días durante el tiempo que el negocio la necesite. En algunos casos, la ley exige conservar los datos durante mucho tiempo.
Aunque sea una herramienta solicitada por TI del negocio, quizá puedan encargarse de parte de la administración técnica, pero muchas veces no tienen tiempo o son desarrolladores, no administradores de sistemas o de redes, y no pueden hacerlo.
Al final hay que usar un sandbox separado de la TI corporativa, renunciar a comodidades como backups y AD, o implementarlo y mantenerlo directamente como shadow IT.
Por eso creo que una de las razones por las que crecieron SaaS y la nube es que permiten externalizar esos costos.
Si tienes que pelear para comprar un libro de 50 dólares, probablemente elegiste mal la empresa.
Dicho eso, algunos desarrolladores crearon con tarjeta una cuenta no oficial para probar Notion internamente, hicieron ahí un documento importante de resumen y compartieron el enlace.
La mitad de la empresa, al intentar verlo, creó cuentas de forma tácita, y al mes siguiente le llegó al CFO una factura de 10 mil dólares.
La historia de por qué no se debe dar poder de compra a los desarrolladores suele empezar así.
Hay una razón por la que muchas empresas SaaS no ofrecen bien opciones de prepago o límites máximos de costo fijo. Es casi una estafa.
Me cuesta creer que esto sea “el comienzo de la historia de por qué los desarrolladores terminan sin poder de compra”.
Por ejemplo, las herramientas quedan fragmentadas y no se puede encontrar información con una sola búsqueda, o cada equipo tiene que iniciar sesión por separado en herramientas distintas.
Si los equipos administran por su cuenta herramientas que contienen propiedad intelectual de la empresa, se vuelve una pesadilla de compliance cuando se busca cumplir con SOC.
Comprar libros o materiales de aprendizaje me parece bien.
Hablando desde la experiencia de haber decidido más de 100 millones de dólares por trimestre en gasto de hardware, software y servicios de ingeniería: si estás creando herramientas para desarrolladores, primero debes lograr que los desarrolladores actuales las sientan muy útiles y las defiendan con fuerza.
No debes tocar puntos con poder de veto como contratos opacos, lock-in, seguridad de datos y privacidad, integración con inicio de sesión único y autenticación.
El precio también tiene que ser razonable. Un precio que escala linealmente con alguna variable puede no tener sentido en la hoja de cálculo de finanzas. Cobrar por desarrollador al mes es fácil de entender; una licencia flotante para toda la empresa es mejor; y a veces encaja más una tarifa plana ilimitada para toda la empresa.
Incluso con ese último esquema, se pueden trasladar tal cual los costos variables como cómputo y almacenamiento en la nube. Si puedes desplegar directamente en la cuenta cloud del cliente, también se resuelven los problemas de seguridad de datos y privacidad.
Debes ofrecer controles de costos como topes de facturación, límites de uso, restricciones a configuraciones que generen cargos caros y reportes de uso suficientes.
Si lo haces bien, también puedes cerrar contratos multianuales con gasto comprometido. Hay que mantener la confiabilidad del servicio y revisar trimestralmente con los clientes grandes para entender su satisfacción y sus necesidades no cubiertas.
También puedes ofrecer y cobrar servicios profesionales premium, como ingenieros dedicados y soporte. Son muy rentables y a veces son clave para ganar o retener a un cliente específico.
Dentro de la empresa cliente, el producto puede ser polémico y alguien que se oponga puede hacer fracasar su adopción; por eso, si los servicios profesionales se encargan de la integración e implementación iniciales, se reduce la intervención de los guardianes de TI y se llega a los usuarios reales.
Es mejor no empeñarse en vender un producto que el cliente cree firmemente que puede construir por su cuenta. Aunque ese juicio esté equivocado, quizá ganes al principio, pero probablemente termines perdiendo.
El problema es cuándo se evalúa el retorno de inversión de construir versus comprar.
Comprar un producto con costos de integración muy altos es, en la práctica, casi lo mismo que construirlo. La integración requiere tiempo de desarrolladores, y ese tiempo podría haberse usado en otras tareas o en el producto mismo.
Sería ideal que esto se revelara durante una integración de prueba de concepto, pero incluso esa etapa requiere tiempo de desarrolladores para ejecutarla.
Depende de la empresa. En una empresa donde trabajé antes, la política era: “Si necesitas algo que facilite el trabajo, como libros, licencias e incluso hardware, simplemente cómpralo. El costo administrativo de tomar la decisión es más caro, así que la opción predeterminada es aprobarlo de inmediato”.
¿Los desarrolladores se lanzaron a comprar sin control? No; compraron al mismo nivel que antes de la política. En la práctica, la vida se volvió más cómoda.
Hace falta asumir que se puede confiar en darles permisos de administrador a los desarrolladores, o que el área de TI de la empresa puede permitir la instalación.
Se puede dar un pequeño presupuesto a todos o administrarlo por equipo o departamento, pero en el momento en que se necesita integración con TI corporativo, deja de funcionar bien.
Si lo dejas correr 10 o 20 años, puede verse muy distinto. Se acumulan aumentos de costos lentos e invisibles, y puede convertirse en una cultura donde quienes gastan un poco menos sienten que tienen que comprar cosas para no hacer quedar a los demás como derrochadores.
Hay muchos mecanismos sutiles que incentivan el aumento de costos, así que hace falta algo que empuje en la dirección contraria. Lo veo como un problema aún no resuelto.
Podría funcionar poner un límite de presupuesto generoso, pero aclarar que no significa que haya que gastarlo todo, y establecer una regla de donar a fin de año un porcentaje del monto restante a una buena causa que cualquiera pueda aceptar.
Algo como: “Pueden comprar libros. Solo recuerden que por ese libro la donación a los ponis baja 5 dólares”. Si fueran manatíes, corro el riesgo de terminar trabajando con una Chromebook.
En el mejor de los casos, muchas veces son incompetentes; sería mejor reducir algunos puestos de gerencia y usar esos sueldos como presupuesto discrecional. Todos ganan.
No tengo que conocer el proceso interno de pedidos y envíos de la empresa, y es el mejor método que he visto hasta ahora.
Me topé con este problema una vez como empleado. Quería una ThinkPad, pero la dirección insistía en una Dell pésima; al final recibí la ThinkPad.
Fuera de eso, si pedía libros o herramientas, simplemente me los daban, e incluso se podía conseguir un teclado dividido caro.
Ahora que soy trabajador independiente, simplemente compro lo que necesito. En realidad no necesito tanto.
No hay muchas “herramientas para desarrolladores” lo bastante útiles como para gastar dinero en ellas, y hay aún menos que valgan la pena integrar a mi flujo de trabajo. Con el tiempo, esta última parte se volvió más importante.
Me dieron una Dell pésima, se descompuso, me dieron otra Dell pésima, se volvió a descomponer, y luego me dieron otra Dell.
Dicen: “Solo tenemos contrato con Dell”, y cuando preguntas si no deberían, para empezar, no tener contrato con Dell, se hace el silencio y recién entonces empiezan a pensar.
Uno se da cuenta de que cuando la Dell se descompone es el mejor momento de la vida. Tardan 5 días en atravesar capas de órdenes de compra y política de pedidos para enviarte equipo nuevo, y durante esos 5 días no puedes hacer nada por las políticas de seguridad brutales de la empresa.
Así que durante 5 días duermes, te pones al día con tus amigos y vuelves a ser humano.
Amo las Dell. No quiero una ThinkPad.
Para uso personal uso una MacBook.
Antes trabajé en una subsidiaria orientada a ventas de una empresa de ingeniería.
Al principio podía invitar sin problema un almuerzo de 100 dólares, pero no podía comprar una tarjeta de 30 dólares para mi computadora.
En cambio, en la empresa matriz era fácil comprar equipo de pruebas de 5 mil dólares, pero para llevar a alguien a un restaurante de comida rápida había que llenar tres formularios.
Hacia el final de mi periodo, en ambos lados prácticamente no se podía hacer nada sin ese formulario.
Muchas empresas exitosas de herramientas para desarrolladores ganaron dinero haciendo marketing a los jefes, no a los desarrolladores. Pasa no solo en tecnología, sino en muchos ámbitos.
Comprar cosas fuera de tu área era absurdamente complicado.
Más recientemente, la empresa dijo: “Tienen tarjeta corporativa, úsenla”, y los EVP aprobaban los gastos relacionados con eventos. No era lo habitual, pero me impresionó que supieran que a veces hay que cortar la burocracia.
La próxima vez que haga una liquidación de gastos normal, seguro terminaré peleando con contabilidad porque un recibo de taxi de 20 dólares no incluye origen y destino.
Compro directamente las licencias de software y las meto en impuestos. Es la forma de evitar falsos ahorros.
Gracias a que busqué y compré por mi cuenta herramientas adecuadas y baratas, recibí premios en el trabajo, me volví irremplazable en ciertos proyectos, obtuve aumentos de sueldo y pude elegir en qué trabajar.
Mi licencia de Jetbrains es el ejemplo típico. Me cuesta imaginar refactorizar código sin ella.
Si la empresa deja de recortar costos, tendré más competencia en el trabajo.
Un empleador anterior pagaba una tarifa baja por kilometraje, así que solía reclamar la diferencia en la declaración de impuestos.
En cuanto al software, no tengo claro cómo se aplicaría el criterio para determinar si es un gasto permitido.
Como la mayoría de las empresas no compran el software correcto para el trabajo, terminé siendo la persona más efectiva del equipo. Porque, a diferencia de otros, puedo hacer las cosas rápido y de forma eficiente.
Si se puede subir a Azure, AWS o Google Cloud, la cosa cambia
Aunque no puedas comprar ni un lápiz sin aprobación, en la nube de la empresa puedes gastar miles de dólares sin que nadie pregunte
Pero esta vez eligió un servicio de AWS que costaba más de 1.000 libras al mes. Cuando llegó la factura de la tarjeta fue un gran dolor de cabeza, y los cargos del mes siguiente ya estaban bastante avanzados
Después de eso tuvimos que imponer controles más estrictos
Pero si compramos la licencia empresarial, solo con el ahorro se recuperaría el costo de inmediato, así que aunque no sea mi trabajo principal, siento la presión de intentarlo
terraform applycon un flujo de aprobación de SAPUn modelo de negocio en el que los ingenieros son quienes toman la decisión es perfectamente viable. Solo que se limita a herramientas con las que el ingeniero puede hacer una optimización local sin impacto directo fuera de su alcance
El IDE es el mejor ejemplo. Si una empresa permite que sus ingenieros tomen decisiones individuales sobre IDEs para aumentar su productividad, el impacto global acumulado de esas decisiones puede ser aceptable. Jetbrains lo demuestra
Pero no todas las herramientas son así. El artículo original trata ejemplos que caen en la segunda categoría, como Redis, Terraform y AWS
A diferencia de los IDEs, cuando las decisiones individuales se propagan en bases de datos, gestión de infraestructura o infraestructura cloud, se vuelven problemáticas. La empresa tiene que mantener un stack heterogéneo, y un proveedor no puede cerrar un contrato corporativo significativo solo porque un equipo eligió Redis
Por eso termina haciendo falta cierto grado de estandarización. En ese punto, el impacto de la elección y el tamaño de la licencia crecen, así que no solo los líderes de ingeniería, sino también finanzas quieren tener voz. Y tienen buenas razones para hacerlo
Y en cuanto entra finanzas, hay que justificar la elección en un lenguaje que a la mayoría de los ingenieros les resulta difícil
Mi autoridad de compra funciona así. Le digo a mi jefe: “Si compramos esta herramienta de desarrollo, podemos ahorrar X horas de tiempo de desarrollador”
Solo hace falta que X sea lo bastante grande en comparación con el precio de la herramienta. Este enfoque funciona bastante bien y lo he usado tan seguido que mi jefe ahora lo mira con escepticismo
Eso no significa que no existan herramientas valiosas. Existen, pero son muy raras