Get best of the week

Análisis de hoja de trucos: cómo "desenterrar" un sistema

En la Conferencia de analistas de los días de analistas # 10, el arquitecto hizo una presentación sobre cómo desenterrar el sistema heredado sin documentación o si hay documentación conflictiva ("4 reglas de un arqueólogo: cómo" desenterrar "el sistema, Evgeny Aslamov). Gran informe

Cuando un analista llega a una nueva empresa para un producto más o menos formado o incluso un sistema heredado (en este caso, ni siquiera sé si el analista tuvo suerte o no), a menudo también se ve obligado a recopilar una descripción de la funcionalidad como rompecabezas (en las empresas donde trabajé y donde se describió la entrevista) el producto fue cuándo? Casi nunca. Quizás tuve mala suerte, pero quizás viceversa).



Tuve que hacerlo. En algún lugar intuitivamente había un entendimiento sobre a quién preguntar. Algunas veces alguien del equipo del proyecto sugirió. Incluso fue así que aprendió sobre algún tipo de disparador en su funcionalidad después de un incidente del departamento de soporte. Algo se aclaró como parte de la actualización de la funcionalidad. Bueno, lo más importante es la autoevaluación y el uso del producto.

Después de ver todo esto, tuve la idea de escribir una especie de hoja de trucos para analistas, de qué manera gotear.

Solo que no serán 4 reglas como en el informe del arquitecto, sino 4 pasos:

Paso número uno Recopile toda la documentación para la solución implementada.


1. Idealmente, si contiene para cada bloque funcional:

  • una descripción de la necesidad de esta funcionalidad en cualquier herramienta (solo texto, etiquetas, algunos esquemas en cualquier notación);
  • descripción frontal: comportamiento del elemento, usuario wf;
  • descripción de la parte posterior: servicios internos, descripción de la base de datos y componentes;
  • Descripción de los servicios de integración, incluidos ejemplos de solicitudes y respuestas, estados de las respuestas.

2. Toda la documentación regulatoria y regulatoria que define los límites de los productos: Ley Federal, regulaciones, pedidos, proyectos.

3. TK / TP / especificaciones (subrayar lo necesario): un documento en el que se describieron los requisitos de funcionalidad.

4. Acuerdos registrados en los que puede rastrear cualquier deseo incumplido.

5. Manual de usuario / instrucciones en caso de que no haya una descripción de la necesidad para comprender cómo debe trabajar el usuario con el sistema.

Paso número dos. Pruebas


Independientemente de si existen o no los documentos anteriores, el siguiente paso debe ser probar el producto.

Simplemente siéntate y comienza a hurgar en todas partes y mira cómo reacciona el sistema. Al mismo tiempo, registra el comportamiento y observa momentos dudosos para aclararlo entre los poseedores de conocimiento secreto.

Paso número tres. Preguntas


Usted descubre desde el jefe (línea, gerente de proyecto, líder, etc. - subraye lo que es necesario) quién puede asesorar sobre los problemas. Estás preparando una factura de preguntas. Pregunte, describa la respuesta. Vas a dejar que todo pase por ti.

Paso número cuatro. Obtén lo que tienes


Usted procesa la información recibida de la manera prescrita en su empresa. Esto puede ser la actualización de documentos o la creación de una base de conocimiento en confluencia, tal vez incluso la actualización de tickets para padres en el rastreador de tareas, en general, un lugar conveniente para usted.

En el buen sentido, los siguientes pasos deberían ser: ir a trabajar


Pero lo que realmente quiero decir al final del artículo: la tarea del analista es dejar atrás la información estructurada.

Abandonar: esto significa emitir y colocar en un lugar público. Y no te des cuenta, como un colegial con nuevos conocimientos, y déjalos contigo.

Información estructurada: esto significa poner en los estantes todo lo que fue malo para usted.

¡No tengas miedo y ve por ello!

More articles:


All Articles