Desarrollo de software. Antipatrón. Los arquitectos no programan

Defiendo absolutamente la posibilidad de que en una organización se pueda progresar horizontalmente de manera que técnicos que disfruten con la programación y con la ingeniería del software puedan tener la oportunidad de conseguir mejores condiciones laborales si su desempeño, experiencia y conocimientos les hace merecedores de ello.

Lo anterior es absolutamente compatible con una carrera profesional de índole más técnica orientada a la arquitectura del software.

Es posible que a un programador solo lo puedas vender dentro de un umbral precio/hora (es el reverso tenebroso de los proyectos tipo taxímetro o bolsa de horas), pero en proyectos donde prestas un servicio tener a desarrolladores altamente cualificados, motivados y productivos puede ser la diferencia entre ganar o perder dinero.

Un apunte: No hablo de sobredimensionar la cualificación de los equipos, ya que eso puede jugar incluso en contra del proyecto ya que puede provocar en algunos casos (proyectos de complejidad medio o baja) pérdida de motivación y de rendimiento, lo que unido a mayores costes, puede hacer que el proyecto no sea tan rentable como cabría pensar y encima tienes ocupado en el mismo a gran parte del potencial de tu organización.

Cuando el coste/hora y no la productividad es la que marca los pasos, se pueden llegar a tomar decisiones poco comprensibles como que arquitectos software o analistas orgánicos centren su esfuerzo en definir arquitecturas, frameworks o diseños y dejen a un lado el día a día de la programación.

Todos sabemos como evoluciona el mundo del desarrollo de software y eso hace que ese tipo de decisiones se consideren un antipatrón, ya que cuanto más alejado esté un arquitecto de la realidad de la codificación, más alejadas se encontrarán sus soluciones de las necesidades que pueda tener el equipo de programadores y el proyecto.

La creatividad desmesurada que nos caracteriza puede provocar que el arquitecto elija soluciones más teóricas (cuando no experimentales) que prácticas, alejando al proyecto del objetivo de simplicidad máxima que cumpla las expectativas del usuario. Este defecto lo tiene cualquiera que realice análisis, diseños o arquitecturas y empeora sensiblemente cuando se está alejado del día a día de los proyectos (un analista que no trata con usuarios y con sus problemas, tenderá a hacer soluciones más complejas).

About these ads
4 comentarios
  1. Agata dijo:

    ¿pero es que ese perfil existe? Pienso igual que tu, pero además ese perfil debe ser el responsable de “comerse los marrones” de la arquitectura.
    Pero, para que un arquitecto haga eso primero debe ecxistir su puesto. Cosa que a día de hora pocas empresas lo tienen. Y las que lo tienen… bueno eso lo tienen.
    Otra cosa es que por mucho tener un arquitecto, para que te sirve si el cliente te pide una arquitectura obsoleta. Quizás el problema está en que dichos puestos no son necesarios, ya que los propios clientes son los primeros en poner cortapisas a la creatividad de los arquitectos.
    También es cierto, que un cliente prefiere tener todos sus proyectos con una misma línea o “stack” tecnológico, pero no es menos cierto que para ello se deben realizar alianzas estratégicas. Alianzas entre clientes y proveedores.
    De forma que mediante proyectos piloto, se pueda ir avanzando en las arquitecturas. Esto es más una invesión que un gasto que siempre es rentable. Pero, ¿ quién es el guapo que lo hace ahora?

    • jummp dijo:

      En el contexto de desarrollos a medida para terceros estoy bastante de acuerdo con tu comentario.

      Lo de las alianzas tecnológicas tiene sus pros y sus contras: puede afectar a la competencia de otros proveedores o dejarte a expensas del proveedor o proveedores con los que has realizado tal alianza (algo que se puede ver agravado por el uso de soluciones propietarias y licenciadas de esos mismos proveedores), etc…

      El perfil de arquitecto, como bien dices, está muy poco extendido, pero precisamente porque se asocia a personas que cobran bastante y que resultan complicadas de justificar en los presupuestos de los proyectos.

      Es un perfil que considero necesario:

      - A nivel de organización: plantear unas líneas generales de desarrollo dentro de la organización (muy importante cuando la organización está orientada a productos y también cuando se realizan desarrollos a medida, ya que hay clientes que no imponen una determinada solución técnica o bien se trabaja con un grupo concreto y estable de clientes), selección del ecosistema de desarrollo, etc…

      - En proyectos con clientes, precisamente para realizar una orientación de la arquitectura del sistema a las necesidades del proyecto y del cliente.

      El problema es que muchas organizaciones en la situación actual de crisis tienen una visión cortoplacista y solo se fijan en reducir gastos fijos para ser más competitivos en políticas de precios, sin tener en cuenta que este tipo de perfiles lo que van a hacer (si realizan bien su trabajo) es mejorar la productividad del conjunto.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.198 seguidores

%d personas les gusta esto: