¿Cuál es la mejor manera de permitir que un cliente contribuya a un proyecto?

Esta será la respuesta menos favorita, pero, sin embargo, ¡aquí está!

Es arriesgado (tanto como permitir que un novato conduzca un auto nuevo), pero no es una mala idea.

  

Comprende por qué quieren hacer esto: no es que tengan repuesto   Recursos, es solo para hacerse sentir bajo control.

Lo que debes hacer es lo siguiente:

1. Eduque a su cliente: el software es más que un código. Si quieren participar, permítales revisar primero los aspectos arquitectónicos, los diseños, etc. Plantéeles preguntas y muéstreles las implicaciones de las elecciones que hacen antes.

2. Siempre debe regresar con opciones sobre pro / contras sobre los enfoques (y documentar bien estas reuniones), pero debe permitirles que tomen algunas decisiones. Al menos comenzarán a apreciar que no saben mucho, o se apropiarán de sí mismos.

3. Puede crear un espacio separado, como ramas, para que puedan codificar lo que quieran, las cosas se deben probar debidamente antes de cometer o fusionar.

Aunque sé que pueden ocurrir complicaciones, cada problema es una oportunidad. Si todo va bien, su cliente realmente apreciará más los problemas internos y desarrollará una mejor confianza porque saben cómo usted ha hecho un buen trabajo.

PD: Para darte una idea, soy de la India; Y conozco muchas tiendas de TI donde la gerencia realmente no tiene mucha idea. Por lo general, no les importa (ni siquiera se sienten felices) que el cliente pone recursos adicionales para asegurarse de que el proyecto no vaya a la basura. Esto funciona muy bien para ellos; todos van con una mentalidad "Lo que digas señor!". Esto no es para degradar a mi propio compatriota, sino para mostrar que desarrollo conjunto no es una mala idea. Es después de todo, lo que muchos gurús de gestión la imagen es " Enfoque del consumidor " a los problemas de negocios.

Ouch ... Tienes la idea correcta, pero he visto lo complicado que puede resultar esto, y ambas partes sufren considerablemente. Actualmente estoy manteniendo una aplicación de este tipo.

Descubra las razones reales por las que el cliente considera necesario contribuir directamente al proyecto. ¿Es que ahora quieren que el proyecto se realice más rápido de lo que realmente se puede lograr? ¿Ya quieren cambios pero temen incurrir en costos adicionales para realizar cambios en las especificaciones o solicitar funciones adicionales? ¿Existe una lucha política en su organización en la que los recursos de desarrollo interno deseen más control y aportes en el proyecto o cuando estén buscando trabajo ocupado para desarrolladores internos? (este último golpea cerca de casa para mí)

Encuentra cuáles son sus verdaderas motivaciones y abordalas si es posible. El hecho de que incluso lo sugieran es una gran señal de advertencia de que los problemas están por venir. Trate de aliviar sus preocupaciones reales antes de aceptar tal cosa porque lo más probable es que lo que sucederá es que mantendrán el control del proyecto y lo eliminarán, o causarán un caos masivo y un proyecto fallido.

EDITAR: Desafortunadamente, el barco ha navegado por ti, pero no te desesperes todavía. Todavía hay cosas que puede hacer para minimizar en gran medida el dolor que vendrá. Pase lo que pase, asegúrese de estar seguro de que es UN SOLO UN SOLO ADMINISTRADOR DE PROYECTOS y PROPIETARIO DEL PRODUCTO y que esta persona está asociada con su organización / empresa. Esta persona debe tener la capacidad de planificar carreras, incluir o eliminar historias de usuarios y asignar tareas a los recursos de su empresa, así como de la empresa de su cliente. Pase lo que pase, asegúrese de que los recursos de desarrollo en su empresa no funcionen por separado de los recursos de sus clientes y, lo que es más importante, NO permita a los desarrolladores de su empresa informar a sus gerentes de proyecto o propietarios de productos. O aprovecharán por completo el trabajo gratuito no cubierto por el contrato o lo excluirán de su propio proyecto. Es una certeza.

Desde una perspectiva legal, básicamente estás preguntando "¿Cuál es la mejor manera de montar un burro con los ojos vendados a través de un campo de minas?"

Desde una perspectiva de programación, pediría más información. ¿Se puede implementar lo que el cliente está solicitando utilizando algún tipo de sistema EAV definido por el usuario o con enlaces que se pueden agregar al sistema? Idealmente, me gustaría mantener el código del cliente lo más separado posible del suyo por varias razones.

Alguien que normalmente está en el rol del cliente aquí interviene. Honestamente, no tendría este problema porque si llegara tan lejos estaría en mi control de código fuente, usando mi configuración de CI y mi configuración de control de calidad para probar cosas. Este arreglo puede ser bastante difícil de configurar: los asesores me rechazan mucho, especialmente para que todo funcione. Teniendo proceso se interpone con las horas facturables que parece.

Creo que tu perspectiva es, honestamente, un poco sesgada. Primero, tenga en cuenta que no se trata de su código base, sino de nuestro código base. La segunda es que, en la mayoría de los casos, la tienda de TI del lado del cliente tiene una motivación mucho mayor para asegurarse de que este producto funcione como está diseñado y que sea fácil de mantener, administrar y brindar soporte en el futuro. Bucear de nuevo para corregir errores es no más horas facturables para nosotros, a diferencia de la mayoría de los consultores. Además, construir cosas para que sean fácilmente configurables y fracasen de manera predecible es mucho más importante cuando usted posee el lado de operaciones de la moneda también. Es posible que termine con un proyecto de mayor calidad porque parte del personal de desarrollo no está limitado por las horas facturables.

En cuanto a cómo hacer que funcione, DCVS es definitivamente el camino a seguir si se puede hacer que suceda. Elegir algo neutral (bitbucket, github) puede ayudar. Tener IC en su lugar también es un regalo de Dios aquí: es más difícil que las cosas se salgan de control cuando todos saben que se salió de golpe en el último compromiso. Si puede forzar la implementación de elementos a través de CI, algo que normalmente tenemos que imponer a los proveedores, realmente puede garantizar que todos los cambios estén comprometidos. En cuanto a la capacitación, ¿has considerado emparejarte con el cliente por unos días? Esa podría ser una buena manera de establecer los lazos laterales que necesitará. En general, la mejor opción es convencer a todos que están en el mismo equipo. Porque están en el mismo equipo.

Parece que este es un problema de gestión, ya que es un problema técnico. He lidiado con situaciones como esta en empresas de consultoría y software. De un "¿Cuánto valor obtendrá el cliente del software?" y "¿Cuánto esfuerzo necesitaré para mantenerla después de la producción?" Esta es realmente una buena situación para ti. Muchos clientes insisten en que su gente esté involucrada. Sin embargo, tomará mucho trabajo.

Comenzando con el final en mente, necesitará una buena Declaración de trabajo . Esto indicará para qué estás enganchado y para qué están enganchados. Una matriz de Roles y Responsabilidades es un documento menos legalista que describe quién es el propietario de cada elemento, quién está involucrado y quién solo necesita Ser informado. Ambos suponen que tiene una Estructura de Desglose del Trabajo bien definida que figura en un nivel bajo (lo suficientemente bajo como para estimar) qué cada tarea es

En términos de creación, suele ser el orden inverso: Ámbito (que claramente ya tienes) - > WBS (que puede tener) - > Matriz de roles y responsabilidades - > SOW.

Una vez que haya definido claramente la propiedad, es hora de administrar el código y los entornos. Soy bastante agnóstico en herramientas de gestión de código. Lo que diré es que es vital hacer una revisión del código para todo lo que haga alguien que no sea el equipo central. Si la herramienta que está utilizando señala esto, mejor. Desea evitar que alguien que se aferre a algo que va en contra de las decisiones arquitectónicas clave tomadas anteriormente. El concepto de 4 ojos (2 ojos adicionales que revisan todo) es la decisión táctica más importante que puede tomar.

Los entornos también son dolorosos de manejar. Por lo general, he experimentado situaciones en las que "Hacemos nuestro trabajo en nuestro entorno, cuando terminamos, se envía al tuyo" y el proveedor y el cliente luchan a través. Tu situación suena más compleja. Le aconsejo que intente encontrar una manera de trabajar en su entorno hasta que el proyecto haya finalizado. Si puede encontrar una forma de capacitar al cliente en la gestión de sus entornos (no asuma que son buenos en esto) entonces mejor.

Un par de otras advertencias ...

1. No asuma que el cliente tiene la misma productividad que su equipo. (Obtendrá sorpresas hacia arriba en el conocimiento del dominio, hacia abajo sorpresas en la velocidad específica de su software.)

2. No asuma que el cliente conoce su metodología.

3. No asuma que el cliente comparte la ética de trabajo de su equipo. (He visto tanto sorpresas hacia arriba como hacia abajo.)

4. Pasa mucho tiempo entrenando y co-localizando.

5. Cada hora que dedique a enseñar al cliente a solucionar problemas ahorrará muchos días en el futuro.

6. Utilice al cliente para trabajar a través de su organización interna y encuentre expertos en preguntas de contenido y dominio.

7. Utilice al cliente para vender y entrenar a su organización.

8. Por defecto, involucrar a los clientes en su proceso de desarrollo lo obligará a pensar como una empresa de servicios profesionales. David Maister escribió el mejor libro sobre el tema. Incluso si solo el 20% es relevante para usted, vale la pena leerlo.

A pesar de todas estas advertencias, los clientes de sus equipos pueden hacer maravillas para acercarle a sus compradores. Estos clientes son los más propensos a ser futuras referencias. ¡Buena suerte en sacar lo mejor de esta situación!

A su cliente se le debería dar un recorrido de cómo se configura todo, debería haber sido un requisito para firmar en la primera fase. Debe hacer retroceder para que su cliente pueda editar cualquier cosa directamente, debe completar una solicitud de cambio que se ingresa en su sistema de seguimiento de problemas y se le asigna prioridad con el resto del trabajo. Dependerá de usted y su cliente decidir qué solicitudes están fuera del alcance del contrato. La forma en que esto sucede debe diseñarse en algún tipo de flujo de trabajo / documento de gestión de cambios, si no existe uno, le sugiero que cree uno y haga que su cliente acepte que este es el proceso mediante el cual puede cambiar las cosas y poner esto en práctica. escritura. De lo contrario, no hay mucho que puedas hacer aparte de orar, nada sale mal.