Definir un ámbito factible para su proyecto pro bono

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

• Aplicar las mejores prácticas para implicar a su organización
• Documentar los requisitos mediante historias de usuario
• Definir un ámbito del trabajo razonable

Cómo definir un ámbito para el éxito

Para aplicar sus superpoderes pro bono con eficacia, deberá aprender a aplicar correctamente un ámbito a sus proyectos. Pero ¿qué significa eso exactamente? Dicho en pocas palabras, la aplicación de un ámbito a un proyecto es el proceso de comprender lo que desea conseguir una organización y acordar lo que puede conseguirse (y lo que no) con los recursos y plazos disponibles.

Desde que Salesforce.org lanzó su programa Pro Bono en 2014, miles de empleados de Salesforce completaron exitosamente proyectos pro bono con instituciones sin fines de lucro y educacionales. Un impresionante 82% de esas organizaciones afirma que, como resultado, son más eficientes en su gestión de Salesforce y en el cumplimiento de sus objetivos. La forma en que los voluntarios pro bono de Salesforce definen el ámbito de los proyectos es un impulsor clave del éxito del programa, y estamos encantados de compartir nuestras mejores prácticas con usted.

La mentalidad de un principiante

Es esencial iniciar todo proyecto pro bono con la mentalidad de un principiante. Hay que aportar curiosidad y apertura al proyecto. No asuma que su experiencia se transfiere directamente a la organización.  

Por ejemplo, puede que el cliente no sepa cómo cambiar un formato de página o enviar un email en Salesforce, así que no es conveniente asumir que sí. Los temas que para usted son coser y cantar en un entorno de negocios pueden requerir cierta orientación práctica con las instituciones sin fines de lucro y educacionales.

Matthew Watson, ingeniero de soluciones de servicio y plataforma APAC de Salesforce: "Las organizaciones sin fines de lucro usan un lenguaje diferente, se enfrentan a desafíos distintos y tienen menos experiencia en la gestión de proyectos tecnológicos que los clientes de negocios".

Tenga en cuenta que son las cosas más simples las que permitirán a las instituciones sin fines de lucro y educacionales hacer mucho más en Salesforce. Las claves son:

• Comprender exactamente cómo funciona la organización
• Investigar los casos de uso que corresponden a los procesos de la organización
• Dedicar el tiempo necesario para explicar la funcionalidad
• Asegurarse de que la organización se siente cómoda trabajando en el sistema

Para usted, un proceso como la importación de datos puede ser obvio, pero debe asegurarse de que el cliente pueda comprenderlo cómodamente.

Si viene con una mentalidad abierta a su proyecto pro bono, estará en el buen camino para crear una solución sostenible para su organización. 

Lo bueno, si breve...

Tiene mucho que hacer. Incluso aunque ahora mismo tenga algo de tiempo libre, nunca se sabe cuándo puede surgir una nueva oportunidad laboral, un proyecto de trabajo complejo o una prioridad familiar. Lo mismo ocurre con los empleados de Salesforce que se presentan voluntarios para participar en nuestro programa Pro Bono. 

Y es por eso que limitamos nuestros proyectos del programa pro bono para que no tarden más de 20 horas en completarse. Si limita su proyecto a 20 horas como máximo, habrá muchas menos probabilidades de que surja un trabajo inesperado o circunstancias personales que impidan completar el proyecto. 

Esto no significa que no pueda dedicarle más horas si lo desea. Los empleados de Salesforce son muy generosos y suelen encadenar dos o tres proyectos pro bono para apoyar la causa que más les apasione. 

La mayor ventaja de limitar el ámbito a pequeñas porciones de trabajo es que siempre puede replantear su participación entre un proyecto y otro. Eso le da flexibilidad, a la vez que le permite centrarse en una tarea distinta cada vez.

Evitar proyectos que tengan una fecha límite o sean esenciales para la organización

Sabemos que quiere contribuir a la sociedad y marcar la diferencia. Es por eso que puede sentir la tentación de aceptar cuando su organización le pida que realice una implementación completa o que la configure para dar soporte a una gran gala de recaudación de fondos dentro de solo un par de semanas. Queremos que sepa que no pasa nada por decir que no. De hecho, le recomendamos que evite los proyectos que tengan una fecha límite o sean esenciales para la organización.

Cuando se trabaja como voluntario, es muy difícil mantener un compromiso a largo plazo o terminar un proyecto muy exigente con un plazo corto. Nunca puede saber cuándo cambiarán su trabajo o sus circunstancias personales, y lo último que querrá es abandonar un proyecto antes de terminarlo. Si acepta ayudar a una institución educacional o sin fines de lucro, esta cuenta con que lo hará hasta el final.

Las instituciones educacionales y sin fines de lucro no suelen tener los conocimientos ni los recursos necesarios para completar su proyecto si lo abandona antes de completarlo. Es superimportante que solo se comprometa a hacer lo que puede cumplir.

Sea específico

Como aprendió en la unidad anterior, la reunión de planificación inicial es donde puede aclarar los objetivos generales del proyecto. Durante la fase de definición del ámbito del proyecto, tendrá que hablar con los usuarios sobre las formas específicas en las que usan Salesforce y otras herramientas en su trabajo diario. Necesitará averiguar qué es lo que se hace fácilmente y qué resulta difícil o frustrante. Asegúrese de centrarse en los casos de uso que parecen relevantes para los objetivos del proyecto y busque las tareas manuales repetitivas que podrían automatizarse. 

El objetivo es comprender claramente el problema, cómo afecta a la organización y cómo sería un proceso mejorado, de modo que pueda recomendar la solución correcta. Aquí incluimos algunas preguntas que debería plantear a los usuarios sobre su experiencia:

• Enséñeme cómo hace la tarea [x].
• ¿Funciona bien el proceso? ¿Qué parte es más fácil? ¿Qué le resulta difícil o frustrante?
• ¿Qué importancia tiene esta tarea para su trabajo? ¿Le gustaría poder hacerla más rápidamente o de forma más eficiente?
• Hábleme sobre los datos que recopila. ¿Qué tipo y cantidad de datos supervisa? ¿En qué estado están los datos?

Las respuestas a estas preguntas deberían darle una idea de cuáles son los puntos débiles y su importancia para la misión y las operaciones de la organización. Puede partir de aquí para documentar los requisitos funcionales y empezar a pensar en posibles soluciones.

Es importante documentar y compartir lo que aprendió con su organización. Incluso un pequeño malentendido puede hacer que tome un camino equivocado durante el proyecto. 

Requisitos de documentación

Escribir historias de usuario es una forma excelente de documentar y coordinarse con los requisitos específicos de su organización. Cada historia de usuario describe una necesidad del usuario en un lenguaje sencillo y no técnico. 

Por ejemplo, pongamos que es voluntario en una organización sin fines de lucro de una pequeña comunidad que ofrece servicios de tutoría gratuitos para ayudar a jóvenes y adolescentes. La organización depende de una gran subvención del estado de California para pagar a los tutores. 

Cada mes, la directora ejecutiva de la organización sin fines de lucro envía un reporte financiero al estado, en cumplimiento de las condiciones de la subvención. Y tarda entre cuatro y cinco horas cada mes en crear el reporte. Le vendría mucho mejor dedicar ese tiempo a encontrar nuevas fuentes de ingresos.

Podría escribir una historia de usuario que sería, más o menos, así:

"Como directoria ejecutiva, quiero que el reporte financiero se ejecute automáticamente para poder dedicar menos tiempo a crear reportes y más tiempo a encontrar nuevas fuentes de ingresos".

Observe que la historia de usuario se escribe desde la perspectiva de la directora ejecutiva ("usuario") y describe su necesidad (el "qué") y el motivo por el que es necesario (el "porqué"). La frase está escrita en un lenguaje sencillo y resulta fácil de entender para las personas sin conocimientos técnicos, que pueden dar su feedback.

Una vez que la organización confirma la historia de usuario, puede empezar a definir los requisitos específicos. Siguiendo el ejemplo anterior, deberá identificar los campos que necesita incluir, los criterios de filtrado, la fecha de ejecución y el periodo de generación de reportes antes de empezar a automatizar el suyo.

Determinar qué entra en el ámbito del proyecto (y qué no)

Tras documentar los requisitos de cada historia de usuario, deberá estimar la cantidad de tiempo que tardará en cubrirlos. Esto es más una estimación que un dato concreto, y dependerá de lo familiarizado que esté con la funcionalidad deseada y de si desea estudiar documentación de productos adicional.  Intente llegar a una estimación lo más aproximada posible. 

Después, deberá trabajar con su organización para decidir qué requisitos incluir en el proyecto actual y cuáles posponer para un proyecto futuro. Ahora que ya definió un ámbito realista para el proyecto, es el momento de dar rienda suelta a sus superpoderes de Salesforce para diseñar y crear su solución.