Category Archives: Opinión

Motivación, Estudios y Profesionalidad

Ayer, además de dar la conferencia que publiqué (en el post anterior), asistí a una conferencia denominada Y tras la Facultad ¿Ya soy Profesional?, impartida por Oshcar Vidal (no, no me he equivocado al escribirlo, la h es un valor añadido para crear branding).

En principio, supongo que por prejuicios (positivos) me hice espectativa de que la ponencia fuese como ir a un concierto, asistir a un evento ameno, entretenido y que se comentarían aspectos a tener en cuenta cuando se terminan estudios tales como son los facultativos o universitarios.

Mi opinión sobre la charla

Mi balance sobre la charla en sí fue el mismo que comparto con más gente que asistió (no todos), de que la charla fue algo rancia, pero sin acritud. Es decir, después de haber estado mucho tiempo estudiando y leyendo, viviendo, formas de hacer software, convivir con personas (porque muchos trabajos es casi como si vivieras con la gente), que tienen gran sabiduría y de las que se aprende un montón, llegan otras que nos dicen que tienen la panacea, al fórmula que pueden aplicar y hacer que todo vaya a mejor. No me lo creo.

En sí, los valores que intentaba inculcar: el tener un valor diferencial, crear marca propia, una imagen, y destacar sobre el resto; la pretensión de buscar siempre la perfección, sobresalir, puede crear que el trabajo en grupo, en equipo, se haga muy complicado. Personalmente, a un individuo que solo busca su beneficio personal (no estoy diciendo que Oshcar sea de este tipo de personas) es importante destacar, que se le vea y competir con los demás, incluso dentro de su empresa.

Aunque la sana competencia es importante para mejorar profesionalmente, sinceramente, valoro más que la gente sepa trabajar en equipo, que sea colaborativa y que mire por el equipo. Que haya un individuo que sea independentista, un astro de su materia, puede ser ventajoso, o incluso todo lo contrario, ya que el factor de medida del equipo y la carga se pueden volcar automáticamente sobre él y hacer que el trabajo salga, solo si el astro se encuentra en forma.

Las mismas valiosas personas que de forma individual son grandes trabajadores, si se potencian y enfocan al equipo, pueden hacer grandes y potentes equipos y, personalmente, prefiero que rindan al 75% la mayoría de personas de mi equipo, a que lo haga una sola de ellas al 100% y el resto al 20%.

¿Soy profesional?

A la pregunta, y tras la facultad, ¿soy profesional?… pues como es lógico, no, no lo eres, porque la profesionalidad es un grado que se consigue a base de experiencia, y la experiencia no es teoría, sino práctica. El profesional es una persona que trabaja en un cargo, durante un tiempo determinado y demuestra que sabe desempeñarlo con diligencia. Por tanto, la única forma de ser profesionales, es serlo, valga la redundancia.

El tema de fondo, quizás más importante, ¿la facultad prepara profesionales?… lógicamente, no, la universidad debe de formar personas, la base de sus doctrinas, que les permitan cumplir la base curricular para acceder a los puestos de trabajo que quieran desempeñar las personas. ¿cómo pueden conseguir estas personas su experiencia entonces?… trabajando.

En este enfoque, tienes que buscar a qué te quieres dedicar y potenciar tu educación en ese sentido. Eso lo primero. No hace falta hacer másters en el extrangero, basta con que quieras aprender y lo hagas con libros, con colegas, a través de una práctica de empresa… lo que sea. Algo que llegado un momento pueda probar tus conocimientos avanzados en una determinada materia.

Recuerda, sobretodo, que en el mundo que vivimos, vale más que hayas realizado algo tangible (escrito un libro, un artículo, dada una conferencia, un taller, un curso…) que tener un título de 80 horas en una doctrina específica. Nuestros contratadores buscan experiencia, que les resuelvas el problema que tienen y, si tienes los conocimientos, les da igual el cómo los hayas conseguido.

Los sabores de Windows

Las liberaciones de Windows, de Microsoft, suelen realizarse siempre por triplicado, es decir, de cada línea interesante que saca la compañía, hay tres versiones, después es abandonada por los motivos que se verán obvios.

La triada de Microsoft consiste en sacar una versión primera, una versión más elaborada gráficamente y mejor recibida por el público en general, y una última versión que termina siendo un fiasco, que dura poco en el tiempo y en la memoria de muchos usuarios, afortunadamente para Microsoft.

