En nuestra empresa el enfoque lo tenemos claramente centrado en el
producto. No generamos entregables ni documentación porque no tenemos
cliente, somos nosotros mismos.
Lo que sí veo es que, con el paso del tiempo y el consecuente
crecimiento de la empresa, se echa de menos cierta metodología
interna. Antes para nosotros el wireframe era el nexo de unión entre
usabilidad y el resto de departamentos. Con éso era suficiente. El
prototipo hablaba por sí solo. Poco a poco me voy dando cuenta de que
quizá el wireframe (por muy explicativo que sea) se queda corto ya que
cada vez más, cualquier proyecto toca a más departamentos.
Yendo un poco más lejos, creo que las empresas pequeñas, en general
tienen un planteamiento de desarrollo más centrado en el producto. Las
empresas grandes, debido a la cantidad de departamentos que alojan y a
su estructura, van poco a poco centrándose en el proceso.
Será el tamaño de la empresa la clave de todo ésto? El tamaño importa?
Me preocupa pensar que sí...
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 en 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
>
--
Juan Leal
_______________________________________________
altas, bajas y modificaciones:
http://www.cadius.org/lista/opciones.html
