project management

El año comienza cargado de proyectos y de mucho, muchísimo por hacer. Tengo pendientes muchas lecturas por realizar, muchos hitos que cumplir, tanto en lo personal como en lo profesional, y, entre todo ello, una modernización de esta web en la que ya estoy trabajando y dos nuevos proyectos literarios (uno de ellos técnico).

Es estimulante comenzar el desarrollo de un nuevo producto. Siempre hago una distintación clara entre "productos" y "proyectos", ya que sus ciclos de vida no tienen nada que ver. Personalmente me gustan más los primeros, ya que tienes que pensar de otro modo para afrontarlos, considerar su mantenimiento de una forma radicamente diferente y, además, sabes que si se cierra bien, puedes pasar al siguiente, sin quedarte años trabajando en el mismo proyecto y, por suspuesto, habiendo dejado un nuevo producto para el catálogo de tu compañía. 

Otra cosa es todo lo relacionado con la rentabilidad; aunque esos son temas de desarrollo de negocio, sólo quiero apuntar algo que no me deja de sorprender. Hay demasiadas empresas de software empeñadas en captar proyectos, con el enorme esfuerzo comercial que eso supone, en lugar de apostar más por la creación de un conjunto de productos que, una vez hechos, se pueden vender una, diez o mil veces. ¿Se ve la diferencia? Al menos, integrar un modelo mixto entre productos y proyectos.

Hemos dado lo primeros pasos para el desarrollo de un nuevo producto, de nombre Smart TPL para el que además tenemos ya comprometidas la comercialización de varias licencias. Aunque lo que me interesa aquí es hablar más de cómo lo hacemos que lo que hace realmente. No obstante, aquí indico una breve descripción del mismo.

Smart TPL es una aplicación para móvil que se usará para la lectura en local de contadores digitales de tecnología PRIME. Esto es necesario ya que no todos los contadores que se instalan (ya sean de uso doméstico o industrial), tienen capacidad de telegestión, de modo que sigue siendo necesario que un operario se desplace al lugar de la instalación para obtener sus medidas, eventos, etc. Nota: los contadores de los que hablo con esos dispositivos que se instalan en la puerta de casa o en el cuadro centralizado de un bloque de viviendas para medir el consumo elétrico, entre otros muchos parámetros eléctricos.

¿Cómo vamos a realizar este nuevo producto?

De nuevo, no hay que inventar la rueda en el ciclo de vida, tan sólo seguir las buenas prácticas, que resumo a continuación.

Después de un tiempo en conversaciones con el primer cliente que nos has cumplido su adquisición, hemos intercambiado una serie de documentos con los que hemos consesuado las característias que debe cumplir el producto. De aquí se extraen los requisitos.

Estos requisitos software tienen que consensuarse con el cliente y, sobre todo, me tengo que asegurar que todo el mundo entiende el mismo lenguaje, es decir, todos entendemos igual ese dominio o ese universo particular relacionado con los problemas que resuelve la aplicación.

Esto parece una tontería, pero es vital para que después no termines cayendo en la clásica viñeta de la rueda y el "yo entendí"...

A continuación, se establecen fechas de entregas claras, que son tanto un compromiso personal para el equipo de desarrollo como una expectativa que el cliente espera que se cumpla.

Y, por supuesto, en esta fase, los requisitos, que ya son bien conocidos y están muy claros, se añaden a la herramienta ALM (application lifecycle managemente). En mi caso, no puede ser otra que nuestra suscripción al Visual Studio Online (antiguo Team Foundation Server) de Microsoft. En mi opinión, de las mejoras herramientas para la implementación de proyectos software que existen.

¿Y qué hay de las tecnologías a usar?

Puesto que conozco y el equipo conoce bien todas las tecnologías relacionadas con .NET Framework, está claro que nos debeíamos decantar por la plataforma Xamarin para el desarrollo de la aplicación móvil.  La decisión de esta elección no se hace por gusto, sino por un asunto de productividad. A expertos en C# les va a resultar muy fácil, e incluso natural, realizar aplicaciones en ese lenguaje aunque sea para otro framework o API diferentes.

