Posts Tagged ‘software’

h1

De análisis de redes y el Juego de Tronos

04/08/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

El floreciente campo de la informática ha cambiado nuestra visión del mundo físico: de una colección de partículas que interactúan unas con otras, a la de una agitada red de información. Bajo esta manera de ver la naturaleza, las leyes de la física forman parte de un software o algoritmo, mientras el mundo material – el hardware – desempeña el papel de una computadora gigantesca.

Paul Davies (n. 1946). Físico, escritor y locutor británico.

A tan sólo tres semanas para que se estrene la sexta temporada de la serie de televisión, y de manera optimista, un par de meses para que el sexto de siete libros que conforman la odisea completa sea publicado, los fans de la saga del Juego de Tronos de George R.R. Martin estamos esperando con ansia la resolución de varios cliffhangers que involucran a los protagonistas principales de la serie.

Sin embargo, ¿Quiénes son los verdaderos protagonistas de esta historia? Porque si algo hemos aprendido de Mr. R.R. Martin, es que aparentemente, cada vez que un personaje tiende a transformarse en un protagonista central, él o ella es asesinado, usualmente en formas brutales y despiadadas. Esto es exacerbado por el hecho de que el propio autor es todo un troll, quien si bien ofrece algunas pistas, jamás ha divulgado quiénes serán los ganadores del Juego de Tronos. Sin embargo, existen algunos personajes apareciendo constantemente en los libros y la serie de televisión, y que probablemente logren llegar sin tantos raspones al final de esta extraordinaria historia.

Es así como Andrew J. Beveridge, profesor en matemáticas del Colegio Macalester en Saint Paul, Minnesota, realizó un pequeño trabajo de investigación, modelando al mundo de Juego de Tronos como una red social, para después aplicarle el así llamado análisis de redes: una rama de la teoría de grafos que se alimenta de varias disciplinas, incluyendo la economía, la sociología y la informática, para examinar cómo fluye la información entre varios “nodos”. En este caso, se busca encontrar un patrón de comunicación entre los diversos personajes, para identificar los que mayor interacción e influencia tienen sobre otros. Así, usando el tercer libro de la serie como referencia (A Storm of Swords, más o menos equivalente a la tercera temporada de la serie de televisión), cada que dos personajes interactúan dentro de un espacio de 15 palabras, un enlace (o “borde”) se añade entre ambos. Los enlaces se ponderan según la frecuencia de proximidad mutua entre ambos personajes. El resultado habla por sí mismo:

Graph representing the GOT characters

La red social generada para A Storm of Swords. El color de un vértice indica la comunidad inmediata a la que pertenece el personaje. El tamaño del vértice corresponde al valor del PageRank dentro de toda la red, y el tamaño de la etiqueta corresponde a la importancia de intermediación hacia otros personajes. El grosor de un enlace representa su peso.

(Fuente de imagen y pie de página: Mathematical Association of America)

El personaje que obtuvo el primer lugar en casi todos los aspectos es Tyrion Lannister, héroe Byroniano por excelencia quien de hecho, es el favorito de Mr. Martin. Así, Tyrion es el personaje matemáticamente más importante en el Juego de Tronos, y sin el cual, la saga se vería muy limitada en todos sus aspectos. Claro que, Tyrion es seguido por Jon Snow, el 998o. Lord Comandante de la Guardia Nocturna y presunto hijo bastardo de Eddard Stark. Finalmente, tenemos a Sansa Stark, la hija mayor de Eddard, quien se encuentra involucrada en una multitud de difíciles situaciones a lo largo de esta historia.

Por otro lado, Daenerys Targaryen, la aparente legítima heredera al Trono de Hierro, también es muy importante. Sin embargo, en el grafo obtenido por el profesor Beveridge, ella tiene un rango más bajo, debido a que el personaje radica en el continente de Essos, apartada de la acción principal, que transcurre en el ficticio continente de Westeros. De acuerdo al propio Beveridge, el análisis de redes predice hacia dónde se dirigirá la historia, ya que “Daenerys realmente representa el futuro, pues se puede ver lo que está a punto de suceder, en base a la gente con la que ella está vinculada.” Y ciertamente así ocurre: durante los siguientes volúmenes y temporadas de la serie, la historia de esta mujer se ha vuelto infinitamente más importante; sobre todo porque desde el final de la quinta temporada de la serie de televisión, Tyrion ya es parte de la corte real de la “Madre de Dragones”.

De vuelta a la realidad

Sin embargo, dejando de lado el fantástico mundo del Juego de Tronos, esta disciplina tiene aplicaciones mucho más serias: a sabiendas de que el crimen organizado y el terrorismo se han vuelto una actividad social que requiere de medios de comunicación sofisticados, los análisis de redes permiten, mediante software comercial al alcance de todos, identificar a los miembros de este tipo de agrupaciones delictivas. En conjunto con registros telefónicos, es posible hacer un análisis que permita determinar con precisión la identidad de los cabecillas de una conspiración: de acuerdo al sociólogo e investigador en redes sociales Duncan Watts, si las agencias de seguridad estadounidenses hubieran realizado un análisis como éste en los meses previos a los atentados terroristas del 11 de Septiembre de 2001, dichas agrupaciones habrían identificado con facilidad a los principales responsables del ataque, acabando con el plan desde su incepción al haber capturado o eliminado a sus 3 autores intelectuales.

Aunque los detractores pueden considerar este tipo de análisis como un ataque a nuestra privacidad, la realidad es que este tipo de explotación de la información ya es usada de manera constante por corporativos multinacionales, incluyendo los bancos y las compañías de retail, para modelar nuestros gustos y preferencias, personalizando sus ofertas para asegurar una venta. De hecho, otras lo hacen porque ESE es su modelo de negocio: cuando una compañía nos ofrece servicios aparentemente de forma gratuita, es porque nosotros somos el producto. Sin embargo, tampoco deberíamos bajar la guardia: si las reglas del juego (privacidad y almacenamiento de la información personal) no están bien establecidas, esas compañías que muchos de nosotros consideramos nuestras “amigas”, y a las que confiamos nuestra información más íntima, no tienen ningún problema en entregar nuestra información a los malandros, por un precio.

h1

¿Qué es la estrategia TI Bimodal (Bimodal IT) y cómo podemos implementarla?

01/08/2016

Wizdoc [Icon By Buuf]  Tips & Tricks.

No importa qué tan lento vayas, siempre y cuando no te detengas.

Confucio (551 – 479 AC). Profesor, editor, político y filósofo chino.

Hace un par de semanas tuvimos una reunión con cliente relacionada a su estrategia TI y cómo piensa crecer durante el próximo año fiscal. Durante la junta salieron a relucir algunas palabras clave como innovación o implementación ágil. Sin embargo, la frase que nos dio la respuesta a lo que realmente está buscando, se resume en dos palabras: estrategia bimodal. ¿De qué se trata? ¿Por qué algunos la están considerando como la nueva panacea que asegurará la competitividad de las organizaciones TI? ¿Y cuáles son los riesgos encontrados durante su adopción?

Durante el Simposio/ITxpo llevado a cabo por la firma de consultoría e investigación de mercado Gartner en Octubre de 2014, el vicepresidente senior y jefe global de investigación, Peter Sondergaard, señaló que mientras los CIOs no sean capaces de transformar sus departamentos TI de manera que sean más ágiles y competitivos, podrán convertir sus organizaciones mediante un modelo TI Bimodal; de hecho, según Gartner, para el 2017, el 75% de las organizaciones de TI tendrá una capacidad bimodal. Este modelo se describe como “La práctica de gestionar dos modos distintos y coherentes de ejecución de TI, uno centrado en la estabilidad y el otro en la agilidad. El Modo 1 es tradicional y secuencial, haciendo hincapié en la seguridad y precisión. El Modo 2 es exploratorio y no lineal, con énfasis en la agilidad y rapidez.” Así, la organización tendrá dos maneras de llevar a cabo sus iniciativas TI:

Modo 1

• Involucra a proyectos relacionados con el mantenimiento de los sistemas centrales (core systems) – usualmente las bases de datos y sistemas legados.
• Se centra en proporcionar estabilidad y eficiencia, respetando los ciclos de desarrollo más tradicionales, como cascada.

Modo 2

• Involucra a los proyectos que ofrecen innovación y agilidad para el negocio.
• El foco está en la respuesta rápida, mientras trabaja en liberaciones frecuentes (básicamente, desarrollo ágil de software).

No tan rápido

Sin embargo, el problema que intenta atacar Gartner no es nuevo (agilidad vs. estabilidad); por el contrario, si no se lleva a cabo de manera adecuada, el modelo bimodal puede degenerar en una lucha de poder entre las dos áreas, ya que es indispensable una colaboración transparente entre ambas con el afán de agregar valor de negocio. Las consecuencias, descritas en la revista CIO Insight, se enumeran a continuación:

• La primera y de mayor impacto sería la creación de silos artificiales para productos, procesos y personas. Esta es la dirección opuesta a toda tendencia organizacional saludable de TI desde que el término “síndrome del silo funcional” fue acuñado por Phil Ensor en 1988. TI Bimodal en silos significa lanzarse al ruedo precipitadamente, ignorando numerosos estudios publicados durante los últimos cuatro decenios.

• Estancamiento del Modo 1: El enfoque bimodal propone aplicar una curita sobre la herida que representan las plataformas tradicionales, pero no hace nada por detener la hemorragia. Este modelo institucionaliza el estancamiento, al desalentar la innovación en plataformas legadas bajo el pretexto de que “si no está roto, no lo arregles”.

• Rigidez del Modo 2: En palabras de Gartner, “el Modo 2 requiere un enfoque riguroso y disciplinado”, así que el modelo bimodal prescribe un flujo de proceso definido, previsible y lógico en torno a lo que en esencia, es un proceso impredecible para la experimentación y el descubrimiento. Algo así como “Pintura por números para la obra de Jackson Pollock.”

