El plan de Buzzfeed para 2020 es ser parte de la inspiración y de la transacción

La idea es diversificar las fuentes de ingresos y eliminar al intermediario.

Los ingresos en publicidad nativa de BuzzFeed cayeron de 60% en 2017 a 30% en 2019. El resto provino de otras fuentes de ingresos, como licenciar la marca (Tasty por ejemplo, en venta de libros de cocina o alimentos y todo lo relacionado), programática en todas sus propiedades y enlaces de afiliados (creando notas que recomiendan productos de empresas como Walmart o Amazon), así como seguir evolucionando y expandiendo esto a otras regiones.

El siguiente paso es eliminar al intermediario digital (Google y otros), de tal manera que, a partir del tráfico generado en su red de contenidos (la inspiración), los usuarios puedan comprar directamente a otros socios como hoteles o aerolíneas (la transacción), evitando que el usuario vaya a un intermediario para la búsqueda del producto y posterior compra. Ser una plataforma bussines-to-consumer (B2C) de pleno derecho.

Hay más en su plan, como la idea de formar comunidades que aporten valor o un mejor periodismo acompañado de la publicación de documentos y revelaciones. Curiosamente todas las áreas de Buzzfeed hacen dinero, menos News.

El plan completo publicado en Buzzfeed in 2020.

John Doerr sobre la definición de objetivos, al estilo Silicon Valley

Measure What Matters: OKRs: The Simple Idea that Drives 10x Growth por John E. Doerr (2018). También disponible en español y en Kindle. No tiene versión PDF. Recomendación: ★★★★★.

Mide lo que importa es un libro sobre cómo establecer objetivos y hacerlos funcionar en el mundo real. Define el modelo OKR (Objetivos y Resultados clave) como un contrato social cooperativo para establecer prioridades y definir cómo cuantificar el progreso. Pasar de los típicos objetivos fijos de revisión anual, por otros de una frecuencia trimestral o hasta mensual. En los que no hay miedo de cambiar sobre la marcha un objetivo o, de ser necesario, eliminarlo. Donde si varios objetivos se cumplen, es porque no fue lo suficientemente desafiante.

El autor propone desacoplar los objetivos de las bonificaciones, porque esto hace que los equipos busquen resultados claves conservadores buscando cumplimiento, limitando las oportunidades de innovación del producto.

Larry Page escribe el prólogo y se deshace en elogios hacia el autor. Los casos de éxito de Google, Chrome, YouTube o Intuit son la evidencia de la efectividad del modelo OKR. El autor nombra a Andy Grove como padre de los OKR y cuenta la experiencia de trabajar con él en Intel. Todos estos ejemplos ayudan al lector a entender cómo funcionan en el mundo real.

Aunque el modelo OKR es de una simplicidad aplastante y efectividad demostrada, viene con advertencia del autor: ser cauto con los objetivos que apliquen a su organización. Este tipo de modelos no son simples de implementar, en algunos casos toman varios trimestres y con mucho dolor corporativo.

No solo aplica a negocios digitales: por su naturaleza, su alcance es amplio y desafiante. Un libro indispensable de negocios y liderazgo.

No hay futuro

Esta industria necesita aprender algo del punk.

I

En 1977 los Sex Pistols lanzaban su sencillo ‘God save the Queen’, una canción protesta sobre la falta de oportunidades para la juventud británica de aquella época y su poca confianza en la monarquía. Esta canción fue un éxito inmediato. Por su letra controversial, la cadena BBC se negó a transmitirla,[1] pero su popularidad la hizo llegar rápidamente al número uno en diversos rankings musicales. El estribillo de la canción era “… No hay futuro, no hay futuro para ti …”.

La juventud de ese entonces interpretó esto como una llamada a la desesperanza: si no había futuro, quedaba conformarse con la situación actual, ya no quedaba más para una generación que había perdido la fe en sus lideres. La filosofía Destroy como norma de vida.

Johnny Rotten luego tuvo que salir a aclarar: el estribillo “No hay futuro” no es un llamado a la desesperanza, sino un llamado a la acción, al cambio. Si no hay futuro, hay que crearlo.

Si no viene el salvador, tienes que salvarte solo.

II

En 2006 Buzzfeed empezó a hacerse conocido por ser uno de los primeros sitios generadores de trafico gracias al volumen de notas con memes, listados de curiosidades y títulos diseñados para el clic. Viralizados a conciencia y apoyados en data, fueron un subidón de tráfico para el sitio. Lo que paso luego es harto conocido: medios creando volumen de contenido para ganar alcance (algunos llegando al borde de las noticias falsas sin ningún pudor)[2], y por otro lado buscadores y redes sociales afinando los algoritmos trabajando por eliminar esta visibilidad[3]. Al caer la visibilidad, se contrata gente que debe generar más volumen a toda costa para recuperar, y los algoritmos nuevamente reducen el alcance, y así sucesivamente.

