You are currently browsing the category archive for the ‘Organiziación de trabajo’ category.

Ya desde tiempo, los “métodos ágiles” de desarrollo de software como Scrum, eXtreme Programming o Scaled Agile son de moda; tanto que incluso tu empresa ya estará disfrutando de ellas. O de algo parecido al menos de nombre. Porque los métodos ágiles se parecen a menudo al comunismo. Son ideas maravillosas mientras no tienes que vivir con ellas.

Lo que también tienen en común con el comunismo, es que ciertos elementos, sí, son útiles. Igual como un capitalismo social avanza el bienestar general (capitalismo = hay medicamentos, socialismo = los enfermos pueden pagarlo), elementos de los métodos ágiles pueden mejorar mucho el desarrollo de software. La pregunta es: ¿qué elementos?

Para sacarles el mejor rendimiento, conviene entender el contexto cultural de donde los métodos ágiles salieron. Como muchas ideas religiosas recientes, los métodos ágiles también han salido de los Estados Unidos de América. Y como los norte-americanos tienen un don de marketing, les gusta dar nombre llamativos como “Scrum”, “eXtreme Programming” o “Chrystal Clear” que, para el tu bien mental, mejor no traduzques a tu lengua materna. El libro gordo de esta religión se llama “Agile Manifesto” y expresa, entre otras cosas, y en palabras más positivas, los siguiüente puntos en negrita.

  1. La profesionalización del concepto “el producto madura en el cliente”. Funciona muy bien, mientras el cliente piensa que las frecuente actualizaciones corresponden a “mantener el producto” y no a “no hacerlo bien desdel principio”. Madurar el producto en el cliente está aceptable para el software que tienes en tu teléfono, pero no suele ser buena idea para aparatos medicinales.
  2. Nadie tiene dominios. Todos programan de todo. En todas las empresas (menos en una en que era el único programador) se ha tenido la idea de un proxy que sería capaz de hacer tu trabajo si no estás por enfermedad, vacaciones o despido. Y en ninguna empresa ha durado mucho hasta dejarlo. Los programadores no son intercambiables. Todos no saben igual de todo. En el momento que escribes una pieza de código, eres automáticamente el máximo experto para ello. Es inevitable. Así, o bien aceptas que los demás programadores constantemente deben aprender código nuevo que les hace bastante lento, o dejas mentirte y aceptas que cada uno tiene un dominio. No quiero decir que vale la pena mandar a todos a hacer de todo. Puede funcionar si se hace con consecuencia desde el principio. Pero no pondrás un novato a estudiar una nueva parte de código por varios días, si mañana tienes la release final.
  3. No hagas documentación que nadie se lea. Porque cualquier documentación tiene el peligro de hacerse obsoleta con los cambios en el códio. Por eso es mejor no tenerla. En cambio el códio es auto-explicativo y el resto se pregunta. No olvides que comunicación es importante en los métodos ágiles. Ya sabes, todos deben saber de todo, y mejor que no haya nadie a quién ocurre proponer un documento que explica el programa al menos a alto nivel. Saber leer y dejar trabar a los demás es para introvertidos. Los novatos tienen que integrarse y esto es más fácil si deben preguntar de todo. Mejor aún si deben pasarse una semana entera (o para siempre) con una pareja veterana en la mesa. Así y comunicación.
  4. Usa el sentido común. Recordar que comunicación es importante parece poco novedoso si vienes de un país con un clima en que a la gente gusta encontrarse en la calle, pero esto quizá no es tan obvio para otros países donde tienes el permiso de sacar un arma si alguien pisa tu territorio. Tampoco falta un título en bla-bla avanzado para descubrir, que es más eficiente si un programador termina un trabajo antes de empezar uno nuevo en lugar de interumpirle constantemente. Si quieres promover métodos ágiles en tu empresa, considera que, fuera de Estados Unidos, la gente viene equipado con sentido común desde fábrica y probablemente ya lo sabe.

De hecho, sentido común ayuda considerablemente en sacar el máximo provecho de los métodos ágiles. Desgraciadamente, estos “consultores” de métodos ágiles demasiadas veces no son lo suficientemente ágiles ellos mismos para reconocer, que los prerequisitos de su método son díficiles de conseguir. Programadores no son fáciles de intercambiar, el product owner no tiene tiempo aunque debería y el cliente no tiene ganas de pasar su tiempo en la empresa que paga para quitarle el trabajo.

Un buen ejemplo del carácter religioso de métodos ágiles es la creencia de la mayor eficiencia de la programación en pareja. Una minoría de los programadores se llevará bien, y pasa el día charlando en lugar de trabajando. La mayoría acaba estando tan estresando con tener constantemente otro tipo al lado, que se marchará de la empresa. De hecho, la programación en pareja es una manera eficaz de descubrir los programadores competentes: son aquellos que se han ido tras un año. Pero también puedes verlo positivo: siempre tendrás a un equipo joven. (Si no te dejan introducir la programación en pareja para descubrir a los talentos, obligar a llevar corbata funciona también. Si ya llevas corbata pero no entiendes el chiste, entonces, enhorabuena, ya trabajas para tu empresa perfecta.)

No sigas a un método ágil porque es la moda. Busca los elementos que mejoran tu desarrollo y aplícalos al dominio adecuado.

Como ejemplo de limitar el dominio adecuado, considera una empresa que vende equipamento médico. No puede vender su producto mediamente hecha y esperar mejorarlo cada dos semanas con las opiniones de sus clientes. Un laboratorio médico puede tardar un año entero probando que tu producto funciona como deseado. Te puedes imaginar como se alegran de poder repetirlo cada mes. Pero lo que puedes hacer, es producir versiones tempranas durante el desarrollo del producto para poder probarlo con todos los componentes existentes juntos. En este caso el método ágil no funciona con el cliente externo, pero, sí, con clientes internos.

