El Método OnMind - Versión 1 (Preview)

» Una metodología para análisis y diseño de software, gestión de proyectos ágiles y gestión organizacional modesta
© 2018-2021, Cesar Arcila. Todos los derechos reservados.

El método de OnMind es una manera de repensar el análisis y diseño de sistemas tomando aspectos convencionales e incorporando elementos y un modo singular de abstraer conceptos y objetos del mundo que son susceptibles de gestionar o sistematizar en orden al apoyo y estrategia que ello aporta en organizaciones, o bien, en lo relacionado con datos e infraestructura.
Estaríamos hablando entonces de un método para el análisis y diseño de sistemas que simpatiza con una gestión organizacional modesta (siendo incluyente y compatible también con pequeños negocios), además de proyectos ágiles de software de gestión.

Para abordar los aspectos o lineamientos que se proponen, se plantea el siguiente temario a desarrollar:

Concepto general del método OnMind
Definición de conceptos claves (Glosario)
Contexto para profesionales administrativos e interesados (no técnicos)
Aspecto en torno a una gestión organizacional modesta
Aspecto sobre proyectos ágiles de software de gestión
Aspecto de análisis y diseño de sistemas de información (A&D)
¿Qué se considera y qué no hace parte del método OnMind? (Alcance)
¿Cómo interactúan los elementos o cómo se aplica el método?
Sobre la herramienta de gestión de OnMind (del mismo Autor)

En el presente texto en muchos casos se usa paréntesis a modo de estilo y convención para indicar algún asunto técnico o comentario aclaratorio respecto al contexto, por tanto, en función de una lectura más fluida se podrían omitir tales comentarios, salvo que se requieran tener presente detalles o se quiera hacer una revisión. No obstante, en la medida que se avance el contenido puede ser altamente técnico, por ejemplo, el punto 6, 7 y 8. Aún así, en tales temas podrían encontrarse explicaciones de interés, de modo que, si no es motivo de confusión por lenguaje técnico, se da también la bienvenida a todo interesado. Adicionalmente, se incorpora un glosario como referencia sobre conceptos claves y como base para una comprensión.

Sobre el Autor

Ingeniero de Sistemas, con conocimientos en Gestión de Proyectos y afines (visión organizacional o de negocios), Profesional Certificado Oracle (OCP) como desarrollador, conocimientos en ITIL y estudios en Filosofía. Desde los años noventa he emprendido una carrera profesional que ha partido de lo técnico hacia un perfil de gestión, adaptándome a nuevas tendencias y conservando lo mejor de los orígenes. Experiencia participando en proyectos de software (ERP, CRM, Workflow) con diversas tecnologías informáticas y en los que se involucran empresas importantes de diferentes sectores (Financiero, Servicios Públicos, Tecnología, Educativo, Salud y Gobierno), adicionalmente proyectos con redes y actualmente computación en la nube.

Líder, experto y creativo, con un punto de vista singular, enfoque holístico y unificador. Políglota informático, apasionado por proyectos de tecnología que se alinean con ideas bien pensadas (ej. proyecto onmind.co :)

Ver obras recomendadas del Autor (portafolio)

1. Concepto general del método OnMind

Para introducirnos al concepto general es importante referirnos al fundamento simplificado que surgió de mi experiencia y sobretodo de mi inspiración:

En un mundo o contexto de ideas e ilusiones mentales surgen fabricaciones mentales. Esto se refleja en los sistemas y en lo que se proyecte. Estas fabricaciones se vinculan con identidades. No todas las identidades participan activamente, de allí que se distinguen los participantes. Además, las identidades pueden conformar círculos de vínculos, estos pueden interpretarse como roles naturales de las identidades en un contexto. Luego, tenemos el entorno y las cosas que distinguimos de un modo distinto a las identidades, refiriéndonos incluso a conceptos o asuntos. Surgen procesos donde se requieren entradas o solicitudes que usualmente generan alguna actividad (o su suporte). Dado que este mundo está altamente influido por el aspecto financiero, tendremos resumenes de cuentas y sus operaciones. En cuanto algo sea altamente específico o requiera mayor detalle, se puede decir que hay cosas extraordinarias y complementarias (extra). Este es el fundamento de un análisis bajo mi óptica, de allí que lo participe como un método, quizás con algunas añadiduras.

En un sentido general, el método OnMind consiste en unos lineamientos o aspectos que parten de una manera de abordar el análisis y diseño de sistemas de información e incluso apunta a proyectos ágiles y una gestión organizacional modesta (siendo incluyente y compatible también con pequeños negocios), apoyándose regularmente en lo que denomina o cataloga como un entorno de datos orientado a la misión (Management Oriented Data Environment - MODE), por ejemplo, la plataforma de software OnMind. Algunos lineamientos son más significativos y fundamentales que otros que pueden ser más flexibles, tales lineamientos los desarrollaremos en el presente texto.

Siendo principalmente un asunto tecnológico con incidencia en gestión de proyectos y ligeramenta en negocios, el campo al que apunta nos remite a interesados, tanto profesionales de tecnología (informática y de software) como administrativos, cuya visión moderna no discuten la influencia, la estrategia que aporta y el apoyo de la informática para el desempeño de la gestión y la dimensión o alcance de las organizaciones en nuestra actualidad, así como el factor en torno al conocimiento.

Cuando se habla aquí de proyectos ágiles, debe evitarse confundir con inmediatez o con una expectativa lineal de reducción de costos, dado que no necesariamente sea el caso, simplemente, un proyecto ágil tiene un curso natural más fluido que cuando se enfrenta un proyecto de mayor dimensión. En algunos casos, los proyectos grandes pueden ser ejecutados en fases menores permitiendo proyectos ágiles.

En principio, el método surgió para apoyar micro-proyectos y proyectos por fases cortas, basándose en la implementación de la plataforma de software OnMind (que aunque no requiere el método, este le da una mejor orientación aprovechando sus características). Posteriormente, la plataforma terminó teniendo incidencia y dió forma al método.

Si bien, existen varias metodologías ágiles para proyectos, además de su sentido original, este método apunta a diversos criterios así como beneficios:

Dar apertura para abordar micro-proyectos y proyectos por fases cortas tanto en la gran empresa como en la pequeña, siendo también incluyentes con el profesional independiente (freelance). Se considera que el tiempo es dinero, si al disminuirse en los costos no se ve mayor beneficio, los beneficios se pueden apreciar en otro sentido (por ejemplo, la oportunidad de una entrega en menor tiempo o en la validación de una prueba piloto). Es decir, debe valorarse la incidencia del método en la reducción del tiempo a la vez que se pueden valorar bien los servicios profesionales.
Dar un nuevo aporte al análisis y diseño de sistemas informáticos que resulta distinto al practicado regularmente (aunque homologable) para soportar micro-proyectos o proyectos modernos, así como orientar bases de conocimiento aplicado a negocios.
Considerar el cuidado de la creatividad de los desarrolladores en un proyecto, o bien, buscar un equilibrio ante trámites de gestión que puedan simplificarse o hacerse sencillos, comprendiendo que la creatividad influye en la productividad y en últimas en la calidad. En otras palabras, en tanto sea posible para una organización, colocar la creatividad en primer lugar siendo guiada (en lo concerniente al desarollo de software y parámetros de un proyecto, sin tratarse de un absoluto).
Confrontar barreras de acceso que se han producido por exigencias de la industria o por la revolución del conocimiento tecnológico, y generan brechas o círculos que separan de otros, si bien, pueden ser comprensibles y respetables en muchos casos, en algunos resulta cuestionable. Como analogía con el sector de construcción: hacer una megaconstrucción es distinta a un puente convencional, fabricar un rascacielos es distinto a un condominio, indistintamente del caso puede existir mantenimiento o adecuaciones específicas, y en últimas, las expectativas, exigencias o requisitos son distintos en cada caso. En tecnología el principio de lo virtual o de software es el mismo tanto para pequeños como para grandes, distinta es la libertad de acogida que ejerce un cliente grande, esto se ve influenciado también por líderes técnicos que buscan mitigar el riesgo para su compañía pero en muchos casos hay temor o intereses, y quizás se encuentre un nuevo tipo de líder más valiente en nuevos tiempos o de mentalidad abierta para nuevas tecnologías.
Tener apertura de acogida, según el proyecto o la organización, para la incorporación de recurso empírico (no profesional, con experiencia o introducido), incluso independientes (freelancers), así como trabajo remoto (teletrabajo), de tiempo parcial o completo de ser viable y dentro de un código de disciplina (por ejemplo: ser responsable con lo acordado, reuniones, tareas, entrega, etc.).
En un tema técnico y complejo, transmitir algo de sencillez, un sentido holístico y unificador.

El término “OnMind” podría entenderse en el origen de las palabras en inglés “on” y “mind” como “encender la mente” (o despertar, que puede relacionarse con la creatividad), y fue usado para promocionar el proyecto del mismo nombre (la plataforma de software OnMind) cuyo eslogan original cita: “Enciende tus ideas con una experiencia digital”, actualmente …

Apps o proyectos apoyados en plataforma para encender ideas

2. Definición de conceptos claves (Glosario)

Con el fin de lograr un acercamiento de comprensión de un asunto con aspectos técnicos generales, se hace uso del siguiente glosario. Puedes revisarlo o dejarlo para referencia posterior entrando en materia con el siguiente tema.

