👨🏼‍🏫 💅🏻 ✌🏼 Mal consejo para el empleador. Cómo interactuar "correctamente" con el desarrollador 🦆 ◀️ 😼

He tenido suerte últimamente: trabajo para empresas donde los desarrolladores son realmente respetados. Pero este no fue siempre el caso; tuve que lidiar con diferentes enfoques de interacción. Me gustaría decir que la "moralidad salvaje" es cosa del pasado, pero las historias de mis colegas sobre sus lugares de trabajo anteriores y mis observaciones del mercado refutan esta afirmación.

Bueno, hablemos sobre cómo interactuar "correctamente" con el desarrollador, por ejemplo, personalmente conmigo ...

(Si fuiste al río con toda tu familia,
no evites que papá y mamá tomen el sol en la playa.
No grites, dale un descanso a los adultos.
Sin molestar a nadie, intenta ahogarte, Grigory Oster) ...

Cuando planeas mi horario ...

... recuerda que lo mejor de todo es que trabajo en modo de emergencia, durmiendo 3 horas después de la sesión de codificación de 40 horas de ayer. Es en este momento que 2 monitores se convierten visualmente en 4, y el código comienza a realizar bailes de nativos americanos con el sonido uniforme de una pandereta en la cabeza. Solo de esta manera recibirás de mí ideas no estándar, se podría decir, brillantes. En este estado de emergencia, el código comienza a parecer fideos largos. Tendría un atributo de archivo de 'solo escritura' si existiera uno. Puede leer dicho código solo sumergiéndose en el mismo estado de emergencia en el que lo escribí.

Desafortunadamente, los líderes de equipo están tratando de dedicar más tiempo a la evaluación de proyectos, y esto evita la formación de una emergencia. Por lo tanto, la mejor manera es pasar la mitad del tiempo declarado coordinando la fecha de lanzamiento y discutiendo el proyecto "sobre la mesa" (en secreto, sin dejar rastros). Recuerde, decodificar TK es mi pasatiempo favorito, y trae la prisa.

Más cerca del punto, recomiendo cambiar la esencia de la tarea o transferirla a otro equipo por completo; sobre todo, me gustan los proyectos que llegan inesperadamente que los contratistas anteriores no pudieron manejar, y ahora necesito llegar a tiempo sin importar lo que pase. ¡Entonces, los últimos 5 días antes del lanzamiento serán los más productivos!

Por cierto, aquí hay un "truco de vida" de uno de tus trabajos pasados. Un par de días antes del lanzamiento, puede establecer una regla para conectarse a mí por Skype durante 18 horas al día y escuchar el ruido de las teclas y el murmullo atento para asegurarse de que no me he quedado dormido y escribir el "código", y el próximo cliente no le disparará.

Si no puede ajustar los plazos, al menos reduzca el equipo. Recuerde: la emergencia se puede realizar en cualquier proyecto, si despide rápida y silenciosamente a la mitad de los desarrolladores. Una idea aún más prometedora es que habiendo despedido a la mitad, puedes reclutar a otros, sin experiencia, y cuanto más mejor. Pero también puedo enseñar a los niños en situaciones de emergencia, corrigiendo simultáneamente su código con el segundo hemisferio.

No olvide que necesito mantenerme en buena forma en todas las etapas del trabajo, incluso durante la planificación. Si evalúo la tarea a las cuatro horas de trabajo, no dude en llamar al cliente dos. Está claro que he puesto una reserva de tiempo para la ociosidad.

Después de asignar una tarea, recuerde que necesito distraerme al menos una vez cada 5 minutos. Si me siento en los auriculares, necesito pedirles que se quiten. Después de todo, si no revisas lo que estoy haciendo, ¡tampoco trabajaré o me sentiré abandonado y solo! También puedo sospechar que no estás haciendo nada, ya que no te preocupa el destino del proyecto.

La forma más fácil es inscribirme en todos los correos de Jira, todos los canales públicos de Slack y otras notificaciones disponibles (sin apelación). Proporcione una lista de todos los canales de comunicación necesarios. Y no te olvides de llevar el teléfono de mis familiares, de lo contrario duermo profundamente.

Como tiene la tarea de "hacer ping" regularmente a todo el equipo, acostúmbrese a escribir algo como @chanel o cualquier mensaje en Slacktodaspara que todos reciban una notificación independientemente de la configuración del cliente. ¡Y exija una respuesta a más tardar 5 minutos después (quién no contesta, puede llamar al teléfono)! De lo contrario, ¿cómo vivirá el equipo sin informar que el gato de la secretaria cumple años hoy?

Por cierto, debe trabajar con canales de manera integral. Hay dos estrategias óptimas: no compartir nada en el sentido, discutir todo con todos en una sola ventana, o usar el hecho de que los programas modernos te permiten crear miles de canales e intentar poner cada tema por separado. Lo principal: no elimine los canales no utilizados. ¿Y de repente sus suscriptores quieren sentirse involucrados, pero conscientemente disfrutan el zen del silencio?

Si no sabes cómo motivarme ...

... pon excusas por cada error encontrado durante las pruebas.

Esto es obvio, si estaba en algún lugar cerca del código, aunque no me metí en él, ¡lo rompí! No mire en git culpa, allí puede encontrar el autor de una línea de código. Y luego me privarás del placer de volver a publicar en Instagram otra obra maestra con un pensamiento alegre: "Este no soy yo".

Pero lo principal aquí es no ir demasiado lejos. Si sospecha que realmente me equivoqué, trate de guardar silencio por el contrario. De lo contrario, ¿cómo voy a tener una idea de la fragilidad de todas las cosas (incluida la inutilidad de mi propio trabajo)?

Sí, y olvide el mantra "todo el código del proyecto es común", ofende a los verdaderos autores y viola el derecho a la propiedad privada.

Para aumentar la productividad, también puede llevarme a algún cliente escandaloso, para que exprese en mi cara todo lo que piensa sobre la última versión. El estrato de gerentes en este caso arruinará la sensación de vivacidad que no sería posible sin un buen abuso temprano en la mañana. Solicite al cliente por adelantado que transfiera sus cargos a la persona. Lo principal es asegurarme de que la opinión del cliente no sea positiva, de lo contrario me relajaré y generalmente dejaré de trabajar.

Si un cliente se niega a dar retroalimentación a los desarrolladores, pase toda la negatividad usted mismo. Al mismo tiempo, es deseable embellecer un poco. Recuerde: la motivación se formó a partir de la palabra "mat". En un caso extremo, puede llamar a un evaluador emocional que solo ve errores en su trabajo y se complace en decirle al desarrollo qué tan mala es la aplicación que estamos escribiendo. Y luego (ver arriba) me relajaré.

Estoy escribiendo el código perfecto para el código perfecto. No me interesa en absoluto cómo se usa este código y si se usa en absoluto. No es necesario que me distraigas con una reacción positiva o, más aún, negativa a la funcionalidad que hacemos. "Escribí y olvidé" - mi eslogan. ¿Por qué necesito gracias de los usuarios? ¿Quizás incluso darles un autógrafo?

Entregue atajos a todos los empleados. Permita que tenga a Petya, que "siempre trabaja lentamente", y Vasya, que "siempre corta el césped". Y también debería haber Maxim quien hizo este "módulo XXX", y solo él puede hacer cambios allí. De lo contrario, ¿cómo navegarán los nuevos empleados por el equipo?

Más a menudo le recuerda que Petya es lenta, regañe a Petya en público, para que todos entiendan claramente por qué. Recuerde: los empleados no cambian y no se desarrollan; no tiene sentido verificar si la misma Petya se corrige después de un año de trabajo en la empresa. Si de repente Petia hace la tarea rápidamente, es mejor alabarlo tête-à-tête. ¿Y de repente sus colegas olvidan que Petia todavía es lenta? Bueno, en general, regañar públicamente, y alabar en la tarde.

Encuentra una mascota en el equipo y elogia más su dignidad, incluso si no cumple ni la mitad de las tareas que se le asignaron. Deje que haga las tareas más interesantes. Tal "mano derecha" debería estar en cada jefe. Pero, ¿cómo puedes aguantar un puesto de liderazgo sin apoyo?

Gran batido - pago retrasado. Si el dinero no llega a tiempo, definitivamente recordaré que trabajo por el dinero, acumularé mis pensamientos y comenzaré a trabajar mejor. El efecto será mayor si oculta cuidadosamente las noticias sobre la compañía. Deje que todos piensen que algo está sucediendo, pero nadie puede entender exactamente qué. Y apoye a aquellos que, con la ayuda de su imaginación, empeoran la situación. Cuanto más terribles son los rumores sobre el futuro del proyecto entre los equipos, más tranquilo trabaja el desarrollador, que tiene una hipoteca por la eternidad y una esposa con hijos pequeños detrás de él.

Si el proyecto termina, manténgase en silencio hasta el final. ¿De repente costará y el cliente decide repetir lo mismo, reescribiendo en un marco de moda nuevamente?

Pero en general, la motivación es mi desafío. Su tarea es fundamentalmente no notarme o retirarse de la zona de confort, como aconseja Internet. ¿De qué otra forma me desarrollaré? Si ves que no me gustan los mitaps y las fiestas de programación, hazme ir a ellos. Y viceversa, tan pronto como tenga una tendencia a tal pasatiempo, cargue de trabajo para que no quede tiempo para las fiestas. ¡La zona de confort no se irá sola!

Si quieres darme una tarea ...

... formular TK lo más corto posible. Recuerde: la brevedad es la hermana del talento, porque puedo adivinar todos los detalles de los tres litros de café molido que quedaron del último lanzamiento sin dormir. Texto ideal: "¡Todo debería estar bien!"

Si la introducción vino del analista demasiado comprensible, ¡no dude en recortar! Solo texto, sin capturas de pantalla. Aún mejor: un video en Viber, en el que, mientras conduce, habla durante 20 minutos sobre la situación en el camino y, en el último minuto, informa rápidamente de la existencia de la tarea.
Si de repente tiene que aplicar enlaces a algunas maquetas o documentación para la tarea, intente relacionarse con proyectos fundamentalmente diferentes, en el peor de los casos, con diferentes versiones de un proyecto. De lo contrario, será demasiado fácil. ¿Y qué tipo de desarrollo sin una búsqueda al principio?

En TK, en ningún caso debe haber información sobre la versión exacta del navegador o sistema operativo, ni enlaces a documentos en los que se produjo un error.

No hay nada más valioso que la comunicación humana. Me animará si lo envía al diseñador para las maquetas, los detalles de la tarea, al analista, la especificación de la API, al cliente. Aunque no está en nuestro equipo, también está aburrido y quiere hablar.

Por cierto, es mejor prepararse para este paso de antemano. En ningún caso no discuta los detalles de la tarea en un canal común, pero qué cosas buenas aprenderé demasiado al respecto y no iré directamente a los colegas con preguntas. Además, después de ver la comunicación del administrador de tareas en el canal común, podría pensar que el primer ministro está ocupado ... ¿y es esto posible? Utilice siempre solo mensajes personales, por lo que la fragmentación del conocimiento sobre el proyecto es mayor.

Por la misma razón, no debería proporcionarme de forma independiente una secuencia de tareas para el desarrollo. La tarea debe ganarse: búsquela de los mismos diseñadores, analistas o evaluadores. Por cierto, parte de las tareas de estos mismos analistas y probadores todavía me pueden culpar. En general, se acepta que es el desarrollador quien escribe y admite las pruebas automáticas de la interfaz de usuario. Pero el desarrollo puede ser eliminado de mí. ¡Me encanta comenzar a hacer la tarea y luego dársela a los "inconclusos" según lo indiquen las autoridades!

Cualquier tarea para mí debe ir acompañada de un máximo de burocracia. ¿De qué otra forma estaré seguro de que es realmente importante?

La información sobre el trabajo realizado debe ser lo más detallada posible. Si no tengo que ser notado en un par de sistemas de seguimiento de tiempo (equipo y corporativo, por ejemplo), sentiré que nadie aprecia mis esfuerzos. ¡Solo la duplicación de información garantizará el nivel adecuado de seguridad! Es deseable que el formulario de informe sea diferente.

Vale la pena aceptar que la duración de las tareas realizadas por semana no debe ser inferior a 40 horas. Asegúrese de considerar todo, incluso los descansos de 2 minutos. Si en este momento el empleado no detuvo el rastreador, ¡acción disciplinaria!

Verifique los informes de tiempo al menos una vez por semana, organizando una llamada general para analizar cada línea. Y finalmente, calcule la velocidad promedio de los codificadores: ¡todos saben que la duración de la tarea es directamente proporcional al número de líneas de código escritas!

Establezca la condición para igualar esta velocidad como el KPI del desarrollador, de modo que el salario también dependa de ello. Y luego, las conversaciones simples que la tarea realizó más de lo previsto no le permiten sentir la importancia del proceso.

Hablando de llamadas telefónicas y manifestaciones ... ¡debería haber tantas como sea posible! ¡Para cualquier pregunta, convoque a todo el equipo! Y siempre al menos un poco, pero llega tarde. Honestamente, no conozco otra forma de enfatizar mi importancia inicial. No intente advertir a la persona que se agrega a la llamada, lo cual se discutirá. Deje que le muestre cómo sabe saltar de un lugar a otro. Permítales obtener enlaces a cualquier tema de antemano y haga malabarismos al instante. O deje que los busque en doloroso silencio en mensajes privados con el diseñador, el resto esperará. El resto generalmente puede codificar durante una llamada.

Durante la reunión, discuta todos los problemas que le vengan a la mente. Si incluso las inconsistencias privadas, que generalmente se resuelven cara a cara, se traen a discusión, el día será más productivo. Entonces, por ejemplo, durante el día puede hacer todas las preguntas sobre la tarea actual de cada empleado. Por lo tanto, a partir de 10 minutos, el tiempo diario se puede extender a 2 horas.

Y para tener la oportunidad de convocar una reunión sobre el mismo tema nuevamente, nunca, al final, formule ninguna decisión (¿qué pasa si tienen que implementarse?). Actas de reuniones? ¿Para qué? El investigador tiene los protocolos, y somos pacíficos "trenduns". Si aún lo pasó por alto y alguien formuló estas acciones antes que usted, trate de ignorarlas.

Si está planeando un lanzamiento ...

... recuerda que el mejor momento para desplegar es el viernes por la noche. De todos modos, todos tienen días libres libres, por lo que solucionaremos rápidamente todos los errores en la producción antes del inicio del próximo sprint.

Y no olvide dejar los números de teléfono personales de todo el equipo al cliente. Quienes introducen la práctica del deber están equivocados. El fin de semana después del lanzamiento, todo el equipo esperará una llamada del cliente. El mejor momento para chatear es a las 23:59 del viernes, cuando empiezo a sufrir que el trabajo ha terminado y hay un fin de semana entero por delante. Descansar con la familia es algo gratis, estaré encantado de trasladarlo.

Todos saben que es necesario lanzar una solución en producción el mismo día que el lanzamiento de alguna API importante involucrada en esta solución. La parte posterior debe encontrarse con el frente más cercano a la producción, la integración es una palabra incomprensible. Y no escuche a quienes dicen que el desarrollo es una cosa de equipo. Los diseñadores, analistas y evaluadores del proyecto en las etapas iniciales no tienen nada que hacer. Conéctelos al final, mejor, uno o dos días antes del lanzamiento. Y, por cierto, el próximo sprint, incluso para ellos, no se puede comenzar a cocinar antes de que terminemos este.

Construya el proceso para que necesite cambiar de contexto tan a menudo como sea posible. Deje que la cola de prueba sea máxima para que mi solicitud de grupo se pruebe no antes de un par de semanas después de que la haya aprobado. Las correcciones solo serán mejores si me acerco a cada error, como por primera vez.

En ningún caso, no cree stands separados para diferentes ramas de desarrollo. ¿De qué otra forma verificas la influencia mutua de los diferentes cambios en el lanzamiento? Y asegúrese de utilizarlo en el desarrollo de la base de datos con producción. Solo así sentirá todo el equipo un nivel de adrenalina. Bueno, los probadores solo estarán felices de relajarse después del "asesinato asesino" del molesto y solo ponerse de pie.

Si accidentalmente obtienes un especial de nivel superior ...

... en ningún caso no le permitas realizar tareas ordinarias. Es mucho más efectivo contratarlo con 10 Jones como "aprendices" para que los convierta en intermediarios en un par de meses. Él es especial, ¡así que tendrá éxito! Considere obtener todo el equipo por aproximadamente el mismo dinero. De todas las formas posibles, evite que tome tareas y escriba código él mismo, incluso si una cometa vuela sobre la arquitectura del proyecto y ve el proyecto solo con la ayuda de una revisión. Retrasar la revisión del código por un par de semanas, no apresure a los chicos, no hay tiempo para explicar por qué.

Lo principal: no aumente el salario de profesionales capacitados. Este es el paso correcto para actualizar el equipo. ¿Por qué no "exprimir" a los ya entrenados y no forzar a los mayores a aprender una nueva fiesta? La sangre fresca en el equipo siempre es útil. Y otras compañías sabrán que usted es una verdadera fragua de personal. Lo aprecian, créeme.

Si no hay Jones, que así sea, dale todas las entrevistas y las tareas más interesantes. El resto del equipo se alegrará de no tener que hacerlo ellos mismos. Después de todo, ¡todos están encantados con la rutina!

Los módulos que este senior escribirá deben permanecer solo con él, nadie debe tener el derecho de tocarlos. ¿Por qué revisar y refactorizar si tienes el ideal en tus manos? Y no muestres este código a los principiantes. ¿Y de repente entienden algo allí u ofenden al senior con la ayuda de una revisión? Chick-chick - y para el maestro.

Si desea actualizar la pila de tecnología ...

... piensa: cuanto más nueva es la tecnología, más dudosa es. No hay necesidad de apresurarse a cambiar a nuevas versiones e idiomas si al menos la mitad de la industria aún no lo ha hecho. Dejen que otros conos de migración se llenen ellos mismos. Dicen la verdad: las nuevas tecnologías son más fáciles que las antiguas. ¡Pero somos profesionales! ¡Podemos trabajar en lo difícil! No obtuvo lo mejor para gastar dinero y tiempo en simplificaciones. Si los desarrolladores han estado trabajando durante mucho tiempo, vincúlelos con el hecho de que las tecnologías antiguas y conocidas no tienen demanda en el mercado. ¡Bingo!

Y si elige la tecnología moderna para un nuevo proyecto, ¿cómo entenderá el cliente que somos un equipo profesional? Y si tiene su propio marco y un montón de bibliotecas de código, un constructor de constructor universal, nunca podrá actualizarse en absoluto.

Si un desarrollador está tratando de aprender algo sobre las nuevas tecnologías a sus espaldas, desarrollando proyectos favoritos, intente cargar su tarea principal con más fuerza. Me estoy desarrollando en la dirección técnica solo para alejarme de ti por mucho dinero (y más rápido).

Por cierto, olvídate de refactorizar el proyecto. Nosotros, los desarrolladores, se nos ocurrió esta redacción para divertir nuestro orgullo. Y no busque una nueva mirada al código de otros miembros del equipo o de equipos vecinos. Como dije, escribimos código perfecto por el bien del código perfecto. No hay necesidad de una revisión. Incluso si el desarrollador trabaja solo y no ve el código de otra persona, el suyo será perfecto. Sin embargo, si el cliente requiere la revisión, haga este procedimiento puramente formal. Deje que el revisor tenga la oportunidad de simplemente hacer clic en la marca de verificación verde sin leer la esencia. No intente crear tareas para cerrar deudas técnicas y refactorizar, esto es un desperdicio de recursos.

Si me llevaras a la oficina ...

... no gastar dinero extra en muebles. Puedo sentarme en una silla por 500 rublos. VHI es - entonces respaldaremos nuestra espalda.

Y no coloque barras horizontales ni cintas de correr en la oficina. Y luego los desarrolladores se convertirán en corredores en lugar de fumar productivamente. ¿Cuál es el código perfecto cuando han estado a escondidas durante días y días?

Pensando en el horario, trate de hacerlo lo más ajustado posible. ¿A los desarrolladores les gusta dormir por la mañana? Nada para relajarse! Que todos vengan a las 8:00. ¿Encontraste a quienes les gusta? Cambia el horario. Ahora deje que todos lleguen a las 10:00, a través de los atascos. Lo principal es que todos deberían sentirse igual de mal: ¡reúne al equipo! Ya hemos dicho que debería estar lo más incómodo posible. El gráfico en este sentido deja un amplio campo para las maniobras. Penalización por llegar tarde, correr frente a la puerta de la oficina, ¿qué podría ser más divertido? ¿Proporcionar un día para trabajo remoto a un empleado de oficina? Fuh, un mal sueño, no lo recuerdo.

Si me contrataste para trabajar remotamente ...

... intenta contactarme lo menos posible! El trabajo remoto se creó para no hablar con otros Homo Sapiens.

Por cierto, fui a udalenka precisamente para no comunicarme con esa parte del equipo que permanecía en la oficina. Permítales tomar sus decisiones de diseño en una sala de fumadores y preferiblemente sin mí. ¿Por qué debería participar en esto?

No me dejes determinar las horas de trabajo yo mismo. Si todos los colegas de la oficina llegan a las 12, entonces el trabajador remoto debe abandonar el lugar de trabajo a las 12. Y entonces, ¿qué clase de udalenka es, si no cambias el horario de la noche?

Lo principal es darle al control remoto menos libertad para elegir un reloj. Apenas puedo apreciar la seriedad del empleador si no puede insistir en sus condiciones. Y recuerde, el control remoto es el que siempre está en la computadora. Esto es conveniente, no mire las horas de trabajo, no las cumplen. Si no molesta a los trabajadores remotos por las tardes, pueden tener algo para comenzar. Por ejemplo, familia o hijos.

Autor del artículo: Eugene Wetzel ( @imater )

PD Mi historia solo tiene coincidencias fantasmales con la realidad. Honestamente, los he experimentado durante bastante tiempo en dosis homeopáticas, especialmente porque no he sido un desarrollador normal durante algún tiempo. Pero recuerdo perfectamente mis sentimientos y pensamientos.

Y la moraleja aquí es simple: si pensamos en ello y tratamos de tener en cuenta estos "consejos" (con el signo correcto, por supuesto) al planificar el trabajo, todos se sentirán un poco más cómodos. Y luego, para ver todo esto desde una perspectiva diferente, daremos consejos perjudiciales a los programadores de la compañía ... en el próximo artículo.

PPS Publicamos nuestros artículos en varios sitios Runet. Suscríbase a nuestras páginas en VK , FB , Instagram o en el canal Telegram para conocer todas nuestras publicaciones y otras noticias de Maxilect.

Mal consejo para el empleador. Cómo interactuar "correctamente" con el desarrollador