Buzzfeed no siguió en el juego del volumen: redujo personal y continuó cambiando, experimentando con formatos más allá del pageview. Así, de un momento a otro, pasaron al video por suscripción, encuestas, generación de nuevas marcas (Tasty es un caso de estudio), recomendación de productos e ecommerce. Así las cosas, durante el periodo 2018–2019. se generarán 200 millones de dólares en líneas de negocio que no existían en 2017. [4]

https://www.amazon.com/Tasty-Seasoning-Gift-Set-McCormick/dp/B07QMZP2F9?ref_=ast_sto_dp

III

Los caminos de la experimentación son diversos, ya que usualmente esta es asociada con la creación de algo completamente nuevo y disruptivo. Usando metodologías tipo Design Thinking se puede llegar algo completamente novedoso. Aquí el riesgo es grande y la recompensa también, pero poner en marcha estos tipos de proyectos es costoso en tiempo, gestión e implementación.

Otro camino es adquirir tecnología o servicios y construir sobre estas. Es posible, pero esta limitado a la apertura de la plataforma y también es probable que un proveedor aplique restricciones en razón de mantener su negocio. Felizmente no siempre es el caso, Amazon Web Services es un ejemplo donde los medios no invierten en datacenters, sino arman toda la infraestructura tecnológica sobre la nube. Costo por uso.

La opción recomendada es la mejora continua. Comenzar con lo que se tiene: simplificar, optimizar, quitar, reemplazar y automatizar. Experimentar con un ciclo de implementar > medir > aprender usando procesos ágiles. Es la opción con menor riesgo o si hay poco presupuesto (y en muchos casos lo más realista).

Sea la opción que escoja, la experimentación debería (¡debe!) ser parte del día a día de la industria. En ocasiones ideales será motivada por la dirección de la empresa (si es el caso, aprovéchelo al máximo aunque sera para probar y que ese caro power point no termine en un cajón). En otras veces aparecerán iniciativas desde niveles más bajos de la escala corporativa[5]. Si realmente queremos innovar, estas iniciativas deberían ser evaluadas y darse la oportunidad de experimentar. Fomentar la actitud de resolver problemas a toda nivel debe volverse una actividad natural.

Las opciones están y las metodologías para lograrlo existen, le toca salvarse.


Imagen: Feral kid. Mad Max 2 (1981).

[1] https://en.wikipedia.org/wiki/God_Save_the_Queen_(Sex_Pistols_song)

[2] https://www.goodreads.com/book/show/41742717-no-hemos-entendido-nada?from_search=true

[3] https://www.sistrix.es/blog/google-core-update-septiembre-2019-primeros-resultados/

[4] https://www.niemanlab.org/2019/03/buzzfeeds-jonah-peretti-yes-to-scale-yes-to-platforms-still/

[5] https://www.thinkwithgoogle.com/intl/es-es/insights/los-ocho-pilares-de-la-innovacion/

Rápido y sucio

Por qué la excepción no debe hacerse regla.


Hubo una vez un maestro programador que escribía programas no estructurados. Un programador novicio, buscando imitarlo, también comenzó a escribir programas no estructurados. Cuando el novicio le pidió al maestro evaluar su progreso, el maestro lo criticó por escribir programas no estructurados diciendo: “lo que es apropiado para el maestro no es apropiado para el novicio. Debes entender el Tao antes de trascender la estructura”.

Tao del programador, 3.1


Una solución rápida y sucia es modificar una funcionalidad para salir del paso. Esto tiene el beneficio de que se soluciona el problema en el momento, pero, siendo una medida temporal, no corrige el problema de fondo. Esto es conocido como anti patrón de diseño de software.

Dado que es un último recurso, quick-and-dirty debe considerarse cuando:

  • Es una emergencia. Una medida de excepción. Una corrección imprescindible.
  • Se tiene un equipo que conoce muy bien su producto así como las consecuencias de cambios rápidos en la experiencia de uso.
  • Se cuenta con una metodología ágil que permita aplicar estos cambios rápidamente, sin sacrificar calidad y seguridad.

Pero hay que tener en cuenta que esto será tan alegre como jugar con el jabón en el baño de la prisión: es divertido hasta que se te cae. Si esto no se hace con cuidado, se pueden empeorar las cosas.

Además, este tipo de soluciones tiene desventajas adicionales: una es que, dada la velocidad de la implementación, se tiene la impresión de que esta solución es permanente y lo recursos luego se asignan a otras prioridades. Así se deja de lado implementar la real solución y se acumula deuda técnica.