Además, Xamarin ha sido adquirido por Microsoft, lo cual todo hace indicar que su presencia en el mercado se va a mantener durante muchos años y existe una gran comunidad alrededor de Xamarin.

¿Y cuáles son los siguientes pasos?

Puesto que implemento un acercamiento ágil al desarrollo de software, y este proyecto es un claro candidato para ese enfoque, definiremos un primer sprint de trabajo en el que montaremos el proyecto y cerraremos una funcionalidad sencilla del catálogo de requisitos (backlog items).

En este primer sprint:

• Generaremos una versión muy elemental de la aplicación, pero aunque sencilla, se podrá usar ya desde el terminal móvil elegido.
• Plantearemos un mock para el backend que el que debe conectar la aplicación móvil, y que estará basado en servicios REST que estarán accesibles dentro de una VPN.
• Tendremos un conocimiento mejor de Xamarin para la implementación de los siguientes sprints.

Y, sobre todo, nos divertiremos currando en este nuevo proyecto. 

Hablaré más adelante de su progreso a medida que vayamos cerrando sprints.

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. 

No me me deja de sorprender que compañías 100% de desarrollo e implantación de soluciones software, este trabajo previo e indispensable para crear una cotización aproximada y correcta, sencillamente no se tenga en cuenta con la seriedad que debería. Sí, me temo que puedo contar casos que harían palidecer a más de uno.

Hace un tiempo lanzé una encuesta con el siguiente lema: "El tiempo que se establece para los proyectos, ¿es correcto?"

El 81% de las respuestas seleccionaron la opción "No, se suelen hacer estimaciones cortas y muy ajustadas". Genial, como para recomendar a tus hijos esa profesión...

¿Cómo podemos estimar tiempos si no llegamos a especificar correctamente un porcentaje alto de lo que el cliente necesita?

Es cierto que nos podemos guiar un poco por la intuición después de llevar muchos años trabajando en el desarrollo de productos y proyectos, pero ningún negocio puede sobrevivir basado únicamente en este olfato, ni sería serio para ningún cliente determinar el precio de una manera no profesional: "pues a este, le vamos a cobrar X, más o menos", no, de ningún modo es serio, y sin embargo en muchas ocasiones se hace así, o ojo y con prisas, me temo.

La consecuencia natural de esta forma de hacer las cosas la he comentado mucho en este blog y en El Libro Negro del Programador: desarrolladores sin tiempo de hacer bien su trabajo y presionados, clientes enojados porque no se cumplen las fechas o porque se les entrega algo que no es exactamente lo que han pedido, compañías que pierden dinero, etc. También digo que con frecuencia es el mismo cliente el que te impide hacer el trabajo correctamente y te pone impedimentos.

La solución es bien sencilla, pero como todo lo fácil, requiere de disciplina y no dejarte llevar por la comocidad: no se pasa a la fase de ejecución de un proyecto hasta que no esté en su mayor parte especificado en un documento; pero, lo más importante, ese documento debe estar consensuado con el cliente. No es necesario que ese documento sea el que contenga los requisitos software, sino que la especificación puede estar en el mismo lenguaje con el que el cliente habla y entiende su negocio; de ahí, se extraerán después los requisitos software pero es suficiente para hacer una valoración de tiempos más acertada.

Pensándolo bien, en una compañía es vital gestionar los riesgos, ¿no es un riesgo ejecutar un proyecto por debajo del precio que se va a cobrar por él?

Esta falta de seriedad en la especificación la puedo comprobar continuamente y si de otras muchas cosas dudo, de hecho, suelo dudar de casi todo, en esto no hay nadie que me pueda rebatir. La buena ejecución de un proyecto depende enormemente de lo bien especificado que esté. Parece una perogrullada decir esto, pero como sabemos del día a día, a veces es difícil ponerlo en práctica. Otra cosa es que aplicando correctamente buenos principios de desarrollo, el proyecto sea mantenible y evolucionable cuando se planteen nuevos requisitos.

Otras veces es el mismo responsable comercial de la compañía el que quiere cerrar el tema (lanzándole la pelota o el marrón a otros), y a otro asunto.

