Análisis de proyectos gubernamentales: no da miedo / Sudo Null IT News
¿Con qué frecuencia ha escuchado durante las entrevistas que los candidatos a analistas rechazan su proyecto porque no quieren trabajar en el sector público, porque creen que la burocracia interferirá en gran medida con su trabajo, su desarrollo y el lanzamiento de un producto de calidad?
Hoy me gustaría compartir con ustedes nuestra experiencia, enfatizando que trabajar como analista en proyectos gubernamentales no da tanto miedo como podría parecer. Mi nombre es Georgy Dodeliya y gestiono proyectos internacionales de TI en la empresa JSC GNIVC. Trabajo en la industria de TI desde hace más de 12 años. Comencé como analista de negocios, luego me interesé en el análisis de sistemas y luego pasé a la gestión de proyectos.
Un poco de información sobre la empresa JSC “GNIVC”: llevamos más de 46 años en el mercado, nuestra plantilla supera las 1.700 personas, estamos representados en 8 ciudades de la Federación de Rusia. Nuestros productos son bien conocidos por usted: se trata de aplicaciones móviles para diferentes tipos de contribuyentes (por ejemplo, cuentas personales de empresarios individuales, particulares), autónomos, una plataforma para consultar cheques, un proyecto de oficina de registro civil, etc. También gestionamos un conjunto de sistemas para las necesidades internas del Servicio Federal de Impuestos de Rusia.
Me gustaría comenzar a presentar nuestra experiencia con una introducción al contexto: les contaremos en detalle las condiciones en las que comenzamos.
La primera condición es el cierre de todas las oficinas por cuarentena debido a la pandemia, que nos obligó a trabajar de forma remota, lo que generó una serie de problemas, por ejemplo: interacción con herramientas no probadas, trabajo en procesos antiguos, dificultades para formar y equipar un equipo. .
El segundo es un proyecto internacional, que implica la interacción con un estado extranjero. Era necesario establecer comunicación con colegas de las autoridades fiscales de otro país, y esto no fue fácil por una sencilla razón: no te conocen, no te conocen, de ahí los problemas de acceso, no te conocerán. compartir información contigo, etc., ya que eres su única persona “Varyags”.
En tercer lugar, es necesario un rápido inicio del desarrollo debido a que el contrato estatal se firmó antes de la pandemia.
Cuarto, el cliente tiene una jerarquía estricta. No es que no te den los requisitos, no irán a fumar contigo a menos que reciban permiso de arriba.
Quinto, los procesos de TI del cliente están bastante desactualizados. Por ejemplo, no hay roles: analista, probador, gerentes de proyecto. No estoy hablando de DevOps. El desarrollador “se acerca” a su gerente (un representante de la “empresa”), recibe una tarea de él y va a implementarla. Una semana después tiene una nueva tarea y así sucesivamente. Agreguemos que solo hay un stand de desarrollo y un stand industrial. Y mis colegas solo desarrollan sistemas OLTP. Como parte de nuestro propio proyecto, nos enfrentamos al problema de que es difícil construir un sistema analítico para encontrar (¿detectar?) infractores de la disciplina fiscal por una simple razón: la calidad bastante baja de los datos (debido al pobre desarrollo de requisitos comerciales para el sistema, los colegas lo perfeccionan constantemente y generan muchas “muletas”).
La sexta condición se refiere a un problema interno de Rusia que encontramos al contratar personal: se trata de un gran auge de las tecnologías de la información entre las “personas que no conocen las tecnologías de la información”. Imaginemos a un colega de negocios que realizó dos pequeñas producciones para desarrolladores, asistió a un par de capacitaciones, redactó un hermoso currículum y solicita el puesto de analista con altas expectativas salariales. Tuvimos que dedicar una gran cantidad de tiempo a filtrar a esos candidatos.
¿Por dónde empezamos? Desde la celebración de una serie de reuniones entre los líderes de análisis, desarrollo, pruebas y el director del proyecto. Discutimos las expectativas de cada rol a partir de los resultados del trabajo del otro rol, en qué forma se debe proporcionar este resultado.
Al final de una serie de reuniones, formulamos requisitos para el equipo de análisis. Compartamos.
En primer lugar, nuestro analista debe tener conocimientos en análisis de negocios. Siempre añadimos al contrato una etapa de estudio de los procesos de la automatización que estamos introduciendo, para no automatizar el caos.
En segundo lugar, el analista debe tener habilidades arquitectónicas. Para comprender qué hay “debajo del capó” del complejo de hardware y software del cliente, realizamos una auditoría técnica. Los analistas participan cada vez más en la formalización de los procesos que se crean en los departamentos de TI de nuestro cliente y ayudan en la comunicación y organización de auditorías en todas las demás áreas de infraestructura y seguridad.
El analista también debe tener conocimientos en análisis de sistemas. Una ventaja es el conocimiento de metodologías flexibles, el conocimiento de la notación BPMN, la capacidad de modelar modelos de datos, el conocimiento de los casos de uso y las historias de usuarios (en adelante, UC y US, respectivamente) y la interacción de integración. Pero, como comprenderá, la lista puede ser interminable y necesitamos encontrar un especialista en poco tiempo, por lo que cualquier combinación de habilidades adicionales nos convenía, estábamos listos para enseñar el resto.
Los siguientes acuerdos principales se referían a los lugares de trabajo. Los llamamos “elementos de trabajo de Jira”. Todo el desarrollo se dividió, según el sentido empresarial, en epopeyas, que a su vez se descompusieron en “historias”. Y para comprender claramente el progreso en la implementación de tal o cual “historia”, decidimos crear una subtarea para cada uno de los roles. Durante el trabajo, pueden aparecer tareas que no están directamente relacionadas con la función comercial; simplemente debes crear una tarea para ellas. Por ejemplo, prepararse para una presentación, redactar un PMI, trabajar con una nueva biblioteca. El equipo de pruebas también prepara casos de prueba y planes de prueba. Además, introducimos defectos.
Después de todo esto, desarrollamos el siguiente proceso productivo.
Pero primero, sobre la composición de los roles del equipo de producto:
· grupo de metodología, se trata de ex empleados de la Oficina Central del Servicio Federal de Impuestos de Rusia, que se trasladaron a JSC GNIVC y estudiaron cursos de especialización en productos;
· Analistas: tanto orientados al negocio como orientados al sistema.
· un equipo de desarrollo compuesto por frontend, capa de servicio y capa de datos (en nuestro trabajo utilizamos un enfoque de “lago de datos”);
· equipos de testers (manuales, de automatización y de carga).
El proceso se basa en principios Kanban, la visualización se realiza a través de un tablero Kanban.
Paso 1: completar el Backlog. El backlog es generado por el equipo de metodología. Los colegas escriben “historias” (cómo yo… quiero… eso…), complementadas con criterios de aceptación. Con cierta frecuencia se realiza un backlog-grooming, en el que participan todos los miembros del equipo o representantes de cada rol, se aclaran expectativas y criterios de aceptación y así se suma la “historia”.
Paso 2: planificación de tareas. A la “Tienda” se le asigna una prioridad u otra, y cae en la columna “Programada”.
Paso 3. Los analistas asumen tareas de la columna planificada. El analista comienza a recopilar requisitos y diseñar. Una vez que la colección y el diseño están completamente listos, envía su producción para revisión interna al equipo de análisis y al equipo de metodología. Así apoyamos el principio de V&V – Validación y Verificación.
Paso 4. Si la tarea pasó la revisión, ingresa a la columna “Análisis listo”. Al mismo tiempo, debe cumplir con los requisitos de Definición de Listo. Se trata de un conjunto de criterios que cualquier producción debe cumplir para considerarse lista. Por ejemplo, entre las producciones debe haber un guión demostrativo, así como un conjunto de criterios de aceptación ajustados para tener en cuenta el trabajo del analista.
Paso 5: desarrollo del código. Cuando el equipo de desarrollo anuncia recursos gratuitos, se programa una “revisión de la historia”, en la que el analista defiende su producción ante el equipo de desarrollo y pruebas. La tarea entra en desarrollo, se descompone y ocurre la magia de escribir código. Para pasar una tarea de “Desarrollo” a “Desarrollo finalizado”, debe cumplir con los requisitos de Definición de finalizado del equipo de desarrollo.
En la etapa de “Desarrollo”, el equipo de pruebas participa en el trabajo, que genera datos de prueba y diseño de prueba.
Paso 6. La tarea se transfiere a “Listo para desarrollo”, después de lo cual un analista y un especialista del producto realizan una demostración. Si todo es satisfactorio, habremos conseguido el objetivo de la historia: hemos solucionado el problema al principio. Luego pasa al estado de “Prueba”. Además, la “historia” puede pasar a “Pruebas” después de una demostración, incluso con un conjunto mínimo de defectos.
Paso 7. Ahora es el turno del equipo de pruebas. Antes de comenzar las pruebas, un analista y un especialista del producto realizan una revisión del caso de prueba. Se trata de una revisión de los casos de prueba para comprender si se cubren todas las variaciones y no hay nada superfluo, para no perder el tiempo. Según los resultados de las pruebas, la tarea se transferirá al estado “Prueba lista” si se cumplen los requisitos de los criterios de cálculo de la prueba, los llamados criterios de preparación basados en los resultados de las pruebas. Por ejemplo, un cierto número de defectos es aceptable con un cierto nivel de importancia, y así sucesivamente.
Paso 8: preparar el lanzamiento. Una vez que se ha acumulado una cierta cantidad de “historias” en “Testing Ready”, se combinan en un lanzamiento por decisión del equipo.
Paso 9: se instala el disparador en un soporte industrial. Una vez que se completa la instalación, las tareas se transfieren al estado “Implementado”.
¿Qué artefactos están preparando los analistas de nuestro proyecto?
Uno de los artefactos que utilizan es un sistema de colaboración de información para redactar documentación y una herramienta de gestión de proyectos para realizar un seguimiento de las tareas.
En el sistema de colaboración se crea una página llamada “Historial” a la que se le asigna un número según una máscara específica. El “quiero eso” y los criterios de aceptación de la herramienta de seguimiento de tareas se transfieren a la página. Quiero explicar de inmediato que la “Historia” es una página de una sola vez. Si necesitamos cambiar la misma funcionalidad, entonces no ajustaremos este “Historial”, crearemos uno nuevo, porque ya será una nueva característica comercial (con un nuevo “Quiero” o un nuevo objetivo). Luego este US se firma a través de UC (principal y alternativo), al final de la producción hay un guión para el demo. Si en el marco de “Historias” es necesario desarrollar nuevas formas de pantalla, entonces el analista desarrolla “maquetas” para ellas y las coloca en la sección GUI de la página “Historias”. Las “maquetas” se preparan en la macro draw.io, después de lo cual se envían al diseñador, quien luego las implementa en Pixso, adjuntando un enlace al “Historial”. Todos los comentarios y reglas para el funcionamiento de los formularios de pantalla son formalizados por el analista en forma de texto debajo de cada una de las “maquetas”, a las que se hace referencia en los pasos de la UC.
La UC, por supuesto, tiene condiciones previas y prórrogas. Un ejemplo de extensiones son los algoritmos. El algoritmo está escrito en una página separada en el bloque de algoritmos y está versionado. Las páginas de algoritmos suelen contener una breve descripción del algoritmo, su propósito, parámetros de entrada y salida, un diagrama de flujo de cálculo y una descripción textual paso a paso de este diagrama de flujo (posiblemente en forma de tabla).
Para garantizar que todos en el proyecto hablen el mismo idioma, además del glosario, utilizamos un modelo de datos de nivel lógico, porque en la etapa de diseño, los analistas no saben completamente de qué base de datos (relacional o no, dónde exactamente) se tomarán los datos para el algoritmo. Esto lo diseñará, por ejemplo, un arquitecto en colaboración con el equipo de Hadoop.
Si necesitamos otorgar algunos derechos o, por el contrario, reducir algunos accesos, entonces tenemos un modelo a seguir, también se describe por separado con versionado y una descripción de cada rol.
Existe un directorio de todas las alertas y errores, que contiene un cartel con el texto de la alerta o error y la indicación US.
También contamos con información regulatoria y de referencia, donde cada libro de referencia está en una página separada y también está versionado.
Si es necesario ampliar la lista de requisitos no funcionales para la GUI, por ejemplo, el tipo y tamaño de fuentes, colores, etc., se utiliza una página de cambios separada para esto. En esta página, cada requisito de la GUI se mantiene de forma atómica. Para otros subtipos de requisitos no funcionales, hay una página separada con secciones sobre subtipos y descripciones de requisitos atómicos (por ejemplo, versión del navegador, resolución de pantalla, etc.).
Si es necesario describir un informe o un formulario impreso, debe publicarlo en una página separada con una breve descripción: qué tipo de formulario es, algoritmos y reglas para completar cada una de las celdas, comenzando por los requisitos para fuentes, relleno y finalizando con una descripción de las reglas para completar los campos. Además, si este formulario es dinámico (puede cambiar el número de filas o columnas), entonces es necesario describir el algoritmo de cálculo. Un artefacto integral es el formulario de ejemplo adjunto.
Otro artefacto importante es la descripción de los contratos de integración. Los analistas describen la estructura de los archivos (solicitudes/respuestas) en forma de tabla, adjuntan sus diagramas y ejemplos.
Ahora me gustaría hablar brevemente sobre nuestros planes.
En primer lugar, actualmente existe un pequeño problema con las plantillas de documentación para casos del sistema. ¿De qué se trata? Para obtener un cálculo o una muestra, a menudo es necesario configurar un proceso ETL. Sería incorrecto agrupar todo esto en una sola historia de usuario; su desarrollo llevará mucho tiempo y supondrá una gran cantidad de costes generales (desde el control de la implementación hasta la larga coordinación con el cliente). Ahora se lanza como una tarea de desarrollo, lo cual no es muy agradable. Queremos crear plantillas de artefactos para este tipo de tareas y trabajar en ellas.
En segundo lugar, queremos configurar una macro que nos permita recopilar documentación GOST desde el espacio en el sistema de colaboración, lo que requerirá modificaciones mínimas adicionales por parte del analista y el redactor técnico.
En tercer lugar, miramos hacia otra macro. Nos permitirá definir claramente qué es un requisito de nuestro proyecto, asignarle un identificador, un conjunto de detalles y, lo más importante, conexiones. Obtendremos un seguimiento de requisitos que mejorará la calidad de los requisitos cuando cambien en el futuro.
