Todo profesional de sistemas trabaja usualmente basado en un "brief", en el cual básicamente otra persona desglosó que requiere del desarrollador. Esto esta bien, pero no es suficiente si deseamos crear soluciones eficientes y durables.
Imaginen Coca Cola les arma un brief, quieren una intranet mundial. Si toman el brief y se apegan a sus necesidades, seguramente se topen con cuestiones al final, que jamás fueron previstas por lo de Marketing y demás departamentos.
Ejemplo Revisión de un Brief
Por ello es conveniente seguir algunas reglas base desde el lado de IT, que serán apreciadas y hasta facturadas $$$
Entendiendo la necesidad
Lo primero deben hacer, es leer el brief de punta a punta. No dejar interrogantes, comprender no solo el pedido, sino lo que conllevaría en dos niveles:
Para que lo quieren.
Como será usado.
Cuando respondan para que es que quieren el sistema, podrán determinar "pequeñeces" no previstas dentro del sistema. Quizá le falte un sistema de seguridad, quizá comentarios, etc...
Cuando comprendan por quienes y de que manera sea empleado, podrán darse cuentas de situaciones más graves, como la usabilidad, el entorno del sistema, la tecnología a emplear, etc..
Por ello pueden emplear las siguientes reglas para determinar problemas en líneas generales:
1. Para que lo quieren:
Crear un diagrama de flujo de datos para determinar toda la información "este allí".
Asegurar que los servicios que esten planteados en el brief cumplan con el objetivo.
Intenten mejorar los aspectos generales de cada servicio. Ejemplo: Si es un diario y quieren un editor de noticias, quizá quieran también un editor de ortografía.
Lleven el ambito del objetivo a toda la empresa para asegurar esta bien conectada con el resto del diagrama de datos y corporativo.
Permitanse pensar en mejoras posibles a los servicios. Ejemplo: Quizá el diario además quiera una aplicación para buscar noticias relacionadas en la web.
Piensen gerencialmente, y luego pongan a pruebas los módulos de reportes, estadísticas, etc... Adelanten el problema.
Creen finalmente una estructura de base de datos que intente resolver todos esos problemas para delinear si todo esta allí presente.
2. Cómo será usado:
Creen un flujograma de las actividades de los diferentes departamentos en el sistema.
Diagramen un flujo de cada sub-proceso de cada departamento.
Determinen si requiere seguridad especializada (Encriptación, algoritmos complejos, etc...)
Piensen cual sería el mejor esquema de pantalla. Diagramenlo en papel luego en la PC.
Intenten eliminarle clicks a sus interfaces (Menos clicks, menos problemas).
Piensen modular, intenten adaptar varios módulos similares en una sola pantalla.
Creen una usabilidad única para el usuario.
Piensen en que tecnología sería mejor llevar a cabo el sistema (AIR, Flex, VB, C++. lo que sea).
Diagramen la usabilidad según cada departamento (No es lo mismo RRHH que MKT).
Revisen sus esquemas de diseño para asegurar sea uniforme.
Empleen lectura iconográfica en las interfaces.
Desarrollen sistemas de guía y validaciones para asegurar la información.
Diagramen mejoras al framing general según la base de datos, flujos y experiencia de usuario.
Asuman lo impensable, hagan los sistemas a prueba de idiotas.
Vean el contexto general: Usuario, multiusuario, mono-idioma, multi-idioma.
Según su contexto planeen integraciones de seguridad para múltiples usuarios, charts de idiomas, aceptación de modismos.
Planeen si cada idioma, departamento, país puede integrar problemas con un proceso que es diferente para otros empleados. Unifiquen lo más posible.
En base a los resultados obtenidos de su arduo análisis, presenten una contra-propuesta funcional, un plan técnico, que resuelva lo que podrían ser problemas a futuro. Haganlo visual, presenten pantallas, esquemas, flujos, etc.. Más información, mejor orientado quedará.
A la hora de crear el sistema, recuerden que todos son humanos, tendrán fallas. Para evitar demoras por fallas lo mejor es:
Crear presentaciones intermedias según progreso.
Evaluar el tiempo de "reparación" de lleno en nuestro cronograma (Yo estimo un 20% más).
Una vez tengamos delineadas las etapas, aseguremosnos de tomarnos un tiempo para crear un manual de implementación técnica. De esta forma, variables comunes y funciones tendrán una lógica común (Como departamentos, nombres de procesos rutinarios, etc...).
Es una buena idea trabajar bajo un framework, adaptado para la empresa. De esta forma, no solo tendremos nuestro esquema de trabajo usual, sino que podremos plantearle reformas útiles y clases especializadas para la empresa en cuestión.
Ejemplo: La empresa debe generar reportes .sql todos los días. Ergo armamos una clase: Export SQL para lidiar con ese tipo de información de lleno. Pero también pueden existir necesidades más puntuales, como la comunicación entre departamentos, lo cual puede requerir generar un procolo de comunicación (Ejemplo: Todo mensaje debe tener las siguientes reglas... ).
Cuando se empiece el coding, no olviden como normal general, comentar como degenerados cada bloque de código. No solo para ustedes, sino que sea entendible para cualquier ser humano.
También una práctica que suelo hacer, es crear un sheet donde ir anotando los diferentes servicios creados donde se ubican y como serán empleados. De esta forma, al terminar se puede generar un reporte técnico con la entrega final, con todos los detalles del código.
Piensen a futuro
Es importante entender un buen sistema debe permanecer. Por lo cual creen el código pensando que será editado y bastardeado para evolucionarlo en miles de versiones nuevas con sistemas más inteligentes.
Adapten las siguientes reglas a sus proyectos para que vean la luz del mañana:
Código prólijo y bien identificado.
Creación del plan técnico arriba explicado.
Clases polimórficas.
Piensen mejoras ustedes mismos.
Ejemplo de un esquema simple de OOP
El punto 4, es especialmente interesante. Ya que nosotros hemos creado el sistema, somos a su vez, quienes podremos idear mejores evoluciones. Para hacerlo debemos estar atentos a los usuarios, controlar el sistema cada día y finalmente ser creativos para proponer soluciones nuevas.
Fácil implementación
Diagramen un esquema de instalación coherente para sus sistemas, de manera tal que hasta un mono sea capaz de migrar al sistema.
Es buena idea organizar la entrega final, con criterios como:
Instalación sencilla.
Manual de usuario (Interactivo +10 puntos).
Documentación online.
Servidor de soporte en línea (Help Desk, Manejo de crísis, etc...).
Previsión de fallas (Servidores de soporte, replicación de datos de respaldo, etc...).
Esquema de actualizaciones sencillo.
Comunicación con los usuarios del sistema.
Generación de encuestas de calidad entre los operadores del sistema (Parte de la comunicación).
Ups, debe decir al principio: "Cómo continuación al anterior artículo, "Entender una empresa antes de crear un sistema", este artículo hablará de como crear correctamente un brief desde el aspecto de un "IT GUY" " Por:Hernán
Saludos Hernan:
Gracias por compartir esta información con nosotros. Quisiera profundizar mas en el tema y saber que herramientas podría usar para realizar los procesos informados en el articulo. Muchas gracias.
merlyn333, puedes obserbar los programas en este post.
Respecto a Hernan, estan buenos tus post, sin embargo le veo mucha carencia en el sentido de realizar bien las cosas.
Esta correto contar con un brief y revisarlo, pero hay q obtener requerimientos, stakeholders (todo los involucrados), hay q crear un plan de tareas, determinar si es factible o no lleva a cabo la aplicacion, por lo que hay q analizar eso, y hay q ponerse de acuerdo con el clientes en la mayoria de los aspectos....
Ademas de esto hay varias cosas mas, pero todo tiene a ser ciclico, esto quiere decir, que se arranca con algo y a medida q se avanza se va aumentando el tamaño y verasidad de las cosas.
No solo con tener un brief, uno tendria q ponerse a trabajar.
Creo q faltan determinar muchas otras cosas, pero es bueno ir conociendo algunos elementos.
Saludos Por:bubudrc
requerimientos, stakeholders (todo los involucrados), hay q crear un plan de tareas, determinar si es factible o no lleva a cabo la aplicacion, por lo que hay q analizar eso, y hay q ponerse de acuerdo con el clientes en la mayoria de los aspectos....
De los requerimientos hablo justamente en el primer parrafo. A eso se refiere con leer y analizar que te esta pidiendo. El tema de quien esta involucrado hablo más extensivamente en el otro artículo, igual lo del plan de tareas y factibilidades.
Te cuento como para que sepas, los artículos tienen dos enfoques diferentes:
1) Entender y Analizar una empresa --> Desde el lado de consultor de Marketing, entendiendo factores de entorno no solo de necesidad. 2) Este artículo --> Desde el lado de un desarrollador, abordando más en detalle luego de ese "primer analisis".
Si juntas ambos obtendrás un buen resultado.
En cuanto a herramientas, las usadas son:
1) Balsamick MockUps 2) Para manuales uso Corel Draw X4, aunque puedes usar cualquier cosa que cree PDFs, Word incluso si gustas.
internet
marketing
negocios
sistemas
