Cuestiones sobre el diseño de soluciones en SharePoint (1)

Una de las incuestionables capacidades de SharePoint, es la de poderse adaptarse rápidamente a muchas de las problemáticas que surgen en las empresas.

Sin embargo a la hora de diseñar estas soluciones no todo es tan sencillo, con esto me estoy refiriendo al hecho de que nos encontramos en innumerables ocasiones con problemáticas empresariales que no son excesivamente complejas pero que sin embargo a la hora de trasladarlas a SharePoint, se convierten en un verdadero infierno.

Durante estos años que llevo trabajando con SharePoint, me he encontrado con multitud de casos en los que cosas que parecían relativamente sencillas por que el 80% del trabajo ya estaba hecho, funcionalidades que de por sí contempla SharePoint el 20% restante ha supuesto una cantidad de trabajo terrible. Donde ese 20% has supuesto una cantidad de tiempo y un coste tan elevado que es casi imposible de justificar.

Vamos a dejar al margen las ocasiones en que el diseño de una solución debe ser estrictamente fiel a un procedimiento empresarial, y debe reflejar de manera completa y exacta dicho procedimiento; en este punto la postura es clara; tendremos que hacer lo que sea para que la solución cumpla al 100% los requerimientos del procedimiento.

En el resto de ocasiones, tenemos la disyuntiva de hasta qué punto debemos ser flexibles en el desarrollo de la solución. Según mi experiencia debemos ser flexibles y agiles.

Muchos de estos procesos requieren que seamos agiles, no podemos esperar meses a tener una herramienta para poder gestionar eficazmente. A esto debemos añadir el hecho de que muchos de estos procesos están vivos, es decir se empieza haciendo cosas de una manera, y tras evaluaciones sucesivas del procedimiento así como de la experiencia que se va adquiriendo del uso del mismo, se va optimizando, suprimimos, añadimos y cambiamos pasos, información y flujos de la información.

Tenemos que contemplar el diseño como una negociación Win-to-Win, en donde todos ganamos por una parte tendremos que adaptar los requisitos o los procedimientos para que estos sin perder en esencia su objetivo sean los menores para no tener que realizar complejos sistemas para sustentarlos. De esta manera y solo de esta manera seremos capaces de diseñar sistemas cuyo ROI, sea positivo desde el comienzo.

En esta negociación, se deben poner sobre la mesa los requerimientos y los recursos de que disponemos para trasladar estos a la plataforma.

Un sencillo ejercicio de ponderación, donde valoramos los requisitos de modo que los que más valor aportan tendrán una puntuación más elevada y los que menos valor aportan una puntuación inferior y del mismo modo, evaluamos la complejidad que entrama desarrollar cada una de las partes del sistema, valorando en términos de tiempo, coste y complejidad cada uno de los pasos necesarios para cumplimentar dichos requisitos.

A través de un ejercicio de esta índole, debemos suprimir todo aquello que en esencia sea superfluo y buscar alternativas a aquellas partes del sistema que por su tiempo, coste o complejidad vayan a ser cuellos de botella tanto en el uso como en el desarrollo de las mismas.

Otro punto importante, es el de la rapidez; cuanto antes demos a nuestros usuarios una herramienta y algo básico con lo que trabajar empezaremos a recibir feedback que deberemos tener en cuenta, muchas de las propuestas del usuario final son imaginativas y creativas (y generalmente más baratas).

En muchas ocasiones esto conlleva exprimir lo que tenemos al máximo, más adelante siempre tendremos oportunidades de realizar esas complejas partes que harán de nuestra solución una solución perfecta.

En próximos posts me gustaría comentar algunas experiencias tanto mías como de algunos colegas sobre el diseño de soluciones con SharePoint.

Cualquier comentario o aportación será bienvenido.