Archives

El presente documento tiene como objetivo presentar a modo introductorio el Modelo de Madurez de BPM, cuyo desafío es establecer una normativa para evaluar la madurez de los procesos de negocio de una organización. El Business ProcessMaturityModel (BPMM) es desarrollado colaborativamente por el CMM Software(1), CMMI(2),y People CMM(3).

Teniendo en cuenta que diferentes dominios experimentan problemas similares, los mismos modelosdemadurez que tienen éxito en determinados proyectos, si son apropiadamente aplicados, pueden proveer similares beneficios en otros dominios, esta es la principal premisa para adaptar los conceptos creando un modelo de madurez general aplicable a un número significativo de dominios.BPMM es un modelo conceptual basado en las “mejores prácticas” que son actualmente utilizadas en diferentes dominios, tales como marketing, bancos, manufactura, finanzas o IT, el mismo describe los elementos esenciales de procesos efectivos para uno o más dominios seleccionados. BPMM describe un camino de mejora continua para guiar a las organizaciones partiendo de procesos inconsistentes e inmaduros hasta alcanzar la madurez de los mismos. Esta guía se ordena en etapas donde cada una provee una base en la cual se construyen las mejoras emprendidas en la siguiente.

La estrategia definida por BPMN provee un mapa para la mejora continua de procesos, ayudando a identificar las deficiencias en la organización y guiando las mejoras en etapas lógicas e incrementales. Estas etapas se definen en cinco niveles de madurez.

Grafico-1

Niveles de Madurez

BPMM se divide en cinco niveles de madurez representados por diferentes estados por los que atraviesa una organización al transformar sus procesos, mejorando su capacidad. Cada nivel de madurez puede ser descripto en términos de donde se focaliza la administración y de cuáles son sus principales objetivos.

  • Inicial (Initial) - “Fire-fightingmanagement” -No hay objetivos específicos, el éxito en estas organizaciones depende de la capacidad de las personas que trabajan en la organización y no del uso de procesos ya probados.
  • Gestionado (Managed) - “Workunitmanagement” - El objetivoes crearuna basede gestión o conocimientodentro de cadaunidad detrabajo o proyecto.
  • Estandarizado (Standardized) - “Processmanagement” - El objetivo es establecer y utilizar una infraestructura de procesos activos, con base en la experiencia, para lograr coherenciaen la forma enque se realizael trabajopara proporcionar productos yservicios.
  • Predictible (Predictable) - “Capabilitymanagement” –El objetivo es administrar y explotar la capacidad de la organización para controlar la variación y predecir los resultados en base a la infraestructura de procesos disponibles y la experiencia.
  • Innovador (Innovating) - “Changemanagement” - El objetivo es la mejora continua tanto de los procesos de la organización como de los resultados obtenidos, por medio de la prevención de problemas, el aumento de la capacidad, planificación de mejoras y de la innovación.

Los niveles de madurez 2 al 5 se componen de áreas de procesos que conjuntamente permiten alcanzar la capacidad requerida en cada nivel. Cada área es diseñada para alcanzar objetivos específicos en la generación, soporte o sustento de los diferentes estados organizacionales característicos de un nivel en particular. Cada una consiste de una colección de “mejores prácticas” que indican qué se debería hacer, pero no cómo se debería llevarlas a cabo, por lo tanto, las organizaciones son libres de definir sus propios métodos y enfoques para satisfacer los objetivos de cada área de proceso en particular.

Algunos de los usos de BPMM son los siguientes:

  • Comprender y definir las actividades necesarias para lanzar y sostener programas de mejoras de procesos dentro de la organización.
  • Analizar la madurez de los procesos existentes en una organización e identificar las fortalezas y debilidades de los mismos.
  • Identificar las tareas críticas dentro de cada proceso para mejorar, tanto los procesos, como los productos y servicios, guiando en la definición y mejora de los mismos.

“Un uso efectivo de BPMM permite a una organización introducir la mejora de procesos en etapas, cada una de las cuales representa una transformación básica que genera las bases para las etapas sucesivas y permite un cambio progresivo de la cultura organizacional”.

En una organización inmadura, los procesos son generalmente improvisados por las personas a medida que se realiza el trabajo, incluso si los procesos fueron definidos, no son rigurosamente aplicados o directamente no son tenidos en cuenta. Una organización inmadura reacciona ante la aparición de problemas o situaciones de crisis sin contar con un plan de acción predefinido. El presupuesto, la planificación y los acuerdos de niveles de servicios a menudo no se cumplen porque no se sustentan en estimaciones reales. El objetivo principal que se persigue con este modelo de madurez es ayudar a las organizaciones a definir una guía que permita avanzar paulatinamente y de forma organizada, en etapas, enfocando el esfuerzo en las áreas y procesos críticos, de forma tal que crezca o madure a lo largo del tiempo, logrando la mejora continua de sus procesos de negocio.

Notas:

(1) CMM Software (CapabilityMaturityModel): modelo de evaluación de procesos de una organización.

(2) CMMI (CapabilityMaturityModelIntegration): modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

(3)People CMM: marco de madurez que se centra en la mejora continúa de la gestión y desarrollo de los activos humanos de una organización.

Fuentes:

1 - Business Process Maturity Model, v1.0

OMG Document Number: formal/2008-06-01

Standard document URL: http://www.omg.org/spec/BPMM/

Copyright © 2007, Borland Software, Inc.

Copyright © 2008, Object Management Group, Inc.

Needham, MA, USA

1 - Guide to the Business Process Management Common Body Of Knowledge (BPM CBOK)

ISBN/EAN13:149051659X / 9781490516592

Version 3.0, Third Edition, 2013

Imagen: Stairs! por Richard Leming.

Por Cristina Ramos

Uno de los principales problemas que nos encontramos al momento de introducir un equipo ágil (externo o interno) en una empresa con metodologías tradicionales es la falta de un rol que represente “la voz” del cliente: el ProductOwner (PO). Este rol es indispensable para poder construir en tiempo y forma el producto más adecuado para el negocio.

Dado que este impedimento es un riesgo extra del proyecto, en este breve documento explicamos un rol llamado PO Proxy, que sustituye el rol inexistente del PO y permite mitigarlo.

¿Que es un ProductOwner?

En la mayoría de los proyectos ágiles de consultoría, el rol de ProductOwner(PO) es representado por el líder de proyecto del lado del cliente,que tiene como objetivo llevar adelante la construcción de un producto adecuado a las necesidades del negocio.

Las responsabilidades propias de un PO son:

  • Decidir qué habrá de construirse y en qué orden (prioriza el backlog de trabajo)
  • Definir las características del producto o los resultados esperados del proyecto desde la perspectiva del negocio
  • Seleccionar las fechas de entrega y su contenido
  • Asegurar el retorno de la inversión (ROI)
  • Priorizar las características y resultados según el valor de mercado
  • Ajustar las características y resultados según las necesidades
  • Aceptar o rechazar los resultados del trabajo realizado
  • Servir de facilitador en la reunión de planificación (ScrumPlanning)

Además, es imprescindible que el PO trabaje en estrecha colaboración con las partes interesadas, facilite la comunicación del equipo y los grupos de interés y se asegure de que el equipo esté construyendo el producto correcto.

¿Qué sucede si se presenta un equipo mixto: ágil y tradicional?

El líder de un equipo tradicional no siempre entiende y presenta las habilidades o características propias de un PO, pudiendo representar un impedimento extra en el proyecto. Si se presenta este caso en el equipo del cliente, será necesario que el equipo ágil cubra ese rol desde el inicio para una mejor integración de la metodología.

Luego del relevamiento realizado por un equipo ágil, interactuando con un cliente con metodología tradicional, se arribó a la conclusión de que era necesario elegir un PO proxy.Éste actuaría como “traductor” del líder del cliente, desde una perspectiva tradicional y la llevaría a una perspectiva ágil, permitiendo al equipo representar algunas funciones del PO, tales como priorizar el backlog de trabajo y los resultados esperados por el negocio en corto y mediano plazo, necesarias para poder avanzar con objetivos claros.

El rol de PO proxy fue cubierto por el analista funcional del equipo, quien al conocer del negocio y participar de todas las reuniones de equipo y con clientes, pudo tomar varias de las decisiones que corresponden al PO, con el fin de organizar la correcta construcción del producto.

¿Cuál fue el resultado de contar con un PO proxy?

Con el apoyo del equipo y en constante comunicación con los involucrados, el equipo ágil pudo llevar adelante el proyecto, con altibajos en varios momentos, debido precisamente a que no tenía la potestad de tomar ciertas decisiones concernientes al PO del cliente, y éste a su vez no tenía el apoyo interno suficiente como para lograr respuesta a consultas y realizar definiciones necesarias para el avance del desarrollo del producto.

Es un gran desafío participar de un proyecto donde el PO no puede tener claros ciertos aspectos que pueden cambiar el curso de lo que se espera del producto en ciertos momentos, y definir las prioridades de manera clara y objetiva, teniendo siempre como prioridad construir el producto adecuado para el negocio, dentro del contexto.

Conclusión:

Si una empresa es tradicional en su enfoque del desarrollo de proyectos, se hace difícil la integración del POa un equipo ágil. Los problemas comunes en este sentido son la pérdida de tiempo en cuestionar los procesos(sprints, dailys, etc), y el costo del tiempo en el aprendizaje y la adaptación para colaborar al desarrollo del producto dentro de la metodología ágil, lo que incluye: definir historias de usuario, criterios de aceptación, entender el armado de sprint, etc.

Por otro lado, también podría ser riesgoso que el PO sea alguien sin conocimiento del negocio o carezca de las habilidades blandas necesarias que le permitan ser un buen negociador y tener buena relación con todos los interesados.

Es recomendable capacitar a los futuros PO nacidos en metodologías tradicionales, especialmente para aquellos que tengan ganas de adquirir conocimientos sobre la metodología ágil y asuman la responsabilidad que eso conlleva.

Gracias a esta capacitación, el POpodrá obteneruna variedad de herramientas que le permitan colaborar para que tanto el equipo de desarrollo del producto como los dueños del producto obtengan lo deseado de la mejor manera y en el menor tiempo posible, aportando un valor agregado que conduzca al equipo al logro de un proyecto exitoso.

Referencias:

https://www.scrumalliance.org/why-scrum/core-scrum-values-roles

Imagen: Jogo da Comunicação no Workshop de desenvolvimento ágil por Improve it

Las metodologías ágiles proponen capturar los requerimientos desde la perspectiva del usuario .Los requerimientos ágiles son expresados a través de UserStories(US), las cuales tienen un formato en particular:

Como <rol> quiero <funcionalidad> para lograr <objetivo>.

Sin embargo, una vez descrito el comportamiento esperado del sistema en un conjunto de UserStories (denominado backlog) existe un problema a resolver: en qué orden se irán implementando cada una de ellas, es decir, por dónde arrancar.

Existen distintos factores y dimensiones a considerar

  • Tiempo
  • Esfuerzo
  • Valor Funcional
  • Opinion de los stakeholders,
  • Opinion del equipo de desarrollo
  • Valor de Mercado, y seguramente varios más.

A partir de los mismos han surgido distintas técnicas para priorizar los UserStories del backlog.

Las siguientes describen algunas de las técnicas más comúnmente utilizadas [1,2]. Para facilitar la comparación, se introduce un pequeño ejemplo de un backlog. El mismo luego será priorizado según la visión de cada técnica. El ejemplo consiste en una aplicación de comercio electrónico, con las siguientes UserStories:

 

US-01. Como usuario registrado quiero poner artículos en el carrito de compras para armar mi pedido.

US-02. Como dueño del comercio quiero que las personas puedan recorrer el sitio sin estar registradas para facilitar la visibilidad del mismo.

US-03. Como dueño del comercio quiero que únicamente los usuarios registrados puedan realizar compras para lograr fidelidad.

US-04. Como jefe de finanzas quiero que los pagos con tarjeta de crédito sean seguros para evitar fraudes.

US-05. Como usuario registrado quiero hacer “check-out” del carrito para finalizar mi pedido.

US-06. Como jefe de marketing quiero que sea sencillo e intuitivo agregar          productos al carrito para que los usuarios les resulte atractiva la página.

US-07. Como jefe de marketing quiero que los usuarios puedan realizar búsquedas para que puedan encontrar los productos que desean.

Técnica Business Value&StoryPoints

Esta técnica proponer priorizar las UserStories basándose en factores como el esfuerzo y la opinión del ProductOwner, del cliente y del equipo de desarrollo, o incluso combinándolas. ElBusiness Value es un valor númerico asignada a cada UserStory (US) donde a más alto el valor, mayor valor para el cliente.

Entonces una manera de priorizar el backlog sería utilizando el Business Value de las US. Sin embargo, llevarlo acabo de manera “aislada” puede traer problemas.

Uno de ellos radica en que el cliente muchas veces se deja llevar por detalles superfluos y esto puede llevar a dejar de lado funcionalidad realmente importante.

Otro problema es que no se considera el esfuerzo que lleva implementar cada US. Esto último puede resolverse con StoryPoints, que son valores numéricos que introduce el equipo de desarrollo estimando el esfuerzo que le llevará desarrollar cada US. Luego, una manera inteligente de priorizar el backlog es utilizando el cociente Business Value/StoryPoints. Es decir, lo más sencillo de implementar que devenga en mayor interés para el usuario. Para ilustrar esta técnica, suponer los siguientes valores para las US del ejemplo:

US Business Value Story Points Cociente
#01 8 1 8
#02 4 5 0,8
#03 7 5 1,4
#04 10 8 1,25
#05 12 3 4
#06 8 5 1,6
#07 6 8 0,75

 

Dados estos valores, el equipo de desarrollo dará más prioridad a las US #01 y #05, que son las referidas al manejo del carrito. Son las US que más la interesan al usuario que implican menos esfuerzo para el equipo. Luego seguirán las US #06, US#03, y US #04, para terminar con las US #07 y #02. Es importante notar que estos valores no son fijos y se pueden actualizarse al terminar cada sprint.

Técnica Urgente

En [3] proponen priorizar el backlog utilizando dos dimensiones, pero cambian el concepto de StoryPoints por otro: la urgencia en tener lista una funcionalidad. Se introducen valores de 1 a 5, donde 5 implica que esa US debe estar lista ya o de lo contrario perderá sentido, mientras que un valor 1 indica que no hay apuro en tenerla lista. También se tienen en cuenta para este valor de urgencia si la funcionalidad tiene que estar desarrollada por cuestiones contractuales, o porque de ella dependen muchas otras US, por lo debe implementarse antes. Los Business Value siguen la misma escala y se asignan valores de 1 a 5. Obtenidas todas las asignaciones, se multiplican los valores de urgencia por los de Business Value (obteniendo números entre 1 y 25) y se ubican en una tabla como la que sigue (fuente provista, [3]):

imagen-tabla

Dada esta tabla, la priorización es evidente: primeros las US en el sector rojo, luego naranja, amarillo y finalmente las verde.

Retomando el ejemplo del comercio electrónico, se pueden asumir los siguientes valores:

US Business Value Urgencia Sector

US Business Value Urgencia Sector
1 5 4 Rojo
2 3 4 Amarillo
3 3 2 Verde
4 4 3 Amarillo
5 4 4 Naranja
6 5 4 Naranja
7 3 2 Verde

 

