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:

1. Para que lo quieren.
2. 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á.

Coding

A la hora de crear el sistema, recuerden que todos son humanos, tendrán fallas. Para evitar demoras por fallas lo mejor es:

1. Crear presentaciones intermedias según progreso.
2. 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:

1. Código prólijo y bien identificado.
2. Creación del plan técnico arriba explicado.
3. Clases polimórficas.
4. Piensen mejoras ustedes mismos.

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:

1. Instalación sencilla.
2. Manual de usuario (Interactivo +10 puntos).
3. Documentación online.
4. Servidor de soporte en línea (Help Desk, Manejo de crísis, etc…).
5. Previsión de fallas (Servidores de soporte, replicación de datos de respaldo, etc…).
6. Esquema de actualizaciones sencillo.
7. Comunicación con los usuarios del sistema.
8. Generación de encuestas de calidad entre los operadores del sistema (Parte de la comunicación).

via Cómo crear briefs para proyectos de tecnología.