Alojamiento “web” (“web hosting”): El alojamiento o “web hosting” es un servicio frecuentemente usado para publicar sitios en Internet. Este servicio surgió con la transición de siglo (finales del noventa y principios del dos mil) dada la necesidad de publicar sitios. Antiguamente quién deseaba tener su sitio debía comprar un servidor (en algunos casos tener un computador aislado en el garaje o el estudio), configurarlo, administrarlo, dejarlo encendido y exponerlo contando con servicios de una empresa de telecomunicaciones o proveedores de Internet. Basicamente, consiste en publicar una carpeta (destinada por el proveedor) donde se guarda el contenido (o páginas) del sitio, adicionalmente da acceso a funciones como buzones de correo electrónico y bases de datos, en ocasiones incluyen el dominio (la dirección por nombre en Internet), además, al basarse en carpetas no se mide capacidad de computo (en muchos casos se restringe procesamiento). Dado el interés de publicar sitios, además con la gran acogida para marketing digital, es el servicio más económico, sin embargo un alojamiento “web” convencional no es apropiado cuando se trata de plataformas informáticas e infraestructura empresarial, esto sería mas bien un asunto que correspondería al concepto de la nube.
Aplicación Informática (“app”): Programa de computador diseñado para realizar una función específica. Cuando un producto de software es grande, se pueden usar términos como funcionalidad, módulo o componente en el contexto de aplicaciones, incluso algunas veces, el término opción o característica (asociada a un icono, cuando es significativa en el sentido comercial). También existe la acogida del término en inglés denominado “Apps”. Para efectos de negociación, se pueden exponer funcionalidades, módulos o componentes significativos o que se relacionan con un proceso y que tienen un precio según una propuesta dada. Cuando una aplicación funciona bajo el mecanismo de internet se habla de “aplicación web” (o “web app”).
Base de Datos (“database”): Mecanismo y programa de computador en donde se almacenan datos debidamente organizados, en inglés “database”. Generalmente, las aplicaciones para negocios hacen uso de un programa gestor (o motor) de base de datos que pertenece a un fabricante distinto y que puede generar un costo adicional, si bien existen alternativas decentes de bases de datos sin generar costos por licenciamientos (distinto cuando se trata del soporte). En muchos casos, para acceder a la información estos motores de datos usan un lenguaje estructurado de consulta (concido como SQL), como alternativa, aquellos gestores que no lo usan entran en un grupo denominado NoSQL.
Dominio: Para el contexto se refiere al nombre de dominio que se registra para Internet (por ejemplo: onmind.co), si se toma como analogía el concepto de dirección de domicilio, el dominio sería la dirección en Internet, y si se toma la idea de un local dentro de un centro comercial o empresarial se podría hacer la analogía con lo que se conoce como subdominio, el cual guarda dependencia con un dominio.
Hardware: Se refiere al componente físico, tanto visible como electrónico de los computadores.
Infraestructura: Si se toma la raíz del latín “infra”, que significa “debajo”, se comprende entonces que se refiere a algo debajo de la estructura, o lo que está en el fondo de un asunto (por ejemplo, el tecnológico, eléctrico, vial, etc.). Cuando en tecnología se habla de infraestructura empresarial se refiere a redes, aparatos, computadores, servidores y demás que correspondan a un enfoque empresarial, descartando lo diseñado con fines domésticos o para una simple oficina. No obstante, en la actualidad podría considerarse cierta infraestructura doméstica o para una oficina (por ejemplo, combinando elementos como wifi, redes domésticas, computadores, etc.).
Interesados: Es un término mas bien usado en gestión de proyectos para referirse a quienes se involucran de algún modo en el proyecto. En la analogía de un encuentro deportivo, tanto los espectadores, como los jugadores, el director técnico, los ejecutivos y los inversores serían los interesados. Ahora bien, cuando se requiere toma de decisiones, esto se remite a un número reducido de personas que se conocen como interesados claves, los cuales deben estar bien identificados en un proyecto.
Lenguaje de Programación: Cuando en nuestro contexto tecnológico se eschucha hablar de términos como Java, Javascript, PHP, Python, Kotlin, SQL, etc., es como cuando enunciamos los lenguajes Inglés, Español, Mandarín, Portugues, Francés. De manera semejante al lenguaje humano, el lenguaje de programación es la manera de comunicar y dar instrucciones a un computador, en realidad es un asunto bien técnico. La escritura de ciertas palabras con convenciones, operaciones y signos para lograr un resultado, es lo que se conoce como código o programa. La acción de escribir este código se denomina codificación o programación de computadores. En algunos casos se encuentra en el medio una plataforma de programación (como la máquina virtual de Java o .Net) que admite varios lenguajes (quizás sirva de analogía imaginar una región o país políglota).
Licencia de Software: En temas de derechos de autor, el propietario de los derechos puede otorgar o autorizar el uso de una copia (ejecutable) de su obra para que sea instalado bajo los términos especificados para la licencia, lo que se conoce como licencia de software, es decir, el software requiere de una licencia que estipula su uso. Existe un grupo de licencias conocida como “open source”, generalmente indican que exponen el código sin ningún tipo de garantía y la licencia no tendría costo, distinto es en cuanto al soporte. Hay otras semejantes sin costo (conocidas como “freemium”) que evitan exponer el código y ofrecen versión de pago. Las licencias comerciales clásicas incluían tanto un costo alto por la licencia como el costo por soporte en cada versión liberada. También está el caso de alquileres de licencia (por ejemplo, pago anual). En lugar de licenciamiento existe un modelo que ofrece servicios empaquetados (combinando no sólo el software, sino infraestructura y algún soporte) que funcionan a través de internet (remitiéndonos a “la nube”), mas no se estiman licencias de software para el usuario sino un servicio (el proveedor es quién adquiere la licencia o es un fabricante que no necesita distribuir su software, sólo se usa en su propia infraestructura).
Máquina Virtual: Dado el avance de los computadores actuales (sobretodo de servidores), es posible simular un computador tomando recursos de la máquina real, como si existiese otra máquina dentro de nuestro equipo (o servidor), esto se conoce con el término máquina virtual. Cuando se trata de un proveedor que ofrece publicar máquinas virtuales a través de internet (con costos menores a un servidor físico), se habla de un servidor privado virtual (usando las siglas en inglés, VPS).
Nube (la nube o “Cloud”): En inglés “Cloud”, también conocido como la computación en la nube (Cloud Computing), en el presente contexto es un término se refiere a un servicio que funciona a través de internet y es expuesto generalmente por un proveedor. Cuando el caso es distinto de almacenamiento en la nube (para archivos), generalmente involucra una plataforma con orientación organizacional o hacia el procesamiento (computación), lo cual brinda un alcance interesante y muchas veces requerido en negocios. Los clientes directos de un proveedor de servicios en la nube, generalmente no requieren adquirir licencias de software sino un servicio y es el proveedor el que puede obtener alguna licencia para el software que este instala, salvo el caso de ser el mismo propietario o productor de ese software. No obstante esto también depende de los términos de la licencia que un proveedor adquiere y que pueden generar impacto mayor en el cobro del servicio que preste.
Plataforma: En un sentido general puede referirse a un soporte para algo (o alguién) o como sinónimo de base. Aplicado a la informática, se refiere a sistemas que sirven de base para otros componentes o módulos compatibles (tanto en software como en hardware).
Proyecto: En contexto, se orienta hacia un esfuerzo que generalmente comprende un alcance, un costo y toma un tiempo para obtener un resutado, producto o servicio. En cuanto a proyectos ágiles, debe evitarse confundir con inmediatez o con una expectativa lineal de reducción de costos, dado que no necesariamente sea el caso, simplemente, un proyecto ágil tiene un curso natural más fluido que cuando se enfrenta un proyecto de mayor dimensión. En algunos casos, los proyectos grandes pueden ser ejecutados en fases menores permitiendo proyectos ágiles.
Red: Basicamente, se refiere a un conjunto de computadores y dispositivos electrónicos interconectados que posibilitan una comunicación entre ellos (bien sea por cable, de modo inhalámbrico o móvil), haciendo uso de protocolos para establecer su conexión. Internet en últimas es una red enorme. El aparato que comunmente es utilizado por las compañías de telecomunicaciones para ofrecer el acceso a Internet por cable se llama “modem”, este a su vez puede brindar la señal inhalámbrica (WiFi®), en otras palabras, el “modem” es el puente para el acceso a Internet por cable y actualmente suele proporcionar señal inhalámbrica (en las empresas se combina su uso con otros aparatos como el denominado “router” o puntos de acceso). También encontramos servicio de Internet móvil para uso doméstico (sin cable), el cual requiere de un dispositivo para señal MiFi (tecnología que en lugar de remitirse a redes por cable es pensada para redes móviles).
Servicio de Consultoría: En el sentido tecnológico, la consultoría se refiere en principio a una función orientativa, de análisis, de apoyo o acompañamiento, y actividades derivadas en un contexto estratégico o sobre un conocimiento específico, distinta o complementaria a la producción de software (como fábrica o industria), por otra parte, no consiste en servicio técnico sobre aparatos de uso convencional (domésticos o de oficina, como celulares, impresoras, proyectores de video, etc.) o sobre algo que es cubierto por otra ocupación o personal dedicado a ello.
Servicios de Terceros: Se refiere a cualquier servicio de empresas que prestan un servicio adicional para cubrir alguna necesidad complementaria, y que se adquiere por separado. Tal es el caso del proveedor de servicios de internet (ISP) que suelen ser compañías telefónicas o de telecomunicaciones. También se puede identificar el proveedor de dominio, proveedor de servidor en internet, proveedor de certificado de seguridad, proveedor de pasarelas de pago (cuando se requiere cobro con tarjetas desde una “app”), de mensajes, etc.
Servidor: En un sentido general, se refiere a proceso diseñado y enfocado exclusivamente para atender peticiones, compartir recursos o su función específica. Esto se aplica a servidores físicos (que son computadores especializados), virtuales y a programas de software según se refiera el contexto. Cuando se habla de servidores físicos o servidores en una red de computadores, se refiere a máquinas o computadores especializados que son debidamente diseñados para proporcionar servicios o compartir sus recursos (en ocasiones y en cuestiones de redes domésticas, se llega a usar el concepto con cualquier computador destinado para hacer las veces de servidor, mas en un entorno empresarial esto resulta inadmisible).
Sistema Operativo: Software principal que interactúa entre el computador y los demás programas, recursos y dispositivos que se conecten directamente (Ej. Microsoft Windows, macOS, Linux).
Software: Referente al componente lógico en sistemas informáticos, tales como aplicaciones, sistemas operativos (Ej. iOS, Android, Windows), etc.
Web: Término genérico referente al mecanismo de Internet. Aunque el término en sí aplica a la red informática mundial (World Wide Web), también se puede aplicar a redes locales cuando se combina o acompaña otro término (ej. Sitio Web, Aplicación Web, Servidor Web). Además existe otro término para referirse a servicios de computación a través de internet, denominado “la nube”, sin embargo, esta estaría dentro de la Web con un acceso controlado.

3. Contexto para profesionales administrativos e interesados (no técnicos)

Si bien partimos de un contexto tecnológico, nos enfocamos en lo concerniente a la acogida de la informática que apoya la gestión en negocios, organizaciones, o en proyectos, involucrando eventualmente a interesados de diversos perfiles.

Entre los campos de acción de la tecnología, una de los que demanda atención es el entorno empresarial o de negocios, siendo fundamental para el desarrollo de organizaciones que bien alcanzan una dimensión mayor cada día, o tienen una dinámica distinta a las organizaciones anteriores a la informática de nuestros tiempos. Con la globalización, o al menos, dado el alcance de interacción internacional del mundo actual ha sido determinante el desarrollo de la informática, y en particular la que se ha conocido como informática de gestión (aquella de nuestro interés y que se relaciona con la estrategia para los negocios).

Como la tecnología avanza cada día más, o se introducen nuevos elementos, el hombre comienza a designar términos, hablando así de cosas como la nueva era del conocimiendo, la computación en la nube, la hiper-mobilidad o hiper-conectividad, el “Big Data” con las bases de datos modernas, mas ¿qué tiene que ver eso con la mayoría de ocupaciones o alguien no técnico? En realidad la designación de los términos no interesa tanto como la comprensión de lo que sugiere y sus inicios, así que nada de motivos para ofuzcarse.

Hemos dicho que hablamos del campo que se ha conocido como informática de gestión, no estamos hablando de tecnología para videojuegos, ni de editores de medios o de contenido (gráficos, video o sonido), ni la que apoya las simulaciones de computación científica, la inteligencia artificial pura o la robótica, aunque lleguen incluso a relacionarse o generarse aportes entre tales campos.

Para ir aterrizando el contexto, podría decirse que la computación desarrollada con interés militar fué importante para el desarrollo científico (como influencia en América podríamos citar a la NASA), luego dío paso al apoyo en las finanzas, naciendo entonces la informática de gestión en las organizaciones y negocios, que fueron creciendo, mientras se incorporaban redes (cableado, aparatos y computadores destinados para establecer comunicación y acceso a la información) y se expandía el uso de Internet (que tuvo orígenes en un proyecto militar a finales de los sesenta), introduciéndose en los hogares en la década de los noventa con proveedores para este servicio (en inglés: ISP, de Internet Service Providers), generalmente compañías telefónicas de aquel momento prestaban el servicio. Por supuesto, esto daría paso al comercio electrónico, que se anexa a la informática de gestión en tanto se usen redes, infraestructura, datos y obviamente gestión.

Retomando un par de términos citados, cuando se habla de computación en la nube significa aprovechar el alcance actual de las redes a través de Internet con un mayor alcance o una dinámica que hace posible que desde un teléfono móvil o una tablet se gestionen actividades de negocio o se involucren contratistas, empleados, clientes, incluso procesos de trámites que dan lugar a la autogestión de un consumidor desde dónde se encuentre, por ejemplo, que un cliente solicite un servicio o que se gestione el pago o una compra desde su portátil a través de Internet. El modelo que impera consiste en servidores (que son computadores especializados y destinados para servir a otros, o para gestionar servicios) que se publican en un proveedor (salvo que se cuente con propia infraestructura) otorgándo presencia a través de Internet, generalmente de modo centralizado, para que los aparatos, computadores o dispositivos accedan a un servico, recurso u otro similar, usando además proveedores de telecomunicaciones actuales (proveedores de internet o ISP).

Por otra parte, viene bien retomar el término “Big Data”, puesto que es importante comprender primero que nuestro tema involucra tanto infraestructura (redes y otros) como el tratamiento o mecanismo para almacenar los datos. Antiguamente la información quedaba en papel y archivadores, luego surgieron paquetes de oficina con una herramienta de hoja de cálculo (como Microsoft Excel) y que frecuentemente es utilizada para soportar una base de listados de información (si bien, desde décadas atrás al contar con recurso técnico se usaba un lenguaje de programación para gestionar archivos de datos denominado COBOL, aún usado, por ejemplo en algunos cajeros automáticos), pero fueron las denominadas bases de datos relacionales que operan en red (o para ser precisos, motores de bases de datos fabricados por proveedores especilializados) las que almacenaban información cada vez mayor y que se acumulaba (podría asemejarse a un modo de organizar una biblioteca manualmente o los archivadores de documentos antiguamente) y que pueden usar un mecanismo estándar o lenguaje común para manejar la información (denominado lenguaje SQL, sumándose bases de datos NoSQL que se presentan como alternativa con su propio modo de operar sin requerir SQL).

Con este tipo de base de datos (o motores) los sistemas informáticos se desarrollan sin ocuparse en instancias o mecanismos cubiertos por tales herramientas y enfocándose en procesos o en el negocio que es sujeto de análisis, es decir, tales bases de datos (libres o de proveedores que las comercializan) resultan ser un componente de uso frecuente por los sistemas informáticos. Cuando llegaron las redes sociales (como Facebook y demás) u otras empresas de una dimensión global (por ejemplo, Bancos, Telefónicas, Gobiernos, etc.) el tamaño de información que llegaron a manejar dió lugar al término “Big Data” (“Big” significa grande en inglés). Se comprendería entonces que cuando se trata de una población inmensa de datos, o que se trata de información que abarca 50 estados (como en USA), o expansión de negocios en más de 2 o tres países, o tratamiento complejo con datos que comienzan a ser voluminosos, estaríamos hablando de “Big Data”. Si bien, actualmente OnMind quizás no sea el más ideal para proyectos de “Big Data”, salvo viabilidad en casos específicos, lo descrito nos da un panorama de comprensión y del alcance que se abordará mas adelante.

Ahora bien, bajo el contexto de proyectos con informática de gestión, se ha desarrollado la ingeniería de software, en el que uno de los factores primarios o fases se refiere al análisis. Quienes desempeñan el rol de analistas de sistemas o funcionales (generalmente ingenieros) utilizan diagramas y documentos para aterrizar dentro de un proyecto aquello que el cliente o usuario interno requiere para el sistema teniendo en cuenta un alcance. Podría decirse que tales documentos manifiestan en buena medida acuerdos entre las partes (equipo informático e interesados claves), y algunos otros que traen diagramas, incorporan lo que podría ser la analogía de los planos de un edificio, en cuyo caso el resultado sería la base de datos de un proyecto y el diseño del sistema informático que se comunica con la base de datos. Muchos formatos y diagramas son bien influenciados por la industria (las grandes corporaciones de tecnología) y han dado sus resultados en las últimas décadas, marcando una tendencia y logrando gran acogida. Sin embargo, aunque algunos diagramas pretenden ser comprensibles para un usuario o un interesado, en ocasiones pueden ofuzcar al usuario, o se cae en una saturación (exceso de diagramas, lo que demanda tiempo), sobretodo cuando corresponden a un nivel más técnico dirigido a profesionales del área de tecnología (tanto líderes como desarrolladores), claro está, con un fin distinto, el de conservar el conocimiento del producto o proyecto siendo un activo para la organización correspondiente (bien sea un proveedor de tecnología que parte de un producto propio, o una compañía que tiene su propia area de tecnológia con desarrollo en casa, incluso tercerización).

Dado el contexto, el método OnMind busca tanto simplicidad como agilidad en un punto apropiado para abordar proyectos de tecnología, podría ser más conveniente en escenarios menos estrictos ante lo convencional, con acogida y apertura a un modo renovador de hacer las cosas, o simplemente en proyectos por fases cortas (micro-proyectos) en una empresa sin importar el tamaño, siempre y cuando considere una visión organizacional.

4. Aspecto en torno a una gestión organizacional modesta

Por “modesta” se quiere indicar una manera, tanto panorámica como simplificada, de considerar aspectos de gestión para ser incluyentes con pequeños negocios que se proyectan con una visión organizacional. Sin importar el tamaño de la empresa, en orden a la prestación de un servicio o producto se pueden definir áreas, o al menos roles o proveedores que los cubren. Estas áreas o roles responden a diferentes focos para organizar y gestionar las empresas, por ejemplo: la dirección, ventas, servicio al cliente (la cual resulta importante que tenga su propia gestión), recursos humanos, área administrativa o financiera, tecnología, y si es el caso el área de producción. No obstante, esto puede cambiar si por ejemplo una empresa se visualiza bajo la gestión de proyectos donde las áreas o los recursos están a la disposición de gerentes de proyectos que pueden llegar a compartir los recursos (lo que se conoce como una oficina de gestion de proyectos o PMO, por la siglas en inglés de “Project Management Office”)

Tomando como referencia la influencia de la escuela clásica de la teoría de la organización y la gestión, Henri Fayol (1917) define el acto de administrar como un proceso compuesto por funciones indicando que “Administrar es pronosticar y planear, organizar, dirigir, coordinar y controlar”. Sumada la necesidad de comunicación y gestión de la información de las organizaciones, puede comprenderse la informática de gestión con una visión estratégica, en muchos casos también abarcadora, que brinda apoyo sobre dichos factores, por ejemplo, organizar, controlar, comunicar, gestionar, atender, servir, etc.

Lo que hace un analista o el miembro de un equipo de trabajo que aplique el método OnMind, sobre todo en cuestión de proyectos, es utilizar una serie de elementos y herramientas para lograr de modo ágil y simple un resultado en función de un proceso, producto o servicio dentro del contexto de nuestro interés. Entiéndase ágil y simple si se compara con otros modos de abordar proyectos estimados desde un año en adelante (o macro-proyectos de 3 años) y evítese confundir con cualquier sentido inmediatista que resulta fuera del contexto.

Aunque el método sugiere un aspecto técnico (incluso avanzado), es posible que entendiendo los principios exista un acercamiento para un trabajo interdisciplinario entre los interesados de un proyecto, sobre todo en las primeras instancias o instancias de análisis, además aprovechando que en la actualidad por cultura general las personas se han familiarizado en el uso de tecnologías informáticas de un modo u otro.

Se verá entonces, que si se usan mapas mentales (de conceptos) para ilustrar o comprender un asunto de interés entre las partes, se usen algunas veces prototipos de diseño visual (dibujos) sobre una aplicación (“app”), se realizan reuniones planeadas y se usa un tablero de tareas para un equipo de trabajo con metas y alcance bien definido, se estaría evidenciando una dinámica que opera en el ámbito de gestión y esto ha sido considerado por el método OnMind.

Un punto de referencia puede ser el menú de aplicaciones de la plataforma OnMind, se encuentra influenciado por una visión organizacional como podemos ver en sus categorías u opciones principales:

Gestión del Servicio
Operación del Negocio
Enfoques Específicos
Gestión Digital
Gestión Tecnológica
Gestión de OnMind

Por citar otro elemento, se tiene en cuenta la teoría japonesa denominada las “5S” en torno a la organización empresarial y la calidad en los procesos, incluso aplicada en la vida cotidiana: Seiri, Seiton, Seiso, Seiketsu, Shitsuke. Algo como clasificar, ordenar, limpiar, estandarizar o resolver anomalías, aplicar el hábito o disciplina. En realidad, al considerar en un asunto técnico otros elementos o el factor estratégico, se integran aspectos de gestión que se acogen en el método.

El método también se pronuncia en favor de la creatividad en proyectos que generalmente tienen algún factor de innovación, sin que esto sea motivo de excusa para quién no guste de trámites en absoluto. Esto se refiere a que el equipo de desarrollo debe gestionar sus actividades técnicas y en muchas organizaciones registros de calidad, normas que de algún modo pueden perder de vista lo esencial (en ocasiones tienen una tendencia a esforzarse para una certificación de calidad en una organización) cuando pueden buscarse otras maneras o simplificarse. La creatividad influye en la productividad y en últimas en la calidad, incluso en la confianza, propósito y sentido de pertenencia de los miembros creativos del equipo.

Es prudente tener presente, en la gestión humana en las organizaciones, aspectos como la creatividad de las personas (en este caso podría aplicarse al equipo del proyecto), hay quienes hablan de felicidad en el trabajo o compañía felíz, en últimas esto brinda un aporte en las buenas relaciones con los clientes y su fidelización (cuidar o proporcionar factores para la lealtad del cliente). No obstante, aterrizando esto a la realidad de la organización, aunque una compañía acoja este enfoque o pueda proporcionar lo mejor posible para ello, en la vida práctica no puede cubrir todo o tener el control de todo lo que corresponda en torno a los miembros del equipo, ni todo es su menester. Sin embargo, si se proporciona lo mejor que se pueda de su parte, conforme a la organización, estará en una dirección correcta.

De igual manera, si bien las mediciones e indicadores en procesos, proyectos, áreas, incluso evaluaciones de desempeño, podrían estar bien fundamentados por aquello de que “lo que no se puede medir no se puede controlar”, resulta importante que las organizaciones consideren que la realidad puede ser distinta en algún momento, es decir, muchas veces hay un exceso de indicadores y sobretodo se evade la idea de que no siempre todo se puede controlar, quizás sea el momento de un mejor enfoque orientado a indicadores claves y simples, incluso con un sentido humanista si así lo acoge la organización (por ejemplo: pensando en el talento humano), sin descuidar lo financiero.

Considero introducir aquí el término de “intuición” aplicado a la gestión, no estoy seguro si ya hay quien lo utilice oficialmente en la academia de los administradores de empresas, pero creo que finalmente en muchas situaciones los gerentes hacen uso de la intuición para tomar decisiones, como aspecto de liderazgo natural. Me atrevo incluso a ir un poco más allá, en pensar que si bien son relevantes los datos que arroje el mercado, una encuesta, unos indicadores, etc, le daría prioridad a la intuición quedando los anteriores bajo la tutela de esta o en un segundo lugar, teniendo aún su utilidad a la hora de tomar decisiones. Es de comprender que la intuición no se puede medir, se escapa a esquemas mentales y puede tener acogida en quién, lejos de cualquier esquema, tiene apertura y sensatez con su naturaleza de líder escuchando su voz interior.

5. Aspecto sobre proyectos ágiles de software de gestión

En realidad, el método plantea el uso de una herramienta, mejor aún, una plataforma (como ejemplo, el software OnMind) que brinde lo que se pretende catalogar como un “Entorno de Datos Orientado a la Misión” (“MODE”, que en inglés corresponde a “Management Oriented Data Environment”). Esto con el fin de tener una base para abordar proyectos de software en menor tiempo, lo cual confronta el hecho de que en muchas ocasiones se requiere dedicar 2 o 3 meses de planeación, mas si se considera que se aborda un asunto con alcance bien delimitado y específico, proyectos por fases cortas o micro-proyectos duran ese mismo tiempo. Si se trata de la puesta en marcha de un macro-proyecto o de una nueva empresa que se introduce al mercado requirientdo capacitar al personal para un despliege comercial, no es el caso apropiado de aplicación del método. Lo que se indica es que si se habla de micro-proyectos se puede tener una expectativa de que tome menos de 6 meses, mientras en otras escalas puede ser el tiempo invertido en planeación, guardando el hecho de que cada caso es cada caso, además al aplicarlo a la vida práctica, aunque se tenga una visión holística e integradora, no necesariamente un método resulta ser para todo.

Inspirándose en los fundamentos de las herramientas de proyectos ágiles, al apoyarse además en una plataforma, como OnMind, es altamente probable que se rescaten funciones disponibles, como la gestión de usuarios, su acceso y seguridad, algunos componentes, incluso posibilitar implementación de prototipos operables. Por citar un ejemplo, mientras que un proyecto desde cero puede invertirse entre 6 meses y 1 año en afinar un sistema o módulo de seguridad empresarial (si bien, continúa sujeto a mantenimiento), este sería un tiempo que se reduce si se aprovecha dicha plataforma, además de otros factores que brinda. En el caso del software OnMind, dada su estructura y enfoque alineado con el método, está diseñado para ser adecuado por medio de micro-proyectos o proyectos.

En otras palabras, un proyecto que generalmente toma más tiempo, puede ser abordado con el método OnMind y una herramienta que lo acompaña (o MODE, el cual abordaremos más adelante), así puede llegar a considerarse un proyecto de mayor dimensión (1 año o más) como uno para abordarse en menor tiempo de modo ágil. El tiempo es dinero, reducir el tiempo no necesariamente reduzca siempre los costos de modo sustancial, en muchos casos también se traduce como la oportunidad o beneficio que significa tener un servicio o producto a tiempo para la venta o para su uso.

Aunque el método no aborda la gestión de riesgos de un proyecto si considera que de modo práctico tiene que existir un riesgo tolerable, que ante una situación compleja se puede asumir o se considera en coherencia con la inversión, en cuanto menor sea la inversión, mayor será la tolerancia. Por otra parte, dado que se consideran iteraciones e instancias (o micro-fases en orden al desarrollo del software), en la medida que avancemos en el texto, si se mencionará el riesgo de invertir tiempo en iteraciones o asumir un par de días en prototipos operables, también con el riesgo de cambios al requerimiento. En este sentido, se debe estimar un porcentaje en mantenimiento debido a las iteraciones que lo introducen en la marcha (por ejemplo, el 20%) y un tiempo mínimo para ejecución de micro-proyectos (por ejemplo, 1 mes y medio con el costo que ello implica), así como considerar como número máximo de iteraciones de revisión con el cliente el límite de 3 (tres).

Las partes deben ser conscientes que la alteración del alcance altera el compromiso de entrega y es menester cuidarlo, como existe un anticipo (cuando es tercerizado) el equipo del proyecto esperaría hasta la entrega para cubrir el monto del proyecto (salvo otra consideración), de igual manera los interesados claves (o el cliente) generalmente están aguardando el evento de entrega de modo que puede generar afectación en ambas partes. Ahora bien, si se dilata demasiado (superando las iteraciones máximas de revisión con el cliente) es signo de alerta y determinación de un alcance inamovible para el micro-proyecto (o fase corta), o de algo de una dimensión mayor que debía haberse considerado, en cuyos casos generalmente no se reporta a tiempo. Tal revisión también podría dar lugar a una renegociación que puede impactar también el presupuesto del proyecto. Este es un riesgo que se corre al abordar un proyecto en menor tiempo contemplando algunas validaciones en la marcha que dan claridad sobre la necesidad del cliente o sobre la orientación del micro-proyecto con la intención de una entrega satisfactoria.

6. Aspecto de análisis y diseño de sistemas de información (A&D)

Cuando se trata de diseñar sistemas informáticos con bases de datos (en muchos casos relacionales o tipo SQL) se comprende que el modo convencional tiene su aplicación y acogida en razón de que es lo conocido en la formación académica del profesional informático y en las empresas. Repensar o confrontar ello requiere de una mente abierta y de la acogida que quizás encuentre apoyo con la introducción de las bases de datos NoSQL (siendo alternativa o complemento a aquellas que usan el lenguaje SQL). Se advierte que aquí estamos abordando un tema que nos remite a aspectos técnicos, aunque algunos conceptos pueden resultar novedosos en términos generales.

Existe anexo sobre Enfoques para Programar

He preparado un artículo separado (en el enlace de arriba) donde se expone un enfoque y panorama con los criterios sobre los elementos técnicos que se requieren para producir software. Allí se habla un poco sobre cómo logra un equipo formado apoyar los procesos administrativos y comerciales con tecnología aplicable a nuestros días (lenguajes de programación, arquitectura para la web y aplicaciones móviles entre otras características).

Las etapas del desarrollo de software

Simplemente decir que el proceso de fabricación de software puede tener algunas etapas que varían según su aplicación específica. Por lo pronto podemos pensar en un Dianóstico (o análisis preliminar), Análisis y Diseño, Codificación, Pruebas, Despliegue y Mantenimiento (o transición a un nuevo ciclo o proyecto), además de la documentación que puede ser funcional (como la ayuda o guías) o técnica, y puede irse ejecutando de menor a mayor medida hasta la liberación del software. Éstas pueden aplicarse a un proyecto o a un requerimiento del cliente o usuario, semejante a lo que puede ser considerado un “micro-proyecto”.

Introducción de Arquetipos

Situándonos en el análisis y diseño, con el método OnMind se llegan a introducir arquetipos, entendidos como categorías significativas identificadas por la observación de sistemas y conceptos, en última instancia super-clases o tablas grandes, de modo que en lugar de aprender lo que se conoce como normalización o sobre como relacionar tablas (o colecciones), se establecen los arquetipos y se busca con la capacidad de abstracción del analista que un objeto se identifique con el mejor arquetipo al que se ajusta, las relaciones definidas serán de tipo gerarquico entre arquetipos, e incluso consigo mismos.

Mientras en un modelo tradicional un sistema significativamente grande supera 1000 tablas (objetos o colecciones), los arquetipos propuestos por el autor de OnMind para su propia plataforma son menos de 40, los cuales se asemejan a las clases de objetos o super-colecciones de datos, o simplemente tablas internas del repositorio). La introducción de algunos arquetipos nos lleva a comprender que un analista informático puede llegar a observar algunos patrones, conceptos que siempre están en el fondo de un asunto o se repiten al momento de aplicar la abstracción de la realidad del mundo a un sistema informático. Mientras las bases de datos relacionales promueven infinidad de posibilidades de objetos (colecciones o tablas), con sus relaciones o interrelaciones posibles, con los arquetipos se puede llegar a reducir dramáticamente.

