junio 28, 2005

Organización empresarial en empresas basadas en Software Libre

Siguiendo con el tema anterior, voy a transcribir otro fragmento de mi tesis del MBA. otra vez. Hablo de la organización empresarial en organizaciones que quieran basar su actividad en software de código libre.
 
No olvidemos de todas maneras que una estrategia alrededor del software libre siempre debe estar muy centrada en lograr la máxima calidad del producto, o de lo contrario la comunidad dejaría de confiar en una empresa que puede anteponer sus intereses a los del producto de software libre. Por tanto, asegurando la calidad del producto y la transparencia de la empresa en conseguirla, se alcanzará una de las estrategias claves: conseguir la confianza de la comunidad de software libre. Todos los trabajadores deben centrarse en ello, y debe garantizarse mediante la organización empresarial adecuada.

Tradicionalmente el software se ha desarrollado bajo una jerarquía bastante estricta, dónde las personas implicadas podían jugar estos roles:

Jefe de proyecto: Quien gestiona el equipo y se asegura de su buena marcha.

Analistas: Que obtienen los requerimientos del cliente y realizan el diseño del software a implementar. A veces se dividen en analistas senior y junior, y se dividen la responsabilidad de tratar con el cliente o la iniciativa de tomar decisiones estructurales del software.

Programadores: Como último escalafón seguirían los diseños de los analistas creando el código fuente. También se suelen distinguir entre senior y junior, principalmente por su experiencia.

Ahora estamos hablando de que hay que proporcionar mayor confianza a los trabajadores, de que son estos quienes deben relacionarse con el mundo exterior. En este caso, los verdaderos conocedores del código fuente son los programadores. Cada vez más se escucha que se debe dar mayor importancia a los programadores, valorarlos más. Podemos asegurar que la clave de una empresa son sus personas. Las técnicas de organización, de calidad, de producción,... cada vez se orientan más hacia el valor de la persona. Por supuesto, los procesos son también importantes, pero "la clave del éxito son las personas". La organización empresarial de una empresa de software, ya sea comercial o basada en software libre, no debe olvidarlas.

Los roles tradicionales limitan la capacidad de las personas. Nadie quiere ser programador como rol tradicional, porque se limita a realizar un trabajo a veces carente de iniciativa en los proyectos más burocratizados. Además, es un trabajo menos valorado. Una organización que motive a las personas intentará que cada uno rinda al máximo de sus posibilidades, centrándose en los equipos como medio fundamental para la creación de software. En la creación de software esto es todavía más importante, puesto que ya hemos hablado que no se pueden establecer procesos idénticos, porque no existen los mismos problemas. Cada producto de software es único, aunque tengan las mismas funcionalidades.

Ya existen formas organizacionales de los equipos de desarrollo de software diseñadas para eliminar las barreras jerárquicas, para mejorar la comunicación y disminuir la burocracia. Un ejemplo de esto es la metodología de gestión de proyectos de software conocida como "eXtreme Programming ." o XP. Por supuesto, esto puede ser aplicable a empresas productoras de código abierto y las que no lo son.

junio 24, 2005

Habilidades del buen programador

Para ser un buen programador (Robert L. Read), y no quedarse en el programador "mediocre", no solo se necesitan habilidades técnicas, si no que además se necesitan habilidades sociales y personales.
Hacía mucho tiempo que había leido este documento y ahora me ha venido de nuevo a la cabeza tras la historia de las multinacionales.
El caso es que llega un punto en el que se necesita algo más que conocimientos técnicos para ser valorado, y para ser un buen profesional. Puedes quedarte con los mismos conocimientos y mejorar técnicamente, pero después se necesita trabajar en equipo, capacidad de negociación, de asimilación de ideas,... muchas habilidades que desde luego no enseñan en la facultad de informática.
En general, me imagino que no las enseñan en ninguna carrera técnica, pero creo que otro tipo de ingenieros salen con una mentalidad mucho más abierta de la carrera en cuanto a las capacidades laborales que se les van a requerir. Supongo que las pantallas de los ordenadores nos absorben mucho durante la carrera, pero se debe evolucionar para trabajar en el mundo empresarial. O puedes quedarte siempre siendo el gurú ese que está en una esquina y lo sabe "todo sobre casi todo".(que también puede ser una area interesante...)
Os recomiendo el artículo anteriormente comentado. Muy al estilo Spolsky.

