Logo
  • Lecciones aprendidas
  • Hola!
Dani Pàmies, Copyright 2015
29 abril, 2016
dpamies
Artículos
0

Programadores y alcance abierto

PreviousNext
programadores-y-alcance-abierto

Cuando estoy exponiendo un proyecto en el que interviene un desarrollo informático, me gusta explicar que los programadores no son – o somos 😉 – tontos.

La capacidad analítica, de abstracción y optimización que habitualmente tienen permite dar solución a necesidades reales del mundo en el que vivimos. Su mente estructurada y el procesamiento lógico que suelen aplicar hacen que cuando visualizan una solución, avanzan decididamente hacia ella. Y por eso les “contrarian” los cambios.

Lo ideal en mi opinión, sería que los desarrolladores interpretaran la solución que deben implementar y se apropiaran de ella. Deberían poder aportar valor al proyecto desde un punto de vista técnico y de optimización. Al fin y al cabo, el trabajo en equipo es esencial porque son los programadores los que acaban haciendo que la tecnología funcione.

¿Cuál es la realidad?

Todo programador tiene la capacidad de tomar decisiones que afecten a los sistemas. Ya habrás oído decir que les gusta añadir funcionalidades porque les parece que así el sistema será mejor. No te digo que no, pero no estoy hablando de esto.

Estoy hablando de su capacidad para detectar y arreglar las incongruencias que sí o sí acabaran saliendo a la luz. Y es que por muy definidos que estén la arquitectura de los sistemas, las necesidades funcionales, los diagramas de la interacción, etc., no dejan de ser marcos de actuación (más o menos acotados) para acabar desarrollando código.

Es entonces cuando me pregunto, ¿por qué a la hora de contratar un proyecto definido, se hace necesario especificar hasta el más mínimo detalle? La respuesta que encuentro siempre es que, de esta forma, se tiene definido el alcance y se puede hacer una previsión de costes y tiempo. Para mi, lo que pasa es que no se ha contemplado una gestión de proyecto de alcance abierto.

La siguiente pregunta es: ¿Y si en lugar de definir tanto el alcance (tarea que de por sí ya supone un coste) definimos a priori el coste y el tiempo y vamos gestionando el alcance? Y no me refiero ni a modelos lean o agile, ni a metodologías o herramientas de desarrollo. Estoy hablando de gestión de proyecto.

Me he encontrado con empresas consultoras que “regalan” el análisis de requisitos y el funcional en contrapartida de la realización del desarrollo del software. Es curioso que la fase en la que hay que plasmar el valor del proyecto y del negocio salga más barata que las horas de programación… ¿Acaso es menos importante? ¿Es por volumen de horas/coste? ¿Es porque los arquitectos y los programadores tienen más que decir? ¿Es una estrategia de balanceo de costes ;)?

En proyectos de innovación, proyectos que no son réplicas exactas, proyectos que no están puramente sistematizados y probados, es habitual tener cambios. Y la gestión de cambios es cara. Entonces, ¿por qué no conceptualizamos el proyecto como tal, en pos de encontrar el producto o servicio ideal?

Trabajar con alcance abierto

Veo dos aspectos esenciales a la hora de desarrollar un proyecto de esta forma: lo primero es tener una relación estrecha de confianza entre los diferentes componentes del equipo (cliente, partners, etc). El otro, es poner en valor y comunicar de forma transparente todo aquello que se está haciendo.

“Todos los profesionales que participan en un proyecto con alcance abierto deben tener una relación de confianza, para que todos tengan presente el coste del esfuerzo y el valor aportado en base a ese esfuerzo.”

Estoy convencido que trabajando de forma conjunta, dejando que las decisiones y conocimiento de cada profesional pesen más en aquellos puntos del proyecto dónde es experto, y no intentando encuadrarlos en un alcance definido, el producto o servicio del proyecto dará otro tipo de frutos.

Está claro que hay que realizar un análisis y anticipar los problemas, pero también hay que estar preparado para poder gestionar un alcance de forma eficaz.

equiposGestión de proyectos
Share this

The Author dpamies

More Posts Like This One

gestionar-proyectos-incertidumbre

Gestionar proyectos con incertidumbre

17 octubre, 2014
Contratar_programadores

Contratar programadores

14 agosto, 2015
como_crece_tu_equipo

¿Cómo crece tu equipo?

26 junio, 2015
0 Comments General

Leave A Comment Cancelar respuesta

 

Entradas recientes

  • Taller de innovación creativa en BDW
  • ¿Gestionas o repartes?
  • ¿En qué es bueno mi hijo?
  • El brief como herramienta
  • Cyborgs, personas y tecnología

Comentarios recientes

  • dpamies en Equipos con entusiasmo
  • dpamies en El programador ninja
  • Ubuntu VPS en Equipos con entusiasmo
  • sikis izle en El programador ninja
  • Dani Pàmies en 6 beneficios de un proyecto UX

Archivos

  • junio 2016
  • mayo 2016
  • abril 2016
  • marzo 2016
  • febrero 2016
  • enero 2016
  • diciembre 2015
  • noviembre 2015
  • octubre 2015
  • septiembre 2015
  • agosto 2015
  • julio 2015
  • junio 2015
  • mayo 2015
  • abril 2015
  • marzo 2015
  • febrero 2015
  • enero 2015
  • diciembre 2014
  • noviembre 2014
  • octubre 2014
  • septiembre 2014
  • agosto 2014
  • julio 2014
  • mayo 2014
  • abril 2014
  • marzo 2014
  • febrero 2014

Categorías

  • Artículos
  • Eventos

Meta

  • Acceder
  • RSS de las entradas
  • RSS de los comentarios
  • WordPress.org