3006
2016
Software Project Management

Frameworks corporativos

No es la primera vez que me encuentro ante un nuevo proyecto en el que el cliente te exige utilizar ciertas tecnologías para sus desarrollos internos. Se trata de una compañía que tiene su propio departamento para satisfacer las necesidades software de la empresa (web corporativa, intranets, canal de pedidos, gestión de tickets e incidencias, etc.); ahora necesitan externalizar algunos trabajos.

No es que usen esas tecnologías porque sí, sino que es la misma política de empresa la que en su día decidió apostar por ellas y no salir de ahí salvo por un motivo bien justificado. De ese modo, todas las aplicaciones internas tienen cierta coherencia.

Esa decisión puede ser muy arriesgada: ¿y si basamos todos los desarrollos en este motor de base de datos que termina cayendo en desuso o cuya licencia sube de precio escandalosamente? ¿Y si usamos este framework para las interfaces de usuario web y con el tiempo surgen otros mucho mejores y productivos?

¿Acaso alguien tiene una bola de cristal y puede predecir las necesidades de la empresa a años vista? Puff...

Trabajar realizando proyectos software que deben tener una vida muy larga es en ocasiones gestionar muchísima incertidumbre en cuanto a la elección de las mejores tecnologías para ese proyecto.

Yo lo digo a menudo, y no me cansaré de repetirlo: es casi más importante usar bien una librería o framework que usar todo lo último porque sí

Por poner un sencillo ejemplo, me encanta Angular, es increíblemente productivo y te permite desacoplar muchos elementos de las interfaces de usuario para poder crear tests sobre ellos. Sin embargo, la nueva release Angular 2 es un mundo aparte en relación a la anterior versión y por tanto, si has hecho algo en los últimos años con Angular 1.x, pues ya sabes que o tendrás que continuar con ello mucho tiempo o tienes que plantear una migración, si te interesa, a la nueva versión. Y cómo no, desde el punto de vista empresarial, esa migración cuesta dinero...

Si el éxito de una compañía consiste, en parte, en mitigar y reducir riesgos, entonces definir el conjunto de tecnologías que usa para sus desarrollos internos puede tener sentido. Este enfoque no es único para grandes corporaciones, de ningún modo, cualquier organización de cualquier tamaño puede implementar esta política.

1504
2016
Coaching para desarrolladores de software

Principios sólidos

No, no voy a hablar de nada relacionado con los principios de desarrollo S.O.L.I.D., que, en cualquier caso, recomiendo a cualquier programador conocer en profundidad y, sobre todo, ponerlos en práctica.

En los últimos meses he tenido que leer bastante documentación sobre licitaciones y también he estado inmerso en propuestas de nuevos proyectos en colaboración con otras compañías.

En esas licitaciones, algunas para gobiernos autonómicos de mi país, llama la atención la falta de rigor en las especificaciones. Es más, concretamente en alguna se indicaba que "las tareas a realizar se plantearán con exactitud cuando el proyecto sea adjudicado al licitante". En otra, decía que el licitante debía adaptarse a las metodologías de trabajo más comunes, y mencionaba CMMi, Métrica 3, etc. En fin...

Al mismo tiempo, la mayoría de esos proyectos consisten en evolucionar aplicaciones que ya están funcionando en consejerías o departamentos de esas regiones.

¿Cómo poder estimar el esfuerzo para evolucionar algo sin ver su estado actual? ¿Estará la solución hecha unos zorros? ¿Será el típico proyecto espagueti o en cambio todo se habrá hecho con conciencia, mejoras continuas, limpieza de código, etc.?

Miedo me da encontrarme con algo así. 

En esos proyectos se hablaban de tecnologías que ya existían hacer quince años y que siguen muy presentes aunque bajo revisiones más recientes.

En otro, que no tiene nada que ver con los anteriores, se hablaba de trabajar a muy bajo nivel con cierto tipo de dispositivos, empleando el protoloco DLMS.

Y para variedad, estoy trabajando como colaborador externo para una magnífica compañía nacional, líder en su sector, y de nombre Altafonte. Utilizan un sistema basado en PHP, base de datos MemSQL, etc. A sus desarrolladores los considero unos héroes, por haber sabido avanzar en la solución, la base y el core de su negocio, mientras éste crece con multitud de nuevos requerimientos continuamente.

Pensando en todos esos proyectos, ¿qué es lo que pueden tener en común?

1202
2016
Coaching para desarrolladores de software

¿Requisitos? ¿Y eso qué es?

Question woman

Este es un tema tan manido en nuestra profesión, tan pesado, pero al mismo tiempo tan importante, que seguimos años y años hablando de lo mismo y sufriendo las mismas consecuencias una y otra vez.

¿Están bien especificados los proyectos? ¿Se parte de un grupo de requisitos suficientemente amplio? Es cierto que en software ágil ya se da por sentando que los requisitos pueden cambiar, porque de hecho cambian, es lo natural, pero lo hacen a partir de entregas, y esto es bueno y es precisamente lo que resuelven de manera magnífica todas las prácticas y principios de lo ágil.

Sin embargo, el peor vicio de nuestra profesión consiste en no saber o no querer esforzarse lo suficiente en establecer correctamente un documento con el catálogo de requisitos o especificaciones que indiquen qué es lo que hay que hacer. Es de sentido común dejar claro lo que el cliente quiere, ¿no?, sin embargo...

Muchas veces, el que tiene que tomar los requisitos, no sabe cómo hacer ese trabajo, me temo, pero en otras ocasiones, es la pura pereza de hablar con el cliente lo suficiente lo que impide que el equipo del proyecto sepa con más exactitud lo que hay que desarrollar.

Existe una ley universal que deberíamos tener siempre presente:

Cuanto más esfuerzo se dedica a especificar, menos tiempo se emplea en el desarrollo del proyecto.

Esto es una obviedad, una sandez decirlo, pero en el día a día, metidos en la vorágine del trabajo, reuniones, visitas, etc. se nos suele olvidar este principio.

Así de sencillo, así de simple. 

0701
2016
Coaching para desarrolladores de software

Cuidado con lo que lees...

"...no vaya a ser que cambie tu modo de pensar". Leí una vez en un libro de esos de desarrollo personal.

Comienza el año y después de tanto Rosco de Reyes (dulce típico en España y que pone fin a las navidades), te das cuenta de que ya es enero, vuelves al trabajo y esa enorme lista de propósitos y proyectos que alegremente hacías en diciembre, ahora la tienes delante y es hora de empezar a hacer cosas.

O sea, lo de siempre, comienza el camino para que al final del año, si nos seguimos acordando de esa lista, nos demos cuenta de que no hemos conseguido ni la mitad de la mitad. Es más, yo creo que esas promesas de mejora para el nuevo año entrante son más bien un tirar hacia delante y una excusa para justificar lo difícil que nos resulta actuar y hacer lo que debemos y queremos hacer. ¿O no?

Vale, sí, yo soy el primero que uso esas listas, las uso desde hace mucho con mayor o menor éxito. Uno de mis propósitos para este año se seguir leyendo más y mejores libros de todos los temas que me interesan, muchos de ellos de tecnología, otros de desarrollo personal, etc. 

¿Es que puede ser de otro modo? ¿Puede existir cualquier negocio o profesión que no avance sin seguir aprendiendo? Todo evoluciona, si no lo hacemos al mismo ritmo que todo lo demás, podemos terminar intentando vender algo a clientes de un mercado que desapareció o se transformó hace mucho.

2412
2015
Coaching para desarrolladores de software

Green Kiwi Games

Green Kiwi GamesGreen Kiwi Games © es un proyecto en el que he ido trabajando muy poco a poco en los últimos meses y que constituye lo que se llama un producto mínimo viable (MVP), esto es, un producto o proyecto que muestra la esencia de algo y que se expone para validar su propuesta de valor (o sea, si a la gente le resulta útil o no).

Si una cosa he aprendido en los últimos diez años, y no exagero, es que tu día a día como profesional termina reduciendo tus habilidades a un conjunto de tecnologías, las que usas lógicamente en la compañía para la que trabajas. Y esto no es bueno más aún cuando el cambio en nuestra profesión es vertiginoso. No obstante, en tecnología en general y en software en particular, las posibilidades son tremendas y la cantidad de tecnologías consolidadas y stacks maduros que existen te obligan a tener que estar al día si en unos años no quieres estar más obsoleto que el T-800 de Terminator.

Pues bien, Green Kiwi Games ha sido para mí la forma de profundizar en el stack MySql+Express+AngularJS+Nodejs (lo que se suele llamar MEAN, pero en esta ocasión sin MongoDB...).

Ya he hablado en alguna ocasión brevemente sobre cómo enfocar proyectos de emprendimiento desde el punto de vista del software, campo en el que he tenido mis éxitos pero también mis fracasos. Es un tema muy amplio y lamentablemente muchos proyectos fallan no por falta de una idea que pueda funcionar, sino por la ejecución del mismo proyecto y falta de disciplina para llevarlo a cabo en el tiempo. Buena ejecución, tenacidad y disciplina en el trabajo, esta es la receta en mi opinión.