No obstante, son muchos los elementos de los métodos ágiles que valen la pena tener en consideración.

  1. Empieza con un producto minimal, pero útil y con calidad. Lo “minimal” puede a veces ser todo, pero muchas veces no lo es. Y si lo poco funciona bien, los clientes estarán interesados en la próxima versión.
  2. A nivel de equipo de desarrollo, esto se traduce a generar una versión temprana para que otros equipos puedan integrarla. Puede ser incompleta, pero debería funcionar.
  3. Genera versiones con frecuencia, para que los demás equipos pueden tener la mejor versión posible en cada momento.
  4. Intenta dividir tareas grandes en tareas pequeñas pero completas en sí, para que puedas publicar algo en cada iteración.
  5. Usa ramas de desarrollo para añadir nuevas funcionalidades y siempre manten una versión que funciona. Puede ser tu rescate si un desarrollo no funcionaba.
  6. Sólo añade cambios completos. Completo quiere decir que haya casos de pruebas (que se ejecutan automatizados) y la documentación adecuada. (Actualizar la documentación es parte del cambio.)
  7. Limitarse a lo que es necesario. Lo necesario es a veces no tan fácil de reconocer. En primer lugar no es crear un vector de n elementos especificado para el caso n = 3, si sólo necesitas un vector de tamaño 3. En el mismo primer lugar es no crear documentación porque sí, sino por qué ya sabes denominar alguien, que la quiera leer. (Miembros nuevos del equipo, por ejemplo.) De otro lado hay decisiones en que hay que pensar hasta el final: La arquitectura del programa, los requisitos mínimos, si los programadores serán intercambiales (y por lo tanto se les permite más tiempo para aprender código nuevo), la estructura de crear y testear versiones etc. Una buena estrategia para limitarse a lo necesario es pensar: ¿ya tenemos un escenario en que esto va a importar? ¿Sí? ¡Entonces hazlo! ¿No? ¡Entonces espera con ello! No hagas cosas por si acaso sino porque alguien quiere pagar por ellas.
  8. Fomentar la comunicación. Las pequeñas reuniones diarias y un tablón con las tareas pendientes fomenta que todos ven como va el equipo en completo.
  9. Ten una estructura de comunicarse con el cliente. Los métodos ágiles demandan que los clientes están presentes en el equipo de desarrollo. Esto es muchas veces imposible. Pero debería haber alguien que pueda presentar la vista del cliente – y esto será preferiblemente uno que entiende realmente a clientes aunque no entienda de todo a los programadores.
  10. Dejar a los programadores estimar cuánto tiempo necesitan para una tarea y dejarles decidir, a cuantas tareas se quieren cometer. Tendrás una mejor estimación de tiempo y los planes se basan en las palabras de aquellos que deben cumplirlas. Es decir, en lugar de “esto necesito hasta viernes” preguntar “qué necesitas pra terminarlo hasta viernes”.
  11. No cambies planes durante una iteración. Deja suficiente tiempo libre para atender a emergencias típicas.
  12. Intenta terminar el plan de una iteración. Si un programador ya hizo todo su trabajo, entonces quizá puede ayudar a otro en crear casos de pruebas o actualizar la documentación.

En fin, esto no es un pamfleto contra los método ágiles, pero uno contra su aplicación religiosa. Y un recordadorio que todas las culturas tienen puntos fuertes. Hazte conciente de ellas antes de adoptar algo sólo porque aparenta tener éxito en EEUU.

Lectura adicional

Por qué utilizar un wiki

Siempre cuando alguien entra como empleado en una nueva empresa, se puede observar un comportamiento que es casi común a todos los novatos. Las primeras semanas nunca se van sin su cuaderno y su bolígrafo cuando van a hablar con alguien. Ahí se apuntan, quién es el responsable para qué proyecto, que es la dirección IP de su equipo y en qué carpeta de red se encuentra qué documento. Tras unos meses, estas ganas de apuntarse todo se van. Ya han aprendido lo más importante y lo nuevo memorizan.

Todos los nuevos empleados apuntan más o menos lo mismo en su cuaderno. Esto no extraña ya que empiezan a trabajar en la misma empresa. La pregunta es, ¿por qué los veteranos no pasan sus cuadernos a los nuevos empleados? Con esto ya tendrían apuntado todo y lo único que necesitan es actualizar alguna información obsoleta.

Pues, esto se puede hacer con un wiki. En un wiki, cada uno puede escribir lo que sabe y puede corregir lo que los demás ya han apuntado. La meta de un wiki es unir el saber de dos medio sabios a un conocimiento completo. El sitio más famoso que funciona con este método es la Wikipedia – de ahí el nombre “wiki”. Pero el mismo software se puede usar también para la empresa.

En lugar de apuntar tus notas en un cuaderno, lo haces en un wiki. Otro empleado nuevo puede entonces utilizar estas notas ya hechas y completarlos con lo que faltaba por apuntar. Un empleado veterano puede corregir información insuficiente. De esta forma surge un sitio de información completa, que está vivo y se actualiza constantemente – al menos si los empleados lo utilizan en lugar de sus cuadernos.

Cómo utilizar un wiki

La pregunta es, qué tipo de información ponemos en un wiki. Para cada proyecto ya suele haber una documentación que no hace falta repetir. Por eso ponemos en el wiki lo que no hemos puesto en ningún lado todavía.

Típicamente escribimos en un wiki lo que llamamos “meta-información”. No guardamos la documentación del proyecto, sino dónde está guardado o quién podría ayudarnos. Es decir, apuntamos lo mismo que el nuevo empleado apuntaría en su cuaderno. Sólo que de esta forma la información está disponible para todos y se puede actualizar y mejorar continuamente.

Usar el wiki puede ser más rápido que un cuaderno. Recibimos un email con los enlaces a los ficheros fuente. Pegamos este email en el wiki y ya tenemos una página con los enlaces importantes. Preguntamos el cliente sobre las especificaciones que faltaban en la especificación y apuntamos las respuestas en el wiki. Así no sólo tenemos toda la información en el mismo sitio, sino surge automáticamente una parte de la documentación del proyecto.

De esta forma el wiki no sólo puede sustituir a los cuadernos sino también a los archivos de email. En lugar de que cada uno tiene su colección de correspondencia, la ponemos a disposición de todos los interesados. Un wiki puede incluso sustituir presentaciones de tipo PowerPoint. Simplemente proyectamos a la pared la página correspondiente en lugar de una presentación. La información presentada ya está en el wiki y si hace falta cambiar algo, se puede corregir directamente durante la presentación. Al final de la presentación, los oyentes puede consultarla en el wiki al salir de la sala de reunión.

Qué tipo de wiki es recomendable

El software más conocido es “Wikimedia”, que es lo que usa la Wikipedia. No obstante, esta aplicación no ofrece tablas de contenido con jerarquía que permitiría ordenar páginas con una estructura lógica. El wiki “Confluence” de la empresa Atlassian tiene esta funcionalidad, pero este es de pago. Hay tantos tipos de wiki distintos que alguien amable ya creó el sitio Wiki Choice Wizard, para elegir el más adecuado para tus necesidades.

Vale la pena dedicarle tiempo a la selección del tipo de wiki, ya que será una herramienta con un uso de larga duración.

Lectura adicional

Desde años espero que algún gurú norte-americano en economías diga que la subcontratación excesiva de empleados no sólo es mala para los empleados sino también para las empresas. No es que haga falta un gurú para darse cuenta de esto, pero hace falta uno para que los directores de las grandes empresas escuchen el mensaje. Porque a los no gurús no hacen caso. Pero quizá no es en vano que, hasta que el gurú se pronuncie, lo explique yo, porque – aunque sea poco probable – no es imposible, que un alto cargo de una gran empresa española navegue en alguna hora baja de su vida laboral por Internet a la búsqueda de inspiración de como reducir costes en su empresa y se estropiece justamente con mi blog.

Es cierto que la subcontratación es un mal menor para tantos desempleados que ya estaría contenta con cualquier forma de empleo y es lógico que la atención pública se dedica en primer lugar a sus necesidades. No obstante, la subcontratación excesiva es síntoma de una cultura empresarial que agrava la crisis y que impide que España alcance un nivel tecnológico y salarial tan alto como los países más avanzados.

La subcontratación ya es tanta que parece ser una excepción trabajar para la empresa que paga tu salario. Las grandes empresas tienen la tendencia de sólo emplear a jefes. Aquellos que hacen el trabajo real, se subcontratan. Lógicamente las empresas subcontratadas pueden subcontratar estos empleados a otras empresas, que a su vez las subcontratan donde pueden. Es posible que se haya pasado un empleado como “servicio” por varias empresas, cuando realmente sólo trabaja en la última.

Esta situación puede llegar a situaciones absurdas. Por ejemplo, puede que un empleado no debe revelar en su puesto de trabajo la empresa que paga su salario, ya que su empresa A le alquiló a una empresa B que le presenta como uno de los suyos a la empresa C. La empresa C ya no conoce la empresa A, pero de alguna forma depende de ella. Si la empresa A quiebra o no paga correctamente la seguridad social para sus empleados, es posible que el empleado desaparece de un día al otro.

Esta falta de transparencia es similar a la causa de la crisis financiera. Primero los inversores podían comprar seguros sobre créditos hipotecarios. Luego podían comprar seguros sobre los seguros de créditos hipotecarios y finalmente seguros sobre seguros sobre seguros. Nadie podía calcular, como afecta la incapacidad de un deudor de pagar su hipoteca al valor de estos seguros de seguros asegurados.

No obstante, el primer afectado en el mundo de empleo es el empleado. Cada “sub” en su empleo subsubsubcontratado se queda con una parte de su salario y la suma de estas partes puede ser más que él finalmente recibe. Y esto trae lógicamente un problema para la economía en general. Si cobras más alquilando personas que creando un valor añadido real, entonces no extraña que nadie quiere trabajar algo productivo.

Otro problema de la economía española es una cultura empresarial sin perspectiva a largo alcance. En las empresas más prestigiosas del mundo, se hace todo para que los empleados se queden en la empresa. En España se hace todo para que sea lo más fácil deshacerse de ellos. En las empresas más prestigiosas, los mejores empleados cambian su puesto dentro de su empresa para ampliar sus conocimientos. En las empresas españolas, los mejores empleados cambian la empresa, porque es la única forma eficaz de ampliar sus conocimientos. Saltando empleos en otros países sería una indicación, que está algo mal con el empleado. En España es una expresión de que está algo mal con las empresas.

Esta falta de lealtad de la empresa a sus empleados tiene lógicamente consecuencias negativas. Para una empresa española es mucho más difícil enfrentarse a proyectos complejos, ya que requieren personal con mucha experiencia que no tiene. Los empleados subcontratados se identifican menos con la empresa y con sus intereses. Ven más fácilmente su situación de empleo como un abuso y les preocupa menos abusar en cambio de la empresa. Los empleados subcontratados no se van a la huelga para hacer su empresa mejor. Simplemente se van a otra empresa que ya es mejor.

Es lógico que, en un entorno así, es imposible acumular las décadas de experiencia tecnológica que tienen las empresas más avanzadas. Y es comprensible también, que los mejores empleados se van del país, porque quieren trabajar para estas mejores empresas. Así, los que se quedan tienen aún más difícil avanzar en productividad y nivel tecnológico, que son la base para tener empleos estables y bien pagados. Con ellos, la crisis económica sería menos grave en España.

La pregunta ahora es: ¿por qué es así? No creo que este problema se debe a una falta de dinero o de suficiente gente bien formada. Esto se debe únicamente a una organización económica que se podría cambiar sin gasto adicional. Y esta organización del empleo deciden los directores de las grandes empresas.

Las empresas de trabajo temporal (ETT) y las “consultorías” sólo aprovechan las oportunidades de negocio que se ofrecen. Pero estas oportunidades existen porque las grandes empresas las han creado. Si deciden emplear directamente a todas la personas que necesitan para el trabajo que tienen, entonces todo este sistema de ETT y “consultorías” se redujera a un nivel en que realmente aportarían un valor añadido.

La subcontratación es algo útil cuando sirve para aplanar picos de trabajo o trabajos fuera del negocio principal de la empresa. No obstante, subcontratar empleados para departamentos clave, merma el modelo de negocio. Traspasa el conocimiento clave de la empresa a terceros.

Es razonable también subcontratar a otra empresa para la búsqueda de posibles empleados, pero sólo la búsqueda. Subcontratar a empleados durante años no ahorra dinero. Una gran empresa no tiene por qué pagar más para la gestión de cada empleado que una pequeña. Al contrario, puede aprovechar mejor sinergias.

Es posible que los altos cargos en las grandes empresas viven bien con la cultura empresarial en España ya que se encuentran al lado privilegiado del despilfarro. No obstante, quizá les motiva el hecho, que en las empresas más prestigiosas no sólo los empleados simples cobran bastante más, sino sobre todo los altos cargos.

En fin, aprender del líder ayuda a mejorar tu propia posición. Seas quien seas.

Lectura adicional

Hay muchos artículos sobre cómo conseguir un trabajo. Normalmente lo escribe un empleado del departamento personal para los candidatos que solicitan un trabajo. Este artículo es el caso contrario. Lo escribe un empleado para aquellos que seleccionan empleados.

La empresa que no consigue empleado

Los empleados del departamente personal suelen dedicarse todos los días a hacer entrevistas de trabajo. Así no sorprende que suelen tener más experiencia que los candidatos. Pero igual como un candidato mal preparado, un entrevistador también puede conseguir dañar su reputación (y, además, la de su empresa) de forma irreparable con pocas faltas. Es fácil evitarlo, pero mi experiencia ha demostrado que tampoco es tan fácil.

