Christian A. Estay-Niculcar's research blog

Espacio de reflexión personal dedicado a la investigación aplicada cuando se vincula la ciencia proyectual con la disciplina informática, y se aplican al desarrollo de las personas y de la gestión empresarial.

Information Systems Philosophy: ¿Cómo modelar sistemas para insertarlos en organizaciones? una visión sistémica orgánico-estructural para una deconstrucción pensada en usuarios y operadores (2010)

Esta nota tiene que ver con el proceder para identificar sistemas desde una óptica sistémica.

a. ASPECTOS TEÓRICOS Y CONCEPTUALES DEL MODELAMIENTO

Hablar de modelamiento es no un acto baladí. Es un intento de resumir y sintetizar un gran espectro de opiniones y desarrollos en muchos campos. La lingüística quien aporta su dominio del análisis de las estructuras de las lenguas y que en un modelamiento resulta esencial para comprender el sentido de lo que se dice y se pretende representar con un modelo. La sicología, la sociología y la antropología para comprender el sentido de lo que hacen las personas, entiendo la expresión “lo que hacen” en un sentido tan amplio como el estar haciendo cosas como las cosas que se producen del estar haciendo.

Aparte están las disciplinas con su propio acerbo de sentidos a las cosas y a los conceptos y aquí el mejor ejemplo es el concepto de ‘sistema’: cada disciplina y autor le ha definido de una manera u otra, siempre similares, pero iguales. Con esto el modelamiento de un sistema se torna complejo del momento mismo que quien pretende modelar tiene sus propias percepciones del entorno y sobre ese entorno fuerza a aplicar su concepto de sistema para intentar ‘ver un sistema’.

Si a esto sumamos que la palabra modelamiento contiene su propio conflicto al preguntarnos qué es un modelo, la complejidad del acto de modelar, el modelamiento es más que claro. Un modelo se define de muchas maneras y pretender quedarse con una definición es tan arriesgado como necesario pues impone un sentido pero no todos los sentidos. Ahora bien, qué se modela es otra cuestión. Se pretende modelar lo que un observador vé, “el modelador”, pero el modelador solamente “ve” lo que sus sentidos le permiten percibir de la realidad circundante, lo que sus principios y creencias le permiten aceptar cómo válido, y lo que su propio lenguaje le permite dar una expresión. Por ende, lo modelado es la interpretación de una persona. Pero cómo se interpreta todo, pues con una herramienta que tiene el modelador, su lenguaje. Así se llega al claro ejemplo de decir: “cuéntame lo que has visto”, lo cual tiene como resultado una narración. Del momento que esta narración se expresa se tiene un modelo, una visión de algo. Por ende, la realidad expresada no es la realidad “real” sin la realidad que el modelador proyecta a través del lenguaje que use para expresar su realidad percibida.

Pero, cuando el modelo se expresa de una manera distinta, aparecen los diagramas. Los diagramas son dos cosas al mismo tiempo: por un lado es un lenguaje con unos símbolos claramente especificados y una gramática o reglas de operación sobre sus símbolos; y, por otro lado, están los resultados de aplicar el diagrama o sus instancias que son ni más ni menos que las representaciones, esos dibujos o esquemas visuales que las personas usan para comunicarse. Las instancias de los diagramas (que en el uso diario entre personas les ha llevado a llamarse diagramas, por ejemplo “muéstrame el diagrama”), los esquemas siempre serán expresiones visuales del modelo de alguien surgido de aplicar las reglas y los símbolos de un diagrama (muy teóricamente llamado un lenguaje diagramático). Aquí surge otro problema, similar al que ocurre cuando uno habla, si no domina todas las palabras (símbolos) y las reglas gramaticales (las reglas), no podrá expresar toda la realidad que cree percibir. Esta discusión no puede concluirse sin dejar de mencionar que si lo observado no existe en la mente del observador, no podrá expresarlo. Al unir todos estos problemas se comprende bien cuando dice o escucha expresiones como: “no tengo palabras para decirlo” o “no sé cómo contarte esto”.

Un elemento adicional a este proceder es que el proceso observar en sí mismo posee o se detecta que posee una dimensión activa, pues conforme el observador observa una realidad, al mismo tiempo redefine sus propias percepciones conforme aprende de la propia observación de su proceso de observación y de la realidad que el mismo va definiendo y define. Así, queda claro que un observador o modelador, al final de sus observaciones posee una interpretación distinta a la que tenía inicialmente y por se comprende que muchos diagramas son la mejor expresión de un observador o modelador en un momento de comprensión de la realidad, o, que es lo mismo, en un momento del análisis de la realidad, de comprender y entender la realidad.

