Cómo hacer las paces con los plazos en el desarrollo de software

FECHA LÍMITE…

Como desarrollador, esta es una de tus mayores pesadillas, ¿o debería decir tu enemigo? Nómbralo como quieras.

Admitelo. Te asusta mucho. Incluso ahora, mientras lee estas frases, se le pone los pelos de punta.

¿Preguntándome cómo lo sé?

Lo sé porque yo sentí lo mismo. Pero ahora el miedo está en el pasado. He hecho las paces con los plazos. Los he abrazado.

Así que te sugiero que hagas lo mismo. Abrázalos, haz las paces con ellos. Esta es la única forma en que puedes derrotarlos.

Ok, pero, ¿cómo puedes hacer eso?

Hay algunos hechos que todos tendemos a ignorar cuando se trata de establecer una fecha límite. Mi objetivo aquí es mostrártelos para que veas que se necesita tan poco para enterrar el miedo y empezar a disfrutar de la vida mientras trabajas en tu proyecto sin preocuparte por las fechas.

Trabaja en un ambiente tranquilo

No se apresure. No fuerces nada.

Lo primero que debe saber es que no puede encontrar la paz estableciendo fechas poco realistas y obligando a su equipo a trabajar apresuradamente. Hay empresas que lanzan grandes palabras y muestran cosas poco realistas para motivar a su equipo a seguir adelante. Pero si bien hay algunos hechos obvios para todos en el equipo, ¿cómo puedes esperar que crean en lo que estás diciendo si está muy lejos de la realidad?

Sin una fecha límite fija, y lo más importante, creíble, no se puede trabajar con calma. Sí, mantener la calma es la clave aquí. Cuando no confías en la fecha, o cuando alguien te dice que hagas todo dentro de un período de tiempo limitado, o alguien agrega más tareas al proyecto sin darte más tiempo, comienzas a trabajar como un maníaco. Esto ya no es trabajo. Esto es el infierno.

Cuando está bajo estrés y presión, no puede ser productivo. Cuando está tranquilo, también está consciente, lo que significa que puede tomar mejores decisiones.

Nuestras estimaciones apestan

Los usuarios de Windows recordarán ese diálogo de ventana. La estimación en el cuadro de diálogo es exactamente como nuestras estimaciones, ¿no?

Admitámoslo. Nuestras estimaciones apestan. Creemos que podemos adivinar cuánto tiempo llevará algo. Tenemos la tendencia a creer que todo lo que adivinemos se hará realidad.

Sin embargo, generalmente, cuando adivinamos, ignoramos algunos factores importantes que pueden afectar nuestras suposiciones. ¿Por qué? Porque somos demasiado optimistas.

Para mí, el primer paso para hacer las paces con la fecha límite y mejorar en el establecimiento de fechas límite es admitir que somos unos calculadores terribles. Cuando acepte este hecho, estará consciente la próxima vez y evitará que subestime los requisitos. Y aquí hay una solución para que mejore su estimación:

Divide las cosas grandes en cosas más pequeñas . Cuanto más pequeño es, más fácil es estimarlo . Esto aumentará sus posibilidades de tener estimaciones más precisas.

Lo suficientemente bueno está bien

"Lo perfecto es enemigo de lo bueno". - Voltaire

A la gente le gustan los grandes desafíos. Somos los mejores para encontrar una solución complicada para un problema simple. Pero aquí hay un hecho:

Cada problema tiene su propia solución simple que probablemente ignore.

No busque una solución perfecta. Tu primera versión no tiene por qué ser perfecta. Construya un medio producto que pueda funcionar. Si espera demasiado, desperdiciará sus recursos limitados y su tiempo precioso, o perderá el plazo y, lo que es peor, no hará nada en absoluto porque está persiguiendo la perfección. La solucion es:

Encuentre la solución que le aportará mucho valor y requiere poco esfuerzo. Y no lo olvides, lo bueno se puede convertir en grandioso después.

No seas demasiado optimista. Ser realista.

