✋🏾 🌍 💞 Mal consejo para el desarrollador: qué hacer para "complacer" a la gerencia 🏍️ 🧛🏽 🧜

Como se prometió en el artículo anterior , estamos cambiando la situación en la dirección opuesta. No solo era un desarrollador, sino también un líder en diferentes niveles. Ya he mencionado que últimamente he tenido suerte con los equipos y colegas. Pero todo el tiempo sucedió todo.

(Grigory Oster)

Hablemos sobre con qué desarrolladores sueña la gerencia. Esta vez actuaré como gerente abstracto ...

Al comienzo de cualquier proyecto ...

¿Sabía que la habilidad más alta de un gerente es tomar decisiones con una información inicial mínima? No nos detengan, líderes, de entrenar esta habilidad. Sigue estas tácticas:

Nombra las fechas de niebla, pero no hables de ellas en absoluto.
Cuando le preguntamos si las mejoras propuestas no romperán los módulos existentes, ¡guarde silencio, en un apuro, haga una misteriosa expresión facial!
Hablando de los próximos problemas del proyecto, nunca ofrezca sus soluciones, recuerde, necesitamos preguntas de personas, no soluciones de opciones de personas.
— , , ? 48- , 10 , .
— , .

Si en la etapa de configuración de la tarea fue admitido en el cliente para hacerle preguntas aclaratorias, aprenda de los ataques DDoS: dé lo mejor de sí mismo. El cliente espera de usted al menos 50 mensajes con preguntas, preferiblemente en detalle: apreciará su desempeño en el género epistolar. No es necesario que adjunte ninguna captura de pantalla o video; permítales descifrar su mensaje, incluso si solo contiene "¡Hola!" y un largo "escribiendo ...".

Recuerde: el cliente y el usuario final son personas diferentes. ¡Nunca se comunique con los usuarios finales y no intente imaginarlos! Si la tía Masha en la caja debe ver 25 líneas de texto en el monitor, colóquelas con calma sin mirar el tamaño de la pantalla. Deje que la lupa tome si no le gusta.

Nunca nos diga qué tareas específicas se resolverán dentro del proyecto. Hable solo sobre los métodos de solución. Y es deseable en todos los detalles: ¿de qué otra manera podría CTO dormir tranquilo esta noche?

En su historia, de ninguna manera mencione dinero, tiempo u otras métricas que otros entiendan. Después de todo, incluso la secretaria del director puede traducir historias sobre las estructuras abstractas utilizadas en escenarios de usuarios y la cantidad exacta de ganancias que obtenemos. Entonces, al evaluar tareas, use el sistema de cantidades más abstracto. ¡Recuerde, 1 boa constrictor es 38 loros!

Cosecha tantas sorpresas como sea posible. Además de tiempo para resolver el problema, también requerirá suscripciones o herramientas pagas, que no sabremos hasta el último momento. Nos encantan las trampas y estaremos encantados de buscar una salida del punto muerto antes del lanzamiento. A mi cliente y a mí nos encanta aumentar el presupuesto asignado semanalmente, coordinándolo constantemente en todas las instancias. Conduzca a Ivan Tsarevich a través de una nueva iteración desde el comienzo de la historia después de cada actualización de información sobre dónde se almacena la muerte de Koshcheev.

Código perfecto ...

Intenta escribir solo el código perfecto para el código perfecto. No es necesario hacer esto la primera vez. Si tiene prisa, escriba de manera rápida, luego vuelva a hacerlo y luego nuevamente. Recuerde: la repetición es la madre del aprendizaje. Si el código ha sido reescrito tres veces y al menos ligeramente diferente del ideal, comience a refactorizar con urgencia como parte de una pequeña tarea que no se aplica a esto. Mejor aún, transfiera su código a otra biblioteca o marco. Deje que el código sea moderno y juvenil. Lo principal es que, en ningún caso, todos estos procesos pueden formularse como tareas separadas. ¿Y de repente adivinamos que algo no era ideal en el proyecto? Cosas como esta se hacen mejor justo antes del lanzamiento. ¡En este momento, todo el equipo está trabajando mucho más rápido!

Hablando de refactorización. Funcionará de manera más eficiente si cambia simultáneamente los mecanismos en el código, para no subir allí dos veces. Recuerde, tales procesos deberían afectar tantos componentes como sea posible. ¿Por qué pasar tiempo seleccionando módulos individuales? ¡Solo de esta manera terminarás pareciendo un héroe que salvó a todos! Otros desarrolladores estarán felices de descubrir las sorpresas de los nuevos mecanismos cuando les disparen en el pie.

El código perfecto debe estar formateado correctamente. Intente crear archivos de tamaño máximo, ocupando muchas pantallas y conteniendo varios componentes a la vez. Siguiendo este estilo de diseño, puede superar heroicamente los conflictos de fusión y, durante mucho tiempo, estar de acuerdo con colegas cuyas ediciones fueron más importantes. El código debe parecerse a los fideos más largos, sin necesidad de perder el tiempo creando archivos pequeños e insignificantes. En aras de una función, invente un nombre de archivo: ¿qué podría ser más doloroso?

El código perfecto que creó no es necesario para cubrir con pruebas. Solo puede hablar sobre la necesidad de llevar la cobertura al 100%, pero en realidad el 10% es suficiente. Para mantenerse al día, agregue un par de pruebas que, de hecho, no comprueban nada, luego no tendrán que actualizarse.

Si de repente resulta que una solución escrita rápidamente no funciona o no funciona como se esperaba, no dude en culpar al arquitecto del sistema, API, administrador del servidor, etc. por todo. Está claro que su código ideal no puede dejar de funcionar. Recuerde lo principal: nosotros, como usted, sabemos que un programador ideal solo puede trabajar en el vacío en condiciones ideales. Y si está distraído, no brinde información a tiempo, escriba TK incomprensible, entonces generalmente no puede ser responsable por el hecho de que el módulo implementado no cumple con la tarea comercial. Bueno, correcto, el negocio es nuestra responsabilidad. Es recomendable mantener todos los nombres de los factores culpables hasta la fecha límite, serán necesarios más tarde, ahora no distraiga a los líderes.

Cuando hablamos de la necesidad de lanzar MVP rápidamente, no dude en ignorar nuestros intentos de acelerar el proyecto en detrimento de la calidad y la velocidad. Sin embargo, saben que con una buena idea, puede comenzar en el mercado en cualquier momento. El tiempo no juega ningún papel. Deje que los competidores caguen, y cuando escriba el código perfecto, nuestro MVP se disparará en 5 años. Y todos estos años, los inversores estarán felices de pagar por crear una obra maestra con su dinero.

El orden en el proyecto ...

Tu tarea es tu personalidad. El desorden creativo agregará peso a nuestros ojos. La capacidad de construir un desorden y mantenerlo en un estado bastante caótico es tan valioso que incluso transferimos proyectos de una mano a otra para aumentar el grado de desorden. ¡Tan pronto como el caos alcance su máximo, lo recompensaremos con un nuevo proyecto!

Si comprende que se ha formado un desastre completo en el proyecto, pero aún no ha sido reubicado, comience a cavar en sus deudas técnicas con sus patas o solicite otro proyecto usted mismo. Quizás simplemente no rastreamos la situación.

Todo lo que sucede dentro del equipo debe pasar por nosotros. Incluso si decide salir a fumar con el probador, asegúrese de estar de acuerdo con él a través del gerente del proyecto, pero es mejor involucrar al CTO en esto. Nos sentimos innecesarios si nadie se queja de nuestros colegas, no recurre para resolver disputas dentro del grupo de trabajo o no introduce algunas reglas de trabajo.

En cuestiones de diseño, es recomendable que escribamos solo en PM. Esto ocultará todos los rastros de nuestra actividad de la alta gerencia y, al mismo tiempo, nos obligará a volver a contar las soluciones resueltas a otros participantes en el proceso. ¡Nos encanta!

Resolución de problemas ...

Una vez que haya resuelto el problema o solucionado el error, en ningún caso verifique su solución. ¡Grita "Hurra" y huye del lugar de trabajo lo más rápido y más lejos posible! Por lo tanto, entregará la tarea más rápido y le dará al equipo una lección para la primera mitad del próximo sprint: corregirá las jambas de la tarea que acaba de entregar. Lo que es importante, tampoco priva el trabajo de sus compañeros probadores. ¡Un conjunto de errores causados por la nueva muleta en la solución es el mejor regalo el viernes por la noche! Registre en su código solo un caso exitoso, usted es optimista.

La secuencia correcta de acciones al resolver un problema:

leer TK, ignorando notas,
fumar para olvidar los detalles,
Implemente rápidamente y sin dudar solo las funciones básicas,
pasar la tarea igual de rápido
Obtenga revisiones con un descifrado claro de las notas de TK no leídas,
que así sea, arregle el problema en 3-4 iteraciones.

No hay refactorización en la estela, no hay peinado de código. Deje que las variables se invoquen como quería su pierna izquierda en el momento de la comprensión, y el código permanece mal leído. ¡No es para que entiendas esto más tarde! Bueno, entrena para revisar tu código de inmediato: eres un tipo bueno pero delicado.

En esta etapa, es imposible crear ninguna evidencia de que la tarea se haya completado (o a veces aparecerán un video para escribir sobre el proyecto cómo se inicia el módulo ...). Quizás el probador no notará ninguna discrepancia con los TOR, o de lo contrario la tarea se enviará a otra, mientras que usted puede descansar en una nueva tarea.

Si hay momentos ambiguos en la tarea, por ejemplo, no se sabe si el campo de entrada debe aceptar solo letras en inglés o ruso al mismo tiempo, no dude en responder las preguntas usted mismo, de acuerdo con sus gustos y experiencia de vida. Como no está escrito en la declaración de trabajo, ¡esto debería ser obvio para todos!

Y nunca pruebe ninguna hipótesis en una pequeña parte de la tarea, de lo contrario, sus colegas pensarán que tiene dudas.

Si tiene prisa con una tarea para liberar y comprende que algunas funciones deberán completarse más adelante, no tiene que perder tiempo configurando una tarea en el sistema de gestión de proyectos. Es mejor hacer una nota directamente en los comentarios al código y no decirle a nadie al respecto. Por lo tanto, será aún más interesante contraer deudas técnicas. Tendrá la sensación de que hay muchos de ellos y que todavía es muy necesario en el proyecto.

¡No conserve más de la mitad de los archivos en el repositorio del proyecto! No es de extrañar que se hayan inventado tantos lugares de almacenamiento diferentes en el mundo. Es importante colocar los archivos restantes de manera uniforme entre los repositorios personales de los empleados y, por ejemplo, la documentación (ni siquiera necesariamente para el proyecto actual). Por lo tanto, el "conocimiento secreto" sobre el proyecto se dividirá en partes iguales en el equipo y todos serán irremplazables. Y luego vendrá un recién llegado al proyecto y lo resolverá rápidamente en el ya implementado. Algo que no puede resistir en su lugar: todos serán reemplazados instantáneamente por Jones más baratos.

Cada proyecto debe tener un conocimiento secreto que se transmita de boca en boca. Solo de esta manera puedes tomar un suspiro de una foto y, escupiendo, decir: "Oh, estos junes han estado trabajando durante una semana, pero no saben nada sobre el proyecto. ¡Apártate, hazlo tú mismo!

Si se comprometió a llevar a cabo cualquier tarea de Jira, no es obligatorio marcarla. Somos medios: adivinaremos lo que está haciendo ahora, pero al mismo tiempo adivinaremos el estado actual del proyecto. Por cierto, podemos hacer esto con el tiempo empleado: no tenemos que escribir nada en ningún lado, descubriremos la cantidad de horas trabajadas y calcularemos su salario.

Comunicación sobre el proyecto ...

¿Has oído hablar de omnicanal? La comunicación sin dividirse en diferentes canales es la última tendencia. Estar en tendencia! Para cualquier pregunta, escriba PM a algún mensajero, es mejor personal, no un trabajador, para que sepa que usted no está detrás de las últimas tendencias de este mundo. Pero los equipos de proyecto en Slack y otros mensajeros se utilizan mejor para enviar imágenes divertidas con gatos y conversaciones personales.

Llegue tarde a las reuniones regulares de 15-20 minutos. Mejor aún, tenga un micrófono de la era soviética y Wi-Fi lejos del lugar de trabajo. Deje que todos escuchen su croar, es como cuadros abstractos: todos escuchan lo que quieren escuchar. Y en el Daily, puede hacer todas las preguntas que tenga sobre el proyecto. Si no hay suficientes problemas de diseño, agregue más temas. En el peor de los casos, siempre puedes preguntar algo abstracto. Un buen ejemplo de este tipo refleja mejor por qué no le gusta llamar y por qué es mejor no asistir a ellos.

Bueno, no lo olvides, cada persona tiene bluetooth de alta velocidad en su cabeza. Por lo tanto, si ya ha imaginado todo en su cabeza, simplemente transfiera esta imagen. Las palabras solo pueden explicar pequeños detalles que no eran visibles en la imagen. Deja que traten de entenderte, este es su trabajo.

Por cierto, vale la pena llegar tarde a la oficina si trabajas en nuestro territorio. Esta es la única forma de crear una impresión de su importancia. Y nunca advertir sobre llegar tarde. Esto mostrará que tenías prisa, es decir arruina tu imagen de un gurú tranquilo.

Si abandona su lugar de trabajo, no tiene que preocuparse por la disposición de los estados en Slack u otros mensajeros instantáneos. Cualquiera que escriba en su ausencia (e inicie una notificación) dará una razón para una maldición larga y reflexiva de que se está distrayendo en su tiempo personal. ¿Dónde más encontrarías tal razón? Y permita que los gerentes y colegas aprendan a acumular sus preguntas rápidas antes del comienzo de su jornada laboral oficial (habrá algo que discutir en el día).

El intercambio de experiencias es superfluo. Por lo tanto, si aún publica algún enlace a un artículo o marco para el canal de Educación en Slack, no necesita hacer ninguna descripción al respecto. Que sea una búsqueda de colegas. Quieren nuevos conocimientos: déjalos esforzarse y comprender lo que les arrojaste. Y no importa que esta no sea su área. Y en ningún caso no comparta las observaciones de su proyecto, decisiones interesantes, errores y conclusiones instructivas. Desarrollador a desarrollador lobo. ¡Debes competir y no desarrollar una experiencia de equipo común! Y sí, ¡casi lo olvido! Si encuentra un artículo extenso, no lo lea usted mismo, solo déjelo a sus colegas, tal vez estén interesados.

El trabajo de otros desarrolladores puede y debe ser criticado. Tienes que encontrar fallas en cada pequeña cosa. Simplemente no confunda críticas y críticas. Es necesario criticar ampliamente y con gusto (y preferiblemente lo más abstracto posible, por ejemplo: "Su código es terrible"), pero realice la revisión lo más rápido posible: haga clic en la marca de verificación verde sin mirar el código y sin dejar comentarios. Y luego se deberán formular algunas razones constructivas para la insatisfacción.

Transfiera a nosotros toda la responsabilidad de su motivación y capacitación avanzada. Ya estamos descansando para ti, incluso fotos de cascos de diferentes resorts. Permítanos también crear una motivación para usted. Está claro que en el proyecto todas las tareas son interesantes y solo fuera de peligro encontramos una rutina para usted. Y organizamos salidas rápidas a propósito, porque trabajas mejor en este modo. Sin embargo, no lo matriculamos en cursos por daños. Nos transfiere todas sus necesidades a través de Bluetooth, que está integrado en su cerebro, las recibimos, pero las ignoramos. No es necesario convertirlos en palabras, los sentimos de todos modos.

Hacia el final del proyecto ...

Cuando le pedimos que muestre el proyecto al cliente, en ningún caso no se prepare con anticipación para la demostración. Está claro para todos: si el proyecto comenzó en su computadora portátil, significa que está funcionando al 100% y comenzará en cualquier lugar. Todos tenemos suerte!

Si, de acuerdo con los resultados de la demostración, el cliente no está contento, sentirá un conflicto inminente, debe enviar al cliente al infierno. Simplemente no entiende nada. Y no hay necesidad de informar al gerente. Por cierto, un conflicto con un cliente es la mejor razón para pedirnos más dinero. Estaremos encantados de estar de acuerdo!

La fecha de lanzamiento es una ficción. Nos encanta marcar estas fechas en el calendario. De hecho, los gerentes, especialmente en el control remoto, realmente carecen de comunicación. Y posponer las fechas de lanzamiento es la mejor manera de convocar rápidamente 3-5 reuniones a las que las personas no se negarán a asistir.

Cuando la situación en el proyecto se está calentando, es hora de disolver los rumores de que todo colapsará pronto. Dedique tantos colegas como sea posible a sus suposiciones, difunda más negatividad. Si los rumores están justificados, su distribución nos motiva a corregir la situación con la onda de una varita mágica. Y si no está justificado, nos complace que todavía esté en buena forma.

Por cierto, si los rumores no ayudan, comience a entrar en pánico a coro. Esta es la solución más constructiva. En este punto, puede comenzar a hablar cosas desagradables sobre la compañía, no solo dentro, sino también afuera (por ejemplo, en entrevistas). ¡Esto definitivamente ayudará a igualar la situación financiera y conseguir colegas fuertes en sus colegas!

Hacia el final del proyecto, puede dejarlo en voz alta y efectiva, articulando la razón para irse con un salario demasiado bajo, a pesar de que ha estado en el proyecto durante tantos años y por el bien de nosotros no tocamos las nuevas tecnologías. Siéntase libre de ir a los competidores, ellos lo apreciarán. Nuestra búsqueda favorita es buscar nuevos especialistas una semana antes del lanzamiento. Cuando te vayas a otra empresa, no te olvides de nosotros.

Cuéntales a todos sobre un lado del problema. Guarde silencio sobre sus "hazañas", cuéntenos qué gerentes son injustos. No trates de entendernos, dile a los forasteros. ¡A NDA se le ocurrieron cobardes!

Todas las dificultades deben informarse solo como último recurso, si el proyecto no se puede poner en producción. Este es el mejor trabajo en equipo cuando el equipo "apaga el fuego" la noche anterior a un lanzamiento importante o ya está en producción. ¡No te prives a ti y al equipo de este placer!

Si aún experimentó una liberación en el equipo y algo salió mal, puede poner errores en la producción de forma segura al final de la cola. Deberían tener la misma prioridad que todos los demás. ¡Que se pongan en línea!

Bueno, y sepa que la noche posterior al nombramiento del desarrollador para el puesto de estación de servicio, ocurren profundas metamorfosis con él. Olvida todas las necesidades de los desarrolladores, se vuelve miope, autoritario, estúpido e inaccesible. Por lo tanto, nosotros, gerentes, gerentes y estaciones de servicio, los entendemos muy mal a ustedes, los desarrolladores.

Autor del artículo: Eugene Wetsel (imater)

PD: Como la última vez , mi historia solo tiene coincidencias fantasmales con la realidad. Y la moraleja es esta: tomemos en cuenta todo este sarcasmo, construyendo relaciones en el equipo.

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.