Consejos para establecer el alcance de una estrategia empresarial

No basta con querer: debes preguntarte a ti mismo qué vas a hacer para conseguir lo que quieres.
Franklin D. Roosevelt

Una vez que has establecido la estrategia empresarial que seguirás para elaborar un producto o prestar un servicio, es decir, ya que sabes lo que quieres hacer, el siguiente gran paso consiste en traducir esa estrategia en acciones concretas organizadas en procesos que lleven a la obtención de resultados.

En un post anterior, conversamos sobre cómo construir la estrategia para un producto o servicio y decíamos que se podía empezar respondiendo qué esperamos sacar del proyecto y qué podrían esperar nuestros clientes de este. En esta oportunidad vamos a ver cómo convertir las respuestas a esas preguntas en requerimientos.

Luego de que tengamos todos los requerimientos, conseguiremos como resultado un documento llamado especificaciones funcionales el cual tendrá todas las acciones a ejecutar tanto para la funcionalidad como para el contenido asociado con el producto o servicio.

Antes de entrar en materia, tal vez sea conveniente mencionar que no hay que perder de vista que el éxito de una estrategia depende de que conjuguemos nuestra situación interna con lo que ocurre en el entorno, o sea, que tengamos presente las oportunidades, que recordemos a Kairós.

Más adelante volveremos a esto, pero adelantemos que no importa cuan detallados estén los requerimientos de un proyecto ni cuán buena sea la estrategia si no se cuenta con un equipo motivado y que comparta la filosofía y el propósito de la empresa o del proyecto en particular.

Por supuesto, tener una estrategia clara y plantear el alcance del proyecto contribuye a la sinergia dentro de la empresa que ejecuta el proyecto y justamente por eso nos parece importante conversar sobre este tema. Veamos de qué se trata todo esto.

Definiendo el alcance de la estrategia empresarial

En palabras simples, para implementar una estrategia empresarial es necesario acordar con el equipo envuelto en el proyecto qué funciones y qué tipo de contenido tendrá el producto o servicio sobre el que se está trabajando. Para mejores referencias, usaremos el desarrollo de una Progressive Web App (aplicaciones web) como ejemplo.

¿Qué funciones tendrá la aplicación? ¿Para qué la utilizará el usuario? ¿Cómo la utilizará? ¿Qué información se va a mostrar? ¿Cómo esperamos que esta información se consuma? Estas y otras preguntas similares determinarán la lista de requerimientos que tendrá dicha aplicación.

Cuando sea el momento de plantear estas preguntas y tratar de responderlas, es de esperar que surja cierta conversación dentro del equipo de trabajo y esto es bastante conveniente porque presenta la oportunidad para discutir la visión que tiene cada quien del proyecto y se pueda llegar a un acuerdo sobre lo que se hará y no se hará cuando se vaya a ejecutar.

Otra ventaja de abordar el proyecto de esta manera es que permite que todos compartan el mismo objetivo, cada quien sepa lo que va a hacer y qué se espera de cada uno. También será la oportunidad para plantear un esquema general de todo el proyecto que bien puede ser un diagrama de flujo.

Con esto presente, podemos decir que todos los requerimientos pueden agruparse en dos secciones al momento de elaborar las especificaciones funcionales: una que tenga en cuenta aquellos relacionados con las funciones y otra que incluya aquellos relacionados con el contenido a desplegar en la aplicación web.

Requerimientos relacionados con la funcionalidad

Antes que todo, es importante advertir que no hay razón para que esta lista esté escrita en piedra. Lo mismo que con la estrategia, el alcance del proyecto debe ser genérico y tener la flexibilidad suficiente para que pueda cambiarse según lo vayan haciendo las circunstancias del proyecto.

¿Cómo lograr tal flexibilidad? Una forma de hacerlo es enfocarse en las funcionalidades principales del producto o del servicio. En el caso de una aplicación web, si el objetivo establecido en la estrategia fue, digamos, ofrecer una tienda online para facilitar el proceso de compra de los clientes, es claro que las funciones relacionadas con la selección de mercancías y su pago tienen que especificarse.

Hay algunas sugerencias en relación con la redacción de los requerimientos. Estas son:

• Usa un tono positivo: en vez de enfocarte en un aspecto negativo, dale la vuelta para evitar una redacción que suene prohibitiva. Por ejemplo, en vez de escribir el usuario no debería comprar nada en la tienda sin registrarse antes podría plantearse así: recomendar al usuario registrarse para mejorar la experiencia de compra.
• Sé específico: es conveniente evitar cualquier redacción que sea susceptible de diferentes interpretaciones. Si un requerimiento se escribe con ambigüedad, será difícil la coordinación. No es lo mismo decir que la ventana de pago debe ser pequeña a expresar que la ventana de pago debe ser responsive.
• Evita usar términos subjetivos: al evitar expresiones subjetivas podemos garantizar que los requerimientos no sean malinterpretados. Sin duda, no queda claro que se quiere decir al escribir algo como que la aplicación debe tener vistas lindas en comparación con la aplicación debe cumplir con los parámetros generales de diseño establecidos en el branding de la compañía.

Requerimientos relacionados con el contenido

Establecer el alcance del contenido va de la mano con las funcionalidades que se espera que tenga el producto o servicio (en nuestro ejemplo, la aplicación web). Lo mismo que con las funcionalidades, es conveniente plantear qué tipo de contenido se va a emplear en el desarrollo de la aplicación.

Hay que tener en cuenta que, aunque solemos pensar en texto cuando hablamos de contenido, en realidad también incluye imágenes y videos pues estos también ayudan a mejorar la experiencia de usuario. En este sentido, es importante establecer de antemano quién se encargará de gestionar la redacción, quién será responsable de las imágenes y quién creará los videos.

En el caso de la redacción, y porque estamos hablando de una aplicación web, hay que tener en cuenta cómo se desenvuelve el mercado del producto o servicio para el cual se crea la aplicación. Aquí habría que hacer uso de las diferentes estrategias de marketing online como SEO, marketing de contenidos, email marketing, marketing en redes sociales, entre otras.

En el caso de las imágenes, aquí habría que tener en cuenta fotografías, gráficas, infografías y cualquier pieza de diseño gráfico que sirva de apoyo a la información que se está mostrando en la aplicación web. Lo mismo cuenta para los videos que bien pueden ser animaciones con mensajes cortos y al grano.

Por supuesto, aquí también habría que redactar los requerimientos de forma positiva, siendo específicos y evitando planteamientos subjetivos. En sí, el propósito de todo esto es tener una idea general del trabajo por hacer y que cada quien conozca su responsabilidad dentro del proyecto.

¿Influye la tecnología en la forma en que planteamos los requerimientos?

La respuesta corta es que si, la tecnología marca la pauta en cuáles requerimientos tendrá el proyecto y cómo se plantean. Aquella vez, cuando definimos las aplicaciones web, conversamos un poco sobre la tecnología y cómo se relaciona con la humanidad.

Allí planteamos que la tecnología es el conjunto de conocimientos y técnicas que nos permiten modificar nuestro entorno para satisfacer nuestras necesidades y encontrar soluciones útiles a nuestros problemas.

Eso significa que la tecnología determina qué podemos y qué no podemos hacer. ¿Y no es acaso eso lo que esperamos conocer al preguntarnos por el alcance del proyecto? Es imposible, para una aplicación web, que uno de los requerimientos trate sobre la emisión de olores a través del dispositivo cada vez que alguien presione algún vínculo. ¡No hay tecnología para eso!

Veamos un ejemplo más real que tiene que ver con la tecnología LAMP y JAM, ambas usadas para el desarrollo de aplicaciones web. Sus nombres provienen de las herramientas que emplean para lograr su cometido, por eso se les suele agregar la palabra stack que significa amontonar o apilar, así que podría traducirse como un grupo de tecnologías.

LAMP, por ejemplo, toma sus letras de Linux, Apache, MySQL y PHP; si tomamos la primera letra de cada nombre, obtenemos LAMP. En el caso de JAM, su nombre viene de las iniciales de Javascript, APIs y Markdown.

LAMP y JAM, formas diferentes de desarrollo web

Bien, habíamos dicho que la tecnología influye en qué podemos hacer y qué no. Digamos que un cliente espera que la aplicación web tenga tiempos de carga reducidos, menores a 5 segundos, y solo disponemos de tecnología LAMP. ¿Qué hacer? Lo mismo que haríamos en el caso de que nos pidieran que los dispositivos emitieran olores cada vez que el usuario usa un enlace: explicar que no se puede.

Afortunadamente, podemos decirle a un cliente que si es posible que su aplicación web cargue en menos de 5 segundos. El asunto es que no es posible con la tecnología LAMP sino que habría que hacer uso de la tecnología JAM.

Además, usar la tecnología JAM permite hacer uso de unas herramientas construidas a partir de Javascript llamadas frameworks para crear aplicaciones web progresivas que, aunque también podrían hacerse con LAMP, no dan garantía de que la aplicación cargue rápidamente pues es necesario agregar otro plugin que, más bien, incrementa el tiempo de carga.

¿Por qué ocurre esto? ¿Por qué con una sí, y con la otra no? La razón está en que ambas tienen formas diferentes para desarrollar una aplicación web. Veamos cómo funcionan ambas tecnologías.

LAMP o consultas web en tiempo real

Con la popularización del Internet surgió la necesidad de compartir nuestras ideas y lo que hacemos con los demás. Fue el momento para que surgieran los blogs, los sitios web y otras aplicaciones web. Por esos tiempos, también tomaron fuerza Linux y sistemas operativos construidos a partir de este, así surgió Ubuntu.