La otra desventaja es que esto puede volverse una mala costumbre. Es decir, una vez hubo una solución rápida. Como fue rápida, seguro fue fácil. O sea, ¿podríamos hacerlo de nuevo, no? Estas falsas impresiones son peligrosas y terminan destruyendo sistemas enteros.


Aplicar soluciones de este tipo no tiene que ver con la agilidad. Una solución de emergencia es eso, de emergencia.

Una buena manera de evitar esto es evaluar el origen de los últimos cambios del producto: ¿tienes cambios de emergencia todas semanas (o días)? ¿son diversos los orígenes o son de una misma área? ¿es una necesidad interna o externa?

Si pasa demasiadas veces, hay un problema más grande y no necesariamente de software.

> Photo by Marc Kleen on Unsplash

Los podcast que hay que escuchar

Ahora hay más podcast, pero hay poco buen podcast. Paso una breve y arbitraria lista de algunos que estoy siguiendo ahora.


Filosos

Un podcast sobre filosofia en la cultura pop. Siempre te deja con preguntas, no te vas a aburrir.

Yo estuve ahí

Una selección de historias de la actualidad del equipo de Telemundo. La última cuentan sobre su entrevista exclusiva con Donald Trump, en otra hablan sobre el Instituto para Devolverle al Pueblo lo Robado. Todas buenas historias.

Plain english

Si estas aprendiendo inglés o te interesa ejercitar el idioma este podcast sirve. Tratan temas de actualidad un capitulo por semana usando un inglés pausado.

Asi de claro

Los periodistas de RPP explican la actualidad peruana en 3 minutos, todo en palabras breves y simples. Ideal para los que no quieren escuchar largos noticieros.

Canción original

Cada episodio cuenta como se hizo una canción original para una serie o película, mi favorita es sobre la creación del tema de Volver al Futuro.

Escalera al CEO

Semana Económica entrevista a CEOs de diversas industrias. Cuentan sus historias, aciertos y fracasos.

Metadata

En cada capitulo un completo análisis de lo último de la tecnología, además de reseñas y recomendaciones.

Entiende tu mente

Este podcast son capítulos de 20 minutos sobre como funciona nuestra mente desde el punto de vista de la psicología.

Dínamo

Un podcast sobre el universo Apple. Todas las novedades sobre sus productos y servicios. Obsesiones solo para los fans.

Astronomía y algo más

Sobre los misterios del universo y como la ciencia busca resolverlos, en lenguaje para gente común como nosotros 🙂

El encantador de perros argentino

Historias y recomendaciones de “Pampita” Montenegro para cuidar a nuestros perros.

Cacharradas

Este es un podcast sobre vida digital. Hablan de temas diversos como el reto de vivir dos semanas sin Google, Kingdom Hearts III o qué es el 5g.

/imagen: Photo by NeONBRAND on Unsplash

Estrategia de la Arquitectura de la Información

Optimismo no es estrategia.

Photo by Jamie Templeton on Unsplash

Los slides de la presentación en el WIAD Lima 2018 a continuación:

https://docs.google.com/presentation/d/12KijrR0x4WuiyZrdA5ynzclipALmSW4WTf8LIg07Iv4/edit?usp=sharing

Algunas notas de la presentación:

  • casi la mitad de los internautas peruanos confiesa haber tenido dificultades para acceder a un sitio web para comprar o buscar información sobre algún producto desde su smartphone” … es evidente que el rol de la Arquitectura de Información peruana es deficiente.
  • Se pone peor cuando el 41% [de nuestros usuarios] busca la solución en la competencia”. ¿Por que esta carencia de atención a nuestros propios productos?
  • En el curso de Experiencia de Usuario que dicto este año, las evaluaciones supervisadas realizadas por los alumnos a los sitios web y aplicaciones locales tampoco dan un panorama alentador. Es una debilidad común que la organización del sitio web responda a la organización de la empresa.
  • El “tecno” optimismo que existe en el mercado actual seria uno de los motivos. Esta bueno clarificar la ideas y moldear prototipos, sino miremos las hackatones y eventos startuperos con las selfies con murales repletospost-its, pero aún es una carencia las pruebas heuristicas y de usuario más básicas. Todo esto se refleja en los productos que construimos.
  • No me mal entienda, el problema es que nos enamoramos del proceso y nos olvidamos de validarlo con el usuario. No hay experiencia del usuario sin los usuarios.
  • El puente entre la investigación de usuario y el diseño esta roto. Nos falta el diseño antes del diseño. La estrategia de la arquitectura de la información es ese puente. Por una parte sobre como la información será estructurada, organizada, administrada, etiquetada e integrada, y por otro como esto será comunicado a los equipos involucrados y dirección de la empresa.
  • Esta comunicación es el punto de falla usual. La pobre comunicación del valor de la arquitectura de la información causa que esta se subestime y en ocasiones hasta se ignore. Afectando principalmente al SEO y la usabilidad, empobreciendo el resultado final.
  • Aqui resaltan dos artefactos: un documento (o wiki) que documente claramente la estrategia de arquitectura de la información integral, y una presentación que “venda” a la organización el proceso y el valor que aporta al producto.
  • Menos “tecno-optimismo” y más estrategia para mejores productos.