En cualquier caso, todo parte de una idea que termina siendo lo que nos anima a seguir adelante porque de algún modo creemos en ella. Ahora bien, ¿cómo saber si los demás también la ven útil? Desde luego no es contándola, sino creando algo que lo muestre, algo que se pueda tocar y evaluar. De ahí lo del producto mínimo.

Pero, ¿cómo surgió la idea y qué es Green Kiwi Games? Pues bien, hace un tiempo me encontré con ciertas personas que hacían por su cuenta juegos de cartas, pero con un esfuerzo tremendo al no dominar ninguna herramienta informática y de forma totalmente manual. ¿Por qué no habilitar una web en donde el usuario subiera las imágenes y que la aplicación web se encargara de generar un pdf con las cartas listo para impresión? Sencillo, nada de otro mundo. Una idea, para ser buena, se tiene que poder explicar con muy pocas palabras. La innovación no trata de generar productos cercanos a la ciencia ficción, en cosas sencillas y banales se puede innovar también; es más, la mayor parte de la innovación pertenece a este último grupo. Tendemos a mitificar la innovación.

Eso es Green Kiwi Games, un sencillo portal que le permite a un usuario crear juegos de cartas de manera muy fácil, casi a golpe de clic. En un mundo en el que va dominando el do-it-yourself, descubrí auténticas comunidades dedicadas a hacer juegos de cartas personales y de distribución fuera de los canales habituales comerciales.

Si embargo, no hay dos sin tres, de modo que aproveché este mini proyecto para meterme de lleno en tecnologías que me apasionan, de modo que puedo decir que he pasado por todos los elementos que debe dominar un full-stack-developer y que describo a continuación.

0611
2015

Consideraciones acerca de la seguridad informática

Software security

Hace unos meses leíamos sorprendidos la noticia de que un grupo de estudiantes francés había descubierto miles de bases de datos MongoDB con acceso público y abiertas, no por alguna vulnerabilidad en ese engine de base de datos, sino por malas prácticas de quienes las habían implantado. Terrorífico si se piensa por un momento; puede parecer anecdótico pero el fondo de la cuestión es que la información de esas bases de datos podrían poner en situación de vulnerabilidad a personas, instituciones e incluso países. Sin llegar a exagerar, ese caso probablemente no sea más que un gota en el océano.

Admitámoslo: cuando se trabaja desarrollando proyectos, casi siempre terminan entregándose con presión de tiempo y dejando una larga estela de TO-DOs y de elementos que se podrían mejorar. Es más, pocos clientes, sobre todo si son de ese tipo que no entienden demasiado de tecnología porque su negocio o actividad es otro, ignoran cómo evaluar la calidad de lo que se les entrega: mientras funcione y lo que ven les guste, no habrá problemas, todos contentos, nosotros hemos entregado un proyecto, la compañía lo habrá cobrado y a otra cosa.

Cuando hablamos de software, hablamos de un medio que permite que otras actividades funcionen: la gestión documental de una compañía, el blog de un freelance, al firmware de una lavadora o un sistema Scada que gestiona una central térmica.

Sin embargo, ¿existe realmente interés por encarar la seguridad en el contexto de cualquier proyecto software sea del tipo que sea? No estoy hablando de software para aeronaves, plantas nucleares, etc., sino aplicaciones de cualquier tipo realizado por cualquier empresa para clientes no excepcionales (que, por otra parte, intentan pagar lo menos posible).

Esto es lo que quiero decir: la seguridad informática apenas es un aspecto relevante para la mayoría de desarolladores de software, y es así no porque ignoremos técnicamente cómo afrontar esos temas, sino porque en general no existe una cultura tecnológica extraordinariamente preocupada por exigir consumir software con todos los estándares de seguridad. La ciberseguridad sigue siendo más un término de películas de ficción que una auténtica preocupación masiva en toda nuestra industria.

Tanto si se trata de un simple proyecto que de ser vulnerado puede tener poca o ninguna repercusión, hay muchos otros proyectos para los que cualquier incidencia de seguridad puede ser un auténtico problema: desde la pérdida de horas de trabajo y una enorme frustración para la gente afectada hasta la seguridad física de personas e instalaciones. Y no exagero, en absoluto: por poner un ejemplo, uno de los productos que comercializamos en la compañía para la que trabajo puede dejar literalmente sin luz a miles de abonados de compañías eléctricas. ¿Y si alguno depende de un soporte vital? Es un tema bastante serio que conviene no frivolizar.

La seguridad es importante, extraordinariamente importante, sobre todo en un momento en que toda nuestra economía no sólo es adicta al petróleo sino que también depende de la tecnología para seguir funcionando. Para muchas plataformas, una hora sin funcionar puede significar mucho dinero (aparte de dar una imagen poco profesional), pero también para una pequeña web de una empresa familiar puede suponer muchas horas perdidas para resolver el problema.

Digo yo que para tratar mejor el tema de la seguridad en nuestros trabajos debemos tener también cierta faceta de hackers y actuar como pentesters.

2710
2015
Software Project Management

Mejorando cuando se trabaja en proyectos

Project Planning PictureEsta es la realidad: la mayoría de los desarrolladores y gestores trabajamos en proyectos para un cliente específico final. Es decir, hay un cliente que genera unas especificaciones y un equipo que las desarrolla (en el mejor caso esos requisitos están claros al principio aunque lo habitual es que no lo estén).

¿Pero es que puede haber otra cosa? Claro que sí, no tiene absolutamente nada que ver la dinámica de trabajo en un proyecto que la dinámica de desarrollo de un producto software.

Ya he hablado en alguna ocasión sobre esta cuestión, pero ahora quiero enfatizar qué aspectos en el desarrollo de proyectos se deben cuidar mucho para evitar que tanto los equipos de trabajo como la misma compañía caigan abrumados bajo el peso de multitud de proyectos mal gestionados y mal cotizados.

El desarrollo de un proyecto está lleno de detalles y todos cuentan: el resultado final es un conjunto de aspectos que se han ido haciendo suficientemente bien, como en cualquier otra actividad profesional. Si descuidamos algunos, se notará en el resultado final. Sencillo de entender, ¿no?

Recientemente he visitado una empresa en la que he visto que se dan algunas de estas circunstancias: gente con ganas de hacer las cosas mejor pero agotadas de las guerras del día a día en que no hay tiempo de pararse un momento y ver qué no funciona o qué se puede mejorar. No hay que ser muy listo para evidenciar qué se está haciendo mal o qué impide que las cosas avancen mejor, el problema es que tú puedes pensar algo pero tiene que ser el gestor del equipo, sus jefes o el responsable de la compañía el que ponga los medios para que la gente trabaje correctamente y decida también cambiar cómo se hacen las cosas. Esto también es algo típico: la incapacidad de ver que los resultados dependen de eso...

Y no sólo se trata de disponer de la infraestructura mínima necesaria, también de mantener una disciplina metodológica en la forma en que se decidan hacer las cosas. Yo creo que no hay más, lo difícil realmente es seguir esa disciplina y los procedimientos establecidos.

Surver Monkey Logo

He creado esta pequeña encuesta sobre los puntos que vamos a ver a continuación.

1610
2015

South Summit 2015

South Summit 2015 logo

El pasado 7 y 8 de octubre estuve en uno de los mayores eventos sobre start-ups del sur de Europa, el South Summit, en un auditorio un poco peculiar (la Plaza de Toros de Las Ventas de Madrid). Vinieron muchísimos asistentes de todas partes del mundo y la agenda estaba cargada de interesantísimas charlas con actores de primer nivel, tanto de empresas muy conocidas como inversores de capital riesgo y business angels.

Si bien había empresas ya consolidadas y starts-ups de muchos tipos distintos, la mayoría tenían una base tecnológica que, de una manera u otra, incorporan el software como pieza fundamental. Todavía me preguntan si las ciencias de la computación tienen futuro o no.

Me llamó mucho la atención algunas colas que vi en algún momento de gente que iba a presentar sus proyectos a inversores con el típico pitch que no puede durar más de unos pocos minutos.

Estuvieron desde la deslumbrante Gwynne Shotwell de SpaceX hasta Adeyemi Ajao, actualmente en Workaday y que fue uno de los fundadores de Tuenti (el Facebook español), pasando por Paul Ford de Sendgrid y Jeroen Merchiers de Airbnb, que dio una interensantísima charla de título "Disrupting Markets: The Sharing Economy" junto con muchísimos otros de areas y mercados distintos. 

Gente inspiradora que sin duda tienen muchos fracasos detrás para conseguir cualquier éxito.

Quería hablar un poco de mi experiencia asistiendo al South Summit, pero también reflexionar por qué debemos incorporar en nuestra agenda el salir de la oficina de vez de en cuando para asistir a charlas o reuniones profesionales.

2409
2015
Coaching para desarrolladores de software

Contratando a los mejores (y cómo no reinventar la rueda)

Productivity

Me encanta prototipar, probar conceptos, ideas y ponerlas en marcha sencillamente para validarlas o por profundizar en tecnologías que me gustan. Esto creo que es uno de los vicios de muchos desarrolladores, la necesidad sana de aprender cómo funciona tal framework, cómo desplegar con Heroku o cómo funciona el mecanismo de plugins de cualquier software, por poner algunos ejemplos.

Ahora bien, si queremos probar una idea no podemos perdernos en los detalles y desviarnos así del asunto relevante que queremos conseguir. No obstante, veo lo fácil que es perderse en esos detalles y no centrarse en lo importante realmente, lo que aporta valor al proyecto, producto o idea que estamos probando.

De ahí el conocido mantra en nuestra profesión de poner el foco completamente en la funcionalidad particular de un proyecto de modo que la general debe ser cubierta por el entorno a usar en forma de librerías reutilizables, plugins, extensiones, plantillas, etc, cualquier cosa, en definitiva, reutilizable.

Es como si se nos planteara realizar una plataforma para la gestión empresarial y decidiéramos hacerlo todo desde cero y no contar con algunos de los productos que ya existen como base en el mercado. Sería, cuanto menos, inviable en términos de tiempo y esfuerzo.

Sin embargo no siempre pensamos en adquirir alguna solución de tipo comercial ya existente y comenzar a partir de ella y, de nuevo, caemos en el error de reinvertar la rueda una y otra vez, sin evaluar realmente el coste de esto. Una cosa es investigar e implementar por simple gusto o curiosidad en tu tiempo libre y otra muy distinta justificar decisiones en tu compañía que supongan costes extra que se pueden evitar.

Vicio, mala práctica o pura ignorancia, este es uno de los déficits habituales de muchos desarrolladores que, además, es de camino inverso: no saber seleccionar componentes del mercado o de código abierto y también no saber desacoplar lo suficiente lo que se hace para reutilizarlo en un futuro.

1009
2015
Coaching para desarrolladores de softwareSoftware Project Management

¿Es tu jefe un buen gestor de proyectos software?

La pregunta de este post es algo típica pero no menos importante; recientemente leía que en un 70% de los casos de gente que abandona su empleo, en realidad están huyendo de sus jefes. Lamentable, sobre todo porque un buen profesional se puede echar a perder si no se rodea del equipo adecuado, pero, en especial, de un jefe (manager o coordinador) que haga bien su trabajo. También oí una vez decir a Sergio Fernández que uno tiene que poder elegir a su jefe. Sea así o no, la realidad es que un mal gestor puede hacerte la vida imposible y uno bueno puede hacer que vayamos a la oficina con una motivación extraordinaria.

Entre otras cosas, dirijo equipos de desarrollo desde hace mucho tiempo y llevo años con la convicción de que un buen proyecto tiene éxito no sólo por la profesionalidad con la que se encara, también por el buen hacer de quien tiene ese trabajo de coordinar el de los demás.

Nunca me ha gustado la palabra jefe, ni manager (¿pero por qué en LinkedIn todo el mundo se etiqueta como manager de algo?), por sonarme demasiado a jerarquía o como si dentro de cualquier organización unas personas fuesen más importantes que otras. Cada uno tiene su papel y para que todo funcione, cada uno, individualmente, tiene que hacer el suyo de manera profesional. Sí, esto suena muy democrático y guay decirlo, no lo es tanto aplicarlo en el día a día. Esa idea de "todo vamos en el mismo barco", "el equipo es lo primero", etc. que tanto les gusta a los managers de medio pelo repetir, no siempre se traduce en acciones reales. Vamos, que una cosa es lo que se dice y otra muy distinta lo que se hace.

Pero, ¿en qué consiste en realidad ser un buen gestor?, ¿puede un proyecto con éxito considerarse como tal si el equipo de trabajo está quemado y el gestor es el que se lleva todas las medallas ($)?, esto último es tanto como decir que las empresas y compañías existen sólo para hacer dinero y generar beneficios. No, no sólo deben existir para eso, los beneficios deben ser una consecuencia de hacer las cosas bien y proveer de un trabajo de calidad a todas las personas que forman parte de esa organización. 

En cierta forma, un proyecto software tiene una naturaleza un poco especial a diferencia de otro tipo de trabajos, de modo que hay que conocer bien esos detalles diferenciadores para que todo vaya bien. 

¿Quieres mejorar como gestor? ¿Quieres evaluar a tu jefe y a lo mejor ponerlo a caldo? Pues sigue leyendo.

Páginas