La anterior fue una semana movida en Libres y aunque nos divertimos mucho en lo que estuvimos haciendo, no hubo mucho tiempo para escribir, así que lo hago ahora.
Se buildearon varios servers de prueba para los diferentes productos, estuvimos trabajando junto con los early adopters para poner en producción los prototipos avanzados, varias arquitecturas en las que estábamos trabajando tuvieron una mejora drástica o directamente ya están en su versión final.
También estuvimos con los early-adopters estudiando casos de uso, o mejor explicado, casos de "no uso", contextos donde los productos de Libres Consultores no serían aplicables inmediatamente. Nos contactamos ya con una comunidad importante de usuarios, especialistas en uno de los componentes más importantes de uno de los productos en desarrollo de Libres.
Otras cosas que estuvimos viendo fue cómo se ajustarían los productos de LC a los que ya existen en el mercado, ya que son complementarios de ellos.
Así que hoy tenemos 7x1, siete artículos en uno, así ya vamos introduciendo el importantísimo concepto de bundles al blog de Libres Consultores.
- Servers de Testing
- Arquitecturas
- Gestión de proyectos flexible
- Early Adopters
- Componente actualizado
- Colaborando con la comunidad
- Innovación incremental y productos complementarios
Servers de Testing
Un alto grado de automatización va a estar ubicado en los productos de LC en sí, pero por el momento en la infraestructura de building y testing, hay que trabajar con servidores completos, a la vieja escuela, levantar los Linux, cargarlos con el software necesario y montar sobre ellos los productos.
En la teoría parece fácil "levantar servers de prueba", pero cuando se trabaja en equipo, los servers de prueba no pueden ser gestionados localmente, por ejemplo, usando máquinas virtuales locales (Vagrant, VirtualBox, KVM, etc.), más que para probar muy limitados aspectos de los productos, a lo sumo características en la que el miembro del equipo esté trabajando personalmente.
En los servers de testing principales es adonde va a parar el "código" final, todo lo necesario para ir perfilando los productos de cara al prototipo funcional avanzado.
En este contexto se vuelve muy fácil, pero muy fácil, entender la obsesión por las infraestructuras de nube (Openstack), y el software de configuration management (Chef, Puppet, SaltStack, Ansible, Rundeck, etc.), de los ingenieros de infraestructura de grandes empresas que deployan constantemente nuevo código (Continuous Delivery & Improvement): así es cómo se permiten poder crear y destruir rápidamente decenas de servidores de testing y producción nuevos diaria, semanal, mensualmente, dedicando un número de horas que quede en un total siempre de 2 cifras.
Arquitecturas
En varias ocasiones, en intercambios en Internet, me ví explicando qué era, para qué servía una arquitectura en infraestructura, que la idea es similar, pero diferente de lo que es arquitectura de software en el marco de la ingeniería de software. Por supuesto que las nociones de arquitectura de software se aplican totalmente en arquitectura de infraestructuras, simplemente se prescinde o se adapta algunas nociones que están muy especializadas en la gestión de lenguajes, código fuente y desarrollo en gral.
Las arquitecturas que estuvimos definiendo son aquellas básicas para la implementación de determinados componentes, en la práctica, esos componentes son productos internos en Libres, y cada uno sigue el mismo ciclo de desarrollo y definición que los productos públicos, simplemente que no se van a vender directamente, sino que los vamos a usar internamente en Libres (para integrarlos en los productos y/o en los procesos de la empresa).
Una forma muy básica de definir la arquitectura es ver qué se necesita hacer, ver los requerimientos, márgenes de tolerancia deseables, etc.etc. Luego se define qué componentes de software se va a usar para gestionar esos requerimientos (y si hace falta desarrollarlos o no, por ejemplo), y luego vemos qué capacidades puntuales del software elegido son las que se va a implementar en la arquitectura; si se determina que las capacidades no cubren los requerimientos, se vuelve - con ese feedback - a las etapas anteriores, inclusive llegando a revisar la definición de requerimientos. Recordemos aquí que Waterfall es tabú en Libres Consultores y no hay etapas de nada que no sean revisables, reajustables, especial y específicamente si se cuenta con feedback (nueva información), que permita - si es que no exige - re-optimizar (*dentro de parámetros - económicos, de tiempo, de recursos en gral. - razonables), el trabajo ya hecho.
* Determinar qué son parámetros razonables está totalmente alineado con el skillset que brinda la experiencia y la capacitación "dura" en IT. Muchas veces se llega a la conclusión - con la experiencia dada - que el camino más corto entre A y B, para la gestión de proyectos de infraestructura, no es ni por lejos una "línea recta".
Gestión de proyectos flexible
Lo anterior es un clara alusión a la futilidad patente para la gestión de proyectos de tecnología de la información (IT), de muchas metodologías de gestión de proyectos que no incluyen diversos factores de contexto en la planificación, hiperfocalizándose en la tecnología (servidores, fibras ópticas, tiempo que se tarda en instalar el server en el rack, etc.), olvidando las personas y su entorno, los que son en realidad factores que tienden - contínua, constantemente - a afectar la planificación realizada sobre la "tecnología pura".
Ejemplos de importantes "Factores de contexto": estado de salud promedio de los parientes y familia cercana de los miembros del equipo, eventos importantes personales próximos para los miembros del equipo y su familia cercana, tiempo que se tarda en llegar efectivamente - de verdad - al nivel de expertise necesario en la administración de un software para poder configurarlo apropiada, acertadamente para los escenarios y requerimientos complejos planteados, si los miembros del equipo se mueven en colectivo o en auto propio, si está lloviendo muy de seguido y las reuniones de equipo se realizan lejos de los lugares de residencia de los miembros, etc.
Si no vas a por los factores de contexto, los factores de contexto de seguro van a por tu proyecto y su probablemente aséptica e irreal planificación.
Early Adopters
Los early adopters son colaboradores de LC, validadores de las ideas del producto mínimo, son quienes están usando la implementación más básica de la idea, tosca inclusive, de lo que va a ser el producto final, sumamente más refinado que las versiones que los early adopters están usando ahora mismo.
Las métricas obtenidas de los early adopters son la información más importante de Libres Consultores de momento, en especial aquellas que validan determinadas ideas de diseño de los productos, por ende es difícil dar muchos detalles.
Componente actualizado
Uno de los componentes clave de un producto de LC ha sido beneficiado recientemente por una actualización masiva incremental ("incremental" es el mejor tipo de actualización que puede recibir un software que ya funciona muy bien, por cierto), justo en estos días. Lo bueno de todo es aunque ya se trata de una versión avanzada del software - hace tiempo ya dejó la versión 1.0 - y tienen una fortaleza probada en escenarios empresariales muy exigentes, en el tiempo restante hasta que LC libere la versión inicial de su propio producto, incluyendo este componente, el producto va a ser beneficiado con la experiencia de los early adopters del software recién actualizado mencionado, y aquellos que van a actualizarse a la nueva versión.
Colaborando con la comunidad
No está de más mencionar que también vamos a contar - y a generar! - con los meta-datos importantes que siempre son lentamente liberados en el primer par de meses luego de una nueva versión mayor de un software complejo: tutoriales, fixes, howto's avanzados, howto's especializados creados por los mismos desarrolladores/implementadores del software, etc.etc.
Hace unos días justamente me puse en contacto con un ingeniero que está usando en producción este software (componente del producto de Libres), en una implementación avanzada y personalizada para un escenario, un caso de uso muy similar al caso de uso modelo del producto de Libres; ya se hicieron las presentaciones y estaremos colaborando conjuntamente en los meses venideros intercambiando material técnico importante al respecto, casualmente, esta misma semana pasada, recibí de su parte un "batch" importante de "metadatos" que son de suma utilidad para el producto de Libres y devolví un feedback con algunos datos que extrapolamos de nuestras propias implementaciones de testing.
Innovación incremental y productos complementarios
El caso de Google y su emprendimiento para crear un producto que genere un mercado nuevo, nos sirve para ejemplificar el trabajo que estamos haciendo hoy en LC sin contar qué es lo que estamos armando (todavía no se puede en esta etapa*).
*Google puede comentar en público cuál es el proyecto en el que está trabajando porque tiene el crédito ganado en proyectos anteriores llevados adelante con éxito, lo que es un importante capital en marketing y lo están gastando un poco al hacer público un proyecto ambicioso que todavía no se concretó en tecnología que no sea prototipos que no pueden ser llevados a producción masiva, ni venderse al público, por cierto.
En Libres Consultores ya tenemos prototipos funcionales de los productos, sin embargo, (todavía), no tenemos el crédito necesario para dar a conocer los conceptos en la instancia en que no están listos para producción masiva ni venta al público, en cambio, es preferible llegar a generar el(los) producto completo (algo que tampoco está demasiado lejos), y recién en esa instancia, hacer públicos los conceptos.
Lo que, como dije anteriormente, no impide que podamos comentar cómo estamos trabajando en LC.
Google está desarrollando automóviles que no necesitan conductores para poder usarse.
http://en.wikipedia.org/wiki/Google_driverless_car
La tecnología base para lograrlo ya está creada (algunos prototipos recientes usan Ubuntu como sistema operativo), pero faltaba que alguien emprendiera en la idea de integrar esa tecnología avanzada dispersa en una función singular, práctica (y rentable): un auto que pueda usarse sin necesidad de conducirlo.
La tecnología que va a vender Google se basaría principalmente en que ya existe un producto base sobre el cual se podría llegar a instalar el hardware y software necesario para lograr un driverless_car, esto es clave, ya que Google difílmente pueda llegar a construir sus propias fábricas de automóviles e integrar ellos mismos la tecnología en fábrica, sí en cambio se podría ver cómo poder vender kits de la tecnología para poder instalarlos en vehículos (tal como se puede instalar unos parlantes en el baúl de un auto hoy en día, por ejemplo), sino directamente kits que requieran instalación especializada con licencias de instalador, lo que según se lee en la red, tal vez sea lo más probable que ocurra (es parecido a la instalación de tanques de gas natural y lo necesario para adaptar su uso en motores que de fábrica funcionan con otro combustible).
Es decir, el probable futuro producto de Google va a ser - tal vez - un bien complementario de un automóvil.
Las tecnologías complementarias, los bienes complementarios son clave en la creación de nuevos productos, ya que aceleran en gran medida la adopción de un nuevo producto, por el simple concepto de la innovación incremental.
Un extracto explicando la noción:
"La innovación en los negocios se consigue de diferentes maneras. Pueden ser desarrolladas por modificaciones realizadas en la práctica del trabajo, por intercambios y combinaciones de experiencia profesional y de muchas otras formas. Las innovaciones más radicales y revolucionarias suelen provenir de I&D mientras que las más incrementales suelen emerger de la práctica, pero existen excepciones a cualquiera de estas dos tendencias."
El artículo de abajo, justamente, cita a Google como una de las empresas que mejor aplica el concepto de innovación incremental para sus productos.
"Innovación Disruptiva (Radical) e Innovación Incremental."
http://www.eoi.es/blogs/juanadoricelcepeda/2012/03/09/innovacion-disruptiva-radical-e-innovacion-incremental/
Lo anterior es un clara alusión a la futilidad patente para la gestión de proyectos de tecnología de la información (IT), de muchas metodologías de gestión de proyectos que no incluyen diversos factores de contexto en la planificación, hiperfocalizándose en la tecnología (servidores, fibras ópticas, tiempo que se tarda en instalar el server en el rack, etc.), olvidando las personas y su entorno, los que son en realidad factores que tienden - contínua, constantemente - a afectar la planificación realizada sobre la "tecnología pura".
Ejemplos de importantes "Factores de contexto": estado de salud promedio de los parientes y familia cercana de los miembros del equipo, eventos importantes personales próximos para los miembros del equipo y su familia cercana, tiempo que se tarda en llegar efectivamente - de verdad - al nivel de expertise necesario en la administración de un software para poder configurarlo apropiada, acertadamente para los escenarios y requerimientos complejos planteados, si los miembros del equipo se mueven en colectivo o en auto propio, si está lloviendo muy de seguido y las reuniones de equipo se realizan lejos de los lugares de residencia de los miembros, etc.
Si no vas a por los factores de contexto, los factores de contexto de seguro van a por tu proyecto y su probablemente aséptica e irreal planificación.
Early Adopters
Los early adopters son colaboradores de LC, validadores de las ideas del producto mínimo, son quienes están usando la implementación más básica de la idea, tosca inclusive, de lo que va a ser el producto final, sumamente más refinado que las versiones que los early adopters están usando ahora mismo.
Las métricas obtenidas de los early adopters son la información más importante de Libres Consultores de momento, en especial aquellas que validan determinadas ideas de diseño de los productos, por ende es difícil dar muchos detalles.
Componente actualizado
Uno de los componentes clave de un producto de LC ha sido beneficiado recientemente por una actualización masiva incremental ("incremental" es el mejor tipo de actualización que puede recibir un software que ya funciona muy bien, por cierto), justo en estos días. Lo bueno de todo es aunque ya se trata de una versión avanzada del software - hace tiempo ya dejó la versión 1.0 - y tienen una fortaleza probada en escenarios empresariales muy exigentes, en el tiempo restante hasta que LC libere la versión inicial de su propio producto, incluyendo este componente, el producto va a ser beneficiado con la experiencia de los early adopters del software recién actualizado mencionado, y aquellos que van a actualizarse a la nueva versión.
Colaborando con la comunidad
No está de más mencionar que también vamos a contar - y a generar! - con los meta-datos importantes que siempre son lentamente liberados en el primer par de meses luego de una nueva versión mayor de un software complejo: tutoriales, fixes, howto's avanzados, howto's especializados creados por los mismos desarrolladores/implementadores del software, etc.etc.
Hace unos días justamente me puse en contacto con un ingeniero que está usando en producción este software (componente del producto de Libres), en una implementación avanzada y personalizada para un escenario, un caso de uso muy similar al caso de uso modelo del producto de Libres; ya se hicieron las presentaciones y estaremos colaborando conjuntamente en los meses venideros intercambiando material técnico importante al respecto, casualmente, esta misma semana pasada, recibí de su parte un "batch" importante de "metadatos" que son de suma utilidad para el producto de Libres y devolví un feedback con algunos datos que extrapolamos de nuestras propias implementaciones de testing.
Innovación incremental y productos complementarios
El caso de Google y su emprendimiento para crear un producto que genere un mercado nuevo, nos sirve para ejemplificar el trabajo que estamos haciendo hoy en LC sin contar qué es lo que estamos armando (todavía no se puede en esta etapa*).
*Google puede comentar en público cuál es el proyecto en el que está trabajando porque tiene el crédito ganado en proyectos anteriores llevados adelante con éxito, lo que es un importante capital en marketing y lo están gastando un poco al hacer público un proyecto ambicioso que todavía no se concretó en tecnología que no sea prototipos que no pueden ser llevados a producción masiva, ni venderse al público, por cierto.
En Libres Consultores ya tenemos prototipos funcionales de los productos, sin embargo, (todavía), no tenemos el crédito necesario para dar a conocer los conceptos en la instancia en que no están listos para producción masiva ni venta al público, en cambio, es preferible llegar a generar el(los) producto completo (algo que tampoco está demasiado lejos), y recién en esa instancia, hacer públicos los conceptos.
Lo que, como dije anteriormente, no impide que podamos comentar cómo estamos trabajando en LC.
Google está desarrollando automóviles que no necesitan conductores para poder usarse.
http://en.wikipedia.org/wiki/Google_driverless_car
La tecnología base para lograrlo ya está creada (algunos prototipos recientes usan Ubuntu como sistema operativo), pero faltaba que alguien emprendiera en la idea de integrar esa tecnología avanzada dispersa en una función singular, práctica (y rentable): un auto que pueda usarse sin necesidad de conducirlo.
La tecnología que va a vender Google se basaría principalmente en que ya existe un producto base sobre el cual se podría llegar a instalar el hardware y software necesario para lograr un driverless_car, esto es clave, ya que Google difílmente pueda llegar a construir sus propias fábricas de automóviles e integrar ellos mismos la tecnología en fábrica, sí en cambio se podría ver cómo poder vender kits de la tecnología para poder instalarlos en vehículos (tal como se puede instalar unos parlantes en el baúl de un auto hoy en día, por ejemplo), sino directamente kits que requieran instalación especializada con licencias de instalador, lo que según se lee en la red, tal vez sea lo más probable que ocurra (es parecido a la instalación de tanques de gas natural y lo necesario para adaptar su uso en motores que de fábrica funcionan con otro combustible).
Es decir, el probable futuro producto de Google va a ser - tal vez - un bien complementario de un automóvil.
Las tecnologías complementarias, los bienes complementarios son clave en la creación de nuevos productos, ya que aceleran en gran medida la adopción de un nuevo producto, por el simple concepto de la innovación incremental.
Un extracto explicando la noción:
"La innovación en los negocios se consigue de diferentes maneras. Pueden ser desarrolladas por modificaciones realizadas en la práctica del trabajo, por intercambios y combinaciones de experiencia profesional y de muchas otras formas. Las innovaciones más radicales y revolucionarias suelen provenir de I&D mientras que las más incrementales suelen emerger de la práctica, pero existen excepciones a cualquiera de estas dos tendencias."
El artículo de abajo, justamente, cita a Google como una de las empresas que mejor aplica el concepto de innovación incremental para sus productos.
"Innovación Disruptiva (Radical) e Innovación Incremental."
http://www.eoi.es/blogs/juanadoricelcepeda/2012/03/09/innovacion-disruptiva-radical-e-innovacion-incremental/
No hay comentarios:
Publicar un comentario