Unas “perlas” de mi experienca como candidato:

  • Esperar media hora o más a la entrevista.
  • Esperar veinte minutos de pie sin que nadie me atienda. (Sic!)
  • Pedirme que escriba a mano mi currículum de memoria en un formulario mientras espere al entrevistador a que ya envié mi currículum en formato Microsoft Word.
  • Tener un entrevistador que no sabía explicarme, por qué debía entregar dicho currículum manuscrito. (Son reglas que se inventan en recursos humanos, ¡yo qué sé por qué!)
  • Descubrir que el entrevistador no se había leído nada de mi currículum.
  • Tener un entrevistador de emergencia no preparado porque el que debía hacer la entrevista no estaba.
  • Conocer a una headhunter que me pedía que rastreaba una bolsa de trabajo online pública por puestos de trabajo en que podía encajar y enviarme los enlaces para que ella pueda presentarme a la empresa.
  • Solicitar que vaya a empezar en una empresa lo más rápido posible sin ni siquiera hablar del salario.
  • Ser rechazado entre otras razones porque no vivía en el sitio X, cuando expresé mi deseo a mudarme al sitio X.

Todavía no sabes qué empresa es y qué puesto de trabajo ofrecen, pero ya tienes la sensación de mejor intentarlo en otro sitio. Así de contundente pueden ser seleccionadores de personal.

También existe el otro extremo: una empresa, que paga el viaje y el hotel para poder atender a la entrevista de trabajo. Para comenzar a trabajar, te paga la mudanza, un piso temporal para tres meses, la búsqueda de un piso y un salario extra para que no te arrepientes por irte con ellos. Para una empresa así trabajo hoy.

Entre los dos extremos quedan muchas opciones. Pagar tanto a los futuros empleados es un lujo que muchas empresas no se pueden permitir, pero tener la actitud correcta hacia los candidatos es gratis. Y este artículo va sobre esta actitud.

El anuncio

El anuncio es la primera impresión que tiene un candidato de tu empresa. Los buenos candidatos aplican los mismos trucos para conocer a tu empresa que tú usas para conocer a los candidatos. Ellos leen entre las líneas. Y un anuncio contiene muchos metadatos.

El título

No hace falta que diseñes el anuncio como una publicidad para vender algo que la gente no necesita, porque alguien que busca un trabajo ya está dispuesto a leerlo. Lo que importa es que la gente lo encuentre entre miles de otros anuncios. No pongas algo inespecífico “Buscamos los mejores talentos”. El primer filtro es el qué y el dónde. “Ingeniero de software C++ en Madrid” es un buen título.

El aspecto

El cuerpo del anuncio debería estar bien estructurado. Yo suelo leer los anuncios al revés: primero qué experiencia piden, entonces qué contenido tiene el trabajo y luego qué es la empresa. Es más práctico así, porque si no tengo la experiencia requerida, entonces el resto ya no hace falta leer. Y si no me gusta el tipo de trabajo, entonces tampoco necesito saber, para qué empresa.

Con esto no quiero decir que escribes tu anuncio al revés – es correcto empezar con la descripción de la empresa, luego el puesto y finalmente el candidato. Lo que pido que sean secciones claramente reconocibles. A ti tampoco molesta que un currículum empiece con los datos personales siempre y cuando es fácil de encontrar lo que te interesa probablemente primero: la formación y experiencia laboral.

Si rellenas un formulario para anuncio en una bolsa de trabajo en Internet, entonces hazlo tan bien, como tú puedes aceptar que los candidatos hayan rellenado el formulario para publicar su currículum. Errores ortográficos o un mal lay-out no atraen justamente a los superdotados con amor al detalle. Tampoco te pases hacia el otro lado. Si busco un empleo en una empresa pequeña, me da más confianza, si el anuncio no parece haber creado por un diseñador profesional.

Los requisitos mínimos

Para mayor claridad pon los requisitos para los candidatos en dos listas.

  • Una para los requisitos mínimos
  • Otra para los requisitos deseables

No exijas veinte requisitos mínimos a un candidato. El único que realmente los tiene es la persona que acaba de abandonar tu empresa. Otro candidato o bien no los toma en serio y te envía una solicitud aunque cumpla sólo con cinco, o los toma en serio y no te envía nada aunque tú lo emplearías cumpliendo con sólo cinco requisitos mínimo. En ambos casos da la impresión que él no es el mejor para esto puesto y tu empresa no la mejor para él.

Para un desarrollador de software, los requisitos mínimos son normalmente cinco y siempre menos que diez.

  1. La formación mínima
  2. El lenguaje de programación principal
  3. Las tres bibliotecas y herramientas principales sólo si son imprescindibles
  4. La experiencia mínima en hacer algo
  5. Saber inglés.

Todo lo demás es requisito deseable. Esta lista es más libre, pero también es necesario evitar lo obvio y ser específico. Tener alguien que sabe todo siempre es deseable. No obstante tu empresa no querrá pagarle todo. Limita los requisitos a lo que trae un valor añadido a tu empresa y su salario.

Frases vacías

Sony vende equipos electrónicos, Telefónica es una operadora de telecomunicación, Siemens vende máquinaría eléctrica. El electricista de tu barrio se vende como experto en equipos electrónicos, telecomunicación y máquinaria eléctrica. ¿Un solo hombre sabe tanto que los miles de empleados de tres grandes compañías?

Tu empresa puede aparentar más cuando en menos dominios tiene experiencia. Igualmente puede impresionar más, si el lenguaje del anuncio de puesto de trabajo está redactado sin palabras “gloriosas”.

Expresiones en una descripción de empresa y su significado real
Expresión Significado
Somos líder No somos líder. Una empresa realmente líder no pondría “líder”. Pondría “somos la empresa de X más grande del mundo”.
Somos una empresa líder en nuestro sector Nuestro sector es la venta de pan en nuestro barrio y sólo hay dos panaderías. Podríamos poner “somos la productora de pan más importante en nuestro barrio.” Como esto queda ridículo, ponemos “líder”. No obstante, queremos decir lo mismo.
Colaboramos con las empresas líder Mal: vendemos pan a sus empleados
Peor: Somos una empresa de subcontratación
Somos una consultoría Al contrario de una ETT, no alquilamos trabajadores para trabajos manuales, sino alquilamos empleados con formación universitaria. Si el cliente ya no los quiere, les buscamos “otro proyecto”. O al menos, esto es el mito en que creemos.
Somos una consultoría pequeña Somos una consultoría cuya oficina es en un apartamento de cuatro habitaciones.
Buscamos los mejores talentos Bien (gran empresa de un país con ranking económico AAA): podemos permitirnos los mejores salarios.
Mal (todos los demás): copiamos y pegamos frases de otros anuncios
Plan de formación continua Mal: todos los días aprendes algo nuevo en el trabajo.
Mal también: ofrecemos cursos, pero únicamente fuera del horario laboral.
Peor: la parte variable de tu salario depende de si vas a hacer estas horas extras.
calidad Bien: antes que toques la primera cosa, dedicas un mes a leerte los procedimientos de la elaboración, implementación y verificación de los distintos niveles de requisitos.
Mal: lo importante es que funcione
La satisfacción de nuestros clientes nos avala. Pero tú no eres cliente sino empleado. Y sobre esto mejor no escribimos nada.
Somos una empresa de 100% capital español. Y por eso no esperes que oranizamos el trabajo como los alemanes.
Nuestra plantilla tiene un 100% de ingenieros No obstante, en la oficina trabajan empleados de dos empresas más. La “subcontrata basura” para las mujeres de limpieza y demás empleados y el “club de amiguetes” para los altos cargos.
La edad media de nuestra plantilla es de 27 años. Mal: Tu jefe tiene 27 y no vas a subir puesto hasta que se jubile.
Peor: Nadie que está bien en la cabeza aguanta aquí más que tres años.
Somos especialistas en X. Somos una gran empresa en el sector X.
Somos especialistas en X, Y, Z, A, S y T Somos una pequeña empresa que está dispuesta a hacer todo lo que se ofrezca.