Bibliografía:

Indexante Newsletter, lo que hay que leer


Desde que murió Google Reader las cosas se pusieron complicadas para procesar información de diversas fuentes. Reeder no estuvo a la altura y las fuentes RSS — Estándar XML por excelencia para compartir datos— desaparecieron de los sitios web, haciéndolos menos accesibles.

Desde ese entonces para mi la mejor solución a sido automatizar fuentes usando IFTTT y enviándolas a Evernote, así la selección diaria se me hizo más simple. De este proceso siempre resulta un grupo de enlaces que resalta por su precisión o datos importantes, información que merece enviársela a los amigos.

Esos enlaces son los que semanalmente estaré compartiendo en Indexante Newsletter, una selección de enlaces sobre experiencia del usuario, producto, medios digitales y tecnología que se envía todos los miércoles a la mañana.

Últimas ediciones:

Enero 2018

Diciembre 2017

Una lista de cosas que salvarían al periodismo, pero no

Acompañenme a ver esta triste historia.



Storify cierra y borrará todas las historias que contiene en Mayo 2018. Si no exportas tu data toda la “curación” de contenido se ira con el, multitud de contenido embebido desaparecerá, por que ese periodismo esta en tu sitio pero no es parte de el. Otra aplicación promesa que desaparece.

Pero no es la primera vez que pasa.


En el 2009 aparece Google Wave como una señal. Permitía edición simultánea en tiempo real. Toda las buzzwords juntas oiga, pasto para los gurus que se apresuraron a decir que esta aplicación es lo que necesitaba el periodismo, permitiría la colaboración en la redacción de manera nunca vista. Mejores herramientas hacen mejores noticias. Se subieron los mismos de siempre a hablar en los eventos, se publicaron los posts anunciando la buena nueva, se organizaron los talleres.

En 2010 cierra sin que nadie lo entienda, y bueno, de salvación nada.


iPad. La anunciada tabla de la salvación tampoco salvo a nadie. Se montaron las redacciones, se generaron las ediciones exclusivas para iPad, “papel digital” se atrevieron a decir. Trabajar en una nueva plataforma a la manera antigua. Bueno, el intento de The Daily fue lo mejor que se vio, pero del resto nadie se acuerda … y ya saben que paso al final.


Instagram. Otra aplicación en la que hay que estar pero solo para publicar fotos, por que no permite enlaces externos. Tipos inteligentes los muchachos de instagram, cuidan su producto. Mientras los medios que en su mayoria no conocen otra manera que rentabilizar por tráfico sufren, pero igual están por que bueno … hay que estar como en Snapchat ¿no?


Los videos cuadrados. Alguien pensó que como Buzzfeed hacia los videos así, esa era la clave de su éxito (?). Ahora todos con el formato y ver un video así es alerta de contenido que solo busca llamar la atención, por que la información va escasa en la redacción que va por solo el tráfico.


Whatsapp. El público avisando al medio digital de lo sucesos de la ciudad, y gratis!, gran idea. Hagámoslo. Hasta que se se dieron cuenta que hay que pagar un equipo a clasificar la información, verificarla, y ver si tiene valor para publicar. Además de calmar a la gente que envió su “importante información” y no la ve publicada. Solo los que invirtieron mantienen su números funcionando, por que poner al practicante a atender ese teléfono no es buena idea.


Podríamos seguir, sino recuerden a Vine … creo que me entienden.

La moraleja podría ser ver un poco más allá de la herramienta o el formato, pensar en que podría pasar luego. Tener espíritu crítico con la moda, por que al final lo que importa es construir un buen producto.

Así que nada de invertir en Presscoins por ahora, ¿ok?


El empresario que anticipa el futuro

Libros

⭑⭑⭑⭑⭒ Ashlee Vance. (2015). Elon Musk: El empresario que anticipa el futuro (2da edición). Barcelona: Ediciones Península. ISBN 9788499425191. Original en inglés: Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future. Ver en Goodreads.



