¿Qué pasa si el programador no tiene nada que hacer constantemente?

Al acercarse a su programador, ¿se da cuenta constantemente de que está jugando? ¿No hace lo que quieres de él o su productividad deja mucho que desear? ¿Cuál podría ser el problema y cómo resolverlo?

imagen

Hola


Debido a mi deber, no hace mucho tiempo tuve que asumir el liderazgo de junio y todo estaría bien, pero noté que su eficiencia en el trabajo era menor de lo que esperábamos. Me preguntaba por qué. Por naturaleza, a menudo me pregunto "¿Qué estoy haciendo mal?" Y no "¿Qué está haciendo mal?". Por cierto, te recomiendo que a menudo te preguntes al respecto, porque a menudo el problema no está en otras personas, sino en para ti. Especialmente si esta pregunta se relaciona con el entrenamiento y el liderazgo, como dice la vieja sabiduría japonesa: "No hay malos soldados, hay malos generales".
Busque el problema en usted mismo, no en las personas. Si una persona hace algo diferente de lo que quieres, ¿tal vez estás haciendo algo mal?

¿Cuál es la razón de la baja eficiencia del programador? Tenemos un inicio pequeño y muchos procesos no se depuran, en particular, problemas de administración. Como regla general, discutimos tareas cada pocos días, mientras que discutimos no solo uno, sino mucho a la vez, estableciendo objetivos. No escribimos objetivos, simplemente los tenemos en cuenta.

Aquí, obviamente, cometemos un grave error, porque lejos de todos los momentos que recordamos y después de un tiempo solo queda una idea general en mi cabeza y cuando me pongo a trabajar tengo que retomar su discusión nuevamente. Mi experiencia sugiere que no somos los únicos con ese problema, muchos proyectos pequeños también tienen un pecado similar, porque las horas del programador no son un centavo, el director está constantemente ocupado y es demasiado costoso contratar a una persona individual para grabar tareas. Pero, ¿cuál es otra ventaja importante de mantener una lista de tareas?

Las personas y los programadores en particular se dividen en 2 tipos: iniciativa y no iniciativa. Como regla general, siempre hay menos primeros, si su equipo tiene al menos 5 personas, entonces, como regla general, tendrá una persona que no muestra un gran interés en el proyecto. ¿Cómo identificar a esas personas? Las características principales de una persona son las siguientes:

  • Una persona dividirá estrictamente el tiempo de trabajo y la vida personal. Apaga las notificaciones y evita por completo los pensamientos sobre el trabajo tan pronto como termina su jornada laboral.
  • Él está constantemente esperando instrucciones sobre qué hacer.
  • Raramente asume la mejora, la revisión o la escritura de algo hasta que se recibe una orden directa al respecto.
  • En las reuniones, escucha con más frecuencia que ofrece ideas.

Está claro que las reglas no son universales. Como el primer tipo puede poseerlos, el segundo puede no tener ningún hábito. Las personas son diferentes.

¿Esto significa que el programador es malo? ¡No! Tal programador puede compararse con un soldado. No es típico que un soldado haga algo sin una orden directa del liderazgo, más a menudo se castiga, incluso si el resultado ha tenido consecuencias positivas.
Como regla general, tales programadores no son profesionalmente inferiores a los iniciadores, pero pueden ser aún mejores.
Un programador que no sea ​​de iniciativa no es un mal programador

Entonces, ¿cuál es su ventaja? Realizan su trabajo de manera eficiente, siguen un plan estricto y no están acostumbrados a retirarse de él. Mientras que el iniciador, de acuerdo con el resultado, muestra la opción que ve, el soldado mostrará lo que se requiere de él, por lo que si tiene directores técnicos y creativos fuertes y saben exactamente qué es lo mejor para el proyecto, es más útil tener soldados que trabajen.

¿Puede un soldado convertirse en un iniciador y qué se necesita para esto?


Diré de inmediato, sí. ¿Por qué tan confiado? Sí, porque era un soldado, pero después de cambiar mi trabajo me convertí en el iniciador. ¿Por qué pasó esto? Para comprender, describiré ambos trabajos:

1. Mi opinión sobre la mayoría de los temas no fue muy interesante. Está Vasya, es un intermediario o senier, lo sabe mejor, y lo que digo allí, pocas personas están interesadas. ¿Qué puede decir una persona con poca experiencia? Las tareas fueron discutidas por la gerencia, yo estaba allí y escuché sus pensamientos. Al final, como resultado de las discusiones, tuve gachas en la cabeza. A lo que llegaron no se sabe. En relación con esto, el liderazgo concluye que vuelo en las nubes, pero de hecho escucho cien mil opciones en 30 minutos, y no entiendo a qué opción llegaron. No grabé el proyecto, para mí fue solo un trabajo en el que cumplí los requisitos establecidos para mí. Fue allí donde yo era un programador que estaba constantemente esperando una tarea. Si me dijeron que hiciera algo, lo hice, después de hacerlo lo informé,y haciendo la pregunta "¿Qué sigue?" recibió una dosis de negatividad con las palabras "¿Tienes más tareas?" Discutimos medio día ayer, ¿nos escuchaste? Con el tiempo, no comencé a profundizar en el proceso de reunión, simplemente dejé de hacer la pregunta "¿Qué hacer a continuación?" y estaba esperando instrucciones directas desde afuera. La situación se estaba calentando y después de la frase del director "Bueno, vamos a atarlo a la batería y dejarlo reposar hasta que comprenda qué hacer", me fui (realmente fue así, aquí teníamos tales superiores).Aquí están nuestros jefes).Aquí están nuestros jefes).

2. Al llegar, yo era el único programador, mi director era exactamente lo contrario del primero. Entendió que su base técnica podría estar desactualizada y que en algunos aspectos podría conocerla mejor que él, aunque él mismo era un programador altamente calificado en el pasado. Debido a esto, él me escuchó. Ahora elegí tareas y formas de resolverlas. Debo decir de inmediato, a diferencia del lugar anterior, inmediatamente me gustó este proyecto. Ahora trabajaba no solo durante el horario laboral, sino siempre. Se acostó con pensamientos de mejora, se levantó con ideas. Ahora me he convertido en el iniciador.

A partir de esta experiencia, se pueden distinguir varias reglas que llevarán al programador a convertirse en el iniciador.

  • . , - , . , , . 30 « » .
  • . , . , ,
    , , . , . « ».
  • Dale al programador libre albedrío. Está claro que hay casos en los que necesita hacer algo en este momento y su "no quiero" no es muy interesante, pero si está firmemente convencido de que algo debe hacerse primero, déjelo hacerlo. Deje su orgullo, si lo que hace conduce a un resultado positivo, será una ventaja para ambos, si es negativo, el programador comprenderá su error y lo escuchará con más atención.
  • Respeta a la persona.

¿Cómo trabajar con soldados?


Pero supongamos que no necesita un iniciador, está seguro de que sabe mejor lo que se necesita para el proyecto o tiene un gran equipo y será físicamente imposible escuchar la opinión de todos. ¿Cómo no llegar a la etapa de conexión a la batería?

  • . . , , . , , , .
  • , , , , . , ,
  • Distribuya las tareas de inmediato durante un largo período de tiempo. Escriba lo que debe hacer una persona durante la semana. Cada vez que un soldado termina el trabajo, la próxima tarea estará al alcance de su mano. Además, puede controlar fácilmente el proceso de desarrollo. Si le pide a una persona que se acerque al jefe para una nueva tarea, habrá situaciones en las que el jefe está ocupado o fuera de lugar. En este caso, el programador está inactivo y su reloj está goteando.
  • Respeta a la persona.

Parece que todo esto es obvio, pero muchos equipos aún no siguen estos principios, por lo que pierden no solo dinero y tiempo, sino también programadores.

¿Cómo entender a quién necesitas?


Aquí todo es bastante simple. Debe haber al menos un iniciador en el equipo, él, como regla, con el tiempo se convierte en el líder, 3-5 soldados deben estar en un iniciador. No irás lejos con algunos iniciadores, y al final algunos de ellos se convertirán en soldados.

Gracias por su atención, esperando su opinión en los comentarios.

All Articles