Entre tantos CMS (Content Management System), hubo alguien que vio la oportunidad de aprovechar el auge de LAMP para crear una plataforma que permitiera crear blogs sin tener que conocer mucho sobre desarrollo web. Este CMS es muy conocido hoy en día, su nombre es WordPress.

WordPress supo aprovechar la tecnología LAMP. Esto fue un rotundo éxito. Incluso, al momento de escribir esto (2020), la mayoría de los sitios en la web están hechos sobre el paradigma LAMP por medio de WordPress.

Bajo este paradigma, la información fluye más o menos así:

1. El usuario usa un navegador para contactar con la aplicación web.
2. Apache recibe esa información y la pasa a PHP para que ejecute la solicitud realizada al servidor.
3. PHP también se comunica con MySQL para sacar la información que necesite de la base de datos.
4. Finalmente, PHP junta toda la información y la transforma en un archivo HTML que envía a Apache para que pueda ser desplegado en el navegador y pueda ser leído por el usuario.

Vale resaltar que el servidor funciona con sistemas operativos hechos sobre Linux, como Ubuntu, y que toda la información se encuentra en un solo lugar, es decir, basta con que falle algo en el servidor para que la aplicación deje de funcionar. Por esta razón se les conoce como sistemas monolíticos o centralizados.

JAM o consultas web precargadas

Con todo y que LAMP tiene sus funciones centralizadas y ello trae como consecuencia que las aplicaciones web sean susceptibles a sabotajes y hacks, este paradigma fue todo un éxito porque solucionaba las necesidades que teníamos, y todavía seguimos teniendo, en relación con las aplicaciones web.

No obstante, hay algo curioso en los seres humanos que bien podría decir que está en nuestra naturaleza: somos insaciables. Siempre queremos más, siempre queremos estar mejor. Apenas hemos satisfecho una necesidad y estamos seguros de que no nos faltarán medios para continuar satisfaciéndola, comenzamos a indagar sobre cómo satisfacer las siguientes.

Además del tema de seguridad que acabamos de mencionar, también pasa que un sitio web que toma más de 5 segundos en cargar nos llena de impaciencia. Son muchas las razones por las cuales un sitio web tarda en cargar, así que nos enfocaremos en hablar del caché y su relación con la diferencia en los tiempos de carga cuando usamos JAM.

Para ello, necesitaremos conocer cómo fluye la información con esta tecnología, tal cual como hicimos en el caso de LAMP. El proceso va más o menos así:

1. El usuario usa un navegador para contactar con la aplicación web.
2. Casi inmediatamente, el usuario recibe en su dispositivo la información solicitada.

Pero, ¿cómo? ¿En JAM no hay servidores? ¿El navegador no crea ninguna conexión con el servidor para solicitar información? ¿Para qué es Javascript, las APIs y el markdown entonces?

¿Cómo funciona JAM?

Si hay servidores. Lo que ocurre es que todo el proceso de carga de la información ocurre mucho antes de que el usuario lo solicite. Como se sabe que en algún momento alguien usará la aplicación web, todas las vistas han sido cargadas con antelación y almacenadas en la memoria caché del servidor que hospeda la aplicación web y es ese archivo el que solicita el navegador para mostrar al usuario.

Como mencionamos antes, con Javascript se realizan los frameworks que permiten agilizar el proceso de desarrollo web, con una API (Application Programming Interface, o interfaz para programación de aplicaciones) se organiza toda la información y desde otra aplicación se diseña la forma en que esa información será mostrada bien sea a través de markdown u otros lenguajes de programación.

En otras palabras, la mayor parte del proceso de carga de la aplicación web ocurre cuando el desarrollador sube los archivos a los diferentes servidores, incluso el que hospeda la aplicación web y, en ese momento, ocurre un proceso llamado rendering que nos es más que la carga anticipada de la información diseminada en diferentes servidores para ser almacenada en la memoria caché del servidor que sirve las vistas al navegador web. Este proceso se conoce como Server-Side Rendering

Tecnología, cuestión de alcance

Con todo y que LAMP y WordPress han sido de gran ayuda, no es posible crear con esa tecnología una aplicación web que cargue casi instantáneamente (hay más ventajas de usar JAM, pero nos estamos enfocando solo en esta).

Además, como la construcción de las vistas no se hace en tiempo real, sino que son precargadas cuando el desarrollador sube la información a los diferentes servidores, el hacking es virtualmente imposible ya que no hay forma de incluir archivos maliciosos cuando el usuario carga la aplicación web.

En virtud de todo esto que hemos mencionado, es fácil decir que tener un conocimiento claro de las herramientas a disposición para ejecutar un proyecto marcará la pauta, pues, de qué necesidades podremos satisfacer y cómo plantear los requerimientos. En el fondo, es una cuestión de preguntarnos qué haremos para conseguir lo que queremos.

¡Gracias por leer!