La línea light

Cuando los equipos no eran tan potentes como para soportar todas las características que tenía incluídas Windows NT, la empresa tuvo que realizar un sistema operativo mezclado con el sistema DOS que ya tenía, para obtener un sistema mixto llamado, en un principio, Windows 95.

Después llegó la versión bonita, que fue Windows 98, la cual era una versión gráficamente superior de Windows 95 y mejor preparada para Internet.

El punto final a esta línea lo puso Windows ME (Millenium Edition), del cual, pocos se acuerdan, salvo los que lo sufrieron y la mayoría coincide en que tenía multitud de fallos y las mejoras gráficas y de incorporación de elementos multimedia no compensaba esos fallos.

La línea NT para particulares

Cuando la potencia de las máquinas de uso cotidiano alcanzó a poder ejecutar sistemas NT, la compañía recuperó su sistema base, sin recortes, y aprovechó el cambio de siglo para sacar su primera versión, la cual tuvo una expansión hacia los sistemas servidores y un gran lanzamiento en lo que respecta a la empresa (que era la que podía hacer el mayor desembolso). Esta versión fue Windows 2000.

Dos años después, esta versión ya era posible en su incorporación al mercado residencial y se potenció su interfaz gráfica, así como sus elementos multimedia, liberándose como Windows XP. Esta versión supuso un cambio drástico a aquellos que cambiaban directamente desde Windows 98 (un sistema basado en el kernel de DOS) a este (con un kernel NT que no permitía ya la ejecución de aplicaciones de 16 bytes de DOS).

Al igual que en la línea anterior, se intentó potenciar la línea multimedia y de interacción gráfica para el sistema pero, parece que la historia se repitió y la tercera entrega, al igual que Windows ME, fue otro fiasco. Esta liberación tuvo el nombre de Windows Vista.

Re-escritura y nueva vida

Después de topar con la imposibilidad de seguir con la infraestructura NT tal y como estaba, la compañía necesitaba un nuevo lavado de cara y comenzó el desarrollo de Windows 7, el cual ha sido una reescritura completa, desde cero, así como lo fue Windows 95 y Windows 2000. Con lo que conforma el principio de otra línea, en la que la siguiente versión será, o eso se espera, muy buena, llegando una tercer que marcará el final de la línea… con otro fiasco.

Alternativas

Microsoft no es la única compañía que, después de 15 años, ha realizado un sistema basado en el kernel de NT para la ejecución de programas. Estos sistemas, desde simuladores para otros sistemas operativos a sistemas operativos en sí mismos, han hecho que el uso de sistemas tipo Windows no sea monopolio de Microsoft.

Entre otros, los emuladores más conocidos, desde el mundo GNU/Linux, son Wine, Cedega y CrossOver (basados en wine).

Uno de los sistemas operativos, que trabaja junto con wine en el desarrollo y emulación del kernel NT bajo sistemas Unix, es ReactOS. El desarrollo de este sistema es muy activo desde que comenzó y ya tienen un LiveCD en el que se pueden probar aplicaciones para Windows. Una alternativa muy a tener en cuenta, y sobre todo porque es GPL, es decir, software libre.

¿”Ingeniería” del software?

El creador de menéame, Ricardo Gallí, escribió hace unos días un artículo en su blog bastante interesante sobre lo que respecta a la llamada Ingeniería del Software. Ricardo sostiene que el título de “ingeniería” ha sido dado de forma errónea al desarrollo de software y, en muchos aspectos, tiene razón.

Rescato la lista que él mismo recopiló de Tom DeMarco, sobre un artículo de opinión publicado bajo el título Software Engineering: An Idea Whose Time Has Come and Gone? (Ingeniería del Software: ¿Una idea cuyo tiempo pasó?), hablando de su libro:

Controlling Software Projects
T. DeMarco; Prentice Hall PTR 1986

  • Hoy en día todos comprendemos que las métricas de software cuestan dinero y tiempo, y que deben ser usadas con moderación.
  • El desarrollo de software es inherentemente diferente de las ciencias naturales tales como la física, por lo que sus métricas son mucho menos precisas para capturar lo que deben describir.
  • La frase más citada del libro es No puedes controlar lo que no puedes medir. Esta frase contiene una verdad real, pero cada vez me sentía más incómodo con el uso que hice de ella. Está implícita en la frase (y en título del libro) que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.
  • Muchos proyectos se han realizado sin demasiado control pero han generado productos maravillosos tales como Google Earth o la Wikipedia.
  • Esto nos lleva a la desagradable conclusión: el control estricto es algo que importa mucho en proyectos relativamente inútiles y mucho menos en proyectos útiles. Sugiere que mientras más te enfoques en el control aumenta la probabilidad de que estás trabajando en un proyecto que se esfuerza por generar algo de valor relativamente menor.
  • ¿Estoy diciendo que está bien ejecutar proyectos sin control o con un control relativamente menor? Casi. Estoy sugiriendo que deberíamos seleccionar primero los proyectos cuyo control preciso no importe demasiado.
  • Estoy llegando gradualmente a la conclusión: el momento de la ingeniería del software vino y se fue.
  • En los últimos 40 años nos hemos torturado por nuestra ineptitud en acabar proyectos a tiempo y con el presupuesto previsto. Pero como sugerí antes, no debería haber sido el objetivo supremo.
  • El objetivo más importante es la transformación, crear software que cambie el mundo, o que transforme una empresa, o la forma en que se hace negocio.
  • El desarrollo de software es y será siempre algo experimental. Lo construcción real de software no es necesariamente experimental, pero sí lo es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde deberíamos haberlo hecho siempre.

Esto nos indica que el software debe de realizarse con un fin concreto, con una utilidad en mente y, el hecho de prefijar, fijar o realizar unos requisitos sobre él, no son más que el ejercicio de la práctica y las necesidades reales que quieran cubrirse de forma eficiente. Cambiando algo significativamente.

Otro aspecto que se enfatiza es el tema del control. ¿El control excesivo es perjudicial para un proyecto de “ingeniería” del software?

Lo que es casi obvio para la mayoría de profesionales, es que el desarrollo de proyectos en cadena es bueno emplear metodologías tradicionales, puesto que son cosas que se han podido medir durante mucho tiempo, no suelen cambiar mucho y se realizan siempre de la misma forma. E igualmente, el equipo humano, su creatividad y destreza no son tan importantes como el procedimiento marcado para realizar el programa en el tiempo estimado.

Por otro lado, los proyectos a medida, que se realizan con una especificación de requisitos variable y que pueden ir modificándose en el tiempo con la necesidad del cliente, requieren de otro tipo de metodologías que den otro tipo de control a los desarrolladores y mayor libertad a los programadores. En este caso sí es muy importante que los desarrolladores (analistas) sepan cercanamente lo que se hace y cómo se hace, que sepan lo que cuesta realizar el trabajo y, sobre todo, que sean los programadores los que digan lo que van a tardar en cada tarea. Aproximadamente.

Esta última forma es el que más proyectos genera para la industria de creación de software y, dado que la llamada ingeniería es tan liviana en este caso, quizás sí, quizás el nombre no sea todo lo acertado que debiera… quizás necesitemos otro nombre para nombrar lo que hacemos.

El Principio de Peter

Hace tiempo ya escribí algo relacionado con esto, en el artículo despide a tu jefe. Hoy, después de haber leído la definición del principio de Peter en la wikipedia, se le puede dar más forma, precisión y color :-P

El caso es que en la mayoría de empresas, lo normal, es promocionar, es decir que, siendo bueno en lo que se hace, se sube de puesto por méritos y se toma mayor responsabilidad, mayor sueldo… pero también, algo poco evaluado, es que se cambia de trabajo.

El principio de Peter viene a decir que cada persona es ascendida hasta su nivel de incompetencia.

Esto quiere decir que, si somos buenos haciendo lo que hacemos, al ascender, haciendo otra cosa distinta, podemos no ser tan buenos, e incluso podríamos ser un desastre haciendo ese trabajo. Ahí es donde se centra el principio de Peter, ya que, siendo ya no tan buenos en el nuevo trabajo, es más difícil ascender.

Esto no es así en el 100% de los casos. Hay gente que cuando sube de puesto se recicla y comienza a hacerse valer en el nuevo puesto… pero son los menos.

La pregunta que debemos de hacernos cada uno, entonces, es… ¿has llegado a tu nivel de incompetencia o te sigues reciclando?

Debate sobre la Ingeniería Informática

Reconociendo al sector informático como la cuarta parte de los estudiantes de las ingenierías que se estudian en las universidades españolas, la regulación de las titulaciones y el asegurar que dichas titulaciones son de calidad y corresponden a la calidad de nuestros vecinos europeos, se cierne sobre Estado y Universidades el debate de la responsabilidad de que esto sea así.

El Partido Popular, en el debate para votación de la Propuesta de No Ley (PNL) sobre la Ingeniería Informática, presentada por este mismo partido, hacía presentación y propuesta de querer defender las titulaciones informáticas por los motivos:

  • Creación de Fichas de Grado y Máster donde se reflejen las Competencias de los Titulados de Ingenierías Informáticas.
  • Dichas Fichas se crearon en el Libro Blanco, el cual fue anulado y retirado.
  • No se han tenido en cuenta las Ingenierías Técnicas y las Ingenierías de Informática para la asignación de títulos que habilitan para el ejercicio de las diferentes profesiones de Ingenieros Informáticos.

Entre líneas, se puede entrever que el portavoz del Partido Popular, intenta dar voz a los Colegios de Informática para vencer el intrusismo que se origina en nuestro sector.

Por otro lado, el portavoz del PSOE, da los siguientes puntos en contra de la PNL, que son a tener muy en cuenta:

  • En el contexto europeo, las titulaciones informáticas con relación a másteres, grado y doctorado son muy ágiles y no pueden estar sujetos a regulaciones.
  • En este contexto que se tiene, es en el que operan las mejores universidades del mundo y que han demandado decanos españoles.
  • Por ley, las fichas que se demanda hacer no pueden realizarse mediante la PNL, puesto que las titulaciones no están reguladas para funciones laborales concretas.
  • Los estudiantes y titulados no pierden derecho ni valor de sus estudios y títulos, respectivamente.

Escuchando el audio completo, el portavoz del PSOE rebate el argumento de trasfondo de la PNL, que es establecer unos cortes y asignaciones laborales concretas en el campo de las Ingenierías e Ingenierías Técnicas Informáticas y, establece que, el medio expuesto es el equivocado, que se ha recubierto de algo llamativo, que se establezca como un FUD para la comunidad de estudiantes y profesionales para demandar algo que ya tienen otros Ingenieros como los Arquitectos, por ejemplo.

La votación se produjo, quedando 19 votos en contra, 17 a favor y 2 abstenciones. Con lo que, se deja libertad a las Universidades para el establecimiento de grados, másteres y doctorados.

Por otro lado, queda el tema del intrusismo que, si la educación de las universidades preparase para el trabajo real, yo mismo defendería, pero teniendo en cuenta de que se enseña a ingenieros para desarrollar el trabajo de técnicos… y que mucha gente sin titulación resulta, en muchos casos, más profesional y efectiva que gente con titulación, lo que se debería es de defender más que la PNL no haya salido y que las universidades, con la flexibilidad que les ha sido otorgada, se encarguen de hacer competente su plan de estudios para hacer que los universitarios sean trabajadores e ingenieros competentes.

A día de hoy, si se busca a, por ejemplo, un Arquitecto Java, que es una persona que establece el análisis de un productos software, la solución arquitectónica en base a un diseño general y su seccionado para el trabajo de grupos más pequeños… algo básico y rudimentario para un ingeniero, ¿cuántos titulados serían capaces de realizar este trabajo?, ¿cuántos de ellos no se pondrían directamente a desarrollar todo lo que pide el cliente directamente en Visual Basic?

Quizás, lo que debería de haber es más control de calidad en los estudios y enseñanzas de las universidades a través de exámenes y certificaciones a sus alumnos, para asegurar que salen ingenieros e ingenieros técnicos competentes.

Documentación de Proyectos Libres

Se ha hablado mucho sobre la escasez de documentación en proyectos libres, tanto de manuales técnicos o de administración, que expliquen como instalar y administrar el software, como manuales de usuario, que expliquen cómo realizar las actividades que propone el software realizar.

Es claro que, cuando una persona aprende a desarrollar, a programar, se sienta frente al ordenador y comienza esa frenética batida de golpes contra el teclado, una pausa para ver los resultados, un momento de pensar en el siguiente paso, y otra vez a teclear… en esos momentos, la documentación, si se piensa hacer, es algo que se estima para un futuro… para cuando se dé a conocer.

Es lógico que un proyecto grande, creado con una línea en mente, a veces por una empresa o una entidad como puede ser una fundación o una universidad, suele ser otra cosa (casos como MySQL, PHP, PostgreSQL, Firefox, OpenOffice, Apache, …).

La documentación es como la lluvia, nunca cae a gusto de todos, por lo que es muy complicado realizar un documento sobre un programa que cumpla con las expectativas de todos los posibles usuarios que vaya a tener el programa.

Los tipos de documentación que se han identificado a lo largo de los años pueden englobarse dentro de los siguientes grupos:

  • Receta (o How-To): es un documento para gente que quiere hacer algo funcionar de forma rápida y no se quiere parar en detalles. Suelen ser documentos cortos, concisos y estructurados en pasos.
  • Getting Started: algo así como los primeros pasos. Es para gente que quiere ver algo funcionar de forma rápida, para después centrarse en los detalles. Es básicamente en lo que se fundamenta Linux, Unix y demás sistemas parecidos… la filosofía Unix.
  • Manual: suele ser un libro extenso donde se explican, por capítulos, cada parte específica del programa. Este tipo de documento suele venir bien para quien tiene interés en aprender a usar bien el programa y, depende del enfoque, el modo en que se use: usuario, administrador, instalación…
  • Tutorial: parecido al anterior, pero más pedagógico, intenta adentrar de una forma más suave al usuario a lo que es el uso del programa.
  • White Paper: algo así como la filosofía en la que se basa el programa. Explica la ideología, en lo que se basa, pero no cómo se usa. Muy útil para quien tiene interés en saber el trasfondo de la creación del programa.
  • Guía de Referencia: suelen ser los comandos o atajos que se pueden usar en cada parte del programa, ya sean comandos, teclas rápidas, combinaciones, menús de acceso… depende de cómo se presente el programa.

Hay proyectos, comerciales y libres, que reúnen toda esta variedad de documentos, lo cual es muy útil y, aún así, sigue habiendo problemas entre los usuarios, puesto que la calidad u orientación de los mismos, puede no ser muy precisa o atinada. En este aspecto, los manuales, en su mayoría, suelen tener un baremo en el que presentan el público a quien va dirigido el documento y lo que trata en sí, encontrándose así libros para gente nueva en el tema, de nivel bajo, intermedio o avanzado.

En proyectos de gran tamaño, como puede ser Apache, la documentación que se reúne, puede sobrepasar, perfectamente, las mil páginas. Más en concreto, el manual de usuario con guía de referencia de PHP (de su página web) tiene un tamaño de aproximadamente 2000 páginas.

Por lo tanto, no es que los programadores o desarrolladores no hagan documentación… es que escribir documentación es una tarea ardua, larga y conlleva más tiempo que en escribir el código del programa que se documenta para, después, encima, ver que la documentación escrita no es suficiente, o no se entiende bien… ya que, además, si la escribo en castellano, no es lo mismo que si la escribo en inglés, por supuesto.

Desmitificando: software y su mantenimiento

Desde siempre, cuando una empresa apuesta por software privativo frente a software libre o de fuente abierta, lo hace por tener cubiertas las espaldas, por tener garantías y saber que hay una empresa que responde por ese software, tanto en mantenimiento, como en incidencias graves, que pueden llegar a pagar indemnizaciones.

Este es el principal motivo de que se abogue por software propietario, simple y llanamente. Cualquier otro motivo es un mito, como cualquiera de los siguientes:

  • Una empresa te dará más y mejor soporte: normalmente suele… o solía ser así. Las empresas de software contratan programadores, analistas y una serie de personal que son capaces de desarrollar un software más o menos eficiente y después mantenerlo… pero, existen muchos casos en los que este soporte y mantenimiento, no se ha pensado, no se da o es ineficiente. Por:
    • El software se ha desarrollado contra-reloj, sin fuerte planteamiento flexible a cambios y falto de documentación sobre la filosofía que sustenta que todo esté “ensamblado” de la forma en la que lo está.
    • La programación ha sido realizada “sobre la marcha” haciendo el software inconsistente, con gran cantidad de fallos y las soluciones no terminan de llegar. Con cada incidencia reportada aparecen nuevas.
    • El equipo de desarrollo cambia íntegramente o parcialmente, haciendo que el nuevo equipo programe el hard-coding de una forma distinta al anterior grupo, con lo que el software va mutando y distnaciándose del planteamiento original, que fue informado únicamente al primer grupo.
    • Una empresa tiene los recursos humanos limitados y, en caso de tener mucho trabajo, puede que incluso esos recursos humanos ya no respondan de la misma forma que al principio.
  • Una empresa te garantiza el software: hay cláusulas que limitan ese tipo de garantía y, en muchos casos, incluso las incumplen con lo que tienen que tirar de un seguro que les pague la indemnización. Tener una garantía no te asegura que funcione y, sobre todo, si quien te da la garantía tiene una veracidad y credibilidad dudosa.
  • El software propietario está mejor hecho: no se sabe, puesto que no se puede ver. Lo que sí se sabe es que no debe de estar tan bien hecho cuando necesita ser reescrito entre versiones, muchas veces. De igual forma, sería mejor no fiarse de una empresa que no tenga departamento de calidad, que certifique que el proceso de desarrollo ha sido llevado usando un cierto proceso lógico y se han llegado a cumplir una serie de espectativas de forma satisfactoria.
  • Es mejor tener el producto que no un servicio: ciertamente, y por eso se debería de preferir tener un software con una licencia que te permite ciertas libertades sobre él, y no un producto del que solo se ha comprado una licencia que te permite usarlo con muchas limitaciones. Muchas veces incluso limitaciones en el tiempo. Adquirir una licencia es como adquirir el servicio de uso sobre un producto, a modo de alquiler, pero sin la ventaja de poder reemplazarlo sin coste adicional en caso de deterioro, el servicio de mantenimiento se suele contratar aparte.
  • Software a medida es caro, difícil de hacer y no suele cubrir las espectativas: si se piensa esto es que no se ha pedido su desarrollo a una empresa seria. El desarrollo de software es un proceso que se debe de seguir, desde una especificación hasta obtener el producto que el cliente quiere usar. Cuando se desarrolla sin seguir un protocolo, con limitaciones o simplemente saltándose pasos… esto deriva en un software “mal acabado”, que no cumple con los requisitos iniciales y que deja la sensación de que, cualquier “chapuza” sobre un software ya hecho (como Office o similar) hubiese sido mejor.

Bueno, la verdad es que podría extenderme mucho más, porque las chapuzas en el campo de la informática están a la orden del día, pero con tener presentes estos puntos, creo que es suficiente para tener una visión un poco más amplia de lo que hay y lo que realmente se debería de buscar en cada caso.

Recordar también que, el software libre es una gran librería de programas que sirven para probar, seleccionar algo que guste usar y solicitar modificaciones y/o ampliaciones sobre ese software en caso de necesitarlas.

¿Está mi empresa organizada?

Cuando una empresa se forma, se intenta organizar el trabajo entre las pocas personas que la inician y si su estructura es buena y sus productos/servicios asequibles para el mercado, la empresa crece y con ella su personal. Es el inicio de los problemas.

Cuando una empresa crece, se contrata a más gente y estas personas comienzan a ocupar cargos que antes desempeñaba una persona en un porcentaje pequeño de su actividad laboral. El ritmo vertiginoso hace que las reuniones con esta nueva persona, para explicarle su cometido sean breves y escasas, así que terminan por hacer el trabajo a su manera.

Después de pasar por varias personas, varias formas de hacer las cosas y distintas formas de organizar las cosas, cuando un grupo de personas deja la empresa y retoman otro grupo, suele ser un caos y, el reactivar el proceso de producción en esa parte, muy lento y costoso.

El problema se debe a la falta de método y documentación.

Cuando una persona entra a trabajar en una empresa madura, suele entrar en un engranaje del que tiene que formar parte. Sus conocimientos básicos son los que se le solicitaban al entrar al puesto de trabajo, como pueden ser saber programar, una cierta metodología, idioma o titulación. Pero a partir de ahí, la formación debe de ponerla la empresa y, es en este punto, donde la mayoría de empresas, no tienen forma de explicarles a sus nuevos empleados lo que hay, lo que tienen que hacer o cómo hacer su trabajo.

El funcionamiento de una empresa, sus procesos y su burocracia, debería de estar recogida y revisada en un documento de Modelo de Negocio. En este documento se especifica cómo funciona cada departamento, los cometidos de cada uno de los subdepartamentos y las políticas de trabajo, comunicación y otros aspectos o típicos como seguridad laboral.

