NPS (Net Promoter Score) es un indicador para medir la satisfacción de los clientes, y también podemos comprobar si los clientes están satisfechos hasta el punto de recomendar nuestros productos o servicios a sus amigos y allegados.

Fue elaborado por un estudiante de Harward,Fred Reichheld en el año 1993, mientras estaba trabajando para la consultoría Bain & Company. Después de probar varios tipos de cuestionarios en su trabajo, Reichheld observó que de las preguntas utilizadas, la que mayor correlación establecía con la compra de productos eran las recomendaciones que hacían los clientes de estos. De este modo, esta pregunta sobre la recomendación del producto o servicio se ha convertido en la base del NPS. Posteriormente, en 2006 Fred Reichheld publicó su libro, The Ultimate Question, con Rob Marke, generando gran aceptación y comenzando a usarse por multitud de empresas.

Para medir la lealtad de los clientes, NPS formula una única pregunta: "¿Qué probabilidades hay de que recomienden nuestro producto a un amigo?" Tras plantearles esta pregunta, le pedimos a los clientes que la respondan a partir de un parámetro del 0 al 10, cuyos resultados son categorizados posteriormente por el sistema NPS en detractores (0-6), pasivos (7-8) y promotores (9-10).

El NPS nos permite determinar cómo de contentos o descontentos están nuestros clientes y así poder adaptar nuestra estrategia empresarial hacia ciertos ámbitos y comparar continuamente nuestra empresa con nuestras competidoras, ya que una de las grandes ventajas del indicador es que ya es usado por muchas compañías que publican continuamente sus informes y con cuyos datos podemos compararnos. De este modo, con un buen enfoque, equipo y software adecuados pueden conseguirse grandes resultados que podrán repercutir en la estrategia futura y el crecimiento de la compañía.

Diaspora es una red social descentralizada basada en software libre. El proyecto inició en el año 2010 y sus fundadores son cuatro estudiantes del Instituto Courant de Ciencias Matemáticas, de la Universidad de Nueva York: Ilya Zhitomirskiy, Daniel Grippi, Maxwell Salzberg y Raphael Sofaer.

Al ser una red descentralizada, como el e-mail, Jabber/XMPP o Pump.io, no hay una empresa o entidad concreta dando el servicio a todo el mundo, sino que existe diversidad de servidores, todos interconectados entre sí. Al ser diversos los servidores si uno tiene problemas no afecta a todos. Un usuario puede crearse una cuenta en cualquier servidor de Diaspora, e interactuar con sus contactos independientemente de donde estos tengan sus cuentas.

Es decir, Diaspora no es propiedad de ninguna persona o entidad, manteniéndose así libre de adquisiciones corporativas, publicidad, y otras amenazas. En este sentido Dan Grippi expresó: “…nuestro diseño distribuido significa que ninguna gran corporación controlará jamás a Diaspora. Diaspora nunca venderá tu vida social a los anunciantes, y nunca tendrás que ajustarte a las reglas arbitrarias de alguien más, o mirar por encima del hombro antes de hablar”.

En las redes convencionales uno debe pensar previamente qué contenido compartir ¿Afecta a mi trabajo? ¿Mi relación con mi familia? ¿Con amigos? ¿Quiero que mi mensaje llegue a todos? ¿Quiero que sepan todos los aspectos de mi vida?

En eso pensaron los creadores al definir la forma de agrupar a los contactos en “aspectos”. Permite agrupar en “trabajo”, “familiar”, esto implica que tanto a la hora de leer como de publicar se selecciona el aspecto adecuado, de manera que solo leeremos a la gente en dicho aspecto, y si publicamos algo, solo será visto por gente en dicho aspecto. También se pueden manejar varios aspectos al mismo tiempo.

Al igual que GNU Social o Twitter podemos seguir los #tags de los temas que nos despiertan curiosidad y también podemos añadirlos a nuestras publicaciones para llegar a usuarios que busquen esa información y que no nos siguen a nosotros.

