Freelancers: ¿cómo se hacen para reunir los requisitos?


18

Como programador independiente:

  1. ¿Cuál es su proceso para reunir los requisitos de un cliente?
  2. ¿Cuánto tiempo te lleva el proceso de recopilación de requisitos? Sé que esto no se soluciona, y hay variables como qué tan rápido responde el cliente y tal. En general, teniendo en cuenta el retraso en las respuestas y tal, ¿cuánto tiempo lleva llegar al requisito final?
  3. ¿Qué canal de comunicación (correo electrónico, teléfono, mensajería instantánea, otros) utiliza para reunir estos requisitos?
  4. ¿Cobra por el tiempo dedicado a la recopilación de requisitos?
  5. ¿Hay entregables en su proceso de recopilación de requisitos? ¿Si es así, Que son?

Voto a favor ... Me encantaría saber la respuesta a esta también.
Georges Duplessy

Aparte del n. ° 4 (que puede ser parte del factor ROI), ¿esperaría que algo de esto fuera diferente si fuera un empleado?
JeffO

Respuestas:


21

1. ¿Cuál es su proceso para reunir los requisitos de un cliente?

entrevista, pizarra, llamada en conferencia, visita a la tienda, observación de trabajadores, entrevistas con el personal, reuniones, etc., lo que sea apropiado, lo que sea necesario para comprender el problema real , equilibrado con lo que sea que sean susceptibles y les dará tiempo para

2. ¿Cuánto tiempo te lleva el proceso de recopilación de requisitos? Sé que esto no se soluciona, y hay variables como qué tan rápido responde el cliente y tal. En general, teniendo en cuenta el retraso en las respuestas y tal, ¿cuánto tiempo lleva llegar al requisito final?

Obviamente, esto depende del tamaño del proyecto. No es inusual pasar 20 horas en requisitos y modelado para un proyecto muy pequeño (<100 horas), ya que debe comprender el contexto comercial lo suficientemente bien como para eliminar las capas de los problemas que presenta el cliente para llegar al problema real que tendrás que resolver para hacerlos felices

si esas 20 horas son dos días calendario o seis semanas depende de la capacidad de respuesta y disponibilidad del cliente, y de cuánto tenga que pensar entre sesiones (para problemas difíciles)

3. ¿Qué canal de comunicación (correo electrónico, teléfono, mensajería instantánea, otros) utiliza para reunir estos requisitos?

todos ellos

¿Cobran por el tiempo dedicado a la recolección de requisitos?

¡Oh sí!

Debe comprender el negocio del cliente, comprender y documentar sus problemas, y proponer soluciones que luego podrían llevar a otra persona para implementar . Esta es la parte de consultoría del proceso, y los consultores no trabajan gratis.

5. ¿Hay entregables en su proceso de recopilación de requisitos? ¿Si es así, Que son?

Por lo general, una lista preliminar de características, historias de usuarios, descripciones de casos de prueba, una estructura abreviada de desglose del trabajo (con estimaciones del proyecto), una lista resaltada de áreas / elementos poco claros / desconocidos para mayor discusión / investigación, y una lista de cosas ( información, recursos, herramientas, acceso, etc.) que necesitará del cliente con fechas objetivo. Todo esto se presenta como una propuesta con información básica sobre el negocio, los métodos utilizados para identificar los problemas, las limitaciones y las advertencias sobre la solución, las notas sobre los plazos y el ROI esperados, y una solicitud de seguimiento en una fecha específica. .


+1: excelente respuesta. sería muy interesado en ver algunos simulacros o plantillas que tienes (yo tengo el mío, pero me encantaría compararlo)
Steven Evers

@SnOrfus: todo se revelará en mi próximo libro "CITA: El cambio es la respuesta", que se publicará ... eh ... me pondré en contacto con usted sobre eso ;-)
Steven A. Lowe

Interesante, espero leerlo.
Steven Evers

@ StevenA. Lowe, ¿hay algún estilo estándar para escribir los documentos de recopilación de requisitos? encuentro esto ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/Requirements/… pero busco un ejemplo más descriptivo
AminM

@AminM: sí, hay muchos estándares de este tipo; tómelos con un bloque de sal: reduzca el documento de requisitos a solo lo que sea útil para su situación. Ejemplo: muchas veces, una lista de historias con descripciones de prueba de aceptación (formato BDD) es suficiente para capturar no solo los requisitos sino también los criterios de aceptación, y es mucho menos detallada que el "estándar" IEEE (que es muy cascada) )
Steven A. Lowe
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.