Voy a opinar sin saber exactamente si es apropiado hacerlo. La lista tiene tan buen nivel, que invita a participar, aún cuando no se es abesado en muchos de los temas propuestos. En cuanto a este en particular, puedo hablar desde la experiencia sin acreditar muchos téminos académicos. Me parece que en ambos casos, esto responde al grupo de trabajo. Como para todoas las cosas, existen enfoques desde el punto de vista de quien toma el tema. En mi caso tengo formación en publicidad y tecnologia educativa, y un par de proyectos en curso relacionados con la educación a distancia, el e-learning y la usabilidad. Mi representación de ambas metodologías, si las son, es que pueden ser aplicadas según el equipo de trabajo. Se me hace que a mayor gente, existe la necesidad de control, para no caer en el caos, sin que esto implique necesariamente, el desvincularse emocionalmente del producto.
El factor grupo es fundamental a la hora de los desarrollos. En mi caso particular somos un grupo pequeño de personas, en donde con solo ponernos de acuerdo en ciertas cuestiones técnicas propias de un desarrollo, salimos al trabajo. Asi las cosas no dejamos que por esto, cualquiera sea el producto a desarrollar (no me gusta mucho la palabra producto) nos gane el desorden y la desorganización. Para un caso puntual en donde trabajamos cuatro personas, utilizamos un Trac para colocar los objetivos, las caracteristicas necesarias y deseables del producto, y las referencias, tanto bibliográficas, papers, etc como de desarrollos similares, a modo de imagen de marca. Así las cosas tambien nos viene bien el utilizar los tickets para poder avanzar sabiendo quien es el responsable de cada cuestion que surge, y en la tranquilidad de que esa persona lo va a solucionar, sin la necesidad de estar todos trabajando en el mismo espacio físico al mismo tiempo. No se si es una metodología, seguramente si, pero es un modo que el grupo de trabajo encontró adecuado y cómodo, en el que todos estamos de acuerdo, y en el que el único jefe es el objetivo final y cada una de sus metas reflejadas en las versiones. A veces me da un poco de angustia el pensar que luego de tanto trabajo, el usuario final este conforme y quienes dictan los requerimientos (autoridades, jefes etc) no lo estén. Parece descabellado, pero, vamos que pasa bastante seguido. Tengo una palabra que me gusta usar mucho, y es absolutismo; es algo muy común en nuestra profesión discutir por un punto de vista o por otro y cerrarnos a, tal vez, otras muchas opciones disponibles. Como en cualquier proceso de calidad, la clave esta en las personas, y en la cultura de trabajo en equipo, si un equipo es unido, se conocen, y van tras un mismo objetivo, no veo el porque de un fracaso. Los puede haber, somos falibles, pero un buen grupo humano se sobrepone a estas cuestiones. Entonces agregaría para complicar un poco mas el hilo el grupo humano vs producto vs proceso. Como todas las cosas, y siendo un poco bastante constructivista en esto, el proceso como el producto son herramientas de las que disponemos para llegar a un fin específico. Una o la otra, siempre dependerá de quienes las usen y como las usen. Saludos a todos.- Alejandro Karpich Zardalevich -- http://www.karpicius.com.ar http://www.catfish-project.com.ar -- On 11/21/06, César Astudillo González <[EMAIL PROTECTED]> wrote: > > A mí me parece una encarnación más del clásico debate "reduccionista > versus > holista". Si prestas atención exclusiva al proceso, y lo haces en tal > grado > que te haces acreedor de caricatura, acabas siendo demasiado cartesiano > (aquello de trocear el problema complejo en varios problemas más simples y > creer que con eso ya lo has hecho todo), y caes en el peligro de la > sinergia > negativa: cuanto ensamblas las partes, te encuentras con que la suma de > las > partes es menos que el todo. Problemas de integración, estrategia > psicológica de limitación de los daños ("eso no era mi responsabilidad"), > producto Frankenstein que no satisface a nadie, "un camello es un galgo > diseñado por un comité", etcétera. De eso hay que huir como de la peste. > La > sangre huye de tus miembros y se te pone la piel gris y cerúlea. Y > empiezas > a caminar dando tumbos y a comer cerebros. Tengo un amigo aeronáutico que > me > cuenta cosas flipantes del proyecto del Airbus 380 e n ese sentido: ¡ríete tú > de la web 1.0! > > Por el contrario, si te centras en el producto (y eres lo bastante > competente como para recorrer el camino sin "lastres metodológicos" <-- > ¡qué > peligro esta concepción!), y lo haces en tal grado que eres objeto de > caricatura, acabas dependiendo demasiado del "talento" (esa cosa tan > inasible e intermitente) de personas individuales que "lo tienen todo en > la > cabeza". El resultado acaba dependiendo demasiado de los biorritmos de las > personas que intervienen en el equipo, y tu "truck number" (el número de > personas que, si se mataran en un camión, fastidiarían tu proyecto) se > hace > alarmantemente bajo. Por otra parte, y esto último lo digo con cierta > timidez, porque generalizar es errar, me da en la nariz que si llevas más > de > tres proyectos consecutivos centrados en el producto, y te están saliendo > más o menos bien, una de dos: o la fluidez con que desarrollas obedece a > cierta autosimilitud de los proyectos que permite la reutilización de > conocimiento y/o activos, en cuyo caso quizás estés transitando por > caminos > demasiado familiares (¡corre Forrest! ¡huele a factoría!) o es que has > encontrado, por primera vez en la historia de la computación, la famosa > "bala de plata". Y cuando oigo hablar de una bala de plata, siempre me > pregunto qué peaje estás pagando (aunque puede que creas que ninguno: hay > hipotecas que tienen periodo de carencia). > > Por otra parte las metodologías son como el Flash: deben su mala fama a la > mucha gente que las usa mal. Si quieres innovar, o te gusta jugar a la > ruleta rusa o tienes que usar metodología (implícita o explícita), lo que > pasa es que a lo mejor inventas una nueva casi cada vez. No se me ocurre > otra manera de adentrarte en caminos inexplorados. Como dijo Roosevelt, > "en > la guerra he aprendido que los planes no sirven para nada, pero la > planificación es imprescindible". Y como dicen los ingleses, "no hay nada > más práctico que una buena teoría". Lo que necesitas es agilidad para > adaptar la metodología a los descubrimientos que vas haciendo, saltarte > pasos si crees que no van a aportar valor, dinamitar un problema > inesperado > con un barreno metodológico que a lo mejor no habías puesto en tu equipaje > de partida. Y estar habilitado para justificar tus decisiones si al final > se > revelan erróneas: la mayoría de los clientes no se conforman con el "en > aquel momento parecía una buena idea". O sí se conforman, lo que pasa es > que > luego no repiten. > > De todos modos, seguro que la gente de Knapp en el fondo usa mucha > metodología y la usa con flexibilidad y sentido común. A mí con Alberto me > pasa que creo tanto en él como para, a veces, no creerme lo que dice :-) > > César Astudillo > > > _______________________________________________ > altas, bajas y modificaciones: > http://www.cadius.org/lista/opciones.html > _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
