archivo

Archivos Mensuales: enero 2014

La segunda actividad es la que se denomina: “Crear un Elevator Pitch” y consiste en preparar un mensaje breve que describa el producto, su utilidad y destinatarios.

El anglicismo Elevator Pitch hace referencia a la brevedad y contundencia del mensaje que debería permitir que en un trayecto corto, como por ejemplo, el que tenemos en un ascensor, podamos hacer llegar a un tercero, la esencia de lo que pretendemos hacer.

Es un ejercicio complicado, ya que requiere de una importante capacidad de síntesis, teniendo en cuenta además que las conclusiones se deben obtener por consenso. Para llegar al Elevator Pitch se generará, probablemente, un intenso debate ya que en esta actividad es necesario bajar el nivel de abstracción, saliendo a relucir nuevos detalles.

En la plantilla que propone Jonathan Rasmusson, autor de estas técnicas, podéis consultar el formato que propone para el Elevator Pitch.

La tercera actividad es la que se denomina: “Diseño de una caja de producto”.

La diferencia con el Elevator Pitch es que en este caso tenemos que ponernos en el papel del potencial cliente o potencial usuario del producto con el objetivo de crear un mensaje o un slogan (el que pondrías en la caja del producto) con las características y/o beneficios del producto que lo convencerían para una potencial compra (o potencial aceptación del producto).

Como en el caso del Elevator Pitch debe ser algo sencillo (aunque no por ello menos creativo).

La primera actividad del Inception es la que se denomina: “¿Por qué estamos aquí?”.

Su misión principal es determinar, sin entrar en detalle, cuáles son las razones que nos llevan a meternos en este proyecto o en la realización de ese producto, y de ellas determinar cuál es la más importante.

Razones puede haber muchas: ganar dinero, hacer más efectivo un determinado proceso, incrementar la productividad, etc…

Si no resulta sencillo identificar razones puede ayudar la formalación de la siguiente pregunta: ¿por qué es necesario hacer esa inversión? Y no nos centremos exclusivamente en la vertiente monetaria ya que hay otras, como por ejemplo, el tiempo (que también puede/debe traducirse en dinero), el desgaste personal que supone realizar determinados tipos de proyectos en según que condiciones, etc…

Eso de confrontar unas ideas iniciales, que el ánimo o el optimismo puede empujar a querer convertir en proyecto, con su utilidad u objetivo real (las razones), es muy útil, porque lo mismo en ese momento, se cae en la cuenta de que hay otros aspectos más prioritarios en los que enfocar el esfuerzo e invertir el dinero, es decir, lo mismo se descarta la propuesta, se continúa con ella, se hacen matizaciones sobre el objetivo que se pretende o surgen nuevas ideas que se siguen analizando en este proceso.

La segunda actividad es la que se denomina: “Crear un Elevator Pitch” y consiste en preparar un mensaje breve que describa el producto, su utilidad y destinatarios.

El anglicismo Elevator Pitch hace referencia a la brevedad y contundencia del mensaje que debería permitir que en un trayecto corto, como por ejemplo, el que tenemos en un ascensor, podamos hacer llegar a un tercero, la esencia de lo que pretendemos hacer.

Es un ejercicio complicado, ya que requiere de una importante capacidad de síntesis, teniendo en cuenta además que las conclusiones se deben obtener por consenso. Para llegar al Elevator Pitch se generará, probablemente, un intenso debate ya que en esta actividad es necesario bajar el nivel de abstracción, saliendo a relucir nuevos detalles.

En la plantilla que propone Jonathan Rasmusson, autor de estas técnicas, podéis consultar el formato que propone para el Elevator Pitch.

La tercera actividad es la que se denomina: “Diseño de una caja de producto”.

La diferencia con el Elevator Pitch es que en este caso tenemos que ponernos en el papel del potencial cliente o potencial usuario del producto con el objetivo de crear un mensaje o un slogan (el que pondrías en la caja del producto) con las características y/o beneficios del producto que lo convencerían para una potencial compra (o potencial aceptación del producto).

Como en el caso del Elevator Pitch debe ser algo sencillo (aunque no por ello menos creativo).

La cuarta actividad es la que se denomina: “Crear una lista lo que No es”.

La eficiencia va de la mano de la simplicidad y una variable que influye en la misma es la huída del desperdicio de esfuerzo, es decir, de aquellas funcionalidades que no son necesarias para conseguir el objetivo que estamos persiguiendo.

También permite protegernos de malos entendidos (al menos desde una perspectiva global del producto) ya que en este punto se discute qué no va a ser o a hacer el producto.

La técnica propone crear tres listas:

– Lista de funcionalidades que entran en el alcance.
– Lista de funcionalidades que no entran el alcance. Es la más importante de las tres, porque en ella se hace una primera criba.
– Lista de funcionalidades para las cuales no se ha decidido su inclusión en el alcance. Se trata de funcionalidades que si hubiera oportunidad (económica principalmente y plazos) se incluirían en el alcance pero que se consideran en este momento menos prioritarias y se dejan, a un lado, de momento.

En este momento, lo más normal es que las funcionalidades o historias de usuario sean de alto nivel. La pregunta importante que se debe resolver es si la no inclusión de una funcionalidad en la lista de funcionalidades que entran en el alcance rompe con la esencia del producto y objetivos que se pretenden conseguir.

Todavía no es el momento de entrar a confrontar lo que se quiere con la realidad presupuestaria y temporal pero sí que se debe tratar de hacer la lista con los pies en el suelo.

La quinta actividad es la que se denomina: “Conoce a tus vecinos”.

Se trata de identificar a los grupos, equipos o departamentos de personas que van a tener una vinculación con el proyecto que se va a desarrollar, como por ejemplo, usuarios del sistema, administradores de bases de datos, administradores de sistemas, administradores de comunicaciones, centro de atención a usuarios, etc…

El ejercicio, aunque simple, es bastante potente porque trata de poner sobre la mesa que para que un proyecto salga adelante se necesita de más gente que el propio núcleo del proyecto y que la participación de esas personas no será testimonial, independientemente de que algunas de sus actuaciones sean más o menos puntuales, debiéndose tener en cuenta las mismas en determinadas decisiones y mantenerlas informadas adecuadamente sobre la evolución de los trabajos (entrando más en detalle en aquellos aspectos que les afecten directamente).

La sexta actividad es la que se denomina: “Muestra la solución”.

Es la primera actividad en la que nos centramos en el cómo.

Básicamente se trata de dibujar un diagrama de despliegue (o similar) en el que se identifiquen posibles nodos físicos (o agrupación de ellos si se consideran infraestructuras cloud o de alta de disponibilidad) y servidores lógicos (web, aplicaciones, bases de datos, etc…).

Además se hará una reseña de las tecnologías que se prevén utilizar en la solución.

Todo a muy alto nivel.

En ese esquema o ficha que se obtendría como resultado de esta actividad, se podrían señalar explícitamente algunos aspectos de la infraestructura o de la tecnología sobre los que habría que tener especial cuidado o atención, pudiéndose indicar el motivo o también expresar cualquier aspecto de las mismas sobre los que en estos momentos existan dudas. También se podría indicar explícitamente algún elemento o tecnología que no se tendría en cuenta en la realización del proyecto, sobre todo si existe riesgo de que se produzca algún malentendido.

La séptima actividad es la que se denomina: “¿Qué nos impide dormir?”.

Se trata de identificar los principales riesgos que puede tener el proyecto, es decir, aquellos que realmente nos preocupan, centrándonos en los que de alguna forma podemos manejar, gestionar o defendernos.

En este caso, se podría identificar como posibles riesgos, por ejemplo, que no exista un product owner que sea consciente del trabajo que debe realizar en el proyecto (o que siéndolo no se implique), que los procesos que se pretenden informatizar sean un caos en la actualidad, que el proyecto no tenga un respaldo económico suficiente, que los plazos sean demasiado rígidos, que el equipo de proyecto no disponga de personas con la suficiente experiencia y/o conocimientos en la tecnología, etc…

Como veis se pueden identificar riesgos que pueden ser atajados o gestionados antes de que el proyecto comience o que incluso hagan replantearse la viabilidad del mismo. Cualquier cosa mejor que iniciar un “Death March Project“.

La octava actividad es la que se denomina: “Estimar el tamaño”.

Se trata de establecer un orden de magnitud (deseable).

Dentro de ese esquema general se pueden establecer estimaciones parciales sobre determinadas actividades del proyecto, como por ejemplo, el tiempo en el que se espera tener la mínima versión viable del producto o determinados hitos de carácter funcional.

Con el resultado de esta actividad se podrá discutir si el tiempo necesario para obtener las diferentes versiones del producto resulta excesivo o no, si
se van a disponer de los medios necesarios durante todo ese tiempo, etc…

Puede darse el caso que, como consecuencia de esta actividad, sea necesario volver a otras anteriores para replantearse el alcance y/o la propuesta de solución planteada.

La novena actividad es la que se denomina: “Sé claro sobre lo que vas a proporcionar”.

En esta actividad se da un paso más en la gestión de las expectativas. En actividades anteriores se trabajó sobre las funcionalidades o sobre la tecnología, en este caso se pretende establecer el nivel de importancia, trascendencia y/o atención que se le debe dar al alcance, la inversión, los plazos y la calidad.