DWR: AJAX sencillo, pero ¿útil?

Siguiendo con la fiebre de AJAX, se ha publicado (leido en TheServerSide) la versión "Release Candidate 1" de DRW. El primer vistazo que le he dado ha sido bastante positivo. Parece que simplifica el uso del XMLHttpRequest mediante la casi transparente llamada desde JavaScript directamente a las funciones JAVA. Aparentemente, por supuesto, por que hay que incluir un servlet en tu aplicación, y un JavaScript en tus páginas HTML.

Entiendo que para aplicaciones complejas esto puede tener utilidad, puesto que te abstraes del canal de comunicación por HTTP, y de sus invocaciones. Pero, ¿hasta qué punto se quieren hacer efectos complejos, si seguimos teniendo el problema de la latencia entre la petición y la respuesta por HTTP? Para que AJAX sea útil en una interfaz, debe proporcionar una velocidad que sea prácticamente transparente para el suario, y para ello, no sé hasta que punto nos podríamos poner a realizar tareas complicadas en el servidor.

De todas maneras, la herramienta DRW, será muy útil, para ver AJAX en el desarrollo sin complicaciones.

junio 23, 2005

Multinacionales, desarrolladores... y costes.

¿qué valor tiene un buen desarrollador(programador) o un buen equipo de desarrollo en una multinacional? Obviamente la pregunta podía extenderse a la generalización de todos los empleados, pero como ahora hablamos de lo que hablamos, me pregunto si debería haber diferencias.
A nivel directivo, en una multinacional, los números es lo que cuenta. Los directivos pueden preocuparse más o menos de sus empleados, y de construirles el mejor sitio para trabajar, pero el ROI manda. La teoría de los masters se suele quedar en palabras bonitas sobre cómo tratar a los empleados (y alguna reunión para calmar los ánimos de vez en cuando). A esto se suma el poco entendimiento de la producción tecnológica de software, como un proceso totalmente diferente de la producción de bienes materiales, y a medio camino muchas veces de la prestación de servicios.
Además, se suele hablar de la diferencia que existe entre los programadores "buenos" o "malos". Extensivo sin ninguna duda a los equipos, donde las sinergias entre los miembros pueden multiplicar los factores humanos que inciden en la buena marcha de un proyecto.
¿Existe tanta diferencia entre equipos o personas de otros sectores, como entre los "buenos y malos" programadores? ¿las multinacionales hacen algo por reconocerlos?
Este Post no intenta llegar a ningún objetivo :) , solo reflexionar.
 

junio 21, 2005

Gestión de la innovación: Soft.Libre vs privativo

Extraido del trabajo de Nuevos Modelos de Negocio...

En el mercado del software la innovación tiene una importancia vital. Es muy importante que la empresa este basada en una cultura con sólidos cimientos en la innovación. Es realmente sorprendente cómo el software libre puede ser respaldado por los factores básicos de la cultura occidental descritos por Samuel P. Huntington:

  • Igualdad de las personas en cuanto a su dignidad: El software libre iguala tanto al productor como al consumidor en la utilización del software.
  • Libertad: Es la base del movimiento, donde se dispone de toda la libertad para cualquier uso, copia o modificación del software.
  • Participación: El software libre realmente permite participar en el desarrollo a cualquier persona.
  • Solidaridad: El software libre además es gratuito, y facilita la utilización de cualquiera que lo necesite.
  • Subsidiaridad: El productor del software no puede tomar ninguna decisión que podría perjudicar a los usuarios, puesto que el software en realidad no le pertenece.
Los principios de creatividad, conocimientos, eficiencia y valores humanos descansan sobre estas bases culturales. Estos principios, que deben estar presentes en todas la empresas, parece que se ven más respaldados todavía en este modelo nuevo de negocio, al cumplimentar los factores básicos de la cultura occidental no solo desde el punto de vista de la empresa, si no además del usuario.

Es decir, estos factores en los que se basan los planteamientos estratégicos de creatividad, conocimientos, eficiencia y valores humanos no son solo valorados desde el punto de vista de la empresa. Ahora se da la vuelta a la relación empresa-cliente, y se observan desde el punto de vista del usuario de software. Esto es lo que Richard Stallman planteaba: la libertad de los usuarios que además debe acarrear incluso mejoras sociales.

¿Significa que las empresas comerciales intentan omitir factores elementales de la cultura en su relación con el cliente? Sinceramente no lo creo. Simplemente el punto de vista es distinto. No creo que una relación comercial entre un productor de software y un usuario, la venta de un código binario mediante unas licencias, suponga ninguna trasgresión de los derechos de ninguna de las partes. Pero el nuevo modelo de negocio implica simplemente la visión desde el otro lado, desde el lado del usuario. Y ello ha llevado a cambios muy importantes en el sector industrial.
El modelo de negocio basado en software libre facilita sobremanera la capacidad de innovación mediante la copia. De hecho, la empresa que adquiere la innovación mediante la utilización de software libre, ni siquiera debe hacer esfuerzo en realizar la copia, no supone un trabajo de análisis de producción para alcanzar la producción igual que la original. Simplemente es software el libre, y por lo tanto también lo es la innovación que represente.

La innovación de ruptura puede venir de distintos departamentos que los encargados del desarrollo. En este punto, la empresa comercial puede tener ventajas sobre una comunidad de usuarios no organizada. Los distintos departamentos de la empresa colaborarán en buscar mejoras de ruptura, que no tienen por qué venir únicamente desde el perfil técnico. Marketing o el departamento financiero, por ejemplo, pueden (y deberían) colaborar en distintas ideas que puedan significar desde su punto de vista una innovación.

En las comunidades de usuarios muy distribuidas, generalmente las innovaciones provienen del esfuerzo de una sola persona. Estas innovaciones pueden ser brillantes, pero por lo general tendrán ventaja los equipos bien organizados de las empresas. Por esto, las empresas basadas en software libre deberían realizar un esfuerzo para encaminar a la comunidad a una organización dónde se fomente la innovación, o realizarla internamente con conexiones al exterior.

En el software de código abierto la innovación incremental es la más aplicada. Los desarrolladores van mejorando un producto, añadiendo cada uno su porción de innovación, pero es más difícil que se planteen un cambio radical al producto.

En las comunidades de software libre la innovación descansa únicamente en los desarrolladores de forma individual, pero las empresas pueden innovar compartiendo visiones distintas: desde el área comercial, desde la alta dirección o desde el área financiera. Estas areas pueden aportar, y de hecho es necesario que lo hagan, un fuerte empuje para facilitar la innovación empresarial.(Aunque cada vez más los proyectos de software libre son liderados por empresas, lo que paliaría esta situación)

Se suceden mayor número de iteraciones para obtener un producto terminado, debido a la externalización de los recursos. Puede tener un coste que hay que gestionar (repositorios, listas de correo,... en definitiva, es muy importante el sistema de información empresarial)

Las redes son la mejor explicación del funcionamiento de las comunidades de software libre. Los intercambios entre las personas y organizaciones involucradas en un desarrollo de software código abierto no sigue ninguna jerarquía, puesto que no existe una súper-organización, al menos explícitamente, que englobe a todas las partes.

La importancia de las 3 Cs: Crear, Colaborar y Compartir, en la innovación es importante. Esto se realiza ya incluso con proveedores, clientes e incluso competencia. Se puede ver a distintas empresas sin acuerdos escritos entre ellos colaborando entre sí. La licencias GPL en alguna manera les obligaría a ello, puesto que deben publicar sus cambios y mejoras. De esta manera, la misma naturaleza de la licencia en cierta manera fomenta la innovación basada en el trabajo de un grupo. Por lo menos de manera más clara se fomenta la creación y el compartir, por que quizá sea en la colaboración como manera de innovar donde se encuentren mayores problemas. Todos colaboran creando el mismo producto, pero es más que posible que cada trabajo vaya en su dirección, la que le interese al programador voluntario, o a la empresa que lo desarrolla.

junio 14, 2005

Método científico de desarrollo

¿Es distinto el método de desarrollo en los sistemas de software libre que en los propietarios?  Ted Schadler  indica que en el software libre el modelo de desarrollo se aproxima más al método científico de investigación, dónde se dan estas características:
  • Revisión por pares 
         La meritocracia de desarrolladores da a los mejores programadores las posiciones líderes.
     Solo las mejores ideas y código se lanzan en las versiones finales. Un “líder”(generalmente el fundador) hace de “dictador benevolente”.
  • Resultados publicados 
        Como el código es público, los fallos son corregidos rápidamente. Muchos equipos pueden trabajar en módulos diferentes simultáneamente. Las mejoras se soportan totalmente por el código existente.
  • Programadores voluntarios
       
    Internet mantiene la comunidad unida-virtualmente ilimitada. Los programadores están altamente motivados por que escogen su propio trabajo.
  • Versiones lanzadas por ingenieros 
        Se lanzan las versiones cuando los ingenieros piensan que el sistema está listo para producción, no cuando conviene al depto. de ventas.
    Se hace un paralelismo con la comunidad científica, sonde los artículos son publicados, para ser revisados por un numeroso grupo de colegas. Pero en realidad, ¿hasta que punto todo lo mencionado son ventajas que se den realmente? Todo depende en realidad del número de desarrolladores implicados.
    ¿Cuantas veces un código de alguien es revisado "a conciencia"? Más bien, únicamente si se descubre un bug. Y el que otros lo solucionen ¿puede dar lugar a efectos colaterales por no conocer perfectamente el sistema?
    El código público, ¿cuanta gente lo observa mínimamente, o pasa directamente a usarlo? La motivación de los desarrolladores puede ser muy alta en el software libre, pero no tiene por qué serlo menos en una empresa bien coordinada y que valore a sus trabajadores (que no sé si existen! :) ). Además, en muchos proyectos de sw. libre los desarrolladores están en lugares distintos, y en cuestiones organizativas, nadie dudará que una reunión cara a cara es mil veces más efectiva que cualquier otro sistema.
    En definitiva, realmente el modelo de desarrollo del sw. libre o propietario puede ser distinto en alguna manera no radical. Pero no creo que ninguno de los dos sea mejor que otro.

junio 09, 2005

La fiebre de UML

¿conoces a alguien con la  fiebre de UML?
Los procesos de desarrollo de software están llenos de herramientas que podemos usar: tarjetas CRC, diagramas de todo tipo, generadores de código automáticos, documentación...
El problema surge cuando nos centramos más en las herramientas que en el software que debemos construir. Se ve en bastantes proyectos, dónde se manejan ingentes cantidades de documentación, agendas, diagramas; pero no se vislumbra cómo va el desarrollo del software, que es el objetivo final. De repente, nadie sabe exactamente en que estado está el producto. Unos días te hacen una demo de una parte, y días despues de otro módulo, pero entonces te dicen que el del otro día ya no funciona, que hay que revisarlo. Eso sí, los diagramas UML te los enseñan, para descibirte las características internas del sistema.
El artículo "Death by UML Fever" describe con un poco de sarcasmo, los casos clínicos del abuso del UML, sin duda la herramienta más extendida hoy por hoy para el diseño y ayuda del proceso de construcción del software. La falta de experiencia práctica parece ser una de las principales razones para que los ingenieros de software se dejen llevar por las "fiebres" que provocan el uso indiscriminado de UML. Parece más facil e igual de útil pintar diagramas que ponerse "manos a la obra".
Y tú, ¿conoces a alguien afectado por las fiebres del UML?

junio 07, 2005

Newsletters de JAVA

Existen numerosas suscripciones a listas de correo sobre temas de JAVA. Una de las que sigo con más interés es la de Maximun Solution.

En su apartado de Newsletter podeis encontrar todos los artículos enviados desde el inicio de la lista. En general tratan temas para especialistas en JAVA, que requieren un conocimiento avanzado del lenguaje y la plataforma. Si crees conocer JAVA a fondo, planteate echar un vistazo a los temas que tratan. Seguro que algo aprendes. yo por lo menos, lo he hecho, y muchas veces.

Y otro sitio clásico e imprescindible: La guía de "performance" de Jack Shirazi, dónde encontrar los mejores recursos para solucionar los problemas de eficiencia de una aplicación JAVA.

junio 03, 2005

AJAX y Struts

Parece que ahora se ha puesto de moda de repente lo que se conoce por AJAX. Es decir, que desde JavaScript se puedan envíar peticiones HTTP al servidor y obtener la respuesta para ser tratada y mostrada desde el mismo JavaScript sin tener que recargar la página completa.
Desde que Google lanzó su Gmail parece que el mundo ha caido en la cuenta de lo valioso que puede ser este mecanismo de traer datos sin recargar la página, de manera oculta para el usuaario, para mejorar la "experiencia del usuario".
Casi siempre he utilizado Struts en los desarrollos J2EE, y obviamente ya hay múltiples páginas mencionando la integración de AJAX con Struts. Aunque realmente son tecnologías que poco tienen que ver por su lugar en la arquitectura, tratan de estandarizar un poco el proceso de uso.
En definitiva, se trata de crear acciones que devuelvan un formato definido para mostrar en una capa concreta del HTML, posiblemente a respuesta de una acción o evento capturado desde la interfaz mediante JavaScript. El código JavaScript lee la respuesta y la muestra adecuadamente.
En fin, un pijadilla más para mejorar las interfaces en los navegadores.

junio 02, 2005

Java Internal Use License (JIUL)

Sun ha optado por abrir un poco más su mundo JAVA. Ante las peticiones del mundo del software libre, este paso es del todo insuficiente, de hecho la licencia nueva con la que saca el JDK 5.0, no significa que el compilador de SUN sea software libre.
La licencia no permite distribuir una versión modificada del compilador, para eso existen otro tipo de acuerdos comerciales, si no que permite ver el código y que si lo necesitas lo puedas modificar. Luego tienes la opción de reportar esos cambios a SUN que pueden evaluarlos para su siguiente versión del JDK.
SUN sigue apostando por controlar muy de cerca el desarrollo de su plataforma JAVA, y lo más importante, su especificación. Personalmente, creo que los JCP para definición de requerimientos son una buena idea para el funcionamiento de JAVA. No pierdes el control, pero tampoco dejas de lado a la comunidad. Para el mundo empresarial, y eso ha facilitado el crecimiento de JAVA, el control por parte de SUN es muy importante, para evitar miles de distribuciones distintas.

junio 01, 2005

Centrarse en la metodología o en las personas

Desde javaHispano , he llegado por uno de sus comentarios a un artículo de Alistair Cockburn que merece la pena realmente leer. Es posible que sea un artículo muy conocido, pero hasta ahora no había llegado a mis manos. Destaca la importancia de las personas como componente de primer orden para el éxito de los proyectos (de ingeniería) informáticos.
La metodología XP tiene una de sus bazas fuertes en aumentar la importancia de los programadores sobre la metodología, y es uno de sus puntos fuertes. Obviamente, ya hablamos de que XP no vale para todo tipo de proyectos. Pero para mi la conclusión que me ha confirmado este artículo es que es más importante el equipo de personas con el que trabajes, que la metodología utilizada.

Por otro lado, el artículo de javaHispano de crítica al XP tiene algunos puntos buenos, pero en general, da la impresión de que el autor "odia" las metodologías ágiles, y que eso le ha llevado a escribir muchas cuestiones sin sustentarlas en razonamientos lógicos o recapacitados.