• Sobre-simplificación de procesos: Las nuevas aplicaciones se acuñarán en torno a uno de dos modos y serán siempre encerradas en un modus operandi que sin duda resultará ser inadecuado a largo plazo. TI Bimodal cierra las puertas a las aplicaciones legadas del Modo 1 para evolucionar a las ofertas ágiles del Modo 2; por el contrario se endurecerán las condiciones para que un prototipo ágil del Modo 2 pueda convertirse en una oferta de servicio más estable de acuerdo al Modo 1.

¿Cómo implementarla?

Aunque TI Bimodal suena bastante razonable sobre el papel, en la práctica los principales retos a sortear incluyen la priorización de los proyectos, la distribución de recursos entre ambos modos, integración o intercepción de proyectos (ya que por ejemplo, una aplicación móvil no es nada sin un back-end estable que la soporte) y cómo mantener a la organización, proveedores y socios de negocios apegados a esta visión. En pocas palabras, para alcanzar la meta planteada, es fundamental definir un gobierno TI o governance adecuado. Aunque la definición completa de un gobierno TI no es el objetivo de este post, baste decir que éste debe incluir los siguientes puntos:

• La alineación entre la estrategia de la organización y las TI.

• Obtención de valor que las TI generan para la organización.

• Mecanismos que permitan mediciones apropiadas para poder valorar las TI en su conjunto y poder tomar decisiones respecto a su gobierno.

• Gestión del riesgo que en un momento dado pueda afectar e impactar negativamente en las actividades y procesos de la organización.

• Gestión de los recursos TI y la utilización óptima de los mismos.

El gobierno TI debe facilitar un modelo transparente en el que todos los interesados tengan visibilidad sobre el día a día de las operaciones y el avance del programa estratégico. Asimismo, el modelo debe proveer una comunicación y priorización claras, que ayuden en la detección y resolución de problemas más rápidamente. Por ello, el proceso de gobierno debe abordar los siguientes tres niveles de revisión:

1. Estratégico: Cuando a un nivel de dirección ejecutiva, los diferentes grupos de interés puedan mantener y hacer crecer la relación (evitando caer en luchas de poder), resolviendo asuntos importantes, manteniendo la dirección establecida y aprobando los cambios estratégicos y el plan para el futuro.

2. Táctico: Donde a través de reuniones periódicas de los grupos de interés, éstos son capaces de asegurar que se está avanzando de acuerdo a los objetivos generales del programa.

3. Operacional: Cuando todos son capaces de trabajar sobre una base del día a día para ofrecer los servicios y entregables TI, respondiendo a peticiones, problemas y consultas, en línea con los objetivos del programa.

Pic: Bimodal IT Governance Example


Para que TI Bimodal – o cualquier otra estrategia de TI – tenga éxito, la visión tiene que ser compartida por todos los niveles de la organización: la alta dirección, proveedores, socios de negocio, gerentes de proyecto y equipos de trabajo por igual. Además, el éxito se mide no sólo por la entrega de valor a la organización de TI, sino por el valor del negocio; es decir, que la estrategia TI beneficia al negocio de una manera cuantificable. El éxito del programa, por lo tanto, debe ser comunicada a todos los niveles de la organización.

Parafraseando a George Orwell, aunque los tres niveles de revisión son igualmente importantes, algunos son más iguales que otros: el nivel estratégico tiene como principal responsabilidad mantener alienada la estrategia con los objetivos de negocio, monitoreando el desempeño de las demás áreas y detectando y resolviendo cualquier riesgo de alto nivel que se llegue a presentar; por otro lado, el nivel operativo lleva a cabo los proyectos individuales, reportando su progreso y asegurándose que las métricas impuestas por los otros dos niveles se cumplan. Sin embargo, el nivel que es crucial durante la implementación es el nivel táctico (la Oficina de Gestión de Proyectos o PMO, así como el Centro de Excelencia o CoE) ya que tiene por principal responsabilidad:

• Generar estándares y procesos, así como seleccionar las herramientas y tecnologías que usará el resto de la organización.

• Revisar el rendimiento y apego a normas de desempeño acordados para todos los grupos.

• Desarrollar el programa de implementación de la estrategia.

• Llevar a cabo el presupuesto, planeación y asignación de recursos.

• Asegurarse de que todas las políticas, planes, normas, etc. permean a los equipos de la organización.

• Resolver problemas tácticos escalados con el Comité de Gobierno estratégico (Steering Committee) y

• Escalar problemas al Comité de Gobierno cuando sea apropiado (por ejemplo, asuntos contractuales).

Algunos tips durante la adopción de este modelo

La gran ventaja de Bimodal es que la organización ya debería poseer un área de operaciones/desarrollo relativamente madura trabajando en Modo 1; esta madurez es precisamente la que asegura una implementación ordenada y estable, pero impide que iniciativas “para ayer” se concreten eficazmente. Por lo tanto, el proceso de adopción debe enfocarse a la creación del Modo 2 y cómo sus equipos deben interactuar y coordinarse eficientemente con los equipos del Modo 1. Por lo tanto, una adopción debe considerar entre otros, los siguientes puntos dentro del programa de implementación de estrategia:

• Una evaluación de la capacidad (readiness assessment) para convertir un segmento de la organización al Modo 2 de operación. Esto permitirá saber qué equipos y proyectos pueden generar el mayor valor de negocio en el menor tiempo posible. Por ejemplo, los proyectos más apropiados para llevarse a cabo en el Modo 2 son aquellos que poseen 1) fechas de entrega muy agresivas, 2) un alto grado de complejidad, y 3) un alto grado de innovación.

• Identificar uno o varios coaches versados en el Modo 2 de operación – Scrum, Lean, Kanban, V-Model, etcétera – que puedan resolver las dudas durante la implementación. Éstos por supuesto, deben ir de la mano con el Centro de Excelencia para definir los procesos, herramientas y entregables de gestión y desarrollo ágil que adoptará la organización.

• En caso de que los equipos del Modo 2 se hayan integrado con el personal original de la organización, es indispensable enfocarse en el cambio cultural. Si bien las prácticas y herramientas ágiles son importantes, establecer una mentalidad ágil es indispensable. Esto implica creer firmemente en el empowerment, liderazgo subordinado o equipos multidisciplinarios. El beneficio es que aseguramos una mentalidad de colaboración y urgencia para satisfacer las cambiantes demandas del negocio.

• Para el momento en que se inicie el delivery de equipos en el Modo 2, ya se debe haber seleccionado una herramienta de planeación (por ejemplo, JIRA o VersionOne), se debe haber proporcionado el entrenamiento adecuado a los equipos y se deben haber definido las métricas mínimas para que de manera periódica, pueda existir una rendición de cuentas al Comité de Gobierno.

• Finalmente, una vez que se han dado los primeros pilotos de adopción del Modo 2 y se ha establecido la manera en que ambos tipos de equipo estarán colaborando, es indispensable generar un proceso de mejora continua para perfeccionar la integración de todos los interesados. Para este momento, iniciar la estandarización – por ejemplo, certificar los proyectos corriendo en Modo 1 en CMMi-5 y los proyectos ejecutados en Modo 2 en CMMi-3 – ya es posible.

Conclusiones

La estrategia Bimodal NO es la bala de plata. Es tan sólo un paso intermedio hacia la introducción de prácticas como DevOps. A final de cuentas, lo que cualquier organización debe buscar, es la convergencia para actualizar sus procesos e infraestructura a la realidad del mercado. Hace algún tiempo, el analista independiente Jason Bloomberg dio su propio punto de vista al respecto de lo que él llamó una “receta para el desastre” de Gartner, añadiendo su propia recomendación: … para que la transformación digital tenga éxito, debe ser de extremo a extremo – con los clientes en un extremo y los sistemas legados del otro. TI tradicional, por supuesto, sigue siendo responsable de los sistemas legados.

Así, el enfoque debe ser el de empresas exitosas como Apple, Amazon o Google:

• ¿Cómo podemos deleitar a los clientes con nuevos productos y un mejor servicio?

• ¿Cómo se puede mejorar continuamente nuestro negocio con pequeños incrementos?

• ¿Cómo podemos optimizar la cadena de valor?

• ¿Cómo nos aseguramos de que el negocio impulsa el cambio y no el departamento de TI o marketing?

La clave reside en contestar estas preguntas honestamente y trabajar en ello… o formar parte del registro fósil de empresas fallidas, junto a anti-ejemplos tales como Eastman Kodak, PanAm y Compaq.

h1

Adrenaline Junkies and Template Zombies

08/28/2015

Wizbook [Icon By Buuf]  Libros.

No existen los fracasos – sólo experiencias y tus reacciones a éstas.

Tom Gunnar Krause (1934 – 2013), cantante bajo-barítono y maestro de canto finlandés.

En el área de TI en general y el desarrollo de software en particular, es poco frecuente encontrar un “hombre orquesta” que pueda llevar por sí mismo proyectos complejos o de alta criticidad. Hoy por hoy, la industria requiere de equipos de trabajo compuestos por personal de diferentes áreas – gerentes, programadores, DBA’s, especialistas en dominio de negocio – quienes deben colaborar de manera efectiva para alcanzar los objetivos propuestos por la organización o proyecto. Sin embargo, aunque la literatura se enfoca a las habilidades individuales y cómo debe gestionarse el proyecto, muy pocos autores se han enfocado al tema de la cultura organizacional y cómo ésta puede entorpecer o apoyar al cumplimiento de estos objetivos.

Es así como “Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior” por Tom de Marco et al. nos presenta un compendio de 86 patrones de comportamiento – buenos, malos y el ocasional wtf – encontrados en nuestros proyectos y organizaciones. Es un libro dirigido a los practicantes del team leadership o project management, y aunque no es demasiado formal, las narrativas de cada uno de estos patrones nos permiten identificar si vamos por el buen camino, o si estamos cayendo en esas dinámicas de grupo en las que el resultado no será nada agradable. Los autores no se toman a sí mismos demasiado en serio, por lo que muchos que ya tenemos varios años en este negocio, recordaremos con una sonrisa aquellas “tragedias griegas” que hemos experimentado a lo largo de nuestra carrera. A continuación incluyo algunos de los patrones más valiosos que encontré en este ejemplar:

2. Rattle yer Dags: El equipo exhibe un sentido palpable de urgencia para determinar quién debe hacer qué para cuándo, y un deseo de llevar a cabo todas las acciones necesarias inmediatamente.

8. Contacto visual: La organización tiende a co-localizar al personal del proyecto cuando el trabajo es urgente y complejo.

31. Ritmo: El equipo establece un ritmo de trabajo mediante entregas en intervalos regulares.

33. Noche de Póker: Los empleados de toda la organización se reúnen para realizar actividades que no están vinculadas a sus funciones de trabajo.

56. Toda la atención: La participación de tiempo completo en un solo proyecto mejora el rendimiento individual.

66. Seelenverwandtschaft: La organización permite que un equipo particular deje fuera incluso las reglas más fundamentales de su proceso de desarrollo.

75. La puerta del refrigerador: De manera rutinaria, los miembros del equipo exponen los frutos de su trabajo para que los demás los vean.

78. Razones para el cambio: Se abren ventanas de oportunidad para cambios de alcance específicos durante todo el proyecto, usualmente alineados con los límites de iteraciones de desarrollo.

Es interesante ver cómo sin realmente proponérselo, los autores nos muestran que buena parte de los patrones positivos encontrados en el libro pertenecen a la filosofía ágil: si bien éstos son nombrados de diferente manera (por ejemplo, la “puerta del refrigerador” es mejor conocida como “radiadores de información” en el ámbito ágil), todos estos patrones permiten mejorar la productividad del equipo, mientras al mismo tiempo, facilitan elementos clave de la gestión de proyectos, como la comunicación, la propiedad compartida sobre los entregables y un mejor control del alcance del proyecto.

Por otro lado, el problema que tengo con el libro es que éste sólo describe la dinámica resultante, sin dar mayores explicaciones. Esto es especialmente aparente en los patrones negativos: aunque son muy jocosos – o mejor dicho, tragicómicos – la realidad es que una vez que nuestros proyectos tienden a permanecer en el lado negativo de las cosas, el lector tendrá que depender de su propia experiencia y habilidades para modificar el entorno de trabajo y prosperar, o mantenerse en un curso directo al desastre. Por ejemplo, uno de los capítulos que demuestra este punto es la “jerga de proyecto” o project-speak: palabras y frases que suenan inofensivas a primera vista, pero que disfrazan ideas nefastas:

CUANDO ELLOS DICEN: REALMENTE QUIEREN DECIR:
El calendario es agresivo. Estamos fritos.
Vamos a compensar la metedura de pata en las próximas iteraciones. Seguimos estando fritos.
Él es el hombre clave. Él está frito.
resumen ejecutivo versión de tira cómica
alto nivel que no es de verdad
acumulación rápida de personal (rapid staff buildup) si una mujer puede tener un bebé en 9 meses, trayendo 9 mujeres a bordo tendremos un bebé en un mes, ¿cierto?
Gerente de Proyectos Especiales gestiona su propio escritorio
Venimos del corporativo y estamos aquí para ayudar. (No necesita mayor explicación)
El trabajo continúa. No tenemos ni idea.
El tiempo lo dirá. No tenemos ni idea, y lo admitimos.
Esta ha sido una experiencia de aprendizaje. Realmente jodimos esto.
Una vez dicho esto… Todo lo que he dicho anteriormente eran tonterías.
código completo no probado
Estás facultado. (empowered) Te toca cargar con la culpa de esto.
fruta madura (low-hanging fruit) Algo que incluso [insertar nombre] no puede estropear.
Pongamos esto atrás y sigamos adelante. (significa lo mismo que cuando un político lo dice)
Ahora, toma mi consejo. Te supero en rango.
El código se ha vuelto inmantenible. Yo lo hubiera diseñado de otra manera.
Todavía estamos a 30,000 pies. Está en mi escritorio, sin tocar.
Bradley aquí es nuestro comodín. Bradley aquí es el idiota del proyecto.
Mantente en la misma página. Hazlo a mi manera.
mejor práctica inventado por las personas que no trabajan aquí y por lo tanto infinitamente superior a todo lo que hacemos
Apalanca las competencias básicas (core competencies). No hagas la parte difícil.
Hazlo fuera de línea. Haz que desaparezca.
Tienes un nuevo enfoque. Eres un imbécil.
Las pruebas han resultado ser un cuello de botella importante. Se mantienen encontrando errores.
liberación limitada liberación sin funcionalidad
Déjame clarificar lo que necesito ¡Vienen nuevos requerimientos!
Estamos considerando nuestras opciones. la única que tenemos.
Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. Tom DeMarco, et al. (Dorset House, 2008).


Y… eso es todo con respecto a este tema: puede ser divertido conocer el significado real de aquellas frases usadas recurrentemente por el jefe o el cliente, pero ojeando a través del libro, es imposible encontrar cómo contrarrestar este lenguaje complicado y casi sin sentido (tip: es necesario demostrar honestidad y transparencia durante nuestras interacciones con otros, porque debemos entender que la deshonestidad crea incomodidad y duda entre aquellos con quienes estamos negociando; sin confianza o respeto mutuo sólo estamos postergando lo invetiable: una dolorosa ruptura). Por ello, Adrenaline Junkies debería considerarse como una serie de situaciones y anécdotas personales – historias de guerra si así lo queremos ver – pero de ninguna manera puede ser valorado como un libro con soluciones puntuales a una mala cultura corporativa afectando nuestros proyectos. Todo puede resumirse en “oh, sí; he pasado por esto antes”, pero jamás exclamaremos “Ahh, es por eso que este proyecto terminó en desastre…”

Así que, para aquellos que están iniciando sus carreras como gerentes o líderes de proyecto, será necesario buscar en otras publicaciones la razón de su falta de sueño y qué herramientas se requieren para coger al toro por los cuernos. Para los que ya tienen experiencia, es un buen retrato de lo que hemos tenido que soportar, y puede usarse como referencia para recordarnos cómo detectar aquellos olores que apestan nuestro proyecto, antes de que se conviertan en una historia de horror.

h1

¿Qué es la Internet de las Cosas (IoT)?

07/10/2015

Wizdoc [Icon By Buuf]  Tips & Tricks.

La mejor manera de predecir el futuro es creándolo.

Abraham Lincoln (1809 – 1865), decimosexto presidente de los Estados Unidos.

La Internet de las Cosas no es un concepto nuevo. Éste se basa en dos tecnologías que han existido por casi 50 años: la Internet y la comunicación máquina a máquina (Machine to MachineM2M). Lo que realmente ha cambiado las reglas del juego, es cómo estas dos tecnologías se han combinado para crear un paradigma que podría revolucionar al mundo. A continuación mencionamos por qué.

Corría el año de 1959, cuando el Departamento de Defensa de los Estados Unidos encargó a la Universidad de California en Los Ángeles (UCLA), una red de telecomunicaciones que pudiera ser utilizada de manera confiable y segura por todas sus instancias de gobierno, funcionando incluso ante una eventual guerra nuclear. Dicha red, finalmente implementada en 1969, basada en los protocolos TCP/IP y denominada como ARPANET, pasaría a ser parte del dominio público algunas décadas más tarde, extendiendo sus nodos hasta cada rincón del planeta. Ahora la conocemos como Internet, y cerca del 42.4% (2015) de la población mundial está conectada a ella de alguna u otra forma.

Por otro lado, en 1969 el inventor griego Theodore G. Paraskevakos ya había logrado crear un dispositivo que pudiese identificar el número telefónico desde el cual le estaban llamando. Hoy por hoy, esto es conocido como el identificador de llamada entrante o Caller ID, y es ahora considerado como la primera instancia de comunicación máquina a máquina. Con el pasar del tiempo, esta disciplina fue evolucionando hasta adquirir su actual modelo de operación: M2M comprende un dispositivo, tal como un sensor o medidor, que captura un evento (como la temperatura, el nivel de inventario, etc.) que se retransmite a través de una red a un programa de software o aplicación, traduciendo el evento capturado en información significativa. Por ejemplo, artículos que necesitan ser reabastecidos.

Usando este tipo de investigación, en 1982 varios estudiantes de la Universidad Carnegie Mellon conectaron una máquina expendedora de refrescos modificada a la ARPANET, convirtiéndose en el primer dispositivo o appliance en ser conectado a Internet del mundo. La máquina expendedora podía reportar su inventario, así como si las bebidas recién cargadas estaban frías.

Aunque ambas tecnologías ya estaban lo suficientemente maduras para 1987 – año en que las primeras aplicaciones comerciales de M2M basadas en RFID salían a la luz – no fue sino hasta el año de 1999, que el emprendedor británico Kevin Ashton acuñó el término “La Internet de las Cosas” (Internet of Things – IoT): “un sistema en el que la Internet está conectada al mundo físico a través de sensores ubicuos”. Con la aparición de la Web 2.0, la computación en la nube y Big Data, se ha extendido este concepto hasta incluir mucho más que teledetección. En términos simples, IoT predice que una vez que todos los dispositivos se encuentren conectados a Internet, existirán aplicaciones que les permitirán conectarse con los demás objetos a su alrededor, así como otros sistemas y aplicaciones en la nube. Cuando todos ellos actúen al unísono, conformarán una “inteligencia ambiental“. Por ejemplo, podríamos ver un sistema muy complejo, tal como un vuelo internacional, reportando los valores de todos los componentes mecánicos de la aeronave, la lista de pasajeros, inventario de carga e información de ruta, incluyendo aeropuertos de origen y destino, para combinarlos de una manera que optimice costos e incremente la seguridad del vuelo:

