¿Cuánto deben interactuar los Desarrolladores con los Clientes? [cerrado]

7

Ha surgido una discusión filosófica en mi departamento en la que me gustaría conocer la opinión de p.se. Somos un departamento de desarrollo para 6 personas dentro de una tienda de TI para 60 personas. Todos los demás departamentos están creciendo RÁPIDAMENTE, y el nuestro ha sido del mismo tamaño (y no se ha reservado completamente en ese tamaño) durante algunos años.

Mi administrador, y el encargado de mainframe de la vieja escuela, sostiene que los desarrolladores nunca deberían tener CUALQUIER contacto con el cliente. Que toda la interacción con el cliente debe ser mitigada por una capa de Gestión de Proyectos. Afirma que esto le permite al programador el enfoque que necesitan para CÓDIGO, y protege la relación de la empresa con el cliente de las tendencias de espectro autista de Joe Average Code Monkey. (Mis palabras, no las suyas).

Su jefe, el propietario de la compañía, le dijo esta mañana que todas las personas de la compañía deben considerarse una extensión del departamento de ventas y que deben estar atentos todo el tiempo para obtener oportunidades de ventas adicionales. Para este fin, él piensa que los clientes deberían tener acceso más o menos completo a los desarrolladores directamente, en parte para que los desarrolladores tengan la oportunidad de escuchar oportunidades de venta.

Estoy en algún lugar en el medio, yo mismo. Creo que es bueno proteger a los desarrolladores de los clientes hasta cierto punto, pero en la práctica eso nunca será total. Y sí, cada trabajo en la empresa incluye ventas, pero eso no significa necesariamente que todos tengan la misma oportunidad para ello.

EDITAR: No somos una tienda ágil. A algunos de nosotros (tos) nos gustaría dirigirnos en esa dirección, pero por ahora supongamos que se trata de una tienda tradicional con contrato fijo de oferta.

EDIT2: La broma del autismo no fue graciosa. Lo tengo. Totalmente posible que las bromas del autismo nunca lo sean. Dicho esto: hay desarrolladores que tienen la capacidad de representarse bien a sí mismos ya sus empleadores y los desarrolladores que no tienen (actualmente) esa capacidad. Mi gerente tiene una preocupación real sobre cómo estaría representada la compañía si todos los desarrolladores estuvieran facultados estructuralmente para ser representantes de la compañía.

También es cada vez más claro al leer tus respuestas que el verdadero empujar y tirar aquí es entre cascada y ágil.

    
pregunta Dan Ray 17.08.2011 - 20:57

11 respuestas

14

Personalmente no trabajaría en ningún lugar donde no tuviera la oportunidad de contacto directo con el cliente. Tratar de resolver un problema con los requisitos cuando tiene que pasar por capas de PM y BA es doloroso y el mensaje nunca se transmite con claridad. Quiero que este acceso mejore el producto para que realmente refleje las necesidades de los clientes y no la interpretación de esas necesidades por parte de alguien que no sabe las preguntas correctas.

En mi respuesta, puede ser relevante que yo haga el trabajo ETL de la base de datos y, a menudo, una conversación de 5 a 10 minutos con la persona de TI del cliente puede resolver un problema de larga data con las importaciones o exportaciones. A veces nuestra gente de TI necesita hablar con su gente de TI. Esto es especialmente cierto si se trata de una importación delta o una que va de dos maneras. Tengo que entender su estructura de base de datos y sus necesidades, así como las necesidades de mi base de datos. Hablar directamente es la única forma de obtener esta información.

Sin embargo, no deseo que el cliente reciba mi correo electrónico y mi teléfono de manera rutinaria, ya que algunos de ellos llamarán directamente cuando no deberían hacerlo. Solo necesito hablar con ellos cuando hay un problema que no podemos resolver de otra manera. Y tiene que poder establecer límites para que no intenten aprovechar el acceso para obtener trabajo de usted que no están pagando. Siempre remito cualquier solicitud nueva fuera de los límites del problema que se supone que estamos discutiendo al lado de ventas.

Incluso cuando hablo directamente con el cliente, rara vez, si acaso, veo una oportunidad de venta adicional, mi cerebro simplemente no funciona de esa manera.

    
respondido por el HLGEM 17.08.2011 - 21:08
4

Creo que debería haber algunos puntos de contacto establecidos con el cliente. En la gestión de proyectos tradicional, esta persona es el director del proyecto. En Scrum, usted llamaría a esta persona el propietario del producto. En Programación Extrema, es el representante del cliente. Tenga en cuenta que en Scrum y XP, nada dice que esta persona tiene que pertenecer a la organización del cliente, pero solo debe tener la voz del cliente cuando llegue el momento de tomar decisiones.

Para mí, la mayor preocupación es el número de rutas de comunicación . El número de vías de comunicación en su equipo de proyecto se define como (N × (N-1)) / 2 donde N es el número de personas en el equipo de proyecto. Si todos los miembros del equipo tienen acceso de comunicación al cliente o al cliente, entonces N aumenta según la cantidad de contactos dentro de la organización del cliente, lo que aumenta considerablemente las rutas de comunicación. Es casi imposible saber quién sabe qué información, quién dijo qué cuándo y mantener toda la comunicación organizada.

Mi segunda mayor preocupación con la comunicación gratuita entre su equipo de desarrollo y su cliente es hacer un seguimiento de quién está diciendo qué en cuanto a la salud actual y el estado del proyecto, cumplir con las estimaciones en el calendario y el presupuesto, etc. Tener un punto de contacto principal garantiza que todas las personas ajenas a la organización de desarrollo sepan exactamente lo que sucede en el nivel apropiado de granularidad, y se aseguran de que cada miembro del equipo tenga todo lo que necesita para realizar las tareas que se les asignan.

  

Mi administrador, y el encargado de mainframe de la vieja escuela, sostiene que los desarrolladores nunca deberían tener CUALQUIER contacto con el cliente. Que toda la interacción con el cliente debe ser mitigada por una capa de Gestión de Proyectos. Afirma que esto le permite al programador el enfoque que necesitan para CÓDIGO, y protege la relación de la empresa con el cliente de las tendencias de espectro autista de Joe Average Code Monkey.

Estoy de acuerdo con su gerente, en su mayor parte. Sus desarrolladores están ahí para desarrollarse y sus evaluadores están ahí para probar. ¿Eso significa que uno de sus desarrolladores no puede ser un contacto con el cliente, un Propietario del producto o un representante del cliente? Absolutamente no. De hecho, podría ser útil tener a alguien con experiencia técnica involucrada en la interacción con el cliente, especialmente cuando se trata de ingeniería de requisitos, discusiones de viabilidad y programación (después de todo, los ingenieros son los mejores en la programación de tareas de ingeniería). / p>

Afirmar que su cliente debe estar protegido de sus desarrolladores es incorrecto, y quizás incluso ofensivo. Sus ingenieros deben tener el conocimiento y las habilidades que se necesitan para interactuar con los clientes (y con todas las partes interesadas en un proyecto). Es solo que no todos deben ser llamados a hacerlo.

  

Su jefe, el propietario de la compañía, le dijo esta mañana que todas las personas de la compañía deben considerarse una extensión del departamento de ventas y que deben estar atentos todo el tiempo para obtener oportunidades de ventas adicionales. Para este fin, él piensa que los clientes deberían tener acceso más o menos completo a los desarrolladores directamente, en parte para que los desarrolladores tengan la oportunidad de escuchar oportunidades de venta.

El propietario está absolutamente equivocado. Las personas sin ventas o educación o capacitación en marketing no deberían estar haciendo el trabajo de esos departamentos. ¿Podrían los ingenieros tener que interactuar con las ventas y el marketing? Absolutamente sí. Pero no es su trabajo vender software, es su trabajo crear software que cumpla con los requisitos de los interesados. Si todos sus desarrolladores están ocupados vendiendo y comercializando el software, ¿quién lo está diseñando, construyendo y probando?

    
respondido por el Thomas Owens 17.08.2011 - 21:22
2

Puedo estar de acuerdo hasta cierto punto con no estar totalmente protegido del cliente, pero los desarrolladores no deberían estar a la ligera como el maldito personal de ventas.

Un desarrollador es solo eso, alguien cómo desarrolla el producto final. Reunirse con el cliente varias veces es algo bueno, ya que permite a las dos partes resolver cualquier problema potencial que pudiera surgir al desarrollar elementos específicos. El cliente podría expresar lo que quiere directamente y los desarrolladores podrían expresar lo que es posible en un período de tiempo.

Donde esto puede salir mal es el contacto constante. Imagina que tu cliente es el tipo de persona que cambia de opinión cada dos días. Ahora imagine que el cliente envía un correo electrónico al equipo de desarrollo cada dos días con sus cambios de planes y cómo eso causaría estragos en el desarrollo del producto. Forzar al cliente a pasar por más "canales apropiados" para discutir los cambios en el producto permite a los desarrolladores enfocarse en terminar el producto y solo cambiar las cosas si realmente surge la necesidad.

    
respondido por el Glenn Nelson 17.08.2011 - 21:09
2

Mi opinión es que los desarrolladores no deben interactuar con los clientes directamente, sino a través de la administración cuando obtienen trabajo o comentarios o un departamento de soporte al cliente cuando tienen problemas de soporte. Los desarrolladores deben realizar tareas procesables y no deben tratar de averiguar qué quieren / necesitan los clientes a través del contacto directo (por ejemplo, correspondencia por correo electrónico). Eso debería dejarse en manos de la gerencia o de otros departamentos, como un departamento de ventas, para que puedan administrar la dirección en la que va el software y averiguar dónde encajan los deseos / necesidades de los clientes.

    
respondido por el Bernard 17.08.2011 - 21:10
1

Tu PM tiene razón. Una vez que su cliente tenga el número directo de desarrollo, el desarrollador se verá inundado de llamadas de soporte.

El PM debe ser lo suficientemente técnico para que él pueda actuar como una persona del medio sin que se convierta en un obstáculo.

Lo siguiente debe gritarse desde los tejados ... así que aquí va:

¡ESE ES EL TRABAJO DE LA PM! PARA ASEGURARSE, LOS DESARROLLADORES TIENEN TODO LO QUE NECESITAN HACER UN TRABAJO, Y PARA ASEGURARSE DE QUE PUEDEN FUNCIONAR SIN INTERRUPCIÓN CONSTANTE! EL PM FUNCIONA PARA LOS DEVS !!! ¡CUALQUIER PMS QUE PIENSE QUE EL DEVS FUNCIONA PARA ELLA ESTÁ INCORRECTO, Y QUE MANEJA EL PROYECTO!

    
respondido por el Morons 17.08.2011 - 21:19
1

Creo que generalmente es mejor tener un PM como búfer. Cuando no ha habido, he notado lo siguiente:

    El desarrollador
  • se ve abrumado por la forma no organizada y no tan pensada en que los requisitos se presentan cuando son directamente del cliente. Los buenos PM hacen una cantidad asombrosa de trabajo refinando las ideas en bruto del cliente antes de entregarlas al desarrollo. Pocos desarrolladores tienen tiempo para hacer esto y construir el producto.

  • el desarrollador ofende al desarrollador porque no está satisfecho con algún componente. El desarrollador ofende al cliente porque el desarrollador parece estar ignorando sus necesidades. Los PM proporcionan un canal de comunicación objetivo entre las dos partes que es menos probable que se caliente bajo presión.

