Archivos de la categoría Management

Mi pequeña biblioteca técnica

Hoy voy a mostraros la pequeña colección de libros técnicos que he ido acumulando durante los últimos diez años. A tiempo pasado me he dado cuenta de que una gran mayoría de ellos no pintan nada ya en la estantería ya que son tecnologías desfasadas o superadas por nuevas versiones, tal es el caso, por ejemplo, de Visual Basic 6.0, Windows NT, Oracle 8i… Otros pueden servir aún como introducción general (Java2, SQL Server, MySQL, etc.), pero nunca serán un referente en sí mismos ya que están también “anticuados“. Bien es verdad, y considero importante puntualizarlo, que el grueso de mi biblioteca data del periodo 2000-2005, los últimos años apenas he comprado nada, Internet es, sin lugar a dudas, la biblioteca particular de todos nosotros. Mis últimas adquisiciones tratan temas más relacionados con la gestión (de proyectos, personas y negocios) que con la tecnología en sí misma, y es que estos últimos no pierden su capacidad de enseñanza, con los años siguen ahí para quien quiera consultarlos.

Estos son mis libros, agrupados, más o menos, por temática. Indico entre paréntesis el/los autor/es y la editorial, a continuación el año en que lo compré y una pequeña reseña del mismo.

  • Sistemas Operativos:
    • Guía completa de Microsoft Windows NT Server 4.0 (Russel y Crawlord, Mc Graw Hill), 2000. Con este y los dos siguientes aprendí todo lo relacionado con redes Windows, controladores de dominio, usuarios, etc. En su momento me fueron de muchísima utilidad e incluso gracias a ellos llegué a impartir formación sobre Windows NT, ha pasado mucho tiempo ya.
    • Windows NT 4.0 Server, instalación y gestión (J.M. Martínez y M. Martínez, Prentice Hall), 2000.
    • Windows NT Server 4.0 (Anaya Multimedia), 2000.
    • Linux Máxima Seguridad (Anónimo, Sams), 2002. En su momento me pareció una joya y me sirvió para profundizar y mejorar considerablemente mis conocimientos en temas de seguridad, auditoría e IDS en sistemas Linux. Aún sigo haciendo alguna consulta de vez en cuando.
    • El Libro Oficial de Red Hat Linux – Firewalls (Bill McCarty, Anaya Multimedia), 2003. Fundamental junto al anterior en mi formación sobre sistemas de red avanzados bajo Linux. También sigo echándole un ojo de vez en cuando aunque en Internet esté toda la información más que explicada.
  • Programación y lenguajes:
    • Teach yourself Java2 in 21 Days Second Edition (Lemay & Cadenhead), 2001. Un clásico. Con la primera edición aprendí Java allá por 1996. Con este libro recuperé mi formación en Java, importante en aquel momento.
    • Core Servlets and Java Server Pages (Marty Hall), 2002. Tras mejorar mis conocimientos de java con el anterior y junto al siguiente, aprendí todo lo relacionado con aplicaciones web en Java. En su momento me parecieron un par de libros fundamentales.
    • More Servlets and Java Server Pages (Marty Hall), 2002.
    • Creación de sitios web con XML y Java (Maruyama, Tamura y Uramoto, Prentice Hall), 2002. Lo compré a raíz de los anteriores, supongo que lo habría visto recomendado en algún lado, pero no recuerdo que me pareciese un libro impactante.
    • Learning Perl 3rd Edition (Schwartz & Phoenix, O’Reilly), 2002. Necesitaba algo de formación en Perl pero nunca llegué a leérmelo entero, más que nada porque nunca llegué a necesitar un nivel avanzado en Perl.
    • ActionScript con FlashMX Edición Especial (Prentice Hall), 2003. Sin duda otro libro básico en mi formación. Gracias a él aprendí todo lo relacionado con ActionScript, algo que me ayudó enormemente a dar el paso a Flex algún tiempo después.
    • Desarrollo de juegos con J2ME (Manuel J. Prieto, Ra-Ma), 2005. Un proyecto fracasado :P, en aquel momento tenía algunas ideas en la cabeza pero nunca llegué a leerme este libro.
    • Visual C#.NET (Fco. Charte Ojeda, Anaya Multimedia), 2004. No lo compré, llegó a mis manos por casualidad y tampoco hice nada con él.
    • Enciclopedia de Microsoft Visual Basic 6.0 (Fco. Javier Ceballos, Ra-Ma), 2000. Sin lugar a dudas fue básico en mi formación inicial allá por el año 2000. Hoy está completamente desfasado gracias a la tecnología .NET, pero en aquel momento era imprescindible. Creo que fue el primero de todos.
    • Programación de Active Server Pages (Hillier & Mezick, Mc Graw Hill), 2000. Gracias a este libro conseguí mi primer trabajo de programador web. Corría el año 2000 y comenzaba mi carrera profesional. Junto al anterior, fueron mis primeros libros.
    • XML (Óscar González, Anaya Multimedia), 2001. Cuando estaba aprendiendo Java, no recuerdo por qué, necesitaba conocimientos avanzados en XML y este pequeño libro de bolsillo me dio lo que buscaba.
    • WebServices (Joan Ribas Lequerica, Anaya Multimedia), 2003. Lo mismo que el anterior pero para WebServices, va al meollo del asunto sin complicaciones.
    • La Biblia ASP.Net (Mridula Parihar, Anaya Multimedia), 2009. Mi última adquisición. Por cuestiones profesionales he de ponerme las pilas con .NET, ahí lo tengo esperando :P.
    • The Pragmatic Programmer – From Journeyman to Master (Andrew Hunt & David Thomas, Addison Wesley), 2006. Fundamental para cualquier programador, todo lo que cuenta es completamente lógico y de cajón, tanto que muchas veces lo olvidamos todo.
    • The Unified Modelling LAnguage User Guide Second Edition (Booch, Rumbaugh & Jacobson, Addison Wesley), 2007. La biblia del UML.
    • UML y Patrones Segunda Edición (Craig Larman, Pearson – Prentice Hall), 2005. Empieza bien, pero me lo dejé a mitad, es bastante espeso. Espero retomarlo pronto.
    • The Zen of CSS Design (Dave Shea & Molly E. Holzschlag, New Riders), 2005. Éste y el siguiente me ayudaron considerablemente a entrar en el mundo del CSS, hay miles de recursos en Internet, pero no está de más tener algo de ayuda “a mano“.
    • Stylin’ with CSS – A Designer’s guide (Charles Wyke-Smith, New Riders), 2005.
    • Usabilidad – Diseño de sitios web (Jakob Nielsen, Prentice Hall), 2002. Completamente imprescindible. Recuerdo cómo me impactó su lectura y cómo me abrió los ojos hacia el desconocido campo de la usabilidad en un momento donde no estaba tan de moda como ahora. Todos los que trabajamos en diseño de software deberíamos leerlo, no es que aporte nada concreto, lo importante es la visión global que te hace tener sobre cómo deben pensarse las cosas que fabricas teniendo en cuenta en quién las utilizará.
  • Bases de datos:
    • Oracle 8i Guía de aprendizaje (Abbey, Corey y Abramson, Oracle Press), 2001. Este libro me permitió salir airoso de una tarea que me habían encomendado por aquella época, gracias a él conseguí aprender los conceptos básicos de Oracle.
    • Oracle 9i – Servidor de aplicaciones, red y programación (Cesa Pérez, Ra-Ma), 2003. La idea era prolongar los conocimientos que había alcanzado con el anterior, pero al final todo se quedó en nada ya que profesionalmente me aparté de Oracle.
    • MySQL  Edición Especial (Paul DuBois, Prentice Hall), 2001. La lectura de este libro fue fundamental para mi en aquel momento, con él aprendí a tunear y optimizar un sistema con una elevada carga. En 2001 no había tanta literatura al respecto en Internet como hay hoy en día.
    • Microsoft SQL Server a Fondo (Soukup, Mc Graw Hill), 2001. Mi primera toma de contacto con la base de datos de Microsoft.
  • Management y gestión de proyectos:
  • Negocios y emprendedurismo:
    • El Manifiesto Cultrain (Levine, Locke, Searls & Weinberger, Deusto), 2008. Un clásico sobre la gestión de negocios en Internet orientado hacia el trato con el cliente, la apertura de información en ambos sentidos, etc.
    • El Arte de Empezar (Guy Kawasaki, Ilustrae), 2007.  Otro clásico. Kawasaki expone su experiencia en la creación y desarrollo de startups.
    • El libro negro del emprendedor (Fernando Trías de Bes, Empresa Activa), 2008. Sería el equivalente en  español al de Guy Kawasaki. Muy recomendables los tres en todo caso.
  • Multimedia:
    • Premiere 6.5 (Antonio Paniagua Navarro, Anaya Multimedia) 2002. Con este pequeño manual dí mis primeros pasos en la edición de vídeo digital.
    • Adobe AfterEfeects 5 (Anaya Multimedia), 2002. Y con este otro profundicé un poco en ellos :).
    • Photoshop 5.5 para Windows (Miguel Angel Casanova González & Azucena González Ajenjo, Anaya Multimedia), 2001. Nunca llegué a leerlo, ni ganas de hacerlo :P.