La nueva flota de aviones Virgin creará 500 gigabytes de datos en cada vuelo. Así que un vuelo redondo generará 1 Terabyte de información. El director TI para Virgin, David Bulman, espera una explosión de información. Los datos no sólo se generan a partir de fuentes digitales, sino también de ‘entidades’ físicas, como empleados, clientes, aviones y carga. En una entrevista para Computerworld Reino Unido, Bulman citó: “Los últimos aviones que estamos recibiendo, los Boeing 787, están increíblemente conectados. Literalmente, cada pieza de este avión tiene una conexión a Internet: desde los motores, los flaps, hasta el tren de aterrizaje. Si hay un problema con uno de los motores, lo sabremos antes de que aterrice, para asegurarnos de que tenemos las refacciones en el destino. Se está llegando al punto en el que cada parte del avión nos está diciendo lo que está haciendo conforme el vuelo ocurre. Este nivel de percepción operativa implicará la generación de grandes cantidades de datos por cada aeronave.”

Finnegan, Matthew. (2015). “Boeing 787s to create half a terabyte of data per flight, says Virgin Atlantic“. computerworlduk.com.

Todo dispositivo que tenga un sensor estará conectado a Internet, incluyendo los autos, los refrigeradores, las luces en nuestro hogar, e incluso elementos insospechados, tales como nuestros libros, la ropa de cama o las plantas ornamentales:

  • Transporte: Vehículos y sus partes, así como los dispositivos de navegación y rastreo, combinados para resultar en vehículos autónomos como el Google driverless car, rutas de distribución más eficientes, diagnóstico ante fallas mecánicas o “estacionamiento inteligente” (ver abajo), sin la necesidad de dobles filas o esperar a ver qué cajón de estacionamiento se desocupa.
  • Ciudades: Sistemas urbanos, incluyendo redes de energía, agua y drenaje; luces de tráfico y monitoreo de contaminantes. El uso de sistemas inteligentes permitiría una mejor planeación urbana, reducción de contaminantes o mapeo y respuesta rápida ante emergencias. Imaginemos un centro de monitoreo basado en los videojuegos SimCity o Cities:Skylines para darnos una idea de las posibilidades de esta plataforma.
  • Edificios inteligentes: Sistemas de ventilación, cámaras de vigilancia, red eléctrica e integridad estructural que permitan una mejor administración de los recursos del edificio – tales como luz y agua potable – así como incremento en su seguridad.
  • Hogar: Calefacción, detectores de humo, cerraduras, termostatos, artículos para el hogar (televisores, refrigeradores, estufas, lavavajillas, lavadoras) y robots de limpieza trabajando como una sola unidad: para una brillante, aunque algo deprimente representación del funcionamiento de una casa automatizada, basta leer la historia corta Vendrán lluvias suaves (1950), del aclamado escritor estadounidense Ray Bradbury.
  • Salud: Monitores del ritmo cardiaco, implantes, sensores de glucosa, administración de medicamentos. El cuidado de la salud es una de las áreas en las que más información se traduce en una mayor posibilidad de salvar vidas, mediante la prevención, seguimiento y tratamiento de enfermedades.
  • Wearables: Relojes, cámaras, pulseras, lentes, ropa, detectores de movimiento. Un ejemplo salido de la industria del entretenimiento: el MagicBand permite acceder a cualquier atracción encontrada en los parques temáticos de Disney, reemplazando prácticamente cualquier transacción dentro de sus instalaciones, tales como reservaciones y compras, mejorando la experiencia de los huéspedes.

IoT es un paradigma revolucionario porque las tecnologías involucradas (interfaces, dispositivos, redes, sensores, información y software) permiten no sólo detección y reporteo, sino que también es responsable de ejecutar acciones en base a las aportaciones de varios dispositivos, trabajando en conjunto:

Pic: IoT Innovations: Connected Car ~ SAP @ informationisbeautiful.net

Ejemplo de un auto conectado a IoT: estacionamiento inteligente. Si en vez de estar buscando por un lugar de estacionamiento – ¡algunas veces, por hasta 30 minutos! – posteriormente buscar el parquímetro y pagar con cambio, pudiésemos hacer todo esto de forma automática y con la mínima intervención humana posible, el tráfico en las grandes ciudades disminuiría considerablemente, mejorando nuestra productividad y calidad de vida.

(Dar click en imagen o aquí para ver en tamaño original)

(Fuente: informationisbeautiful.net)

A mediados del 2015, existen alrededor de 7 mil millones de dispositivos conectados a Internet; se estima que para el 2020, entre 25 y 30 mil millones de dispositivos estarán conectados, resultando en un fuerte impacto en una gran variedad de sectores económicos: la manufactura, la agricultura y los servicios que formen parte de IoT tendrán un valor de mercado de aproximadamente USD 1.7 billones para el 2020 ($ 1,700,000,000,000), equivalentes a un poco menos del producto interno bruto de Canadá de hoy en día.

Aspectos ingenieriles de IoT

Aunque una descripción detallada de los protocolos y frameworks existentes de IoT está fuera del alcance de este post, vale la pena mencionar que el paradigma ya no sólo se trata de gestionar conexiones TCP/IP: es necesario proporcionar seguridad, confiabilidad, redundancia y por supuesto, interoperabilidad. Primero lo primero: ¿cuál es la arquitectura de IoT? Para que se puedan considerar “conectados”, los dispositivos deben poder comunicarse entre sí (Device to Device – D2D). Luego, los datos capturados por el dispositivo deben ser recogidos y enviados a la infraestructura IT, compuesta principalmente por servidores (Device to Server – D2S). Esa infraestructura tiene que compartir los datos del dispositivo entre los servidores que la componen (Servier to Server – S2S), para posteriormente proporcionar información de regreso a los dispositivos, a los programas de análisis, o los dispositivos móviles que forman parte de la arquitectura. A grandes razgos, toda la plataforma puede verse así:

Pic: Framework of the IoT support system. ~ ZTE

Concepto de sistema de soporte o arquitectura de IoT: [Éste] consta de cuatro capas: la capa de detección, la capa de transporte de red, la capa de operación y gestión, y la capa de aplicación. La capa de detección consiste de una red inalámbrica de sensores (Wireless Sensor Network – WSN), lectores de RFID y terminales M2M. La capa de transporte de red contiene varias subredes (GSM, CDMA, 3G y de línea fija) ofrecidas por los operadores para la transferencia de información entre la capa de detección y la capa de aplicación. La capa de operación y gestión incluye la plataforma de apoyo a la operación, así como el ambiente en el que reside el Sistema de Apoyo a la Operación de Negocios (Business Operation Support System – BOSS). Al hacer uso de protocolos estándar, la plataforma de apoyo a la operación puede tener acceso a las terminales y aplicaciones, proporcionando funcionalidad como autenticación, facturación, gestión de servicios y aceptación del servicio, de modo que los operadores pueden gestionar aplicaciones de IoT de manera unificada. La capa de aplicación contiene un número de aplicaciones industriales que llaman a diferentes funcionalidades de los servicios a través de la plataforma de soporte de operaciones, con el fin de satisfacer las necesidades de servicio.

(Dar click en imagen o aquí para ver en tamaño original)

(Fuente de imagen y pie de página: zte.com.cn)

Por otro lado, los protocolos que controlan cómo un dispositivo transmite y recibe datos pueden ser un componente crítico a la hora de gestionar el resto de sus recursos. Sin entrar en demasiado detalle, los protocolos que forman parte de IoT se describen a continuación:

  • MQTT (Message Queue Telemetry Transport): Usado para recolectar la información capturada por el dispositivo y comunicarla a la infraestructura IT (D2S).
  • XMPP (eXtensible Messaging and Presence Protocol): Utilizado para conectar los dispositivos a las personas; basado en XML es un tipo especial de D2S ya que a final de cuentas, se conecta a los servidores.
  • DDS (Data Distribution Service): Un bus de datos utilizado para integrar dispositivos entre sí (D2D).
  • AMQP (Advanced Message Queuing Protocol): Un sistema de encolado utilizado para conectar servidores entre sí (S2S).

Retos

No todo es miel sobre hojuelas. IoT enfrenta grandes retos, los cuales determinarán durante los próximos años si ésta se convertirá en una exitosa estrategia de crecimiento tecnológico global o una rama relativamente importante de M2M, aunque sólo dirigida a nichos de mercado específicos:

  • Falta de estándares: La falta de estándares abiertos es un problema a nivel institucional dentro de IoT. Por ejemplo, el Internet Engineering Task Force (IETF) incorpora las aportaciones de múltiples interesados, incluyendo una combinación de responsables de políticas, capitanes de industria e ingenieros para formular el marco de desarrollo futuro para Internet. No existe tal organización para IoT, a pesar de que la tecnología toma prestados tanto el hardware como las prácticas de desarrollo de la Internet. La consolidación y competencia futuras podrían degenerar en otra guerra de estándares, como las ya famosas VHS vs. Betamax, o iOS vs. Android.
  • Privacidad y seguridad: En el ejemplo del automóvil conectado a IoT de más arriba, es necesario contar con diferentes proveedores de servicios trabajando al mismo tiempo para alcanzar un fin común: en este caso, encontrar y pagar por un cajón de estacionamiento. Es necesario enviar por la red información privada; mínimamente las placas del automóvil, así como la cuenta de la que se sustraerá el pago por el espacio. En caso de presentarse una falla de seguridad – un posible hackeo o robo de información personal – ¿Quién habría sido el responsable de salvaguardar esta información?
  • Complejidad de diseño y pruebas: Debido a que IoT implica interacciones entre una gran variedad de sensores, es muy complicado realizar el diseño correcto y pruebas correspondientes de una nueva aplicación, lo que limita el ingreso a sólo las compañías que pueden pagar por extensas pruebas y depuración. ¿Cuál fue el costo de conceptualizar, diseñar, implementar y depurar el sistema de MagicBands mencionado más arriba? La no-tan-despreciable cantidad de 1,000 millones de dólares – una inversión considerable incluso para Disney, pues representa 8% de sus ingresos brutos anuales.

Conclusiones

La Internet de las cosas se está convirtiendo en un tema de conversación cada vez más importante, tanto en el lugar de trabajo como fuera de él. Es un concepto que no sólo tiene el potencial de afectar la forma en que trabajamos, hacemos negocios o vivimos; ésta puede mejorar exponencialmente nuestra eficiencia, así como reducir desperdicios de tiempo, dinero y recursos. Sin embargo, así como IoT puede abrir muchas posibilidades, también ésta debe solventar muchos retos. Por ejemplo, la seguridad es uno de los obstáculos más importantes que han detenido la implementación generalizada de este paradigma: Con miles de millones de dispositivos conectados e interactuando conjuntamente, ¿qué debería hacerse para mantener segura la información personal? Después de todo, existe la posibilidad de que alguien llegue a hackear nuestro refrigerador, obteniendo acceso a toda nuestra red. Y si en la actualidad las empresas de todo el mundo están sujetas a constantes ataques a su seguridad – muchas veces, gestionados por gobiernos de naciones rivales – ¿cómo podemos asegurar nuestra privacidad e intercambio de datos seguro? Justo hace un par de días, hackers todavía sin identificar fueron capaces de colarse en una batería alemana de misiles tierra-aire…

Sin importar qué camino llegue a tomar la Internet de las cosas, es innegable que eventualmente tendrá un profundo impacto en nuestras vidas, de la misma forma en que los dispositivos móviles lo hicieron hace algunos años, o la TV y las computadoras lo hicieron con nuestros padres y abuelos desde hace algunas décadas.

h1

El nuevo crash de los videojuegos

05/29/2015

VGdoc [Icon By Buuf]  Entretenimiento: Videojuegos.

Durante los primeros días del negocio de los videojuegos, todo el mundo jugaba. La pregunta es, ¿qué pasó? Mi teoría – y creo que está bastante bien corroborada – es que en los años 80, los juegos se volvieron sangrientos, perdiendo a las mujeres. Y luego se volvieron complejos, perdiendo al jugador casual.

Nolan Bushnell (n. 1943), ingeniero electrónico y empresario estadounidense, fundador de la compañía de videojuegos Atari.

Hace algunos ayeres, los videojuegos eran prácticamente un esfuerzo académico de algunos ingenieros en electrónica con demasiado tiempo libre, pues en aquél entonces, las únicas computadoras en existencia eran unos armatostes de decenas de toneladas de peso, encontradas en los centros de investigación, instituciones militares y grandes corporativos multinacionales. En 1952, el estudiante de la universidad de Cambridge, Alexander Douglas, codificó una versión electrónica del tres en línea o gato, llamada OXO, ahora considerado como el primer videojuego del mundo, pues podía correrse desde la terminal de un computador EDSAC (Electronic Delay Storage Automatic Calculator), una de las primeras calculadoras electrónicas.

Algunas décadas más tarde (1971), Nolan Bushnell creó Computer Space, el primer juego de gabinete o arcade. Al fundar la icónica compañía Atari en 1972, Bushnell inició la era del videojuego. Para la década de 1980, otros competidores provenientes del Japón – Nintendo y Sega – estaban lenta, pero inexorablemente, arrebatando el mercado del videojuego a Atari. Luego vino el crash de 1983, cuando una sobresaturación del mercado, aunada a una pobre calidad de los títulos en existencia, causó la quiebra de decenas de compañías asociadas a esta forma de entretenimiento, incluyendo Atari.

Fue entonces que desde la mitad de la década de 1980, el videojuego para la PC se hizo presente. Elite y 1942 fueron algunos de los pioneros que hicieron su aparición en el Commodore 64 y ZX Spectrum. Algunos años más tarde, estos mismos juegos fueron “portados” a la ahora dominante IBM PC o compatible y su rústico pero poderoso sistema operativo, MS-DOS. Para la década de 1990 había ocurrido una explosión de géneros del videojuego, que hasta ese momento había consistido principalmente de aventuras de texto y side-scrollers, para darle paso a la estrategia en tiempo real, el survival horror o el first-person shooter.

Hoy por hoy contamos con mods, contenido descargable, juegos de rol multijugador masivo en línea, 3D, juegos para móvil y un sinfín de deleites gracias a consolas de octava generación, smartphones con más poder de cómputo del que disponía la NASA cuando colocó astronautas en la Luna y por supuesto, a la gloriosa raza superior de jugadores de PC 😉

Sin embargo, no todo es miel sobre hojuelas. Para ilustrar el argumento, una pequeña joya encontrada en la web:

Pic: I’m missing video games ~ commitstrip.com


Desarrollar un juego antes:

¡Estoy seguro que podemos mejorar la experiencia de juego y lanzar un videojuego totalmente perfecto! ¿Alguna idea?

Desarrollar un juego ahora:

Estoy seguro que podemos mejorar la experiencia de juego y hacer que la gente gaste más. ¿Alguna idea?

(Fuente: commitstrip.com)

El surgimiento y consolidación de una industria que para 2015 está valuada en US$111,057 millones, significa que en la actualidad, una buena parte de los videojuegos que salen al mercado ya no son producidos por equipos pequeños de personas que persiguen un sueño y buscan ganar algunos dólares en el camino. Ahora tenemos producciones multimillonarias llevadas a cabo por cientos de desarrolladores y dirigidas por siniestros individuos de saco y corbata, que sólo buscan hacer más dinero: Electronic Arts (EA) es el ejemplo más citado, con una terrible reputación de adquirir compañías de desarrollo para luego estrangularlas lentamente antes de asestar el golpe mortal, incluyendo a DreamWorks Interactive (Medal of Honor), Origin (Ultima, Wing Commander), Westwood (Command & Conquer) y Bullfrog (Syndicate, Dungeon Keeper).

La última víctima de EA ha sido el venerado Maxis, estudio del que surgieron las franquicias “SimCity” y “The Sims”. Lo más triste del asunto, es que su liquidación sólo ha mejorado la posición financiera de EA, para lograr ganancias por más de US$1,480 millones en 2014. Es decir, de momento, este ciclo seguirá presentándose: si algún estudio no satisface las expectativas comerciales de los ejecutivos de EA, recibe el hachazo inmediatamente. Como bien comenta Mike Williams en el sitio de videojuegos US Gamer: hasta los estudios relativamente exitosos como PopCap (Plants vs. Zombies) o Criterion Games (Burnout) pueden tener sus días contados.

Por ello, muchos analistas creen que se avecina otra crisis relacionada a esta industria. En el sitio cracked.com, los autores J.F. Sargent y Dave Williams nos describen la razón:

  • En la actualidad, los ejecutivos de las compañías desarrolladoras y distribuidoras de videojuegos no tienen nada que ver con la industria – son aquellos siniestros hombres de negocios descritos más arriba.
  • Los presupuestos para crear videojuegos se han vuelto una locura, haciendo de la innovación algo imposible. Y no es de extrañarse: si un videojuego ha costado decenas o cientos de millones de dólares en su producción y distribución – como los US$500 millones que costó Destiny – es muy difícil si no imposible que sus creadores se aparten de líneas de juego y modelos de negocio seguros.
  • Corrupción en los sistemas de reseñas. Básicamente, los distribuidores hacen payola para obtener una buena calificación, con frecuencia inmerecida, de parte de los críticos. Un caso muy sonado fue el Gerstmann-gate, en el que el director editorial del sitio de reseñas Gamespot, Jeff Gerstmann, fue despedido por dar una mala reseña del videojuego Kane & Lynch de Eidos Interactive.
  • El hardware cambia constantemente. ¿Recuerdan la famosa Ley de Moore? Resulta que cualquier videojuego tarda en promedio poco más de dos años para realizarse. Esto significa que los desarrolladores usualmente empiezan escribiendo código para cierto tipo de hardware, sólo para darse cuenta tres meses antes de la liberación que ese hardware es obsoleto, y es necesario volver a codificar. Esa es la razón por la que esos comerciales poseen un bello rendering que es completamente diferente del juego que hemos instalado.
  • Finalmente, la industria es extremadamente explotadora, alejando al verdadero talento. Con horarios de trabajo de 60 a 80 horas por semana y “marchas forzadas” que pueden durar por años, los veteranos – aquellos que realmente son capaces de llevar a cabo obras maestras de diseño e implementación – terminan tirando la toalla, cambiándose a áreas IT más convencionales. Así, la industria de los videojuegos sólo se queda con empresarios sin experiencia en la industria, supervisando a los jóvenes inexpertos que se quedan.

Esto no quiere decir que la industria llegará a desaparecer – por el contrario, con un crecimiento promedio de 12% anual ¿cómo podría? – sino que representa un cambio de paradigma, para bien o para mal. Con cada vez mayores costos, existe la posibilidad de que las superproducciones al estilo Hollywood encuentren un nicho en el mercado de las consolas, con tan sólo algunos nuevos juegos cada año, como la enésima encarnación de Call of Duty y Grand Theft Auto. Mientras tanto, poco a poco, los móviles están alcanzando el poder de cómputo de una PC, dejando atrás los Angry Birds y Candy Crush por juegos más sofisticados. Claro que, aquellos tipos de videojuego jamás desaparecerán, pues el modelo de microtransacciones sigue siendo viable. Finalmente, mientras sea posible portar estos videojuegos a la PC, ésta categoría permanecerá como un “colchón” para los productores independientes. Aunque eventualmente, este mercado será absorbido por las tablets y otros dispositivos móviles.

Si nos basamos un poco en los eventos posteriores al crash de 1983, es muy probable que el mercado finalmente se vuelva global: en aquél entonces, Atari, primordialmente Americano, cedió el paso a Nintendo y Sega, que son marcas Japonesas. Hoy en día, es posible que debido a un menor costo de mano de obra, así como sistemas de distribución digitales como Steam, veamos el surgimiento de nuevas marcas en los así denominados “mercados emergentes”, como China, el Sureste de Asia, ¿y por qué no? Latinoamérica, África y el Medio Oriente. Con decir que en diciembre de 2014, la compañía con mayores ingresos por videojuegos no era Sony, Microsoft o EA: el primer lugar se lo lleva Tencent, un conglomerado chino que ofrece servicios de desarrollo de redes sociales, portales de sitios web, comercio electrónico, juegos en línea y servicio de mensajería instantánea.

En el caso mexicano, el artículo Video Games Around the World: Mexico, de los autores Humberto Cervera y Jacinto Quesne, nos presenta un excelente resumen de la historia del videojuego en México, que forma parte de un compendio relacionado a esta industria alrededor del mundo. De acuerdo a la publicación, en la actualidad existen alrededor de 75 compañías dedicadas al desarrollo de juegos de video en nuestro país, y unas 50 tienen desarrollos en marcha. Algunos ejemplos incluyen Artefacto Studio, Larva Game Studio o KaraoKulta Games. Sin embargo, como es de esperarse, estas compañías sólo han ingresado al mercado móvil, que aunque es muy lucrativo, dista mucho del mundo de las grandes ligas. Como bien se menciona al final del artículo, “Esperemos que dentro de una década podamos volver a leer esto y seamos testigos de cómo la industria ha crecido, pero en este momento (verano de 2013), lo único que podemos hacer es trabajar duro y seguir adelante, juntos. Sólo entonces tendremos una industria mexicana relevante a nivel internacional. Hace diez años, nadie habría pensado que esto era posible. Así que tal vez, estamos a punto de despertar a un gigante.”

h1

Suites de Gestion de Procesos de Negocio de Codigo Abierto: el caso Mexicano

03/28/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

[Se ha estimado] que el proceso de negocio como servicio (BPaaS) y el mercado de BPM en la nube crecerán en valor desde USD 1 mil millones en 2013 hasta 7,120 millones de dólares en 2018.

The next evolution of BPM. Lance Harris. (Business Technology News and Information, 2013).

Hace algunas semanas nuestro country head me encargó encontrar los BPMS (Business Process Management SuitesSuites de Gestión de Procesos de Negocio) de mayor uso en México, y si entre éstos existe una opción basada en código abierto lo suficientemente competitiva como para incluirla dentro de nuestra oferta de servicios. Los resultados se obtuvieron en su mayoría a partir de información encontrada libremente en la web, por lo que me es posible compartir una buena parte de éstos:

Esta investigación presenta las opciones más utilizadas para el software de código abierto con respecto a Business Process Management Suites (BPMS) en México. Los resultados se presentan tomando en cuenta que el software BPMS es poco utilizado en México y el resto de América Latina. El conjunto de opciones mostradas a continuación está pensado principalmente con la finalidad de fomentar la evaluación de opciones de código abierto durante la generación de nuestras propuestas de solución y servicios. Se entiende que el mercado de software, especialmente la rama de código abierto, es un entorno de desarrollo muy dinámico y las opciones que figuran en este documento pueden quedar obsoletas rápidamente. Aun así, esta lista tiene como objetivo ser de utilidad para los clientes potenciales que consideren el código abierto como una opción, y para ayudar a darle mayor credibilidad y seguridad a nuestras propuestas.

Contexto

Típicamente, los beneficios del software de código abierto incluyen precios más bajos de adquisición, bajos o nulos costes de licencia, interoperabilidad, así como integración y personalización fácil de implementar; menos barreras para la reutilización, conformidad con los estándares abiertos de tecnología y datos que dan autonomía sobre su propia información. Finalmente, proporciona la posibilidad de no tener que “casarse” con un proveedor determinado.

El código abierto es poco o en absoluto utilizado en las organizaciones mexicanas de gran tamaño. Los integradores de sistemas y fabricantes no consideran al software de código abierto para sus soluciones de TI. Esto se puede demostrar en el Cuadrante Mágico de Gartner para BPMS (2010):

pic: Magic Quadrant for Business Management Suites (Oct 2010)

Cuadrante Mágico de Gartner para suites de gestión de procesos de negocio (Octubre 2010). (Fuente: avoka.com)

De entre 27 opciones diferentes, sólo una (Intalio) es de código abierto. Éste cae dentro del grupo de visionarios.

Hay importantes obstáculos al código abierto en México. Algunos de ellos incluyen una falta de una orientación clara para su adquisición, resistencia por parte de los proveedores, preocupaciones sobre las obligaciones de licenciamiento y – desde que el TLCAN comenzó su existencia hace más de 20 años – el tema de las patentes, malos entendidos acerca del proceso de acreditación de seguridad y mitos alrededor de la calidad y el soporte técnico del código abierto.

Cómo interpretar este documento

Este documento presenta el software de código abierto para ser considerado en nuevas soluciones BPM que cumplan con los requerimientos del negocio, o como sustitutos de software propietario ya existente. Se ofrecen varias opciones sobre la base de las implementaciones ya liberadas en el mercado mexicano hasta marzo de 2014. Este conjunto de opciones se puede utilizar para:

• Informar durante el diseño de nuevas soluciones de TI.

• Sugerir oportunidades de TI de servicios o soluciones nuevas.

• Retar propuestas de solución que no utilicen las tecnologías de código abierto.

El criterio general para que un software de código abierto sea listado entre las opciones sugeridas es que debe existir una oportunidad real para su uso. Un uso significativo y probado es un factor clave, en el que “probado” puede significar:

• Uso a gran escala, volumen o en escenarios de alto rendimiento.

• Uso en funciones críticas, tales como salud o seguridad.

• Historial de uso, de preferencia durante muchos años.

Uso de los BPMS

La mayoría de los proveedores de BPMS proporcionan análisis de procesos, diseño y herramientas de modelado de flujos de trabajo dentro de sus suites.
Por otro lado, la mayoría de las organizaciones optan por invertir en BPMS porque necesitan apoyo para un programa de mejora continua de procesos, el apoyo a un proyecto de transformación de negocios, y/o el middleware necesario para implementar una arquitectura orientada a servicios (SOA). Las organizaciones también pueden buscar adoptar un BPMS para guiar el proceso de implementación de una solución de procesos específica.

Las soluciones BPM han sido adoptadas principalmente por los organismos financieros, donde la visibilidad y la adherencia a las regulaciones de cumplimiento son una parte integral de este sector (por ejemplo, la ley Sarbanes-Oxley). BPM también se ha aplicado en las organizaciones de servicios donde la productividad y la eficacia del personal desempeñan un papel clave en el rendimiento del proceso. La mayoría de las organizaciones deciden adoptar BPM porque prevén que los cambios en sus procesos se producen con frecuencia. Sin embargo, muchas organizaciones también están comenzando a ver más allá de BPM como un simple documentación y rastreo de procesos, considerándolo como una oportunidad para transformar su negocio, mejorar los procesos y reducir costos.

Adopción de los BPMS

La mayoría de las herramientas y software de BPM utilizados hoy en día son productos comerciales caros. El mercado está siendo liderado por IBM (Lombardi) y Oracle (Oracle BPM 11g), acaparando más de la mitad de la cuota de mercado. Sólo un pequeño porcentaje (aproximadamente 15%) de las empresas en México han adoptado una solución de código abierto para BPMS. Estos están dirigidos por Intalio y jBPM de JBoss. Otros jugadores incluyen BonitaSoft, ProcessMaker y Activiti, que representan una pequeña fracción de la cuota de mercado. Estos tres son adoptados en su mayoría por organizaciones pequeñas y medianas (PYMEs).

BPMS Clientes
IBM Afore Banamex, CaixaBank, Financiera Independencia, GNP Seguros, AXA Seguros, Coca-Cola, Redpack, Telcel
Oracle AXA Financials, Banamex Gpo. Financiero, Bimbo, Comex, Nextel, Movistar, Cablemas, Televisa, Casas GEO
Intalio Sky, Santander, Samsung de México, Costco, Sears de México, DHL
JBoss jBPM BBVA, Toyota, Grupo Posadas
BonitaSoft DirecTV, Xerox (gestión de documentos)
ProcessMaker Banregio, Mexbrit, Lenovo LatAm
Activiti CONACyT (Gobierno Mexicano)

Principales clientes de las suites BPM más utilizadas en México. Los clientes fueron obtenidos de las páginas web de cada proveedor.

Por qué código abierto y cuáles son los retos para su adopción

Antes de cualquier otra consideración, el principal motivo de adopción de una solución de código abierto u open source consiste en los costos de licenciamiento y servicios profesionales necesarios para su implementación. Los productos comerciales se encuentran en el orden de USD 250,000 por implementación, generalmente a través de pagos por adelantado. Por el contrario, las herramientas BPM de código abierto están atrayendo más atención en el mercado debido a los posibles ahorros en costos y términos de licenciamiento más flexibles. Los usuarios también pueden ampliar las prestaciones de los productos y su escalabilidad sin costes adicionales. En caso de que la solución requiera una personalización específica o corrección de bugs, es posible buscar la ayuda de un tercero o de la comunidad open source, en lugar de esperar los lentos tiempos de respuesta de los proveedores comerciales.

Los principales retos a los que se enfrenta cualquier adopción BPMS se enumeran a continuación:

• Fuerte dependencia de operadores que realizan sus tareas de forma manual, sin automatización ni flexibilidad para satisfacer las cambiantes necesidades del negocio.

• Falta de procesos y prácticas bien documentadas.

• Escasa colaboración en equipo; todo se hace a través de correo electrónico y llamadas telefónicas. Los documentos son almacenados en formato físico (hard-copy).

• Los proveedores actuales se centran en el departamento IT para proveer las necesidades de BPM de la organización; en realidad, BPM debería ser responsabilidad del área de negocios.

• Muchas organizaciones están centradas en datos (data-centric) en lugar de estar centradas en el proceso (process-centric).

• A menos que el cumplimiento normativo o de continuidad del negocio sean un factor, muchas organizaciones siguen un crecimiento orgánico, dejando la gestión de procesos en un segundo plano.