Encontrar este libro en español y versión Kindle es imposible para este lado del planeta. Simplemente no se puede comprar por restricción geográfica en Perú, así que conseguí la edición física de toda la vida con el sobreprecio correspondiente.

El autor del libro es el único que logra acercarse a Elon lo suficiente para dar un relato verídico de este emprendedor nato. Ese acercamiento permite que se extienda por casi 400 páginas relatando la vida y obra de este empresario símbolo de Silicon Valley.

La lectura es entretenida y con mucho detalle. Relata los orígenes de Musk, en Africa, su migración a Canada. Luego sus emprendimientos, la creación de X.com, Paypal y el golpe de estado, la aventura de lanzar el primer cohete de SpaceX, como comienza Tesla y como crea sus autos, Solar City y otras aventuras. Los pocos amigos y los muchos enemigos que hizo en el trayecto.

El capitulo de Tesla: la génesis de la empresa, los problemas que atravesaron y el detalle de la construcción del Modelo S, me parece la parte más interesante. El libro también derriba algunos mitos como que fue fundador de Tesla o que el creo Paypal. No es así fanboys. 🙂

Describe una persona enfocada al extremo en su visión, la dureza con la que trata a su personal para lograr los objetivos trazados. No se puede ser muy sensible cuando estas en la dirección de las empresas que podrían cambiar el mundo.

Es una mirada honesta a la persona detrás de la celebridad, aunque la comparación con Steve Jobs es ociosa. Es también excesivo el uso de notas al pie y dos apéndices para explicar momentos o hechos, esto podría haber sido mejor contado como parte de los capítulos en si.

Lectura recomendada para los interesados en emprender, y en general a todos los interesados en conocer como se forma una revolución en industrias establecidas.

Para todos los quieren diseñar pero no hacerse responsable del diseño

¿Existe la experiencia del usuario sin usuarios?



En todos los cursos los alumnos lo mencionan en clase. Algunos colegas también. Historias donde el cliente en un diseño ya avanzado insiste en cambios en la estructura de la página o los colores solo por una cuestión de “gusto”. Algunas historias incluyen escenas donde el cliente (o peor aún el jefe) abre photoshop y el mismo empieza trabajar los elementos visuales.

Síntomas: sliders o galerías de fotos que se mueven solos y sin control, Logos gigantescos. Primer enlace de la navegación “Inicio”. Banners invasivos. Fotos gigantescas sin utilidad. Esta situación es imparable por algo muy simple: equipos de “experiencia del usuario” que no ejecutan pruebas de usuario, evaluación heurística, analítica mínima, card sorting, etc. no tienen los fundamentos necesarios para defender su diseño.

No tienes como decirle al cliente que ese slider no le sirve a nadie por que todas las pruebas de usuario que lo podrían demostrar no se hicieron.

Diseño irresponsable sin compromiso con el producto. Señores que leyeron Don’t Make Me Think pero no lo comprendieron.


El arte emociona, motiva, conmueve, trasmite un mensaje personal del autor, se interpreta. Ves una pintura y te gusta, no tiene utilidad práctica. En productos digitales, el diseño podría tener estos atributos, pero además tiene una función. Se utiliza. Es funcionalmente eficaz.

¿Cuanto le cuesta a la empresa que la gente llene el carrito y por una pobre experiencia de usuario no compre nada?


El cliente quiere diseñar por qué no ve la conexión entre el diseño y los objetivos del producto. Asume que si es “bonito” funcionará. El equipo de diseño tiene que hacer un trabajo de educación (y de paciencia) para mostrar que cambios en el diseño tienen consecuencias en el proyecto.

Aquí es donde entran las métricas y las pruebas de usuario. Analizar que funciona y que no.

Pasar de discutir que colores del diseño le gustan al cliente para que apruebe el proyecto a discutir como el diseño apoya las metas del proyecto basado en pruebas es toda una señal de madurez en la organización.

Este es el reto del verdadero diseñador de experiencia del usuario: Pasar de limitarse a aplicar las principios básicos del la usabilidad y diseño a involucrarse en la construcción de experiencias de usuario con el usuario.


Referencias

Libros y lecturas recomendadas para el curso de Experiencia del usuario

Una lista constantemente actualizada.


Usualmente antes del curso de Experiencia de Usuario envío una lista de lecturas y libros recomendados para los alumnos. Así van entrando en materia antes de la acción.

LECTURAS

UX Pin tiene una completa colección de EBooks constantemente actualizada, sirve como referencia.

ESTRATEGIA

ALCANCE

DISEÑO

PRUEBAS

LIBROS

Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd Edition) (Voices That Matter)3rd Edition
Por Steve Krug