Como conclusión, lo que os comentaba anteriormente. La mayoría de libros decentes sobre lenguajes de programación son muy caros y su vida útil es, como mucho, un par de años, a no ser que sea algo más tradicional como C ó C++. Hoy en día en Internet hay literatura de sobra para aprender cualquier cosa, la única pega que teníamos era tener que pegarte al monitor para leer un pdf o imprimirlo. Por suerte, la bajada de precios de los ebooks hace que durante los próximos meses asistamos a una migración paulatina de lectura técnica hacia los libros electrónicos, y es que así ya puedes ojear tranquilamente ese pdf de Python que tienes pendiente ;).

SCRUM de dos equipos en distintas ciudades

El pasado mes de mayo comenzamos el desarrollo de un nuevo proyecto que ha terminado recientemente, al menos la primera fase del mismo. Partimos casi de cero, los requerimientos eran muy básicos y poco documentados, pero parte del equipo teníamos en la cabeza exactamente lo que teníamos que hacer, de hecho era plasmar en una única aplicación todo nuestro trabajo de los últimos cuatro años.

Desde el principio nadie tuvo dudas, SCRUM era la mejor metodología posible para cumplir los plazos que nos habían impuesto. Planteamos sprints de dos semanas y dailys diarios (obviamente) a las 10 de la mañana de alrededor de 10 minutos. Como scrum master se quedó uno de nuestros project managers y como product owner otro del departamento de operaciones. La mayoría nos habíamos leído ya el Scrum desde las trincheras, pero una cosa es la teoría y otra muy diferente la práctica, y ahí casi nadie teníamos experiencia.

No trataré en este artículo de enseñaros SCRUM, no soy un experto, como mucho un poco “evangelizador” :P, simplemente trataré de explicar mis sensaciones tras cinco meses de SCRUM intensivo.

El Equipo

En el proyecto participaron dos equipos de desarrollo, uno en Valencia de 6 personas y otro en Madrid en el que llegaron a trabajar más de 30. Ninguna de estas casi 40 personas tenía disponibilidad completa para este proyecto sino que hubo que redistribuir toda la carga de trabajo para, con el mismo equipo, asumir un nuevo proyecto de cinco meses de duración. Salió bastante bien. Los dailys se hacían vía conferencia entre una sala de reuniones en Madrid y otra en Valencia. Se hicieron, además, infinidad de reuniones a dos bandas entre los dos equipos para decidir funcionalidades, discutir los puntos donde no había acuerdo y resolver dudas.  No sólo participaban desarrolladores sino también jefes de equipo, project managers, diseñadores, “expertos” en usabilidad, gente de testing y calidad, documentalistas, gente de sistemas, de datawarehouse

En la parte tecnológica tuvimos otro grave problema. Desde Madrid desarrollaban en .NET y desde Valencia en PHP. ¿Cual es el problema? :P. Se diseñó la arquitectura de manera que la aplicación trabajase indistintamente en uno u otro lenguaje. Dentro de un mismo entorno web, unos módulos se cargan de un lado y los otros del otro de forma completamente transparente al usuario. Se diseñó un sistema de single sign on que pudiesen compartir y consultar ambas tecnologías y, asociado a éste, todo un mecanismo de seguridad de acceso a distintos menús y opciones de la aplicación. El resultado fue formidable, todo funciona perfectamente de una manera integrada, robusta, eficiente y segura.

La Pila de Producto (product backlog)

Con la poca documentación que se tenía al principio se elaboró una pequeña pila de producto que fue creciendo a medida que las tareas de análisis evolucionaban. A esto debemos sumar requerimientos que iban llegando por parte de los departamentos comerciales y de operaciones. Al final el backlog era considerable. En agosto hubo que decidir quitar algunas historias de usuario ya que era imposible acometer todo lo que se quería, de hecho los requerimientos a estas alturas eran infinitamente superiores a los que se habían supuesto en mayo. Aún así, eliminando cosas, se hizo un producto mucho más ambicioso de lo esperado. Las historias de usuario eliminadas no se olvidaron, simplemente se trasladaron a una segunda versión.

Para el seguimiento del SCRUM, en vez de la clásica pizarra y dada la dispersión de los equipos, decidimos utilizar una herramienta de software. Comenzamos con un sencillo Excel y a mitad del proyecto incorporamos ScrumWorks, no creo que sea el programa ideal pero cumple su función.

Los Sprints

Los tres primeros sprints fueron prácticamente de análisis. Se hicieron documentos funcionales y orgánicos de todos los módulos requeridos y se perdió bastante tiempo definiendo la arquitectura de la aplicación, en realidad de las dos aplicaciones (.NET y PHP). Todo esto nos llevó a plantarnos a mediados de junio, tras 3 sprints, con muy poco que mostrar en la demo, y nos condujo a la consabida reprimenda de los que mandan, nos estábamos desviando (teóricamente) de la planificación estipulada. Sin embargo el tiempo nos daría la razón, el tiempo perdido en el diseño de la arquitectura se recuperó con creces en sprints siguientes y llegamos a la fecha con el proyecto terminado. Bueno, en realidad dejamos para el final un pequeño detalle, el rendimiento, que se solucionó en un sprint adicional.

A todo esto hemos de añadir, como ya he dicho, que el equipo no estaba dedicado al proyecto, cada día variaba la gente que entraba al daily ya que no todos estaban trabajando en el proyecto en ese momento. A eso hay que sumarle lo que llamo “contingencias del trabajo diario“, es decir, nuevos proyectos que van surgiendo durante todo ese tiempo y que implican dedicarle tiempo que tienes que quitarle a lo verdaderamente importante. Por si eso no fuera poco, a finales de junio se nos informa que una parte de la aplicación, un módulo de reporting, tiene que estar operativa a finales de julio puesto que se necesita para dar servicio en otros proyectos. Esto, que de palabra suena sencillo, nos obligó a modificar la planificación, el product backlog y la pila de sprint ya que el funcionamiento de este módulo implicaba a otros (login, seguridad, diseño…). Y aún así cumplimos todos los plazos, increíble. Eso sí, otros proyectos tuvo que decidirse entre descartarlos o aprobar una desviación de una o dos semanas en el proyecto del que hablamos, con lo que de igual manera fueron descartados :P.

Las Estimaciones

Uno de los mayores problemas es, sin duda, estimar las horas de las tareas. Comenzamos quedándonos cortísimos y terminamos quedándonos cortos también, creo que rara vez se hizo una estimación cercana a la realidad. Es muy complicado, sin duda. Las tareas de análisis se sobrestimaron en su mayoría y las de desarrollo (la mayoría) se quedaron cortas. Para planificar los primeros sprints utilizamos Poker-Scrum, pero acabamos haciéndolo directamente de viva voz ya que decidimos que no aportaba nada. En los primeros sprints hubo que arrastrar bastantes tareas de uno a otro porque se habían estimado muy a la baja, sin embargo hacia el final se recuperó el tiempo perdido y las estimaciones no eran tan malas.

Las Demos

Las demos al cliente (interno en nuestro caso) son el peor momento del sprint, no pocos días nos tocó quedarnos hasta altas horas de la noche para llegar a la demo del día siguiente con el trabajo terminado o, al menos, visible. Si esto lo hacíamos cada dos semanas, imaginaos que hubiese pasado si utilizásemos metodologías tradicionales, hubiésemos llegado al final del tiempo de desarrollo sin hacer ninguna demo, sin haber probado las cosas de una manera real. Habría sido imposible, de hecho es lo que ocurre habitualmente :P.

En nuestro caso nos sirvió no sólo para ver la reacción del cliente ante el avance del producto sino también para ver las fortalezas y debilidades del trabajo que estábamos desarrollando y reorientar los siguientes sprints.

Las demos están para que el cliente vea el avance del producto que se le está desarrollando. El cliente en nuestro caso era una persona en representación de uno o varios departamentos internos de la organización. ¿Qué utilidad tienen las demos si sólo asiste el product owner? Digo esto porque de vez en cuando aparecía por allí algún despistado que se dedicaba a criticar el producto, en concreto partes del mismo que llevaban dos o tres meses terminadas y validadas por el product owner. ¿Por qué esa actitud revienta-demos? O mejor aún, ¿por qué no le prestas el debido interés a un producto en el que se basará todo tu trabajo los próximos años? Ah, ya, es más fácil dejar la responsabilidad al product owner y después quejarse. Sin la implicación de toda la organización da igual qué metodología se utilice, ninguna conseguirá triunfar. Estamos hablando de media hora cada quince días, sólo eso.  Otro punto importante a tener en cuenta es la opinión. La gente que asiste a la demo debería estar obligada a decir algo y no quedarse callados como si no fuera con ellos porque al final ocurre lo mismo, cuando tienen que opinar no opinan y después, cuando ya no se puede hacer nada, es cuando hablan.

Retrospectiva y planificación

Las reuniones de retrospectiva fueron bastante interesantes. Por un lado comentábamos la indiferencia de los asistentes a las demos y por otro discutíamos sobre los problemas que se habían presentado durante el sprint, unas veces con más energía y otras con menos. En realidad casi podríamos decir que servían como válvula de escape al pasotismo de los asistentes a la demo.  Son necesarias las retrospectivas, sirven precisamente para evaluar no sólo lo que ha ocurrido sino también los ánimos del equipo.

Tras la retrospectiva llega la reunión de planificación de sprint. Tal como indicaba más arriba, las estimaciones se hicieron muy complicadas, muchísimas tareas por historia de usuario, muchísimas dependencias entre ellas y no siempre tenemos todos en la cabeza las implicaciones que pueden tener unas con otras, lo que termina en estimaciones muy poco aproximadas por no decir aleatorias. Aún así poco a poco se fueron afinando bastante. En las reuniones de planificación se ponían sobre la mesa también nuevos requerimientos que habían ido surgiendo y modificaciones sobre los ya terminados que obligaban a modificar las prioridades de la pila de producto ajustando el calendario a las nuevas necesidades y objetivos hasta llegar a la pila del sprint siguiente.

Conclusiones

Sin duda la experiencia ha sido muy positiva. En otras ocasiones habíamos hecho intentos de aplicar SCRUM a determinados proyectos  que resultaron en utilizar solamente algunos conceptos de SCRUM, pero la falta de implicación del cliente (casi siempre interno) restaba utilidad a la metodología. En esta ocasión se hizo una aplicación completa, real y efectiva, implicando a todos los elementos de la organización que tuviesen algo que decir dentro del proyecto y, aunque siempre se pueden hacer críticas a la implicación de algunos, podemos afirmar que, en general, todos cumplieron con su parte.

Una de las cosas de SCRUM que todos alabamos cinco meses después son, sin duda, los dailys. Nos sirvieron a todos los partícipes del proyecto para conocer de buena mano qué estaban haciendo los demás, qué problemas había,  cuándo se iban a resolver, etc. Creo que cualquier equipo de desarrollo, independientemente de la metodología que utilice, debería realizar reuniones diarias para compartir ideas y problemas.

La idea de tener demos del producto cada dos semanas obliga a todo el equipo a pensar más en hacer cosas que funcionen que en ir avanzando en tareas, es más importante terminar dos historias de usuario para presentar al final del sprint que comenzar 20 tareas que no se terminen.

Uno de los puntos que nos desviaron del objetivo en cada sprint fue el proceso de integración y preparación para la demo. Nunca tuvimos en cuenta estas horas que al final implicaban bastante tiempo de todo el equipo ya que al realizar la integración siempre había cosas que no funcionaban bien. El último día estaba dedicado casi íntegramente a estas labores que nunca estaban planificadas en la pila del sprint.

Los que me conocen saben que llevo ya unos años defendiendo SCRUM como metodología adecuada para el desarrollo de software. Esta experiencia no ha hecho más que confirmar esta opinión, la adaptación del producto al cliente que se consigue no se podría lograr con metodologías clásicas en las que la más mínima modificación de las tareas a realizar puede provocar una desviación enorme.

Supongo que pagamos algo cara la falta de experiencia, sobre todo al principio, pero aún así logramos el objetivo, seguramente con un poco más de experiencia el resultado habría sido aún mejor.

Por cierto, no hemos dejado SCRUM, el proyecto sigue y ya trabajamos en la siguiente release, así que seguimos liados con dailys, sprints, estimaciones…

Motivar y desmotivar en la gestión de personal

Estas vacaciones de Semana Santa que he pasado en Túnez (pronto contaré la experiencia como siempre 😛 ) me han servido para terminar de leer un libro (en realidad dos) que se me había atragantado un poco, El mito de la motivación, como escapar de un callejón sin salida, de Reinhard K. Sprenge. Lo empecé en diciembre pero hacia la mitad se me hizo un poco pesado, algo que después cambia y se hace mucho más llevadero pues el libro es realmente  interesante y de recomendable lectura a cualquiera que tenga gente a su cargo.

Reinhard, a partir de su experiencia en multitud de empresas, diferencia claramente entre motivación y manipulación,  desmitificando cualquier tipo de sistema de incentivos, léase por objetivos, pagas de beneficios, comisiones… Para él cualquiera de estos sistemas son la respuesta a la acción desmotivadora de algún directivo que no sabe cómo reconducir a su gente después de haber provocado, sin saberlo, la situación que viven.

En un momento del libro, Reinhard dice algo así,

Si nuestros colaboradores son gente adulta, con hipotecas, niños a los que criar y educar, parejas por las que luchar… ¿Por qué hemos de pensar  que en su vida  profesional alguien tiene que tratarlos como críos diciéndoles en cada momento lo que deben hacer y cortando su iniciativa?

Nuestros colaboradores son gente con conociemientos, preparación y experiencia y no quieren un trabajo de marionetas, quieren retos, afrontar problemas y tomar decisiones, pero si alguien se hace responsable permanentemente de las decisiones sin permitir que los demás tomen la inciativa y demuestren su valía nos plantamos en eso que se conoce como “desmotivación”. ¿Quién es el culpable entonces?

Intentar motivar es absurdo e imposible una vez se ha caído en la desmotivación. Por muchos intentos que se hagan por conseguirlo, normalmente a base de incentivos económicos, su éxito será sólamente efímero puesto que el dinero se valora y disfruta en un primer momento, cayendo en el olvido o en la costumbre en los siguientes.

La verdad es que en el libro no se cuenta nada que, desde la perspectiva de los que estamos por debajo, no hayamos visto siempre como “de cajón“, pero parece que hay mucha gente que nunca ha tenido este punto de vista y hay que mostrárselo.

Un libro que todos los directivos y managers deberían leer para entender muchas de las cosas que ocurren a su alrededor.