• Falta de confianza en BPM. Muchas organizaciones esperan resultados verificables en menos de 6 meses desde la adopción de BPM.

Principales Suites BPM Open Source

Intalio

Intalio es una plataforma de procesos de negocio de código abierto construido alrededor del modelador BPMN STP de Eclipse y el motor Apache ODE BPEL 2.0, ambos originalmente aportados por Intalio. La versión Enterprise proporciona los componentes necesarios para el diseño, la implementación y la gestión de varios procesos de negocio, tales como:

• BRE (Business Rules Engine – Motor de reglas de negocio).

• BAM (Business Activity Monitoring – Monitoreo de Actividades de Negocio).

• Portal.

• ESB (Enterprise Service Bus – Bus de Servicios Empresarial).

• ECM (Enterprise Content Management – Gestión de Contenidos Empresarial).

Intalio está disponible en varias ediciones, pero la versión relevante para este documento es la edición de comunidad libre (free community edition) de Intalio. Ésta se compone de dos módulos: Intalio Designer e Intalio Server. Intalio Designer permite el modelado de los procesos para ser eventualmente desplegados en el Intalio Server. Intalio Designer permite que modelos BPMN se conviertan en procesos BPEL ejecutables. De acuerdo a la filosofía de Intalio, el área de negocio podría generar, editar y ejecutar los procesos, sin requerir de un desarrollador técnico para traducir la visión de negocio en código.

JBoss jBPM

jBPM es una plataforma de código abierto para diferentes lenguajes de procesos ejecutables que van desde la gestión de procesos empresariales (BPM) hasta el flujo de trabajo para la orquestación de servicios. jBPM admite tres lenguajes de proceso diferentes. Cada uno de ellos está dirigido a una función y entorno específico:

• jPDL (lenguaje de definición de proceso propio de JBoss).

• BPMN 2.0

• Pageflow

jBPM genera todos estos lenguajes de proceso de forma nativa en la parte superior de la Máquina Virtual de Procesos (Process Virtual Machine – PVM). Así mismo, jBPM es independiente de las bases de datos, servidores y es integrable en otras aplicaciones (embeddable). Finalmente, esta suite es altamente personalizable – desde el punto de vista de los desarrolladores.

jBPM es modular. Funciona con el middleware empresarial de JBoss o cualquier otra plataforma de middleware que cumpla con la especificación Java EE. Está disponible a través de suscripciones que incluyen software certificado, soporte por industria, actualizaciones y parches, documentación y política de mantenimiento de varios años. El modelador es una aplicación Java estándar y no necesita un servidor de aplicaciones; las empresas que estén interesadas en jBPM pueden utilizarlo sin añadir más complejidad. Los formularios que pertenecen a los procesos modelados pueden implementarse como aplicaciones web o aplicaciones de escritorio (standalone) en Java.

Bonita Open Solution

Bonita BPM es un gestor de procesos de negocio de código abierto y suite de modelado de flujos de trabajo, creado en el 2001. El proyecto se inició en el Instituto Nacional de Investigación en Informática y Automática (Francia), para luego incubarse por varios años en el interior de la empresa informática francesa Groupe Bull. Desde 2009, el desarrollo y soporte de Bonita es realizado por Bonitasoft, una empresa creada específicamente para esta actividad.

Bonita consta de tres módulos principales:

• Bonita Studio: permite al usuario modificar gráficamente los procesos de negocio siguiendo el estándar BPMN. El usuario también puede conectar los procesos a otras piezas del sistema de información (tales como mensajería, planificación de recursos empresariales, administración de contenido empresarial y bases de datos) con el fin de generar una aplicación de negocio autónoma, accesible como un formulario web. Bonita Studio también permite al usuario diseñar gráficamente las formas que se mostrarán al usuario final con el fin de interactuar con el proceso. Por otra parte, el modelador permite al usuario empezar a trabajar con procesos diseñados con otros estándares y tecnologías como XPDL o jBPM. Se basa en Eclipse.

• Bonita BPM Engine: El motor de BPM es una API Java que permite al programador interactuar mediante programación de los procesos. Se basa en Hibernate.

• Bonita Portal: es un portal que permite a cada usuario final administrar en una interfaz parecida a webmail todas las tareas en las que él o ella está involucrada. El portal también permite que el propietario de un proceso pueda administrar y obtener informes sobre los procesos. Se basa en GWT.

ProcessMaker

ProcessMaker está diseñado estrictamente para las pequeñas y medianas empresas (PYMEs). Al igual que Intalio, ProcessMaker tiene la filosofía de que los usuarios de negocios y expertos en procesos que no tienen experiencia en programación puedan diseñar y ejecutar flujos de trabajo, así como automatizar los procesos de todos los sistemas. ProcessMaker tiene varios módulos con los que el usuario puede crear mapas de flujo de trabajo, formas de diseño personalizadas, extracción de datos de desde fuentes externas y otras características para generar y optimizar las operaciones de gestión del flujo de trabajo y de negocios:

• Diseñador de Mapa de Procesos

• Dynaform Builder (formularios personalizados para los procesos de la organización)

• Output Document Builder (diseñador de documentos de salida de proceso) / Gestión Documental

• Motor de reglas de negocio

• IDE para construcción de web services

• Gestión de usuarios

• Bandeja de entrada de casos

ProcessMaker posee una biblioteca en línea que proporciona plantillas de proceso que el usuario puede descargar y editar. La curva de aprendizaje también se puede reducir ya que el desarrollo puede basarse desde una plantilla ya construida y probada. Algunas plantillas de muestra incluyen:

• Solicitud de tarjeta de crédito

• Proceso de informe de gastos

• Solicitud de zonificación de distrito

Activiti

Activiti es una plataforma BPM de código abierto para un entorno basado en Java. Originalmente desarrollada por Alfresco, su código fuente se distribuye bajo la licencia Apache. Dentro de la plataforma Activiti BPM se encuentran los siguientes componentes:

• Modelado: Activiti Modeler, Designer y Kickstart

• Ejecución: Activiti Engine

• Gestión: Activiti Explorer, REST.

Activiti es soportada y desarrollada por varias empresas como SpringSource, Atos Origin, Signavio, Camunda y otros. Así mismo, la plataforma se puede integrar a mule, un popular ESB de código abierto, para la entrega de soluciones basadas en SOA. Su modelador soporta BPMN y jPDL; posee extensiones que permiten la integración con el middleware de JBoss.

Benchmark entre los diferentes BPMS

Finalmente, se presenta un comparativo de los diferentes BPMS, incluyendo los productos de IBM y Oracle:

BPMS Tipo Interfaz de Usuario Notación Workflows Binding
IBM Lombardi Workflow, Process Designer, ESB, ECM, Portal Todos BPMN BPEL J2EE, WSDL/WS
Oracle BPM 11g Workflow, Process Designer, ESB, ECM, Portal Todos BPMN BPEL J2EE, WSDL/WS
Intalio Workflow, Process Designer, ESB, ECM, Portal, BRE Web 2.0 BPMN WS-BPEL J2EE
JBoss jBPM Workflow, Process Designer Todos jPDL, BPMN, Pageflow BPEL WSDL/WS
BonitaSoft Workflow, Process Designer, Portal Java BPMN XPDL, BPEL J2EE
ProcessMaker Workflow, Process Designer, ECM Todos BPMN BPEL J2EE
Activiti Workflow, Process Designer Todos BPMN BPEL REST

Comparativo con las características de los BPMS más usados en México.

Análisis y recomendaciones

Para clientes pequeños con un gasto menor a USD 100,000 anuales dedicados a BPM, es recomendable adquirir un producto de código abierto. Dependiendo del requerimiento del cliente, puede utilizarse alguna de las opciones mostradas en el documento; sin embargo si el cliente tiene esperado un fuerte crecimiento en la demanda de su solución BPM, las mejores opciones son jBPM o Intalio, ya que ambos productos permiten conexión con plataformas de alta escalabilidad, incluyendo middleware y bases de datos comerciales. En el caso de jBPM, este producto permite utilizar la vasta gama de productos ofrecidos por Red Hat, mientras Intalio permite al cliente utilizar la Community Edition hasta que haya alcanzado la masa crítica necesaria para adquirir sus licencias. Basándose en una comparación a juicio de experto entre ambos productos, NO existe una clara ventaja competitiva de alguno sobre otro, por lo que dependiendo de las características del cliente variará el criterio de selección del BPMS a implementar.

h1

A qué dedica su tiempo un desarrollador

01/10/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

Los requerimientos cognitivos para la programación (ingeniería de software) son mucho más parecidos a los necesarios para componer música o pintar un cuadro, que aquellos para construir un puente o instalar una alcantarilla. La falsa idea de que los “geeks” somos aburridos, poco creativos y torpes implicaría que Mozart, Beethoven y Daft Punk también lo son.

Entonces, ¿por qué insistimos en medir el desarrollo de software como si fuera una ciencia de la ingeniería?

Hace un par de meses publiqué un post referente a las herramientas y tecnologías más usadas en el lenguaje de programación Java. Adicionalmente a la frecuencia con la que se emplean estas tecnologías, el estudio original también contiene un apartado relacionado a la productividad del personal IT. Específicamente, a qué dedica su tiempo un desarrollador. Los resultados son reveladores:

Actividad Descripción Tiempo Porcentaje
Generación de código Programando, codificando, desarrollando hacks 15 Hrs. 37.5%
Resolviendo problemas Debugueo, perfilamiento, tuning de desempeño 5 Hrs. 12.5%
Comunicación Juntas, chats, correos, teleconferencias 5 Hrs. 12.5%
Overhead técnico Compilando, desplegando, instalando hardware y software 4 Hrs. 10%
Estrategia Arquitectura, diseño, refactoring 4 Hrs. 10%
Ocio Twitter, Facebook, YouTube 3 Hrs. 7.5%
QA Generación de pruebas, revisiones de código 2 Hrs. 5%
Bomberazos Caídas de sistema, problemas de desempeño 2 Hrs. 5%