The Design of Everyday Things: Revised and Expanded Edition Paperback — November 5, 2013
Por Don Norman

Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems 1st Edition
Por Steve Krug

Usabilidad. Deja de sufrir.
Por Daniel Torres Burriel

Information Architecture: For the Web and Beyond 4th Edition, Kindle Edition
Por Louis Rosenfeld, Peter Morville, Jorge Arango

Lean UX: Designing Great Products with Agile Teams
Por Jeff Gothelf

The Elements of User Experience: User-Centered Design for the Web and Beyond (2nd Edition) (Voices That Matter) 2nd Edition, Kindle Edition
Por Jesse James Garrett

Mapping Experiences: A Complete Guide to Creating Value through Journeys, Blueprints, and Diagrams 1st Edition, Kindle Edition
Por James Kalbach

Content Strategy for the Web, 2nd Edition
Por Kristina Halvorson

Designing for emotion
Por Aarron Walter

Web Form Design: Filling in the Blanks
Por Luke Wroblewski

Rework
Por Jason Fried, David Heinemeier Hansson

Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers
Por Alexander Osterwalder, Yves Pigneur.

Getting Real
Por 37 Signals.

Read This Before Our Next Meeting: How We Can Get More Done
Por Al Pittampalli

Presentation Zen
Por Garr Reynolds

Lo que podemos aprender de un barco construido para ayer

Rápido, bonito, barato. Imposible.



Durante la Segunda Guerra Mundial la construcción de los cargueros clase Liberty era de extrema urgencia, se buscaba reemplazar rápidamente los barcos hundidos en el conflicto y recuperar la línea de suministros de EE.UU. hacia Inglaterra.

Se planificó todo de tal manera que cada barco pueda ser armado en 244 días. Nueva metodología, nuevas técnicas en soldadura y nuevo sistema de producción en cadena. Se logró construir el primer buque en solo 70 días. El ritmo de construcción llegó a ser de 42 días por unidad. El récord se alcanzo con el CSS Robert E. Peary, que tardó tan solo 4 días, 15 horas y 29 minutos en armarse.

Así entraron en servicio los nuevos barcos, pero otra fue la historia. El SS John P. Gaines se partió a la mitad y se perdió tripulación y carga. Luego dos buques más sufrieron el mismo destino. El 30% de las naves recién construidas presentó fallas estructurales. 1200 unidades tenían grietas en cubiertas y casco. En bajas temperaturas el acero del casco se volvía quebradizo. Toda la producción tuvo que volver al astillero para ser reparada y reforzada.

El origen de los problemas fue la mala supervisión, la mano de obra poco calificada y el uso inadecuado de materiales.

¿Le suena conocida la historia?


La supervisión requiere conocimiento y experiencia, tan simple como eso. El conocimiento necesario para entender cada paso y la experiencia de haber participado desde abajo en otros proyectos. Y sí, también haber metido la pata un par de veces cuenta. La experiencia genera respeto.

Ambas cosas aseguran la calidad. ¿Cómo revisar diseño si no se conocen los principios generales del diseño de interacción? ¿Cómo hablar de aseguramiento de la calidad sin la elaboración del plan de pruebas? Las microdecisiones diarias comprometen la calidad.


Si la contratación de programadores no pasa por una prueba de escribir código o al menos código funcionando en algún repositorio público, es contratar a ciegas. Para el programador el código es lo que vale, el resto son palabras. Lo mismo con los diseñadores o analistas. Necesitamos pruebas de que eres bueno.


La elección de la tecnología de un proyecto depende de diversos factores: la madurez y el uso, el diseño de las herramientas, el soporte (o la cantidad de información en Stack Overflow que es lo mismo), la cantidad de programadores en el mercado que conozcan el tema etc. Todas razones válidas y discutibles. Solo un consejo: no escoja nada por moda.


Entregar rápido y a tiempo es un arte que se domina con la práctica. Y no se hace solo, debe ser una cultura de equipo. Esta cultura requiere disciplina y control. Disciplina para respetar los procesos a pesar de la presión y control, hitos verificables de cumplimiento, métricas internas.

Evitar pasos en el proyecto como las revisiones de usabilidad, los test funcionales o pruebas con usuarios es prepararse para un rally sin casco ni cinturón de seguridad confiando en un viaje tranquilo. Y los productos digitales no son un viaje tranquilo.

Referencias

Política de oficina y otras cosas que entierran el producto

Diseño del producto y el impacto de la realidad.

Doug y Frank terminan con tu proyecto.

Escribe Kara Pernice en Poor Management = Mediocre UX Design :

Nuestra encuesta muestra que los profesionales UX de hoy luchan con el mal soporte de gestión para UX, la falta de procesos y liderazgo UX, y por lo general no tienen un equipo de UX para apoyarlos. La mayoría percibe el UX solo moderadamente efectiva y el diseño en sus empresas como solo de calidad moderada. La mayoría siente que no tiene los recursos para llevar a cabo la investigación del usuario necesaria para ser más eficaz.


Si la dirección de la empresa no conoce el valor del diseño del producto, no lo apoyará. Si no lo apoya, el presupuesto asignado a UX será cero. Si el presupuesto es cero, el producto será pobre, perderá identidad y no se podrá vender. Ya en crisis, tendrás que recurrir a trucos básicos como inflar el tráfico y vender banners para pagar las cuentas.


La política de oficina es un fenómeno real. Si el diseño del producto no trae consigo una estrategia interna para apoyarlo, no prosperará. Reuniones informales, emails detallados y reuniones tensas son parte de la política que hay que ejecutar para sacar adelante los proyectos. La principal barrera es el mito de que diseño es decoración y eso no va cambiar de la noche a la mañana. Hay que fundamentar por qué el diseño del producto va a resultar y cómo, es decir, comprometer a la dirección en los productos, hablando su idioma.


El puesto es un encargo pero el liderazgo viene con el ejemplo. Hay que involucrarse en el día a día pero no entrometerse. Generar ideas con ellos, hacerlos participar y defenderlas esas ideas. Pararse al costado de la gente no es liderar. No haga micromanagement, haga equipo.


No necesitas usar la técnicas de Frank Underwood, solo necesitas una mejor forma de acercarte a la dirección de la empresa con cosas tan simples como un email bien escrito o una presentación con las personas correctas.

Así es como mueren las empresas de software

Recuperado del antiguo blog en indexante.com. Esta es una traducción no autorizada y libre de un viejo texto que @g33k me compartió hace unos años. El texto fue escrito en 1995, y aún conserva vigencia.

El autor es Orson Scott Card, que como todo buen fan de la ciencia ficción sabe, escribió el premiado El Juego de Ender.



Cómo mueren las empresas de software

Por Orson Scott Card, original en inglés en zoion.com.

{Windows Sources, Marzo de 1995, pág. 208}

El ambiente que nutre a los programadores creativos mata a los tipos de gestión y comercialización — y viceversa.

La programación es el Gran Juego. Esta consume, el cuerpo y el alma. Cuando usted está atrapado en ella, nada más importa. Al salir a la luz del día, es posible que descubras que tienes un centenar de kilos de sobrepeso, la ropa interior es mayor que el promedio de primer grado, y a juzgar por el número de cajas de pizza por ahí, debe ser primavera ya. Pero no importa, porque su programa se ejecuta, y el código es rápido e inteligente y firme.

Ganaste

Usted es consciente de que algunas personas piensan que eres un nerd. ¿Y qué? No son jugadores. Nunca tuvieron una justa con Windows o han ido mano a mano con el DOS. Para ellos C++ es una evaluación decente, casi un B-, no es un lenguaje. Apenas existen. Como los soldados o artistas, usted no se preocupa por las opiniones de los civiles.. Estás construyendo algo intrincado y bien.

Nunca lo entenderán.

Apicultura

Aquí está el secreto en que se basa cada compañía de software de éxito: Se puede domesticar a los programadores de la manera que los apicultores domestican a las abejas. No puede comunicarse con exactitud con ellos, pero se puede conseguir que pululen en un lugar y cuando no estén mirando, puede llevarse la miel.

La manera de evitar que estas abejas le piquen es pagándoles dinero. Tanto dinero que no saben qué hacer con él. Pero eso es menos de lo que piensas. Mire usted, todos estos programadores siguen oyendo las voces de sus padres en la cabeza diciendo: “¿Cuándo vas a entrar en el mundo real?”. Todo lo que tiene que hacer es pagar el dinero suficiente para que puedan responder (también en la cabeza) “Caray, papá, estoy haciendo más dinero que tú”. Para el término medio, esto es barato.

Así usted consigue que se queden en la colmena, con otros programadores del enjambre. La única persona cuya alabanza importa es la de otro programador. Los programadores menos talentosos los idolatran; los de igual nivel los desafiarán y se aguijonearan entre sí, y si usted desea conseguir un buen enjambre, tiene que asegurarse tener al menos un programador genio certificado que todos puedan admirar, así sea sólo para mirar el código de los otros lo suficiente para burlarse de él.

Él es un jugador, piensa el programador junior. Miró mi código. Eso es suficiente. Si una compañía de software proporciona tal colmena, los programadores no se darán por vencidos por el sueño, el amor, la salud y la ropa limpia, mientras que la compañía mantiene la mayor parte del dinero.

Fuera de control

Aquí está el problema que acaba matando a una compañía tras otra. Todas las empresas de software con éxito tenían, con su personalidad dominante, un líder que nutre al resto de programadores. Sin embargo, ninguna empresa puede tener un líder para siempre. O empieza a hacer efectivo por su cuenta, o los tipos de gestión terminan cansandolo, o el cambia y se convierte en un tipo de gestión. De una forma u otra, los de marketing obtienen el control.

Pero … el control de qué? En lugar de encontrar cadenas de montaje de trabajadores productivos, descubren rápidamente que su producto es producido por absolutamente impredecibles, poco cooperativos, rebeldes, y lo peor de todo, personas poco atractivas que se resisten a los intentos de administración. Póngalos a llegar a la hora, y vistalos de traje, y se vuelven hoscos y comienzan sabotear el producto. Lo peor de todo, usted puede sentir que se están burlando de ti con cada palabra que dicen.

Ahumados

Sin embargo el choque es mayor para el programador. De repente se encuentra con que criaturas extraterrestres controlan su vida. Reuniones, horarios, informes. Y ahora alguien exige que él PLANIFIQUE toda su programación y luego se adhiera al plan, sin mejoras, sin ajustes, y nunca, nunca tocar el código de algún otro equipo. El programador joven que una vez adoró es ahora su jefe tiránico, un cargo que tiene, porque él jugó al golf con algunos tipos con traje.

La colmena ha sido arruinada. Se fueron los mejores programadores. Y los de marketing, cómodos ahora porque están rodeados de las corbatas poderosas y tienen las cosas bajo control, están desconectados de cada nueva iteración de su software que pierde cuota de mercado mientras se hincha de código y los bugs proliferan.

Solo tenemos que conseguirle un mejor empaque. Sí, eso es.

Definición de objetivos del proyecto para medios digitales que no quieren formar parte del…


Esta es una pregunta que siempre hago en mis clases: ¿cúal es el objetivo de su proyecto? La mayoria de respuestas es una colección de buenos deseos acerca de cómo hacer buen periodismo escribiendo en una instalación de wordpress (?).

Para hacer buenos proyectos hay que ponerse serio: defina correctamente lo que quiere lograr.

“Hacer buen periodismo” no es un objetivo claro del proyecto. “Hacer buen periodismo para la gente que vive en la ciudad de Arequipa” tiene mejor definición pero es insuficiente: definiste para quién pero no cuándo se cumplirá el objetivo.

“Hacer buen periodismo que sea leído por 500 000 usuarios únicos que se quieren informar sobre los sucesos en la ciudad de Arequipa para abril 2017” está mejor definido porque ya sabemos para quiénes, cuántas serían estas personas y cuándo debería cumplirse el objetivo.

“Hacer buen periodismo que sea pagado por 1 000 usuarios suscriptores que se quieren informar sobre los sucesos en la ciudad de Arequipa para abril 2017”. Well, that escalated quickly! Podríamos seguir puliendo el objetivo, pero creo que ya se entendió la idea. Ante la duda, recurra al viejo y confiable método SMART de definición de objetivos.

Esta definición será la base de su proyecto. No se quede con el primer objetivo que le salga, revise, documentese y vuelva a definir hasta que esté seguro que es el que busca. Asegúrese que sus objetivos sean medibles y con tiempo definido, métrica y plazo son importantes para las siguientes fases del proyecto, comience bien.

Medio con miedo

El #findelperiodismo se explica mejor con ejemplos


0

Algo tarde leo el caso de @codybrown y el New York Times, y aún no me salgo del asombro.

1

@codybrown es un programador hábil, y como cualquiera que se precie de serlo, le gustan los retos. Así que en una hora construyo una replica de Snow Fall, el famoso especial del New York Times, hizo un video de la hazaña y lo publicó.

NYT amenaza legalmente al atrevido. “Infracción de derechos de autor” le dicen, eso no se hace. Ofendidos por que un programador puede desarrollar su idea en una hora exigen que se retire el video. El programador tiene dinero para costear un servidor, pero no abogados.

El video se retira.

2

Es claro que lo que hizo @codybrown no es ni siquiera una amenaza para NYT, la reacción corresponde con miedo a lo desconocido.

El programador clonó la interacción pero no el proceso de como se logro construir el especial original, ese valor siempre será del medio, eso no es replicable y proviene del talento de los equipos.

No hay que asustarse porque un programador experimenta, hay que asustarse de no motivarlo a hacerlo. La creatividad viene de todos lados, hasta de fuera de la organización y hay que aprovecharlo.