Así no se hacen las cosas por Ernesto Kiszkurno

Primero una definición de backlog coupling  extraída de aquí : "if a large number of items in the backlog of a digital product team require a corresponding backlog item to be raised in another team, then productivity and responsiveness suffer enormously. Backlogs get chained across the organisation, each being prioritised according to a different system. Tasks acquire big red ‘blocked’ stickers on kanbans, stakeholders get angry, the shared service providers react as best they can - usually responding to the loudest voice." Si extrapolamos la idea en personas, pasa algo parecido. Cuando tenemos una tarea en nuestra lista que depende de que alguien más haga alguna otra tarea, esas tareas están acopladas.  El problema de este acoplamiento es claro: "The tasks that had to wait for another team were 10-12x slower in elapsed time. So dependencies have a real significant impact." En el caso del software, la solución a esto es algo más compleja (y pueden le

Así como los grandes proyectos de consultoría se "agilizaron", para pasar de años o meses a semanas o días, o los grandes data warehouses cedieron espacio a herramientas más pequeñas pero que dan poder de análisis a los usuarios finales y "agilidad" para hacer más rápido las cosas, el mundo de las grandes desarrollos de software y productos va a ceder espacio también . ¿Por qué desarrollar aplicaciones complejas, si podemos lograr lo mismo mediante microservicios y APIs? Son más fáciles entender y rápidos de evolucionar. Podemos reusarlos como building blocks para construir soluciones más grandes o complejas. Podemos usarlos internamente y externamente. Podemos combinar múltiples nubes. ¿Alguien no cree que esto sea así? Lo podemos convencer mostrándole el crecimiento que vienen teniendo ( ProgrammableWeb ). O el ecosistema de tecnología en el que nos movemos actualmente. Las APIs y micro servicios permiten el armado de verdaderos mashups  

En la parte 1 de una interesante saga llamada 5 Disruptions to Marketing , Scott Brinker me hizo notar un fenómeno interesante. Así como, cada vez más, el presupuesto de IT está siendo desviado a áreas de Marketing, las actividades de desarrollo (las más básicas obviamente) también estarían siendo tomadas por lo que Scott llamó "los ciudadanos del departamento de Marketing": "I use the phrase “citizens of the marketing department” quite intentionally, because these wizard-like capabilities that marketers are acquiring align with three big IT-democratization movements: CITIZEN DEVELOPERS — who use no-code or low-code tools to create web apps, mobile apps, interactive content, bots, and other kinds of functional experiences for staff, prospects, and customers CITIZEN INTEGRATORS — who use iPaaS and other workflow automation tools to create business processes on-the-fly, intelligently routing data and triggering activities across multiple teams CITIZEN ANALYST

Les dejo un video de 5 minutos, en inglés, que responde a una pregunta que muchos se hacen hoy en día: "En qué consiste el diseño de la experiencia de usuario" Espero que les sirva. Seguimos pensando..

En nuestros días ya no es necesario recordar la importancia de la estrategia de testing a nadie. Todos somos conscientes de que es necesario pensar antes de actuar, si queremos cuidar los -siempre escasos- recursos y tiempos asignados a las pruebas. Lo que no es tan común es tener designado un rol de estratega de testing en el equipo, cuya responsabilidad principal es pensar (o cuestionar) la estrategia de cada prueba.  Un rol así es importante pues nos previene de un error recurrente en los equipos de prueba, el de quedarse enamorados de una estrategia "default" .  A veces encontramos una fórmula que nos sirvió en el pasado y la adoptamos como única para todo lo que viene. Está en la naturaleza humana hacerlo. El problema es que en testing tenemos la famosa paradoja del pesticida : los bugs se acostumbran a nuestros pesticidas, por lo que tenemos que cambiar. Seguimos pensando..

Qué alegría me dio leer este  artículo en el que se menciona como un aspecto clave de la transformación digital al cambio cultural que se requiere . Veo a muchos temerosos por los puestos que las máquinas van a arrebatarnos a nosotros los humanos, pero pocos pensando en el GAP de capacidades  que ya tenemos para afrontar la transformación. Rescato 6 frases del artículo: "The innovative approach required for digital disruption to succeed will instead come from talented people." “Employers can start encouraging a culture of collaboration through using technology in the right ways.” "One example is to give people the tools they need to free up their time from administrative or mundane tasks, so teams can collaborate on creative initiatives, customer-centric improvements to the business, and experimentation." “Working collaboratively will not just apply to working with other people, but having the skills to work effectively and efficiently with machin

Les dejo un video de una charla TED de OK Go, unos tipos que hacen unos videos muy interesantes. La charla es acerca del proceso creativo que siguen para lograr sus videos. Me pareció interesante la noción de encontrar  una idea, en lugar de tener  una idea. Porque muchas veces se trata de encontrar una combinación nueva, de cosas viejas. También se mencionan, algo al pasar y rápido, otros conceptos que en estos días estamos aprendiendo a usar en esto de innovar que hace años ni se nos ocurrían: prototipos, planning iterativo, jugar, ... Llevando la atención hacia otro lado, ¿vieron la estructura y forma de presentar de la charla? Sin PowerPoint, sincronización total entre el orador y el grupo que hace de apoyo con láminas. También ahí hay cosas para rescatar, no? Me encanta cuando encuentro gente que puede tener este nivel de profesionalismo tanto en la fase planificación como en la de ejecución. Seguimos pensando..

Terminé de leer Value Proposition Design  de Alex Osterwalder (VPD) y me gustó mucho. Es el complemento de otro interesante libro llamado Business Model Generation  del mismo autor, que también explota muy bien el uso de herramientas gráficas a la hora de explicar. Lo primero que hay que decir es que el libro es lindo y da ganas de tenerlo en papel. Su estética es muy cuidada y realmente verlo o leerlo en digital no es lo mismo. Lo segundo es que el método que plantea para pensar ofertas y servicios asociados a los dolores de los clientes es muy interesante. La sensación usándolo  es que uno hace un camino muy directo desde el cliente que desea cautivar, pasando por sus problemas o necesidades, para llegar a las potenciales soluciones.  Además, el libro no viene solo, sino que es complementado con videos que muestran la forma en que pueden usarse los conceptos (las pizarras y "papelitos" que tienen estos muchachos para anotar cosas son realmente envidiables!).

Encontré un artículo de Bain que muestra gráficamente algo importante: Debemos entender lo que nuestros clientes cuestan y lo que dan  para poder evaluar si nos convienen . Pero cuidado, hagamos el análisis bien. Algunos clientes contribuyen marginalmente  pero lo hacen, otros son pequeños pero valen la pena . No cometamos el error de  recortar demasiado. Seguimos pensando.. Posts relacionados: El poder de la sustracción aplicado al negocio No se olviden de la contribución marginal

Les dejo un breve video del maestro que ayuda a poner en perspectiva algunas cosas. Disfruten. Seguimos pensando..

En un artículo de HBR llamado Your Strategy Won’t Work If You Don’t Identify the New Capabilities You Need  se hace una observación interesante acerca de la estrategia: "While strategic planes identify what your organization should do differently, very few provide a roadmap for how to build the skills, knowledge, and processes needed to carry out and sustain the critical changes. But without building these capabilities, it’s very difficult to achieve the results you want." En otras palabras, a la hora de planificar estratégicamente no alcanza con enunciar los resultados que queremos obtener sino que necesitamos también trabajar sobre cómo los lograremos. En particular, si queremos desarrollar nuevos productos y servicios, debemos entender qué capacidades necesitamos para lograr implementarlos. Es común ver en las organizaciones la tensión entre los que venden y los que ejecutan, algunos dirían que es hasta algo natural. Mi sensación es que si trabajaran un poco más e

Hace un tiempo recibí el llamado de un cliente que tenía una reunión importante y quería mi ayuda para recolectar información y prepararse. Acordamos encontrarnos para hablar del tema unos pocos días después. Nos encontramos, indagamos y luego respondimos.  Otro competidor, en cuestión de días y sin haber hablado, presentó propuesta. Creo que la agilidad es importante en el trabajo comercial/consultoril. Responder rápido en el mundo actual es claramente una ventaja, pero también es importante responder bien. Rápido y mal no sirve. Bien y lento tampoco. Entender ese equilibrio fino entre rápido y bien es una capacidad diferencial de un consultor. Cuando logramos hacer esto la relación con nuestros clientes se fortalece. Seguimos pensando..

Hoy descubrí una aplicación llamada Bear  que realmente me dejó impresionado.  De esas que hacen que la experiencia de escribir sea bella. Casi que uno se siente que escribe bien y todo. La lista de features  hizo parecer a Evernote un "elefante" torpe y pesado, si me permiten el chiste fácil. Tal vez por eso algunos , como yo mismo , pensamos que viene cayendo en desgracia. Las que más me gustaron fueron: La posibilidad de insertar #hashtags en el texto que luego ordenan tus notas sin necesidad de clasificarlas en carpetas o cosas por el estilo. La experiencia de usuario que logra permitiendo formatear todo desde la línea de escritura. La gran contra: No tiene aplicación para Windows. Seguimos pensando.. Posts relacionados: 5 razones para las que recomiendo usar Evernote Revisando el "software que me gusta"