Veo gerentes que son demasiado optimistas, lo que los hace establecer plazos optimistas para motivar al equipo. Esto esta muy mal. No le digo que deba ser pesimista sobre el futuro. Al contrario, te digo que deberías poder ver todas las posibilidades que pueden crear un cuello de botella. Una vez que pueda verlos, puede considerarlos y tener una estimación más precisa.

Hay diferentes equipos en la empresa. Ingeniería, desarrollo empresarial, marketing, etc. Cuando el equipo de desarrollo empresarial le obligue a darles una fecha límite en un futuro muy cercano, no debería verse afectado por ellos. Quieren que su trabajo esté terminado lo antes posible.

Recuerda que cada equipo piensa en su propio bando.

Diferenciar entre "tienes que hacer", "puedes hacer" y "quieres hacer"

La comprensión es la clave aquí. ¿Cuáles son los requisitos básicos para lanzar su producto? Por lo general, el equipo de producto tiene dificultades para diferenciarlos.

Cuando tenga una reunión, uno de los miembros del equipo dirá, "podríamos implementarlo, nos aportará tanto valor", o otro dirá "Deberíamos publicar esto". Miran desde su propia perspectiva. Bien, podemos implementar esto y puede aportarnos algo de valor, pero la pregunta importante es “¿lo necesitamos ahora? ¿En la primera versión?

La respuesta es NO en la mayoría de los casos.

Las cosas que tienes que hacer son en las que debes concentrarte . Elimina las cosas que podrías hacer y quieres hacer. Ni siquiera son negociables en la mayoría de los casos.

Di no por defecto

Hay un hecho importante que solemos olvidar cuando decimos "Sí" a algo. Estamos diciendo no a las cosas que ya necesitamos completar.

Cuando dices que sí a algo nuevo, no estás pensando en el impacto que tendrá en tus tareas pendientes existentes.

“Agreguemos más tareas al proyecto después de establecer la fecha límite. (Su proyecto debería hacerse más pequeño con el tiempo, no más grande) ” NO .

“Nos enfocamos en lo que importa, está bien. Pero ¿qué pasa con los detalles? Consideremos qué tipo de detalles tenemos que pueden generar problemas en el futuro ". NO . Ignora todos los detalles de la primera versión. No intente predecir el futuro.

Encontrar más tiempo para las cosas no es el problema aquí. Demasiadas cosas que hacer es el problema. Diferenciar entre " imprescindibles " y " agradables ".

La única forma de hacer más es tener menos que hacer.

Nunca cambie la fecha límite

Veo equipos de desarrollo con un mal hábito que puede afectar gravemente el desarrollo de sus productos: reprogramación de fechas límite.

Cuando no cumplen con la fecha límite, establecen una nueva. Si no pueden cumplir con este, establecen otro. Cuando hacen esto repetidamente, se convierte en un hábito. Entonces este mal hábito se convierte en su cultura. Otros equipos de la empresa pierden la confianza y cuestionan el trabajo de los desarrolladores. Peor aún, el propio equipo de desarrolladores puede perder la confianza entre ellos. En sí mismos también.

Cambiar la fecha límite es esencialmente una admisión de fracaso . Se trata de hacer declaraciones como, "No cumplimos con los requisitos del plan, no dijimos que no lo suficiente, no nos centramos en lo que importa, empujamos a nuestros equipos a hacer cosas irracionales en un tiempo irrazonable".

Tenga en cuenta que siempre habrá algunos problemas.

Ser demasiado optimista hace que ignore el hecho de que puede haber algunos problemas. Sea consciente. Probablemente algo salga mal. Y esto hará que pierda algo de tiempo arreglando cosas. Así que es mejor estar preparado para los malos escenarios. No estoy diciendo que debas ser pesimista y que debas intentar predecir el futuro y prepararte a ti y a tu equipo para lo desconocido. Simplemente encuentre un equilibrio entre optimismo y pesimismo. Ser realista.

Mi experiencia me mostró que, en el desarrollo de software, algunas cosas siempre salen mal. Mi consejo para ti es:

Agregue algo de tiempo a su fecha límite antes de establecerla considerando que algo puede salir mal.

No agregue más personas a un proyecto

Mucha gente piensa que pueden acelerar el proceso si agregan más personas al proyecto. Sin embargo, pierden un punto muy importante. Recordemos la ley de Brooks:

Agregar recursos humanos a un proyecto de software tardío lo hace más tarde. - Freed Brooks

Según Brooks en Wikipedia, hay una persona incremental que, cuando se agrega a un proyecto, hace que tome más tiempo, no menos. Entonces, ¿por qué funciona de esta manera?

• Se necesita algún tiempo para que las personas agregadas a un proyecto sean productivas. Primero tendrás que educarlos. Ya tiene recursos humanos limitados y tendrá que dedicar esos recursos para educar a los nuevos miembros. Además, dado que son nuevos, introducirán nuevos errores que alejarán el proyecto de su finalización.
• Los gastos generales de comunicación aumentan a medida que aumenta el número de personas.
• Agregar más personas a una tarea altamente divisible, como limpiar habitaciones en un hotel, disminuye la duración general de la tarea. Sin embargo, otras tareas que incluyen muchas especialidades en proyectos de software son menos divisibles. Otro gran ejemplo de esto de Brooks es: mientras que una mujer necesita nueve meses para tener un bebé, “nueve mujeres no pueden tener un bebé en un mes”.

Otra evidencia de Richard Dalton para entender por qué agregar más personas está mal es:

“Los equipos son inmutables. Cada vez que alguien se va o se une, tienes un equipo nuevo, no un equipo cambiado ". - Richard Dalton

No pospongas las cosas

Déjame ayudarte a entender lo que quiero decir. La semana pasada, tuvimos una reunión sobre la definición de la fecha límite para una nueva característica de nuestro producto. Estuvimos hablando de qué tareas son nuestra prioridad y cómo debemos implementarlas de manera efectiva.

Hubo una tarea en la que hemos perdido mucho el tiempo. Había tres formas de implementar esa tarea, pero de alguna manera estábamos estancados. No pudimos elegir porque los desarrolladores intentaban predecir el futuro. Comenzaban cada oración con "¿Y si?".

No puedes predecir lo que te traerá el futuro. No te prepares demasiado para lo desconocido.

No estoy hablando de grandes decisiones técnicas aquí. Por supuesto, si tiene que decidir cuál es su tecnología principal, debe dormir con ella para encontrar la solución adecuada. Pero no gastes tu tiempo en cosas pequeñas. Las cosas inciertas aumentan las reuniones y bloquean su progreso porque su proceso de backend trabaja continuamente en ellas.

No lo pospongas, decídete y sigue adelante.

Cambie su mentalidad de "Pensemos en ello" a "Decidamos ahora". Las decisiones acelerarán su progreso. Cuando se decida algo, estará claro para todos en el equipo. Todos sabrán exactamente qué hacer.

Comunicarse: ¿Ves dónde está el cuello de botella?

Planeaste todo. Usted definió en qué concentrarse y qué hacer. Sabes exactamente cuánto tiempo tomará (probablemente te equivoques). Entonces, el plazo se ha resuelto. ¿Es suficiente?

NO.

Como mencioné anteriormente, siempre existe la posibilidad de que algo salga mal. Mientras los miembros de su equipo están trabajando en sus tareas, algo puede bloquearlos. Algo puede detenerlos para terminar sus tareas a tiempo. Tienes que ver dónde está el cuello de botella y cuál es.

La comunicación es la clave aquí. Tienes que mantener los equipos sincronizados. A veces, los miembros del equipo pueden entrar en una caja y puede ser muy difícil para ellos ver qué está sucediendo fuera de ella. Aquí es donde debes entrar en escena. Una vez que haya identificado el cuello de botella, elimínelo para que los miembros de su equipo puedan continuar desde donde estaban atrapados.

Te deseo buena suerte cumpliendo con todos tus plazos :)

Gracias por leer.

Publicado originalmente en //huseyinpolatyuruk.com.