Blogia

softinspain

Programador vs empresario

En mi faceta profesional actual, tengo muchas veces complejo de esquizofrenia, soy a un mismo tiempo desarrollador y empresario, en mi propia empresa.

Como desarrollador quiero ir probando constantemente cosas nuevas: nuevas técnicas, nuevas herramientas, nuevos métodos, instaladores, bases de datos.

Pero como empresario siempre debo pensar si eso aporta valor a mi empresa, si me ayudará a vender más.

Actualmente estoy en una de esas fases, porque acabamos de terminar una versión del producto que tenemos, y estamos empezando a planificar la siguiente. Vuelven a surgir las dudas, si continuamos con la misma plataforma de bases de datos, si nos quitamos de encima ese generador de infomes que nos da tantos quebraderos de cabeza, si reestructuramos la base de datos para poder hacer eso que nos lleva de cabeza con la estructura actual, si reescribimos totalmente la aplicación (una burrada) con otro lenguaje.

Pero debo ser práctico y centrarme en aquellas cosas que aportan valor al programa, y por lo tanto, a mi empresa. A mis clientes no les interesa que este utilizando la última versión del servidor SQL TAL, o que lo esté haciendo con la versión 7.0 de tal compilador, a ellos lo que les interesa es que hemos mejorado las estadísticas, que hemos añadido un nuevo control de riesgo de clientes, que hemos añadido trazabilidad al programa, que puede añadir la imagen del producto, etc. Sin embargo a los clientes si que les aporta valor que mejoremos nuestros procesos de desarrollo, que incorporemos una herramienta para hacer tests.

¿Que opinais? ¿Debería dejarme llevar por mi parte técnica o por la empresarial?

Tablas auxiliares

No se si a vosostros os pasará tambien, pero en mis aplicaciones el número de tablas auxiliares crece de forma exponencial respecto a las tablas principales.

Si tomamos una tabla principal, digamos artículos, tenemos 5 o 6 tablas auxiliares, veamos:
- Linea negocio
- Familia
- Subfamilia
- Marca
- Estado (alta, baja, bloqueado, etc...)
- Color (por ejemplo)

Al final decidí hacer un mantenimiento genérico y único para todas estas tablas auxiliares, y es más, las metí todas en una metatabla con la siguiente estructura (mas o menos):

ID -> identificador único del registro
TABLA -> Que tabla es (FML, SBF, MRC, LNG, ...)
NOMBRE -> Descripción
ID_SUP -> indentificador del superior (para estructuras jerárquicas)

Luego utilizando vistas obtengo cada tabla auxiliar allí donde lo necesito.

¿Como lo haceis vosotros?

El modelo del usuario

En una de las aplicaciones que desarrollé, sin duda las más compleja que hecho jamás, trataba sobre una gestión del flujo de trabajo de una gestoría.

Se desarrolló la aplicación, se mostró a los usuarios, se les hizo una formación y se puso en producción. En este cliente estaba yo integrado en la empresa, por lo que ante cualquier eventualidad tenían solución inmediata, la mayoría de las veces.

De lo que se trataba era de desarrollar un nuevo sistema de gestión que consiguiera dos objetivos, aumentar la capacidad de procesamiento de la gestoría y conseguir mayor control sobre los procesos, para que al aumentar el volumen no se descontrolaran los procesos.

Pero hubo un problema, no involucramos a los usuarios completamente desde el principio, creímos, el cliente y yo, que nuestro modelo, nuestra idea de "workflow" era correcta, que era una buena solución para controlar el trabajo de la gestoría. Si que se les consultó, pero luego no se les mostró la evolución del programa, no se les hicieron pruebas para que opinaran, y eso fue un error.

¿Que ocurrió? Pues que los usuarios utilizaban el programa de una forma diferente a la que se diseñó. ¿Porque?, porque nosotros partimos, al diseñar el programa, de una premisa equivocada, que todos los documentos eran iguales, y lo son, pero no el 100%, si no un 70%, y lo que ocurre es que el 30% que falta consume casi el mismo tiempo de proceso que el resto, porque los documentos "problematicos" requieren de alteraciones en los procesos para adecuarlos a las particularidades de cada uno.

Moraleja: Ademas de dar solución a lo QUE necesita tu cliente, tienes que dar solución a COMO lo necesita.

"No me hagas pensar..."

Esta frase es el título de un libro que quiero leer, es un libro sobre usabilidad en web. Lo he visto como reseña al final del libro de Joel Spolsky "User Interface Design for Programmers", éste lo acabo de leer y he sacado muy buenas conclusiones, que estoy empezando a aplicar a las aplicaciones que desarrollo.

Una de las conclusiones es que los usuarios no leen, aunque es sabido por la mayoría de programadores no lo tenemos suficientemente presente, los usuarios no suelen leer los avisos, no suelen leer los manuales (bueno salvo como último recurso), por lo tanto, no les hagamos leer, no llenemos las aplicaciones con cuadros de diálogo llenos de texto, muchas veces incomprensible, vayámos al grano, simple por encima de todo.

Otra conclusión es que no permitas que los usuarios se equivoquen, porque no son los usuarios quienes lo hacen mal, es tú aplicación que no sabe responder a unas situaciones determinadas. Sobre esta conclusión quiero mostrar un ejemplo que he tenido recientemente:

Es una pantalla que sirve para introducir cobros de clientes, en la que se selecciona un cliente y se introduce un importe cobrado, y el programa va "repartiendo" ese importe por las facturas pendientes del cliente.

Cliente con facturas pendientes

Teníamos un fallo, un bug, resulta que si seleccionabas un cliente que no tenía deudas, igualmente podías introducir una cantidad cobrada, y el programa intentaba repartirlo entre las facturas pendientes (o sea, ninguna), no daba un error, pero no hacía nada y el usuario se quedaba con la duda de que había pasado.

La primera solución que se nos ocurrió (creo que es la primera que viene a la cabeza) es la de avisar al usuario que no hay facturas pendientes entre las que repartir la cantidad introducida. Pero eso no resuelve la "frustación" del usuario, porque él ha introducido una cantidad, la solución buena es evitar que la introduzca si no ha de hacerlo. ¿Como? pues desactivando los controles donde se introduce la cantidad, de esa forma no se puede hacer y el usuario lo "ve" antes.

Cliente sin facturas pendientes

En otra parte del programa tenemos una pantalla que reorganiza los ficheros, reconstruye los índices y, opcionalmente, hace unas comprobaciones de integridad y de consistencia. La opción de comprobar los datos, estaba mediante un check que el usuario seleccionaba, porque esta opción tarda un poco más, estudiando lo que hacen los usuarios, nos dimos cuenta que o se seleccionaba siempre (por si acaso) o no se seleccionaba jamas (por si acaso). Esto realmente es un fallo de diseño, porque no tiene sentido que se pueda seleccionar, siempre se debería hacer porque no es un proceso que esten haciendo habitualmente, y por lo tanto, cuando lo hacen es porque ha ocurrido algo (corte de luz, problemas con el disco, cuelgue de Windows) y no les importa que tarde un poco en hacerlo, total que hemos quitado el check y ahora siempre hace la comprobación de datos además de recostruir los índices.

En próximos posts continuaré hablando de más cambios que estamos realizando para mejorar el interfaz de la aplicación.

Producto vs proyecto

Durante mi "carrera" profesional siempre he desarrolado software, sin más, resolviendo lo que los clientes me pedían, no era consciente de que eso eran proyectos, no productos.

A partir de que en la empresa decidimos desarrollar un producto "estándar" empecé a darme cuenta de las diferencias entre desarrollar proyectos y productos.

En los proyectos resuelves problemas que te comentan personas que conoces, que tienes cerca, en un entorno conocido y sobre el que, en cierta forma, puedes intervenir para adecuarlo a la solución del problema. A cambio, no siempre se aplica la mejor solución (desde el punto de vista técnico) para el problema, muchas veces simplemente se soluciona, bien porque el cliente lo quiere para YA!!!! o porque sabes que no se va a utilizar mucho (a veces una sola vez).

En un producto... tienes que resolver problemas "abstractos" de gente que no conoces, de clientes que lo pueden ser del producto, sobre una plataforma determinada pero no sobre unos equipos concretos, debes dejar el software lo más abierto posible para que el usuario pueda "personalizarlo". Debes escribir código robusto, lo más que puedas, porque no sabes donde se va a ejecutar, no sabes la preparación "informática" de los usuarios. En definitiva, todo muy amplio, muy abstracto.

En un proyecto, estás a disposición del cliente (al menos esa siempre ha sido mi postura), te tienes que adaptar a sus necesidades cambiantes (porque cambian, verdad?), muchas veces se cancelan, o se congelan, determinadas funcionalidades porque se cambia de prioridad.

En un producto, debes escuchar a los usuarios, recoger información sobre sus necesidades, tener capacidad para sintetizarlas y extraer lo común, lo realmente útil y no "caprichos" individuales. Y en base a ésto realizar un plan de desarrollo, y seguirlo. Está en tus manos (en cierta forma) la evolución del producto (mal harás si no escuchas a tus usuarios).

Como veis las cosas son muy diferentes, por ello me costó mucho cambiar de "chip", acostumbrado durante varios años a atender a las necesidades concretas de un sólo cliente he pasado a tener que recopilar sugerencias, necesidades, estudios de competencia para decidir que funcionalidades se le añaden al producto y cuales se quedan en la recámara.

(Continuará ...)

Desarrollando "in situ" (II)

Uno de los aspectos negativos de trabajar en casa del cliente, es que este, al final, te toma como un empleado más, y si es una empresa poco (o nada) organizada, tu trabajo se ve afectado. Y eso en el desarrollo de software todos sabemos que significa, poca calidad, muchos errores. Por eso, hay que tener mucha "mano izquierda" para saber en todo momento como "capear" al cliente para "marcarle" los límites, que no se olvide que eres un profesional que le está haciendo un trabajo, con la particularidad que se lo haces en sus instalaciones. La gestión del tiempo es primordial, porque como te tienen "a mano", continuamente te están interrumpiendo, por ello, se deben marcar unas pautas para tener reuniones en las que tratar los temas de situación del desarrollo, quejas de los usuarios, nuevas necesidades, etc...

En el mayorista de informática para el que trabajé (ver artículo anterior), utilizábamos un método, creo que bueno, para mantener la comunicación con los usuarios y con los jefes sin que tuvieran que interrumpir el trabajo. Se utilizaba el Outlook contra un servidor Exchange para mantener una lista de tareas de desarrollo, separada por catergorías en las que se indicaba si era un error, si era una cosa nueva, la prioridad, etc...

A los usuarios les instruimos para que si encontraban un problema, hicieran una captura de pantalla (con el mensaje de error o con la pantalla donde estaba el problema) y lo enviaran junto con una explicación a una lista de correo donde lo recibíamos los desarrolladores, el responsable la gente de pruebas y los jefes, para que todo el mundo estuviera enterado. A muchos de esos mensajes se les respondía indicándo que se tomaba nota del error y se añadía a la lista, y a otros con la solución o explicación del problema.

Funcionar así fue muy bueno para todos, sobre todo por el asincronismo que proporciona el correo electrónico y el utilizar unas listas de tareas, cada implicado podía hacer su trabajo sin necesidad que los otros estuvieran presentes. Muchos de los que leais esto pensareis: "Vaya chorrada, así es como se trabaja en muchos proyectos!!!", pues aunque sea tan evidente, se de muchas empresas de "desarrollo" que no utilizan nada de esto, que funcionan a base de reuniones, de horas y horas de aislamiento. Lo que proporcionaba este sistema era un flujo de comunicación permanente con los usuarios, de esta forma ellos no se sentían "solos" y nosotros conocíamos los problemas reales.

Hoy en día, seguramente, montaría en el cliente algo como el bugzilla o como el FogBUGZ para mantener la base de errores, mejoras, comentarios, etc... Esto permite al cliente (al personal del cliente) formar parte del equipo de desarrollo de su propia solución, y eso es bueno, muy bueno.

Continuará ...

Desarrollando "in situ" (I)

Este es un primer artículo de una serie en los que quiero contar mis experiencias desarrollando en casa del cliente, "in situ".

Los proyectos que desarrollé lo hice como autónomo, no como miembro de una empresa.

Durante unos años trabajé para una empresa, tras lo cual, al ver que el rumbo que tomaba la misma no era el que yo creía como adecuado, decidí dejarla y continuar por mi cuenta, ya tenía experiencia al respecto porque en un periodo anterior ya había estado como "freelance".

Tras dejar la empresa se presentó la posibilidad de trabajar para un antiguo cliente, desarrollándole la versión Windows de una aplicación de MS-DOS que hice. Al mismo tiempo, otro cliente me llamó para que le realizara una gestión, un mini ERP, a medida.

Enseguida me vi en dos proyectos, a la vez, y totalmente diferentes. Uno de ellos era una gestión de documentos, realmente una gestión de los trámites de documentos (una gestoría administrativa) y el otro una gestión de una empresa comercial (un mayorista de informática).

El de la gestoría era (y es) mucho más complejo, porque se pretendía no solamente registrar datos sino hacer un "workflow" para controlar el proceso e ir mejorándolo progresivamente, de hecho gracias a la aplicación la empresa tiene la ISO 9002 sin problemas.

En el del mayorista, la complejidad residía en la cantidad de datos que se trataban y en el tiempo disponible para desarrollarlo, empecé en Agosto de 1.999 y estuvo en funcionamiento en Diciembre... (Aún alucino con lo rápido que se fue) Para diciembre no estuvo terminado al 100%, pero se puso en producción a falta de cosas adicionales, lo que era la actividad diaria estaba cubierta en un 70% y durante los primeros días de enero de 2000 estuvo plenamente funcional el trabajo diario. Respecto a la cantidad de datos, en aquellos tiempos se realizaban alrededor de 300 albaranes diarios, introducidos por un grupo de 10/12 televendedoras.

En el proyecto de la gestoría, al principio trabajaba desde casa, pero las cosas no funcionaban, no avanzaban lo suficiente. Con el mayorista, desde el primer día se trabajo "in situ", con reuniones casi diarias para estudiar la evolución, a poco de empezar se agregó una persona al proyecto, una persona del propio mayorista.

En el tema de la gestoría no funcionaba por culpa mía, por diversos motivos me embarque en soluciones técnicas que al final no sirvieron para nada y sólo fue una pérdida de tiempo para el cliente. Una lección que aprendí.

Tengo que destacar que para que un proyecto de este tipo funcione perfectamente, tiene que haber una implicación al 100% por parte del cliente, tiene que estar supervisando y probando constantemente el producto.

Sin saberlo, en 1999, en el proyecto del mayorista, estuve utilizando una pseudo programación extrema, ya que prácticamente a diario se entregaba al cliente una nueva compilación del programa que se testeaba inmediatamente y se corregía "ipso facto". Con la documentación justa, trabajando con el código. Utilizámos el FreeVCS que se integraba con Delphi para controlar las versiones del código y no "chafarnos" el trabajo. De esa forma conseguimos avanzar mucho, y en la dirección adecuada, lo único que nos faltó fue un set de pruebas, las "unit test", porque compilaciones diarias hacíamos, pruebas en casa del cliente se hacían, y un cliente en el equipo... Pues mas bien al reves, yo formaba parte del cliente. Como dice Joel Spolsky, no hay nada como comerse uno su propia comida.

Trabajar en casa del cliente, tiene sus inconvenientes, pero según mi experiencia, tiene muchas ventajas, sobre todo para el cliente. Todo depende de varios factores:
1) Que el cliente esté dispuesto a "ceder" parte del personal/tiempo para las pruebas.
2) De la "actitud" del desarrollador, debe estar abierto a las sugerencias del cliente.
3) Deben establecerse unos mecanismos de "aprobación" de sugerencias, no todo lo que diga el cliente se va ha hacer, al menos no inmediatamente. Hay que hacerle ver que es mejor utilizar un método para ello. Ya contaré como lo hicimos.
4) Hacer partícipe al cliente de los problemas que surgen, si optamos por ocultarselos, al final se vuelve en nuestra contra.

Fin de la parte 1, continuará ...

"La sombra del viento"

Va y mi segundo post no es de desarrollo, pero es que quería escribir sobre el tema.

Hace un par de semanas terminé de leer "La sombra del viento" de Carlos Ruiz Zafón, desde las primeras páginas me enganchó, pienso que es uno de los libros que más hondo me han calado (Junto "Sinuhe, el egipcio", "El juego de Ender", "El diccionario de Lemprirere", y unos pocos mas...).

Ruiz Zafón construye una historia no muy compleja, pero llena de detalles, llena de personajes creíbles y humanos, profundiza en sentimientos muy personales. A mí el personaje que más me gusta es el de Fermín, con su verborrea, sus recursos para conseguirlo todo, debido a su vida en la calle, me encanta.

Muy recomendable.

Primer post

Creo que el primer "post" que debo hacer es indicar las intenciones de este blog y presentarme.

Este blog prentende ser un lugar donde expresar mis opiniones sobre el desarrollo de software en España. ¿Porque? Pues porque me dedico a ello desde hace más de 10 años y quiero expresarlas.

Me llamo Jose Alberto Hernandis Talens, vivo en un pueblo de Valencia llamado Algemesí, y hace un par de años abrí, junto a un socio, una empresa de informática (un día comentaré todas las visicitudes que pasamos para abrirla y los errores que cometimos)

Temas que trataré:
- Pros y contras del software estándar y "a medida" (o producto vs. proyecto)
- Empresario vs. desarrollador.
- Métodos de desarrollo.
- Errores que hemos cometido y como los hemos solucionado.
- Control de errores en el desarrollo de software.

Debo añadir que actualmente desarrollo utilizando Delphi, utilizando como base de datos SQLServer, Firebird/Interbase y dBase.

Mi intención es publicar algo cada semana, pero seguro que no lo voy a cumplir, asi que, publicaré cuando tenga algo que decir, ni más, ni menos.

Espero que me leais.