Así son las cosas. Sin embargo, un buen responsable de equipo o de proyecto, no debe aceptar la puesta en marcha de un nuevo proyecto si no tiene claro en su mayor parte lo que hay que hacer. Es como si le pidiéramos a un constructor que nos levante una casa: ¿y cómo la hago?, pues mira, más o menos...

Esta 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.

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

Si te sientes identificado con algo de lo siguiente, enhorabuena, perteneces a una cultura de trabajo muy extendida en nuestro sector (con poca productividad y resultados pobres que se pueden mejorar). Todo lo que indico a continuación es demasiado obvio y a muchos les sonará a principios básicos, no obstante, ¿se cumplen en la mayoría de compañias de software?

#1 Un proyecto bien estimado en tiempo nos permite trabajar mejor

Cosa obvia aunque lo habitual es que los proyectos se consigan reduciendo los tiempos al máximo y cotizando las horas por lo bajo..., ¿resultado?, proyectos que tienen que salir sí o sí con poco tiempo y, por tanto, en su desarrollo deberemos ir abandonando las buenas prácticas de trabajo (las conozcamos o no, que esa es otra).

Básicamente, los proyectos se cotizan por horas y éstas por los perfiles de la gente que va a participar en ellos (dentro de la misma compañía suele haber perfiles más caros que otros).

Por tanto, si ese trabajo de estimación de horas no se hace bien, habrá dos posibles consecuencias: o vamos a reventar al equipo con mucha presión (cosa no mala sino malísima) o bien la compañía va a perder dinero (que tampoco es nada bueno, vaya).

¿La solución? La estimación se debe hacer por lo alto y contando con la opinión de las personas más relevantes que van a participar en el proyecto, añadiendo también alguna desviación. Esto es fácil de decir y difícil de llevar a la práctica, de ahí que las habilidades comerciales permitan conseguir esto. Seguramente de este modo va a salir un precio mayor que el cliente va a intentar regatear, que ese es otro tema, no menos importante.

Comercialmente no se puede disparar a todo lo que se mueve sin darnos cuenta de que igual que hay compañías que trabajan mal, también hay clientes que conviene no tener. Difícil decisión en épocas de crisis, claro.

#2 La especificación tiene que ser lo más completa posible

Este es el gran caballo de batalla de nuestra profesión en la que lo normal es que los clientes no tengan claro al 100% lo que realmente quieren o necesitan. No obstante, un buen comercial debe ser capaz de ayudar al cliente y extraer de él lo que quiere.

Lo importante de esto es que se debe adquirir el compromiso de que una vez establecida la especificación, ésta no debe cambiar (al menos demasiado) a lo largo de la ejecución del proyecto, y, si cambia, si nos obligan a cambiarla, entonces tenemos que repercutir en el cliente los excesos de tiempo que supongan. Claro, esto tampoco será sencillo, pero el cliente debe entender que no trabajamos por amor al arte y si los números no salen, pues no salen.

Para ello es necesario un trabajo comercial que sea capaz de llevar al cliente al terreno que nos interesa.

#3 Evitar la dispersión de tecnologías

A menos que la compañía cuente con muchísimas personas con perfiles muy distintos, lo normal es que sólo se dominen algunas tecnologías y se sepa algo de otras.

Al cotizar un proyecto hay que tener en cuenta el grado de conocimiento que tiene el equipo en las tecnologías que se van a usar. Si el equipo no conoce bien, por poner un ejemplo, JSF, entonces estamos obviando la curva de aprendizaje (igual a tiempo) en que se va a incurrir durante la ejecución del proyecto. Es, digamos, un coste oculto que hay que tener en cuenta.

No nos engañemos: si bien hay gente que en sus horas no laborales pasan gran parte del tiempo empapándose de manuales o haciendo proyectos por su cuenta, mucha gente no toca esos temas fuera de la oficina.

¿La solución? Intentar contratar proyectos en cuya ejecución se utilicen las tecnologías que mejor se conocen: esto es garantía de productividad (y rentabilidad).

En mi opinión nada peor que un equipo que le da a muchos palos (para mis lectores latinos, "darle a muchos palos" = hacer cosas muy distintas). Sólo podemos ser expertos en pocas cosas y, por tanto, la rentabilidad y productividad va a venir de la mano de esas tecnologías que conocemos mejor. Estamos hablando de hacer un proyecto rentable, no de querer jugar con MongoDB porque mola y voy a forzar a usarlo en el proyecto X sencillamente porque me gusta, no porque realmente encaje en él.

#4 Hay que usar algún tipo de gestión de la configuración

El día a día en el trabajo está lleno de pequeños momentos y detalles que podemos hacer bien, ejecutar en segundos o hacerlos rematadamente mal. Todo detalle cuenta, de modo que la falta de fluidez en el trabajo se debe a ejecutar mal parte o todos esos detalles del día a día.

No hay nada que afecte más a la productividad de un desarrollador que una mala gestión de la configuración: aunque sea simple, se debe establecer. 

¿Cuánto tiempo hemos perdido a veces porque se ha roto la compilación o porque hemos querido volver atrás en el código y esto ha sido imposible?

No es sólo usar un repositorio de código (me da vergüenza hasta escribir esto, pero es que hay quien trabaja sin usar ninguno), también establecer unos mínimos procedimientos sobre cómo usarlo para un equipo de varias personas.

En cuanto a la gestión de la configuración está todo inventado, no hay que innovar, sólo céntrate en las buenas prácticas buceando mínimamente en Internet.

#5 Hay que crear cierta documentación

Vale, sí, esto es obvio pero ¿hay alguien en la organización que exija que se cierre el proyecto con una mínima documentación? No estoy hablando sólo de la guía de usuario para el cliente final (si es que este la exige), sino de todo aquello que debamos documentar mínimamente para poder retomar el proyecto de manera rápida en el futuro. 

Yo siempre insisto en hacer una guía de diseño con todos aquellos aspectos sobre el diseño y la arquitectura que se deban explicar y que no sean evidentes; también una guía de despliegue exhaustiva que nos garantice que podemos instalar y hacer funcionar el proyecto en un nuevo entorno. Esto es tremendamente productivo y generalmente consume sólo unas pocas horas (muy pocas en comparación con cualquier proyecto). Ese tiempo meses más tarde, a la hora de asumir el proyecto de nuevo, pueden ahorrar mucho más y la frustración de hacer ingeniería inversa para ver cómo se han hecho las cosas.

No se puede dar por cerrado un proyecto si no se crea la documentación exigida; es más, se debe ver si ésta se puede realizar a lo largo de la ejecución del proyecto.

Al cotizar el proyecto se deben incluir unas horas dedicadas a la documentación. No es exagerado incluir un 5% de tiempo dedicado a este trabajo.

#6 En lo posible, hay que practicar el enfoque ágil en los proyectos

En la mayoría de proyectos podemos poner en práctica todas aquellas características del desarrollo ágil que nos permite avanzar con productividad. Puesto que un proyecto será rentable si está bien cotizado y si se realiza en tiempo, entonces hay que cuidar mucho todo aquello que suponga ahorrar horas de trabajo.

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.

A continuación indico lo puntos claves y básicos que en mi opinión hacen de un gestor un buen responsable de proyectos software:

• Conoce en todo momento lo que hacen los miembros de equipo que dirige.
• Nunca ordena sin más: planifica y organiza para que se sepa en cada momento lo que tiene que hacer cada uno y todo el mundo conoce la coherencia y el contexto de las tareas encargadas.
• Para golpes: puesto que tu jefe tiene seguramente sus propios jefes, es fundamental que actúe en ocasiones como paraguas. En otras palabras, los miembros del equipo tienen que aislarse del ruido de fondo, ansiedades o guerras internas de otras partes de la compañía. La creatividad no puede surgir en un entorno envenenado y donde la presión y el estrés se pueden palpar.
• Estimula y motiva, esto es, aplaude las mejoras y los logros y siempre realiza críticas constructivas con ánimo de mejorar. 
• No sabe lo que es un error: llama "resultado mejorable" al error o fracaso.
• Comparte conocimientos: si el gestor lo es porque cuenta con más años de experiencia y está curtido en muchas batallas profesionales, su función es trasladar ese conocimiento al equipo.
• Nunca se fija en lo personal, siempre en los resultados aportados de cada uno.
• Delega: es muy típica la desconfianza de muchos gestores que creen que como ellos nadie puede hacer esa tarea en apariencia complicada o de responsabilidad. Esto es un error, he visto infinidad de veces cómo cuando a los miembros del equipo se les da responsabilidad y sobre todo, confianza, pueden llegar a hacerlo mucho mejor que tú y, por tanto, todos salen ganando: el primero porque delega, el equipo porque así gana experiencia.
• Asume los fallos: esto puede parecer un poco heavy de decir, pero si un miembro del equipo mete la pata, y la mete hasta el fondo, el responsable es su jefe o manager. No hay más. La cara al resto de la organización la tiene que dar él. Cuántas veces gestores (que yo llamo barriobajeros,  chanchulleros o trepadores) acusan firmemente con el dedo a la gente del equipo para esquivar los golpes. Como en todo, si una persona no es honesta fuera del trabajo, ¿por qué lo va a seguir siendo dentro? Quiero decir, somos las personas que somos en todo lo que hacemos.
• Promociona los buenos resultados siempre que puede entre el equipo. Los equipos tienen el derecho de progresar, en lo económico y en lo profesional. En muchas ocasiones, el gestor es el interlocutor con el resto de la organización para hacer eso posible. Si no mejoras es que empeoras. 
• Busca equipos coherentes. En el equipo todos tienen que aportar y se tiene que respirar un buen clima de trabajo, proactivo y estimulante. No se puede transmitir al equipo tus propias ansiedades, incertidumbres e inseguridades. ¿Quién no ha tenido alguna vez un jefe alicaído, negativo, protestón y que contagia estrés a los demás? ¿Se puede promover la creatividad y la innovación en un ambiente así?
• Un jefe quizá necesite más formación que nadie, de modo que debe ser una persona que se recicla continuamente. ¿Por qué? Un gestor de equipos debe dominar ciertas habilidades no necesariamente técnicas: debe comunicar bien y eficazmente, debe organizarse de manera extraordinariamente productiva para cumplir con sus obligaciones, debe saber gestionar y motivar a las personas, entre otras cosas. Al final anoto una serie de libros que me gustan en este sentido.
• Trabajar con gente tiene a veces sus sinsabores: el gestor debe identificar cuándo un miembro del equipo no funciona y por qué, por la razón que sea, y apartarlo del mismo. En alguna ocasión he provocado que algunas personas salgan de la compañía donde he estado trabajando en ese momento (por falta de compromiso y de competencias de esas personas, claro), os aseguro que es muy duro, te quita el sueño (literalmente), pero es necesario para que el trabajo salga adelante. Irónicamente, con el tiempo los equipos involucrados me agradecieron esa actitud de firmeza.
• Un buen responable no puede nunca tener favoritismos hacia nadie, esto crea una sensación de injusticia entre la gente.
• Pero, sobre todo, un buen gestor pone los medios para que el equipo trabaje tranquilo, centrado en las tareas de cada momento y con los medios adecuados.

Seguramente este tema dé para escribir un libro entero y más de uno esté calificando del uno al diez a su propio jefe según los puntos anteriores.

Siempre lo digo y no me cansaré de repetirlo: el éxito de un proyecto software es el éxito colectivo de todos los miembros del equipo, desde el diseñador, los desarrolladores, el gestor y el empresario que ha apostado por ese proyecto.

Si quieres saber más, aquí te recomiendo muy brevemente algunos libros que leí hace tiempo y sus enlaces directos a Amazon, una selección un poco heterogénea entre académica y de desarrollo personal, porque un buen gestor debe dominar muchas facetas de su desarrollo como profesional (buen orador, comunicador eficaz, buena organización del trabajo, etc.)

Behind Closed Doors: Secrets of Great Management, magnífico libro sobre gestión.

Aprendiendo de los mejores: Tu desarrollo personal es tu destino, de Francisco Alcaide. He descubierto a este autor este verano y he leído varios libros suyos. Un buen libro de motivación para mejorar en todos los aspectos de tu vida, también el profesional.

Organízate con eficacia: Llega más lejos de lo que nunca hubieras imaginado, básico para poder afrontar una buena organización del trabajo.

Cómo hablar bien en público e influir en los hombres de negocios (Elipse), libro de cabecera para aprender a transmitir tus ideas y comunicar bien.