¿Por qué los proyectos de desarrollo web tardan tanto en completarse y cómo se termina más rápido?

Esa es la pregunta que les hará ganar dinero a todos. Hice muchos proyectos, de diferentes tamaños, de 15 a 60 horas. Y en la superficie, parece que un empleado de tiempo completo debería realizar un proyecto de 60 horas en una semana y media, ¿verdad? No, es todo un mes.

Este es el por qué:

* el tiempo estimado generalmente incluye el tiempo de desarrollo real. Esto no incluye (a veces lo hace) encontrarse con inconvenientes, cosas que se estropean, retroceder en el código, encontrar las herramientas adecuadas para el trabajo, etc.
* el tiempo estimado se relaciona con el tiempo de desarrollo real (de nuevo, ¿ves?) pero el problema es que los desarrolladores (a menos que REALMENTE estén entusiasmados) no pueden trabajar 8 horas seguidas todos los días durante dos semanas. O si no pueden, no pueden seguir así como una rutina. Espere 6 horas de trabajo al día, con 4 horas de código competente real. Suena mal, lo sé, pero esa es la realidad.

Esos dos puntos lo resumen todo, especialmente el segundo.

Aquí se explica cómo solucionarlo y aliviarlo (lo hago personalmente, bueno, no ahora, estoy respondiendo esta pregunta <. <):

* Pomodoro u otras técnicas similares promueven la concentración. Obtenga 4 horas de trabajo puro en via pomodoro y estará bien para el día. Trabaja a un ritmo más lento por el resto del día. Tendrás alrededor de 5-6 horas de tiempo real de desarrollo. Eso ya es una mejora.
* evite las distracciones con pomodoro y utilizando SCRUM. ¿Qué necesitas hacer hoy? ¿Cómo puedes dividirlo en trozos considerables para el día? Esto te ayudará a ser más eficiente
* Tenga las herramientas adecuadas listas e investigaciones realizadas. Si solo quieres relajarte o tomar un descanso o has terminado con tus tareas del día y te quedan 20 minutos. Echa un vistazo a los blogs sobre tu desarrollador. ¿Estás usando las herramientas adecuadas? ¿Hay algo mejor? Le ahorrará tiempo y distracciones al día siguiente. Sé que en un momento pasé una hora tratando de encontrar un buen registrador PHP que funcionara con Chrome (y no con FF a través de FireBug). Pasa esa hora al final del día cuando te estés enfriando.
* Tener las herramientas físicas y de desarrollo adecuadas. Usar un mouse malo puede costarle una hora al día. No es broma. Tener un teclado defectuoso puede causar MUCHA frustración y no hacer ningún trabajo. Lo mismo ocurre con una configuración de monitor incorrecta, una computadora lenta, etc. ¿Qué tal si usa IDE obsoleto para la programación? Eso cuesta tiempo.
* Muchas veces, debido a fechas límite apresuradas, codificamos como “una cosa única”, pero si codifica de manera “Haré esto de nuevo”, su próximo proyecto será más rápido y luego el siguiente y luego el siguiente hasta que alcances una barrera de tiempo mínimo. Yo, por ejemplo, creé un tema de inicio para WordPress. Me ahorró al menos 10 horas en cada proyecto. En lugar de codificar los conceptos básicos (y tomar, por ejemplo, 5 horas), podría configurar el tema (1 hora) y seguir adelante. El primer proyecto que hice con el tema me costó mucho tiempo extra (aparte, no pagado por el cliente) pero en este momento, es mi pequeño logro insignia 🙂

Hay muchos factores que intervienen en esto, el más básico es “horas facturables” no es lo mismo que “horas reales”. 20 horas facturables podrían significar 60 horas reales en total. Aquí es donde generalmente se pasan las “horas reales”:

Reuniones: las reuniones pierden tiempo de un calendario de proyecto como el agujero en el casco del Titanic. Tiene reuniones de inicio de proyecto, reuniones de inicio de proyecto interno, reuniones de inicio de proyecto, reuniones de personal sobre quién asistirá a las reuniones de inicio y de inicio, reuniones de clientes, reuniones de hitos, reuniones para programar otras reuniones … (entiende el punto) . Pocas organizaciones han descubierto una cura para la reunión común, y es la ruina de los empleados en todas partes.

Admin: estoy usando “admin” como un término general para cosas relacionadas con el proyecto, pero no se puede facturar como trabajo real. Esto incluye enviar correos electrónicos / llamar a clientes / partes interesadas, registrar horas y presentar informes de proyectos. Por lo general, cuanto más complicado es el sistema de facturación / informes, los miembros del equipo tardan más en completarse (y, por lo tanto, mayores son las posibilidades de procrastinación).

Volumen de negocios: no todos los equipos sobrevivirán intactos al proyecto. Habrá reasignaciones, reestructuraciones, reducciones, vacaciones y días de enfermedad. El trabajo tendrá que pasar a otras personas, que tendrán que dedicar tiempo a orientarse antes de trabajar realmente en el código.

Aprendizaje: Ningún desarrollador es omnisciente. Tendrán que pasar un tiempo investigando el código de características que nunca antes han implementado, ya sea a través de Internet o de sus pares / gerentes de proyecto. Algunos equipos cuentan esto como horas facturables, pero no todos lo hacen.

Ciclo de retroalimentación / aprobación: Gran parte del tiempo de un proyecto se pasa esperando a que otras personas se muevan. Los clientes son notoriamente malos en reenviar la información necesaria de manera oportuna, y un miembro del equipo termina haciendo girar sus pulgares mientras espera la información clave (o aprobación) que les permite reanudar el trabajo. Y cuando lo hacen, generalmente es “apresurarse”.

En cuanto a las horas facturables:

Las horas facturables no son consistentes en términos de productividad. A un desarrollador le lleva tiempo alcanzar su ritmo cuando trabaja, y la mayor parte del tiempo mirando la pantalla cuenta como trabajo (porque el desarrollador está tratando de descubrir su próximo paso).

Las interrupciones arruinan el impulso del programador y los retrasos significativos entre las sesiones de programación (por lo general, más de un par de días) significa que el desarrollador tiene que perder el tiempo facturable para reorientarse con lo que ha hecho. Esto puede ser especialmente malo si el desarrollador estaba en medio de solucionar un problema y tuvo que acortar su sesión porque se le acabaron las horas facturables para gastar.

Solución:

El comentario de Antonin es excelente para maximizar su productividad personal, y definitivamente es algo que debe considerar. Para entornos de equipo, debe tener un gerente de proyecto efectivo que esté dispuesto a cortar el toro y decir no a las personas (incluidos los clientes) en aras de completar el proyecto de manera oportuna. Otras cualidades de liderazgo que ayudarían incluyen:

  • Abierto a los comentarios de los miembros del equipo.
  • Grandes habilidades de organización y planificación.
  • Muy versado en el proyecto y el lenguaje de programación (para que pueda funcionar como un recurso y contribuir si es necesario)
  • Grandes habilidades interpersonales.
  • Capaz de mantener a los miembros del equipo enfocados y motivados