Trasteando en archive.org recupero un artículo que escribí en 2004 en mi antiguo blog:
El libro "La cultura norteamericana contemporánea. Una visión antropológica" del antropólogo Marvin Harris dedica un capítulo completo ("¿Por qué no funciona nada?") a buscar una explicación del porqué de la baja calidad de los productos fabricados a partir de la Segunda Guerra Mundial en Estados Unidos (y por extensión, yo añadiría, en todo el mundo occidental).
Desde principios de los años ochenta han proliferado las empresas de creación de aplicaciones informáticas a medida, y desde mediados de los años noventa se le sumaron las empresas que desarrollaban aplicaciones para Internet. Un gran porcentaje de personas que han contratado servicios informáticos para la creación de esas aplicaciones informáticas habrán "sufrido" las consecuencias de la forma de desarrollar dichos proyectos. Otro gran porcentaje de profesionales de la informática habrá comprobado desde dentro el funcionamiento de sus empresas en el desarrollo de dichos proyectos. Todos ellos podrán llegar a una conclusión: las aplicaciones nunca funcionan como el usuario desea .
Volviendo al libro de Marvin Harris, "los artefactos utilizados por las sencillas sociedades prehistóricas tenían un diseño sencillo, incluso primitivo, y, sin embargo, estaban construidos para que cumplieran sin fallos los propósitos a que se destinaban toda la vida." ¿A que se debe esa calidad? ¿Será la tecnología que todavía no está dominada al cien por cien? No lo creo. Según el propio Marvin Harris a que "los productores y consumidores eran los mismos individuos o parientes próximos, lo que garantizaba el mayor grado de seguridad y duración en los artículos manufacturados".
¿Qué significa todo esto? ¿Es un alegato al retorno a la vida prehistórica? ¿Significa que evitemos las especialización y nos dediquemos a realizar todos los trabajos del hogar? ¿Que nos convirtamos en autosuficientes? ¿Que tengamos nuestro propio huerto, nuestra propia panadería, y...seamos nuestros propios médicos? No. Nada de eso. Si lo enfocamos desde la otra perspectiva, y, en vez de preguntar por qué funcionaban las cosas en la prehistoria, retornamos a la pegunta original: ¿Por qué no funcionan las cosas en nuestra época? Una respuesta podría ser: por la alienación de los trabajadores. Es muy difícil que la gente se preocupe de los extraños o de los productos que éstos utilizan. En nuestra época donde predomina la economía terciaria, la de los servicios y de las grandes corporaciones (las multinacionales, los conglomerados, la empresas diversificadas... en realidad oligopolios), y de la consecuente burocracia, no resulta muy complicado que las relaciones productor-consumidor hayan sido sustituidas por las relaciones monetarias no como fin último, sino como medio. La idea de la alienación no es nueva, según Karl Marx la alienación del trabajo asalariado es fundamentalmente un "extrañamiento del obrero frente al producto de su trabajo y frente al proceso de trabajo, y esto lo mismo para el trabajo manual como para el trabajo intelectual".
Actualmente, las grandes empresas de desarrollo de aplicaciones informáticas o las grandes consultoras de tecnología copan casi el 100 por 100 del mercado del desarrollo informático, el otro pequeño porcentaje queda para pequeñas pymes y profesionales autónomos. Según Marvin Harris, "los problemas de la calidad en los Estados Unidos alcanzaron proporciones críticas como consecuencia del aumento, sin precedentes hasta entonces, en el tamaño y la complejidad de las corporaciones industriales, así como el número de trabajadores y directores alienados y negligentes". Las grandes empresas de servicios se han convertido en cadenas de montaje. En esta línea, Corinne Maier, en su obra "Buenos días, pereza", explica que "las profesiones ya no exigen un elevado nivel de competencia técnica o intelectual. Son básicamente una rutina y requieren tan poca iniciativa y espíritu de innovación que cualquier persona con los estudios apropiados se encuentra ya de entrada sobradamente preparada para la mayoría de los puestos de trabajo disponibles".
Además de la alienación de los trabajadores, se ha implantado en estas grandes empresas, y ya en la sociedad globalizada, el márketing (o la "obsolescencia planeada" como lo llama Harris) como un tótem indiscutible. No quiere decirse con lo de "obsolescencia planeada" que se vendan productos con fallos deliberados, pero sí productos con perfeccionamientos paupérrimos sobre sus versiones anteriores con la única intención de implantar los segundos sobre los primeros. Las grandes corporaciones, esas que copan casi el 100 por 100 del mercado de desarrollo informático y cuentan con casi el 100 por 100 de trabajadores alienados, dedican todos sus esfuerzos, no en sacar productos perfectos, sino en crear campañas de marketing perfectas, campañas de venta de humo. Los directivos de esas empresas permanecen en sus puestos como mucho diez años, el suficiente para mejorar las cuentas de la empresa, y cuando los productos están en la calle, ellos ya han salido por la puerta (por la puerta grande, seguramente). Como dijo Goebbels a Hitler: "No hablamos para decir algo sino para obtener determinado efecto". Tras esa fachada de cartón-piedra que es el márketing y la imagen, se encuentran (si la ropa de marca la fabrican niños asiáticos, entonces...) becarios que dedican sus horas de formación y su fuerza de trabajo a sacar adelante productos que el cliente piensa que han sido desarrollados por ingenieros y profesionales altamente cualificados.
Las características de la profesión informática y de los avances técnicos (trabajo a distancia, colaboración con otros profesionales) posibilita que se pueda desarrollar la profesión bajo una forma más manual, más personal, más cercana al usuario final, en definitiva el cliente, como los pequeños orfebres del siglo XV o los pequeños comerciantes de principio de siglo XX. No es necesario que cada profesional sólo pueda ofrecer los servicios de los que es capaz de realizar, sino que se pueden formar pequeños colectivos de trabajo interdisciplinares pero relacionados (programadores, analistas, diseñadores gráficos, analistas de negocio, ingenieros de sistemas, etc.) que puedan ofrecer al cliente un servicio perfecto basado en la cercanía del productor en relación con el consumidor. El productor trabajará directamente para él mismo, se evitará la temida alienación y consecuentemente se pondrán en el mercado mejores productos.
Harris, Marvin. "La cultura norteamericana contemporánea. Una visión antropológica", Alianza Editorial, Madrid, 1984
Maier, Corinne. "Buenos días, pereza", Editorial Península, Barcelona, 2004
Marx, Karl. "Manuscritos económicos-filosóficos de 1844", Editorial Grijalbo, Barcelona, 1975
Mostrando entradas con la etiqueta gestión. Mostrar todas las entradas
Mostrando entradas con la etiqueta gestión. Mostrar todas las entradas
jueves, 11 de diciembre de 2008
viernes, 5 de diciembre de 2008
Burocracia, eAdministración y experiencia de usuario
Aceptemos que la implantación de la eAdministración será un gran paso adelante. Los ciudadanos saldremos ganando: podremos realizar todos (o casi todos) los trámites por Internet, lo que supone un alivio (hoy pretendía realizar un trámite en la AEAT, pero su horario de atención al público es de 9h a 14h, a esas horas trabajo, como la mayoría de nosotros).
Aún así, algo debe mejorar en la Administración y la futura eAdministración y no es más que la experiencia de usuario. Es decir, la facilidad para explicar qué tramites debo realizar para conseguir un determinado fin y cómo debo realizarlos.
Si, por ejemplo, quiero tramitar un matrimonio civil o un certificado conocimientos de nivel c de catalán, es muy posible que algunos de los pasos (esperemos que en el futuro todos) pueda realizarlos por Internet, pero ¿qué pasos debo realizar? ¿en qué orden? ¿qué documentos es necesario presentar? ¿dónde?. Teóricamente los portales de las diferentes administraciones lo explican tras links y más links y textos y más textos crípticos.
Mi amigo y profesor de la UPC Rubén Tous me enseñaba un diagrama que realizó para ayudarse a él mismo y a los futuros padres a conocer todos los trámites que implican el nacimiento de un/a hijo/a (en su caso una niña, Marina). Es sencillo. La Administración Pública debería tomar nota. Se trata de un modelo de estados (cajas) unidas por flechas (mostrando qué debemos hacer antes de y después de) donde se indica:
Los padres o futuros padres podéis descargarlo aquí (PDF en catalán).
Se trata de ponerse en la piel del usuario que no tiene porqué estar familiarizado con la terminología de la Administración. Un ejemplo recurrente cada año es el de la declaración de la renta. Hemos avanzado mucho: confirmación del borrador, carga de datos personales mediante al programa PADRE, pago o cobro online, pero ¿qué significa “Los sujetos pasivos sometidos al Impuesto por obligación personal, cuando su base imponible, determinada de acuerdo con las normas reguladoras del Impuesto” o “procedan de más de un pagador, siempre que la suma de las cantidades percibidas del segundo y restantes pagadores, por orden de cuantía, superen la cantidad de 1.500 € brutos anuales.”?
La Administración (o una empresa privada) debería pensar en crear un programa de ayuda a realizar la declaración de la renta que fuera más o menos así (un ejemplo, tonto):
Paso 1. ¿Trabaja usted por cuenta ajena? Sí
Paso 2. ¿Cuánto ha cobrado? 25000€
Paso 3. ¿Tiene un piso en propiedad? No
Paso 4. ¿Ha comprado o vendido acciones? Sí
Paso 4.1 ¿De qué empresa y a qué precio?
…
Esperemos que poco a poco la Administración Pública consiga la excelencia tecnológica y sirva de modelo para las empresas privadas de este país.
Aún así, algo debe mejorar en la Administración y la futura eAdministración y no es más que la experiencia de usuario. Es decir, la facilidad para explicar qué tramites debo realizar para conseguir un determinado fin y cómo debo realizarlos.
Si, por ejemplo, quiero tramitar un matrimonio civil o un certificado conocimientos de nivel c de catalán, es muy posible que algunos de los pasos (esperemos que en el futuro todos) pueda realizarlos por Internet, pero ¿qué pasos debo realizar? ¿en qué orden? ¿qué documentos es necesario presentar? ¿dónde?. Teóricamente los portales de las diferentes administraciones lo explican tras links y más links y textos y más textos crípticos.
Mi amigo y profesor de la UPC Rubén Tous me enseñaba un diagrama que realizó para ayudarse a él mismo y a los futuros padres a conocer todos los trámites que implican el nacimiento de un/a hijo/a (en su caso una niña, Marina). Es sencillo. La Administración Pública debería tomar nota. Se trata de un modelo de estados (cajas) unidas por flechas (mostrando qué debemos hacer antes de y después de) donde se indica:
- Trámite a realizar
- Dónde realizarlo
- Documentos a presentar
- Documentos que la Administración te entrega
Los padres o futuros padres podéis descargarlo aquí (PDF en catalán).
Se trata de ponerse en la piel del usuario que no tiene porqué estar familiarizado con la terminología de la Administración. Un ejemplo recurrente cada año es el de la declaración de la renta. Hemos avanzado mucho: confirmación del borrador, carga de datos personales mediante al programa PADRE, pago o cobro online, pero ¿qué significa “Los sujetos pasivos sometidos al Impuesto por obligación personal, cuando su base imponible, determinada de acuerdo con las normas reguladoras del Impuesto” o “procedan de más de un pagador, siempre que la suma de las cantidades percibidas del segundo y restantes pagadores, por orden de cuantía, superen la cantidad de 1.500 € brutos anuales.”?
La Administración (o una empresa privada) debería pensar en crear un programa de ayuda a realizar la declaración de la renta que fuera más o menos así (un ejemplo, tonto):
Paso 1. ¿Trabaja usted por cuenta ajena? Sí
Paso 2. ¿Cuánto ha cobrado? 25000€
Paso 3. ¿Tiene un piso en propiedad? No
Paso 4. ¿Ha comprado o vendido acciones? Sí
Paso 4.1 ¿De qué empresa y a qué precio?
…
Esperemos que poco a poco la Administración Pública consiga la excelencia tecnológica y sirva de modelo para las empresas privadas de este país.
martes, 2 de diciembre de 2008
Cuando el usuario escribe la carta a los reyes (magos)
En uno de los posts sobre creación de aplicaciones web, hablaba de la fase de toma de requisitos como, entre otras cosas, una serie de entrevistas con el usuario para conocer sus necesidades. Sin embargo, hay que tener mucho cuidado con este tipo de reuniones ya que muchas veces el cliente escribe, lo que se conoce como “la carta a los reyes”.
Los usuarios finales siempre intentarán que la futura aplicación automatice sus procesos diarios y así hacerles a ellos (y no a la compañía) el trabajo más fácil. Cada uno de nosotros tiene su forma de trabajar en el día a día, unos utilizamos documentos de texto, otros hojas de cálculo, o mensajes de correo, o quizá programas con calendario y tareas o, incluso, la olvidada libreta de papel con cuadros y el bolígrafo, sí, el bolígrafo. Si el cliente cede todo el poder de decisión a los usuarios finales éstos, ten por seguro que te pedirán (si, por ejemplo, les quisiéramos desarrollar una Intranet):
Cierto, cada uno de nosotros trabajar de una forma distinta, pero quizá debamos guardar los documentos en un repositorio común y no en la carpeta Mis Documentos de nuestro PC, compartir nuestros links favoritos (los profesionales) en la Intranet y no guardarlos en mi navegador, o publicar las conclusiones de un proyecto en el blog interno, en vez de guardarnos ese conocimiento.
Los usuarios finales siempre intentarán que la futura aplicación automatice sus procesos diarios y así hacerles a ellos (y no a la compañía) el trabajo más fácil. Cada uno de nosotros tiene su forma de trabajar en el día a día, unos utilizamos documentos de texto, otros hojas de cálculo, o mensajes de correo, o quizá programas con calendario y tareas o, incluso, la olvidada libreta de papel con cuadros y el bolígrafo, sí, el bolígrafo. Si el cliente cede todo el poder de decisión a los usuarios finales éstos, ten por seguro que te pedirán (si, por ejemplo, les quisiéramos desarrollar una Intranet):
- Que el programa pase sus apuntes de Word al mail, se envíen y guarden una copia en la intranet en formato PDF.
- Que el programa lea sus “excels” (sin formato definido) y lo guarde en la base de datos de la compañía, ah, y que les envíe un mail cada noche con las coordenadas de las celdas de color rojo.
- Que el programa escriba un mail a partir de las notas escritas en su libreta Moleskine.
- ….
Cierto, cada uno de nosotros trabajar de una forma distinta, pero quizá debamos guardar los documentos en un repositorio común y no en la carpeta Mis Documentos de nuestro PC, compartir nuestros links favoritos (los profesionales) en la Intranet y no guardarlos en mi navegador, o publicar las conclusiones de un proyecto en el blog interno, en vez de guardarnos ese conocimiento.
martes, 18 de noviembre de 2008
Cómo crear un aplicación web. Fase IV. Programación.
Fase I. Toma de requisitos
Fase II. Prototipos
Fase III. Diseño gráfico + Diseño software
Cuando ya tengamos las pantallas de la aplicación maquetadas en HTML y la base de datos modelada podemos pasar a codificar (programar) la aplicación.
Dividiremos la aplicación en diferentes capas (N-capas). Cada una de esas capas se comunicará con las demás y será independiente de las demás. ¿Qué son las capas? Simplemente agrupación de clases y funciones.
Mi recomendación es que nuestra aplicación tenga las siguientes capas:
Mi recomendación es ir programando las capas en este orden: primero el acceso a datos y de esa forma crear una batería de pruebas para comprobar si los datos se guardan correctamente en la base de datos. Una vez está testeado, crear la capa de negocio y continuar con las pruebas, para acabar con la capa de presentación. Si hemos realizado las pruebas correctamente y, puesto que ya tenemos los prototipos maquetados en HTML, la programación de capa de presentación será muy sencilla y rápida.
Todo este proceso puede dividirse en partes independientes e ir realizando entregas al cliente y así evitar una entrega única al final del proyecto.
Fase II. Prototipos
Fase III. Diseño gráfico + Diseño software
Cuando ya tengamos las pantallas de la aplicación maquetadas en HTML y la base de datos modelada podemos pasar a codificar (programar) la aplicación.
Dividiremos la aplicación en diferentes capas (N-capas). Cada una de esas capas se comunicará con las demás y será independiente de las demás. ¿Qué son las capas? Simplemente agrupación de clases y funciones.
Mi recomendación es que nuestra aplicación tenga las siguientes capas:
- Capa de acceso a datos: lanzará consultas a la base de datos (o el repositorio de datos sobre el que debamos atacar, ya sea base de datos, archivos de texto o archivos de cualquier tipo). Debemos crear una consulta para cada uno de los casos de uso definidos anteriormente, por ejemplo, crear usuario, añadir fotografía, modificar perfil, etc. Las consultas sobre una base de datos relacional se realizan en el lenguaje estándar SQL, es muy recomendable crear procedimientos almacenados (no son más que funciones con parámetros de entrada/salida) en la propia base de datos y minimizarlos a la mínima expresión (select, delete, update, insert).
- Capa de negocio: Es el lugar donde se lleva a cabo el core de la programación, donde se transforma los datos obtenidos por la capa de datos en datos que podrán ser mostrados por la capa de presentación, y viceversa.
- Capa de presentación: en el caso de las aplicaciones web, la capa de presentación es la que muestra datos en la pantalla y recoge datos introducidos en los formularios.
- Capa de acceso a aplicaciones de terceros: si nuestra aplicación necesita acceder a datos de terceros (APIs de aplicaciones públicas, XML de datos de otra web, servicios web, etc.) es recomendable que lo centralicemos en una nueva capa. De esta forma si cambiamos de proveedor o cambiamos la forma de obtener esos datos, será totalmente transparente a las demás capas.
Mi recomendación es ir programando las capas en este orden: primero el acceso a datos y de esa forma crear una batería de pruebas para comprobar si los datos se guardan correctamente en la base de datos. Una vez está testeado, crear la capa de negocio y continuar con las pruebas, para acabar con la capa de presentación. Si hemos realizado las pruebas correctamente y, puesto que ya tenemos los prototipos maquetados en HTML, la programación de capa de presentación será muy sencilla y rápida.
Todo este proceso puede dividirse en partes independientes e ir realizando entregas al cliente y así evitar una entrega única al final del proyecto.
viernes, 14 de noviembre de 2008
Planificación en los proyectos empresariales 2.0
Estas últimas semanas he leído varias noticias que me han inquietado. Por un lado la muy cacareada petición de financiación a la comunidad de usuarios para poder seguir emitiendo de Mobuzz (aquí, aquí, aquí o aquí). Por otro lado, la noticia (rumores) que Facebook necesita otra inyección de capital (sí, incluso después de la que le proporcionó la venta del 1,6% a Microsoft por 240 millones de dólares). Y cómo no, la ristra de despidos en las empresas tecnológicas, dando que pensar que estamos en una nueva “burbuja.com”.
Cómo ya comenté en este post, tengo dudas razonables sobre los planes que tienen ciertas empresas 2.0 como Twitter o Facebook al respecto de monetizar su éxito.
Estuve hablando sobre estas inquiteudes con mi buen amigo Carlos Sánchez (Técnico de Creación de Empresas en Barcelona Activa). Charlamos sobre la importancia de tener un buen plan de negocio y estar preparado tanto para el fracaso como para el éxito cuando te inicias en un nuevo proyecto empresarial. Estar preparados por si el éxito nos sorprende y, en ese momento, saber confiar en expertos para que no asesoren en la gestión del éxito.
A partir de esa charla, y teniendo en cuenta la experiencia que atesora Carlos en el asesoriamiento a emprendedores, le propuse que escribiera un artículo sobre la planificación en los proyectos empresariales 2.0. Aquí lo tenéis:
La planificación en los proyectos empresariales 2.0
Cuando hablamos de creación de empresas, Internet y financiación, son muchos los matices que debemos tener en cuenta y, con ellos, de la mano, los peligros que acechan a cualquier proyecto empresarial en su camino hacia la viabilidad. Como en todo aquello que funciona y además tiene eco mediático, el peligro de quedarse en el titular y no entrar en la letra pequeña es muy elevado. Y es que actualmente somos testigos del éxito de las redes sociales, de la llamada Web 2.0. Nombres como Facebook, LinkedIn o Xing nos son cada vez más familiares y somos muchos los que formamos parte activa o cuanto menos testimonial. Y es que precisamente, estas redes sociales basan su éxito y su enorme potencial en su capacidad para generar usuarios, es decir, en su capacidad para acumular datos y más datos sobre millones de personas, teniendo acceso directo o indirecto a aspectos tales como la edad, la formación, los gustos musicales, sus actividades de ocio, sus viajes o la gente con la que se relacionan. En el caso de proyectos empresariales basados en Internet, en la inmensa mayoría de los casos, el cálculo del valor y el potencial de dicho proyecto residen en su capacidad para generar usuarios. Generalmente, inversores privados o entidades financieras piden previsiones sobre cuántos usuarios podrá acumular el proyecto en los primeros dos o tres años de actividad. Pero, ¿qué ocurre cuando ese proyecto, convertido ya en realidad, acumula usuarios pero no genera los ingresos necesarios para sostenerse? En mi opinión, se pone de manifiesto la falta de previsión y planificación durante el proceso de desarrollo y maduración de la idea, durante la fase de elaboración del plan de empresa.
Hace poco salió a la luz el caso de Mobbuz, una plataforma de TV on-line que pese a tener una cantidad nada despreciable de fieles seguidores, había lanzado una petición desesperada a sus usuarios: una donación para poder mantener la web; de lo contrario se verían obligados a cerrarla. ¿Cómo puede ser que una web con tal cantidad de usuarios esté condenada al cierre? En otras palabras, ¿cómo es posible que una empresa que cumple con las previsiones que auguraban su viabilidad y rentabilidad resulte no ser rentable? Muy sencillo, simplemente el referente para determinar la viabilidad era erróneo, y además las expectativas de ingreso derivadas también. Y es que el silogismo usuarios igual a publicidad igual a ingresos no siempre se cumple. Alcanzar una cifra considerable de usuarios no implica que necesariamente la publicidad y, por tanto los ingresos, lleguen solos. Parto de la base de que un buen producto tiene que aportar valor a su potencial público objetivo, el cual a cambio de dicho valor tiene que estar dispuesto a pagar por ello, de manera directa o indirecta. ¿Estaríamos dispuestos a pagar por los servicios que nos ofrece actualmente Facebook? La mayoría seguramente no. Pero, ¿y si resulta que cuando en el muro de un amigo le explico que estoy buscando piso y automáticamente me aparece a la derecha el anuncio de una agencia a través de la cual encuentro el piso que estoy buscando? Entonces pensaré que Facebook no solamente es útil para relacionarme con mis amigos sino que además me ofrece un valor añadido: me ayuda a encontrar lo que busco. El problema es que no todas las redes sociales o las plataformas o webs 2.0 son tan buenas como para poder generar no sólo una cantidad significativa de usuarios con sus respectivos datos sino de proporcionar la calidad suficiente en esos datos.
Es importante cuantificar qué cantidad de usuarios podemos alcanzar en el primer año de actividad. Pero más importante es prever qué haremos en el caso que alcancemos ese número de usuarios. Dar por hecho que los ingresos por publicidad serán suficientes para sostener el negocio es mucho suponer en la mayoría de los casos. Es necesario escenificar diferentes escenarios, buscar y contemplar ingresos alternativos, dimensionar correctamente los costes fijos de la empresa y conocer en todo momento el nivel de ingresos necesarios para cubrirlos. Si desarrollamos y pivotamos un proyecto de negocio basado en Internet sobre la única base de los usuarios, estaremos tomando un referente equívoco que, por lo tanto, nos llevará a decisiones inadecuadas. Creceremos rápidamente para poder dar respuesta al nivel de usuarios que tenemos, contratando más personal, incrementando el gasto en publicidad y marketing y en definitiva incurriendo en costes adicionales que no podrán ser asumidos por nuestros ingresos. Hasta el momento en que el nivel de costes fijos será tan elevado que nuestra capacidad para hacer frente a nuestras necesidades de tesorería será muy limitada. En ese momento nos veremos obligados a soluciones imaginativas como la de pedir donaciones a nuestros usuarios o a algunas más tradicionales, como la de cerrar la empresa.
Algunos apuntes para planificar bien el proyecto empresarial
La elaboración del plan de empresa nos ayudará a desarrollar y madurar nuestra idea de negocio y a reflexionar sobre todos aquellos aspectos de nuestro proyecto que afectan de manera significativa a su viabilidad. Además de dedicar tiempo al plan de empresa en líneas generales (definición del negocio, público objetivo, elementos diferenciadores, análisis del mercado y de la competencia, plan económico-financiero, etc.), existen algunos puntos de vital importancia en el caso de empresas basadas en Internet:
Definir correctamente el público objetivo: teniendo en cuenta que el objetivo de la empresa deber ser la viabilidad y, por tanto, la generación de ingresos, debemos ser conscientes de quiénes son realmente nuestros potenciales clientes. Obviamente, el negocio debe estar orientado hacia los usuarios, haciéndolo atractivo hacia ellos, pero a no ser que se trate de una plataforma de pago, debemos determinar claramente de dónde obtendremos los ingresos. Si nuestra web es capaz de atraer a usuarios por sus contenidos o utilidad, ¿quién podría estar interesado en darse a conocer u ofrecer sus servicios entre esos usuarios? Y, atención, porque la publicidad no es la única vía. Es importante apostar por soluciones creativas como puede ser la cooperación empresarial o el intercambio de servicios. Por ejemplo, ofrecer promociones, cupones de descuento o condiciones preferentes.
Dividir el horizonte temporal de la empresa en fases: los proyectos empresariales basados en Internet quizás son aquellos en los que resulta más evidente la necesidad de establecer una serie de fases a lo largo de los primeros meses y años de actividad. Las prioridades y las acciones a llevar a cabo van variando según va avanzando el tiempo y es importante que tengamos claras cuáles son las decisiones a tomar en cada momento. En una primera fase puede ser importante dedicar todos los esfuerzos al diseño y desarrollo de la plataforma y los usuarios están todavía en un segundo plano. En una segunda fase, puede que sea necesaria una etapa de testeo, cerrada al público en general. Una vez tengamos un flujo importante de usuarios llegará el momento de introducir el producto en la escena y, por tanto, de poner en marcha la maquinaria comercial. Es necesario quemar cada fase antes de pasar a la siguiente y ni siquiera el éxito y el cumplimiento de las previsiones antes de tiempo debería llevarnos a saltarnos fases. La improvisación en la gestión de una empresa es muy mala consejera.
Establecer objetivos realistas para cada fase: la fijación de objetivos es un elemento clave en el desarrollo de un plan de empresa. Resulta mucho más cómodo trabajar el día a día de la empresa teniendo como referencia objetivos fijados previamente. De esta manera, analizar la situación del negocio en cada momento es mucho más sencillo. Pero la fijación de objetivos sólo resulta útil si estos son realistas. No tiene sentido establecer objetivos totalmente inabarcables y tampoco objetivos fácilmente alcanzables. Es recomendable tomar como referencia otros proyectos similares, en vez de construir hipótesis sobre datos estadísticos.
Planificar los recursos estrictamente necesarios para alcanzar la siguiente fase: además de los objetivos de cada fase, debemos fijar de antemano los recursos necesarios para su consecución y para el acceso a la siguiente etapa del proyecto. Si en la primera fase debemos centrarnos en la parte tecnológica de desarrollo, deberemos construir una plantilla sobre las necesidades exclusivas de esa fase. Por ejemplo, no necesitaremos dedicar recursos ni económicos ni humanos a temas como el marketing o la gestión de usuarios. Pero sí deberemos ser conscientes de en qué momento tendremos que hacerlo.
Buscar financiación en el momento adecuado: la búsqueda de financiación tiene que ir de la mano de las distintas fases en las que se haya dividido temporalmente el proyecto. Es importante determinar claramente la inversión necesaria para cada una de las fases del proyecto, teniendo en cuenta los recursos necesarios para cada una de ellas. No tiene sentido llevar a cabo una primera ronda de financiación por la inversión total del conjunto de las fases, ya que estaremos incurriendo en unos gastos financieros innecesarios y además podemos estar quemando opciones futuras por la inmadurez inicial del proyecto. Las posibilidades de obtener condiciones más favorables aumentan cuando el proyecto está más desarrollado y los argumentos a favor de su viabilidad son más. Además, si tenemos en mente ir a buscar inversores privados, sería bueno tener en cuenta que existen inversores que además de aportar su capital, tienen experiencia y conocimientos sobre el sector en el que queremos emprender y cuyos consejos pueden ser de gran ayuda.
En definitiva, un “negocio 2.0” no difiere tanto de los negocios más tradicionales, como puede ser una librería. El hecho de que mucha gente entre a nuestra librería no asegura que ésta sea rentable, a no ser que un elevado porcentaje de los que visitan la librería, además de eso, compren libros. ¿Por qué resulta obvio que si queremos abrir una librería debemos planificar qué debemos hacer para vender los suficientes libros y que ocurrirá si no vendemos los suficientes y en cambio en un negocio basado en Internet no? Seguramente el éxito de unos pocos ha provocado expectativas sesgadas en muchos inversores, los cuales han querido encontrar su Google particular, invirtiendo dinero en proyectos sin analizar detalladamente su viabilidad y sin exigir lo suficiente a sus promotores. Pero al final lo que vale son las cuentas de la vieja y es que para que una empresa sea rentable hay que ingresar más de lo que se gasta.
Cómo ya comenté en este post, tengo dudas razonables sobre los planes que tienen ciertas empresas 2.0 como Twitter o Facebook al respecto de monetizar su éxito.
Estuve hablando sobre estas inquiteudes con mi buen amigo Carlos Sánchez (Técnico de Creación de Empresas en Barcelona Activa). Charlamos sobre la importancia de tener un buen plan de negocio y estar preparado tanto para el fracaso como para el éxito cuando te inicias en un nuevo proyecto empresarial. Estar preparados por si el éxito nos sorprende y, en ese momento, saber confiar en expertos para que no asesoren en la gestión del éxito.
A partir de esa charla, y teniendo en cuenta la experiencia que atesora Carlos en el asesoriamiento a emprendedores, le propuse que escribiera un artículo sobre la planificación en los proyectos empresariales 2.0. Aquí lo tenéis:
La planificación en los proyectos empresariales 2.0
Cuando hablamos de creación de empresas, Internet y financiación, son muchos los matices que debemos tener en cuenta y, con ellos, de la mano, los peligros que acechan a cualquier proyecto empresarial en su camino hacia la viabilidad. Como en todo aquello que funciona y además tiene eco mediático, el peligro de quedarse en el titular y no entrar en la letra pequeña es muy elevado. Y es que actualmente somos testigos del éxito de las redes sociales, de la llamada Web 2.0. Nombres como Facebook, LinkedIn o Xing nos son cada vez más familiares y somos muchos los que formamos parte activa o cuanto menos testimonial. Y es que precisamente, estas redes sociales basan su éxito y su enorme potencial en su capacidad para generar usuarios, es decir, en su capacidad para acumular datos y más datos sobre millones de personas, teniendo acceso directo o indirecto a aspectos tales como la edad, la formación, los gustos musicales, sus actividades de ocio, sus viajes o la gente con la que se relacionan. En el caso de proyectos empresariales basados en Internet, en la inmensa mayoría de los casos, el cálculo del valor y el potencial de dicho proyecto residen en su capacidad para generar usuarios. Generalmente, inversores privados o entidades financieras piden previsiones sobre cuántos usuarios podrá acumular el proyecto en los primeros dos o tres años de actividad. Pero, ¿qué ocurre cuando ese proyecto, convertido ya en realidad, acumula usuarios pero no genera los ingresos necesarios para sostenerse? En mi opinión, se pone de manifiesto la falta de previsión y planificación durante el proceso de desarrollo y maduración de la idea, durante la fase de elaboración del plan de empresa.
Hace poco salió a la luz el caso de Mobbuz, una plataforma de TV on-line que pese a tener una cantidad nada despreciable de fieles seguidores, había lanzado una petición desesperada a sus usuarios: una donación para poder mantener la web; de lo contrario se verían obligados a cerrarla. ¿Cómo puede ser que una web con tal cantidad de usuarios esté condenada al cierre? En otras palabras, ¿cómo es posible que una empresa que cumple con las previsiones que auguraban su viabilidad y rentabilidad resulte no ser rentable? Muy sencillo, simplemente el referente para determinar la viabilidad era erróneo, y además las expectativas de ingreso derivadas también. Y es que el silogismo usuarios igual a publicidad igual a ingresos no siempre se cumple. Alcanzar una cifra considerable de usuarios no implica que necesariamente la publicidad y, por tanto los ingresos, lleguen solos. Parto de la base de que un buen producto tiene que aportar valor a su potencial público objetivo, el cual a cambio de dicho valor tiene que estar dispuesto a pagar por ello, de manera directa o indirecta. ¿Estaríamos dispuestos a pagar por los servicios que nos ofrece actualmente Facebook? La mayoría seguramente no. Pero, ¿y si resulta que cuando en el muro de un amigo le explico que estoy buscando piso y automáticamente me aparece a la derecha el anuncio de una agencia a través de la cual encuentro el piso que estoy buscando? Entonces pensaré que Facebook no solamente es útil para relacionarme con mis amigos sino que además me ofrece un valor añadido: me ayuda a encontrar lo que busco. El problema es que no todas las redes sociales o las plataformas o webs 2.0 son tan buenas como para poder generar no sólo una cantidad significativa de usuarios con sus respectivos datos sino de proporcionar la calidad suficiente en esos datos.
Es importante cuantificar qué cantidad de usuarios podemos alcanzar en el primer año de actividad. Pero más importante es prever qué haremos en el caso que alcancemos ese número de usuarios. Dar por hecho que los ingresos por publicidad serán suficientes para sostener el negocio es mucho suponer en la mayoría de los casos. Es necesario escenificar diferentes escenarios, buscar y contemplar ingresos alternativos, dimensionar correctamente los costes fijos de la empresa y conocer en todo momento el nivel de ingresos necesarios para cubrirlos. Si desarrollamos y pivotamos un proyecto de negocio basado en Internet sobre la única base de los usuarios, estaremos tomando un referente equívoco que, por lo tanto, nos llevará a decisiones inadecuadas. Creceremos rápidamente para poder dar respuesta al nivel de usuarios que tenemos, contratando más personal, incrementando el gasto en publicidad y marketing y en definitiva incurriendo en costes adicionales que no podrán ser asumidos por nuestros ingresos. Hasta el momento en que el nivel de costes fijos será tan elevado que nuestra capacidad para hacer frente a nuestras necesidades de tesorería será muy limitada. En ese momento nos veremos obligados a soluciones imaginativas como la de pedir donaciones a nuestros usuarios o a algunas más tradicionales, como la de cerrar la empresa.
Algunos apuntes para planificar bien el proyecto empresarial
La elaboración del plan de empresa nos ayudará a desarrollar y madurar nuestra idea de negocio y a reflexionar sobre todos aquellos aspectos de nuestro proyecto que afectan de manera significativa a su viabilidad. Además de dedicar tiempo al plan de empresa en líneas generales (definición del negocio, público objetivo, elementos diferenciadores, análisis del mercado y de la competencia, plan económico-financiero, etc.), existen algunos puntos de vital importancia en el caso de empresas basadas en Internet:
Definir correctamente el público objetivo: teniendo en cuenta que el objetivo de la empresa deber ser la viabilidad y, por tanto, la generación de ingresos, debemos ser conscientes de quiénes son realmente nuestros potenciales clientes. Obviamente, el negocio debe estar orientado hacia los usuarios, haciéndolo atractivo hacia ellos, pero a no ser que se trate de una plataforma de pago, debemos determinar claramente de dónde obtendremos los ingresos. Si nuestra web es capaz de atraer a usuarios por sus contenidos o utilidad, ¿quién podría estar interesado en darse a conocer u ofrecer sus servicios entre esos usuarios? Y, atención, porque la publicidad no es la única vía. Es importante apostar por soluciones creativas como puede ser la cooperación empresarial o el intercambio de servicios. Por ejemplo, ofrecer promociones, cupones de descuento o condiciones preferentes.
Dividir el horizonte temporal de la empresa en fases: los proyectos empresariales basados en Internet quizás son aquellos en los que resulta más evidente la necesidad de establecer una serie de fases a lo largo de los primeros meses y años de actividad. Las prioridades y las acciones a llevar a cabo van variando según va avanzando el tiempo y es importante que tengamos claras cuáles son las decisiones a tomar en cada momento. En una primera fase puede ser importante dedicar todos los esfuerzos al diseño y desarrollo de la plataforma y los usuarios están todavía en un segundo plano. En una segunda fase, puede que sea necesaria una etapa de testeo, cerrada al público en general. Una vez tengamos un flujo importante de usuarios llegará el momento de introducir el producto en la escena y, por tanto, de poner en marcha la maquinaria comercial. Es necesario quemar cada fase antes de pasar a la siguiente y ni siquiera el éxito y el cumplimiento de las previsiones antes de tiempo debería llevarnos a saltarnos fases. La improvisación en la gestión de una empresa es muy mala consejera.
Establecer objetivos realistas para cada fase: la fijación de objetivos es un elemento clave en el desarrollo de un plan de empresa. Resulta mucho más cómodo trabajar el día a día de la empresa teniendo como referencia objetivos fijados previamente. De esta manera, analizar la situación del negocio en cada momento es mucho más sencillo. Pero la fijación de objetivos sólo resulta útil si estos son realistas. No tiene sentido establecer objetivos totalmente inabarcables y tampoco objetivos fácilmente alcanzables. Es recomendable tomar como referencia otros proyectos similares, en vez de construir hipótesis sobre datos estadísticos.
Planificar los recursos estrictamente necesarios para alcanzar la siguiente fase: además de los objetivos de cada fase, debemos fijar de antemano los recursos necesarios para su consecución y para el acceso a la siguiente etapa del proyecto. Si en la primera fase debemos centrarnos en la parte tecnológica de desarrollo, deberemos construir una plantilla sobre las necesidades exclusivas de esa fase. Por ejemplo, no necesitaremos dedicar recursos ni económicos ni humanos a temas como el marketing o la gestión de usuarios. Pero sí deberemos ser conscientes de en qué momento tendremos que hacerlo.
Buscar financiación en el momento adecuado: la búsqueda de financiación tiene que ir de la mano de las distintas fases en las que se haya dividido temporalmente el proyecto. Es importante determinar claramente la inversión necesaria para cada una de las fases del proyecto, teniendo en cuenta los recursos necesarios para cada una de ellas. No tiene sentido llevar a cabo una primera ronda de financiación por la inversión total del conjunto de las fases, ya que estaremos incurriendo en unos gastos financieros innecesarios y además podemos estar quemando opciones futuras por la inmadurez inicial del proyecto. Las posibilidades de obtener condiciones más favorables aumentan cuando el proyecto está más desarrollado y los argumentos a favor de su viabilidad son más. Además, si tenemos en mente ir a buscar inversores privados, sería bueno tener en cuenta que existen inversores que además de aportar su capital, tienen experiencia y conocimientos sobre el sector en el que queremos emprender y cuyos consejos pueden ser de gran ayuda.
En definitiva, un “negocio 2.0” no difiere tanto de los negocios más tradicionales, como puede ser una librería. El hecho de que mucha gente entre a nuestra librería no asegura que ésta sea rentable, a no ser que un elevado porcentaje de los que visitan la librería, además de eso, compren libros. ¿Por qué resulta obvio que si queremos abrir una librería debemos planificar qué debemos hacer para vender los suficientes libros y que ocurrirá si no vendemos los suficientes y en cambio en un negocio basado en Internet no? Seguramente el éxito de unos pocos ha provocado expectativas sesgadas en muchos inversores, los cuales han querido encontrar su Google particular, invirtiendo dinero en proyectos sin analizar detalladamente su viabilidad y sin exigir lo suficiente a sus promotores. Pero al final lo que vale son las cuentas de la vieja y es que para que una empresa sea rentable hay que ingresar más de lo que se gasta.
jueves, 13 de noviembre de 2008
Cómo crear una aplicación web. Fase III. Diseño gráfico + Diseño software
Fase I. Toma de requisitos
Fase II. Prototipos
Llegados a este punto del proyecto, podemos empezar a trabajar en paralelo. Por un lado, los diseñadores gráficos, a partir de los prototipos creados y aceptados por el cliente, pueden crear todas y cada una de las pantallas con la línea gráfica (colores, tamaños, tipos de letra, imágenes, etc.) que finalmente tendrá la aplicación. Lo normal es que los diseñadores trabajen con programas de tratamiento gráfico como, por ejemplo, Adobe Photoshop o Freehand.
Estas maquetas se van presentando al cliente y a medida que acepta la línea gráfica de cada una de las pantallas se pueden ir maquetando en XHTML + CSS. Es importante desde este momento que la maquetación en XHTML cumpla los estándares. Para ello podemos ir chequeando nuestro código en el validador de W3C.
Paralelamente al trabajo de los diseñadores gráficos, los diseñadores de software pueden comenzar su trabajo. A partir de los requisitos y de los prototipos creados, se debe ser capaz de diseñar el software. ¿Qué significa diseñar el software?
Aunque parezca que ha pasado mucho tiempo y todavía no nos hemos puesto a programar, es tarea del responsable del proyecto hacer ver al cliente que estos pasos de definición son necesarios para conseguir un producto estable y escalable. Recuerdo lo dicho en el post anterior, estamos construyendo un edificio y en esta fase dibujamos planos y levantamos cimientos.
Fase II. Prototipos
Llegados a este punto del proyecto, podemos empezar a trabajar en paralelo. Por un lado, los diseñadores gráficos, a partir de los prototipos creados y aceptados por el cliente, pueden crear todas y cada una de las pantallas con la línea gráfica (colores, tamaños, tipos de letra, imágenes, etc.) que finalmente tendrá la aplicación. Lo normal es que los diseñadores trabajen con programas de tratamiento gráfico como, por ejemplo, Adobe Photoshop o Freehand.
Estas maquetas se van presentando al cliente y a medida que acepta la línea gráfica de cada una de las pantallas se pueden ir maquetando en XHTML + CSS. Es importante desde este momento que la maquetación en XHTML cumpla los estándares. Para ello podemos ir chequeando nuestro código en el validador de W3C.
Paralelamente al trabajo de los diseñadores gráficos, los diseñadores de software pueden comenzar su trabajo. A partir de los requisitos y de los prototipos creados, se debe ser capaz de diseñar el software. ¿Qué significa diseñar el software?
- Modelar la base de datos: mediante el modelo entidad – relación se crean las tablas, los campos y las relaciones entre tablas.
- Definir los casos de uso: qué actores participan en la aplicación (por ejemplo: usuario, administrador, vendedor, generador de informes, etc.), que acciones podrán realizar (darse alta, modificar datos personales, añadir un producto al catálogo, añadir un producto a la cesta de la compra, etc.).
- Definir los estados: cuáles son los estados en que pueden estar las diferentes entidades (un usuario puede estar registrado o sin confirmar el registro, un documento puede estar en borrador o publicado, etc.).
Aunque parezca que ha pasado mucho tiempo y todavía no nos hemos puesto a programar, es tarea del responsable del proyecto hacer ver al cliente que estos pasos de definición son necesarios para conseguir un producto estable y escalable. Recuerdo lo dicho en el post anterior, estamos construyendo un edificio y en esta fase dibujamos planos y levantamos cimientos.
miércoles, 12 de noviembre de 2008
Cómo crear una aplicación web. Fase II. Prototipos
Una vez tenemos aceptados los requisitos que la aplicación deberá cumplir (ver Fase I), la persona del equipo que tome el papel de arquitecto de la información deberá crear los wireframes y/o prototipos de todas las pantallas que tendrá la aplicación. Normalmente, el wireframe se utiliza simplemente para mostrar en qué partes de las pantallas se ubicarán diferente elementos: menú, formularios, textos, listados, etc. Los prototipos se les añade funcionalidad (ya comenté una buena herramienta para construir prototipos).
El cliente deberá ir validando las diferentes secciones de la aplicación (registro de usuario, listado de imágenes, módulo de fotos, etc.). Es recomendable validar con el cliente paso a pasos, empezando por un nivel superior donde se definirán las partes comunes de toda la aplicación (menú superior, menú lateral, pie de página…).
Es muy importante hacer ver al cliente la importancia de la validación de los prototipos. A partir de su aceptación, se comenzará a programar, maquetar y construir la base de datos, por lo que los cambios a partir de ese momento suponen un mayor impacto (más tiempo = más dinero = más insatisfacción) en el desarrollo de la aplicación. Es muy común que los clientes no validen funcionalidades al 100% hasta que la aplicación está en marcha y pueden registrarse, listar resultados y, sobretodo, apretar botones. Es normal. Es nuestro trabajo lograr que lo hagan exhaustivamente en este momento y hacerles ver la importancia de esta fase el proyecto.
Éste es el momento en el que estamos trazando las líneas maestras de la aplicación. Se están dibujando los planos del edificio. Cuando el edificio esté en pie será muy, muy complicado añadir un garaje donde hay un local o un balcón donde hay una pared maestra.
El cliente deberá ir validando las diferentes secciones de la aplicación (registro de usuario, listado de imágenes, módulo de fotos, etc.). Es recomendable validar con el cliente paso a pasos, empezando por un nivel superior donde se definirán las partes comunes de toda la aplicación (menú superior, menú lateral, pie de página…).
Es muy importante hacer ver al cliente la importancia de la validación de los prototipos. A partir de su aceptación, se comenzará a programar, maquetar y construir la base de datos, por lo que los cambios a partir de ese momento suponen un mayor impacto (más tiempo = más dinero = más insatisfacción) en el desarrollo de la aplicación. Es muy común que los clientes no validen funcionalidades al 100% hasta que la aplicación está en marcha y pueden registrarse, listar resultados y, sobretodo, apretar botones. Es normal. Es nuestro trabajo lograr que lo hagan exhaustivamente en este momento y hacerles ver la importancia de esta fase el proyecto.
Éste es el momento en el que estamos trazando las líneas maestras de la aplicación. Se están dibujando los planos del edificio. Cuando el edificio esté en pie será muy, muy complicado añadir un garaje donde hay un local o un balcón donde hay una pared maestra.
lunes, 10 de noviembre de 2008
Cómo crear una aplicación web. Fase I. Toma de requisitos
El primer paso de cualquier proyecto que tenga como finalidad construir una aplicación informática es escuchar a los clientes y/o usuarios para saber qué necesitan. En una primera serie de reuniones simplemente debemos escuchar y tomar notas de las funcionalidades que debe cumplir el nuevo sistema. No debemos juzgar si tal requisito se hará de tal manera o si ese requisito es innecesario. Debemos recordar que el trabajo de crear una aplicación web debe estar orientado a la consecución de los objetivos del cliente, no a la satisfacción de los creadores. La satisfacción de los creadores (arquitectos, jefes de proyecto y programadores) debe ser la de crear un producto sin errores, escalable, on-time y que cumpla al 100% las necesidades del cliente.
Idealmente, la toma de requisitos debe realizarse antes del presupuesto en tiempo y dinero ya que es imposible presupuestar un proyecto del que no se sabe exactamente qué se desea. La fase de la toma de requisitos debe afrontarse como una coste comercial, ya que es posible que si no se ha firmado el contrato el proyecto finalmente no se gane. En la mayoría de los proyectos para administraciones públicas o grandes empresas donde se convoca un concurso mediante RFP se comete el error de presupuestar a partir de unos requisitos redactados por el cliente de forma poco exhaustiva por lo que es fácil que aparezcan desvíos tanto en tiempo de entrega, funcionalidades o precios desorbitados.
Una vez hemos tomado nota de los requisitos el siguiente paso, ya de manera interna es ordenar esas ideas. Una buena manera de ordenar ideas es crear, repito, de forma interna, una modelo de datos a partir de las decenas y decenas de ideas que el cliente nos ha transmitido. El cliente no tiene porqué saber (según un ejemplo de aplicación tipo Facebook) si los “amigos del usuario” puede ser lo mismo a efectos de programación que un “usuario”. Debemos ser capaces de reducir todas las ideas recogidas en la primera reunión en un modelo de datos (por ejemplo un modelo entidad-relación a alto nivel).
En la siguiente reunión tomaremos el control y a partir de la lectura de nuestro modelo de datos (traducción de cajas y líneas a prosa) debemos ir confirmado con el cliente que esas son las funcionalidades lo que su empresa necesita. En esa misma reunión debemos proponer temas que puedan aportar valor al cliente y basados en nuestra experiencia: integrar aplicaciones de terceros, formas de enfocar la arquitectura de la información, software existente, etc.
Esta fase y dependiendo de la envergadura del proyecto y/o del cliente puede convertirse en iteraciones de reuniones de toma de requisitos con diferentes responsables de áreas implicadas.
jueves, 6 de noviembre de 2008
Cómo crear una aplicación web
Son malos tiempos para la economía, de eso no hay duda. Son malos tiempos para el sector servicios, consecuencia de lo primero. Las empresas que tenían planeados proyectos que concernían a las tecnologías de la información del estilo: crear una intranet corporativa, comenzar a vender sus productos en Internet, crear un site efímero publicitando la salida al mercado de un nuevo producto, o una aplicación para ofrecer servicios a futuros clientes (Flickr, Twitter, etc.), están intentando ajustar presupuestos o directamente posponiendo esos proyectos hasta 2010 (o sine die).
Se acabaron los tiempos de los grandes proyectos mal gestionados y mal ejecutados a precios desorbitados. Que tomen nota las grandes consultoras. Siendo así, pienso que se abre un resquicio de esperanza para las pequeñas empresas que hagan las cosas baratas, y eso no significa mal., todo lo contrario, significa bien: ajustando precios, sirviendo los proyectos on-time y evitando desvíos que supongan costes en la facturación. Equipos pequeños y cohesionados, las cosas claras y las ganas de hacerlo bien.
Siempre he pensado que el desarrollo de una aplicación web estándar es sencillo. Que lo complicado es la gestión de las expectativas del cliente, o la infraestructura de los sistemas (si crece desmesuradamente) o puede resultar complicado si nosotros, como creadores de la aplicación, nos complicamos la vida innecesariamente. Keep it simple, stupid!!
Me atrevo a decir que hacer una aplicación como Facebook es sencillo. Comienzo aquí una serie de posts en las que doy mi opinión de cómo debería encararse el desarrollo de una aplicación web desde cero. Una aplicación estándar. Lo haré teniendo en cuenta y poniendo como ejemplos la creación de una aplicación tipo Facebook. Veamos.
Sea admiten, cómo no, opiniones críticas constructivas.
Se acabaron los tiempos de los grandes proyectos mal gestionados y mal ejecutados a precios desorbitados. Que tomen nota las grandes consultoras. Siendo así, pienso que se abre un resquicio de esperanza para las pequeñas empresas que hagan las cosas baratas, y eso no significa mal., todo lo contrario, significa bien: ajustando precios, sirviendo los proyectos on-time y evitando desvíos que supongan costes en la facturación. Equipos pequeños y cohesionados, las cosas claras y las ganas de hacerlo bien.
Siempre he pensado que el desarrollo de una aplicación web estándar es sencillo. Que lo complicado es la gestión de las expectativas del cliente, o la infraestructura de los sistemas (si crece desmesuradamente) o puede resultar complicado si nosotros, como creadores de la aplicación, nos complicamos la vida innecesariamente. Keep it simple, stupid!!
Me atrevo a decir que hacer una aplicación como Facebook es sencillo. Comienzo aquí una serie de posts en las que doy mi opinión de cómo debería encararse el desarrollo de una aplicación web desde cero. Una aplicación estándar. Lo haré teniendo en cuenta y poniendo como ejemplos la creación de una aplicación tipo Facebook. Veamos.
Sea admiten, cómo no, opiniones críticas constructivas.
viernes, 31 de octubre de 2008
Sistema informático de alarmas
Informa la agencia Europa Press de que el ministro de Justicia, Mariano Fernández Bermejo, ha propuesto la creación de un "sistema informático de alarmas" para evitar que se repitan casos como el de Mari Luz.
Resulta incomprenislbe y desesperanzador que en 2008 se planteen estas medidas en vez de estar implantadas desde hace años. Este gran invento que "supone que el funcionario entra en un sistema que le transporta de trámite a trámite y se encienden alarmas cada vez que un plazo se aproxima"sistema de alarmas" no es más que un sistema de workflows.
¿Qué son los workflows (flujos de trabajo)? En el ámbito de las tecnologías de la información y la comunicación (TIC), no son más que procesos dentro de una aplicación que "automatiza la secuencia de acciones, actividades o tareas utilizadas para la ejecución del proceso, incluyendo el seguimiento del estado de cada una de sus etapas y la aportación de las herramientas necesarias para gestionarlo" (Wikipedia).
Los workflows en el ámbito de las TIC exiten desde que existen las TIC, y los funcionarios de alto rango del Gobierno deberían saber que las TIC no existen desde que existe la Web 2.0, ni desde que se creó Google, ni desde el año 2000, ni siquiera desde que nació Internet, sino mucho antes (IBM tiene algo que decir al respecto).
Implementar un sistema de flujos de trabajo es tan sencillo como definir el conjunto de estados en los que puede estar una entidad. Por ejemplo: un documento (entidad) puede estar en varios estados, borrador, a revisar, revisado y publicado. Además de definir qué debe pasar para que se cambie de estado, un usuario-revisor revisa el documento y lo notifica pulsando el botón "Revisado".
Crear una herramienta desde cero es sencillo. Configurar una herramienta de workflows es sencillo. Veremos cuantos millones de euros y cuanto tiempo se necesita para crear ese "sistema informático de alarmas", si es que al final se pone en marcha.
Resulta incomprenislbe y desesperanzador que en 2008 se planteen estas medidas en vez de estar implantadas desde hace años. Este gran invento que "supone que el funcionario entra en un sistema que le transporta de trámite a trámite y se encienden alarmas cada vez que un plazo se aproxima"sistema de alarmas" no es más que un sistema de workflows.
¿Qué son los workflows (flujos de trabajo)? En el ámbito de las tecnologías de la información y la comunicación (TIC), no son más que procesos dentro de una aplicación que "automatiza la secuencia de acciones, actividades o tareas utilizadas para la ejecución del proceso, incluyendo el seguimiento del estado de cada una de sus etapas y la aportación de las herramientas necesarias para gestionarlo" (Wikipedia).
Los workflows en el ámbito de las TIC exiten desde que existen las TIC, y los funcionarios de alto rango del Gobierno deberían saber que las TIC no existen desde que existe la Web 2.0, ni desde que se creó Google, ni desde el año 2000, ni siquiera desde que nació Internet, sino mucho antes (IBM tiene algo que decir al respecto).
Implementar un sistema de flujos de trabajo es tan sencillo como definir el conjunto de estados en los que puede estar una entidad. Por ejemplo: un documento (entidad) puede estar en varios estados, borrador, a revisar, revisado y publicado. Además de definir qué debe pasar para que se cambie de estado, un usuario-revisor revisa el documento y lo notifica pulsando el botón "Revisado".
Crear una herramienta desde cero es sencillo. Configurar una herramienta de workflows es sencillo. Veremos cuantos millones de euros y cuanto tiempo se necesita para crear ese "sistema informático de alarmas", si es que al final se pone en marcha.
Suscribirse a:
Entradas (Atom)
Entradas
