Entonces, ¿por qué no hay nuevas producciones? ¿Dónde están las victorias en las competiciones? ¿A qué te refieres con dos meses corriendo y recogiendo papeles? ¿Qué otra creatividad? ¿Y por qué no tienes tiempo para eso? ¿Qué otra secretaria deberías contratar? ¿Qué quieres decir con "me voy"? ¿En serio crees que puedes manejarlo sin nosotros? Bueno, buena suerte.
Algo así describió a un muy buen líder de muy buena vida de grupo de danza "bajo el ala" de una institución estatal, cuando explicó por qué se fue "desde abajo".
El caso se hundió en el alma, tk. Solo estaba realizando un experimento (una vez más) para librar a otras personas creativas, los programadores, de lo no básico, pero "un trabajo tan importante, necesario y obligatorio", que llega a tiempo.
¿Qué pasa si?
He realizado este experimento varias veces, en diferentes empresas, tanto en proyectos como en desarrollo, y en programadores de fábrica, y en la prestación de servicios de revisión. Lo crea o no, el resultado es siempre el mismo.
Si los programadores dejan de preocuparse por los plazos y simplemente resuelven los problemas, uno tras otro, sin distracciones, la productividad se duplicará. En consecuencia, si vuelve a activar el modo de "captura a tiempo", entonces el coeficiente es exactamente el mismo: dos veces, solo que esta vez la productividad se divide por él.
Bueno, y lo más importante: el programador aún no llega a la fecha límite, de por vida. Y si lo hace, solo a veces, por accidente. O a costa de una productividad reducida.
Aquí todo es muy sencillo. No probaré el axioma de que un programador nunca sabe exactamente cuánto tiempo tomará resolver un problema; hay muchos artículos y libros sobre este tema. Si trabajó como programador, no se requiere prueba. Hay, por supuesto, excepciones, tareas similares y repetitivas, pero estas son las excepciones.
La mayor parte de nuestro trabajo contiene muchas incógnitas en constante cambio, recuerdos constantes de viejas tareas, sorpresas de subcontratistas y actualizaciones de dependencias, errores de diseño, etc.
¿Cómo planeas hacer este trabajo? Fundamentalmente, hay cuatro enfoques: fantasía, reserva, volumen y flujo.
Métodos de "planificación"
Fantasy es la aplicación de métodos de planificación de producción por lotes al trabajo de los programadores. Por ejemplo, Lean o MRP. Este enfoque es utilizado por todos los "administradores clásicos", especialmente sus castas separadas: "administradores". Solo necesita exprimir los costos de mano de obra planificados del programador, ignorando todos sus gritos como "Maldita sea, ni siquiera sé a qué me voy a enfrentar allí", y dibujar una hermosa salchicha en el diagrama de Gantt. Y vuelva a dibujar todos los días.
La reserva son enfoques como la teoría de las restricciones, cuando la parte de un caballo simplemente se agrega a los costos laborales planificados, por si acaso. La figura resultante también se dibuja como una salchicha en el diagrama de Gantt. Se vuelve a dibujar con menos frecuencia, pero casi siempre.
El volumen es cuando no se planifica el marco de tiempo para resolver problemas, sino la productividad. Por ejemplo, este enfoque se usa en Scrum: conociendo la velocidad aproximada del trabajo del equipo (en puntos de la historia), puede planificar la cantidad de trabajo por sprint (en el mismo SP). En consecuencia, todas las tareas de sprint tienen la misma fecha de vencimiento.
El flujo es cuando solo hay velocidad. Las tareas están alineadas, el programador se sienta y las resuelve una a una. Las fechas no se conocen, pero se pueden calcular, conociendo la velocidad y el número de tareas en la cola. Lo principal es no confundir al programador con el cálculo del término.
Pros y contras
No tiene sentido siquiera discutir un enfoque elegante, no funciona. No solo eso, también crea un estrés constante y salvaje y un trabajo de reprogramación idiota. Puede vivir si alguien más no está involucrado en la replanificación, pero esto rara vez sucede. Por lo general, un programador es golpeado todos los días con preguntas como "dime la fecha límite", "¿cuándo terminarás esta tarea?" o "ya pasaron todos los plazos, ¿trabajarás o no?" De forma natural y armoniosa, el programador dispone de reservas de tiempo, aunque no sepa nada sobre ningún método de moda.
Las reservas de tiempo le ahorran molestias, pero reducen la productividad, debido a la acción de la ley de Parkinson: el trabajo requiere todo el tiempo asignado. En algunas circunstancias, este enfoque se adapta a todos, por ejemplo, a los programadores de fábrica. Es cierto que hasta que el programador renuncia, como regla general, se da cuenta de que su velocidad de trabajo es menor que los requisitos del mercado.
Se cumplen los plazos, ya que las reservas de tiempo pueden representar miles de por ciento de los costos laborales reales. Si el negocio o proceso está estructurado de tal manera que el indicador clave está cumpliendo exactamente con la fecha límite, entonces el método de reserva de tiempo es muy adecuado.
Los métodos a granel como Scrum pueden duplicar aproximadamente su productividad porque reducir la influencia de la ley de Parkinson y centrarse en una productividad más o menos real, no en fantasías y reservas de tiempo. Sin embargo, un sprint sigue siendo una fecha límite, por lo que la ley de Parkinson sigue funcionando, al igual que las reservas de tiempo y los intentos de manipular los puntos de la historia. Las personas son personas, tanto programadores como gerentes. Los programadores quieren ser buenos empleados. Y los gerentes están tan acostumbrados a considerar a los buenos empleados solo a aquellos que “cumplen con la fecha límite” que al menos tienen una cuenta en la cabeza. Todo esto simplemente se llamará de manera diferente, como "todas las tareas pendientes deben realizarse dentro del sprint y no hay nada que facilitar aquí". Y se les ocurrirá algún otro KPI para este negocio, porque la imaginación no es rica.
No hay tales problemas en la secuencia, ya que no hay razón para ellos: la planificación del trabajo del programador y los intentos, de una forma u otra, de estimar el tiempo del trabajo. El flujo protege la esencia del trabajo del programador: la creatividad. Me gustaría, por supuesto, decir que fluir es pura creatividad, pero esto no sucede. Sin embargo, la pureza es mucho mayor. Y la productividad se duplica más que Scrum.
Lo que es interesante: la protección del programador, o de cualquier ejecutante del trabajo, está incorporada en cualquiera de los métodos anteriores. Pero cuando se aplica a los programadores, la protección siempre se olvida.
¿Cuál es la base de cualquier método?
Por ejemplo, Lean, por extraño que parezca, también se basa en la idea de flujo, ya que inventado en la línea de montaje. La idea es organizar el trabajo de la manera más uniforme y armoniosa posible. Para que cada intérprete de la cadena, por un lado, siempre tenga algo que hacer, y por otro, para que no haya cola frente a él. Solo el espacio libre mínimo requerido. Para un programador, esta es una tarea. Intente dar esta idea a un gerente que sea un experto en Lean; ni siquiera entenderá de qué se trata, porque Omití la sección sobre la protección de los artistas intérpretes o ejecutantes cuando leí el artículo de Wikipedia sobre Lean Manufacturing.
En la Teoría de las Restricciones, que trata sobre las reservas, la protección del enlace de ejecución es generalmente un postulado básico. Donde se sientan los programadores, casi siempre son un cuello de botella. ¿Qué dice la CBT sobre el cuello de botella? Así es, debe estar protegido. Elimine toda la carga de trabajo secundaria (incluida la programación de su propio trabajo), evite el tiempo de inactividad y no calafatee su cerebro con preguntas y reuniones estúpidas. Organice el flujo de trabajo a la velocidad a la que funciona el cuello de botella. Bueno, gerentes expertos en TOC, admítelo, ¿han estado pensando durante mucho tiempo en cómo proteger a los programadores de todo tipo de tonterías?
Bueno, Scrum tiene que ver con el flujo. Allí, el principio de "no interferir con la gente para trabajar" se eleva a un absoluto, y se expresa en la exigencia de máxima autonomía del equipo durante el sprint. Entonces, por favor, venga, vea qué sucedió, elija tareas para la próxima carrera, hurgue en la ducha. Durante el sprint, ni siquiera respire cerca. ¿Quién trabaja en Scrum? ¿Qué dices? Nadie te toca durante el sprint, ¿eh?
Total
Donde sea que escupas, donde sea que necesites un flujo. Para que el programador se siente y programe. No calculé los plazos, no fantaseé con los costos laborales, no reorganicé las prioridades cien veces, no asistí a las reuniones, no participé en correspondencia y charlas idiotas.
Sin embargo, donde sea que escupas, no hay flujo en ninguna parte. Cualquiera que sea el enfoque que se utilice, el gerente, el cliente o algún idiota encontrarán una razón para arrancar al programador del flujo creativo armonioso por alguna tontería increíblemente importante.
Siempre puedes volver a la corriente. O volver. Necesita, sin embargo, voluntad - y regreso, y apoyo. El prurito del seguimiento constante del trabajo del programador no da descanso. Especialmente aquellos que no entienden nada en el trabajo de un programador.