Desglose de actividades desempeñadas durante una semana de trabajo de 40 Hrs. (Fuente: zeroturnaround.com)

De acuerdo al reporte – que incluye a desarrolladores, arquitectos, sysadmins y QAs – el personal IT sólo pasa 26 horas a la semana (65% del total, o tan sólo 5.2 horas efectivas al día) desempeñando su función principal: generando código, resolviendo problemas, realizando tareas de estrategia y QA; el resto del tiempo lo dedica a actividades menos productivas como juntas, bomberazos y cierto grado de ocio.

Por otro lado, si estos parámetros son resultado de una encuesta global, es inevitable darse cuenta que el personal Latinoamericano es aún menos productivo, ya que nuestra cultura incluye distracciones como ir a la tienda de la esquina por unas papas o pasar por el café de las 4:00 al Starbucks local. Esto nos proporciona una buena idea de la productividad real de un desarrollador en nuestros países, ya que ésta puede disminuir a tan sólo 3-4 horas efectivas al día. Como resultado, muchas empresas de la región extienden sus horarios a 45 horas o más a la semana, agotando aún más a los recursos y a largo plazo, impactando su productividad.

Las causas organizacionales de una baja productividad

¿Por qué cuidar la productividad del personal IT? La respuesta es simple: dinero. El factor más importante en el desarrollo de software son los desarrolladores, mientras que el ambiente de trabajo tiene un profundo impacto en la productividad y calidad, como veremos más adelante. Por ello, es necesario hacer ajustes en ambos para maximizar el retorno de inversión: un desarrollador es un empleado caro con un mejor salario que el del promedio de otros trabajadores de oficina. Considerando los tiempos de desarrollo, tiene sentido mejorar su eficiencia y productividad, pues una mala calidad y fechas de liberación erradas terminan en marchas forzadas, cacerías de brujas y ultimadamente, un mayor costo para la organización.

Ahora bien, ¿qué puede hacer la empresa para incrementar nuestra productividad? Muchos jefes creen que bloqueando internet mejorará el desempeño de sus empleados. Sin embargo, esto no puede estar más alejado de la realidad: de acuerdo a varios estudios, al navegar por la red obtenemos el descanso y relajación necesarios para mejorar nuestro estado de ánimo, incrementando nuestra productividad. Por supuesto, sitios pornográficos o con material ofensivo deben ser filtrados, pero una empresa sin acceso a Stack Overflow sólo significa que top management no tiene idea de lo que está haciendo.

En realidad, existen otras maneras de destruir la productividad de la gente IT que pueden clasificarse en básicamente cinco categorías:

1. Las manzanas podridas. En esta categoría tenemos programadores con pésima actitud, hombres orquesta con egos más grandes que la deuda externa y narcisistas que insisten en achacar a otros los errores de su propio código. En algunos casos, es posible corregir el rumbo al delimitar responsabilidades, tener una estrategia de capacitación y una intervención real de recursos humanos que ayude a retenerlos y resolver temas de comportamiento. Aunque, más a menudo de lo que se cree, la mejor opción es deshacerse de las manzanas podridas antes de que echen a perder el resto del barril.

2. Overhead administrativo. Juntas de avance maratónicas, parálisis por inboxes saturados, así como los procesos mismos para medir el desempeño – reportes de actividades, reportes de horas, procesos de control al estilo RUP – dañan más a la productividad de lo que Facebook o Twitter jamás podrán lograr. Aunque la respuesta a este problema yace en la cultura organizacional (tradicional vs. ágil, esclavos de la metodología vs. interpretación pragmática), es una buena idea generar una retrospectiva o análisis FODA para darnos cuenta dónde estamos fallando, ya que la perfección se alcanza, no cuando no hay nada más que añadir, sino cuando ya no queda nada más que quitar.

3. Mala administración. Dos de los peores infractores son aquellos gerentes que no tienen ni idea de TI y cuya única aportación es reenviar correos, o esos managers que recientemente fueron desarrolladores, perdiéndose constantemente en los detalles en vez de tener una visión general del proyecto. En este caso vale la pena ayudar al manager a mejorar sus habilidades, ya sea mediante coaching, revisión por pares o cursos gerenciales. En un peor escenario, habrá que dejarlo “buscar nuevas oportunidades”, pero sólo si hemos buscado ayudarlo sin resultado alguno o ya es un tema de actitud – recordemos que hay estudios demostrando una importante cantidad de sociópatas en las posiciones de medio y alto nivel gerencial.

4. Ambiente de trabajo y dinámica de grupo. Si el ambiente no es propicio para la concentración requerida o el equipo de trabajo no tiene afinidad cultural (programadores vs. testers), se perderá mucho tiempo debido a interrupciones o falta de comunicación. En las metodologías ágiles esto se resuelve al dejar a todo el equipo aislado del resto de la organización, por ejemplo, en una sala de juntas. De la misma manera, los integrantes deben sentirse a gusto con sus demás compañeros al encontrar un tema de interés mutuo, el cual debería ser en la mayoría de los casos, la satisfacción del cliente.

5. Problemas técnicos. La deuda técnica, demasiados requerimientos de documentación o uso de software con pobre documentación, desarrollos que tengan que ver con sistemas legados o por el contrario, implementaciones con tecnologías inmaduras, implican cuantiosas pérdidas de tiempo en investigación, pruebas de concepto, lectura de más y más manuales así como re trabajo constante. Entre otras opciones, es necesario considerar el tiempo dedicado a estas actividades e incluirlo en el plan de proyecto. Así mismo, debemos asegurarnos que las incidencias sean resueltas tan pronto como vayan apareciendo, para evitar que la entropía se haga presente.

Con todo y todo, hasta este punto estamos asumiendo que el ambiente laboral no es tóxico o extremadamente burocrático, o que el personal vive lo suficientemente cerca del trabajo como para no llegar exhausto después de un recorrido de hasta dos horas. Pero, si buscamos quitarle cargas innecesarias a los empleados, estaremos dando un paso en la dirección correcta: hay pocas cosas que podamos hacer para incrementar la motivación y productividad de un desarrollador, pero sí que podemos hacer mucho para destruirla.

Nosotros también somos parte del problema

Así es: los sistemólogos tampoco somos el cuchillo más filoso de la cocina, pues tenemos malos hábitos que impactan nuestra propia productividad, incluyendo:

• Multitasking. La mayoría intentamos llevar a cabo varias tareas al mismo tiempo, como generar un entregable mientras checamos el correo y nos reímos ante la última actualización del 9GAG: ¿por qué creen que las configuraciones multi-monitor y el ALT + TAB se han vuelto tan populares? Multitasking es de hecho, una actividad que incrementa exponencialmente el tiempo necesario para terminar las tareas que podríamos realizar de forma secuencial, y aun así, insistimos con ello: ¿quién no ha visto ese video donde un tipo va caminando por la calle mientras textea con su móvil, sin darse cuenta que tiene enfrente a un oso? Una solución ante un problema tan común es simplemente, trabajar desconectado. Aplicar 25 minutos de furioso trabajo sin interrupciones para después relajarse por 5 minutos y caminar un poco, leer correos o checar el WhatsApp. Esto es de hecho, una recomendable técnica de administración del tiempo con serias bases en la neuropsicología.

• Cómo atacamos tareas “aburridas”. Hay actividades que NO son precisamente del agrado de nadie, como la documentación, reportes de horas o rastreo de incidencias. La mayoría de las personas se quedan estancadas realizando estas tareas, tomando más de lo que deberían. Una buena opción es darnos cuenta en qué momento del día somos más productivos y en qué momento “volamos en piloto automático”. Por ejemplo, si somos del tipo matutino, debemos dejar por la mañana todas las actividades que requieran concentración, dejando para la tarde – usualmente después de la hora de la comida – las tareas más bien repetitivas que requieren poco “cerebro”. Si aun así nos cuesta trabajo, podemos escuchar música que nos ponga en el modo correcto: la instrumental es la más recomendada por los expertos; el ritmo de nuestra selección define qué tan energéticos o relajados nos sentiremos (por ejemplo: dance vs. chill-out).

• Que hacemos – o dejamos de hacer – con las interrupciones. Si no es posible mudarse a una sala de juntas, podemos adquirir unos audífonos anti ruido. Existe una menor probabilidad de ser interrumpidos por ruidos medioambientales y automáticamente estamos dando una señal de “no molestar”. Si es factible negociar un horario flexible, es conveniente trabajar algunas horas extra el lunes y martes, que son los días en que usualmente tenemos más energía y mejor actitud, compensándolas saliendo un poco más temprano el resto de la semana. Por ejemplo, trabajar 12-14 horas el lunes puede significar sólo trabajar hasta el mediodía del viernes.

• Juntas. Si hay algo que atormenta a la mayoría son las juntas innecesarias. Es necesario evitarlas a toda costa, aunque tarde o temprano tendremos que asistir a una. De acuerdo a los especialistas, debemos buscar calendarizarlas a las primeras horas de la mañana, cuando la mayoría tiene más energía. Sin embargo, se supone que el martes a las 3:00 PM (justo después de la comida) es cuando casi todos tenemos un pico máximo de atención. Si el objetivo es llegar a un acuerdo rápido o se trata de reuniones de alto nivel, al tenerla poco antes de la hora de salida lograremos el efecto deseado, ya que a nadie le gusta quedarse después de las 6.

Es un hecho corroborado por varios estudios, que los mejores programadores son hasta 28 veces más eficientes que los peores programadores. Esto se debe entre otras cosas, a que toman ownership del proyecto, generan más código con menos incidencias, escriben estructuras mantenibles y hacen más con menos. Por ello, vale la pena leerse valiosos ejemplares como Beautiful Code o The Pragmatic Programmer y luego poner todo en práctica: en el mercado laboral actual, un “programador promedio” gana alrededor de US$23,800 anuales, mientras un superstar alcanza los US$30,200. Esto significa una diferencia de más del 26%.