Actividad #10 – SCRUM

En base a la dinámica realizada en la clase #3:

Identificar en un proyecto actual cuales son los diferentes usuarios (o tipos de usuarios), cuanto porcentaje de tiempo del equipo se les está dedicando a cada uno y el nivel de felicidad que estima que tiene.

Como podría mejorar la planificación de ese proyecto para balancear la felicidad de usuarios y como para aumentar el valor de negocio?

Se te ocurren nuevas reglas o condiciones que podrían mejorar la dinámica en base a tu experiencia con la actividad y con la realidad laboral? Por qué sería una mejora?

Anuncios
Acerca de

Soy uno de los siete fundadores de FDV Solutions. Como CEO de la compañía, ejecuto la estrategia general de FDV Solutions y la supervisión de las distintas áreas de negocios y gerentes que me reportan: Ventas y Marketing, Operaciones, Administración y Finanzas, y Recursos Humanos. Además tengo un rol activo en las distintas acciones institucionales de la empresa, siendo representante de la misma en diversas cámaras e instituciones, como la Cámara de Empresas de Software y Servicios Informáticos de Argentina (CESSI). Soy graduado en la Carrera de Ingeniería en Informática, y cuento además, con un posgrado en comercialización para ingenieros del Instituto tecnológico de Buenos Aires (ITBA). Actualmente estoy finalizando un máster en Ciencias Cognitivas de la Universidad de Buenos Aires y soy docente universitario en dicha casa de estudios. Soy también Fundador de Proyecto Nahual (www.nahual.com.ar), una iniciativa que busca la inclusión social y la inserción laboral a partir de la capacitación tecnológica en programación y testing de software. Participo además activamente de la Comisión de Inclusión de CESSI.