En ingeniería, -por ejemplo- en general, los esquemas son los “dibujos de los ingenieros”, sus planos, sus maquetas visuales, sus esquemas de ingeniería, o simplemente sus “croquis”. Cada uno de estos esquemas es el resultado del pensamiento de un ingeniero que obrando como observador de una realidad ha proyectado su imagen del mundo presente o su imagen de un mundo deseado o futuro a través de un diagrama lo cual ha dado lugar a esquemas.

Desgraciadamente, los diagramas tienen una gran fortaleza y una gran debilidad. Su gran fortaleza es que poseen pocos símbolos y unas reglas muy precisas (pocas) que permiten expresar de manera muy simple y reducida, gran cantidad de información sin grandes incertezas de las interpretaciones que se puedan hacer del esquema resultante. Su gran debilidad, es que la simplicidad a nivel de símbolos y reglas solamente expresa ciertos aspectos de la realidad del modelador. Así, por ende, el modelador requerirá muchos tipos de diagramas para poder expresar los diversos tipos de dimensiones o aspectos de la realidad que los diagramas permiten expresar. No se trata de que la realidad esté sesgada en dimensiones, sino que la realidad es sesgada por los tipos de diagramas que el modelador maneja. Esto se entiende mejor al poner el siguiente ejemplo: una persona que sólo habla un idioma, por ejemplo, el castellano podrá con suerte y buen dominio expresar determinados fenómenos, pero si domina otro idioma, podrá ampliar su espectro de realidad observada al recurrir a más palabras y reglas de expresión.

Llegado a este punto de esta elaboración  conceptual del proceso de modelamiento, ya es claro que el modelamiento de un sistema demanda control y dominio de muchos factores.

Nuevamente volviendo al espacio de la Ingeniería hay que ver cuáles serían los diagramas  ideales para expresar la realidad que interesa a cada ingeniería en particular. En este sentido se pasará al espacio de la Ingeniería de Software o de la Ingeniería Informática como paso previo al análisis y diseño de sistemas y de requerimientos.

b. SISTEMAS, SUS ORGANIZACIONES Y SUS ESTRUCTURAS

b.1. Distinguiendo y justificando sistemas

Uno de los temas más difíciles es identificar un sistema. Ya se ha visto que la identificación de un sistema es el resultado de un proceso de distinción influenciado por la capacidad de un observador de distinguir cosas. Por ejemplo, ¿cómo podemos ver las fronteras de un sistema? En un sistema orgánico como un león, podemos decir que su frontera es la piel que lo recubre, en un sistema ideológico la frontera está determinada por la adherencia o no a una ideología, en un sistema artificial como una máquina la frontera se determina por la “carcaza” o “cáscara” de la capa, en un sistema artificial organizacional como el departamento de una empresa la frontera se determina por las paredes y funciones de un departamento organizacional …. pero las fronteras de un sistema que sea una cadena de valor empresarial, o las fronteras de un sistema social global … aquí se torna más difícil estas distinciones. De manera análoga, los componentes de un sistema varían. ¿Cuáles son los componentes de un sistema cuerpo-humano? Las venas, los órganos, las células, o las diferentes emociones que le dan forma.

Curiosamente, esta cosa que parece compleja, en el día-a-día está resuelta. Nadie se detiene a pensar si “mis” fronteras son “tus” fronteras. Similarmente a nivel de componentes. Parece ser que todos nos entendemos en el día-a-día. Por suerte funciona así, pero cuando no es así surgen conflictos muy complejos. Y aquí aparecen otros elementos importantes de un sistema: finalidad, objetivos, homeostasis, autopoiesis, entre otros conceptos.

Diversos autores han intentado definir estos conceptos y a pesar de que todos convergen hacia enunciados similares, y a un uso más o menos homogéneo (pues nadie se pregunta si la finalidad de algo es igual o parecida a los objetivos), a nivel de consecuencias puede variar. Por ejemplo, el para qué sirve un sistema arma-de-fuego, varía desde muchas cosas: para matar personas, para practicar deportes, para martillar objetos con su culata, o simplemente para ornamentar un living. Al entrar en detalles, vemos los conceptos más aplicados al caso de un rifle:

  • Finalidad: mostrar poder;
  • Objetivo: arrojar objetos a alta velocidad;
  • Retroalimentación: no existe sin un usuario u operador que lo alimente y mantenga continuamente; y,
  • Autopoiesis: pues no existe pues no se puede reproducir de sus propias componentes.

Debe aclararse que todo lo anterior es cuestionable, pero interesa comprender el fenómeno de distinción de un sistema y por supuesto justificarlo. Ya vemos que no basta con tener la capacidad de “verlo” o distinguirlo, sino de justificarlo.

Por justificación se entenderá que el sistema identificado o distinguido cumple determinados conceptos que lo caracterizan. Antes se pusieron 4 conceptos, pero ni son estos todos, ni son todos los que se manejan.

Ya se notará que el sistema arma-de-fuego para muchos es un sistema mecánico, automático o mejor dicho artificial o no-natural en muchos aspectos, pero es cierto que al poner la autopoiesis como un concepto que define un sistema, el sistema arma-de-fuego queda excluido como sistema. Bueno, este es otro problema de los sistemas … que no existe un cuerpo coherente de conceptos que los caractericen plenamente, sólo parcialmente. La autopoiesis es un concepto introducido en la historia del pensamiento de sistemas para sistemas capaces de evolucionar.

Aquí debemos detenernos pues ya se ha planteado el problema de distinguir y definir un sistema y como se aprecia pues ser extenuante intentar caracterizarlo y además resolverlo. Para efectos presentes, esta discusión se centrará en dar los elementos básicos para analizar y diseñar un sistema.

b.2. La justificación de un sistema.

Justificante 1: El objetivo. Un sistema se justifica cuando se le ha asignado capacidad de tener un objetivo, pero con el cuidado de saber que siempre el objetivo es asignado por el observador. Sobre esto, dos apreciaciones:

  • Se dice que un sistema posee objetivo asignado ‘externamente’ por un observador es porque, en un sistema natural –por ejemplo, un ecosistema o un animal-, nadie sabe cual es su finalidad, sino lo que dicen los biólogos que entienden y comprenden podría ser su objetivo. En un sistema artificial social -como una cultura-, el objetivo de una cultura está dado por la opinión que le cabe dar al antropólogo que la haya estudiado y no exactamente lo que quieran decirle o no los miembros de la cultura. En un sistema artificial máquina –por ejemplo, un motor-, el objetivo está dado el ingeniero que lo diseño.
  • Se dice que debe tenerse cuidado al asignar un objetivo es porque siempre un observador lingüísticamente pobre y/o con poca experiencia, sólo podrá comprender un sistema y su objetivo desde un limitado campo de visión o de opciones. Recordar que toda persona se proyecta en función de su historia pasada, su legado genético y sus aportaciones al futuro que sea capaz de generar.

Asumiendo un observador sin limitantes ni muchos prejuicios que sesguen sus puntos de vistas y sus observaciones, un sistema siempre tendrá un objetivo que surge de la mente de alguien. Por tanto, el primer justificante del sistema es su objetivo claro y bien definido. Esto va atado a su finalidad, entendida como el fin –último una vez conseguidos sus objetivos.

Justificante 2: La frontera. Lo otro importante son las fronteras del sistema. Las fronteras dicen lo que “está dentro y está fuera del sistema”. Pero ¿qué está dentro y qué está fuera? Sin entrar en posibles neologismos de las diversas corrientes de pensamiento, se dará una delimitante simple basada en dos preguntas:

  • ¿qué debe controlar el sistema?; y,
  • ¿qué puede controlar el sistema?.

Al combinar las respuestas a estas preguntas, surgen 4 respuestas:

  • Estará dentro del sistema todo aquello que debe controlar el sistema y puede controlarlo. Por ejemplo, los niveles de stock de un sistema de producción.
  • Estará fuera del sistema todo aquello que no debe controlar y no puede controlar y pasan a ser parte del entorno o medio externo al sistema. Cabe destacar que hoy en día, no existen cuasi estas interacciones que pueden llamarse nulas, pues todo de una manera u otra manera, una produce un efecto en otra. Por ejemplo, las discusiones familiares de los trabajadores no pueden controlarse ni deben controlarse.
  • Estará en la frontera todo aquello que debe controlar pero no puede controlar y por dando debe influir para procurar hacerlo con interacciones de salida hacia el entorno que es donde se encuentran esas elementos que deben controlarse pero no se puede. Por ejemplo, los niveles de stress laboral derivados de crisis económicas globales.
  • Estará en la frontera todo aquello que no debe controlar pero si controla. En estos casos se toman decisiones de frontera, de si debe dejar dentro o fuera del sistema, pues los elementos involucrados en este caso pueden ser parte de “otros sistemas”. Por ejemplo, la influencia de los salarios de sus empleados en el IPC económico de un país.
  • Existe un quinto aspecto, aquello que puede controlar al sistema pero no se desea ni se puede controlar internamente. En este caso se habla de una interacción que afecta al sistema. Por ejemplo, medidas legislativas que afectan al sistema pero no tiene mucha injerencia.

Cabe destacar que la determinación de una frontera es una decisión, no es una realidad tangible. Variará en función de intereses y necesidades y recursos. Se puede hacer el ejemplo de tomar cada ejemplo añadido en los puntos de la lista previa y cambiarlos de un punto a otro y observar los cambios que se producen. Lo importante es justificarla siempre con solidez bajo las preguntas formuladas.

Justificante 3: Las interacciones. Este es uno de los temas más complejos. ¿Cuáles son y donde están las interacciones? Ya “ver” un sistema es complejo, pero ver las interacciones lo son más. Por ejemplo, las fronteras de un sistema máquina son relativamente sencillas de determinar, pero las interacciones físicas entre sus piezas o partes no lo son tanto. A nivel de sistemas sociales, se puede citar el ejemplo de la interacción socio-económica del dinero entre las personas.

Para dilucidar este asunto conviene centrarse en la naturaleza del sistema.

El sistema no existe, lo define un observador, un modelador. Puede ser que exista antes de que el modelador observe una realidad o no. En este momento, cuando se define o se identifica, el modelador debe distinguir sus partes y las interacciones entre las partes y entre las partes y el entorno. Pero esto siempre lo hace a un nivel abstracto, basado en los conceptos y en el lenguaje que le permiten identificar partes e interacciones.

En este nivel de observación el sistema es una concepción mental. Nada más.

b.3. Interacciones entre sistemas y estructuras.

Como concepción mental, todo sistema tiene un referente material en el mundo físico o más concreto que el de las ideas, o aún así, en el de las ideas en concreto. Aquí aparecen las estructuras o en otras palabras, las constituciones materiales que darán cuerpo y forma a las partes y a las interacciones. El problema con esta visión conceptual, es que muchas veces se confunde la estructura con el sistema.

Por ejemplo, si alguien piensa en un sistema de información contable, elucubra procesos transacciones e interacciones numéricas que finalmente permiten consolidar determinados datos en –por ejemplo- un balance. Pero luego, cada empresa y cada país aportan toda una estructura material que aporta responsables de procesos y leyes y normas sobre las interacciones numéricas.

Otro ejemplo, es pensar en el sistema arma-de-fuego, pues si se desea pensar en un sistema que dañe personas a distancia, las soluciones estructurales van desde contratar personas para hacerlo hasta enviar un misil teledirigido. Serán las limitantes estructurales las que dirán que un “rifle” será la más económica, la “más posible” o simplemente la factible. Con el tiempo, este rifle evolucionará y será más efectivo, más eficiente y más eficaz. Cuando esta evolución ocurre, se dice que el sistema se mantiene pero su estructura evoluciona.

Si es cierto, cuando la estructura evoluciona de tal manera que cambia el objetivo del sistema, el sistema será quien evolucione.

Por tanto, al observar un sistema, lo primero es ver cuales cosas determinan al sistema y cuales simplemente son aspectos estructurales a tener presente en el presente, pero no necesariamente en el futuro.

La innovación es una observación de la realidad proponiendo sistemas nuevos, sistemas en nuevos usos a través de la mejora de estructura o de nuevos componentes y materiales estructurales.

c. PRODUCTOS INFORMÁTICOS EN UN CONTEXTO ORGANIZACIONAL.

En general un producto informático alude a un conjunto de componentes de diverso tipo:

  • Un software que responde a una necesidad de resolver una cuestión;
  • Un Hardware donde opera el software; y,
  • Un Peopleware o personas que operarán Software y Hardware, por ejemplo usuarios o “mantenedores”.

Existe una versión especial de producto informático donde no existen todos componentes previos, sino más bien son sistemas humanos al 100% operando según ciertas reglas (que algunos se atreven a denominar el software social) y con ciertos artefactos no computacionales como máquinas o simples escritorios (pero que es hardware igualmente). Esta percepción ideal de un producto informático no automatizado es válida para lo que procede en este documento.

Todos ellos son elementos estructurales de un sistema cuya misión es tratar con información (en unos casos para tomar decisiones, en otros para procesar datos), y además son los elementos disponibles para dar forma al sistema, no necesariamente son los deseados, pero si los posibles y que satisfacen los requerimientos del sistema.

Aquí surge el real conflicto informático… construir un sistema a un nivel abstracto y conceptual pero luego construir materialmente una estructura que sea bien recibida por la estructura de otros sistemas relacionados y con la estructura del propio entorno.

En una empresa, una organización de actividad-humana, el producto informático, como sistema debe insertarse estructuralmente en la estructura del sistema empresa.

c.1. La inserción estructural

Parte inherente del modelado es estudiar la capacidad de que el producto informático sea aceptado, admitido y asimilado por una organización. No es raro escuchar casos de excelentes sistemas técnicos rechazados o pobremente usados por los usuarios por motivos que incluso no son técnicos, sino inclusive de feeling al software recibido o por rechazo al trabajo del Departamento de Sistemas.

Es misión del modelador prever estas circunstancias, motivo por el cual el modelado demanda una comprensión organizacional muy clara y profunda de la realidad organizacional tanto a nivel sistemas y procesos, como de personas y cultura organizacional, y todo dentro de una estrategia organizacional y una estrategia de desarrollo informático.

Por lo tanto, el modelamiento debe considerar todos los componentes sistémicos en la forma de funciones y tareas a cumplir y proveer de manera tanto automatizada como no-automatizada pero, al mismo tiempo, sabiendo que habrán interacciones con un medio que no espera siempre “con buenos ojos” un nuevo actor organizacional. Estas interacciones se suelen asociar a interacciones del tipo: extraer datos o capturar información de usuarios, no obstante hay interacciones no inmediatas, sino mediatas, como los tomadores de decisiones que no siempre son usuarios del sistema, pero si agentes involucrados en la existencia del sistema o en su ciclo de vida. Por supuesto, hay tomadores de decisiones en interacción directa e inmediata con el sistema.

Visto de esta manera, el modelador debe realizar decisiones de índole esencial a la existencia de su producto informático o sistema informático (más en concreto). Se trata de que las funciones y tareas que haya previsto se deban realizar pero aún de una manera abstracta y alejada de la realidad (coloquialmente “en el papel”) deben pensarse y situarse en una estructura concreta. Así aparecen actores y agentes “de carne y hueso” que deben entrenarse, seleccionarse o eliminarse para que el sistema “funcione” y sea aceptado.  Cabe destacar que esto, por supuesto, incluye decisiones tanto sobre los tipos de servidores a utilizar y su relación con las redes existentes y servidores existentes, como de los tipos de interfaces a emplear tanto de hardware como de software y su compatibilidad con estándares aceptados organizacionalmente y con la cultura organizacional de uso que impere.

En términos de un desarrollo informático tradicional, el modelador es una persona que concibe un sistema integrado a una realidad organizacional que no debe dañar sino hacerla mejor y al mismo tiempo una persona que se preocupa de que todo “encaje” con los recursos existentes. En el primer caso, se habla del analista, en el segundo caso, del diseñador.

Conforme esto se haga de manera muy completa y coherente, el sistema será insertado estructuralmente en una organización receptora.

c.2. La de-construcción organizacional

No puede dejarse de lado un asunto muy importante. Todo producto informático, desde el momento que se concibe altera la organización que será su receptora. Por este motivo se observa que un analista que realiza el llamado análisis de la situación actual –por ejemplo mediante entrevistas- para conocer la realidad actual de una organización, “descubra” que cuando termina de hacer su estudio, la organización no era la misma y de hecho asimiló cosas derivadas del estudio que realizaba y de su presencia cuando entrevistaba personas. Por eso este análisis de situación actual debe hacerse con cuidado para evitar incurrir en este fenómeno o aceptarlo y aprovecharlo. Este mismo proceso se repite y es más obvio cuando se está realizando el análisis del sistema nuevo. En este último caso es más normal que la organización receptora ya esté “pensando” en que llegará un nuevo actor a su realidad.