Además de esos parámetros principales, se pueden especificar otros que se consideren de interés para el proyecto.

La ficha que se obtiene como resultado de esta actividad es muy visual, tal y como se puede ver en la plantilla, de manera que se aprecia de forma muy clara, el nivel de importancia que se le da a cada uno de los parámetros.

Lo fácil es darle a todo el máximo nivel de importancia pero, como es lógico, esta actividad debe tratar de ajustar las expectativas a la realidad que va a tener el proyecto, es decir, puedes indicar que el alcance no es negociable, pero si sabes que va a existir una gran incertidumbre en el proyecto y/o no se tienen claro todavía determinados objetivos o cómo plasmar determinadas funcionalidades, tal vez sea conveniente modularlo y hacerlo más flexible.

Si, de verdad, se pretende realizar un proyecto con todos o algunos de los parámetros al máximo, algo que, ¿por qué no?, podría darse, se debe estar dispuesto a poner los medios necesarios para realizar el proyecto, siempre y cuando, el mismo pueda ser viable en esas condiciones.

Es decir, si los plazos son inamovibles, habría que estudiar si de entrada, los mismos son viables y qué se necesitaría para conseguir satisfacerlos.

La décima actividad es la que se denomina: “¿Cuánto va a durar esto?”.

De entrada puede considerarse una actividad parecida a la octava y en cierto modo lo es, solo que en este caso se trata de dar respuesta no solo a plazos sino también a costes y a las características que debe tener el equipo (tamaño, perfiles, habilidades, etc…), para cumplir los objetivos planteados.

En el caso de que las condiciones necesarias no se puedan cumplir se podría decidir la no realización del proyecto o bien, la necesidad de volver a actividades anteriores del Inception y replantear determinados objetivos y expectativas definidos.

No obstante, si el marco y sus conclusiones deben tomarse como algo provisional y/o con cautela, ¿para que sirve Inception?, independientemente de los argumentos que acabo de indicar, resulta muy positivo que, independientemente de que se alcancen acuerdos o consensos generales (que no siempre será sencillo), se abra un debate sobre el producto que se pretende obtener porque en el momento en que se ponen sobre la mesa las diferentes visiones o perspectivas saldrán a relucir las características sobre las que existe prácticamente un consenso sin prácticamente entrar a discutirlas y otras que darán lugar a un arduo debate y que permitirán extraer un aprendizaje muy valioso, ya que confrontar tus ideas con la de otros, reflexionar sobre ello y exponer tus argumentos, permitirá que determinadas características se descarten o se consideren como parte de una futura línea de evolución del producto.

Es decir, permitirá establecer un alcance inicial, una delimitación de lo que se pretende que sea el producto, fruto de esa alineación de opiniones y también unas expectativas que no son fruto de la improvisación, sino de la confrontación de conocimientos, experiencias y necesidades de diferentes personas.

Para que las conclusiones obtenidas sean válidas, no debe haber medias tintas, es decir, cada cual debe expresar su opinión, todo lo que se guarde o edulcore excesivamente terminará saliendo en momentos posteriores, afectando al proyecto, que ha sido concebido, no lo olvidemos, sobre las bases de Inception.

Es cierto que después tocará perfilar y realizar ajustes (será necesario adaptarnos al cambio) pero de entrada se parte con una visión, ¿cuántas veces se inicia un proyecto con mucho menos que eso?, ¿cuántas veces se inicia un proyecto con una visión de máximos en lugar de con una visión más realista y objetiva?.

Pero, ¿se reduce incertidumbre con el Inception?, no puedo responderos afirmativa o negativamente de manera categórica porque el nivel de incertidumbre que rodea a todo proyecto de desarrollo de software (o a cualquier proyecto en general) es tan importante que se trata de ver si este trozo que quitamos a la misma resulta significativo o no.

Lo que sí es evidente es que el simple ejercicio de tomarse en serio una actividad como esta y de que un grupo de personas reflexionen, expongan sus opiniones y se enfrenten a otras que pueden ser diferentes y a problemas o perspectivas en los que no habían pensado o no habían tenido en cuenta, permite quitar algo de niebla al paisaje y a aproximar algo más a la realidad ese conjunto de visiones abstractas.

¿En cuántos proyectos hemos participado en los que nos hemos dado cuenta, unas veces antes y otras después, que determinados conflictos y cambios de rumbo sensibles en la línea de desarrollo del producto han sido provocados porque las personas encargadas de definirla han tenido un mal entendido, de manera que pensaban que hablaban de los mismo cuando en realidad las perspectivas que tenían eran diferentes?.

¿En cuántos proyectos hemos participado en los que se han elegido de manera incorrecta las prioridades?.

¿En cuántos proyectos hemos participado en los que el alcance y el coste no tenían nada que ver?.

¿En cuántos proyectos hemos participado que nunca se deberían haber iniciado, por ejemplo, por existir problemas organizativos que se trasladan después al software?.

¿En cuántos proyectos hemos participado que nunca se deberían haber iniciado por no existir unos responsables funcionales o product owners que asuman con responsabilidad su trabajo?.

Pues precisamente entre otros aspectos, Inception trata de sacar esos problemas a la superficie antes de que se haya dado algún paso significativo en el proyecto.

En esta serie de artículos trataremos Inception desde la perspectiva de una actividad a realizar al inicio del proyecto, en el momento de su concepción.

Desde esa visión podemos definir Inception como una serie de actividades que se realizarían en la etapa de constitución o definición del proyecto (las analizaré más adelante y se deberá tener en cuenta que son herramientas y, como tales, podemos utilizarlas todas, adaptarlas o quedarnos con aquellas que nos resulten más interesantes) y que tienen como objetivo alinear las posturas de las diferentes personas, equipos y departamentos implicados, de manera que se consensúe un marco, que estará formado, entre otros elementos, por el producto que se cree que se quiere (en esta fase tan temprana, me resulta complicado quitar el “cree que”), el cómo se pretende a llegar a él desde la situación de partida, quiénes van a participar de alguna u otra manera en su desarrollo, cuáles son los riesgos que se prevén que nos podemos encontrar, cuál será el coste aproximado y cuándo estaría disponible.

Es fundamental que los implicados sean conscientes del nivel de incertidumbre con el que nos encontramos en este momento inicial del proyecto (de hecho llegar a esa conclusión sería un síntoma de que el Inception se ha realizado adecuadamente) porque de lo contrario determinadas conclusiones que se tomen pueden dar lugar a malos entendidos futuros, es decir, si se piensa que ese marco es inamovible, empezaremos a encontrarnos problemas en el momento en que sea necesario realizar ajustes, algo que ocurrirá más pronto que tarde.

Cuando comenzamos con el estudio de diversas estrategias, enfoques y prácticas ágiles, se describe un marco de actuación que sabemos encajar bien cuando cuando un proyecto se encuentra en marcha pero si no hemos trabajado previamente con ellas o si no lo hemos hecho desde el inicio del mismo, se suele generar la duda sobre qué actividades se realizan antes de comenzar a ejecutar el primer sprint. De hecho mucha bibliografía sobre la materia no lo termina de aclarar.

En un artículo denominado: “Preparando el primer sprint” os expresé mi punto de vista sobre esas actividades, si bien no tuve en cuenta otra, que debería ser anterior a ellas y que incluso puede influir en su enfoque y es la que se denomina Inception.

De hecho, ya veréis conforme vayamos repasando sus propias actividades, que esta práctica perfectamente podría ser aplicable a proyectos que ya estén iniciados, con el objeto de hacer una breve parada, una breve reflexión que nos ayude no solo a priorizar o descartar determinadas líneas de evolución, sino también para analizar si efectivamente los pasos dados van en la dirección adecuada.

No debe confundirse con las retrospectivas, que si pueden compartir algún elemento en común, están orientadas, sobre todo a la mejora continua de los trabajos, la colaboración entre las personas y el producto y se realizan, por regla general, con una periodicidad similar a la de los sprints.

El prototipado, el cartón piedra, el mockup en definitiva, es una herramienta muy poderosa. En el desarrollo de software existe desde tiempos inmemoriales y, desde mi punto de vista, no se le da la importancia que se merece.

Parece que resulta más interesante trasladar requisitos, especificaciones o historias de usuario al lenguaje natural que tener testimonios gráficos de lo que se desea obtener.

Y no solo se trata de tener los requisitos acompañados por un prototipo, lo realmente interesante es que el desarrollador lo explique al responsable funcional, product owner o usuarios implicados, de esta forma se puede comprobar, en primera instancia, que el desarrollador ha entendido el comportamiento y en segunda instancia permite ofrecer una perspectiva menos abstracta de la solución a las personas que deben definirla, algo que agradecerán y agradareceremos porque se conseguirá obtener una descripción más real de lo que se pretende obtener, gracias a esa colaboración que se consigue a través de un instrumento intermedio que las diferentes partes entienden.

No se trata de acertar a la primera, algo que sabemos que es complicado, con y sin estas técnicas, sino de tratar que el desarrollo tenga la mayor intención posible, es decir, que nos ahorremos iteraciones que podían haber sido evitadas.