Basta de esconderse detrás del rol y a terminar las cosas

El siguiente artículo pertence a J Schwan, originalmente se tituló "Stop hiding behind your role and get it done". Me pareció muy bueno, así que lo contacté por correo electrónico y con su permiso, lo traduje al español, para que más personas puedan leerlo.

Basta de esconderse detrás del rol y a terminar las cosas

He notado algunos cambios en la cultura de la Tecnología de la Información, y para ser sincero, no son muy alentadores. Parece que en los proyectos hay más y más división de roles; y aunque la intención es buena (y posiblemente, necesaria) en muchos casos, no está funcionando. La buena noticia es, que tengo una idea de cómo podemos solucionarlo.

Permítanme explicar que es a lo que me refiero con un ejemplo del pasado. Cerca de 30 años atrás, la principal plataforma de desarrollo de aplicaciones era el mainframe. La estructura de los equipos que construían estos sistemas era sencilla. Había gente de negocio (contadores, RR.HH., marketing, etc.) que tenía problemas específicos, o requerimientos, y había desarrolladores que construían sistemas para solucionarlos. Los desarrolladores trabajaban en contacto directo con el negocio, por lo cual estaban forzados a entender las necesidades del negocio para poder solucionar los problemas. Por otro lado, los desarrolladores entendían todos los aspectos del mainframe; las estructuras de datos, el código que necesitaba escribirse para procesarlas y las restricciones de infraestructura para desplegar el código. En otras palabras, ellos sabían todo, de principio a fin. Ellos tenían claro los indicadores del negocio, el diseño y la implementación que se necesitaba hacer y por sobre todo, eran responsables.

Con el advenimiento de los enormes sistemas distribuidos y aplicaciones orientadas al cliente cada vez más complejos, el modelo se volvió difícil de administrar. Las tecnologías maduraron, se dividieron y los desarrolladores comenzaron a alinearse con habilidades específicas, generalmente delimitadas por varias partes del sistema (la red, la base de datos, la infraestructura, los servidores, el contenido, etc.). Para poder administrar estos proyectos complejos, los Líderes de Proyecto surgieron para coordinar todas las tareas que eran necesarias para desarrollar el sistema, y los Arquitectos de Software aparecieron para alinear todas las tecnologías. Como esta gente estaba tan ocupada, los Analistas de Negocio vinieron para actuar como enlace entre la gente de negocio y los equipos de tecnología.

Todo esto está bien, pero algo importante se ha perdido en el proceso (en muchos casos)

1. Comprender las necesidades del negocio y sus indicadores.

2. Comprender el sistema de negocio como un todo.

Y por último...

3. Responsabilidad.

Permítanme dar un ejemplo. Díganme si ha escuchado algo como esto:

Bob el stakeholder de negocio: “El proyecto de marketing XYZ está retrasado y excedido en presupuesto, ¿Cuál es el problema?”

Pam la líder de proyecto (mirando al plan de proyecto): “La construcción de la plataforma MQ es crítica y está tomando más de lo previsto.”

Bob el stakeholder de negocio: “¿Qué es MQ?”

Pam la líder de proyecto: “No lo sé, creo que es una plataforma de mensajería.”

Bob el stakeholder de negocio: “¿Qué es una plataforma de mensajería?”

Pam la líder de proyecto (con una ligera sonrisa): “No lo sé, verás, no entiendo toda esta tecnología, sólo soy la coordinadora de proyecto. Preguntémosle al arquitecto de software.”

Bob el stakeholder de negocio: “¿Art, que es una plataforma de mensajería?”

Art el arquitecto: “Es un sistema que permite a una aplicación, enviar y recibir datos desde otra aplicación.”

Bob el stakeholder de negocio: “¿Por qué está tardando tanto?”

Art el arquitecto: “Define 'tanto'. Estará listo cuando esté terminado, lo estamos haciendo tan rápido como podemos. No miro el plan de proyecto. Sólo me dedico a tener el trabajo listo. Soy un arquitecto, no un adivino.”

Bob el stakeholder de negocio: “¿Qué sistema necesitamos para obtener los datos?”

Art el arquitecto: “El sistema de CRM. Necesitamos acceder a la dirección del cliente desde ese sistema.”

Bob el stakeholder de negocio: “Pero eso es sólo una pequeña información que tenemos en pantalla. Ni siquiera es importante.”

Art el arquitecto: “Hey, estaba en el documento de requerimientos. Habla con Benny el analista de negocio”

Bob el stakeholder de negocio: “Espera, pero....”

Benny el analista de negocio (muestra su cabeza por la puerta de la sala de reuniones): “Me dijiste que lo querías así que lo especifiqué en el caso de uso. ¡Lo has firmado!”.

A continuación, todos estallan en una carcajada.

