Obtención de requisitos como cliente

Parece que ha hecho un gran trabajo al detallar los requisitos. Mi sugerencia es evaluar por qué está contratando a la empresa externa. Si está buscando nuevas ideas e innovación, tenga cuidado de no 'decirle' a la empresa qué hacer en los requisitos. Si está buscando a alguien que realice el trabajo, debe detallar cada función y proceso.

Si no está seguro de por qué, vaya a su jefe y aclare eso. Si contrata a una empresa para que haga la molienda y es un grupo de diseño innovador (o al revés), tendrá dificultades para lograr el éxito.

No dibuje una línea entre usted y sus contratistas. En su lugar, intente configurar un entorno abierto donde la información sobre los requisitos fluya de manera efectiva entre todas las partes. El documento sobre los requisitos (ya sea un conjunto de diagramas UML o archivos de MS Word o lo que sea) tiene que convertirse en una plataforma viva para todas las comunicaciones entre todos los participantes del proyecto.

Y nuevamente, nunca se detenga para obtener requisitos y desarrollar el documento. Obtenga más información sobre los paradigmas de desarrollo de software iterativo e incremental . También recomendaría leer el área de proceso de Desarrollo de requisitos de CMMI para Desarrollo 1.3 .

Básicamente, hay dos enfoques que puede utilizar aquí:

1. Trate de ser bastante específico en términos de lo que necesita. Si conoce bien sus requisitos, intente escribir todo lo que sabe o cree saber. Es más importante poner su conocimiento en papel de alguna manera y no la forma exacta de ponerlo en papel. Así que agregue algunos casos de uso, pero solo mientras crea que tiene algún valor, lo que básicamente significa que tanto usted como un proveedor sabrán mejor lo que está construyendo.

   También tenga en cuenta que, a menudo, uno de los grandes problemas con respecto a los proyectos es el malentendido o la mala interpretación del alcance por parte de una de las partes o, en otras palabras, hacer suposiciones incorrectas. Esto significa que cuanto más detallado sea el alcance, mejor.

2. Como alternativa, puede simplemente aceptar el hecho de que el momento en el que menos sabe sobre el proyecto es al principio (en su caso ahora) y planificar ese alcance, en algún momento, puede cambiar. Entonces le gustaría encontrar un proveedor que quiera construir el proyecto de manera ágil. En resumen, construirán el proyecto de manera iterativa y usted decidirá qué es lo siguiente que debe agregar basándose en lo que ya tiene y no solo en la idea que tenía al principio.

   De esta manera, probablemente obtendrá lo que desea, pero también compartirá las consecuencias de los frecuentes cambios de alcance, ya que básicamente pagaría por ellos. Esto se debe a que este tipo de contratos se basan, al menos hasta cierto punto, en reglas de tiempo y materiales.

Como regla general, cuanto más seguro esté de lo que quiere obtener, más debe inclinarse hacia el primer escenario y viceversa: si no está exactamente seguro de lo que quiere construir, debe considerar el segundo escenario como una forma para llevar.

Para agregar a la excelente respuesta de Perry, me gustaría decir que el nivel de detalles que necesita en los requisitos depende completamente del nivel de competencia que tengan los contratistas de muchas maneras diferentes. Solo por citar algunos:

1. ¿Conocen el área temática?
2. ¿Por lo general trabajan a esa escala (está por debajo de su proyecto normal, justo lo que hacen, o es exagerado)?
3. como les gusta trabajar Algunos muchachos son buenos para obtener sus propios requisitos, otros necesitan que se los expliquen.

La otra forma de verlo por completo es adoptar un enfoque basado en el riesgo. ¿Cuáles son los riesgos de que las cosas salgan mal con un conjunto particular de requisitos, qué está en juego? Un capítulo que es más crítico para sus operaciones (mayor costo si algo sale mal) debe ser más detallado. Un capítulo que es menos crítico necesita menos detalles.

En una parte particularmente importante de sus requisitos, describir lo que espera el usuario (o al menos qué beneficios espera el usuario) podría ser una buena manera de transmitir la intención. Llámalo un caso de uso si esa es tu forma de pensarlo, pero no necesariamente tiene que ser tan formal como eso.

En cuanto a hacer el trabajo del contratista, no existe una regla que diga que no puede hacer su parte si tiene el conocimiento. Pero tenga en cuenta que algunos contratistas querrán presentar sus ideas, por lo que es posible que esté haciendo un trabajo que se desperdiciará. O puede darse el caso, si les gusta lo que has hecho, que te ahorre todo el tiempo y esfuerzo. Eso depende de la relación que construirá con el contratista elegido, de qué tan bien su trabajo se destaca por sí mismo y qué tan bien usted o su jefe negociarán el contrato.

Le ahorré a un antiguo empleador 8 veces mi salario anual al realizar 3 meses de pruebas que, por lo tanto, no tuvieron que repetirse con nuestro proveedor clave. No fue muy bien con nuestro proveedor, pero 1/ finalmente aceptaron los hechos y de todos modos consiguieron más negocios después; 2/ mis jefes estaban felices.

Esa pequeña historia personal solo para decir que las circunstancias pueden estar de su lado o no y ahorrarle dinero a su jefe siempre debe dar sus frutos, incluso cuando es a expensas de relaciones un poco más difíciles con su proveedor.