¡Feliz día del programador! Ama a tus desarrolladores

Hoy es el día del programador, el día 256 del año. Y decidimos escribir una publicación no para nuestros compañeros desarrolladores, sino para aquellos que están junto a ellos y con nosotros. Para aquellos que nos llevan al calor del blanco, nos hace hervir el cerebro, desahogarnos y hablar nerviosamente sobre la esencia, la interfaz y las razones de la fecha límite. Para ustedes, estimados gerentes, empresarios, analistas, gerentes sin experiencia en TI y otros amigos de la oficina.

Si lees el Habr, lo más probable es que tengas que comunicarte con los programadores, pedirles que terminen la interfaz o el backend del sitio, cambien el código de análisis, cuelguen el siguiente fragmento de código en el encabezado del sitio, realicen mejoras en el software del cliente y mucho más. Entonces, ¿cómo encontrar un lenguaje común con el desarrollador para no pelear? Sabemos algo sobre esto.


Entonces, justo fuera de la lista.

Indique claramente sus requisitos. Siempre: no importa si solicita una pequeña selección de la base de datos o si prepara un proyecto de software serio para el cliente. No hay una descripción de las tareas en el formulario "Hazme una tarjeta de evento como un perfil de VKontakte" (hay muchos programadores que trabajan en VKontakte, contrata la misma cantidad y hazlo), "Bueno, haces todo, y yo elegiré" (hacer varias opciones para el programa es costoso, tú ¿El CEO estuvo de acuerdo?), “Hagamos una pelota así” (esta es una cinta y se necesitan bibliotecas especiales para su implementación). En primer lugar, debe comprender lo que desea recibir, y eso es lo que el programador necesita transmitir. Formule los requisitos en ruso, sin la oficina ni declaraciones pseudo-técnicas, y sí, preferiblemente por escrito.

Hablando de escritura. Este es el mayor invento en la historia de la humanidad, actualmente optimizado por computadora. Siéntase libre de usar papel en una conversación con el desarrollador:

  • haga bocetos y prototipos de lo que desea ver (si es un programa o una interfaz separada): hoy en día existen muchas herramientas para esto
  • usar mapas mentales para planificar el trabajo y crear un plan de proyecto
  • Describir la funcionalidad deseada de la manera más simple y detallada posible.
  • componga los términos de referencia (TOR).

Si esto le parece una ciencia complicada, busque en Google lo que hace un analista de sistemas y lo que usa en su trabajo: se puede poner mucho en servicio.

No necesita utilizar diagramas UML, diagramas de flujo y pseudocódigo si no los posee. En el camino había más de un gerente que estaba fascinado por los diagramas UML y dibujó en ellos todo lo que necesitaba: desde el plan de la reunión hasta la descripción de la campaña de marketing. De hecho, la herramienta parece lógica y conveniente, sin embargo, una sorpresa: UML fue creado para diseñar la arquitectura del software, y cada designación no es solo una flecha o un círculo, sino un componente muy significativo. Además, su programador puede no conocer UML y para él serán bloques completamente sin sentido.

La misma historia con diagramas de bloques en los que existen diferentes formas de bloques no por belleza, sino con pseudocódigo. No es necesario escribir en el estilo: " SI mes = abril, ENTONCES placa de datos campo 1 campo 2 campo 3 ". Esto es simplemente una tontería ilegible que no conquistará el servicio de TI, pero en el mejor de los casos se reirá.

Responde las preguntas a tiempo. Todos saben que los programadores son ociosos, están sentados y aserrando su código, nunca llegarán a los gerentes con cien tareas. Ok Pero aún así, cuando está llevando a cabo un proyecto, usted es responsable de ello, y le pasa la tarea al programador, tiene la conciencia para responder las preguntas a tiempo. No es necesario evitar llamadas y chats, marque los correos electrónicos como importantes y colóquelos en una carpeta separada. El programador pasa tiempo de trabajo interactuando con usted, puede tener uno simple debido a una pregunta sin respuesta, y esto es su culpa. Manténgase en contacto durante las horas de trabajo sobre los problemas que haya planteado ante otros desarrolladores. Por cierto, esto también se aplica a clientes de terceros.

Y, sin embargo, si le pidieron ver qué sucedió, evalúe el prototipo o pruebe la funcionalidad para ver si cumple con sus requisitos, no acuda a diez empleados vecinos y no lo hagan juntos. Por lo tanto, aumenta significativamente el tiempo hasta la finalización de la versión final.



Encabezado "Sus modales". Compara consultas similares en ruso e inglés. Trabajo, amor, dinero: todo es como todos los demás. Pero lo más importante, ¿cómo ven a los usuarios?

No culpe a los desarrolladores por todos los problemas. “El servicio de TI ha estado trabajando en el código durante tanto tiempo”, “La gente de TI está perdiendo algo de la fecha límite”, “Algo que el programador ha estado investigando en los conocimientos tradicionales por tanto tiempo”, ¿es familiar? Es fácil culpar el problema a una persona que interactúa con la tecnología; bueno, algo podría haber estado mal allí también. No, mantenga un estricto registro de tiempo, registre el hecho de la transferencia de tareas (puede hacerlo, por ejemplo, en CRM o en el diagrama de Gantt), deje que todos sean responsables solo de su trabajo.

Otro extremo: en caso de insatisfacción del cliente, rocíe cenizas sobre su cabeza y grite: “¡Qué estás haciendo! En busca de algunas críticas y traducir en ti! ¡Estamos perdiendo dinero y reputación! ¡Urgente! El pánico es fácilmente recogido por los colegas y la gerencia, los nervios del programador están al límite. Pero, de hecho, resulta que el puerto del cliente se ha caído o la velocidad de conexión se ha reducido. Aprenda a no culpar, sino a preguntar: “Vasya, Volga LLC ha enfrentado un problema: no hay conexión a la base de datos. ¿No puedes decirme qué podría ser, dónde cavar? " Siente la diferencia?

No dibuje ideas de todo el mundo en un borrador de trabajo. Google agregó filtros a la búsqueda, Yandex activó a Alice, Habr lanzó una nueva versión móvil, Salesforce activó la inteligencia artificial, RegionSoft lanzó CRM v.7 y ahora se apresura por el corredor para ofrecer introducir estas tecnologías en el proyecto de su empresa, porque eso es lo que hacen Gigantes de TI. Sin embargo, cualquier cambio debe introducirse en términos de factibilidad, relevancia y recuperación de la inversión. Y si las mejoras no benefician al usuario final y no generan ganancias, su implementación se convertirá en una carga adicional para el desarrollador. Prepare una justificación, cálculos, calcule el costo de introducir características y solo después de eso tome la decisión de comenzar a discutir el tema.

No evalúe la complejidad de un programador si no es un líder de equipo. "Necesitamos un módulo para calcular el volumen de una caja para enviar un paquete, aquí está el negocio de medio día, ¡sentémonos!" - El vendedor optimista Masha llama y se apresura a tomar el té antes de la tercera reunión. Al mismo tiempo, la propia Masha no sabe de dónde obtuvo esa tasa de tiempo. El programador tiene tareas de trabajo, problemas actuales, un rastreador de errores se cierne sobre él y un backlog parpadea a un lado, por lo que es entre ellos que buscará tiempo para resolver el problema. Y no es un hecho que el problema resuelto en 15 líneas de código pueda resolverse durante el conjunto de estas líneas: el tiempo toma la elección del algoritmo, la búsqueda de una solución, la selección de bibliotecas, el código de depuración, las pruebas automáticas, etc.

Lo mejor de todo, si tiene una regulación de la compañía que prescribe el procedimiento para solicitar compleciones / descargas / ubicaciones extraordinarias, etc. En este caso, todos se sentirán seguros y conocerán los plazos aproximados para resolver el problema. Y sí, establezca términos reales.



No intente influir en la pila de tecnologías de desarrollo si usted mismo no desarrolla nada. La situación es banal: el gerente va a la próxima conferencia intergaláctica de TI, escucha los informes y su cerebro de repente corta que hay ruido en todas partes alrededor de Go, y luego se le presenta un Gopher de felpa. Y ahora se para frente al departamento de TI, acariciando al gopher encontrado y habla sobre las ventajas que Go ha escuchado y cómo usarlo en nuestra empresa sangrienta.

La respuesta es simple. Los programadores son muy curiosos y aprenden sobre lenguajes de programación, DBMS, nuevos sistemas operativos, bibliotecas y marcos mucho antes de que otro participante de la conferencia escriba un informe sobre ellos. Al mismo tiempo, no solo son curiosos, sino que buscan ver si esta o aquella tecnología puede encajar para facilitar el trabajo y fortalecer la fe en el producto (porque los programadores también son extremadamente vagos en el buen sentido de la palabra). Por lo tanto, depende de ellos decidir qué arrastrar a la pila de desarrollo y qué dejarlo descansar hasta tiempos mejores y nuevas tareas. Y es poco probable que los superes en esto.

Tenga cuidado al escribir , no transmite entonación (sin embargo, esto se aplica a todos los colegas y a otros en general). Si escribe “Y me descarga en una hora))))))))))))))))” o “Mejor lo implementaría, me parece que se ralentiza))))))))))))))) " , Los corchetes no lo salvarán, se leerá el mensaje principal. Describa cualquier pregunta de trabajo clara y sin emociones. Si te gustó el trabajo, puedes regalar una barra de chocolate :-)



Después de la solicitud "por qué los programadores rusos son tan buenos" se fueron para estar orgullosos

No impongas tus métodos de comunicación. Hoy, cada uno de nosotros en una PC y teléfono móvil que funciona tiene una docena de herramientas de comunicación: Telegram, Skype, SMS, teléfono, Viber, correo, Slack, Jira ... Y cada uno de ellos tiene su propio círculo de tareas y suscriptores. Por lo tanto, si el programador solicita el fin de semana para escribir solo en el carrito, establecer tareas solo en Jira y llamar solo por Skype, tiene una buena razón para esto: sabe con certeza que no olvidará hacer el trabajo asociado con estos contactos. Pero su SMS "Comience el lunes el informe de pagos para la primera mitad del año" se perderá en los hilos de discusión de la campaña del domingo. Por lo tanto, es mejor escribir sobre esto en los programas de trabajo y no considerarse excepcional y el más eficiente en la comunicación y configuración de tareas. Créeme, esto no es difícil.

Si trabaja con programadores y hace programas para clientes externos, proporcione un comunicado. Es decir, en el momento en que el programa está listo y se inicia en la producción, debe tener todos los materiales promocionales, imágenes, presentaciones, acuerdos, etc. Esto es respeto por el trabajo del desarrollador, porque en una empresa de este tipo realiza la función de una unidad de producción. Si personalizaste a los programadores, hicieron todo a tiempo, y el lanzamiento se pospuso por tres meses, este es un gran desmotivador y desvaloriza al equipo como tal. Raramente hay un programador al que no le importe lo que sucederá con su programa en el futuro y no le interese cómo se comporta en el mercado y con los clientes.





Domestic Yandex tiene una visión completamente diferente de las cosas: incluso Ada Lovelace está clasificada entre los programadores de 1C, y en las vacantes principales están Assembler y Delphi (en todo caso, buscamos en un navegador anónimo). Pero lo principal es que hay 256 días, y es hoy :-)

Aprende de los programadores y aprende terminología. Una persona que sabe programar, piensa sistemática y lógicamente, sabe priorizar, ve la esencia de las cosas y conoce perfectamente el tema (no, bueno, en honor a las vacaciones, ¡puede exagerar un poco!). Tiene mucho que aprender, especialmente porque trabajas en el campo de TI, necesitas un dominio decente del aparato conceptual y del vocabulario profesional. Comuníquese en el trabajo, aclare cuestiones controvertidas, pregunte, recuerde los términos y sus definiciones; esto definitivamente no interferirá con su carrera. Pero la comprensión con un programador definitivamente será mejor.

Al menos no escribirás en el portal corporativo "Feliz día del programador", pero puedes escribir algo como esto:

"Chicos! ¡Feliz día del programador! Es genial que haya usted que confirme el código a tiempo, refactorice y haga que nuestro software sea aún más rápido e intuitivo, recopile las compilaciones a tiempo y las ejecute en producción. Les deseo compromisos exitosos, bibliotecas confiables, marcos convenientes y nosotros, usuarios adecuados. Haces que el mundo del presente sea un pequeño futuro. ¡Y te amamos!

Bueno, ¿has aprendido nuestra pequeña lección? Ahora, felicidades a sus desarrolladores.

Felices vacaciones, amigos! Team RegionSoft Developer Studio , desarrolladores de CRM de gran alcance y otro software para empresas, que saben mucho sobre la comunicación entre usuarios y programadores.



Nuestro canal de telegramas

Saludamos al canal principal de Nizhny Novgorod sobre eventos de TI y su sitio web it52.info . Ir a eventos, estar en el tema.

Si eres de Nizhny Novgorod
Chicos, una solicitud no estándar para Habr: estamos en Nizhny Novgorod buscando un vendedor, pero como un vendedor ++, para una empresa de implementación. Si tiene un joven residente de Nizhny Novgorod (por desgracia, solo una oficina) que quería ingresar a TI, pero no ingresó, deje caer un enlace a la vacante : estamos bien y después de nosotros la persona se va con gran experiencia (aunque algo no es se van, trabajan durante 10-15 años, ¡y es genial!).

Source: https://habr.com/ru/post/es423159/


All Articles