archivo

Archivos diarios: enero 12, 2013

Si tu marca es Apple, Google, Oracle u otra por el estilo, vale. Pero el 99’9% no vende solo por la marca o por su posición en el mercado. De hecho, estas marcas tienen que seguir innovando y mejorando porque de lo contrario perderán cuota de mercado y dejarán de ganar (o perderán) mucho dinero.

Fuera de ahí, quien crea que vende por la marca, se equivoca y todavía más en un mundo tan complicado como el de los servicios de desarrollo de software. La marca se diluye proporcionalmente al tamaño de la organización ya que conforme crecen se van convirtiendo, paradójicamente, en un conjunto de “microempresas” gestionadas (cuando existe gestión) cada una de ellas por el gerente de turno. El cuerpo de conocimiento no suele existir como tal, en su lugar existen procesos organizativos (y no dinámicas de desarrollo) que tratan de dar una identidad a la organización.

Desde este punto de vista, las marcas no respaldan nada, lo que tienen son personas que en un momento concreto del tiempo están asignados a un proyecto.

Este antipatrón surge cuando se piensa que una venta está hecha (o tienes más posibilidades que el resto) por el simple nombre de tu organización, ¿te puede dar ventaja? sí, pero menos de la que piensas. Si quieres conseguir contratos, te lo tienes que trabajar y no esperar que un logo o un nombre lo haga todo por ti.

Agilidad es intensidad. Es una diferencia fundamental con otros enfoques o estrategias de desarrollo de software. La intensidad requiere proximidad (no necesariamente física), en la que los componentes de los equipos se vean entendidos, apoyados y respaldados.

No vale con dar cuatro directrices generales basadas en enfoques ágiles, seguir los trabajos desde lejos y después pedir responsabilidades o esperar resultados. Autogestión sí, por supuesto, microgestión no, también, pero sobre todo responsabilidad a la hora de gestionar proyectos y saber cuál es tu papel.

Si sigues metodologías, estrategias, enfoques o prácticas ágiles, no te debes quedar en la teoría o en hacer que tus equipos cumplan con ella, sino que debes entender cuál es el contexto del proyecto, para saber en cada momento qué es lo que más le conviene, y conocer los problemas del día a día. No se puede ser facilitador desde la distancia, no puedes hacer sugerencias, definir estrategias o pedir correcciones si no sabes qué es lo que está pasando. Tienes que comprometerte con el proyecto y con las personas que lo están sacando para adelante.

Si no actúas de esa forma serás una resistencia más que un apoyo y si quieres dar una visión agilista al proyecto, se quedará fundamentalmente en el aspecto metodológico (cuando la agilidad realmente es cuestión de actitud) y en lo que el equipo de trabajo tenga a bien sacar adelante por sus propios mérito y esfuerzo. Este antipatrón podría considerarse como un caso particular de una definición más genérica como es la de “falso agilista“.