Así mismo, cada departamento y/o subdepartamento, debe tener claro su cometido y esclarecer una forma en la que realizar su trabajo, tener sus tareas bien definidas y documentadas para, en caso de enfermedad, vacaciones, cese o fallecimiento, el trabajo pueda ser cubierto por cualquier otra persona.

Estos tipos de documentos no son solo una gran utilidad para el propio empleado, sino también para las consultoras y asesorías externas, puesto que pueden optimizar dichos procesos, e incluso diseñar software que ayude y dé soporte a estos procesos.

¿Sería capaz de diseñar un modelo que optimice el rendimiento de su empresa?, un modelo de negocio podría desvelarle qué puntos podrían optimizarse y mejorarse, así como qué recursos tiene más explotados y cuáles están más libres.

Filosofía Unix

Desde que comencé en GNU/Linux, sobre el 2002, siempre se ha resaltado la filosofía con la que se fundamentó el sistema al que “copia”, que es Unix.

La filosofía Unix se basa en algunos apartados básicos que todo buen informático debería de emplear en sus desarrollos, ya sea a nivel de sistemas o gestión. El uso de estas directivas, asegura que el trabajo, cuanto más pase el tiempo, más llevadero será.

Las directivas son, básicamente:

  • Escribe programas que hagan una sola cosa y la hagan bien: esto quiere decir que los programas deben de ser lo más atómicos posible y que se compruebe mucho su rendimiento y funcionamiento para hacerlo lo mejor posible.
  • Escribe programas que trabajen juntos: de nada sirve escribir programas que sirvan para una tarea específica y que, después, cuando esa tarea se modifique de cierta forma, haya que reescribir todo el programa. Es mejor dividir el problema en varios programas y después desechar o reescribir solo uno de esos pequeños programas, cuando se necesite, o incluso hacer nuevos.
  • Escribe programas que manejen flujos de texto, pues esa es la interfaz universal: todo lo que se hace con entrada y salida en formato textual es más fácil de enlazar con otros programas, así como reutilizarla en el pasado, presente y futuro.

En estos conceptos se basa la mayoría de software libre que existe, por lo que servidores como sendmail o postfix, se basan en pequeños servidores y/o programas que hacen partes de todo un proceso y, mediante sus ficheros de configuración, se pueden enlazar de una u otra forma, así como usar otros programas y/o servidores en lugar de los que vienen por defecto y, así, extender su funcionalidad.

Sobre filosofía Unix, de una forma más extensa, Mike Gancarz, escribe las siguientes líneas:

  • Lo pequeño es hermoso.
  • Haz que cada programa haga una sola cosa, pero que la haga bien.
  • Construye un prototipo lo antes posible.
  • Elige portabilidad sobre eficiencia.
  • Guarda los datos en archivos de texto plano.
  • Aprovecha funcionalidades del software.
  • Usa scripts de shell para aumentar la funcionalidad y portabilidad.
  • Evita interfaces de usuario captivas.
  • Haz de cada programa un filtro.

Esto no quiere decir que lo realizado sobre interfaces gráficas sea malo, o no respete estas premisas, puesto que muchas de estas interfaces hacen uso de programas que sí respetan al máximo estas premisas y que, favoreciendo la penúltima directiva escrita por Mike, permiten ver los comandos que ejecutan, junto con todos los argumentos.

Concluyendo, pensemos que el trabajo que se realiza día a día, no solo ese software que programamos por amor al arte, debe de sernos de utilidad, no solo en el momento en que nos lo piden para solucionar un problema dado, sino como “caja de herramientas” para la solución de miles de problemas que se deban de resolver en un futuro, quizás no muy lejano :-)

Vía: La filosofía UNIX

HP quiere su propio S.O.

se ve que tanto tiempo vendiendo licencias de Microsoft en sus equipos, le ha hecho a este gigante de la venta de hardware, replantearse si vender sus equipos con Windows, y sobre todo con Vista, es buena idea.

La idea que tienen es desarrollar algo simple para el usuario, basado en GNU/Linux, por lo que supongo que será algo así como Ubuntu, solo que mucho mejor soporte de hardware para los equipos HP con los que se venda.

Nada dura eternamente y, se ve que, la hegemonía en ventas del sistema operativo más criticado, tanto positivamente como negativamente, del mercado, llega a su fin. Ya veremos si consiguen o no levantar el vuelo con Windows Seven, o se convierte en otro fiasco.

Vía: TechTear y en inglés BusinessWeek.