Desarrollo de software. ¿Qué es un proyecto?
Algo que no termina nunca, dirán algunos.
Y no es así, más bien, no debería ser así. Vamos a analizarlo.
Un proyecto es un conjunto de actividades que se realizan en el tiempo (su realización, por tanto, es gradual) que tienen como objetivo producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó.
Definiciones, hay muchas, la anterior puede ser una de ellas.
¿Qué se realizan en el tiempo quiere decir planificadas? En algún momento, y eso es independiente de la metodología utilizada, hay que decidir cuándo se realiza la actividad. Personalmente me gusta más la expresión “se realizan en el tiempo” que “planificadas” porque lo segundo parece que se remonta a un horizonte temporal más amplio y no necesariamente tiene que ser así.
Un proyecto, por tanto y por definición, debe ser finito. Sin embargo, cuando hablamos de enfoques iterativos incrementales en el desarrollo parece que siempre lo hacemos pensando en una continuidad, como si el sistema siempre estuviera en continua evolución.
Ese enfoque es lógico y no solo sucede en ese tipo de ciclo de vida, también nos lo encontramos en el < href="clásico ya que un software siempre es susceptible de ser mantenido en sus diferentes vertientes (evolutivo, correctivo, adaptativo y perfectivo), lo cual no quita que planteemos horizontes temporales para conseguir determinados objetivos.
La vinculación que se tiene respecto a un sistema de información hace que, independientemente de que el proyecto sea el mismo para el cliente que para el proveedor, y por tanto, finalice a la vez, se tengan diferentes visiones, de cuándo realmente termina para uno y para otro.
Si tu rol es el de proveedor, el proyecto termina cuando se alcanzan los objetivos por lo que te han pagado y una vez finalizada la garantía establecida (esto puede ser más o menos tormentoso, llevar más o menos tiempo, pero los proyectos, terminan).
Si tu rol es el de responsable técnico del cliente no está tan claro cuándo terminas, si es que terminas, ya que existe una frontera poco definida entre lo que es la explotación y mantenimiento de un sistema de información (generalmente por una mala definición de las funciones y procesos de los departamentos TIC), por lo que no se termina de pasar página y esto sucede, tanto si se encadenan proyectos como si no. Eres responsable técnico del sistema y lo serás hasta que el ciclo de vida del mismo se cumpla.
El problema de que la vinculación al sistema de información sea esa es que, conforme vaya pasando el tiempo, cada vez serán más proyectos y sistemas con los que trabajes y la montaña se hace cada vez más grande, tanto que la gestión termina siendo insoportable porque habrá sistemas de información que durante un tiempo no den problemas, pero al final siempre aparecerá algo que origina un trabajo.
Cuando se gestionan muchos sistemas, la suma de elementos aislados forman una sucesión interminable de tareas, que afectan a los proyectos reales en los que estás trabajando en ese momento, mermando la calidad de las actividades que realizas en el mismo.
Pingback: Desarrollo de software. Timothy R. Lister. Gestión del riesgo. Su evolución en el proyecto « Jummp
Pingback: Desarrollo de software. P. J. Plauger. Del primer proyecto a la mejora continua « Jummp
Pingback: ¿Qué es el ciclo de vida del software? « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. Las pérdidas de tiempo « Jummp
Pingback: Desarrollo de software. Compartir objetivos « Jummp
Pingback: Desarrollo de software. El analista funcional y el analista orgánico « Jummp
Pingback: Desarrollo de software. Cierre del proyecto « Jummp
Pingback: Desarrollo de software. Ciclo de vida RUP (Rational Unified Process) « Jummp
Pingback: Desarrollo de software. Sun Tzu. Toda guerra se basa en el engaño « Jummp
Pingback: Desarrollo de software. Cuando las personas no pueden suplir los procesos « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. La planificación « Jummp
Pingback: Desarrollo de software. La mejora contínua y el feedback « Jummp
Pingback: Plan de sistemas de información II « Jummp
Pingback: Desarrollo de software. La confianza « Jummp
Pingback: Desarrollo de software. Sun Tzu. Guerra, proyectos, factores similares para conseguir la victoria « Jummp
Pingback: Desarrollo de software. Crisis, problemas, asumir decisiones, mirar adelante « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. El precio de la calidad del software « Jummp
Pingback: Desarrollo de software. Sun Tzu. Gestión inicial del riesgo, condiciones iniciales para el desarrollo « Jummp
Pingback: Desarrollo de software. El inicio del proyecto no es la programación « Jummp
Pingback: Desarrollo de software. Sun Tzu. La importancia de ir liberando versiones operativas cuanto antes « Jummp
Pingback: Desarrollo de software. Sun Tzu. Buenas condiciones de partida « Jummp
Pingback: Desarrollo de software. Desequilibrio entre stakeholders « Jummp
Pingback: Desarrollo de software. Sun Tzu. Saber cómo enfocar un proyecto no asegura el éxito « Jummp
Pingback: Desarrollo de software. Sun Tzu. Las contingencias del proyecto determinan el aprendizaje « Jummp
Pingback: Desarrollo de software. El precio/hora y el triunfo de la mediocridad « Jummp
Pingback: Desarrollo de software. Cuando nos quedamos solos en el proyecto « Jummp
Pingback: Desarrollo de software. Proyectos. La complejidad de tener éxito en todos los contextos « Jummp
Pingback: LCOM4 y la falta de cohesión en las clases « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. Cantidad y calidad de la documentación « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. La regularidad en la producción « Jummp
Pingback: Desarrollo de software. El precio/hora y el triunfo de la mediocridad II « Jummp
Pingback: Desarrollo de software. Mala calidad institucionalizada « Jummp
Pingback: Desarrollo de software. Entregas limpias, por favor « Jummp
Pingback: Desarrollo de software. Inercias « Jummp
Pingback: Desarrollo de software. Cuestión de crédito « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. Documentación, parte de la solución o parte del problema « Jummp
Pingback: Desarrollo de software. El traspaso de proyectos « Jummp
Pingback: Desarrollo de software. Diversificación y equilibrio entre clientes y proveedores « Jummp
Pingback: Desarrollo de software. La tiranía del área usuaria « Jummp
Pingback: Desarrollo de software. Antipatrones « Jummp
Pingback: Desarrollo de software. El comportamiento en las crisis condiciona el resto del proyecto « Jummp
Pingback: Desarrollo de software. Antipatrón. Complejidad no indispensable « Jummp
Pingback: Desarrollo de software. Antipatrón. Tester driven development « Jummp
Pingback: Desarrollo de software. Antipatrón. Avance del alcance « Jummp
Pingback: Desarrollo de software. Antipatrón. Escalada del compromiso « Jummp
Pingback: Desarrollo de software. Antipatrón. Parálisis del análisis « Jummp
Pingback: Desarrollo de software. Antipatrón. Productividad a toda costa « Jummp
Pingback: Desarrollo de software. Antipatrón. Callejón sin salida « Jummp
Pingback: Desarrollo de software. Antipatrón. Te lo dije « Jummp
Pingback: Desarrollo de software. Antipatrón. Organización de cuerda de violín « Jummp
Pingback: Desarrollo de software. Antipatrón. Organización de cuerda de violín « Jummp
Pingback: Desarrollo de software. La competencia entre proveedores o por qué el grande no tiene por qué comerse al pequeño « Jummp
Pingback: Desarrollo de software. Antipatrón. Migración de coste « Jummp
Pingback: Desarrollo de software. Antipatrón. Pollo sin cabeza « Jummp
Pingback: Desarrollo de software. El cliente no es el enemigo « Jummp
Pingback: Desarrollo de software. Guerra de guerrillas « Jummp
Pingback: Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología « Jummp
Pingback: Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología II « Jummp
Pingback: Desarrollo de software. Antipatrón. Introducción de dificultad por analogía « Jummp
Pingback: Desarrollo de software. Buenas prácticas y antipatrones « Jummp
Pingback: Desarrollo de software. La resaca del éxito « Jummp
Pingback: Desarrollo de software. La aceleración y la recuperación del tiempo perdido « Jummp
Pingback: Desarrollo de software. Antipatrón. Ellos me entendieron « Jummp
Pingback: Desarrollo de software. Objetivos, incertidumbre, agilidad « Jummp
Pingback: Desarrollo de software. Avance del proyecto y expectativas « Jummp
Pingback: Desarrollo de software. Antipatrón. Proyecto del día de la marmota « Jummp
Pingback: Desarrollo de software. Cascada y sin dinero para el mantenimiento « Jummp
Pingback: Desarrollo de software. Antipatrón. Cargo cult « Jummp
Pingback: Desarrollo de software. Antipatrón. Corncob. Mazorca de maíz « Jummp
Pingback: Desarrollo de software. Antipatrón. Arrojar al otro lado del muro « Jummp
Pingback: Desarrollo de software. Antipatrón. Caballero de tres cabezas « Jummp
Pingback: Desarrollo de software. Antipatrón. Quiero estimaciones ahora « Jummp
Pingback: Desarrollo de software. Antipatrón. Morir planificando « Jummp
Pingback: Desarrollo de software. Percepción, abstracción, implementación « Jummp
Pingback: Desarrollo de software. Antipatrón. Blowhard Jamboree « Jummp
Pingback: Desarrollo de software. Antipatrón. Los clientes son idiotas « Jummp
Pingback: Desarrollo de software. Antipatrón. Entrenar al entrenador « Jummp
Pingback: Desarrollo de software. Las empresas de desarrollo de software, calidad, cambio de modelo « Jummp
Pingback: Desarrollo de software. Antipatrón. Requisitos esparcidos por la pared « Jummp
Pingback: Desarrollo de software. Si los usuarios quieren, hay sistema « Jummp
Pingback: Desarrollo de software. Fuerza de rozamiento o fricción « Jummp
Pingback: Desarrollo de software. Antipatrón. Otra reunión más lo resolverá « Jummp
Pingback: Desarrollo de software. Agilidad vs fricción « Jummp
Pingback: Desarrollo de software. Antipatrón. Programador discordante o programador con productividad neta negativa « Jummp
Pingback: Desarrollo de software. Antipatrón. Tormenta de reproches « Jummp
Pingback: Desarrollo de software. Antipatrón. Simulacro de incendio « Jummp
Pingback: Desarrollo de software. Antipatrón. El traje nuevo del emperador « Jummp
Pingback: Desarrollo de software. Antipatrón. No es mi trabajo « Jummp
Pingback: Desarrollo de software. Antipatrón. El proceso es el entregable « Jummp
Pingback: Desarrollo de software. Antipatrón. Otro programador más « Jummp
Pingback: Desarrollo de software. Antipatrón. Standing on the shoulders of midgets « Jummp
Pingback: Desarrollo de software. Antipatrón. La cultura del héroe « Jummp
Pingback: Desarrollo de software. ¿Qué es caro?, ¿qué es barato? « Jummp
Pingback: Desarrollo de software. Antipatrón. Equipos fungibles « Jummp
Pingback: Desarrollo de software. Antipatrón. Solicitud dirigida « Jummp
Pingback: Desarrollo de software. Agilidad no es improvisación « Jummp
Pingback: Desarrollo de software. ¿Estamos condicionados por el mercado? « Jummp
Pingback: Desarrollo de software. Antipatrón. Gestión gaviota « Jummp
Pingback: Desarrollo de software. ¿Ser ágil es una moda? « Jummp
Pingback: Desarrollo de software. Antipatrón. Empire building « Jummp
Pingback: Desarrollo de software. Antipatrón. Ingeniería de diapositivas « Jummp
Pingback: Desarrollo de software. Antipatrón. Los arquitectos no programan « Jummp
Pingback: Desarrollo de software. Antipatrón. Abracadabra « Jummp
Pingback: Desarrollo de software. Antipatrón. Guerra de Vietnam « Jummp
Pingback: Desarrollo de software. Antipatrón. Trampas evitables « Jummp
Pingback: Desarrollo de software. La crisis del desarrollo a medida « Jummp
Pingback: Desarrollo de software. Antipatrón. Eso no es realmente un problema « Jummp
Pingback: Desarrollo de software. Antipatrón. Arquitectura o programación orientada a obstáculos « Jummp
Pingback: Desarrollo de software. Enfoques iterativos incrementales y el concepto de proyecto, ¿conflicto? « Jummp
Pingback: Desarrollo de software. El miedo a la responsabilidad « Jummp
Pingback: Desarrollo de software. La agilidad y el nirvana « Jummp
Pingback: Desarrollo de software. Contratación ágil II « Jummp
Pingback: Desarrollo de software. Contratación ágil I « Jummp
Pingback: Desarrollo de software. La experiencia es la acumulación de experiencias, no de años « Jummp
Pingback: Desarrollo de software. Antipatrón. Gestor pero no líder « Jummp
Pingback: Desarrollo de software. La evolución en el enfoque del proceso de desarrollo « Jummp
Pingback: Desarrollo de software. Antipatrón. Orientación al medallero « Jummp
Pingback: Desarrollo de software. Contratación ágil IV « Jummp
Pingback: Desarrollo de software. Contratación ágil V « Jummp
Pingback: Desarrollo de software. Agilidad, orientación al producto y orientación al proyecto « Jummp
Pingback: Desarrollo de software. Agilidad y la evolución en la incertidumbre en el proyecto « Jummp
Pingback: Desarrollo de software. La agilidad es un paraguas en la tormenta « Jummp
Pingback: Desarrollo de software. Antipatrón. Interbloqueo « Jummp
Pingback: Desarrollo de software. Agilidad en la interlocución « Jummp
Pingback: Desarrollo de software. Y esto, ¿quién dijo que se hiciera así? « Jummp
Pingback: Antipatrones I: Antipatrones de gestión « Java Mania
Pingback: Desarrollo de software. Milt Bryce. Gestión proactiva y gestión reactiva « Jummp
Pingback: Ser receptivo a escuchar y a las buenas prácticas y evitar martillos de oro y balas de plata « Jummp
Pingback: Master Executive en Gestión de las Telecomunicaciones y Tecnologías de la Información » Predicciones de Arun Gupta
Pingback: Desarrollo de software. Ciclo de vida clásico o en cascada | Jummp
Pingback: Desarrollo de software. Sprints e implicación | Jummp
Pingback: Stephen Hawking. Adaptación al cambio | Jummp
Pingback: Desarrollo de software. Delimitar el alcance del proyecto | Jummp
Pingback: Desarrollo de software. Ciclo de vida por prototipos | Jummp
Pingback: Mary Poppendieck. Tom Poppendieck. La asignación de personas a proyectos a tiempo completo o a tiempo parcial | Jummp
Pingback: Desarrollo de software. Maleabilidad | Jummp
Pingback: Desarrollo de software. Maleabilidad | StackPointerBlog
Pingback: No confundas presión con efectividad | Jummp
Pingback: No confundas presión con efectividad | StackPointerBlog
Pingback: Desarrollo de software. No hay magia tras los procesos | Jummp