Publicado en Sin categoría
4 comments on “Actividad #10 – SCRUM
  1. La empresa en la que trabajo actualmente se dedica a desarrollar un marketplace, y, además de los dos tipos de cliente que componen el mismo (proveedor, que son restaurantes, y cliente, que son usuarios que realizan reservas), se hacen los desarrollos internos para dar soporte a los procesos de las diferentes áreas.

    (Los porcentajes son completamente subjetivos, ya que en el área de desarrollo somos 4, y cómo se ve, hay más clientes que personas desarrollando)

    Nuestros clientes como área de IT serían:

    Usuarios del sitio, 30%
    Restaurantes, 20%
    Marketing, 15%
    SAC (Servicio de Atención al Cliente), 10%
    Ventas, 10%
    IT, 10% (Tiempo que se dedica en cosas internas o en A/B testing de features no contemplados)
    Cobros, 5%

    Estimar la felicidad de los usuarios del sitio es muy dificil. Es bueno saber que la cantidad de usuarios activos crece, aunque también sabemos que hay mucho de su experiencia de uso que se puede mejorar pero que para detectar y aprender no hay otra manera que haciendo A/B testing.

    Los restaurantes hay una gama muy amplia que va del amor al odio. Hay algunos que les sirven las herramientas que les construimos y las usan, otros con requerimientos muy particulares que nunca se llegan a implementar por lo chico del equipo de desarrollo.

    El área de marketing debería ser el más feliz de todos, pero, siempre quiere más, más y más rápido.

    El equipo de SAC y el de ventas suelen trasladar la felicidad/enojo de los dos primeros (usuarios y restaurantes), y no se preocupan tanto por las herramientas que se les puede dar a su proceso. Cada tanto cuándo se desarrolla algo que realmente les facilita su trabajo su nivel de felicidad sube, pero en general no se preocupan mucho por ellos mismos si no por los otros usuarios.

    Nuestro nivel de felicidad con nuestro trabajo para nosotros es medio (que se encuentra sesgado porque sabemos todo lo que trabaja el equipo). Se postergan algunas tareas como integrar los tests con un CI server, mejorar el manejo automático de infraestructura, etc. Pero al menos cada tanto se pueden hacer sin recibir quejas de que estamos perdiendo el tiempo.

    El encargado de cobros se encuentra en un momento de felicidad suprema porque comenzaron las pruebas para reemplazar el armado manual de las facturas por uno automático. De todas maneras, normalmente, está bastante feliz con el área de desarrollo.

    Se encuentra bastante balanceado por ser un equipo tan chico. Para mejorar, hace falta agrandar el equipo (algo que actualmente estamos intentando hacer), y posiblemente designar dentro del equipo tres personas que hagan foco en cada una en los tres tipos de usuarios, es decir, uno con foco en cada tipo de cliente externo (restaurante y usuario), y otro en todo lo que sea proceso interno de la compañía.

    Para la dinámica, me parece que los clientes deberían cruzarse de equipo y tener como objetivo traer sus puntos de felicidad al equipo original (es decir, con tres equipos cada equipo recibiría clientes de los otros 2 equipos).

  2. Ayelen Tamiozzo dice:

    En la empresa en la que trabajo es algo complejo y a la vez sencillo (aunq suene bastante contradictorio) estimar la felicidad de nuestros clientes.
    Nos dedicamos a herramientas internas para la recoleccion de datos financieros. Nuestros clientes son distintos equipos de recoleccion, es decir, tenemos teams que se dedican a cargar informacion de firmas, otros de fondos, etc.

    Para decidir entre que proyectos hacer, se tiene en cuenta el tiempo que se gana en lso proceso de recoleccion de informacion. Es decir, si se tiene un proyecto que mejoraria el tiempo de cargar data de un fondo, se estima cuantas veces se hace esa activadad por mes y cuanto tiempo se ganaría. En estas estimaciones participan proyectos de todos los equipos de recoleccion y “compiten” entre ellos para ver que proyectos se implementan en cada ciclo.

    Por lo detallado previamente, se puede ver que ver la conformidad de los clientes es una métrica bastante sencilla (la mejora en tiempo de los procesos de recoleccion).
    Sin embargo, realizar una actividad similar a la propuesta se vovlería algo realmetne complicado (y no se hasta que punto util) dada esta caracteristica.

  3. Alejandra Stamato dice:

    Donde trabajo desarrollamos mayormente para clientes internos (software de backoffice mayormente), y algunos desarrollos para clientes externos.

    Tenemos distintas tareas que atienden cuestiones solicitadas por los clientes internos.
    Sin embargo a veces nos caen requerimientos extraordinarios y en rigor, podríamos elegir uno de dos caminos: atenderlos inmediatamente o abrir tickets.
    Tratamos de mantener un balance en la cantidad de atención que le brindamos a cada uno de los clientes: la felicidad reside, por ejemplo, en que los bug fixes inmediatos los atendemos lo antes posible, mientras nos ocupamos de desarrollos particulares (solicitudes de nueva funcionalidad, automatizaciones), y nos aseguramos de que los clientes estén conformes con los arreglos.
    En nuestro caso es imperativo mantener a nuestros clientes contentos, porque entre todos movemos el negocio.

    La dinámica realizada en la clase #3 me resultó muy amena, y a su vez me gustó que se le de énfasis en la felicidad de los clientes. Es algo que no es menor, debemos poder gestionar e identificar qué clientes atender, cuándo, cómo.

    Una de las mejores que podría introducirse a la dinámica es que realmente los miembros del juego se pongan en el papel de product owner, como abogado del cliente. Realizar un intercambio de jugadores entre equipos, dos PO del equipo A van al equipo B y viceversa. Si en el equipo B logra aumentar puntos de felicidad de los PO del equipo A, el equipo B sumarán puntos tanto A como B. En cada iteración rotan dos nuevos clientes.

    También estaría bueno que los “criterios de aceptación” de las cards empiecen mucho antes en las iteraciones.

  4. Rodolfo Cruz dice:

    En mi trabajo integro un grupo cuya tarea es desarrollar el backend de un sistema que corre en varias plataformas. Como tal, nuestros “clientes” son equipos internos a la empresa a los que les proveemos APIs para que puedan integrarse con nuestro código.

    Considero que en general el nivel de felicidad del resto de los equipos es alto ya que tratamos de cumplir sus requerimientos para cuando estos los necesitan. Para ello creo que es fundamental el hecho de tener reuniones semanales a los que acuden representantes de todos los grupos y en el cual se discuten que cosas se necesitan y con cuanta urgencia (no es lo mismo un pedido sobre algo que esta bloqueando a todo un equipo que uno que es una mejora a futuro) y en base a eso se acuerda entre todos a que se le dará prioridad. De esta forma se evitan malos entendidos ya que la priorización es discutida y consensuada entre todas las partes.

    Respecto a la dinámica, ademas de las sugerencias mencionadas de brindar mas preponderancia al papel del cliente, podría introducirse alguna carta o similar que represente el “manejo de expectativas”, algo muy importante en la vida real. Así, si los participantes del juego saben que no podrán brindarle una entrega a un determinado cliente en un plazo inmediato podrían utilizar este recurso para evitar una disminución en la felicidad del mismo durante un par de iteraciones, penalizándoselos con una quita importante de puntos de felicidad si al terminar el plazo no se le ha hecho ninguna entrega, lo que representaría una perdida de confianza del cliente en la labor del grupo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: