¿Cómo puedo aprender a comunicarme mejor con colegas de otra profesión?

¿Son los libros el camino a seguir, o hay otras formas en las que puedo aprender más sobre cómo comunicarme mejor con estos colegas?

La forma en que describe originalmente su enfoque me hace algo pesimista sobre su viabilidad. Aprender todo lo que uno puede (o no ) posiblemente necesitar por adelantado para construir una mejor apreciación del oficio del programador podría llevar demasiado tiempo.

• Especificaciones de software, seguimiento de problemas, técnicas de estimación, enfoques de diseño y metodologías de desarrollo, pruebas funcionales y de regresión, deuda técnica y consideraciones de mantenimiento, etc., etc. Entrar en todo esto podría ser como beber agua de una manguera.

Creo que una forma más realista de comunicarse con los programadores para un no programador que solo desea comprender los conceptos y problemas más comunes involucrados en la creación de software son los 1:1 regulares .

Para obtener una referencia sobre cómo hacerlo, considere un excelente artículo The Update, The Vent y The Disaster . Este artículo está escrito desde la perspectiva de un gerente de equipo de desarrollo, pero en mi experiencia, un enfoque similar también funcionó en una colaboración entre un cliente/diseñador y un programador como usted describe.

... No estoy sugiriendo que cada 1:1 sea un asunto tortuoso para descubrir desastres emergentes profundamente ocultos, pero sí desea crear un lugar semanal donde la insatisfacción pueda aparecer silenciosamente. Un 1:1 es su oportunidad de realizar un mantenimiento preventivo semanal y al mismo tiempo comprender la salud de su equipo.

...El sonido que rodea al exitoso régimen de 1:1s es el silencio. Todo el escuchar, cuestionar y discutir que ocurre durante un 1:1 es mantenimiento preventivo gerencial. Verás cuando el interés por un proyecto empieza a decaer y tomarás medidas antes de que se convierta en insatisfacción laboral. Escuchará sobre la tensión entre dos empleados y moderará una discusión antes de que se convierta en una pelea a gritos en una reunión. Su recompensa por una cultura de 1:1 saludables es una clara falta de drama.

• ^{Un punto muy fuerte del artículo anterior es que es autosuficiente , en el sentido de que además de explicar los beneficios, también proporciona un conjunto de recomendaciones prácticas que básicamente le permiten a uno comenzar a practicar 1:1 regulares sin indagar en otras fuentes (aunque buscando la información adicional no hará daño, ya sabes).}

Con 1:1 regulares, podrá elegir y concentrarse en aprender temas particulares que son de importancia específica en cada momento dado. Si lo hace bien, si habla, pregunta y escucha atentamente, tendrá suficiente tiempo para encontrar y estudiar los recursos necesarios, sin verse presionado por asuntos de urgencia inesperados: " Su recompensa por una cultura de 1:1 saludables es una clara falta de teatro" .

_{Con respecto a los libros, ya que mencionaste Code Complete , probablemente no puedas equivocarte al usarlo como referencia general (aquí, estoy hablando de la Segunda Edición, la que estudié). Es una obra maestra, una visión general fundamental y bien presentada del desarrollo de software profesional que brinda un análisis profundo de cada área imaginable del mismo. Como ya lo tiene, considere hojear el capítulo sobre Prácticas de desarrollo colaborativo : según recuerdo, ha sido el más convincente de todo lo que he leído sobre estos asuntos hasta ahora.}

_{Code Complete es un recurso verdaderamente profundo, excelente para un estudio exhaustivo, pero precisamente por esto, realmente dudaría en recomendarlo a alguien que necesite una introducción rápida a los conceptos de desarrollo de software. Para este último, prefiero elegir Hechos y falacias de la ingeniería de software : un libro pequeño y fácil de leer. Las referencias proporcionadas en cada sección permiten un estudio más profundo del tema si es necesario. Lectura recomendada para aquellos interesados ​​en obtener el software correcto.}

Hay muchos libros geniales, como se indica en otras respuestas. Pero pedirnos recomendaciones no es el mejor enfoque: cada vez que he necesitado aprender más sobre el dominio de un experto en la materia, he ganado más al pedirle recomendaciones a esa persona . Usted y sus compañeros de trabajo son socios que trabajan hacia un objetivo común, y lo mejor para ellos es que usted aprenda más sin perder el tiempo en cosas que no ayudarán. Están en la mejor posición para guiarte.

Para la comunicación, es más importante comprender la forma de vida de otra persona o grupo que conocer necesariamente los puntos principales de todos los pasos de su profesión. Me centraría en:

• Historias de guerra : la gente no solo quiere contarlas, sino que escuchar atentamente le dirá mucho sobre cómo ven su trabajo, el entorno en el que trabajan y lo que es difícil o fácil en su mundo: todas las cosas clave que debe saber. colaboración. Además, el lado de las relaciones públicas: a la gente le gusta que la escuchen, y tener la oportunidad de contarle a un chico nuevo sus historias de guerra y que le respondan preguntas bien pensadas también generará sentimientos positivos hacia ti.

• Búsqueda de jerga : hay una TONELADA de jerga en este tipo de trabajo. Herramientas, lenguajes, procesos, metodologías, modelos y más, todos tienen nombres únicos. Algunos abarcan la industria (coloque una J delante de ellos, y probablemente sea algo relacionado con Java), algunos son exclusivos de la oficina (como el informe TPS en el espacio de oficina). Cuando he tenido que escalar aquí, Wikipedia es mi primera línea de defensa, seguida de pedir diccionarios de terminología y sitios internos que definen procesos.

• Code Complete, específicamente , es una lectura interesante porque se trata del negocio del buen desarrollo de software. Puede ser un buen recurso para eso, ya que se trata de buenas maneras de hacer las cosas, en lugar de los procedimientos básicos de las cosas. Una cosa a tener en cuenta es que cualquier grupo de software tendrá sus propias formas de trabajar que pueden o no adherirse a las mejores prácticas, así que tenga cuidado de hacer suposiciones unilaterales basadas en un libro como este.

• Hable con el programador y el cliente : a veces saber todo acerca de cómo alguien hace su trabajo es perjudicial. La parte importante es estar seguro de que se comunica con claridad y les deja la capacidad de hacer lo que hacen sin proporcionar obstáculos por ignorancia. Hable mucho sobre por qué quiere hacer lo que quiere hacer, pida recomendaciones, pida comentarios sobre si fue claro, pida que se reformule su solicitud u ofrezca lo mismo, y pregunte por qué, por qué, por qué.

• Pida ser testigo del trabajo : al hacer desarrollo de software, descubrí que había un estilo de trabajo y una química mágica en la forma en que uno trabaja en este campo que ningún libro podría resumir. La cueva de los nerds es parte de ella, pero hay más, y puede ser que solo al atravesarla entiendas cuáles son los verdaderos puntos débiles y los momentos gloriosos del trabajo. FYI: Rands in Repose no es un mal sitio para obtener más información interna del desarrollador, pero a menudo puede usar taquigrafía o metáforas culturales asumidas que pueden no ser universales para un extraño ... no estoy seguro, solo lo he leído con la vista de un interno.

Si no estás realmente interesado en convertirte en programador, leer libros de programación podría no ser la mejor manera de aprender a comunicarte con los programadores, ya que estarán llenos de cosas que probablemente no necesitarás.

En cambio, sugeriría simplemente preguntar acerca de los términos que no entiende a medida que aparecen, o escribirlos si no es imperativo que sepa la definición de ellos de inmediato, y buscarlos en Google más adelante. A menudo, mientras aprendes el significado de una palabra, te encontrarás con palabras relacionadas que no entiendes y también puedes preguntar sobre ellas o buscarlas en Google.

No debería llevarle mucho tiempo ponerse al día con la terminología más utilizada para su situación y ser capaz de comunicarse de manera efectiva tanto con el programador como con el cliente utilizando su lenguaje.

Personalmente, prefiero escribir los términos y buscarlos yo mismo más tarde, a menos que necesite saber el significado de algo de inmediato para hacer mi trabajo de manera efectiva, sin embargo, como mencionó Shana en un comentario a continuación, si es sincero acerca de no tener mucho conocimiento. , eso le da a los demás la oportunidad de usar palabras que es más probable que entiendas, y probablemente serán más receptivos a las preguntas rudimentarias que puedas tener.

Aquí hay algunas respuestas excelentes a la pregunta (original, específica), pero tal como se plantea actualmente:

¿Qué puedo hacer para comprender mejor los conceptos más comunes de otra profesión para poder comunicarme y trabajar de manera más efectiva con profesionales y colegas de ese campo, sin aprender realmente su profesión?

Sugeriría que este es un ejemplo de una situación más amplia que he encontrado con frecuencia, y no solo en la industria del software. Desde mi perspectiva, el objetivo del OP es crear un equipo eficaz y multidisciplinario en el menor tiempo posible.

Las barreras clave para esto suelen ser comprender los procesos de flujo de trabajo que utiliza la otra profesión, así como la jerga que se emplea.

Tiende a ser mucho más difícil cuando se trata de áreas que son distintas y separadas, pero un "lego" lo vería como lo mismo (geología y geofísica, por ejemplo), tal vez como parte de la necesidad de una identidad separada que puede originarse cuando las personas están primero. entrenado.

He resuelto esto de varias maneras (como miembro del equipo, líder y gerente) y aunque la autoeducación (a través de libros, videos, blogs, artículos) y las discusiones individuales han desempeñado su papel, hemos También ponga en juego algunas otras cosas clave en las que podría valer la pena pensar.

• tenemos un wiki interno que se utiliza para definir la jerga, la terminología, los flujos de trabajo y los procesos. Es parte de hacer que lo que hacemos sea sólido, pero es un excelente lugar para comenzar.
• enviamos personas a cursos de capacitación (formales) (una introducción a XXX)
• tenemos presentaciones cortas ocasionales sobre cómo y por qué las personas trabajan de cierta manera

Para equipos pequeños y ágiles (¡en el sentido no relacionado con la codificación!) que dependen de expertos técnicos que trabajen bien juntos, estos enfoques pueden ayudar a reducir parte del tiempo de la curva de aprendizaje.

Sin embargo, sugeriría que todas las "facciones" del equipo deben encontrarse en el medio para que esto sea efectivo.

Desde un punto de vista organizativo, puede ser útil obtener la aceptación de la gerencia, especialmente si se necesita capacitación o tiempo "superficial". Esto puede ser un desafío, sin embargo, es de esperar que vean la necesidad de poder crear un grupo multidisciplinario efectivo, sólido y escalable.

Si bien hay muchos buenos libros sobre desarrollo, una de las mejores series de libros que he visto para que los principiantes y las personas simplemente interesadas en el desarrollo se pongan al día en la jerga y realmente aprendan un poco de desarrollo es la serie Head First de O'Reily. .

He incluido algunos de mis favoritos para compartir con los estudiantes a continuación.

1. Head First Design Patterns : excelente para aprender los conceptos básicos de los patrones de diseño que los desarrolladores usan todo el tiempo
2. Head First Software Development : comience aquí para obtener una excelente descripción general del proceso de desarrollo de software y la jerga
3. Programación Head First : esta es una guía para estudiantes y usa Python, pero también es un excelente lugar para comenzar
4. Diseño y análisis orientados a objetos Head First : excelente para una comprensión más profunda de estas técnicas que a menudo surgen cuando se trabaja con desarrolladores.

Ahora sé que la serie de libros puede parecer un poco cursi al principio, pero confía en mí, son efectivos y realmente divertidos de leer. Si tuviera que elegir que comenzara con uno primero, ya sea el libro de Desarrollo de software o el de Programación solo para obtener la jerga y el proceso correctos cuando trabaje con su desarrollador.

Espero que eso ayude.

Si estoy en lo cierto, creo que no escribirá códigos extensos para el proyecto. Su objetivo principal es coordinar con los desarrolladores experimentados de vez en cuando.

• Es un gran proyecto como mencionaste, así que asumo que debe ir por módulos, es decir, todo el proyecto se divide en diferentes módulos que deben entregarse a tiempo.
• La programación no es más que romper la complejidad de los problemas del mundo real en estilo de código.
• Trate de comprender cada módulo y sobre qué base se divide el proyecto en diferentes módulos.
• Piense lógicamente por qué un módulo consume tiempo durante las fases de desarrollo.
• Coordine con el equipo e intente coordinar con cada miembro y, lo más importante, escuche lo que sugiere su compañero de equipo.
• Pregúnteles honestamente sobre los obstáculos que podrían enfrentar durante el proceso de desarrollo.
• Si cree que alguien necesita orientación/apoyo para la tarea que cree que en su nivel personal no es grande, intente con el miembro senior para que co-corporeice con el miembro para mejorar la productividad y reducir los plazos.

Para obtener información técnica, puede seguir algunos buenos libros de Ruby/Python o incluso algunos cursos en línea también se encuentran en la web. Verifique http://codeacademy.com/ -> bueno para comenzar también. Puede wikiar algún texto también como este sobre el desarrollo ágil Desarrollo ágil

Creo que estos puntos no solo lo ayudarán en el proyecto reciente, sino que también lo ayudarán durante otras gestiones de proyectos.

Respuesta corta: Pregúntale a tu colegio de programadores sobre estos temas que quizás te preguntes. Espero que tenga un ambiente amigable y él estará más que feliz de dirigirlo a la fuente correcta.

Además del libro clásico "Código completo", recomendaría encarecidamente considerar los - Hechos y falacias de la ingeniería de software . Ese libro es una especie de revelación y tiene una serie de hechos reales probados por estadísticas e investigaciones.

La práctica de construir software es una tecnología de "chico nuevo en el bloque". Aunque puede no parecer así para aquellos que han estado en el campo durante la mayor parte de sus carreras, en el esquema general de las profesiones, los desarrolladores de software son relativamente "novatos". En la breve historia del campo del software, se han identificado muchos hechos y se han promulgado muchas falacias. De esos hechos y falacias se trata este libro.

Sin embargo, dependiendo de los requisitos de la aplicación en la que esté trabajando, es posible que también necesite obtener un libro específico de framework/idioma.

Me gustaría desarrollar una mejor apreciación del oficio del programador, para mejorar la comunicación con mi programador, así como con el cliente.

Eche un vistazo si hay Code Camps en su área donde los desarrolladores se reunirán y construirán cosas durante el campamento que podrían ser bastante esclarecedores. También puede haber grupos de usuarios o Meetups donde los desarrolladores pueden reunirse que pueden ser útiles para socializar con otros desarrolladores para tener una mejor idea de ellos y tratar de hacer generalizaciones hasta cierto punto, aunque uno debe tener cuidado con la dependencia de generalidades que son 't universalmente aplicable.

¿Qué puedo hacer para comprender mejor los conceptos más comunes de otra profesión para poder comunicarme y trabajar de manera más efectiva con profesionales y colegas de ese campo, sin aprender realmente su profesión?

Puede buscar en el SDLC que puede ayudar con las grandes piezas de los proyectos de TI, aunque estaría más tentado a sugerir que conozca los términos de la jerga y luego hable sobre ellos en un entorno social para que pueda entender lo que significan. Kludge, hack y patch serían solo algunas palabras que me imagino que podrían malinterpretarse fácilmente si uno no conoce el contexto de cómo se está utilizando. La clave aquí sería retomar la jerga utilizada, que puede o no ser fácilmente conocida. Otra ruta es considerar investigar varias empresas dentro de su especialización, así como conocer un montón de siglas.

No subestime el valor de simplemente hablar con su colega programador.

Los libros están bien, pero tu objetivo aquí es mejorar tu capacidad para comunicarte con tu pareja. Considere la mejora en su relación si demuestra explícitamente un deseo de aprender más sobre lo que él o ella hace.

Además de su experiencia de aprendizaje, ayudará a su programador a sentirse como un socio valioso y, con suerte, lo alentará a aprender más sobre lo que hace , en especie.

Las sugerencias de libros anteriores son geniales y puedes aprender de ellas... ¡simplemente no olvides hablar con la gente también!

Además de las otras sugerencias de libros, recomendaría Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology , que describe el progreso de un proyecto de software (ficticio) desde la perspectiva de un diseñador de UX (Ellen Isaacs) y su desarrollador (Alan Walendowski), los desafíos que enfrentan y los compromisos que hacen, ya que tienen que trabajar juntos para lograr un objetivo común.

Como programador, he observado que la razón por la cual la comunicación con los no programadores es tensa es bastante simple.

Los programadores deben pensar con mucha, mucha precisión. Piensan de esa manera porque necesitan poder comunicarle a una computadora cómo operar y requieren instrucciones muy precisas.

La mayoría de la gente no piensa ni se comunica de esta manera.

Por ejemplo, alguien en ventas podría sugerir: "¿Sabes qué ayudaría? ¡Una nueva herramienta para generar clientes potenciales!"

El chico de la interfaz de usuario piensa: "Se verá así", sin ninguna cantidad determinada de precisión. Dependerá mucho de su instinto creativo/artístico y, si es bueno, de buenos principios de diseño con un cuerpo de investigación y datos respaldados.

El programador pensará: "¿Cómo se generarán los clientes potenciales? ¿Cómo se deben almacenar? ¿Cómo se deben presentar? ¿Qué pasa con la seguridad? ¿Qué tipo de seguridad? ¿Encriptación de capa de transporte simple o encriptación de datos? ¿Qué tipo de encriptación? ¿Qué tipo de bloque modo de cifrado?" etc etc etc etc

Los programadores necesitan pensar de esta manera porque deben construir la cosa desde cero. Es como un carpintero que tiene que pensar en el tipo correcto de tornillos a usar o en las ordenanzas de la ciudad mientras que los laicos se relacionan con ellas en generalidades como simplemente querer una casa.