La administración tradicional en el desarrollo de software

_r1_c1 Recién acabo de leer un post en un foro de Microsoft que hace referencia a un artículo en el cual se pretende hacer una analogía entre el desarrollo de software y la creación de una película. Aquí el artículo

Debo reconocer que el artículo es muy bueno, pero similar a muchos que hacen analogías con otros procesos de desarrollo y tratan de acoplarlo al de software.

Si bien, como dije, el artículo es interesante, mantiene la idea de que los modelos "administrativos tradicionales" pueden ajustarse al del desarrollo de software. Esto es, enfocar al desarrollo de software con la continuidad de procesos, y otorgando mayor peso a las típicas cabezas de la pirámide administrativa, y dejando relegados a los productores del mismo software como una "innecesidad", esto es, como el único elemento intercambiable y de mayor versatilidad.

Personalmente, creo que estos modelos de desarrollo, tratando de generar analogías con otras industrias, o procesos (Mas allá del artículo que lo compara con hacer una película), como la de procesos industriales, con controles y supervisión a alta escala, son totalmente desacertados. Si no, veamos los fracasos constantes que tienen los proyectos de software, y muy pocos, casi por azar, llegan a buen puerto.

Pienso que los proyectos de software comenzarán a tener mayor existo cuando el enfoque de pesos cambie de la administración tradicionalista, y se considere al desarrollo de software como una nueva forma de administrar proyectos. O sea, hasta ahora, solo se han intentado mudar los procesos industriales a una materia que tiene no mas de 40 años funcionando.

En el momento que se tome conciencia que un software esta compuesto por líneas de código, y no por controles sobre el avance, creo que en ese momento la administración cambiara y los proyectos tendrán un mejor resultado.

Ojo, con esto no quiero decir que los procesos y controles aplicados actualmente deberían dejar de existir, pero el peso de importancia en ese proceso, esta totalmente fuera de foco.

Veo proyectos constantemente donde tienen mayor importancia el reporte de horas, o la creación de mediciones, que el resultado del proyecto en si. Como resultado, proyectos desgastantes, código ineficiente, tiempos de desarrollos casi infinitos, rotación de personal constante, y un largo etc. Obteniendo, proyectos cancelados, tiempos sobre valuados, costos elevados sin sentido, y una calidad pobre. Aunque, en la recolección de mediciones, se diga lo contrario.

Para dar un ejemplo final, después de pasar por cientos de procesos de testeo de producto, este deja de arrojar errores, entonces, se considera que la calidad del mismo es elevada, aunque, internamente, el código solo contiene un parche tras otro, para subsanar estos errores, en definitiva, es como tener un auto recién salido de fabrica, pero que tiene capas y capas de pintura arriba para tapar los constantes errores de calculo en las máquinas que se usaron para producirlo, ya que cortaban mal el material, o hacían huecos por error donde no debían hacerlo.


6 comentarios on “La administración tradicional en el desarrollo de software”

  1. Marco Andres dice:

    Haciendo una acotación.
    Si bien el proceso de desarrollo y controles son muy importantes estoy de acuerdo con lo que dices que se les da demasiada importancia, a tal punto que, para realizar una modificación que puede llegar a tomarnos 2 minutos, debemos pasar por una máquina de burocracia que incrementa en varios dias esos dos minutos.
     
    Pero, quiero destacar que eso no es culpa del proceso en si, sino de aquellos que no lo aplican en la medida justa a la organización, a la madurez de la misma y a las herramientas que ayuden a llevar y mantener el proceso de una forma automatizada (en medida de lo pisoble).
     
    La intención no es la de hacer de abogado del diablo, soy revelde y contumas de cualquier tipo de control, pero, si vamos a trabajar en serio hay que tener un minimo de madurez en la forma de encarar los proyectos de software, esta madurez se ve reflejada en la forma que se encara un proyecto desde su planificiacion, gestion, control, etc. hasta los patrones y arquitectura a ser implementada, covertura de lineas de codigo y convenciones de nomenclatura.
     
    Muchos pueden decir "… si claro , eso solo pasa en las peliculas…" pero es posible siempre y cuando estemos dispuestos a mantener una postura acorde a la situacion y tener vision al momento de tomar las desiciones.
     
    Quiero rescatar, ademas, que la calidad de un proyecto de software no debería ser medida por la cantidad de evidencia de la gestion, administracion e implementacion del mismo, sino tambien por el proceso post proyecto, es decir, por el mantenimiento y servicios de soporte del mismo.

  2. Matias dice:

    Ojo, no digo que se le da demasiada importancia. Sino, que se le da un valor a una manera equivocada de administracion.
     
    Lo que planteo es el hecho de que, por un lado, se le quita valor a una de las partes mas importantes del desarrollo de software, esto es, el mismo desarrollador del software. Se lo trata de maquillar para argumentar que es un proceso industrializado, lo que le quita mas valor aun. Y por otro lado, se pretende administrar un proyecto de software con tecnicas traidas de otras especialidades, que definitivamente son incompatibles.
     
    Los procesos formales de desarrollo de software intentan simular una realidad industrial inexistente en lo que nosotros hacemos. Se pretende estandarizar la forma de realizar un proceso, creyendo en los puntos en comun, pero estos puntos no son tan comunes de un desarrollo al otro.
     
    Es como tener una banda de produccion de automoviles, donde en cada seccion se realiza un proceso especifico. Por ejemplo, hacer una puerta de dimensiones especificas, con otras secciones que pintan esta puerta de uno de los 10 colores especificados, otra seccion donde se ensambla el chasis y el motor, y asi una sucesion de etapas para la construccion del vehiculo.
     
    Ahora, esto seria estupendo, si tienes que producir miles de unidades identicas. Pero que pasaria si por un lado, el vendedor le dice al cliente que puede elegir cualquier color, mas alla de los 10 pre programados, o que puede elegir no un auto, si no, una moto, o una silla? Sin querer llegar a las analogias con otras industrias (no me gustan). En el software, estos parametros cambian de un producto a otro. Y es mas, en un desarrollo de software, su codigo, esta directamente relacionado al pensamiento del que escribe sus lineas, por ende, obtendras resultados, desde sus entrañas completamente diferentes, por mas estandares y procesos que se quieran imponer.
     
    Entonces, pretender que el software es una sucesion de procesos repetibles, estaticos, inamovibles, es seguir con la linea de pensamiento administrativa tradicional. O sea, como deciamos cuando estabamos en nuestros pagos: Hoy venden autos, y mañana papas. Esto es, que administran estas ventas de la misma forma, sin importar lo que se vende.
     
    A lo que voy es que, en el desarrollo de software no puedes pretender que un desarrollo se adapte a los 10, 20 o 100 procesos que tengas, fijos, estaticos, y que llegado al caso, puedas intercambiar como piezas o maquinas de esta banda transportadora.
     
    Por supuesto, este modelo administrativo te lleva al pensamiento comun, como por ejemplo: Mete a un excelente programador como tester. Programadores encuentro a montones, si total, es hacer lineas de codigo. No tenemos tiempo para plantear la arquitectura de la aplicacion, lo importante es que el cliente quiere el producto rapido. O el que me encanta: Como toda empresa de desarrollo de software, es natural que las personas se queden horas despues de culminadas sus horas de trabajo normales.
     
    Esta ultima, en especial, radica en las fallas administrativas de este modelo, donde el personal debe quedarse horas extras, porque segun lo planificado, un software similar, tomo X cantidad de horas. O, segun lo estimado, este producto deberia contener Y lineas de codigo, entonces, para hacer Y el tiempo es X.
     
    Como si colocar un IF antes o despues de un WHILE fuera tan tivial que pudiera ser 100% automatizado.
     
    En resumen, lo que planteo es que los pesos o mejor dicho, el enfoque de relevancia de un proyecto de software esta totalmente fuera de foco. Al punto en que, los modelos "formales" de desarrollo sobrecargan de tareas administrativas a las fuentes de produccion del producto, para recolectar informacion, y asi saber el estado de ese desarrollo. Si bien, la recoleccion de informacion es valida, definitivamente la forma en la que se hace, no es la correcta. Si no, hay que ver los "numeros" de proyectos exitosos, contra los que no. Lo mas interesante de estos numeros es que, donde la formalidad extricta se deja de lado por otros modelos, es donde se obtiene un mejor resultado.
     
    Y ahora si, por ultimo, desde mi punto de vista, un proyecto exitoso no es necesariamente un proyecto entregado a tiempo, sino, un proyecto en el cual, ademas de haber cumplido con lo que el cliente pretendia, la salud del mismo fue, justamente, saludable. Esto quiere decir que, un proyecto saludable NO ES, un proyecto entregado a tiempo, pero a 16 horas diarias por recurso.
     
    Por ende, la madurez no es representada por la formalidad estricta, que te lleva a seguir un proceso al pie de la letra. La madurez, para mi, es representada por la capacidad de producir una modalidad de trabajo saludable, con objetivos claros, y con resultados elevados en calidad de producto, y mas aun, de codigo. Por esto, se es mas maduro cuando se tiene una mayor capacidad de adaptacion en un modelo que por cada proyecto, representa una nueva forma de hacer las cosas. Indudablemente, esto se logra colocando una maquinaria alrededor de cada proyecto que de soporte a la creacion del mismo, y no, con la simple recoleccion de numeros y palmadas en la espalda por cada "release", sin importar que hay dentro de ese "release".

  3. Dolo dice:

    Respecto a tu nota, no me parece del todo certera, ya que cualquier proceso institucionalizado debe ser lo suficientemente flexible para que una empresa pueda adaptarlo a cualquier desarrollo. no imorta si utilizas CMM, CMMI, alguna norma ISO: cualquier modalidad de trabajo adopatada que te permita mejorar la calidad de trabajo no debe limitar el desarrollo de un producto o un proyecto, el proceso empleado debe permitir (en base a sus especificaciones) que una empresa realice su trabajo de forma eficaz y eficiente. Si un proceso no permite realizar este tipo de desarrollos, es porque no es bien utilizado; cualquier proceso debe ser modificado constantemente, ese es el fiel refejo de que el mismo esta en ejecución. Si un proceso no tiene mejoras es porque no esta en uso.
    Un proceso como CMMI no te va a decir "como hacer tu trabajo", te va a dar los lineamientos o buenas prácticas para que lo lleves a cabo, son las mismas empresas quienes se vuelven presas de sus definiciones.
    Respecto a tu comentario de que "…después de pasar por cientos de procesos de testeo de producto, este deja de arrojar errores, entonces, se considera que la calidad del mismo es elevada, aunque, internamente, el código solo contiene un parche tras otro", eso no es culpa del proceso, eso es la calidad con la que trabajan los desarrolladores.
    Yo he escuchado decir en muchas oportunides que "el cliente decide si pagar o no la calidad de un proyecto, o las horas de testing". Creo que es un error muy grave tener ese concepto, porque más allá de que "vendas un fiat 600 o un ferrari, ambos tienen que funcionar correctamente: arrancar, ponerse en marcha, frenar, acelerar, hacer los cambios…". Hay diferencias de confort?, si. Hay diferencias de performance? si. Hay muchas diferencias entre ambos productos, pero los dos tienen que funcionar correctamente, más allá de las especificaciones de cada uno. 
    Es importante trabajar con calidad, sin importar que metodología adoptes. lo importante es encontrar un equilibrio para que la metodología implementada no te limite y complique mas el trabajo, en lugar de optimizarlo. No importa si tus proyectos son de 100 o de 10000 horas, lo importante es hacer bien las cosas con una metodología de trabajo que sea lo suficientemente flexible para permitir que ambos proyectos tengan la misma calidad de producto.
    Hacer las cosas bien te garantiza mantener tu nombre por encima de comentarios mediocres de la competencia.

  4. Matias dice:

    Dolo, lamento disentir con esto. Pero veo, por un lado, que no estoy pudiéndome explicar, y por otro, que hay una aceptación errónea que dice que el Proceso es sinónimo de calidad.
     
    Con respecto al ejemplo que das del Fiat 600 y la Ferrari, definitivamente cada uno de ellos debe cumplir con objetivos pre plateados, pero el problema es que ambos no pueden ser realizados con el mismo proceso.
     
    Y aquí es donde veo que se falla en entender que pasa con estos procesos "formales". Justamente, dices que "No importa si tus proyectos son de 100 o de 10000 horas". Acá hay otro error, un proceso no es necesariamente lineal, y no puedes medirlo simplemente por el tamaño de "líneas de código", o por la cantidad de horas.
     
    La cantidad de horas puede representar una medida del esfuerzo que le vaya a poner, por el tamaño, y otras cualidades, pero un proyecto no es igual a otro.
     
    El proceso formal pretende o cree que solo intercambiando algunas piezas dentro de la maquinaria, se pueden realizar un proyecto totalmente nuevo. Esto es como pretender que de la misma línea de producción salga un Fiat y una Ferrari, con la única esperanza de que, la Ferrari se vea mas linda, y sea mas confortable, encienda, y funcione para adelante.
     
    Es posible que si quieres hacer un Fiat 600 en una instalación de Ferrari, tengas que cambiar todas las maquinas de la línea de producción.
     
    Y la otra cosa que planteo es la idea equivocada de que dentro de un proyecto de desarrollo de software tiene mas peso jerárquico, lo que lleva a tener mas peso y privilegios, el área de testing, que la de desarrollo. Como bien dices "eso es la calidad con la que trabajan los desarrolladores". O sea, muletillas muy comunes cuando se pone el peso del producto en el lugar errado.
     
    O sea, el desarrollador solo hace código… cuanto tiempo puede necesitar… moveme este botón, si es una pavada.
     
    Esto lleva a otros situaciones como: Ya me hiciste el reporte semanal, en una herramienta lenta, que solo traspasa los datos de tu trabajo a un excel? No, no me dio el tiempo. COMO QUE NO??? Eso es primordial para el proceso. Bueno, ahora te lo hago. (2 Horas después). Ya esta listo… Y el requerimiento que tenias que entregar hoy? No, para, he estado 2 horas haciendo este otro trabajo…. NOOOO YO NECESITO ESTE REQUERIMIENTO HOY!
     
    U otras como: Haceme, el reporte de horas. Vamos a una meeting para hablar sobre los casos de test. Necesito que me hagas esta presentación. Este otro documento, tiene que estar listo para dentro de 1 hora.
    Ok, Ok… y cuando programo?
     
    Y finalmente: Haaaaa, no se, si el programador no carga las horas correctamente (véase, si se quedo 12 horas, que sean 12 horas), el se va a ver perjudicado en desarrollos futuros, porque esos serán los datos que se usaran para futuras planificaciones.
    Entonces, el desarrollador carga como tiene que ser, y ahí viene el ataque del administrador, diciéndole porque hizo tantas horas.
     
    Entonces, de nuevo, y por eso el grafico que puse en la entrada. Las empresas de software trabajan con una pirámide al revés, o sea, ponen más importancia en los lugares donde no se fabrica el producto. Y luego, salen comentarios como los que mostré antes, donde el de más arriba se lava las manos, creyendo que esa acción no lo afecta. O pensando que si se sigue un proceso se garantiza la calidad, o creyendo que mientras pase los requerimientos iniciales, sin importar que hay dentro (en líneas de código), estará todo bien.
     
    En definitiva, lo que planteo es que, cada producto de software no es igual al otro, y que la relevancia esta en el que hace las líneas, no en el que saca las métricas. Por ende, el desarrollador no debe ser molestado con trabajos burocráticos, ya que este debe enfocarse en el código que hace, para que lo haga correctamente. Pensar entonces, que la calidad es algo que se adquiere gracias a un proceso, o que el hecho de que la calidad de las líneas de código este directamente relacionado a una idea de maldad por parte del programador, me parece que es porque aun se esta encandilado con la teoría de procesos, y aun no se ha metido las manos en el barro.
     
    Este es un paper que me paso Lucas Ontivero, de un tipo que hace como 15 años, hablaba de aquello que hoy aun se teoriza. Si no se nota diferencia con lo que pasa en la actualidad en los desarrollos, entonces deberíamos realmente preocuparnos. http://www.research.ibm.com/journal/sj/324/griss.pdf

  5. Lucas dice:

    Quiero aportar algunas cosas a este asunto.1.- Empezar por aclarar que ni ISO ni CMM/I no son procesos ni metodolog’ias. Nadie adapta una ISO. O te adaptas a la ISO (como sea), o no te adaptas pero la norma es un molde al que uno se adapta, no al reves.  2.- Un proceso no puede estar institucionalizado (en realidad si puede pero no debe) porque eso lleva implícita la creencia de que todo el software es igual y se construye igual y tiene las mismas prácticas y eso solo es cierto para quienes nunca han hecho software. La verdad es que un antivirus, un procesador de texto, una aplicación de correo electrónico y un CRM web no tienen nada que ver. 3.- Cuando dicen "Software que funcione perfectamente" están pifiandole demasiado feo porque esa es solo una dimensión menor; la de las características funcionales de la calidad que son las más básicas y las que conllevan menos esfuerzo. Es decir, son las mas baratas. La performance, seguridad, toleracia a fallos, usabilidad, disponibilidad y sobre todo la mantenibilidad (y otras tantas) son verdaderas m’etricas de la calidad. Porque un soft que salga rápido y solo funcione bien lo hace cualquiera total despues lo mantiene magolla. Barato hoy es bien caro mañana. Esta es otra de esas cosas que solo te lo da la experiencia de trabajar haciendo software. 4.- Sobre la calidad con la que trabajan los desarrolladores solo puedo decir que en algunos casos es verdad, como en todo, la excelencia es la excepción aunque en el contexto que lo han expresado aquí, los parches se deben a TODOS y no solo al que hace el trabajo. Debe ser bastante sencillo demostrar que si le damos a alguien 15 minutos para que me barra toda una manzana, lo hará pesimamente mal independientemente de su excelente predispocisión, velocidad, conocimientos o cualquier otra factor. Esos 15′ equivalen en software a poco tiempo, requerimientos incompletos, poca capacitación, malas herramientas, etc.5.- "Encontrar un equilibrio para que la metodología implementada no te limite y complique mas el trabajo" Dios mio!!!! pero acaso las mejores prácticas que llevan implicitas las principales metodologias no son justamente para AYUDAR!? Es que acaso hay que tratar de encontrar equilibrios para que no compliquen mas el trabajo!!!?6.- "Metodología
    de trabajo que sea lo suficientemente flexible para permitir que ambos
    proyectos tengan la misma calidad de producto" esto es una cosa increible. Es tal la confusión aquí que es irrespondible porque para ello necesitaria de experiencias compartidas de trabajar haciendo software en una variedad de empresas con distinta idiosincracia sobre lo que calidad significa. Si alguien que trabaja en una empresa supermadura (con CMMI 5 + ISO 9001 + … + ) te dijera que en su empresa hace la peor basura del mundo con el mejor proceso sobre la faz de la tierra, creele. Esto solo demuestra el punto. No hay relación alguna entre proceso y calidad de producto.7.- "Es importante trabajar con calidad" este es un decubrimiento interesante. Ahora, quien hace las cosas bien? un proceso o una persona? 100 micos con un proceso institucionalizado liberará software de excelencia?Es muy fácil, para opinar de software hay que dedicarse a ello. Cualquiera se aprende las practicas de CMMI y se lee los libros de Crosby, Juran, Deming y demás maestros. Es como leerse 4 o 5 libros de ajedrez y cree que con ello podes ganarle una partida al viejo de la plaza! Es un absurdo.Saludos.

  6. Dolo dice:

    Lamento disernir con tu postura y respondo a cada una de ellas:
     
    Primero que nada trabajo haciendo software, no estoy ni abogada, ni contadora.Y no opino desde el escaso conocimiento de haber leido una vez un pdf de CMMI.
     
    En segundo lugar la mayoria de las empresas que tienen definido un proceso para llevar a cabo su trabajo (en este caso estamos hablando de desarrollo de software) lo tienen institucionalizado, sino, cada uno haria su trabajo como mejor quisiera (aunque esto muchas veces se parezca a la realidad de nuestro dia a dia).
     
    Cuando hablamos de "Calidad de un producto", no solamente me refiero a "una funcionalidad especifica", la calidad de un producto la da "la totalidad del mismo", la cual incluye todo lo que mencionas: performance, seguridad, etc. Es cierto lo que decis respecto de mantener una aplicacion, lo que hoy se hace en tiempos acotadisimos y a costos baratos (para achicarle el tiempo y el bolsillo al cliente) despues es un gran dolor de cabeza.
     
    Respecto a las limitaciones que te da la implementacion de un proceso, depende pura y exclusivamente de como vos lo definas. El ejemplo mas claro es CMMI: CMMI te dice "que debes hacer", pero no te dice "como hacerlo". Sin ir mas lejos, citando "When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectionaltraceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.Requirements traceability can also cover the relationships to other entities such as intermediate and final work products, changes in design documentation, and test plans. The traceability can cover horizontalrelationships, such as across interfaces, as well as vertical relationships. Traceability is particularly needed in conducting the impact assessment of requirements changes on the project’s activities and work products." Ahora, si para mantener esta rastreabilidad usas un excel con 4 columnas, utilizas un sistema para gestionar requerimientos junto con una planilla, o la combinacion de n herramientas (porque en tu definicion de trabajo no supiste optimizarlo), eso no es culpa de CMMI, eso es falta de vision por parte de quienes definen su proceso.
     
    A lo que me refiero con que "utilizar una metodologia de trabajo que sea lo suficientemente flexible para permitir que ambos proyectos tengan la misma calidad", me parece que estas viendo mas alla. No es una cuestion de confusion, ni considero que sea irrespondible: Si una empresa hace basura, lo va a hacer igual, con o sin un proceso de trabajo. Si haces un buen trabajo, minimamente vas a tener en cuenta determinados aspectos a la hora de llevar a cabo el desarrollo del mismo, por mas que ese proceso este armado con 5 puntos o tengas un proceso de 80 documentos.
     
    Esta mas que claro que un proceso no lleva a cabo un trabajo, son los recursos (en este caso personas y la tecnologia). Las cosas no se hacen bien magicamente (ni mal tampoco). Cualquier desarrollo que es llevado a cabo por personas que trabajan con el objetivo de entregar un producto bueno (con todo lo que esto implica) lo van a hacer, siempre y cuando esa sea su forma (mas alla de que tengan o no un proceso definido). Es mas, ni siquiera tiene que estar escrito, cualquier persona que, minimamente tenga ciertas pautas de trabajo para hacer las cosas bien, es el pie incial. Ahora, si sos un chambon y te da lo mismo atar las cosas con alambre y pegarlas como puedas, eso es otra cosa.
     
    Con el mismo concepto, opino que cualquiera que aprende a programar leyendo un libro de Deitel, pero de ahi a que haga las cosas como deben hacerse, hay un gran abismo.
     
    Programar no es la unica pata que sostiene la mesa cuando hablamos de desarrollo de software, son varias patas las que sostienen la mesa, sino fijate cuando un desarrollador entrega una aplicacion en la que ni siquiera se hicieron pruebas unitarias (que es el error mas comun reportado por quienes hacemos testing). Esos son grandes desarrolladores? Ahora yo cito tu frase "Por Dios!!!!"
     
    Saludos


Responder

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