A la hora de publicar, es posible utilizar texto con formato e imágenes, para crear textos elaborados, utilizando los sencillos códigos Markdown. También se pueden incrustar vídeos y audio tan solo pegando la dirección.

Esto es posible usarlo también en los mensajes privados, así como en el campo “Biografía” del perfil, donde se puede detallar todo tipo de datos usando diferentes fuentes e insertando imágenes, para crear un perfil sin restricciones.

Esta red social basada en software libre busca proteger la libertad de los usuarios, brindarles mayores posibilidades de privacidad y de diseño ¡Una vez más el software libre nos da libertad!

¿La probaron? ¡Escuchamos sus experiencias!

En Bitson buscamos una herramienta que nos permita medir las horas de trabajo. Esto nos da la posibilidad de medir cuánto tiempo nos lleva un desarrollo y de aquí sacamos el valor del producto terminado (calculamos las horas invertidas) y también saber cómo va mejorando nuestro tiempo invertido. En nuestro caso también nos permite calcular el retiro (nuestro sueldo).

En esa búsqueda encontramos Kimai. una aplicación web gratuita y de fuente abierta para medir el tiempo. Una de las principales características de Kimai es la posibilidad de acceder a su interfaz web, iniciar el cronómetro de una tarea y salir posteriormente de la aplicación. Kimai sigue contabilizando el tiempo internamente hasta que volvamos a acceder y detengamos de nuevo la cuenta.

Kimai es un script, de código abierto y gratuito, que podemos instalarnos en un servidor local o en la web, en el que podemos gestionar el tiempo que pasamos en un determinado proyecto e imprimir los resultados según nuestra demanda, ya sea por fechas, por trabajos o por clientes.

Desde su web nos indica que es necesario un servidor con soporte php y mysql, configurar los datos en /includes/conf.php y se nos generará las tablas en nuestra base de datos de forma automática una vez entremos desde nuestro navegador. Según anuncian en su web, es que no funciona con Internet Explorer, aunque funciona con Firefox y Safari. ¿Pero quién usa Internet Explorer?

La función más importante que destacamos es la posibilidad de descargar reportes. De esta manera podemos medir y analizar qué es mejor para nosotros y cómo invertir nuestro tiempo de manera correcta.

El servicio se encuentra disponible en más de 15 idiomas. Entre esos se encuentra inglés, alemán, español, italiano, entre otros.

También permite la versión demo. Donde podes tener una primera impresión sobre el software y qué funcionalidad proporciona.

A nosotros nos resulta muy útil y lo recomendamos.

Como ya les contamos en Bitson estamos en una búsqueda por mejorar nuestra organización interna para mejorar nuestra eficiencia como equipo y nuestra relación con el cliente y sus requerimientos.

Primero tuvimos que definir qué técnica usar para la gestión de proyectos y establecimos utilizar tableros siguiendo la idea de Kanban (link a kanban). Una vez resuelto eso analizamos qué herramientas usar y cuál es la mejor para nuestro caso.

Determinamos nuestras necesidades. Lo más importante era encontrar una herramienta que permita la gestión de proyectos tanto de forma individual para incrementar la productividad personal y por otro lado coordinar proyectos entre todos los socios tanto para los que están en la oficina como para los que estamos lejos.

Buscamos todas las herramientas de Project Management y fuimos descartando en nuestros casos las que no nos servían. Por eso es importante definir qué queremos y qué es útil y práctico para todos los miembros del equipo.

Probamos Bitrix24 pero no nos convenció. La UI muy saturada y poco clara. De las Open Source probamos OrangeScrum. La UI un poco rebuscada y con fallas. Y Open Project no me permitía evaluar el conjunto de proyectos. Por eso ganó Freedcamp y hasta ahora los resultados son positivos.

Freedcamp permite agrupar a todos los proyectos creados de manera más conveniente y poner una descripción que sirva para que todos los involucrados sepan de qué se trata el proyecto.

La opción “manage projects” (gestión de proyectos) permite añadir o quitar miembros del proyecto. Hay tres opciones disponibles de usuario: administrador, usuario y cliente. Este último es muy útil cuando trabajas con diversos clientes. Ya que esta herramienta les puede servir para gestionar las tareas de cada proyecto de forma más transparente y con una comunicación más efectiva.

También permite añadir aplicaciones a cada proyecto dependiendo de las necesidades de gestión. La gran mayoría son gratuitas aunque también hay algunas pagas. Igualmente el costo es accesible, y cuenta con 7 días de test. Algunas de estas aplicaciones pueden ser “To do’s”, “Discussions” (para registrar las conversaciones y guardar así el histórico en la herramienta), “Milestones” (o hitos del proyecto), “Calendar” (con sincronización con Google Calendar) , entre otras.

Dentro de las características destacamos las que más usamos en nuestro caso.

• Últimos cambios: podemos visualizar los cambios realizados por nosotros mismo o por algún otro socio.

• To do list: escribimos las tareas que nos faltan para terminar los proyectos, añadimos una etiqueta de prioridad, y comentamos las de otros compañeros.

• Gestor de documentos online: compartimos entre los socios los archivos más importantes o ponemos en común la última versión

• Foro de discusión: debatimos las nuevas ideas, analizamos las ventajas y desventajas, encontramos soluciones y todo queda registrado.

• Gestor de tiempo: se puede escribir cuánto tiempo se ha tardado en realizar una tarea o poner el reloj en marcha. Es decir, cuando empieces a trabajar en una tarea específica dentro del proyecto pones en marcha el contador, y él se encargará de gestionar el tiempo que llevas trabajando.

• Calendario, especialmente diseñado para destacar las fechas de entrega de los proyectos, puesto que siempre aparecerá en la parte derecha de la interfaz de Freedcamp recordando el evento.

¡Recomendamos Freedcamp porque es sencillo, con una interfaz gráfica muy buena y gratis!

¿Vos usas alguna otra herramienta? ¡Contanos en nuestros canalaes cuál y cómo fue tu experiencia!

Empezamos a utilizar Kanban hace ya seis meses y los resultados han sido muy positivos. Es un método que mejora la organización de la Cooperativa y es realmente fácil de aplicar a las necesidades diarias.

El método Kanban, perfeccionado y ampliado por David J. Anderson es una alternativa muy popular para comenzar en la agilidad organizacional. En este artículo se describen sus elementos más importantes y cómo empezar a usarlo

Kanban es una palabra japonesa que viene a significar cartel o panel, elemento clave de este método productivo. El sistema Kanban como tal surgió en Toyota, el fabricante japonés de automóviles, para organizar mejor su producción de vehículos dividiendo el proceso en fases bien delimitadas que se tenían que cubrir correctamente para pasar a la siguiente fase, garantizando así un producto de calidad.

Luego este método ha sido ampliado por David J. Anderson, quien adaptó esta filosofía al desarrollo de software. Quienes estamos en este rubro sabemos que hay muchos puntos en común con el desarrollo industrial. Es decir, diferentes fases, equipos de trabajo y el requisito de que cada pieza del programa a crear funcione correctamente y sea de la mejor calidad posible.

Esta versión moderna fue utilizada por primera vez en Microsoft, y desde entonces se aplicó a cientos de proyectos en todo el mundo ¡Y finalmente nos tocó a nosotros como organización! Por esto te contamos nuestra experiencia.

El método Kanban recomienda usar un panel con tarjetas (que dan nombre al método) que definan cada tarea dividiéndola en columnas que indican cada fase del proyecto.

Lo primero que necesitamos es un sitio físico en donde poder visualizar el trabajo. En nuestro caso utilizamos una pizarra porque es lo más práctico para corregir y para que quede a la vista de todos los socios. Igualmente hay varios programas que recomendamos como Taiga, Wekan, Freedcamp.

Una vez resuelto esto es importante destacar las fases del trabajo pero no hay que limitarnos solamente a una sección de “En progreso” sino también detallar todo lo que nos pueda servir para el desarrollo de nuestro producto o servicio. Identificar las otras fases nos ayuda a entender mejor el proceso y a identificar posibles problemas que surjan en esta fase.

A medida que avanzamos nos surgió la inquietud de quién podría cambiar el ítem de un estado al otro ¿Todos podemos hacerlo? ¿Tenemos que estar presentes? ¿Elegimos a un responsable? Esas respuestas las fuimos respondiendo con la práctica. Para algunos items tenemos un referente, y otros tienen mayor libertad para todos los socios. Es importante determinar quién hace qué para que todos los socios determinen su trabajo y entiendan las reglas o especificaciones de cada caso.

Es importante también identificar cada item y darle prioridad a los que así se determine. Las clases de servicio tienen características explícitas. Normalmente su urgencia se mide por el coste de retraso. Por ejemplo, en el caso de una fecha de entrega que si se retrasa puede costar dinero a la compañía, se utiliza una política distinta de si es una tarea mecánica que aporta poco valor a la organización.

Descubrimos también que hay que limitar el trabajo en curso. Hacer muchas cosas a medias no sirve y la utilización del tablero nos sirve para visualizar si la tarea se ha terminado completamente. Este es uno de los pilares para un proyecto.

Kanban no sólo mejoró la organización sino también el trabajo en equipo. La mejora debe ser acordada en equipo, al igual que la organización de los tableros y las tareas ¡Les recomendamos su utilización!

SCRUM ¿Cómo aplicarlo?

Ya conocemos qué es Scrum pero ahora falta profundizar sobre qué fases tiene esta metodología.

En Scrum un proyecto se ejecuta en ciclos temporales cortos y de duración fija (sprint -iteraciones- que normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback de producto real y reflexión). Cada sprint tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

Dentro de cada sprint tenemos las siguientes etapas.

• Planificación del sprint: duración, objetivo y cómo realizarlo.

• Scrum diario. Se basa en poner en común y sincronizar actividades para elaborar el plan del día. Trabajo de desarrollo durante el sprint. Nos aseguramos que los objetivos se están cumpliendo, que no se producen cambios que alteran el objetivo del sprint y se mantiene un feedback constante con el cliente o dueño del proyecto.

• Revisión del sprint. Reunión con el cliente o dueño del proyecto, en la que se estudia y revisa el Product Backlog del sprint. Se definen los aspectos a cambiar, en caso necesario, de mayor valor o probables para planificarlo en el siguiente Sprint.

• Retrospectiva del proyecto. Oportunidad del equipo de desarrollo para mejorar su proceso de trabajo y aplicar los cambios en los siguientes sprints.

Utilizar esta metodología también significa definir roles y responsabilidades para los implicados. Son los siguientes:

Project Owner:

Se asegura de que el proyecto se esté desarrollando acorde con la estrategia del negocio. Escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

Srcum Master:

Elimina los obstáculos que impiden que el equipo cumpla con su objetivo. Su misión es que los equipos de trabajo alcancen sus objetivos hasta llegar a la fase de “sprint final”, eliminando cualquier dificultad que puedan encontrar en el camino.

Equipo:

Los encargados de crear el producto para que pueda estar listo con los requerimientos necesarios.

Historias de usuarios

Hace más de un año comenzamos el camino de utilizar metodologías ágiles. El cambio significó modificar nuestra forma de trabajar e incluso nuestra cultura pero sabíamos que era el camino correcto en pos de buscar la eficiencia en nuestro trabajo.

Trabajar con Scrum nos hizo conocer las “historias de usuarios”, las cuales se enfocan en definir lo que el usuario necesita hacer, sin describir el cómo, por lo que representa el inicio y no el final de las conversaciones. De esta manera dejamos atrás la forma menos práctica de levantar los requerimientos de los usuarios mediante documentación detallada que sólo representa el final de las conversaciones.

Utilizando esta metodología se establece que el encargado de elaborar los elementos del Product Backlog es el Product Owner. Pero el Scrum Master Sin embargo, el Scrum Master tiene la misión de colaborar con el equipo Scrum para que el Product Backlog sea claro. En nuestro caso utilizamos la historia de usuarios con la base de una plantilla preestablecida (¡Descargala!)

Si usamos correctamente esta plantilla logramos tener un enunciado que nos ayudará a identificar los requerimientos de los usuarios ¡Tendremos el qué pero faltará el cómo! La frase quedará de la siguiente forma: Yo como un [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de la consecuencia].

Estos son lo elementos de la plantilla que utilizamos para crear el enunciado.

• Identificador (ID) de la historia: Código que identifica unívocamente a la historia en el Proyecto que se esté desarrollando. El formato debe ser elegido por el equipo. esto es para una mejor clasificación
• Rol: Es el rol que está desempeñando el usuario cuando utiliza la funcionalidad que se está describiendo. Debe ser lo más específico posible. Por ejemplo:
  • Yo como cliente registrado.
  • Desempeñando el rol de cliente registrado.
  • Como un cliente registrado.
• Funcionalidad: Representa la función que el rol quiere o necesita hacer en el sistema que se está desarrollando. Se puede diferenciar las acciones obligatorias de las opcionales utilizando las palabras puedo o necesito. Por ejemplo:
  • Necesito realizar búsquedas de productos por categorías.
  • Puedo seleccionar una categoría para ver el número de productos que tiene asociado.
• Razón / Resultados: Lo que el rol necesita lograr al ejecutar la acción. Este es el resultado de ejecutar la acción desde el punto de vista del rol. Este punto puede ser opcional, pues la historia puede documentarse sólo con la definición del rol y la acción (sin definir la consecuencia).

Orígenes del Scrum

Primero lo primero ¿De dónde viene el término Scrum? Ikujiro Nonaka e Hirotaka Takeuchi publicaron en 1986 en la Harvard Business Review el artículo: “El nuevo nuevo juego para el desarrollo de productos”. Allí definieron el término Scrum basado en el avance de las formaciones en partidos de rugby. Pero la modalidad de trabajo ya existía en empresas tecnológicas como Hondo, Canon y Fuji-Xerox. Con los años fue evolucionando y se ha extendido a muchos sectores no sólo el tecnológico.

Takeuchi And Nonoka explicaron lo siguiente: “el enfoque de “carrera de relevos” para el desarrollo de productos entra en conflicto con el objetivo de obtener la máxima velocidad y flexibilidad. En su lugar un enfoque como el rugby – donde el equipo intenta avanzar como equipo, enviando el balón hacia atrás y luego avanzar – sirve mejor a los desarrollos competitivos que se ven hoy en día”. Por eso Scrum y equipo auto organizado van siempre de la mano ¡Cooperativa y autogestión son sinónimos así que en nuestro caso para a utilizar esta metodología es muy enriquecedor.

Esta metodología implica realizar entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. s, donde se necesita obtener resultados pronto, donde los requisito. En la actualidad, los proyectos se desarrollan en contextos muy versátiles. Son más complejos que antes, frente a unas exigencias del cliente y del mercado mucho más variables, y con una incertidumbre elevada. Por eso, la aplicación del método Scrum se ha extendido como la pólvora en numerosos sectores, fuera del mundo del desarrollo de software. Por este motivo nosotros utilizamos y se recomienda para proyectos en entornos complejo.

Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema.

¡Una gran metodología para implementar camino a la eficiencia!

¿Por qué decidí formar parte de una cooperativa?

Soy Maria Alejandra Cuervo, tengo 24 años, soy Colombiana y vivo en Buenos Aires hace 7 años. En este momento me encuentro cerca de culminar mi carrera en Analista de Sistemas. Quiero contarles por qué tomé la decisión de formar parte de Bitson

La idea de trabajo que la mayoría de nosotrxs tiene es muy similar; realizamos tareas por las que recibimos un pago a cambio, todo en pos de cumplir con los objetivos que nos marca nuestrx jefe, o en el mejor de los casos, cumpliendo objetivos marcados por nosotrxs mismos. Por lo menos de esa manera lo percibía hasta hace unos meses atrás. Es común encontrarnos en la zona de confort, donde estamos cómodos desempeñando nuestras labores diarias como empleadxs pero qué pasa si tenemos la oportunidad de salir de nuestra zona de confort. Por mi parte se resume a sentir miedo, ansiedad, y rodeada de una montaña de preguntas ¿Es para mi? ¿Es lo que realmente quiero? ¿Me permito decir que no? ¿Es un riesgo?.

Ya que Bitson es una cooperativa de trabajo que se encarga del desarrollo de software y hardware a medida, y va de la mano con todo lo que aprendí en mi carrera, era más que un reto poder insertarme en el rubro de la informática desde el lado del cooperativismo, una oportunidad que tenía que aprovechar para poder poner en práctica los conocimientos adquiridos y desafiarme.

Formar parte de una cooperativa nunca estuvo en mis objetivos a corto plazo, por lo que, recibir la propuesta para formar parte de una , fue una invitación que claramente me sacó del molde y acepte aun cuando no estaba enterada de cómo funcionaba. Mis primeros meses fueron de aprendizaje continuo. En una cooperativa de trabajo no existe jerarquía dada su horizontalidad, por lo tanto todos sus integrantes tienen derecho de entre otras cosas a opinar, debatir, aportar y planificar. Esto hace parte del día a día de una cooperativa, terreno que empezaba a gustarme.

Tomar decisiones que afecten a todo el equipo, solidaridad, humanidad, pro actividad, todas cosas que estaban lejos de ser un campo que conociera pero que me generaba tanto interés. Me arriesgue y me adapté, un nuevo desafío: complementar al equipo, ayudar, cooperar, aportar, planificar, debatir, consensuar, reconfortar, acompañar. Por estas y otras tantas cosas más elegí ser parte de Bitson. Elegí ver a Bitson crecer de la mano de cada uno de mis socixs que da todo para que nos consolidemos como un grupo de trabajo fuerte y coordinado.

¿Por qué emplear la técnica de Entrega Continua?

La técnica de Entrega Continua (CD) trae como consecuencia mayor velocidad y menor complejidad en el proceso de desarrollo de software. A su vez, permite lanzamientos mucho más seguidos, proporcionando retroalimentación inmediata.

Implementar este proceso suele ser difícil para las organizaciones esto se debe principalmente a que no es un cambio en el proyecto tecnológico sino un cambio organizacional.

La entrega continua automatiza todo el proceso de publicación de software. Cada revisión efectuada activa un proceso automatizado que crea, prueba y almacena la actualización. Las pruebas pueden incluir pruebas de la UI, de carga, de integración, de fiabilidad de la API, etc. De este modo, los desarrolladores pueden validar las actualizaciones de forma más exhaustiva y descubrir problemas por anticipado. Con la nube, resulta sencillo y rentable automatizar la creación y replicación de varios entornos de pruebas, algo que anteriormente era complicado en las instalaciones. La decisión definitiva de implementarla en un entorno de producción en vivo la toma el desarrollador.

Cuando se la entrega continua se implementa de manera adecuada, los desarrolladores dispondrán siempre de un artefacto listo para su implementación que se ha sometido a un proceso de pruebas estandarizado. Esto significa mayor autonomía para el desarrollado.

Con la entrega continua, todos los cambios en el código se crean, se prueban y se envían a un entorno de almacenamiento o pruebas de no producción. Pueden efectuarse varias pruebas al mismo tiempo antes de la implementación en producción. La diferencia entre la entrega continua y la implementación continua es la diferencia de aprobación manual para actualizar la producción. Con la implementación continua, la producción tiene lugar de manera automática, sin aprobación explícita.