Arquitectura, buenas prácticas y desarrollo sobre la nueva herramienta de Microsoft SharePoint 2016

¿El branding debe incluirse en la Gobernanza?

branding

Si en la anterior entrada hablábamos de que el desarrollo era el gran olvidado en los planes de gobernabilidad de SharePoint de las empresas, varias personas me comentaron si el diseño/branding debe incluirse en dicho plan. Para contestar a esta pregunta, en primer lugar debemos definir cuáles son los puntos claves sobre los que quieres gestionar el gobierno de SharePoint. En mi opinión los puntos claves son tres:

  • Control TI
  • Administración de la Información
  • Administración de aplicaciones.

Dentro del Control TI es dónde incluimos el apartado de desarrollo por los puntos que citamos en dicho artículo. El branding o diseño «solamente» es la forma en la que se representa a las aplicaciones. El diseño y la usabilidad de la aplicación es algo muy importante. Una buena experiencia de usuario hace que aplicaciones mediocres tengan ventajas sobre otras aplicaciones funcionalmente mejores pero más difíciles de usar para un usuario avanzado.

Ahora bien, ¿el diseño debería ser controlado en la Gobernanza de SharePoint?

images

Según la documentación que proporciona Microsoft sobre un plan de Gobernanza se debe incluir un plan sobre el Branding. En dicho artículo se indica que la organización debe tener una guía de diseño, es decir, un lugar en el que se indiquen aspectos colaborativos como son colores, letra, logos y aspectos que visualmente se deben de tener en cuenta. El principal motivo de esto es para facilitar la adopción de la plataforma a los usuarios. Por ejemplo, si todas las aplicaciones tienen el logo en la parte izquierda, no deberíamos tener aplicaciones con el logo en la parte derecha.

Esta información sobre la guía de diseño es algo que se debe mencionar en el Plan de Gobernanza, pero dicha guía no debe ser parte del documento de gobernanza.

¿Por qué?

De la misma forma por la que en la parte del desarrollo se indicaba que debemos de tener un manual de buenas prácticas de desarrollo y que este manual no se incluía en el documento de la gobernabilidad. La guía de diseño no debe de formar parte, principalmente porque esta guía no depende de todos los integrantes del gobierno de SharePoint, sino que depende de un departamento concreto el cuál es el que debe de marcar las pautas en cuanto a diseño en la organización.

 

¿Debemos incluir qué herramientas de diseño utilizar?

Otro aspecto que se menciona en el artículo de Microsoft es que se debe utilizar Design Manager para los aspectos relativos al diseño. En mi opinión, ningún Plan de Gobernabilidad debe de incluir qué herramientas utilizar. Uno de los motivos es que naturalmente todos los miembros que forman el gobierno de SharePoint no disponen de los conocimientos necesarios para saber que herramienta es mejor que otra. Pero, además de este motivo, para mí el principal motivo es que lo que debe de indicar el documento de Gobernanza es que se utilicen herramientas óptimas y adecuadas. En esta definición, cada equipo de desarrollo es un mundo y quizás a unas personas les gusta utilizar WebStorm para escribir el JavaScript y quizás a otras personas les gusta SharePoint Designer. ¡Para gustos colores! Pero independientemente de la herramienta que se utilice, ésta debe ser óptima y debe ahorrar tiempo (por lo tanto queda claro que Designer no se puede utilizar aunque no lo indiquemos implícitamente).

Conclusión

Muchas organizaciones instalan una infraestructura de SharePoint muy potente, pero al cabo del tiempo deja de funcionar. El motivo principal es que no hay plan para administrar/gobernar SharePoint. Si en tu organización todavía no se dispone de esta Gobernabilidad, como consejo: ir pensando en un plan para ir gobernando. SharePoint es un producto muy grande y completo. No se puede instalar y pensar que con buenas intenciones se va a mantener.

mm

Sobre Adrián Díaz

Adrián Díaz es Ingeniero Informático por la Universidad Politécnica de Valencia. Es MVP de Microsoft en la categoría Office Development desde 2014, MCPD de SharePoint 2010, Microsoft Active Profesional y Microsoft Comunity Contribuitor 2012. Cofundador del grupo de usuarios de SharePoint de Levante LevaPoint. Lleva desarrollando con tecnologías Microsoft más de 10 años y desde hace 3 años está centrado en el desarrollo sobre SharePoint. Actualmente es Software & Cloud Architect Lead en ENCAMINA.
Esta entrada ha sido publicada en buenas practicas y etiquetada como . Enlace permanente .
Suscríbete a Desarrollando sobre SharePoint

Suscríbete a Desarrollando sobre SharePoint

Recibe todas las actualizaciones semanalmente de nuestro blog

You have Successfully Subscribed!

ENCAMINA, piensa en colores