La página web

Alguien, que toma en serio la empresa para que piensa trabajar, se informa sobre ella en Internet. Como futuro empleado me interesa cuántos empleados tiene y qué proyectos hace. Y por eso debería ser posible encontrar esta información en un tiempo razonable.

Esto parece demandar poco pero a menudo no lo es. El caso más extremo que vi era un sitio web todavía “en construcción”. Más tarde encontré que esta no era la única página de esta empresa. Hubo otra razonable bien. Aún así era suficiente para no enviarla mi currículum.

Los casos menos extremos tienen una página pero sin utilidad. Está sobrecargada con algunos efectos, pero no está claro donde está la información. La opción “sobre la empresa” te acerca a la información deseada, pero hasta ahora nunca encontré una página con “lo que interesa a futuros empleados”. ¿Por qué? Si quieres que los candidatos sepan lo más importante de tu empresa, porque no puedes ponerles esta información en Internet? Al final quieres que lo sepan, ¿verdad?

Igual como los anuncions, las páginas web deberían representar a la empresa de una forma auténtica. Si quiero trabajar en una panadaría del barrio, entonces me parece más simpática una página web simple que una que intenta competir con una compañía multinacional.

En fin, en general es mejor un sitio web simple pero informativo que sobrecargado o incompleto. Mejor para el lector de la página, por lo menos.

El currículum

El currículum es un arte que debe manejar el solicitante de empleo. No obstante, es responsabilidad de la empresa de cuántas unidades de currículum pide.

  1. Uno en el formato propia de la bolsa de trabajo online
  2. Otro en formato Microsoft Word
  3. Grandes empresas y otras que pretenden serlo te piden que, además, te registres en su propia base de datos.
  4. Y finalmente ya me pasó que debía escribir mi currículum a mano en un formulario antes de la entrevista.

Y con esto todavía no es suficiente currículum a veces. Sería bien tenerlo también en inglés y/o un currículum detallado para saber todos los proyectos en que has trabajado.

Pues, yo tengo una vida y para esta debería bastar un currículum. Está bien, pedirlo en formato Microsoft Word (o mejor PDF), pero más allá empieza a dar la impresión, que en tu empresa “de alto valor añadido” no se aclaran ni con el formato del currículum.

También ten cuidado a pedir a candidatos que rellenen tu base de datos online. Esto vale para las diez empresas más atractivas del país, pero la tuya será como mucho el número once. Antes de editar mis datos por n-ésima vez, prefiero solicitar empleo a una empresa donde el departamento personal no me pide que yo haga su trabajo.

Si no puedes prescindir de una base de datos editada por los candidatos (porque trabajas para los top 10), entonces establece alguna asitencia informática, que puede extraer información de un currículum en formato Microsoft Word o PDF.

La entrevista de trabajo

La entrevista de trabajo permite al seleccionador concocer al candidato en persona. Pero también permite al candidato conocer a la empresa. Y para él, la empresa en este momento es la gente con el habla (los entrevistadores) y la oficina donde está entrevistado.

Puede ser que no hace falta prestar demasiada atención a estas cosas mientras entrevistas a desempleados que están felices con cualquier trabajo que les ofreces. Pero la cosa se puede cambiar drásticamente, si el candidato cobra más que el seleccionador.

Durante la entrevista, no sólo el candidato sino también la empresa debe mostrarse de su mejor lado, si quiere ser atractiva. Por eso las empresas más atractivas (típicamente con menos del 100% capital español) se gastan un dineral en gastos de viaje y hoteles, para que los talentos de verdad no se lo piensan dos veces. Tratan al candidato como un cliente. Invitan al candidato a una bebida si tiene que esperar o incluso a una comida si ha venido de lejos o debe pasar un largo tiempo en la sede de la empresa.

Al lado contrario hubo experiencias que dan lugar las las siguientes recomendaciones:

  • Tú quieres que el candidato sea puntual. Pues, no le dejes esperar tampoco. Ten tiempo para él, sino cambia la hora de la entrevista.
  • Si no estás seguro que puedes dar la bienvenida tú, encarga alguien como la recepcionista de ofrecerle al menos un sitio donde sentarse.
  • Si el candidato debe esperar, déjale esperar en un sitio confortable con algo a leer y al menos agua a beber. No le encierres solo en una sala de reunión hasta que alguien venga. Lo correcto es que el entrevistador le recoja en la recepción.
  • No le pidas su currículum en tres formatos diferentes. Un candidato os envía un formato que podéis imprimir, pero no tiene por qué entender vuestro formato “interno”.
  • Estudia su currículum antes de la entrevista. Queda elegante esconder sus lacunas con la pregunta “Explícame tu currículum con tus propias palabras”. Pero queda fatal si das impresión de no saber nada de él cuando le has pedido un currículum con antelación.
  • Tampoco te pases por el otro lado: si rastreas el Internet por fotos embarazosas del candidato puede ser que colaboras en un acoso. A ti tampoco te gustaría que tu empresa te trataría así. Además, la información puede ser manipulada. Mucha gente no sabe qué fácil es, que una foto únicamente para los “amigos” en un perfil “privado” de Facebook acaba siendo pública. Y tampoco sabe quién más sube fotos o información con su nombre.
  • Conoce bien el puesto que tienes a ofrecer y sé honesto con sus contratiempos. Mentir es malo, también por parte de la empresa. Contratar a alguien que se va a los pocos meses con una mala opinión sobre la empresa no te conviene.
  • Intenta hacer la entrevista una experiencia positiva. Pasas un rato agradable con otra persona y le puedes dejar una buena impresión. Quizá él no sea la person adecuada, pero si tiene buenos recuerdos de ti, puede recomendar tu empresa a un amigo.
  • Agradécele el tiempo y el esfuerzo empleado para la candidatura.
  • No olvides que quieres ser atractivo para un buen candidato. Trátale como un posible cliente. Algo que no pidas a un cliente, tampoco lo pidas a él.

Conclusión

En tiempo de crisis es fácil encontrar cualquiera como empleado. No obstante, los mejores vienen porque tu empresa es la mejor. Para un entrevistado, la imagen que das como entrevistador es la imagen de toda la empresa. Por eso trata a tus candidatos como clientes. Los empleados no compran productos, pero traen un valor añadido que también vale dinero. Si no tienes tiempo suficiente para todos los candidatos, mejor invitas uno menos para una entrevista. Antes que des una mala imagen, mejor des ninguna. Los entrevistadores también tienen días malos, pero por eso no dejan de ser profesionales.

Los empleados altamente cualificados pueden acabar en puestos de trabajo influyentes, donde pueden decidir, como su compañía gasta el dinero. Para ellos, tener una buena experiencia en una entrevista de trabajo puede ser un punto importante a la hora de confiar a tu empresa como suministrador. Es decir, puede ser que ellos no trabajan para tu compañía por razones fuera de tu poder. Sin embargo, es posible que algún día, esta persona es la razón, porque tu empresa gana un proyecto importante. Como empresario, tu red social es un componente importante. Y esta red puedes ampliar también con entrevistas de trabajo.

Lectura adicional

Hay muchos artículos sobre lo que unos consideran programar bien, y por eso han inventado muchos conceptos para conseguirlo: encapsulación, modularización, convenciones de nombres, orientación a objetos, comentarios de documentación y muchos más. Así de bonita la teoría.

En la vida real nos encontramos con líneas de código que no caben en una pantalla (y a veces ni en cinco), con funciones de mil líneas, con nombres de variables de una letra y, desde luego, todo sin comentarios. No es que los autores de tanta monstruosidad dirían que programaran bien – lo que hacen es “no perder tiempo con cosas innecesarias”.

Lo curioso es que programadores así muchas veces tienen éxito. Su criterio no es un buen diseño sino “que funcione”. Muchas veces llegan a hacer los programas funcionar antes que los informáticos afectados por conceptos académicos los suyos. Y el primero vende. Puede ser que el programador ordenado triunfa en un concurso de la NASA. En el mercado libre triunfa quien sabe vender. El primero vende su programa y los errores que quedan ya se arreglarán en la segunda versión – a saber cuándo y por cuánto – pero el consumidor ya tendrá la paciencia si una vez está acostumbrado a un producto.

Ahora me pregunto: ¿por qué gente con tanto éxito no escribe libros sobre cómo lo han tenido? Tenemos libros sobre cómo programar bien y otros cómo hacerte rico, pero ninguno sobre cómo hacerte rico programando. ¿Por qué no hay ningún artículo que te cuenta que el secreto no está en programación orientada a objetos sino en la programación orientada a objetivos?

“Orientado a objetivos” es una forma fina de “lo importante es que funcione”. Y no es una idea esotérica: hay bastantes ofertas de trabajo que lo piden – sobre todo para puestos de jefe. Si es así de deseado, ¿entonces por qué no se enseña la programación orientada a objetivos en la universidad? ¿Por qué nadie nos revela el secreto?

Tengo varias teorías:

  • Los profesores no tienen la preocupación de “a ver si gano lo suficiente al fin de mes” y por eso no se sienten lo suficientemente expertos para explicar la programación orientada a objetivos.
  • Hay una conspiración de programadores orientados a objetivos que mantiene secreto el saber de hacerte rico programando.
  • Un programador orientado a objetivos no es realmente un genio sino alguien que dispone de un algún colega ordenado con genio que le arregla los fallos en el código. La razón porque los programadores orientados a objetivos se hacen jefes es más bien porque el puesto de jefe es el único en el departamento de informática en que no hay que escribir código.
  • Personas que trabajan orientadas a objetivos se orientan a objetivos que han establecido otros. Mientras no hay nadie que les da el objetivo de escribir un artículo sobre “por qué es mejor no perder tiempo con buen diseño”, no lo van a hacer.

Pero me queda la esperanza que este artículo inspire a algún veterano de compartir su sabiduría. Cuando reconozco no haber llegado a entender como uno se puede sentir cómodo arreglando a una función con mil líneas, me atrevo a adivinar el verdadero fin de la programación orientado a objetivos: ¡psicología! No programas para un ordenador sino aprovechas las emociones del usuario final!

  • El fin de un programa no es un buen producto sino una buena venta.
  • Los consumidores no compran algo nuevo porque es bueno sino porque es novedoso. Aquellos que siguen la moda tecnológica más de cerca se interesan por lo que su nuevo capricho podría hacer. Para saber si realmente lo puede hacer no tendrán el tiempo suficiente hasta la próxima versión.
  • Las insuficiencias de un programa permiten ofrecer (y vender) una nueva versión del programa que a su vez puede contener nuevos errores.
  • Sacar nuevas versiones frecuentemente da más impresión de mejora continua que un producto que ya funciona bien desde el principio. Cuando más versiones en menos tiempo, menos posibilidades tienen los usuarios a descubrir los errores de una versión en concreto.
  • Siendo el primero en sacar un nuevo producto te convierte automáticamente en “experto” para el dominio. Te asignarán empleados que te ayudan a mantener el código que tú pronto dejarás de entender. Esto permite elogiar a tus colegas como los verdaderos expertos de tu código.
  • Algún empleado igual de listo como tú sabe que una larga lista de errores fijados encantará al director. Y por lo tanto asegurará que siempre habrá una lista larga. Así se cualifica para liderar pronto un equipo.

En todo caso es una estimación y reconozco mi insuficiencia en la materia. Antes de conocer a un experto del tema no me quedará otra que seguir programando como alguien a que castigan a volver a leer y entender su propio código una y otra vez.

Lectura adicional

Para los programadores orientados a objetivos
Para los demás

Guardar datos de forma segura implica dos necesidades

  1. Recuperar los datos perdidos.
  2. Prevenir que personas no autorizadas puedan acceder a ellos.

El primer punto trata de fallos técnicos o robo, el segundo por la protección de datos mediante contraseñas y encriptación. Ambos dominios son demasiados amplios para ser tratados en detalle aquí, así me limito a dar unas consideraciones a tener en cuenta.

Es casi seguro que alguna vez un dispositivo de almacenamiento deja de funcionar y se pierden todos los datos. Por lo tanto, guardar datos en sólo un sitio es una manera casi segura de perderlos algún día. Por eso se crean redundancias mediante copias de seguridad (back-up en inglés).

La forma más simple y directa es hacer una copia de seguridad en el mismo disco duro. Es una buena manera para guardar cambios pequeños, por ejemplo, para guardar cada hora el documento Word en que estás trabajando actualmente. Conviene mantener varias copias, porque a veces no te enteras que un documento fue contaminado por un virus o dañado de otra forma hasta días después. Por este motivo un sistema de respaldo en tiempo real (RAID) tampoco da toda la seguridad: no copia sólo los documentos en tiempo real, sino también los virus. Sin embargo, es, sin duda, el mejor sistema para protegerse contra fallos de hardware y una necesidad para una base de datos o cualquier otro sistema que nunca debe fallar.

Un back-up en el mismo disco duro no protege contra la pérdida de datos en caso de fallo del disco duro. Por lo tanto, conviene tener un segundo disco duro. Puede estar en la misma máquina o uno externo. Si tu ordenador no sufre una sobretensión que destruye sus componentes, estás a salvo. Más seguro aún es guardar copias de seguridad en un lugar físicamente desconectado del equipo. Basta con desenchufar el disco duro externo o guardar los datos más importante en un pen-drive o un DVD regrabable.

Esto te protege contra una pérdida total del ordenador pero no contra un robo o un incendio en tu casa u oficina. Para prevenir esto puedes guardar datos en la nube, es decir, en algún servidor en Internet. Esto es muy práctico, ya que puedes acceder a estos datos desde cualquier sitio, pero tiene la desventaja que ya no sabes quién más lee y usa estos datos. O igual ya te lo imaginas: empresas que ofrecen publicidad a medida o las autoridades que están constantemente preocupados que algún terrorista todavía no esté contratado o al menos conocido por el servicio secreto de tu país. Una manera de fastidiarles el negocio con tus datos personales es publicarlos en WikiLeaks. Otra es guardarlos en un DVD en la casa de tu abuela. La forma más segura de proteger tus datos sigue siendo no enviarlos por Internet. Y tampoco tiene por qué ser la más lenta. No subestimes el ancho de banda de un camión cargado con DVDs.

Más seriamente, guardar datos importantes fuera de hogar, pero en un sitio de confianza, protege contra males mayores. Igual como guardarías documentos importantes en papel en una caja fuerte en un banco, lo podrías hacer con un DVD con datos que no quieres perder – aunque sean sólo las fotos de tu boda. Y no olvides encriptar los datos si lo ves necesario.

El artículo “Guía definitiva para mantener tus datos seguros en caso de robo o pérdida de tu equipo” por Goyko Alexander Obrenovich Vinces da razones y consejos prácticos sobre elegir contraseñas, sistemas de respaldo e incluso una propuesta de como localizar tu equipo en caso de robo.

Referencias

Cuando empezamos con un nuevo proyecto, puede surgir la pregunta si se modifica un código viejo o se empieza desde cero. Reciclar código viejo para un nuevo proyecto ahorra tiempo, porque el código viejo ya está escrito y funciona. Escribir código otra vez también ahorra tiempo, porque es específico a lo que está pedido en el nuevo proyecto y un programador no necesita entender un código viejo difícil de comprender.

El ahorro de verdad está entre restaurar proyectos históricos y reinventar la rueda. Así la cuestión es ¿dónde está el punto óptimo entre reciclar y reinventar? Como en muchas ocasiones, no hay una respuesta fácil y, por lo tanto, no la voy a dar. En este artículo presento a condiciones de entorno a tener en cuenta a la hora de decidir si modifico lo viejo y empiezo de nuevo.

Un criterio es la calidad de documentación. Si un programador quiere aprovechar código de otro, no tendrá más remedio que entenderlo. Una buena documentación, que incluso incluye un razonamiento sobre el diseño y el uso de la biblioteca, es una gran ayuda. Entender código sin documentación sólo es beneficioso para secciones pequeñas de código. De otra forma existe el riesgo de pasar mucho tiempo para entender algo que posiblemente ni se puede usar.

En este contexto conviene saber que la herramienta doxygen permite generar gráficos de llamdas de funciones y herencia de clases a partir de un código existente. Doxygen permite llamar a una herramienta específica para la creación de grafos que se llama DOT.

A veces importa que se puede probar un software cuanto antes – especialmente donde se desean hacer pruebas exhaustivas como en la aeronáutica o la medicina. Otra motivación puede ser querer tener un prototipo funcional en cada momento. Entonces se intenta conseguir un código que compile y haga algo aunque sea poco. En este entorno puede ser preferible partir de un proyecto antiguo que funciona y modificarlo hasta que cumpla las nuevas especificaciones sin que deje de ser un programa funcional en ningún momento.

Algo importante a la hora de reutilizar código viejo es el grado de similitud entre el funcionamiento real y el funcionamiento deseado. Poder utilizar una biblioteca tal cual como es, es un argumento poderoso para utilizar el código viejo. Si, en cambio, hace falta tocar la mitad de las funciones, entonces mejor se aprovecha nada más que el fichero de cabecera.

De hecho, reciclar código no significa necesariamente copiarlo todo. La estructura de datos, la interfaz, un bucle o un comentario de documentación: es perfectamente válido empezar con un proyecto vacío y rellenarlo paso a paso con elementos de un proyecto antiguo. Esta es una manera muy útil cuando ya se sabe que el proyecto viejo contiene muchas partes útiles aunque el programador todavía se pierde entre tantas funciones. A la hora que avanza con su proyecto nuevo, entiende mejor las necesidades y puede buscar más eficazmente lo que necesita en el código viejo. En este caso el proyecto antiguo sirve más bien como un código ejemplo que un programa ya completo.

En general suele ser un buen compromiso utilizar lo viejo si cuesta poco utilizarlo y hacerlo nuevo en el caso contrario. Muchas veces no se cambia sólo la funcionalidad sino, además, otras circunstancias de contorno. En lugar de una conexión de puerto serie se usa un puerto USB, el sistema operativo usa 64 bits y no 32, el estilo de código de ahora es mejor que el utilizado en el código antiguo o quizá se piensa crear la aplicación como una página web y no un fichero ejecutable. En corto: si ya te toca tocar código viejo, hazlo de forma contundente.

Hemos visto que el grado de documentación, la necesidad de hacer pruebas o tener prototipos son circunstancias importantes de modificar lo viejo en lugar de empezar de nuevo. Por la similitud entre lo que está hecho y lo que se quiere hacer se elige hasta que grado se copian componentes antiguas: de módulos enteros via apartados de código a meramente inspiraciones para el nuevo proyecto.

Referencias

Hoy en día hay muchos programas potentes gratis que podrían perfectamente reemplazar programas de pago – estos últimos aquí reunidos en el término “Microsoft”. Cuando las razones de usar algo gratis en lugar de pagar son obvias, todavía hay argumentos importantes por qué las empresas siguen pagando licencias de software. En este artículo quiero enumerar algunas razones.

Relacionado con este texto son los artículos “Como pasar tu empresa de Microsoft a código abierto” y “Crear software de pago con código abierto”.

Una razón importante para seguir usando software de pago es su popularidad. La inmensa mayoría de no expertos que “sabe” de ordenadores conoce el sistema operativo Microsoft Windows y usa Microsoft Office. Aunque es cierto que podría aprender Linux y Open Office de la misma forma, las empresas se ahorran pagar formación si se aprovechan de los conocimientos de los empleados directamente.

Además, como todo el mundo usa Microsoft Office, las pérdidas de tiempo por posibles incompatibilidades con otros productos similares fomenta el uso Microsoft Office. Cualquier otro producto aunque sea gratis se va a medir también por su compatibilidad con el programa que tiene la hegemonía en su dominio.

Otra razón de evitar el cambio es el esfuerzo en tiempo y dinero que implica el cambio. Especialmente bases de datos y sistemas que trabajan en tiempo real durante 24 horas son difíciles de cambiar. Debe haber un momento en que se para el programa, se pasan los datos al nuevo sistema que luego debe funcionar sin errores. Algo muy difícil de conseguir en la práctica. Tan difícil que muchos bancos no se molestan a pagar buenos salarios a quienes sepan trabajar con código en COBOL de los años setenta. En estos casos la opción suele ser añadir un nuevo componente alrededor del núcleo existente. El resultado es una aglomeración de componentes y tecnologías cada menos comprensible.

Muchas veces hay incompatibilidades entre software existente y uno nuevo. Por ejemplo, un fabricante sólo ofrece un controlador de impresora para Microsoft Windows pero no para Linux. Tiempo es dinero y una solución que funciona es preferible a una que todavía se debe buscar – muy especialmente cuando el enfoque es a corto plazo.

Programas de pago suelen ser más aptos para principiantes. Se pueden instalar con un click y se pueden conseguir resultados aceptables fácilmente. La otra cara de la moneda se muestra cuando uno quiere hacer cosas serias y fallan. Los formatos de ficheros de datos son a menudo desconocidos en software de pago y dificultan la depuración del código. Y código abierto se deja, al menos en principio, modificar si hace falta.

Y finalmente, a menudo software de pago es la única alternativa que ofrece una funcionalidad determinada. Esto es especialmente cierto para productos novedosos y aplicaciones hechas a medida.

Referencias

Si tu compañía quiere reducir el gasto en licencia de software, entonces encuentras en este artículo algunas pautas de como cambiar a programas sin coste. Sin embargo, conviene conocer las “Razones para seguir pagando” antes de meterse en líos y puede interesar de como “Crear software de pago con código abierto”.

Utilizar un software diferente al habitual puede afectar a una gran parte de la compañía. Por lo tanto debe ser una decisión por el mando responsable. Muchas veces conviene seguir usando las aplicaciones habituales y no pasar a código abierto antes de querer comprar una versión nueva del programa habitual.

En este marco se opta por software de código abierto en primer lugar para software nuevo, es decir aplicaciones que aportan una nueva funcionalidad que todavía no se ha usado dentro de la compañía hasta entonces.

En un segundo nivel se puede intenta cambiar aplicaciones habituales que no funcionan en tiempo real a una versión gratuita. Para esto puede ser necesario dar unos pasos intermedios. Por ejemplo, un paso intermedio podría ser copiar los clipart de Microsoft Word a un directorio aparte para seguir usándolos. Otro paso podría ser convertir los documentos creados con el programa de pago a un formato abierto. Un caso concreto sería convertir los documentos de Microsoft Word *.doc al formato OpenDocument *.docx – aunque este igual no será necesario porque el sustituto OpenOffice puede importar ambos formatos.

Aún así conviene tener presente ambos programas durante una temporada de adaptación. Y siempre es recomendable mantener algún ordenador antiguo con el software antiguo si una pérdida de datos no sería asumible por la compañía.

Muchas veces programas de código abierto pueden importar datos de Microsoft. El cliente de email Thunderbird puede importar direcciones y correos de Outlook, Mozilla Firefox puede importar marcadores de Internet Explorer. Lo mismo no vale en la dirección contrario. Productos de Microsoft no suelen poder importar datos de aplicaciones libres.

Otra faceta a contemplar sería buscar alternativas al uso habitual. Por ejemplo, en lugar de pedir un currículum vitae en formato “Word” se puede favorecer el formato PDF para documentos imprimibles. Se puede usar XML en lugar de guardar datos en formato binario.

El nivel de cambio más sofisticado será el de un sistema operativo o de procesos en tiempo real. Ahí surge el problema que hay que cambiar todo el software de golpe – funcione o no funcione. Casí nunca es rentable cambiar sistemas ya operativos, pero es factible añadir nuevos sistemas con Linux. Para ello es necesario que el intercambio de datos sobre una red use un protocolo con un estándar abierto para que diferentes ordenadores pueden entenderse aunque usen un sistema operativo diferente.

Un uso de varias plataformas fomenta también el uso de lenguajes de programación independientes de una plataforma en concreto – como Java o lenguajes interpretados como PHP, perl, etc, ya que facilitan migraciones de software de un sistema a otro.

Referencias

Una situación peculiar es la creación de software de pago con componentes de software abierto.  Las licencias de software abierto ponen normalmente una condición que se deja resumir así: puedes usar este software gratis en tus propios proyectos siempre y cuando tu dejas usar tu nueva creación también de forma gratuita. Si esto no es la intención, entonces suele ser posible comprar una licencia. Esto es  un caso poco frecuente, pero puede ser interesante para una empresa con una buena posición en su sector.

Un caso más probable puede ser la creación de un software propietario para el uso interno de la empresa. En este caso no suele hacer falta pagar una licencia de software abierto, porque el pago está condicionado a vender un producto. No obstante, no estás obligado a dar tu software a nadie.

El escenario mencionado sólo se refiere a usar un software de pago como un componente en tu aplicación. No se refiere al uso para crear contenido de pago. Por ejemplo, puedes crear una librería de pago con el lenguaje de código abierto PHP, porque el software del lenguaje PHP no forma parte de la librería. El caso contrario sería vender tu propio lenguaje de programación que usar el parser de PHP aunque sea en una versión modificada.

También los ficheros creados con software gratis suelen ser tu propiedad. Por ejemplo, puedes vender textos creados con OpenOffice Writer aunque no hayas pagado por este procesador de texto.

Desde luego, para no violar la ley, es recomendable leerse la licencia (aunque suele ser un rollo). Porque cada licencia es diferente.

Referencias

Escribe tu dirección de correo electrónico para suscribirte a este blog, y recibir notificaciones de nuevos mensajes por correo.

Únete a otros 51 seguidores

Archivos

agosto 2018
L M X J V S D
« Abr    
 12345
6789101112
13141516171819
20212223242526
2728293031