Utilizando esta técnica, el equipo de desarrollo comenzará con la US #01, y luego atacará las US #05 y #06. Finalmente, las US #02 y #04, para terminar con las US #03 y #07. Comparado con la técnica anterior, la US #06 ha adquirido mayor prioridad, ya que con esta visión que el carrito sea sencillo de utilizar ha sido catalogado como más relevante. Razones similares pueden utilizarse para justificar la mayor prioridad de la US #02 en esta ocasión. La posibilidad de navegar el sitio para usuarios invitados ha sido clasificada con un alto valor de urgencia, por lo que ha subido su prioridad final.

Otras técnicas conocidas son:

● MoSCoW: Propone etiquetar las US con:

○ M: Esta funcionalidad debe estar (MUST).
○ S: Esta funcionalidad debería estar (SHOULD).
○ C: Esta funcionalidad podría estar (COULD).
○ W: Esta funcionalidad no estará ahora, quizás en un futuro (WON’T).

Luego, las US se llevan a cabo siguiendo esta clasificación: primero las US etiquetadas con M, luego con S, en tercer término aquellas con C y finalmente aquellas con W.

● Basados en Riesgos: Esta técnica propone simplemente hacer primero las US que involucren mayores riesgos. Lo cual implica realizar un análisis de riesgo completo antes de priorizar el backlog.

Referencias:

The concept of reusability is of foremost importance within any Enterprise-wide IT Initiative. Its promotion is one of the principal means from which ROI is obtained, whether it is through direct re-use or indirect collateral factors such as increased logic centralization, reduced gross "architectural size" and infrastructure footprint, among others.

Although this might seem like a straightforward concept, many Enterprises have neither the governance nor standards required to truly transform reusability into reuse. Without governance and standards, all the effort put into increasing the reusability potential of a software solution is translated into sunken costs and ultimately leverage for taking traditional, tactical, and siloed solution endeavors.

This article aims to give guidance on differentiating reusability from reuse. It will recommend approaches and things to consider to ease the transition from one to the other, with aim on changing hope-driven reuse into proactive reuse.

Reusability and reuse within a single application are not usually costly endeavors. They come with a specific complexity from which no important or profound benefit to the whole enterprise (or a significant segment of one) is commonly attained.

This article will assume that both concepts are being considered within the scope of Enterprise IT initiatives, as mentioned earlier. These initiatives may involve several parts of an enterprise and not represent a single application or discrete application cluster.

That being said, several concepts and definitions within the article can be used in either case; but the scope, benefits, and implications related to each one of them are going to be considered in the wider scope described earlier.

What is Reusability?

Reusability is a concept taken from the ability of something to be used more than once and in different functional contexts than those for which it was initially designed for.

It is a simple concept that, when used within IT Initiatives, entails multiple, complex considerations and approaches. Many of these considerations relate to core concepts such as: functional context, purpose, agnosticism, and compatibility.

In the following paragraphs, all will be explained with the aim of increasing understanding of reusability and each concept's relation to it.

Considering the aforementioned definition of Reusability:

If X is MORE reusable > X can be used in MORE distinctive Functional Contexts.

If X is LESS reusable > X can be used in LESS distinctive Functional Contexts.

Keeping in mind that each distinct functional context has from one clear purpose* associated with its definition to many or an undetermined number of possible purposes, these two concepts can be finally related as the following:

*A purpose answers the question "what for?" whilst an objective relates to the question "what?" For example: what does the pen do? It writes; one might use it to write a poem while someone else might use it to stir coffee. The purpose changes between contexts and instances while the objective remains the same. The objective may be defined as the most primitive characteristic of a solution and the closest relative of the original problem that required it. For this reason, the objective of a particular solution may not be valid in every case where the solution is applied, for the purpose could completely change in each application.

If X is MORE reusable > X can be used to fulfill MORE purposes.

If X is LESS reusable > X can be used to fulfill LESS purposes.

From this, we can conclude:

  • The amount of purposes a solution could be used to fulfill is directly proportional to its reusability potential.
  • The reusability potential of a solution is directly proportional to the amount of purposes it's able to fulfill.

Following this line of thought, the question "How can a solution be designed in a way that it can be used to fulfill multiple purposes?" remains unanswered. The amount of purposes on which it could be used will not (in almost every case) remain clear during the early stages of its definition. A new factor should then be introduced to guide the solution's design towards increasing its reusability in case it is required and the resources for doing it effectively and responsible are available.**

** If something is comestible, it doesn't mean that it will feed any Qt. of people per ration if someone would eventually eat it or even if there are actually people who need to be fed. The same goes with IT solutions that balance several things other than design factors before deciding on the application of additional effort entailed by increasing reusability potential.

The concept of "agnosticism" will be introduced as the aforementioned factor. Agnosticism comes from Greek, and it literally means "without knowledge". The concept was mainly used for religion-driven philosophy, but in the last 50 years the scientific community has started to use it as a qualifier of compatibility:

The more agnostic X is to Y, the more compatible X is to the category or group to which Y belongs ***.

*** This statement has its origin from the idea on which the more something (generally speaking) "knows" the reason for its existence (answering the question "what for?" hence telling its purpose), the less useful could become on situations in which its reason to be used may be different from the one known beforehand. This relies on the presumption in which a solution is then specially designed as to comply with its known purpose, increasing the coupling to it, and becoming more effective in its fulfillment. This approach would entail adding details and features to the solution that could make it less effective or even useless in different functional contexts.

Examples:

  • JAVA is agnostic to its underlying OS. > JAVA is compatible for usage on different OS's.
  • This hammer is agnostic to the nail it hits. > This hammer is effective at hitting different nails.
  • This calculator is agnostic to any equation. > This calculator is compatible to multiple equations.

A collateral consequence of this definition is that nothing can be defined as solely agnostic. It must be defined as agnostic to a particular category of things. This is not the most common case within IT initiatives, in which the modifier "agnostic" is used alone for simplicity's sake or even to increase the scope of its applicability. There is always an implicit accord with this, and there is usually no doubt about to which category of things that attribution is being related.

The purpose is what relates a problem to its solution. The more agnostic a solution is to its problem, the more agnostic it is to its linking purpose. The original problem cannot be changed but can only be replaced; therefore, the design and definition of its solution are responsible for the increasing the level of agnosticism associated with its purpose. They must at the same time remain effective for the problem that initially connected them. This last attribution is represented by the solution's objective which maintains the descriptive information required to understand the first or original purposes that solution was intended to fulfill.*

*A glass will always be considered to have been made to hold liquids. Despite the number of purposes that could be given to it, its objective will be maintained until is no longer contextually meaningful. This means that the objective remains implicit, for it should be interpreted from the original solution's context, known by that solution's owner. It makes a clear distinction between the original and/or fundamental purpose of a solution and all those following. The logical distance and the particular contextual differences between a solution objective and a particular purpose given to it are a measure of how effective that solution is at fulfilling that purpose.

  • The MORE agnostic the design of a solution, the MORE agnostic the solution is to its initial purpose.
  • The MORE agnostic a solution is to its initial purpose, the MORE compatible it is to other purposes.
  • The MORE compatible a solution is to any purpose, the MORE likely it is that that solution will be able to fulfill those purposes.

Taking all this into consideration, we can assert that:

  • The reusability potential of a solution is directly proportional to the agnosticism of its design.

In conclusion: The more agnostic, the more reusable.

What is Reuse?

Reuse is the action of using something more than once, in a different functional context from the one for which it was initially designed.

*This definition may not be effectively used outside the conceptual context of this article. The same could be considered for the aforementioned concept of reusability because it is broken down by semantics. If something is used for a second time, it is reused. Plain and simple. Although this is semantically correct, it is not true reuse from which IT initiatives benefit the most. The definition chosen for this article does not allow a solution to be defined as something that has been reused if it is executed in the same functional context. For example, a glass wouldn't be considered reused if it were used simply to hold two different liquids.

With this description in mind, it is important to notice the main and most important difference between the words reuse and reusability:

Reusability: "... the ability of something to be used more than once ..."

Reuse: "... the action of using something more than once ..."

The difference is simple:

Reusability promotes and enables reuse but does not ensure it.