En todo este proceso los conceptos se re-hacen producto de nuevas visiones y usos de las cosas, las concepciones del trabajo tal cómo se hace transmutan conforme aparecen nuevas formas de trabajo cada vez más automatizadas, los centros de decisión se movilizan hacia nuevos puntos de toma de decisiones y al mismo tiempo se posicionan cambiando los ejes del poder organizacional, y, por supuesto, las personas ven variar su entorno y por ende su concepción de la organización y de sus modos de trabajo. Todo esto se conoce como un proceso de deconstrucción que surge porque los conceptos varían producto de la historia del desarrollo del producto informático desde sus fases de análisis y diseño, y por la introducción y aparición de metáforas organizacionales nuevas que de una u otra manera enriquecen y cambian el lenguaje organizacional. Sobre esto último, se puede citar un ejemplo cuasi cotidiano hoy en día y es que muchas bromas organizacionales hoy en día recurren a conceptos computacionales, cosa que hace unas décadas atrás era impensable, o simplemente se explican situaciones con términos informatizados como cuando antes se hablaba de procesos secuenciales y ahora se habla de procesos batch.

c.3. La última palabra la tiene el usuario

Una frase muy recurrida dice que cualquier esfuerzo de analizar y diseñar no sirve de nada si el usuario no acepta el producto.

Pero hay que tener cuidado pues el análisis y el diseño involucra pensar en las personas que trabajarán y se verán afectadas por un producto informático. Es en casos muy particulares cuando no hay intervención humana en un sistema cualquiera. Pero no confundir con la errada percepción de minimizar el trabajo de análisis y diseño por proceder a construir un sistema rápido y luego “veremos” en el camino.

El usuario, por otra parte, no es una figura metafórica que “nada sabe”. Esta figura “nada sabe” de los artilugios y gadgets introducidos en un sistema y además de manera natural precisa ser entrenado en una nueva herramienta que muchas veces no espera ni desea tener ni usar. La analogía es muy simple: si se construye en un coche hay que pensar en la ergonomía del asiento de conductor y en las bondades de una acústica adecuada para que alguien use el coche, si no, el “el coche no sirve”. Inclusive bajando costes, puede ser que un coche no sea usado. Lo mismo ocurre con un sistema o producto informático.

Hay muchos roles o perfiles definidos pero se abordará a continuación una tipología general que termina distinguiendo usuarios, operadores y clientes.

Sobre tipos de usuarios, podemos distinguir dos grandes tipos:

  • Los usuarios como tal que “usan” un artefacto. En este caso, se tiene al usuario que simplemente interactúa aportando datos y/o recibiendo datos, pero en ningún momento garantiza ni le preocupa cómo opera el sistema ni que le esté pasando en su interior. Otros usuarios son los tomadores de decisiones que pueden o no interactuar con el sistema pero que reciben principalmente datos y los someten a un análisis personal para decidir acciones.
  • Los operadores que permiten que un artefacto opere de manera normal. En este caso se cuenta con los –por así llamarlos- operarios de mantenimiento, operarios de uso que revisan el comportamiento del sistema a nivel
    • de sus variables de operacionales (que miden su rendimiento, tiempos de respuestas, deadlock, entre otros procesos y comportamiento) y para este caso los operarios son profesionales de la computación;
    • de sus variables funcionales (que miden la capacidad de atender y satisfacer los requerimientos que justifican el sistema, como por ejemplo, cantidad de procesos consultados de cierto tipo) y  para este caso los operarios son profesionales de la informática; y,
    • de sus variables estratégicas (que analizan la existencia del sistema dentro de los procesos estratégicos de la empresa) y para este caso los operarios son directivos del ámbito de la informática.

La literatura reporta más variedad de tipos de usuarios y tipos de operadores, pero lo más importante es distinguir ambas dimensiones de interacción.

Por último está el cliente que es quien financia/paga el desarrollo, puede ser usuario y/u operador o no ocupar posición alguna. En cualquier caso, el cliente suele ser el más importante de todos estos roles o perfiles.

Y como corolario … para desarrollar productos hay que estar a la escucha de las personas, de los clientes y de la sociedad en su conjunto.

___________________________________________
Estas ideas la puse en un reciente apunte que diseñé y colaboré en su contenido llamado Análisis y Diseño Integral de Sistemas y Requerimientos, cuya referencia es:

  • Saurith, Arleth; y, Estay-Niculcar, Christian. (2010). Análisis y Diseño Integral de Sistemas y Requerimientos. Fundación Universitaria Iberoamericana. ISBN. 978-84-96542-77-8 . Mayo. 167 pp. Barcelona, España. Ver.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

CEO & Co-Founder de EstayConsulting – Consultoría Estratégica

Miembro de Red

//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js (adsbygoogle = window.adsbygoogle || []).push({});

Categorías

A %d blogueros les gusta esto: