Llegamos a ustedes gracias a:



Conversando con...

Harold Hambrose, fundador de Electronic Ink, consultora especializada en el diseño y desarrollo de sistemas de negocios

El mal diseño de software inhibe el uso de aplicaciones de empresa

[28/09/2009] ¿Siempre se ha preguntado por qué los miembros de su equipo usan solo una fracción de los atributos y las funcionalidades que ofrece el generoso software corporativo de su empresa?

Harold Hambrose tiene la respuesta. En realidad, Hambrose, fundador de Electronic Ink, una consultora especializada en el diseño y desarrollo de sistemas de negocios, ha escrito un libro sobre los sesenta mil millones de dólares que, según sus cálculos, se desperdiciarán en los negocios de Estados Unidos durante el presente año fiscal debido al software mal diseñado.
El nuevo libro, Wrench in the System (ed. Wiley), da una mordaz mirada a las prácticas del negocio de desarrollo de software, especialmente los productos de proveedores de empresas. "Generalmente, los fabricantes de software confían en que sus productos tendrán éxito gracias a la fuerza de su tecnología", escribe Hambrose.
"Pero los productos que no llaman la atención de los usuarios pueden ser contraproducentes. Los usuarios tienen reacciones distintas cuando se topan con obstáculos creados por los sistemas de software (argot técnico, mensajes ambiguos, secuencias ilógicas o recarga visual)". Por lo general, se trata de conductas negativas que los usuarios (así como los CIO y los gerentes de aplicaciones) conocen demasiado bien, entre ellas: optar por alternativas de solución frustrantes y poco eficientes, hacer caso omiso del proceso de negocios o abandonar de plano la aplicación.
Hambrose estudió diseño gráfico en la Carnegie Mellon University y luego contribuyó con la interfase usuario del OS/2 de IBM y de la primera historia médica computarizada para First Data, según puede leerse en su biografía. Fundó Electronic Ink en 1990 y desde entonces ha trabajado con British Petroleum, Comcast, McDonald's, Research in Motion, y otras compañías de la lista Fortune 500 en temas de diseño de software.
En su libro, Hambrose no solo ofrece consejos sino que también explica cómo ciertos cambios de bajo costo en el desarrollo pueden marcar la diferencia. Thomas Wailgum, editor senior de CIO.com, conversó recientemente con Hambrose sobre las frustraciones de los usuarios, la pobreza de diseño que presentan la mayoría de paquetes de aplicaciones  y las razones que lo llevaron a escribir su libro.
"Quería darle a un público más numeroso las herramientas para enfrentarse a proveedores de TI de manera más eficiente y quizá también otorgarles un poco de poder para alzar la voz y decir: 'Este sistema me parece malo por tal y tal razón,'" señala Hambrose. "Espero que el libro no solo resulte atractivo para los CIO, sino también para los doctores, enfermeras, corredores de bolsa y quien quiera que esté luchando con sistemas que alguien puso en sus manos con las mejores intenciones".
¿Qué frases de rechazo ha escuchado de parte de potenciales clientes o proveedores de software?
En los entornos ERP más grandes, se oyen cosas como: "Ah, un equipo de diseño, seguro nos van a proponer que customicemos nuestro sistema Oracle o SAP". Lo cual no tiene nada que ver con la realidad. Nosotros representamos un método para configurar el prelanzamiento del sistema mejorando su posterior adopción y utilización.
Otro comentario corriente es: "En esta mesa tengo un grupo de analistas de negocio, ¿acaso no hacen ellos lo mismo que ustedes?" Pues no. En realidad, queremos que usted reemplace a sus analistas de negocios con diseñadores. Sabemos que ellos comprenden el negocio, pero el aporte de los diseñadores consiste en permitir que ustedes modelen el negocio de maneras diferentes, las mismas que le permitirán cambiar su forma de proceder con esta herramienta.
El último es: "¿No se puede resolver este asunto con algo de capacitación y cambios en la administración?" Nosotros estamos convencidos de que si usted nos hace caso, no le hará falta ningún tipo de capacitación, ni mucho menos cambios en el presupuesto administrativo.
¿Cuando surge la disyuntiva entre la estética de la aplicación y la usabilidad, cuál es más importante?
Hay una confusión en la industria de software respecto a usabilidad y diseño, que son dos cosas separadas. Hace mucho tiempo que la industria trabaja en torno a la usabilidad, desde que yo tenía 20 años. Han construido laboratorios de usabilidad y han contratado profesionales de usabilidad. Se trata de personas que vienen del mundo de la ergonomía, que evalúan la efectividad de un diseño en manos de una audiencia humana.
En realidad, la usabilidad es un subconjunto del diseño. Diseñar es un verbo que puede definirse como el hecho de inventar algo de cierta manera y con diversos resultados, uno de los cuales será la usabilidad. Otro resultado será la belleza. Pero ambos están interrelacionados.
Don Norman, experto en diseño y escritor, ha pasado por esa experiencia y comenta en uno de sus libros más recientes: "Las cosas bellas funcionan mejor." Las aplicaciones de software, sin embargo, parecen cada vez más feas.
¿Qué efecto producen el cloud computing y el software-as-a-service- al proveer aplicaciones en la web?
Para nosotros, un browser web no es diferente de, digamos, una aplicación creada en Visual Basic, o en cualquier otro entorno de desarrollo. Pero tengo la impresión de que una vez que las cosas aparecen en un browser web, la gente tiende a verlas como sitios web, y saben que para diseñar un sitio web es indispensable pensar en términos de diseño.
El problema de esta situación, sin embargo, es que hay numerosos sitios web sumamente preocupados por la estética o el aspecto visual, de manera que ahora encontramos en los browsers aplicaciones más atractivas, pero no necesariamente aplicaciones más utilizables. Han sido realizadas por diseñadores, pero solo desde el punto de vista estético. No han cambiado el proceso para que ambos conceptos vayan de la mano.
La popularidad del browser web, de la noción de banca en línea y de algunas de las más sofisticadas transacciones que la gente ejecuta en línea hace que algunas personas se pregunten diariamente: si yo tengo mi página en Facebook y llevo las cuentas de mi familia, cómo es posible que me resulte tan difícil entender la aplicación de contabilidad de mi empresa?
¿Además de Apple, hay otros proveedores de software corporativo que estén haciendo un buen trabajo en el campo del diseño de software?
Hemos encontrado varios sistemas dirigiendo negocios, y algunos fanáticos de software a cargo de los bancos más grandes así como muchas aplicaciones en la industria de servicios financieros; pero se trata de excepciones.
En cuanto a aplicaciones out-of-the-box, se me hace imposible mencionar una pieza de software realmente bien diseñada. ¡Suena terrible!
OK. Entonces, Apple. ¿Se considera usted fan de Apple? ¿Está impresionado por lo que han hecho como modelo para un diseño de éxito?
Se trata de una excelente compañía de diseño de productos. No hay duda de que sus monitores y sus teclados son objetos hermosos. Sin embargo, en lo que respecta a software, su sistema operativo y el iTunes, son más bonitos [que los de su competencia], pero no creo que representen una diferencia significativa de diseño respecto a un entorno basado en Windows.
Tengo la impresión de que el ingreso al espacio iPod, y el consiguiente lanzamiento de ese tipo de productos, significó un gran cambio para la compañía. Apostaron a ganador. El iPhone es un bello producto: el software y el hardware están tan estrechamente integrados que realmente se convierten en un solo objeto.
Pero volviendo al mundo de la PC: el software y el hardware son dramáticamente distintos. El software de Apple no es ni por asomo tan elegante como su hardware. Su sistema operativo, su desktop, presenta los mismos defectos de diseño que el desktop de Windows. No entiendo por qué no aplican sus exitosas prácticas de diseño de productos para diseñar su software.
En los círculos corporativos, la irrupción del dashboard ha sido muy significativa. Tanto los líderes de negocios como los gerentes quieren dashboard, aunque sus resultados no son parejos. Pero los CIO y sus equipos de desarrollo se ven en una situación muy difícil al tener que darle gusto a esta gente de negocios.
Es el mismo problema, solo cambian las fechas: los dashboard, los sistemas CRM o cualquier novedad que surja en el horizonte este mes. Los consumidores de la tecnología -el lado de negocios de la avenida- no saben cómo pedir lo que necesitan. Piden lo que quieren, que no es lo mismo que comprender lo que uno necesita. Al otro lado de la calle, el grupo tecnológico está presto para comprar o construir cualquier cosa que le pidan. 
Por eso en mi libro afirmo que lo que falta en este diálogo es el diseño. A nadie se le ocurriría preguntarle a un chofer cómo tiene que ser el próximo Mercedes-Benz, porque si bien los choferes usan la herramienta o el producto no saben qué podría hacerles daño. No saben cómo pedir innovación. Solo pueden describir su experiencia a través de lo que conocen. Las compañías de autos cuentan con grandes equipos de diseño que se encargan de atender estos pedidos pero además también hacen muchos otras cosas y, luego, aplican los procesos para asegurarse de que lo que están inventando sea adecuado antes de pasar a la línea de ensamblaje.
En lugar de eso, tenemos gente de tecnología que dice: "Adivine qué! Ahora que hemos puesto toda la data de la compañía en un solo envase, podemos sacarla y mostrársela de la manera que más nos guste". Y los ejecutivos responden: Ay sí, por favor, queremos un dashboard para poder ver eso". Y lo enchufan al desktop sin siquiera comprender lo que realmente necesitan estas personas. Buena parte de la tecnología de dashboard no es más que un fracaso abismal de los desktops corporativos, y no es porque se trate de una mala tecnología, sino que nadie tiene los medios para definir con precisión lo que estas personas necesitan y cómo necesitan que se les presente.
  
Usted cuenta que a veces acompaña a sus clientes a las entrevistas de evaluación de productos y demos de los proveedores. ¿Cómo reacciona el personal de ventas y contabilidad?
Lo odian. Se desorientan. En más de una ocasión han pedido que nos retiremos. Y eso se debe a la naturaleza de lo que hacen: vender sebo de culebra. Llegan con la aplicación customizada para un flujo de trabajo que el cliente le ha presentado, y como por arte de magia empiezan a dar clics. En este escenario, los usuarios hacen lo que cualquier ser humano haría delante de un software: dicen, "supongo que ya me las arreglaré", o "la informática no es mi fuerte" o "seguro que luego de la capacitación todo me quedará claro".
Ahí es que nosotros respondemos: "No. Ustedes conocen este negocio. He visto doctores en presentaciones de productos que se rascaban la cabeza diciendo "bueno, no estoy muy seguro de cómo funciona esto pero me imagino ya lo captaré". Ustedes se cuentan entre las personas más capacitadas de nuestra sociedad, y se han dejado confundir! Es ridículo. Deberían pararse y tirarle un tomate a ese tipo.
Al acompañarlos, los vamos guiando: hágales las preguntas que le da miedo preguntar. Pregúnteles por qué le han puesto ese nombre y no cualquier otro.
¿Para nuestros lectores, qué deberían tener en cuenta cuando, por ejemplo, se inicia el proceso de requerimientos para una aplicación de BI (business intelligence, inteligencia de negocio)? 
Sería bueno que fueran capaces de reconocer la oportunidad que tienen delante de ellos: están ingresando en el proceso del diseño de un producto. Esto mismo se ha realizado exitosamente en otras industrias, pero cuando se trata de desarrollo de software por lo general solo hay resultados muy pobres.
Entonces, en primer lugar: tome conciencia de lo que está haciendo. Está a punto de diseñar una herramienta; probablemente no está capacitado para hacerlo y la gente que lo rodea quizá tampoco lo esté. En realidad, tal vez las personas que lo rodean solo son capaces de hacer que las computadoras hagan cosas.
Usted está ante la misma oportunidad que enfrenta alguien que va a diseñar un rascacielos. Esto puede convertirse en un ícono del horizonte de la ciudad, o podría terminar derrumbándose y aplastando a los peatones. Más vale que ocurra lo primero. No olvide que este es un evento de diseño: en este punto podemos hacer que las computadoras hagan cualquier cosa. El mayor reto es hacer que las computadoras hagan precisamente lo que nuestro negocio y nuestros trabajadores necesitan.
Thomas Wailgum , CIO.com