This semantic difference between ability and action is a key factor to consider within Enterprise IT Initiatives. The consequences of blindly promoting reusability are negative:

Analysis & design overhead

  • Increased participation of Users and Business Analysts.
  • Increased complexity of IT solutions.
  • Increased platform and infrastructure requirements.
  • Increased costs and implementation times.

Governance complexity

  • Increased bureaucracy and cultural resistance
  • Increased IT solution life-cycle length and complexity.
  • Increased requirement of management tools.
  • Increased SCM & CM processes and complexity.

Every single one of the aforementioned implications remains true with or without truly reusing the solutions made from that context. The main difference relies on the ROI and other collateral benefits expected from them and should balance the equation when concrete reuse has taken place.

On the other hand, if concrete reuse is not promoted and applied, all those negative implications remain as sunken costs and reduced trust for the initiative. This in turn may slow down and stall that initiative and even drive it to early termination.This in turn may slow down and stall a system and even drive it to early termination.

This article will continue in Part II.

- Part I Published: September 20, 2015 • Service Technology Magazine Issue XCII

Imagen: Luis Zafra, Creative Commons.

Un proceso de negocio, cualquiera sea el tipo de organización y finalidad que persigue, se lleva a cabo dentro de un conjunto de normas, políticas y prácticas que permiten coordinar una serie de actividades relacionadas que definen lo que se conoce como “cadena de valor empresarial”. Business Process Management (BPM) es una disciplina que considera a los procesos de negocio como activos, administrando su ciclo de vida, proporcionando un marco de gobierno, con el objetivo de optimizarlos, agilizarlos y mejorar su performance.

Si bien las ideas y conceptos de BPM llevan más de una década en el mercado, aún resta dar a conocer sus beneficios y por qué una organización debería tenerlos en cuenta a la hora de pensar una estrategia para organizar el universo de aplicaciones y sistemas que se utilizan en una misma organización. Este documento persigue el objetivo de clarificar los beneficios de utilizar BPM viéndolo como un orquestador y no como una aplicación más.

grafico-1 (1)
Actualmente, las empresas se ven abocadas más que nunca a afrontar una dinámica de trabajo realmente exigente. La necesidad de ser cada vez más competitivas ha llevado a comprender que la mera formulación de la estrategia ya no es suficiente, también es esencial diseñar y mejorar adecuadamente los procesos, los servicios y las reglas para implementar dicha estrategia con eficacia.

Deben considerarse aspectos prioritarios para que las empresas sean más agiles, es decir, gestionen los cambios de una forma más rápida, sean más eficaces, eficientes y finalicen más tareas, más rápido y a menor costo; asegurando la mejora continua de sus procesos y la satisfacción del cliente.

BPM, es más que una tecnología, es un sistema de gestión enfocado a perseguir la mejora continua del funcionamiento de las actividades empresariales, ayudando a las personas a administrar su trabajo, resolver de forma rápida y eficiente sus tareas, facilitar la colaboración entre departamentos y tomar correctamente decisiones con una orientación a la consecución de objetivos a corto, mediano y largo plazo.

El funcionamiento de una empresa queda definido por sus procesos, las personas participan en ellos y BPM juega un rol importante informando a las personas sus tareas, cumpliendo las políticas de la empresa, reduciendo el tiempo de comunicación, ya que cada uno recibe su lista de tareas y los detalles necesarios para completarlas.

La implementación de mecanismos que garanticen la visibilidad de los procesos es un requisito indispensable en las organizaciones que han adoptado el enfoque de gestión por procesos, porque estos mecanismos se encargan de proveera los responsables de los procesos la información necesaria para que puedan detectar, de forma oportuna, las desviaciones en el desempeño.

BPM contribuye a mejorar la visibilidad sobre los procesos de la organización, los responsables de los procesos son informados y alertados de forma permanente y oportuna sobre diferentes aspectos importantes, tales como:

  • evolución de los indicadores de desempeño de los procesos.
  • la carga de trabajo por participante.
  • la cantidad y duración de las instancias de procesos y tareas en ejecución.
  • diversas situaciones que podrían afectar el desempeño del proceso.
  • el incumplimiento de los plazos para iniciar o concluir tareas específicas dentro del proceso.

Una adopción exitosa de BPM ayudaa mejorar la alineación de la estrategia de negocio con la estrategia de IT mediante la mejora de la eficiencia operativa, la visibilidad y la previsibilidad, y aumentando la agilidad organizacional.

grafico-2

Una descripción clara de procesos, una mejor visibilidad de los estados de un proceso en ejecución y un apropiado procesamiento de los eventos que se generan durante la ejecución del mismo permiten predecir posibles desviaciones y tomar medidas correctivas a tiempo.

Esta combinación de conceptos pone la información adecuada al alcance de las personas pertinentes, en el momento oportuno y en el debido contexto, Si se aprovechan correctamente, se puede obtener una ventaja competitiva a la hora de tomar decisiones de negocio.

Gracias a la combinación del valor inherente de lo que ofrece BPM y las capacidades diseñadas con objeto de aprovechar los eventos para obtener una ventaja competitiva es posible actuar de manera inmediata, algo fundamental en todo negocio en la actualidad.

Referencias:

1 - El Libro del BPM

Publicado por el Centro de Encuentros BPM. ©Club BPM, 2013, Madrid. ISBN: 978-84-616-4268-7 Versión Digital

http://www.club-bpm.com

2 – Getting Started with Oracle BPM Suite 11gR1

Copyright © 2010, Oracle and/or its affiliates

3 – ¿Por qué BPM?

©BPMteca.com, 2013, Madrid

www.bpmteca.com

¿No está funcionando la Daily meeting? ¡¿Qué podemos hacer?!

Conocida como Scrum Daily meeting, Stand-up Meeting o simplemente Daily, esta reunión es una de las herramientas más útiles en el trabajo de los equipos ágiles (y, en realidad, no sólo en ambientes ágiles) ya que permite la transferencia de información y mejora la colaboración entre los miembros del equipo poniendo de manifiesto en qué se pueden ayudar unos a otros.

Su objetivo, tan simple y claro, a veces se puede ver perturbado por algunos errores evitables cuando las llevamos a la práctica, los cuales podrían hacer que se conviertan en un ritual inútil, una pérdida de tiempo o, incluso, que se dejen de lado y se abandonen.

Una estructura eficiente para esta reunión tiene las siguientes características:

- Timebox de máximo 15 minutos.

- Cada miembro del equipo debe responder estas preguntas dentro del timebox:

1. ¿Qué hice desde la última daily? ¿Hice todo lo que tenía planeado? Si no, ¿cuál fue el problema?

2. ¿Qué voy a hacer a partir de este momento?

3. ¿Tengo identificado algún impedimento para cumplir mis compromisos en este sprint (hito, etapa, periodo)?

- Luego de la reunión (y sólo luego de la reunión), los involucrados en los problemas puntuales planteados o en los impedimentos detectados, se juntan para resolverlos y avanzar, pero fuera de la daily meeting. Esta reunión posterior se puede anunciar durante la daily e invitar a las personas interesadas para que se queden.

Errores comunes

Scrum desde las trincheras* identificó los cuatro errores más comunes al momento de llevar adelante las dailies. Las comento a continuación:

1. El reporte del status se hace dirigiéndose al Scrum Master (o al Project Manager). El reporte, en realidad, es para todo el equipo y de interés de todo el equipo, no un reporte de control.

2. Discusiones de diseño (o temas técnicos que no afecten a todo el equipo): es muy fácil saltar a un tema particular si un miembro del equipo está hablando acerca de problemas de diseño o técnicos que dificultan su tarea. La reunión se debe limitar a reportar progreso y obstáculos para cumplir compromisos. Los problemas y discusiones tienen otros ámbitos para ser tratados.

3. Perder personas durante la reunión: el horario que defina el equipo es muy importante para asegurar que todos estén presentes. Es la forma para poder conocer el progreso del equipo entero. Además, potencia la colaboración para solucionar bloqueantes y problemas detectados durante la daily. Se recomienda mantener el horario acordado y evitar andar reprogramando constantemente porque esto resta al compromiso del equipo.

4. Aclaración de requerimientos: pequeñas aclaraciones de requerimientos que lleven 30 segundos están bien, pero todas las demás aclaraciones deben diferirse para una discusión después de la reunión.

Entonces, ¿cómo puedo potenciar mis Dailies?

¿Hay algo que podamos hacer para mejorarlas? Si mis reuniones son efectivas, ¿las puedo potenciar? ¡Sí! Podemos ayudarnos teniendo claros los objetivos de esta reunión siguiendo la sugerencia de Martin Fowler, usando la nemotecnia GIFTS (Good Start, Improvement, Focus, Team, Status):

● Good Start (buen comienzo): ¡debemos asegurar que la reunión nos recargue de energía! ¡Que sea motivante! Esta energía proviene de tener presente el sentido de urgencia y propósito; esto es, entender qué cosas necesitan ser hechas y por qué. Importante no confundir con “falsa urgencia”, donde la gente está preparada para la acción pero sin una dirección compartida. Para energizar, además, se podría comenzar con algo divertido, como por ejemplo algún chiste diario, una anécdota o la pregunta del día. ¡Esto ayuda al team building!

● Improvement (mejora): “el propósito no es reunirse, es mejorar”. Hacer de la Stand-up meeting una oportunidad no sólo de compartir problemas, sino también de compartir mejores técnicas e ideas para hacer las cosas, contar qué me está funcionando, qué aprendí.

● Focus (foco): “foco en la posta y no en los corredores”. Es muy fácil confundir esfuerzo con trabajo. La Daily debería fomentar el enfoque en mover el trabajo a través del sistema (tablero, estados) con el fin de lograr nuestros objetivos y no fomentar la actividad sin sentido.

● Team (equipo): más que hacer con el equipo ejercicios de “team building” artificialmente, es importante construir un equipo eficaz, lo cual se hace con comunicación fluida, trabajo en equipo y ayudándose entre sí. Eso está fuertemente relacionado con el apoyo mutuo que los miembros del equipo puedan tener para ayudar a los demás a remover obstáculos. Animar estas actitudes dentro del equipo potenciarán el poder de las dailies.

● Status (estado): ya tenemos la estructura de preguntas para llevar adelante la daily. Sin embargo, podríamos potenciar las preguntas de la siguiente manera:

○ ¿Cómo está progresando mi trabajo? Esta pregunta incluye las tres preguntas de la estructura tradicional.
○ ¿Hay algo más interesante que el equipo debería saber? Siempre y cuando sea algo de impacto e interés general, aporta muchísimo compartirla durante la daily. Eso sí, ¡sin caer en los errores mencionados!

Obviamente, deben haber más espacios para este tipo de discusiones, mecanismos adicionales que permitan responder a estas preguntas, pero la Daily es una oportunidad más para garantizar que información valiosa no caiga en el olvido.

Consideraciones basadas en:

* Daily Scrum Mistakes (http://scrumfromthetrenches.blogspot.com/2008/05/daily-scrum-mistakes.html)
y It’s not just Standing Up (http://martinfowler.com/articles/itsNotJustStandingUp.html)

The most frequent issues that organizations face when implementing a SOA initiative are related with problems with the governance and control of the execution of the project. This is why it is critical to have a well-defined and functional SOA Governance system within the SOA initiative to succeed. Some of the issues are:

  • Uncontrolled growth of the number of services
  • Not reusable services and redundant services
  • Lack of metrics to calculate ROI
  • Unstandardized service design and development
  • High cost of services maintenance

SOA Governance vs Government, Methodology and Management

Before introducing the SOA governance concept, it is important to differentiate itself from others. First, Government is a logic group of roles and people that has the authority to take decisions over a organizational system. While on the other hand, the governance provides a framework to make decisions which determinates how these decisions should be taken within an organization. Finally the methodology is a group of processes and rules that follow this framework defined by the governance and the management is the group of people that execute these tasks and processes.

A SOA governance system is a group of controls, processes and methods that provide a systematic way to make decisions during a SOA initiative in order to achieve the expected goals, effectiveness, ROI and agility of the SOA project and to avoid the mentioned issues.

SOA Governance main components

The SOA governance system should be based on the organization characteristics, business and service-orientation maturity. So it is important to do a good SOA assessment of the organization to define the correct SOA governance system. This system should contain at least the following recommended components:

  1. SOA Governance Controls: These are the building blocks of the governance system.
  • Precepts - define the rules that govern decision-making.
  • Roles - people that assume roles to make decisions based on precepts.
  • Processes - coordinate people and precept-related decision-making activities.
  • Metrics - measure compliance to precepts. [1]

These building blocks will control and constrain decision-making during the SOA initiative lifecycle by the application of standards and definition of processes.

  1. SOA Project Lifecycle: Guides the definition of the common and primary stages (or phases) related to SOA projects and the overall service lifecycle. [2] During these stages the management will involve the defined roles and execute the corresponding processes.
  2. SOA Vitality Framework: Since the governance system may lose effectiveness during the execution of the initiative, is necessary to monitor the vitality of the SOA governance system and apply fixes to keep it up to date and functional.
  3. Service Registry Standards: The service registry is a key aspect in any SOA project. So it is very important in the SOA governance system to define the information that the registry should contain and how this information should be managed and updated during the project execution.
  4. Change Management Process: This process contains the definition of how the changes should be approved, managed and implemented within the execution of the SOA initiative or project.

Conclusion

The most frequent reason why SOA initiatives fail is problems with the governance and control of the project. This is why the SOA Governance system is critical for any SOA initiative to succeed and it should defined considering the organization characteristics and goals. The main components of the system are SOA Governance Controls, SOA Project Lifecycle, SOA Vitality Framework, Service Registry Standards and Change Management Process but others may be added based on organizational or project needs.

[1] SOA Governance: Governing Shared Services On-Premise and in the Cloud – Thomas Earl.

[2] http://serviceorientation.com/soaproject/projectlifecycle.

Una de las grandes novedades que introdujeron las metodologías ágiles fue la representación y especificación de los requerimientos: los mismos deben capturarse desde el punto de vista del usuario que interactuará con el sistema. La notación elegida se denominó User Stories (US).

Una US describe una funcionalidad que brinda el sistema que es de interés para usuarios del sistema. La pregunta que surge casi inmediatamente es: ¿qué tan general o específica debe ser una US?

Por ejemplo, una US podría ser: “como usuario quiero poder comprar electrónicamente un producto para evitar salir de mi casa a efectuar la compra”. Esta podría ser la única y gran US de todo un sistema dedicado a la venta mediante Internet. Sin embargo, redactada de esta forma y por sí sola, no es de mucha utilidad para la planificación y gestión de un proyecto. El otro extremo, igual de inútil, sería llenar el backlog de centenares de US con pequeña y limitada funcionalidad. En todo tiene que haber un equilibrio y el mismo viene dado a través de lo que se conoce como EPICS stories o simplemente EPICS [1].

Se trata de US grandes, generales, que se redactan como cualquier US, pero en el futuro serán descompuestas en muchas US más controlables.  Justamente por eso se denominan EPICS, por “épico” en inglés, en alusión a una funcionalidad “gigantesca” o “extraordinaria”. En lo que resta del artículo abordaremos el concepto de EPICS, su utilidad, y la manera de explotarlas a medida que avanzan los sprints y el backlog.

EPICS: Conceptos fundamentales

Al comienzo de un proyecto hay funcionalidades que están más visibles y son sencillas de especificar:

- “como usuario quiero loguearme en el sistema…”,

- “quiero agregar productos a mi carrito de compra”,

- “quiero poder pagar con tarjeta de crédito”,

- “quiero que mis datos estén protegidos”.

Sin embargo hay otras de las cuales no se conoce mucho, pero que de todas maneras se desea expresar que el equipo sabe que existen, aunque sea muy pronto para poder definirlas con mayor granularidad. Para este tipo de funcionalidad se utilizan EPICS. Las mismas permiten en etapas iniciales del proyecto dejar expresada una funcionalidad importante, pero sobre la cual no existen muchos datos todavía y no es posible asignar una estimación sobre su duración o esfuerzo.

Continuando el ejemplo del sistema de ventas online, una posible EPIC podría ser “quiero contar con un protocolo seguro y confiable de comunicación”. Esta US implica quizás el desarrollo de todo un protocolo específico que brinde seguridad y redundancia de datos y que involucre distintas infraestructuras y tecnologías como Posnet o servicios web que proveen las tarjetas de crédito. Dado el contexto, es probable que el equipo de desarrollo no pueda estimar el esfuerzo o duración de esta funcionalidad, y no esté por el momento en condiciones de brindar más detalles o comportamiento. Así, dicha funcionalidad queda expresada en el backlog como una EPIC, especificada de manera general.

El rol de las EPICS en el backlog es justamente ese: dejar por explícito que hay una tarea importante por delante por hacer, pero que por el momento no es posible ni beneficioso hacer nada más.

Descomposición de EPICS

Más adelante, y con el equipo más afianzado en el proyecto, el Scrum Master estará en condiciones de dividir una EPIC en varias US. Éstas US si contarán con la suficiente granularidad y detalle para poder ser estimadas, y podrán ser descompuestas en tareas asignables a los recursos humanos que forman el proyecto. Pero esta descomposición recién se hace al momento de incluir parte de la funcionalidad descrita en la EPIC en el próximo sprint. Tal como está definida, es imposible asignarla a un sprint. Si se desconoce el esfuerzo que le llevará al equipo desarrollarla, es imposible saber si puede “entrar” en el próximo sprint o no.

En este momento el Scrum Master con la colaboración del equipo de desarrollo toma riendas en el asunto y se pasa a dividir una EPIC en US manejables y estimables. Así, en el caso de la EPIC sobre el protocolo, pueden surgir US y tareas más detalladas:

EPIC US
“quiero contar con un protocolo seguro y confiable de comunicación” - estudiar tecnologías y protocolos de comunicación- generar la integración con servicios Posnet

- validar la interacción con los servicios web de las tarjetas de crédito

- desarrollo del protocolo de comunicación

- validación del protocolo

Conclusiones

El rol de las EPICS es importante dentro de las metodologías ágiles. Le brindan al mecanismo la suficiente flexibilidad como para dejar expresado que existe una porción importante del sistema que deberá ser tenida en cuenta y explotada más adelante en el proceso de desarrollo. Pero al mismo tiempo queda explícitamente documentada, lo cual permite su visibilidad, tanto para el equipo de desarrollo y Scrum Master, como así también para el Product Owner y todo aquel involucrado en el proyecto.

Referencias

[1] http://www.romanpichler.com/blog/epics-and-ready-stories/

It is easy to think that the world of marketing and product design are impossible to combine. Both cultures are decidedly different, and often sit on opposite sides of the organization. And, however, they are not so different.

I recently read " Confessions of an Advertising Man, " by David Ogilvy. It is a classic text by a legendary teacher. The book was written in 1963, in an era where paper and television were the most used media. Ogilvy began his career as a salesman in Scotland, his native country. After working as a chef and trying his luck in the field, he founded an advertising agency, which became one of the most important and respected in the world. The author died in 1999, at the beginning of the digital age, and did not see the transition in which we find ourselves.

Despite this, Ogilvy's text is of great relevance to the digital world of today. In particular, his vision on the quality of campaigns teaches us to design better experiences, products, brands and services. In his book, Ogilvy describes 11 principles to create effective campaigns. This was the basis of the success of his advertising agency.

When reading the principles I realized its relevance for the creation of products, experiences and digital services. By changing some words of place and modifying the context, Ogilvy's principles can compete with the UX notions of the current leaders. In my opinion, these are the principles that we must follow to adapt to the new reality of design.

1. What you say to provide is more important than how you say to provide it

Ogilvy considered advertising as the way to help consumers make purchasing decisions. In the end, it's about facilitating sales. The central thing to help people buy is to show them the product in the most effective way possible.

"Your most important job is to decide what you're going to say about your product, the benefit you're going to promise." In the same sense, the most important work for digital products and services involves deciding what they are going to do. People do not use a product of this type because it has incredible animations or is visually appealing. They use it because it provides a tangible value, it has a real usefulness, and a good content. If people do not receive this, the experience fails.

A good example of this situation is Dropbox, which uses a clear metaphor to explain how it works. Dropbox is a box in which users put and take files remotely. It manifests as a simple folder in which we move information on the PC. In this way, the central value is expressed through the entire product experience.

2. The campaign will be a success only if it is built around a great idea

Ogilvy was not interested in creating basic campaigns, which adhered to the standards or conventions of his time. He was convinced that avant-garde ideas can bring tremendous results for clients.

In many cases, digital designers do not have this great ambition. Creating a new experience becomes a task of organizing the content and the interface. The ordered and simple categories are prioritized, that even if they work, they do not have a deeper meaning, or they fail in the connection with the brand. Creating something usable is not a virtue, but a basic requirement. The design of experience must be nourished by great innovative ideas.

3. Prioritizes the data

"Most modern advertisers prefer to write short and lazy ads, collecting data is hard work."

Ogilvy was interested in discovering the largest amount of data about the product to communicate to the consumer. It does not matter if the competitors had a similar product or if they could say the same things. The important thing was to deliver the data about the product. For Ogilvy, "short and fast" ads betray the consumer and are an easy way out for the advertiser.

A similar dynamic can be seen with digital products and services. People are interested in the benefits, in what the product allows them to do. As designers, it is our responsibility to understand the needs of consumers, and then create experience that can satisfy them. Easy to say, hard to do.

4. You can not bore people if you want them to buy

Ogilvy thought that competition for people's attention was becoming fiercer than ever, and it was only 1963. The world became more fierce, more fragmented and varied. And yet, the work remains the same: "It is our goal to make the voices of customers heard." The same goes for digital experiences.

The product experience should stand out from the crowd. It should be something that people enjoy using regularly, that they recommend, promote and share. For design teams, it's a matter of art and skill. They must generate experiences with details that make the difference in front of the competition.

Take the example of Instagram. While Hipstamatic was the first photography application, Instagram integrated social networks with a superior mobile experience. Nowadays it is the most important photographic social network: every day more than 40 million images are uploaded and there are at least 90 million active users in the month.

5. Cultivate good manners

"People do not buy from sellers with bad manners, and studies indicate that they do not buy from malicious ads"

Ogilvy worked as a door-to-door salesman. He had experience introducing himself, gaining the trust of the client, and finally specifying the purchase. He knew the value of charm and knew how to take advantage of it.

The charm of a digital experience is important, and involves tone, character, personality. The charm comes through the small details: from the visual design, the text, the way in which errors are handled and so on. What is sought is a coherent experience that is attractive to human sensibility. The important thing is to let consumers make their own use of the product. Do not obstruct the user experience. This happens when a product assumes that the user is more interested in using the interface than in extracting a value from it. The history of interface design is full of failed experiments around charm and experience. The Microsoft Clippy Wizard is a classic example of how things can go wrong.

6. The experience must be contemporary

Ogilvy estaba muy preocupado por conectarse con los consumidores más jóvenes. Por ello, contrataba a jóvenes escritores, indicando que "ellos comprenden la psicología de la juventud mucho mejor que yo".

Ser contemporáneo requiere mucho más que estar al tanto de los cambios. Requiere plantear a largo plazo con un proceso de desarrollo iterativo, anticipando el cambio antes que suceda. Significa mejorar y reinventar continuamente la experiencia del producto. Las experiencias digitales contemporáneas deben estar a la altura de las expectativas de los consumidores. Vivimos en un mundo con un rango de audiencias y una variedad de expectativas cada vez mayor. Es un planeta globalizado, multi plataforma y micro demográfico.

7. Los comités pueden criticar publicidades, pero no escribirlas

El diseño por comité llevó a malos resultados en la épica de Ogilvy, y lo mismo sucede hoy en día. Algunas cosas nunca funcionan. "La publicidad parece vender mejor cuando está escrita por un solo individuo".

El mismo principio puede aplicarse al diseño de productos y servicios digitales. Muchas experiencias se sienten como una colección de características, en gran parte porque son el resultado de requerimientos creados por comités. No tienen la coherencia que llega de la convicción y la visión. Hay una razón por la que los startups digitales exitosos provienen de equipos pequeños y bien aceitados. La popularidad creciente de las metodologías Lean y Agile tiene que ver con el reconocimiento de lo que requiere un proceso de desarrollo efectivo. Se trata de sincronizarse con el ritmo de la creación. Crear grandes productos y experiencias requiere visión, foco y dedicación. Este dato nunca cambiará.

8. Si tienes suerte de escribir buenas experiencias publicitarias, continúa haciéndolo

Ogilvy reconocía al mercado como un fluido, un material siempre cambiante. Las personas nacen y mueren cada día. En cualquier mercado, nuevas personas llegan, y otras se van. El punto está en lograr un engagement constante, "tener un buen radar" para adaptarse al cambio.

Lleva tiempo construir buenas experiencias, y mucho más las duraderas. Requiere de una mejora constante mediante updates y versiones. En el espacio digital, nuestros radares se han vuelto muy fuertes. Podemos monitorear cómo las personas utilizan los productos, y adaptarnos en base a esa información. Cualquier buen equipo sabe que esta visión es indispensable para el diseño de experiencias digitales.

Pero también hay un lado oscuro para la escala y la flexibilidad del entorno digital. Los diseñadores deben reconocer el momento en que las nuevas características ya no suman al producto. El desafío es balancear el cambio y la evolución continúa al mismo tiempo mantener una constancia de lo que funciona bien de la experiencia.

Podemos tomar la página de inicio de Google como ejemplo. La simplicidad y el foco de ese sitio no ha cambiado. La calidad de los resultados mejora constantemente, en base al monitoreo constante y los esfuerzos de ingeniería. Más recientemente, los resultados han evolucionado para tener una experiencia más similar a la de una aplicación.

9. Nunca escribas un anuncio, crea una experiencia

Para Ogilvy, todo el punto de una publicidad es hablar de un producto de una manera que fomente las compras. Mentir sobre un producto o engañar con información falsa será detectado o bien por los gobiernos, o más significativamente, por los consumidores.

Si tus productos son malos, las personas lo sabrán rápidamente. En estos días, esto se ve amplificado por Internet y las redes sociales. El boca a boca es más fuerte que nunca. Si el producto provee una experiencia excelente las personas la repetirán, le contarán a sus amigos, y los invitarán a experimentarla. Una mala experiencia daña la reputación, y derrocha tiempo, dinero y paciencia.

10. La imagen y la marca

Ogilvy proponía un estilo consistente para la publicidad de la marca a través de los tiempos. Esto es esencial para construir una personalidad coherente, una imagen de marca duradera, y para conseguir el éxito en el mercado.

Cada experiencia de producto y servicio debe ser reconocida como una contribución a la imagen de la marca. Por ello, debe diseñarse, mantenerse y organizarse con esta verdad central en mente. Se debe generar un patrón a partir de experiencias sucesivas exitosas. Y este patrón debe estar enraizado en los valores centrales de la marca.

Mantener patrones consistentes requiere valor y dedicación, sobre todo al hablar de diferentes plataformas, versiones y dispositivos. Hay muchas fuerzas que trabajan en contra de nuestro objetivo: la tentación de hacer algo nuevo es tremenda, las voces de las "buenas prácticas" y los "estándares de la industria" pueden hablar muy fuerte. Y sin embargo, las recompensas aguardan para aquellos que invierten en un patrón consistente, y sobre todo para aquellos que logran sostenerlo en el tiempo. Es la suma total de la experiencias que las personas tienen con tu marca las que definen el valor y determinan tu posición en el mercado.

El diseño Metro de Microsoft es un buen ejemplo. Con raíces en el diseño de interfaz de Xbox y Zune, el lenguaje Metro floreció con el lanzamiento de Windows Phone 7, y se expandió hacia Windows 8 como la nueva identidad de la marca.

11. No seas un imitador

"Si algunas vez tienes la fortuna de crear una campaña exitosa, pronto verás que otra agencia la robará. Esto es irritante, pero no dejes que te preocupe. Nadie nunca ha construido la imagen de una marca imitando a otra.

El punto de Ogilvy en todo esto es enfocarse en el producto, hacer el trabajo duro, encontrar esa gran idea, y finalmente construir una marca duradera en el tiempo. Este principio centraliza a todos los demás.

El mundo de las experiencias digitales está lleno de imitación. Sea piratería de propiedad intelectual, la copia de un líder de mercado, conceptos prestados y más. La clave es lograr imprimir un valor y un estilo a la marca, definir una personalidad atractiva, generar una experiencia única. Nadie ha construido una marca copiando las experiencias de otras. Friendster y MySpace, por ejemplo, ofrecían un servicio muy similar al de Facebook. Todos tenían características parecidas, pero Facebook tenía un estilo único, un tono interesante, y una implementación innovadora. Como resultado, MySpace tuvo que redefinir su experiencia y adaptarse a su nueva realidad de mercado.

Apple llevó a Samsung a juicio por copiar la experiencia de iOS. En su acusación, Apple citó al lenguaje de diseño Metro para ilustrar que no todos los smartphones deben estar diseñados de la misma manera.

Seguir "buenas prácticas" y hacer diseño perezoso son dos caras de una misma moneda. En el fondo lo que importa es enfocarse para definir patrones únicos, y construir una imagen de marca fuerte a través del tiempo.

Trabajando juntos

Los marketers bien establecidos tal vez ya conocen los principios de Ogilvy, pero igualmente es importante considerarlos desde el contexto del diseño de productos digitales. Mirar al marketing a través del lente de las experiencias digitales nos permitirá cerrar la grieta entre la comunicación y el valor de la marca.

Ogilvy's principles are also important for those digital designers who previously believed that marketing had nothing to do with their work. It is about ensuring that the experience communicates the history and vision of the brand.

To be successful and create good digital experiences, I ask the worlds of marketing and product design to start working together and working together. They must create brands, products and services with a deep meaning, that are relevant and can connect with their consumers.

By Ted Booth

Todo proceso de desarrollo se encuentra, en su ejecución y entre otras características, estrechamente ligado a la forma en que un conjunto de distintas herramientas interactúan para ayudar a llevar el producto adelante.

En particular dentro del universo de los métodos ágiles existen numerosas herramientas que ayudan al equipo de desarrollo a crear, construir, planificar, gestionar y monitorear el avance de User Stories (US) y apoyan la organización y gestión de backlogs, sprints, burndown charts, retrospectivas y la mayoría de los artefactos que son propios de la gestión ágil.

Sin embargo, no hay una “bala de plata” entre las herramientas. No existe una que tenga todo al mismo tiempo y con cada función dentro del nivel esperado. Algunas hacen mayor énfasis en la creación y seguimiento de US dejando de lado la generación de estadística o métricas. Algunas herramientas buscan simplicidad al costo de marginar funcionalidad. Otras incorporan servicios más avanzados, pero son más complejas de utilizar, ampliando el período de capacitación y curva de aprendizaje. Como siempre, es importante tener en cuenta ventajas y desventajas de cada uno al momento de elegir la herramienta a utilizar. A continuación se describen algunas de las principales herramientas, detallando sus fortalezas y debilidades [2].

Herramienta #1 - JIRA

JIRA es una aplicación, basada en el estándar J2EE, para la administración de proyectos que ofrece flexibilidad y adaptabilidad para satisfacer las necesidades particulares de los distintos modelos de gestión de los mismos. Esto le permite adaptarse fácilmente a métodos propios del agilismo como Scrum o Kanban.

JIRA cuenta con filtros personalizables y completos, que dan excelentes posibilidades para gestión, generación de métricas y reporting, complementos (Add-Ons), extras de JIRA (algunos pagos, otros no) que ayudan en necesidades específicas. Por ejemplo JIRA Agile proporciona tableros de Scrum (para procesos iterativos e incrementales) o tableros de Kanban (para gestionar el flujo en procesos dirigidos por la demanda) y permite construir y gestionar el backlog (epics, US, swimlines, etc), tener un trabajo colaborativo entre miembros del equipo y llevar métricas ágiles como Burndown charts, velocidad, CFDs, entre otras.

Otro aspecto destacable es la integración con otras herramientas que facilitan los flujos de trabajo y permiten, por ejemplo, lograr completa trazabilidad de los requerimientos, US, Test cases, documentación técnica y demás artefactos. Entre muchas otras integraciones, podríamos mencionar:

  • Documentación de US (y gestión del conocimiento) en Confluence y transformarse en tareas en JIRA.
  • Facilitar el flujo de trabajo de desarrollo actualizando automáticamente los issues de JIRA cuando un desarrollador introduce código en Stash o Bitbucket haciendo "Commit"
  • Implementar Continuous integration mediante Bamboo y supervisar el estado de los builds desde dentro de JIRA.
  • Integración con otros frameworks como SONAR[1] para la utilización de métricas de código como violaciones de reglas o código duplicado.

Herramienta #2 - EasyBacklog

EasyBacklog es una herramienta enfocada en la simplicidad. Es sumamente amigable, por lo que la creación y seguimiento de US, sprints y backlogs no representa ninguna dificultad. Está basado fuertemente en la interacción visual, con lo cual la modalidad “drag and drop” es una cómoda opción a la hora de trasladar US del backlog al sprint actual.

El costo de la simpleza de la herramienta es su escasa funcionalidad. No brinda ningún tipo de estadísticas, así como tampoco es posible asignar tareas a miembros específicos del equipo. Estas debilidades imponen fuertes restricciones en su uso. Sin embargo, es perfecta si sólo se quieren manejar US y monitorear su avance.

Dos casos de éxito de la herramienta provienen de un dominio donde no es fácil imaginar utilizar metodologías ágiles: desarrollo de software para agencias de publicidad. Sin embargo, dos empresas inglesas, Aqueduct y TMW han utilizado EasyBacklog con gran satisfacción [3].

Para Aqueduct fue difícil al comienzo adoptar desarrollo ágil ya que sus clientes estaban acostumbrados a un presupuesto fijo y esquemas de trabajo más “conservadores”. Sin embargo, encontraron en Easybacklog una manera amigable y sencilla de comunicar funcionalidad a los clientes, lo cual les permitió de alguna manera “educarlos” en el mundo ágil y lograron adoptar un esquema híbrido entre descripción ágil del desarrollo y una esquema contractual de pagos fijos.

Para TMW, la herramienta les permitió introducir el mundo ágil de manera iterativa e incremental en sus proyectos, priorizando primero los beneficios de la comunicación y dinámica que las metodologías ágiles le imponen al trabajo en equipo. Inicialmente incluyeron pequeñas iteraciones en sólo algunos proyectos ya que no es un dominio particularmente apto para el desarrollo ágil. Sin embargo, la facilidad de uso de la herramienta permitió una rápida aceptación en todos los niveles de la empresa, reforzando el compromiso al proyecto y una mejor guía para respetar plazos. Rápidamente se corrió la voz en la empresa de esta nueva manera de trabajar, logrando cada vez más participación de los recursos. En la actualidad se ha impuesto en TMW describir y comunicar la funcionalidad en US, así como la especificación de criterios de aceptación como especificación tempranas de casos de test.

Herramienta # 3 - SeeNowDo

SeeNowDo ofrece una interfaz de usuario simple y sencilla para la creación y especificación de US, así como también para la generación de sprints, y la correspondiente asignación de US a sprints. Si bien provee funcionalidad para estadísticas y generación de charts, posee dos grandes limitaciones: por un lado, no existe el concepto de backlog. Todo debe desarrollarse dentro de sprints, lo cual hace difícil el manejo y gestión de US. Por otro lado, su performance no es buena. Aún con proyectos chicos de pocas US la herramienta se vuelve lenta. Su principal ventaja es que en la versión gratuita tiene disponible toda su funcionalidad y no es necesario abonar por features adicionales.

Sin embargo, es importante destacar el principal objetivo de esta herramienta: trabajar con equipos ágiles de manera distribuida y remota. Es cada vez más común que los distintos integrantes del equipo no estén físicamente trabajando juntos día a día, por lo que es necesario contar con una herramienta distribuida que facilite y sincronice la comunicación entre todos. Para estos contextos SeeNowDo es la herramienta ideal.

Herramienta #4 AgileFant

AgileFant es de las herramientas que mayor crecimiento registra en cuanto a popularidad y cantidad de usuarios. Es bastante completa, incluye generación de estadísticas, velocity, burndown charts y utilización de métricas. Una característica interesante es que brinda la posibilidad de definir US generales (denominadas también EPIC Stories) y luego ir refinándolas, agregándoles más detalle a medida que el proyecto avanza. Entre sus puntos débiles se puede mencionar la poca flexibilidad para personalizar la herramienta, y su inexistente integración con otros sistemas, lo cual puede atentar contra su utilización en ambientes corporativos.

Es una herramienta con diversos casos de éxito en el mundo profesional. Por ejemplo, Sarah Schwanbeck, Senior Engineering Manager para Yahoo!, recomienda AgileFant por ser la herramienta ideal para el manejo de backlogs, ampliamente utilizada en desarrollos de la empresa. Coriant garantiza su buena perfomance. Destacando en particular que la herramienta les ha ayudado a entender con más precisión la funcionalidad de un proyecto que ya ha sido desarrollada y la que queda por hacer, facilitando la administración y gestión de los proyectos.

Herramienta #5 RallyDev

RallyDev es también una poderosa herramienta para la gestión de proyectos ágiles. Posee características avanzadas entre las cuales se destaca la generación automática de los distintos diagramas de seguimiento y la posibilidad de exportarlos a diferentes formatos. Esto es particularmente útil para la generación automática de reportes. Brinda también la posibilidad de control de cambios y revisiones para el manejo de US. Finalmente, dentro de cada US es posible definir criterios de aceptación como casos de tests, lo cual facilita la interacción con la fase de testing. Entre sus puntos débiles se puede mencionar una interfaz poco amigable, y bajo rendimiento en cuanto al tiempo esperado de respuesta para algunas características.

RallyDev es ampliamente utilizada en numerosas empresas de diferentes áreas. En la sección de medios y entretenimientos, NBC Universal , Editorial Abril o Gazillion Entertainment destacan su flexibilidad y rápida aceptación dentro de los equipos. La empresa Tata Communications explica que utilizando RallyDev lograron mejoras entre el 30 y el 50% entre costos y duración de proyectos, una mejor predisposición para ideas innovadoras, mejor visualización de los avances y también una mejor dinámica de trabajo en equipo. Finalmente, desde la sección del mundo IT, empresas como SeaGate o BMC Software también respaldan su utilización. Esta última empresa destaca principalmente el éxito logrado con un staff de 900 empleados distribuidos por varios continentes. Esto demuestra la adaptabilidad de la herramienta no sólo para equipos chicos de desarrollo, sino también para desafíos mayores.

Referencias:

[1] http://www.sonarsource.com/

[2] http://www.agile-tools.net/

[3] http://blog.easybacklog.com/

  • URL copied!