No obstante, las posibilidades pueden tambien ser numerosas cuando se aplican los arquetipos a las colecciones del usuario (que se verían como algo virtual respecto al repositorio persistente). En palabras más sofisticadas, cuando se habla de arquetipos es pensar en clases mas no en objetos, pues estos últimos se definirían por configuración o de modo virtual (dinámico). Tales objetos (que terminan siendo simplemente una fila de datos) preferimos llamarlos una fabricación, de modo que podría decirse que se hacen fabricaciones mentales de ideas específicas (arquetipos), o si se quiere ver de otro modo se refieren principalmente a hojas de datos.

Una manera de ilustrar lo que se consigue con arquetipos, es que llega a ser posible introducir a un recurso interesado sin estudios superiores (sólo con la escuela secundaria) sobre arquetipos bien definidos, como si en el sentido figurado simplemente se aprende las tablas de multiplicar (los arquetipos), en lugar de que tenga una base de conocimiento sobre conjuntos, fundamentos informáticos formales, bases de datos relacionales y análisis de sistemas o ingeniería de software. A nivel de herramienta, la plataforma OnMind propone sus propios arquetipos internos para su repositorio.

Los arquetipos definidos para OnMind son esencialmente 10: Identidades, Participantes, Círculos, Entorno, Cosas, Entradas, Actividades, Resumen, Operaciones y Extra

Dados los arquetipos esenciales, se identifica en la realidad de un asunto o proceso, cual de estos encaja de la mejor manera, como si fueran modelos específicos que reiterativamente pueden ser observados en el mundo, al menos con una visión analítica más simple. Mientras la academia tradicional te induce a identificar objetos en el mundo que resultan numerosos, con la propuesta del método OnMind se concluye que tales objetos no deberían ser muy diferentes de los arquetipos esenciales y por tanto no se definirían los objetos del modo convencional sino dentro o como parte de los arquetipos, esas partes serían las fabricaciones que pueden interpretarse también como hojas de datos. Por supuesto, que si se necesita una mejor distribución se pueden alcanzar alrededor de 40 tablas o colecciones de datos según la implementación, pero los fundamentos se repiten. Otra manera de comprender los arquetipos es pensar en cómo se ha inspirado el autor:

En un mundo o contexto de ideas e ilusiones mentales surgen fabricaciones mentales. Esto se refleja en los sistemas y en lo que se proyecte. Estas fabricaciones se vinculan con identidades. No todas las identidades participan activamente, de allí que se distinguen los participantes. Además, las identidades pueden conformar círculos de vínculos, estos pueden interpretarse como roles naturales de las identidades en un contexto. Luego, tenemos el entorno y las cosas que distinguimos de un modo distinto a las identidades, refiriéndonos incluso a conceptos o asuntos. Surgen procesos donde se requieren entradas o solicitudes que usualmente generan alguna actividad (o su suporte). Dado que este mundo está altamente influido por el aspecto financiero, tendremos resumenes de cuentas y sus operaciones. En cuanto algo sea altamente específico o requiera mayor detalle, se puede decir que hay cosas extraordinarias y complementarias (extra). Este es el fundamento de un análisis bajo mi óptica, de allí que lo participe como un método, quizás con algunas añadiduras.

Arquetipos y su Gerarquía

Para dar un ejemplo, pensemos en un arquetipo denominado “Contacto” (o identidad) y en un segundo denominado “Usuario” (o particpante), si los contactos se refieren a la información de cualquier persona (bien sea cliente, empleado, proveedor, contratista, suscriptor, etc.) y los usuarios son aquellos que tienen interacción directa con el sistema (cuentas, roles, miembros con perfil de suscripción, etc.), entonces el arquetipo “Contacto” tiene un nivel de gerarquía mayor que el arquetipo “Usuario”, el cual se asocia a uno de los contactos del arquetipo “Contacto”. Se establece una relación gerarquica en la que el “Contacto” se denota primero que el “Usuario” y se asocia al usuario, incluso si un usuario no tuviese contacto asociado en un instante dado. Al hablar de relaciones gerarquicas lo que se quiere indicar es que no se necesitan expresar relaciones muchos a muchos aunque existiesen, se busca evitar expresar la dualidad de padre y madre (o diversos padres) con un hijo o muchos hijos, por tanto, se expresa una sóla relación principal, la más definida o más fuerte.

Como segundo ejemplo, visualicemos el formato de una factura, la cual tiene encabezado y detalle, y sobre el cual nos referiremos como cargos. Existe una gerarquía bien definida en la que el encabezado de la factura tiene prelación sobre los cargos, los cuales a su vez se asocian al encabezado de la factura. Tanto el encabezado como los cargos tienen un identificador único, al menos internamente (esto sigue siendo como se ha conocido). Ahora bien, podemos haber definido un arquetipo “Resumen” para catalogar todo documento o encabezado y un arquetipo “Operaciones” para ser asignado a cualquier tipo de cargo o concepto de detalle. En tanto se simplifiquen los arquetipos, que también se pueden ver como objetos persistentes, se reduce algo, bien sea gestión o eventos en una implementación.

En efecto, las relaciones no expresadas en tanto sólo se expresa la principal, deben ser compensadas por medio de codificación de programas informáticos y mecanismos cómo índices. Esto da mayor importancia y referencia frecuente a un diccionario de datos (dónde se presenta cada estructura o arquetipo detallando la información posible con sus características), que si se ha comprendido bien, consistiría en describir un número menor de tablas o colecciones de datos.

Podría verse entonces como si se aprendieran o consultaran las tablas de multiplicar en un orden.

Diagramas aplicables

Los arquetipos y las relaciones gerarquicas son fundamento para el análisis y diseño bajo el método OnMind. Los diagramas que dan razón de estos criterios pueden ser gerarquicos al estilo de un organigarma, o un arbol, mapa conceptual, grafos o similares, siempre y cuando proporcione una disposición visual apropiada que exprese las gerarquías bien definidas (de mayor a menor). Existen herramientas que ya están desarrolladas para este propósito.

Para efectos de la fase de análisis, incluso en un diagnóstico preliminar, se introduce el uso de mapas mentales (o de conceptos) siendo aplicables para clarificar el escenario o caso, o el panorama de los requerimientos del micro-proyecto con una visión holística y de contexto. La idea de centrar un análisis con mapas mentales en lugar de flujos de procesos fué tomando forma mientras asistía a clases de filosofía y preparaba los exámenes con este tipo de ayudas, además de observar como se encuentra organizado nuestro universo. Como ingeniero recordaba que se asemejaban a diagramas de contexto (usados en metodologías de análisis propuestas hace décadas y que pueden tener su vigencia) mas se distinguen en que no se requieren ni pautas sobre sistemas, ni niveles. Cuando las herramientas de mapas mentales (digitales) mejoraban, ví una oportunidad de aplicabilidad de algo simplificado, así como actualmente se usan otro tipo de herramientas como “Business Process Managment” (BPM, el cual traduce gestión de procesos del negocio) que se centra en flujo de procesos y que requiere de un concocimiento técnico (un rol y una notación denominada BPMN). Se estima que quien ha sido introducido en mapas mentales en cuestión de minutos (teniendo capacidad de abstracción y catalogación) o un estudiante de práctica (sin importar su carrera) que ha preparado sus exámenes con este tipo de herramientas visuales, estaría apto para comprender lo que un analista quiere visualizar o validar.

Dado que se trata de un análisis más expontáneo, sí se requiere de la orientación o fundamentos técnicos del analista para dar un enfoque influenciado ligeramente por un objetivo de aplicación tecnológica, sin olvidar que lo que se hace es validar la comprensión de un escenario práctico.

Sobre bases de datos

En ningún momento se restringe que se aplique esto sobre un tipo de base de datos, bien sea SQL o NoSQL, dando acogida a ambas categorías, si bien, en función de conceptualización los objetos derivados de arquetipos se pueden expresar como clases o tablas al estilo de una base de datos SQL para ser homologables con estas, puesto que por el contrario, si se trata de una base de datos NoSQL cuya colección compuesta (por ejemplo, cuando se almacena en la misma colección encabezado y detalle) se exprese en JSON no resulta ser legible para bases de datos SQL de gran uso en las organizaciones. En cuanto a bases de datos NoSQL, resultan ser más compatibles las que tienen un lenguaje cercano al SQL, por ejemplo Cassandra. Además, en tanto los arquetipos terminan siendo tablas grandes en una organización pueden tener un buen redimiento con mecanismos de bases de datos de almacenamiento por columnas.

Apoyo en herramienta catalogada como MODE

Introduciendo la idea de usar una plataforma catalogada como MODE (“Management Oriented Data Environment”, o gestor de datos orientada a la misión), se podría comprender entonces que mientras un BPM se centra en procesos utilizando diagramas con su notación (BPMN) y requiere recurso técnico o calificado, un MODE usa simplemente árboles o mapas mentales con un sentido holístico (o panorámico) y en cuanto al nivel de datos se centra en arquetipos bien definidos. Con un BPM se representan flujos de trabajo o procesos, mientras con un MODE es posible de modo simplificado usando un atributo de un arquetipo para procesos posibilitando flujos de trabajo sin requerir esta notación (sin BPMN). Si bien, ambos plantean reducción en la implementación de código y en tiempo, en algunos casos podría verse como un sustituto o alternativa al otro, quizás en otros casos se logren complementar más no sería asunto del método. El principal aporte, de nuestro enfoque en este punto, es ofrecer una perspectiva simplificada con apertura a recursos sin mayor experiencia y a interesados claves dentro de un equipo interdisciplinario, como bien se ha indicado, no se requiere conocer de diagramas de flujo ni notaciones ni lo que se deriva de ello, sólo capacidad de abstracción de conceptos claves aplicables a un escenario o caso.

En cuanto al uso de arquetipos del método OnMind en un MODE, se puede lograr una reducción mayor en el código que con un diseño de datos convencional, sobretodo si es posible que en algunos casos se logren aplicar prototipos operables (es decir, que pueden correr bajo un estándar con algunas funciones disponibles). Tales prototipos operables no necesariamente son fruto de la plataforma en sí, sino que surgen de especificaciones (spec) para su implementación (es decir, que se desarrollan) partiendo del estándar y marco de trabajo interno (librerías o API) que promueva el MODE, aunque tratándose de la plataforma OnMind se cuenta también con una herramienta apropiada.

Existe anexo sobre Especificaciones Frontales

7. ¿Qué se considera y qué no hace parte del método OnMind? (Alcance)

Introducirnos en el alcance implica una base de conocimiento de tipo técnico, agradecemos acogida o comprensión para aquellos interesados de otras disciplinas. El método OnMind reune algunas prácticas tomando elementos ya existentes, algunos coincidieron con lo que se pensó plantear mientras se ideaba el método (por ejemplo, el autor no concocía en un principio sobre bases de datos NoSQL, que resultaron ser afines en sus fundamentos con el método), y otros elementos que se integran o son el factor que posibilita agilizar proyectos con OnMind (se piensa incluso en una herramienta que en la actualidad complementa al método). A continuación veamos qué ha inspirado o coincidido con el método OnMind y se incorpora a modo de aspectos y herramientas.

Mapas mentales. Los mapas mentales son un estilo de diagrama que da una visión del contexto sobre algo conectando ideas, deben ser enfocados con los criterios técnicos fundamentales, así como los de gestión sin aislarse de que representa un concepto en sí. Son simplemente una manera de abstraer algo con un sentido y evidentemente requieren tal habilidad de asimilación y abstracción digna de un profesional o casi cualquier persona aunque se trate de algo general (no necesariamente detallado), por tanto, puede ser más sencillo para un trabajo interdisciplinario o de acceso con menor barrera de comprensión por profesionales de disciplinas distintas a las tecnológicas.
Tablero de Tareas. En términos generales, consiste en una ayuda visual que puede ofrecer un panorama de la actividad requerida para un recurso o equipo, con un estado. A modo de ejemplo, existe el tablero Kanban, derivado o parte de un sistema inventado por Toyota, en dónde las tarjetas Kanban o el tablero específicamente se remite a una manera de gestionar tareas teniendo en cuenta una carga de trabajo y unos estados para la entrega de algo con la premisa justo a tiempo (JIT). Quien conozca la metodología “Scrum” en la que se incorpora un tablero similar, podría usarse en un método OnMind ampliado o personalizado, sin embargo, OnMind en su simplicidad no requiere “Scrum” ni “Kanban”, tan sólo un tablero, dejándolo a gusto del equipo o de la organización.
Uso de “markdown” para documentar. Markdown es un estilo de escritura que usa convenciones para producir textos que pueden ser publicados como artículos digitales o en una página de internet con una apariencia agradable. Siendo sofisticados, es un lenguaje de marcado y su primer o principal caso de uso fue en correos electrónicos, en dónde escribiendo texto plano con algunas convenciones podía traducirse al lenguaje de los navegadores o clientes de correo (en HTML). En la última década ha venido teniendo acogida siendo actualmente tendencia para escribir artículos, incluso libros, o un blog en Internet. El método OnMind propone usar “markdown” para documentar, para ello existen incluso editores libres o gratuitos. En la medida en que se implemente el uso de documentos con esta convención, se puede disminuir progresivamente la dependencia a los procesadores de palabras y se obtiene una mejor integración con otros sistemas, que bien pueden subsistir en tanto aún se requiera para documentos comerciales y sobretodo cuando no se trata de algo digital. Puedes encontrar una guía esencial de Markdown en nuestro sitio, así como también contar con un editor sencillo incorporado en la plataforma OnMind.

Bases de datos con menor restricción referencial. Esta es una cuestión de detalle técnico que no debe implicar mayor impacto en los resultados de un sistema con el alcance para aplicar nuestro método, ni requiere mayor atención por interesados no técnicos. Como ejemplo, nuestro propio producto denominado OnMind (como el método) promueve su propia implementación sobre un motor de base de datos, o bien, usa un repositorio de datos (con pseudo-modelo o meta-modelo, es decir un modelo interno) que no necesariamente implementa los mecanismos de las bases de datos SQL (ni una normalización estricta), mas bien, aprovecha las bases de datos SQL evitando lo innecesario para el modelo interno del repositorio. Podría decirse que se inspira o concuerda con tecnologias ya existentes (por ejemplo, Motor de base de datos MyISAM, Aria o MyRocks en MySQL o MariaDB, así como bases de datos NoSQL) en tanto no impone la implementación de relaciones persistentes o restricción de llaves foráneas, sin embargo, para efecto de transacciones se puede dar preferencia a bases de datos SQL (por ejemplo, Oracle, o al motor InnoDB en MySQL/MariaDB). El repositorio de nuestro producto OnMind implementa un esquema o estructura propio, más a su vez puede tener modelos sin estructura fija, simulando una de las características de las bases de da datos NoSQL, o mas bien, acoje y mezcla caracteríticas tanto de estructura de una base de datos SQL para su modelo interno, como de NoSQL para las colecciones o tablas derivadas. Evidentemente, si una restricción no se aplica en la base de datos debe revisarse si se implementa validación a nivel de código, esto no es muy distinto de cuando se validan mensajes personalizados para el usuario en los que igualmente se ha requerido el uso de código aunque se trate de una base de datos con restricción referencial.
Uso de Arquetipos y Gerarquías (con diagramas gerarquicos). Este punto se ha abordado anteriormente bajo el título “Aspecto de análisis y diseño de sistemas de información” y es uno de los principales aportes del método OnMind. La introducción de algunos arquetipos con sus gerarquías nos lleva a comprender que un analista informático puede llegar a observar algunos patrones, conceptos que siempre están en el fondo de un asunto o se repiten al momento de aplicar la abstracción del mundo observable a un sistema informático. El método considera que transmitir unos arquetipos definidos con relaciones gerarquicas puede ser más digirible por un recurso empírico que el análisis y diseño conocido o convencional. A nivel de herramienta, la plataforma OnMind propone sus propios arquetipos internos para su repositorio. Quizás para algunos, la idea de un repositorio con arquetipos resulte cercana a un “DataMart” usado en bodegas de datos (Data Wharehouse) pero mínimo y operable. Por otra parte, un diagrama gerarquico resulta apropiado para representar graficamente los arquetipos con sus gerarquías. Estos diagramas pueden asemejarse a un mapa mental en tanto se trata de arboles, sin embargo, la disposición visual es distinta semejante a la organización de carpetas de un gestor de archivos (como Finder, Explorer, etc.). El motivo de evitar imponer relaciones persistentes en las bases de datos, es pensar a cambio en relaciones gerarquicas (de un padre a un hijo sin lugar a otras relaciones, es decir, aunque existan no se denotan), por tanto no se requiere un diagrama entidad relacion e incluso puede resultar inapropiado. Evidentemente, al hablar de relaciones gerarquicas implica que sólo aplica una relación, la más significativa, cualquier otra que se observe no queda reportada a la base de datos.
UML de modo opcional y al mínimo. Un interesado, bien sea técnico o recurso sin estudios superiores (sólo con la escuela secundaria) no necesita ni se espera que conozca sobre los diagramas propuestos bajo UML (“Unified Modeling Language”, que traduce Lenguaje de Modelamiento Unificado), mas bien, puede ser introducido en mapas mentales y diagramas gerarquicos, de allí que se propone que el uso de UML sea opcional. De modo que si no eres informático o no son familiares estos diagramas para ti no necesitas revisar este punto. En la actualidad los diagramas UML son un estándar en la industria del software y cubren diversos aspectos, sin embargo, el método OnMind los considera en casos específicos. Por ejemplo, los casos de uso pueden ser de uso común en requerimientos, mientras el diagrama de secuencias sólo se admite cuando es estrictamente necesario por tratarse de procesos complejos y bien específicos, que ameritan su aporte como base de conocimiento sobre el producto. El diagrama de clases puede usarse si ya es costumbre en una organización, sólo que para el método OnMind representaría algo virtual o aún más abstracto, puesto que las relaciones se pueden expresar con un diagrama gerarquico descrito anteriormente, en definitiva es opcional. Podría decirse entonces, que se amite UML al mínimo, básicamente para casos de uso y de modo opcional, así como el diagrama de secuencias u otro eventualmente para situaciones bién específicas. Cuando no se aplican casos de usos, puede usarse un formato de levantamiento de requerimientos clásico o uno libre que no impone uso de dibujos ni UML.
Uso de tecnologías con afinidad empresarial, para la nube y digital. Lo que se quiere indicar aquí es que tratándose de datos e infraestructura es preferible tecnologías que den razón de ello, mínimo máquinas virtuales (o similares, ejemplo: docker, kubernetes) en adelante. Por tanto, dado el enfoque empresarial se excluye alojamiento web convencional (o el “hosting” común para sitios web), o bien, se remite a proyectos en la nube o plataformas de software factor que influye y da pauta para la arquitectura del proyecto, considerando además procesamiento o computo al admitirse procesos (en lote u otros). En cuanto a lo digital, se considera que se piense cada vez menos en reportes orientados para la impresión en papel, relevando su uso para dar prioridad a un enfoque digital, pensando por ejemplo en dispositivos móviles. Para dar un ejemplo de uso de tecnologías con afinidad empresarial, la plataforma de software OnMind utiliza el entorno Node.js y la máquina virtual de Java (JVM programando con Kotlin), tanto Node.js como Java no funcionan en un “hosting web” común, sino a partir de máquinas virtuales o servicios enfocados en estas tecnologías, es el mismo caso con .Net, Go y en muchos casos con Python, en realidad, la mayoría de lenguajes de aplicación empresarial. Podría parecer que esto implique que se descarte un lenguaje como PHP que frecuentemente acompaña el alojamiento web convencional y con gran acogida en marketing digital (además de tener también propósitos para software de gestión), mas lo que se quiere indicar es que aquello que no se trata de computación en la nube no hace parte de proyectos que se aborden con el método OnMind (puesto que se apoya en una plataforma para la nube y considera abordar procesos o servicios que implican capacidad de computo), siendo así, si se usa PHP instalándose en una máquina y se logran sistemas igualmente funcionales que tengan acogida empresarial, queda en últimas sujeto a las libertades de un proyecto y al conocimiento del equipo de trabajo.
Las “5S” japonesas aplicadas en la calidad. Se tiene en cuenta la teoría japonesa en torno a la organización empresarial y la calidad en los procesos denominada las “5S”: Seiri, Seiton, Seiso, Seiketsu, Shitsuke, algo como clasificar, ordenar, limpiar, estandarizar o resolver anomalías, aplicar el hábito o disciplina (en inglés se pueden representar como: sort, set, shine, standardise, sustain). En una visión amplia es un asunto transversal, puesto que esta teoría puede aplicarse a los puestos de trabajo, a una oficina, incluso a la vida cotidiana. En cuanto a nuestro interés, en lo referente a la calidad del software se acoge aplicandolo con expresiones compuestas, así: separar innecesarios (clasificación y descarte), situar necesarios (orden), suprimir obsoletos (limpieza), seguir estándar (estandarizar o resolver anomalías), supervisar compromiso en función de servicio y/o producto (disciplina).
Camino simple para pruebas o punto de revisión. Si estamos tratando de simplificar o admitir proyectos ágiles de modo coherente, algunas exigencias deberían ser menores teniendo en cuenta un menor alcance o duración, es decir, así como en un proyecto grande se invierte gran tiempo en planificar y en la calidad del servicio o producto para una dimensión mayor, en uno ágil podría considerarse una dimensión menor, o aprobarse un alcance y si se requiere un nivel de mayor exigencia dar lugar a tercerización de pruebas (gestión adicional con otro proveedor, incluso especializado). Conforme al equipo de trabajo o la tecnología, debe definirse el camino más sencillo para pruebas, es decir, si se implementan pruebas a nivel de código por parte del desarrollador o se usan listas de chequeo, las cuales han tenido acogida a través de los años para verificación de actividades en general. Si por ejemplo, programar pruebas unitarias significa un aporte para la automatización del proceso de desarrollo o implementar robots se traduce en verdadero apoyo, es claro que ese sería el camino, de lo contrario se pueden considerar perfectamente listas de chequeo, o un simple punto de revisión que indique si la funcionalidad cumple con el requerimiento o no. El método OnMind se pronuncia en favor de la simplicidad, productividad y la creatividad en el software, si fuera necesario podría considerarse la práctica de programación en pares, o bien, que un recurso con el rol técnico realice una verificación a otro de rol apropiado dentro del equipo de trabajo. El método OnMind también da apertura a incorporar recurso introducido o con experiencia sin un título universitario (sólo con la escuela secundaria), así podría designarse un auxiliar para la función de pruebas unitarias de los programas codificados por los desarrolladores expertos, o bien, hacer verificación con una lista de chequeo. El hecho de que otro haga dichas pruebas implica un punto de vista distinto que sugiere control y el desarrollador continúa disfrutando de creatividad o de lo que mejor designa su función logrando mejor productividad. Además, así se resalta que la creatividad y productividad influyen en la calidad. No necesariamente el uso de listas es algo excluyente, también podría considerarse algo mixto, por ejemplo, que según la sensibilidad de una función, algunas veces se implementen pruebas de unidad con código y en los demás casos un punto de revisión que indique si la funcionalidad cumple con el planteamiento del requerimiento (con un sí o un no general, dado el caso alguna observación). Por otra parte, si se exigen otro tipo de pruebas especializadas, como por ejemplo de penetración por vulnerabilidades al exponer un servicio a través de Internet, debería considerarse como un factor adicional que apunta a una tercerización, es decir, dejar esto a un experto en el tema y revisar si se incluye en el alcance por medio de subcontratación o simplemente se está atento conforme al soporte respectivo, esto último tiene más coherencia con un método ágil si se comprende una entrega del desarrollo cómo un hito sin especialidades. Por otra parte, el cliente o usuario estaría invitado a recibir la entrega haciendo su propia validación o tener un contratista para esto, siendo partícipe del punto de revisión.
Apoyarse en una plataforma como OnMind o un MODE (que posibilita prototipos operables). Introducimos las siglas MODE, que en inglés corresponde a “Management Oriented Data Environment”, y traduce “Entorno de Datos Orientado a la Misión” (o Gestión). ¿Qúe es un MODE? Un MODE sería la categoría para una plataforma en la nube que se superpone al sistema operativo, incluso a un entorno o plataforma de programación (por ejemplo, Node.js, la máquina virtual de Java, o .Net), e incorpora aspectos de gestor o adaptador de bases de datos internamente (por ejemplo, a través de una API), mejor aún, un repositorio que se basa en arquetipos, brindando además funciones (componentes) o algunos servicios (por ejemplo, la gestión de usuarios y otros) que pueden ser útiles para adecuar nuevas funciones sin invertir el tiempo que requiere un desarrollo desde cero. Dadas sus facultadas, es posible en cerca de la mitad de los casos (o más) la implementación (codificación) de prototipos operables (páginas o pantallas que pueden funcionar hasta cierto punto) para brindar una noción mejor de lo que se está haciendo. No obstante, esto podría alcanzarse por alguna herramienta existente en el mercado, de allí que la diferencia más significativa es que se fundamenta en el método OnMind, siendo diseñada para apoyar su aplicación.

Resumiendo el aporte de OnMind, se tiene en el fondo un sentido integrador y unificador, en cierta medida holístico, considera la intuición en la gestión y el riesgo tolerable, busca cierta simplicidad o al menos menor complejidad, se puede observar el concepto de arquetipos y sus gerarquías, plantea un repositorio que posibilita un gestor o adaptador de base de datos, o bien, un MODE que posibilite prototipos operables basados en una especificación (de una fabricación de arquetipos), además es un factor de innovación el hecho de incorporar el uso de mapas mentales para simplificar el análisis. Está pensado para admitir micro-proyectos o desarrollos de un profesional autónomo o “freelance” (reforzandose la validación de la entrega por parte del cliente), pasando a equipos de trabajo y compañías que dan acogida o simpatizan con los elementos y fundamentos que se proponen (y que bien pueden personalizarse o adaptarse).

De otro modo, podemos citar generalidades de lo que no hace parte del método OnMind, así:

Las bases de datos relacionales sugieren la necesidad de cierto diagrama (de entidad-relacion o DER), en tanto en el análisis y diseño bajo el método OnMind no se impone la restricción referencial o relaciones persistentes, dando apertura de acogida a bases de datos NoSQL (o motores como Aria o MyRocks) y promoviendo el uso de diagramás gerarquicos para relaciones, el uso de diagramas convencionales para la representación de la base de datos es innecesario e inapropiado en algunos casos, no obstante, puede ser factible y homologable el uso de diagramas entidad relación dada una costumbre, dificultad ante un cambio de mentalidad, o simplemente por alguna necesidad.
Los diagramas UML no son prioridad para OnMind, tampoco se descartan del todo considerando eventualmente su uso.
El método de OnMind nace para proyectos modernos y en la nube, con infraestructura, descartando tecnologías de menor alcance, por ejemplo, lo que se conoce como alojamiento web convencional (o hosting web) no se considera computación en la nube, si bien tiene su aplicación y acogida para un enfoque distinto.
Dando apertura, no se impone la plataforma de software OnMind, si bien, se promueve dado que se encuentra alineada y ha dado lugar al método (además de ser el primer MODE).
En tanto se da preferencia o se centra el análisis utilizando mapas mentales (con herramientas que ya están desarrolladas) y un MODE (Entorno de Datos Orientado a la Misión o Gestión), no se requieren otro tipo de herramientas o tecnologías como “Business Process Management” (BPM, que traduce “Gestión de Procesos de Negocio”). Principalmente, no se requiere notación para flujos de trabajo (o BPMN) en tanto el método busca conservar una mayor simplicidad y sentido interdisciplinario al respecto de este asunto. Este punto ya ha sido tratado bajo el título “Aspecto de análisis y diseño de sistemas de información (A&D)”.
Ningún tipo de certificación tradicional hace parte del método OnMind, siendo algo libre de acoger por efectos de una calidad notable o reconocida en contextos convencionales. En este sentido, lo que pretende el método es reducir barreras, tampoco se trata de eliminarlas completamente pues en un asunto técnico alguna barrera puede admitirse.

8. ¿Cómo interactúan los elementos o cómo se aplica el método?

Para referirnos a proyectos ágiles, bien sean micro-proyectos o proyectos por fases cortas, el alcance debe ser bien definido para dar razón de un entregable concreto, por ejemplo, por requerimiento o necesidad específica. También estaríamos hablando de un ciclo de menor prolongación de tiempo (o duración) aunque sus instancias sean varias, y si es el caso con iteraciones, bien sea por motivo de mantenimiento o para continuar con otra fase (o micro-proyecto siguiente). Sin ser estrictos (por ejemplo, con el análisis) Se considera dentro del ciclo instancias o aspectos como:

Análisis del escenario, usando mapas mentales descritos con anterioridad como facilitador (no obligatorio).
Definición del requerimiento. Esto se refiere a documentación concreta y simple, opcionalmente con casos de uso (UML), y de ser necesario, con diagnóstico preliminar, considerando evaluar si se notifica una estimación espontánea o previa (indicando tiempo y monto preliminar) dada una experiencia, unicamente en función de dar una noción al cliente y dejando claro esto.
Diseño, influenciado en últimas por arquetipos con relaciones gerarquicas. Opcionalmente, si es el caso, usar prototipos de pantallas (aún mejor si se tratan de prototipos que se pueden operar hasta cierto punto, algo así como funcionalidades “dummys” que requieren alguna codificación anticipada, o si se cuenta con la plataforma OnMind que posibilita implementar estos prototipos operables).
Reunión(es) de seguimiento o revisión. Pueden ser varias y estar acompañadas por un acta que soporta cambios al requerimiento, o bien, con una estimación definida o pactada, así como una fecha de compromiso de entrega. Se admiten teleconferencias.
Codificación. Incluye verificación del desarrollo y actualización de documentación técnica, mejor si se apoya en algo existente que se aproveche, como la plataforma OnMind o lo que se promueve como MODE (un entorno de datos orientado a la gestión).
Pruebas funcionales (y actualización de documentación funcional).
Entrega. Incluye registro documental o acta (simple y concreta, orientada a tareas o compromisos, además de anotaciones que inciden en el alcance), de ser el caso digital o una grabación en audio, y recepción o validación del cliente.

A nivel del equipo de trabajo, se revisa la planificación de los recursos aterrizando individualmente las tareas (con el tablero Kanban o similar) y se da una noción del trabajo del otro cuando se relaciona con el trabajo en equipo, por lo cual se da lugar a reuniones, recomendando mínimo 1 semanal. En cuanto a reuniones con interesados distintos al equipo de trabajo, pueden llegar a ser tan frecuentes como se avancen o se necesiten, por lo que es importante contar con interesados claves que influyen y disponen de espacio para el evento de este tipo de reuniones. Finalmente, las reuniones con interesados claves generalmente influyen en la frecuencia de las reuniones con el equipo de trabajo, así como en aplazamientos válidos dada nuevas decisiones o cambios en el alcance original, teniendo también presente que generalmente puede impactar el monto original de un proyecto.

Planteemos el siguiente ejemplo: Un laboratorio farmaceútico requiere brindar a sus visitadores médicos (el personal que promueve los productos médicos y está relacionado con el profesional de la salud) que el reporte de una visita a un médico sea por medio digital, dando evolución o formalización de su actividad desde cualquier sitio que tenga acceso a Internet (datos móviles, wifi, etc.). Para facilidad del ejercicio, no se incorporan otros aspectos (por citar, la ruta o agenda de visitas, ni un calendario), sin embargo, se estaría admitiendo el uso de dispositivos móviles para posibilitar que el visitador médico haga el reporte de visitas desde el sitio, o desde la comodidad de su hogar al terminar su jornada (o ruta), si así lo desea. La información que se reporta es la fecha, el turno que corresponde al orden de atención en el día (puede ser sin turno o un número, máximo 20), médico al que visita, dirección y un detalle de productos acogidos (de multiple selección o incorporación). Esta información se recibe en una reunión con el cliente dando su aprobación para invertir en el proyecto a modo de una prueba piloto en la que se pacta un 50% de anticipo para su ejecución inmediata en tanto se tenga la estimación definitiva.

Basicamente, lo que se está indicando es registrar un evento con unos datos específicos que se originan en torno a las visitas que se hacen a los médicos. Se deduce que para dar lugar a un formato digital de visita deberían gestionarse primero tanto productos como médicos con su información (por ejemplo, la dirección del médico). Se podría validar con el cliente (o interesados claves) si se admite que cuando se hace visita no programada, se use como turno el cero (0) para indicar que es sin turno.

Si observamos, dada la sencillez del caso ya tenemos una definición del requerimiento que no amerita ni siquiera un análisis con mapas mentales (salvo que se desee tener visualmente el contexto y concepto para los miembros de un equipo o interesados cuando alguno no comprende el asunto).

Para la instacia de diseño, si contamos con la plataforma OnMind, es posible aprovechar su repositorio con arquetipos reutilizables o que dan razón de algunos elementos. Por ejemplo, si se tiene un arquetipo “Contactos” podríamos aprovecharlo para la información de un médico, y si se tiene arquetipo “Items” podríamos a provecharlo para la información de los productos. Con la plataforma OnMind se puede implementar un directorio para los Médicos, se contaría con la gestión de productos, los usuarios de los visitadores (podría evaluarse también un directorio para visitadores) y además podría definirse un formato que se puede acondicionar con la aplicación de atención de solicitudes, en este caso, la solicitud es un evento o visita. Si bien, requiere algún punto de código y sobretodo definición en el repositorio (configuración requerido y documentada, o “scripts” entregables), con la plataforma OnMind es posible presentar el prototipo operable para una reunión de revisión mas o menos en 3 días de disponibilidad (incluso en 1 día, si bien, con pruducencia y detalle puede ser 1 semana).

Una vez revisado el prototipo se pueden estimar detalles y reportarse para la instancia de codificación. Cuando se invierte más tiempo en un prototipo operable es posible avanzar en estos casos sencillos, validándolo o probándolo casi como un entregable, sin embargo se corre el riesgo de perder algún día, si en la revisión se toma otro rumbo. Cuando existen iteraciones, si es poco el tiempo en riesgo, esto es inversión en la validación del producto que aporta a la calidad. El líder del equipo del proyecto, o mejor aún, quien gestiona la relación con el cliente debe determinar si es viable, por ejemplo, invertir a riesgo hasta 2 días en 1 recurso (esto podría variar si viene trabajando con el cliente y se conoce su proceder o nivel de acogida) para la elaboración del prototipo o simplemente revisar si se reporta la estimación para que se tome la decisión y poder continuar.

Si se identificó alguna novedad en reunión con los interesados claves (o el cliente), se codifica además de documentar tanto técnicamente y funcionalmente (actualizando o revisando manuales quien tenga dicha función). En las pruebas se puede hacer devolución a la instancia de codificación, incluso dar lugar a una nueva reunión de revisión. Con las pruebas exitosas, si el prototipo se entregó en 3 días con pocas observaciones, al continuar con el desarrollo y las pruebas terminan siendo 2 días más (en el mejor de los casos), tendríamos en una semana laboral nuestro entregable si todo resulta de un modo ideal. Para considerar escenarios más complejos con procesos u otros factores que implican mayor codificación, un micro-proyecto podría tener un tiempo prudente de entrega, por ejemplo, mínimo mes y medio para un recurso, que sigue siendo un tiempo menor respecto a otros proyectos.

Sin importar el tiempo para entregar proyectos, igual se puede pactar un monto de proyecto indistintamente del tiempo, bien sea que resulte a favor o en contra, salvo que se admiten aplazamientos válidos en el métido, puesto que es distinto si el alcance se dilata o se identifica algo que genera impacto o prolonga el proyecto y que debía reportarse desde el principio, o cuando es fruto de una reunión de revisión que genera una nueva iteración dada alguna decisión que plantea otro rumbo (o alcance). Siendo así, si se toma como base menos de un mes y medio, se podrían estimar proyectos con un monto mínimo correspondiente a mes y medio, considerando que la herramienta brinda un beneficio de oportunidad por menor tiempo o el número de recursos es mayor a uno (1), cuando se trata de un equipo de trabajo, o más de un (1) recurso, además por un porcentaje de reserva en soporte o transición (es decir, nuevas iteraciones que se deben estimar, por ejemplo con el 20% del tiempo reportado). No obstante, esto ya es un asunto de costos y estimación de proyectos que se menciona en torno al contexto del método pero no corresponde a su dinámica.

En efecto, si resulta un escenario o caso que no se logra soportar o aprovechar, por ejemplo, cuando se estiman más de 6 meses, es probable que deba abordarse con una metodología distinta, incluso una diferente a las ágiles, en cuyo caso es altamente probable que dicho proyecto se acerque al año (es decir, mucho más de 6 meses). Esto se identifica según la experiencia.

En resumen, existen unas instancias (o micro-fases) para abordar el escenario de un micro-proyecto, el cual se aborda tan pronto como se pueda a partir de un evento o reunión inicial encaminada y en la que se da el aval para iniciar algo concreto (el analisis y la definición del requerimiento o requerimientos) y en términos generales pactando un porcentaje inicial para anticipo (no se está hablando hasta aquí de un monto), puede verse como una orden de ejecución del proyecto contando así con un acta de inicio. En tanto sea viable un diseño con prototipos operables, en la siguiente reunión se validan requisitos y alcance, para lo cual es prudente tener preparado un diagnóstico en el que pueda reportarse una estimación con la fecha de compromiso de entrega de no variar el alcance. Con la aprobación y el pago inicial se programan las actividades y reunión siguiente, así hasta el evento de entrega.

9. Sobre la herramienta de gestión de OnMind (del mismo Autor)

El proyecto original que data desde 2014 (aunque recogió la visión de un recorrido personal 2 décadas atrás) fué denominado igualmente OnMind. Se encuentra en el contexto de producir aplicaciones dónde se involucran datos (o infraestructura tecnológica), dando lugar para acogida de diversos campos y empresas, como valor agregado …

OnMind, más que una herramienta moderna de apoyo para la gestión o de colaboración, es una plataforma adaptable para encender ideas de negocio con una experiencia digital.

En contexto, alojamos y creamos “apps” o proyectos donde intervienen actividades de negocios, internet y dispositivos móviles. Nuestra plataforma es multi-propósito, las ideas nos llevan a lo específico, adaptando la plataforma bajo micro-proyectos. Siendo sofisticados, la catalogamos como “Entorno de Datos Orientado a la Misión” (o Gestión), con las siglas MODE.

Se podría pensar como un sistema operable para la nube con un paquete de aplicaciones para negocios y la oficina.

¿Qué hace que un software sea catalogado como MODE?

Sobre la base de un sistema (como Linux) se vincula nuestra plataforma con la cual puedes gestionar tu servicio o procedimientos, es decir, es posible integrar y orquestar actividad de negocio, principalmente si se opera a través de internet y se usan dispositivos móviles.

Un MODE brinda un nivel nuevo al aprovechar algunas características de un sistema operativo para servidores (máquinas o computadores especializados) inspirándose en la nube, si bien puede operar en una red local. Además nuestro MODE está pensado para soportar proyectos alineándose con el método OnMind. En otras palabras, un complemento o herramienta para el método es contar con un “Entorno de Datos Orientado a la Misión” (MODE) como la plataforma OnMind.

A su vez, la principal característica de un MODE es seguir y apoyar el método OnMind (basándose en arquetipos y posibilitando prototipos operables que pueden correr bajo un estándar con algunas funciones disponibles), lo cual genera un impacto técnico y cambio de mentalidad en el diseño o modelo de datos de la plataforma o entorno de datos. Como aspecto secundario, sería contar con una serie de funciones disponibles como base para facilitar un avance ágil en el desarrollo de software, pero puede exitir en el mercado otra herramienta que hace algo semejante, por lo que no sería una característica definitiva para catalogar un software como MODE.

Es por esto que un MODE no pretende ser un sustituto absoluto sino una propuesta alterna que obtiene acogida en una visión y mentalidad abierta, con una capa técnica superpuesta a un sistema operativo de servidores que opera en la nube para facilitar su operación. En un sentido idealista, esto también podría traducirse en una mejor vida para quienes operen una plataforma, tanto roles técnicos como funcionales o de gestión.

Otras características del MODE de OnMind

Se podría pensar como un sistema operable para la nube con un paquete de aplicaciones para negocios y la oficina.

Tenemos nuestro repertorio de aplicaciones, las que mejor nos distinguen son la de “atención de solicitudes” (CRM) y el “publicador de web privada” (para documentación digital o textos), además aplicaciones para tu negocio que puedes encontrar en nuestra tienda según plan.

Como premisas, nuestra plataforma es multi-propósito, consiste en una base producida (entre 2015 y enero de 2020), tiene un repertorio de aplicaciones, un estandar visual, componentes web, existen funcionalidades dinámicas, componentes configurables o parametrizables, se basa en esquemas o modelos aplicados, formatos o formularios pueden consistir en definiciones y disposiciones de diseño establecido gracias a la plataforma.

Con nuestra plataforma o MODE, basicamente requieres acceso a Internet y un navegador, o nuestra “app” OnMind-AVE (opcional para la Nube). Puedes consultar en detalle las características técnicas en el sitio: https://onmind.co/go/app/land.html#/info

Gracias por leer

https://onmind.co