Esto puede ser exagerado, pero por suerte se entiende mi punto. Hay una tendencia a esconderse detrás de los roles de un proyecto, lo que inevitablemente desacelera las cosas, aumenta la confusión y, al final del día, hace fallar a los proyectos. Hoy recibí un correo de uno de mis clientes favoritos, que en forma vehemente describía al problema como “Ahora tenemos demasiados silos y las interfases entre ellos son abismos” Hay muchas respuestas sobre como resolver estos problemas con metodologías y administración, pero la respuesta es simple..., retomando la propiedad.

En muchos casos esta división de roles es necesaria, es una realidad, pero para poder hacer que los proyectos tengan éxito, debemos dejar de escondernos detrás de nuestros roles y volver al concepto fundamental de que somos tecnólogos. Esto significa que sin importar el rol que estemos representando, es nuestra responsabilidad el entender los problemas de negocio, entender al sistema como un todo y entender el plan que está para resolver los problemas de negocio.

Esto significa que los Líderes de Proyecto (como también los Analistas de Negocio) no pueden apelar a la ignorancia en problemas de tecnología. Como mínimo deberían entender lo fundamental de sistemas distribuidos, sus componentes y las responsabilidades de esos componentes. Si quieres una introducción, puedes ver la última entrada de mi blog Distributed Application Stack. Esto no significa que tengan que aprender a escribir código Java o que tengan que escribir un WSDL en .NET. Esto significa que tienen que entender las bases de la arquitectura para que puedan hablar con inteligencia y puedan entender el contexto de los problemas que pueden ocurrir en un proyecto. Significa que no tienen que tener todas las respuestas, pero tienen que saber hacer las preguntas correctas (¡Es la mejor manera de aprender!). Significa que tienen que ser responsables por la tecnología que se está desarrollando.

Los arquitectos (y los desarrolladores) también tienen responsabilidad. No pueden esconderse detrás de los frameworks o modelos de datos o topologías de redes que tanto gustan de diseñar y construir. Tienen que leer el plan de proyecto con las mismas ganas con las que leen Digg.com. No tienen que administrar el plan, pero tienen que ser propietarios del plan. Tienen que entender los tiempos y el presupuesto y las prioridades del negocio para que puedan tomar las decisiones de arquitectura para cada problema con las restricciones que les son dadas. Significa que tienen que ser responsables no sólo de la arquitectura, sino de los problemas de negocio también, los tiempos y el presupuesto del proyecto.

Ahora, hay amantes de las metodologías que dirán que las metodologías ágiles o RUP o los hitos en SDLC solucionan todo. O los gurús de IT Governance o ITIL dirán que procesos y métricas claramente definidos y estrategias de monitoreo asegurarán que los proyectos en problemas serán atacados en forma temprana, justo a tiempo para permitir a más líderes de proyecto, analistas de negocio y arquitectos salvar al proyecto. Y quizás algunas de estas cosas ayuden. Pero les digo que todo se reduce a ... gente tomando responsabilidades. Responsabilidad sobre los proyectos y responsabilidad sobre sus carreras. Gente que no se esconde más detrás de un rol determinado o detrás de una matriz de responsabilidades o una descripción de puesto de trabajo. Gente que son especialistas en algunas cosas, pero que tienen una pasión por entender todos los aspectos de la IT. Gente que se preocupa.

Tomamos la decisión sensata en Solstice de no crear títulos de puestos que atrapen a nuestros consultores en áreas específicas de IT. Tenemos gente que soluciona problemas. Tenemos gente que es lista y que termina las cosas. Seguro que tenemos roles que nos gustan más. Yo amo el trabajo de arquitecto, y si estoy trabajando en un proyecto que va a requerir mucha gente, traigo a uno de nuestros mejores líderes de proyecto, porque francamente, no soy tan bueno en el liderazgo de proyectos. Pero conozco la diferencia entre un diagrama de Gantt y un Sprint Queue, y cuando es más sensato usar uno u otro para administrar un proyecto. Y de la misma manera, nuestros líderes de proyecto entienden la diferencia entre un servidor web y un servidor de aplicaciones, y que nuestros analistas de negocio no tienen ningún reparo en hacer aseguramiento de calidad o arremangarse para arreglar pequeños errores si el proyecto lo necesita.

Somos todos tecnólogos, y pienso que es eso a lo que la cultura de IT debería regresar. ¡Demonios, hay una razón por la que esas aplicaciones de mainframe todavía están presentes!

Gracias por leer como siempre, háganme saber sus opiniones en los comentarios.

Creo que el punto queda bastante claro, nos hemos concentrado tanto en la especialización, que a veces nos olvidamos del punto de vista sistémico, ver al sistema como un todo, saber que existen diferentes elementos que deben cooperar para alcanzar el objetivo final.

Saludos