¿Cómo puede una persona no técnica aprender a escribir una especificación para proyectos pequeños?

¿Cómo puede una persona no técnica aprender a escribir especificaciones para proyectos pequeños?

Un amigo mío está tratando de externalizar algún desarrollo en un proyecto de estadísticas.

En particular, hace mucho trabajo en Excel y quiere externalizar la creación de scripts para hacer lo que ahora hace a mano.

Sin embargo, mi amigo es extremadamente no técnico. Es pobre en escribir especificaciones técnicas.

Cuando él escribe una especificación, se escribe de la forma en que describirías hacer algo en Excel (ve a esta celda y luego copia el valor en esa celda). También es demasiado detallado, y hace ejemplos varias veces. No estoy seguro si él describe correctamente los casos de esquina.

El primer proyecto que subcontrató fue un fracaso. Creo que sobredescribió algunos detalles, pero subdescribe los casos de esquina. Eso y / o el codificador que contrató no pensó en los casos de esquina y no hizo las preguntas apropiadas. No estoy seguro. Estuve en mensajería instantánea con él y me llevó media hora desenterrar una descripción que debería haber tomado cinco minutos o menos para describirla. Al final escribí los guiones para él, pero no examiné por qué falló su proceso con el codificador.

Me ha pedido ayuda. Sin embargo, me niego a involucrarme, porque tomar su especificación y traducirla en requisitos claros es 10 veces más trabajo que ejecutarla en una especificación claramente escrita.

¿Cuál es la forma correcta de aprender? ¿Hay recursos que pueda usar? ¿Hay maneras de que pueda aprender de pequeños proyectos de práctica de baja presión con codificadores?

La mayoría de sus guiones son estadísticos y orientados al procesamiento de datos. Por ejemplo, tome esta columna y ejecute un promedio sobre ella. Elimine estas filas en estas condiciones. Entonces, el desafío es diferente a especificar una aplicación web.

Veo dos buenos enfoques posibles para este problema. Sin embargo, es importante darse cuenta de dos cosas. Primero, la ingeniería de requisitos es un trabajo duro: convertir una idea en una especificación formal que sea suficiente para construir un sistema requiere mucho tiempo, esfuerzo y práctica. En segundo lugar, si tiene buenos requisitos (en cualquier formato, desde una especificación formal hasta historias de usuarios y casos de uso menos formales), será significativamente más fácil, más barato y más rápido construir el software (y compilarlo correctamente antes).

Si su amigo va a solicitar la creación de numerosas herramientas de software o tiene la intención de contratarlas, debe aprender a escribir los requisitos de software, al menos a nivel de los objetivos comerciales y el concepto de operaciones. Los dos libros principales sobre ingeniería de requisitos de software son de Karl Wiegers: Requisitos de software (2ª edición) y Más información sobre los requisitos de software: cuestiones espinosas y consejos prácticos . Esperaría que la mayoría de las personas que contrataría quisieran algún tipo de documento que describa el sistema, al menos a un nivel de objetivos comerciales o concepto de operaciones, y estos libros entran en eso. También abordan el cómo y el por qué de otros aspectos de la ingeniería de requisitos que sospecho que un buen desarrollador pasaría al principio del proyecto.

La segunda opción sería contratar a alguien con experiencia en desarrollo de software e ingeniería de requisitos (y tal vez incluso algún tipo de ingeniería de sistemas o arquitectura de sistemas) para comprender el espacio del problema y determinar dónde se necesitan soluciones de software y dónde no serían las soluciones de software beneficioso, escribir los documentos y quizás incluso supervisar o llevar a cabo el esfuerzo de desarrollo. Sin embargo, esto probablemente sería más costoso y equivaldría a contratar a un desarrollador de software a tiempo completo durante un período prolongado para desarrollar no solo el sistema solicitado, sino también los requisitos y la arquitectura necesarios.

Honestamente, no creo que lo que esté experimentando tu amigo sea tan poco común para alguien que no comprende el proceso de desarrollo de software. Tampoco creo que la culpa recaiga completamente en él tampoco. Si el primer proyecto de software no tenía buenos requisitos, los desarrolladores a los que se subcontrató deberían haber aclarado, refinado y documentado los requisitos. Francamente, tampoco estoy seguro de que sea la persona adecuada para involucrarse, si no está dispuesto a dedicar el tiempo o el esfuerzo para trabajar con el usuario / cliente no técnico y desarrollar buenas especificaciones técnicas (esto es un papel clave de cualquier persona que realice ingeniería de requisitos en cualquier disciplina de ingeniería).

Creo que la solución óptima es realmente una combinación de mis dos opciones. Creo que su amigo (y quizás usted también) debería aprender sobre lo que implica la ingeniería de requisitos y los beneficios que puede tener para un proyecto tener requisitos sólidos. Usted, como desarrollador de software, también debe familiarizarse con la ingeniería de requisitos y cómo obtener, documentar, analizar y administrar los requisitos según corresponda para los proyectos de software: es realmente una habilidad valiosa para cualquiera que trabaje en cualquier parte del ciclo de vida del software.

Cuando necesito especificaciones de un cliente no técnico, generalmente les pido que escriban en lenguaje sencillo qué es exactamente lo que quieren lograr. Como en "la aplicación debe hacer A a B cuando presiono C, pero solo si D". Bonificación extra por "porque D significa que ...".

De hecho, "toma esta columna y ejecuta un promedio sobre ella". Es un paso en la dirección correcta. Una mejor explicación sería "La tabla contiene esto y aquello" (si la estructura está predefinida); "Obtener un promedio de X". Básicamente, la forma menos técnica posible sin perder los detalles.

En otras palabras, describa la idea, no la implementación.

Luego, un programador atento debería ser capaz de comprender el propósito real de lo que se encargó de hacer y elegir los pasos correctos él mismo, haciendo preguntas para cualquier cosa que no sea obvia.

Si no hay nadie a quien le importe lo suficiente y entienda el proceso, el proyecto fallará en cualquier caso.

Puede intentar usar el enfoque del guión gráfico .

Pídale que escriba una lista de cosas ( historias ) que la aplicación tendrá que hacer y dentro de esa lista, profundice en la funcionalidad de cada historia.

Puede usar una herramienta como Asana para desarrollar el alcance y la funcionalidad del proyecto, e incluso interactuar con su desarrollador.

Traducirlo en requisitos claros es 10 veces más trabajo que ejecutarlo en una especificación claramente escrita.

Amén. Eso también explica por qué:

el codificador que contrató no pensó en los casos de esquina y no hizo las preguntas apropiadas.

Comprender los requisitos es la parte más difícil (y más costosa) de la mayoría de los proyectos de programación. Cuando una persona no técnica escribe requisitos, a menudo solo documentan la solución que desean reemplazar ("abra Excel, haga clic en la celda B3 ..."). ¡Lo mejor que pueden esperar es un duplicado exacto de su dificultad actual!

La forma más productiva que sé para evitar esto es alentar a esta persona a escribir Casos de uso ("usar" rima con "flojo"). En lugar de escribir requisitos, describa cómo se utilizará el sistema. Esto deja al desarrollador un margen de maniobra para sugerir una mejor solución que la que el usuario está haciendo ahora.

Parece que este problema se ve agravado por las malas habilidades de comunicación escrita por parte de su amigo. Él / Ella tiene que dedicar el trabajo a comunicar de manera efectiva sus ideas, o pagar al programador para que obtenga la información de ellas. Cualquiera de los procesos es doloroso y requiere mucho tiempo, pero hacerlo usted mismo es menos costoso que pagarle a alguien para que lo haga con usted.

En cualquier caso, esta es una dificultad común y frustrante en la que las personas creativas tienen una idea incompleta o son incapaces de describirla en menos de un millón de palabras. Esta persona debe tratar de encontrar un programador extremadamente paciente y perspicaz que esté dispuesto a llegar al fondo de lo que realmente está tratando de hacer y hacer que suceda.

el codificador que contrató no ... hizo las preguntas apropiadas

Esa es una receta para el desastre. Eso, y también la expectativa de que el codificador se pida. A los codificadores les gusta codificar, no comunicarse, esperar que rompan sus hábitos sin un incentivo es poco realista.

Si su amigo quiere hacer el trabajo, es mejor que establezcan un proceso que implique una comunicación continua con el codificador, y es su amigo quien tiene que desempeñar un papel activo en eso, no el codificador. "Muéstrame lo que se hace todos los lunes y establece dos horas para discutir esto todos los martes", cosas así.

• Para una introducción, proporcióneles algunas descripciones generales de las metodologías de desarrollo iterativo y ágil (lo harán los artículos de Wikipedia), para que tengan una idea de cómo debería ser.
   
• Para ayudarlos a comprender el fracaso pasado, proporcióneles algunas descripciones ligeras de Waterfall / Big Design Up Front (las que incluyen críticas, una vez más, lo harán los artículos de Wikipedia), por lo general hacen un trabajo bastante bueno al explicar cómo es difícil especificar las cosas correctamente en la delantera.

En mi experiencia, la forma más confiable de conseguir que el software funcione como lo deseaban los clientes no técnicos era comunicarse e iterar permanentemente las descripciones de las funciones, sin tratar de especificarlo de una sola vez.

La mayoría de sus guiones son estadísticos y orientados al procesamiento de datos. Por ejemplo, tome esta columna y ejecute un promedio sobre ella. Elimine estas filas en estas condiciones. Entonces, el desafío es diferente a especificar una aplicación web.

Es diferente: parece mucho más simple que especificar una aplicación web. Es un proceso lógico. Esto es lo fácil.

Su amigo simplemente necesita escribir los pasos que toma cuando realiza este proceso. Puede hacerlo como quiera, pero las cosas clave en las que debe centrarse son la precisión, la concisión y la claridad. No hay razón para que no se pueda hacer únicamente en texto como un manuscrito; se beneficiaría de una división lógica de componentes o tareas, y probablemente funcionaría bien como un diagrama de flujo o diagrama.

Ahora su amigo debe encontrar un analista / desarrollador competente y contratar sus servicios pieza por pieza. Necesita exponer sus expectativas: diariamente o al menos varias veces por semana, su amigo debe reunirse con el desarrollador y ver una demostración práctica del progreso. Su amigo le pagará al desarrollador por su tiempo durante estas demostraciones, pero valdrá la pena asegurarse de que el proyecto se ejecute según las especificaciones. Cualquier cambio en la especificación, es decir, cosas que su amigo omitió, debe ser negociado y probablemente agregado al precio cotizado.

Tenga en cuenta que dije "competente": esto no es lo mismo que "promedio", porque hay muchos desarrolladores "promedio" que no son competentes. Si su amigo solo consigue el programador más barato, o simplemente encuentra a alguien en línea, debería esperar problemas. No es para sugerir que las personas que encuentran trabajo en línea no son buenas, pero no emplearías a alguien sin una recomendación.

Tu amigo simplemente debe encontrar a la persona adecuada. En cualquier proyecto de software hay una necesidad de analistas, programadores, administradores de sistemas, evaluadores y gerentes de proyectos. Cuantos más de estos roles quiera 'externalizar' su amigo, más capacitado será el proveedor y más deberá esperar pagar su amigo.

Lamento ser el que te diga esto, pero no es el trabajo de una persona no técnica aprender a escribir especificaciones formales. El trabajo del desarrollador es entrevistar a la persona no técnica, tratar de destilar lo que la persona le dice sobre lo que está buscando, determinar qué es lo que el cliente realmente quiere (en lugar de lo que cree que quiere, lo que no siempre es lo mismo), cree un documento de requisitos relativamente informal (uno que esté bien estructurado pero que trate de evitar la jerga que el cliente no entenderá) y revise ese documento con el cliente.

Una vez que el cliente esté satisfecho con el documento informal de requisitos, puede usarlo como base para redactar una especificación de requisitos más formal que comience a entrar en más detalles técnicos sobre lo que se necesita.

Todo este proceso se conoce como "captura de requisitos" y constituye el primer paso en el proceso de ingeniería de software. En realidad, escribir el software es solo una parte relativamente pequeña de la ingeniería de software, un hecho que lamentablemente muchos desarrolladores de software olvidan. Otra cosa que parecen olvidar es que existe una gran necesidad de comunicarse con el cliente y mantener un diálogo con ellos durante todo el proceso para garantizar que las cosas sigan su curso.

En cuanto a la comunicación con personas no técnicas, es de vital importancia que intentes evitar usar la jerga de las computadoras y el desarrollo de software cuando hables con ellos. Si usan términos de jerga de su propio campo, entonces es importante entender lo que significan estos términos, por lo que es posible que desee elaborar un glosario del proyecto para obtener definiciones formales de estos términos. Después de todo, estás trabajando para ellos, así que es importante entender de dónde vienen.

en lugar de jerga, debe intentar usar formas no intimidantes de comunicarse con su cliente, los documentos escritos en inglés simple son una ayuda, pero muchas personas en el negocio del software están acostumbrados a escribir para computadoras en lugar de humanos y pueden encontrar esto difícil. Además, a los clientes no les gusta leer grandes montones de papel, sin importar cuán claro sea su idioma, por lo que es posible que desee recurrir a ayudas visuales. Los diagramas, wireframes y guiones gráficos son herramientas útiles aquí.

Pero en resumen, el punto central es que no es el trabajo de su cliente aprender su idioma, es suyo aprender su idioma.