Para que las cosas funcionen, sin embargo, los siguientes factores deben estar en su lugar:

  • El gerente del proyecto debe ser bueno. Tienen que tener la capacidad de ser un saco de boxeo para todos. Los clientes se sienten frustrados con los desarrolladores, los evaluadores se sienten frustrados con los analistas de negocios y los desarrolladores se sienten frustrados con casi todos :). El primer ministro debe estar allí para escuchar a todos y tratar de mantener a todos felices y productivos.

  • Los desarrolladores deben estar dispuestos a pasar por estrictas iteraciones de prueba. Dado que no habrá tanto contacto directo con el cliente, y ningún PM es perfecto para los requisitos de transporte, el cliente y los evaluadores deben ver tantas iteraciones como sea posible a lo largo del proceso, para verificar continuamente que el desarrollador está interpretando las especificaciones correctamente. En mi humilde opinión, a los desarrolladores que les gusta sentarse en su código hasta el final del proyecto, solo hacen preguntas sobre los requisitos, pero en realidad no liberan los entregables con frecuencia, no les irá bien con este tipo de estructura. No es culpa de ellos, pero creo que los desarrolladores con este tipo de estilo realmente necesitan interactuar con el cliente más directamente para crear un mejor bucle de comentarios.

Algunos desarrolladores odian la estructura del búfer de PM, pero me ha encantado. Tener a alguien en medio de un proyecto que es responsable de los requisitos es un salvavidas completo. ¿Quién más sería responsable? No se puede esperar que el cliente describa lo que quiere con los detalles requeridos, y usted no puede responsabilizarse mucho de la persona con el cheque de todos modos. El desarrollador podría ser responsabilizado, pero por lo general ya tienen suficiente en su plato sin tener que interpretar las divagaciones crípticas de los licenciados. Un buen primer ministro que amortigua todo el calor del cliente hace que el trabajo de un desarrollador sea mucho menos estresante en mi humilde opinión.

    
respondido por el Morgan Herlocker 17.08.2011 - 21:45
1

Parece que tu PM es un fanático del proceso de cascada mientras estás más en el campo de desarrollo "ágil".

No estoy seguro de si hay un lado correcto e incorrecto aquí, pero definitivamente me gusta más el lado "ágil". Hablo con los usuarios al menos una vez a la semana, observo lo que están haciendo, escucho sus problemas. Si es algo que el departamento de servicio puede manejar, les diré, pero a menudo veo un problema real de usabilidad o una característica faltante que probablemente nunca me habría alcanzado si la comunicación hubiera pasado por múltiples filtros de servicio / ventas / gestión de proyectos. / p>

Trabajé en compañías donde los desarrolladores estaban protegidos de los clientes. El resultado fue que los desarrolladores entregaron software que cumplía con las cartas de los contratos, pero no siempre fue útil. Peor aún, los desarrolladores se enorgullecían de las cosas que no tenían valor comercial. (¿Quién necesita una excelente navegación con el teclado en un sistema con pantalla táctil y sin teclado? ¿Quién necesita la funcionalidad de secuencias de comandos, si los usuarios del software no tienen el fondo o la hora o ¿La necesidad de usar scripting?) Los objetivos implícitos y no escritos del equipo de desarrollo nunca estuvieron "sincronizados" con lo que realmente necesitaban los usuarios. Y a menos que sus "desarrolladores" sean solo monos codificados a los que no se les permita tomar ninguna decisión, esto lleva a un tiempo de desarrollador perdido.

    
respondido por el nikie 18.08.2011 - 09:34
1
  

Mi administrador, y el encargado de mainframe de la vieja escuela, sostiene que los desarrolladores nunca deberían tener CUALQUIER contacto con el cliente. Que toda la interacción con el cliente debe ser mitigada por una capa de Gestión de Proyectos. Afirma que esto le permite al programador el enfoque que necesitan para CÓDIGO, y protege la relación de la empresa con el cliente de las tendencias de espectro autista de Joe Average Code Monkey. (Mis palabras, no las suyas).

El hecho de que él sostenga esta opinión no es porque sea el mainframe de la vieja escuela, y sus comentarios sobre sus compañeros programadores carecen de respeto en mi opinión.

Dicho esto, existen varias escuelas de pensamiento en términos de gestión de servicios con respecto a quién debería tratar con los usuarios / capas empresariales y no dependen necesariamente de la cultura de la que se trata su administración sino de la moda que se utilizó la última vez. tenías consultores de negocios en.

La posición de su propietario es insostenible porque es casi seguro que causará graves problemas en el alcance del proyecto cuanto más permita a los desarrolladores vender características a los usuarios sin pasar por algún tipo de proceso de priorización. No estoy realmente a favor de ello. Lo que probablemente necesite es una capa, no necesariamente el gerente de proyecto, pero como un gerente de cuenta comercial al que puede recurrir para sugerir características que pueden ser vendidas a sus usuarios o clientes si son prácticas, y alguien a quien también puede ir. Para si necesita la entrada de los usuarios.

    
respondido por el temptar 18.08.2011 - 10:16
0

El ingeniero principal generalmente debe interactuar con los clientes solo durante reuniones altamente técnicas (o las partes de las reuniones que son altamente técnicas); o, para discusiones técnicas de hoja de ruta. Por ingeniero principal, eso significa el mejor ingeniero del equipo, no el ingeniero principal para proyectos particulares.

El PM no siempre es responsable de conocer todos los acrónimos y decisiones arquitectónicas más recientes. El PM (y su gerente) pueden quedarse atrás por una o más generaciones de tecnología. Aquí es donde el ingeniero principal necesita cerrar la brecha.

    
respondido por el Jonathan Cline IEEE 18.08.2011 - 01:21
0

Hay roles en TI que deben ser utilizados y respetados. Cada rol tiene 0, 1 o más motivos de contacto con el cliente.

El motivo del contacto debe ser definido por el PM.

Las funciones correctas, como analista de sistemas, analista de requisitos y analista de negocios, deben asignarse a miembros del equipo capacitados bajo la supervisión del primer ministro.

La interacción con el cliente no es una habilidad trivial. Tanto la habilidad como la política del proyecto deben ser establecidas por el PM.

Las ventajas que deseas alentar son:

  • Relación positiva entre TI y negocios
  • Fuente de requisitos única o muy limitada
  • Recopilación de requisitos precisos

Cosas que no quieres que sucedan:

  • Hacer promesas al cliente fuera del plan / política del proyecto
  • Denegando los requisitos del cliente que pueden ser entregados
  • Perder el rastro de quién prometió qué
  • Requisitos de documentación inadecuados
  • Hacer que parezca que no se hablan entre sí
  • Hacer que el cliente pierda confianza en TI
  • Hay demasiados correos electrónicos que van y vienen sin integración

Entonces, para responder a su pregunta, los desarrolladores "designados" pueden interactuar con el cliente en los roles definidos por el PM y solo en los casos especificados por el PM (por ejemplo, creación de prototipos y pruebas conjuntas).

Espero haber dejado claro mi punto ...

    
respondido por el NoChance 18.08.2011 - 02:41
-1

He visto casos en los que un desarrollador ha interactuado con un cliente y ha tenido resultados desastrosos. También depende de la personalidad del desarrollador, algunos pueden ser agradables y discretos, mientras que otros pueden llevar al cliente a las lágrimas, donde los contratos se cancelan como resultado.

El PM / Propietario del proyecto es el radio en la rueda y si se producen cambios sin su conocimiento, el tiempo, el costo y el alcance se arrastran.

    
respondido por el Adm Tech 28.06.2014 - 01:43

Lea otras preguntas en las etiquetas