¿Cómo gestionas la productividad en un equipo pequeño en una startup?

método Scrum, pero resulta que en realidad no funciona para las empresas emergentes, ya que hay demasiadas cosas de las que deben ocuparse

La gestión de proyectos lleva tiempo, sin importar cuál sea su método. Cuantas más tareas tienes, más tiempo lleva y más molesto es. No importa si descarga los datos en Microsoft Project Server o en un gráfico Kanban de cartón. Los datos están ahí, necesitan ser manejados. No existe tal cosa como: "Hay tanto que hacer que no puedo escribir lo que hay que hacer".

Tal vez este ya sea su primer problema: si las personas no ven cuánto hay que hacer, nadie tendrá que preocuparse por si la próxima publicación en las redes sociales o la próxima tarea es la opción adecuada.

El segundo problema: si no sabe cuánto tiempo necesita ni cuántos desarrolladores necesita, ¿cómo quiere saber cuánto dinero necesita su empresa? Hagas lo que hagas, debe haber un hito, que podría ser solo poner algo en marcha para mostrar a los inversores. Debe planificar las tareas para este hito y la cantidad de trabajo.

No puedo simplemente asignar una tarea y darle un marco de tiempo.

Eso es correcto. A nadie le importan los plazos, cuando son artificiales. Un marco de tiempo tampoco es la herramienta adecuada para aumentar la productividad.

¿Cómo evitar que las personas dejen de trabajar, cuando deberían hacerlo? Dígales. Les pagan por trabajar. Trabajar 14 años en Duke Nukem básicamente también podría valer un premio, pero la mayoría de las nuevas empresas no pueden pagar eso.

Si tiene un hito y una lista de tareas, puede decirles la verdad que cuando no se cumple el hito 1, la empresa no tiene más dinero y básicamente no hay posibilidad de obtener más dinero, porque no hay nada que mostrar a los inversores. , lo que significa la terminación de la mayoría de los contratos. Por supuesto, este enfoque debe ser coordinado y aprobado por su jefe. Pero es la mejor manera de enseñar lo que significa cuando la gente no trabaja: que no se trata de que seas un aguafiestas, sino de que la gente al final perderá su trabajo.

En primer lugar, no se preocupe por lo que hace el equipo cada minuto del día. Si sus codificadores tienen "manos en el teclado" de tres a cuatro horas en un día normal de trabajo, eso es alta productividad. Existe el mito de que la jornada laboral de 12 horas, los siete días de la semana, es más productiva que las jornadas de ocho horas a un ritmo constante y sostenible. Concéntrese en los resultados, no si Joe codifica 30 minutos, FB 30, codifica 30. Concéntrese en lo que se hace.

Las prácticas ágiles funcionan debido a tres cosas, la claridad de la acumulación, la responsabilidad del equipo y el progreso medible.

Claridad de la cartera de pedidos: debe tomarse un tiempo con el fundador para asegurarse de que lo que se está trabajando sea lo correcto. Esto se puede hacer bastante fácil y en pequeños períodos de tiempo utilizando la solución para la responsabilidad del equipo.

Responsabilidad del equipo: muchas nuevas empresas consideran que Scrum es demasiado proceso. Las cosas están cambiando demasiado rápido y la gente suele estar muy especializada. Probablemente tendrá mucho más éxito con un tablero Kanban directo con límites de trabajo en proceso.

El tablero kanban es una lista ordenada de rango directo de trabajo a realizar. Cualquier trabajo que se tiene que hacer se coloca aquí. Incluso cosas no codificadas como "pedir un nuevo escritorio para el chico nuevo". No hay caja de tiempo para el trabajo. En su lugar, la gente saca de la parte superior de la cartera de pedidos y trabaja en ello. Establece límites de trabajo en proceso para que las personas no trabajen en varios proyectos a la vez e incluso fomente el enjambre de tareas por parte de varias personas. Cuando el fundador tenga unos minutos, arrástrelo a la pizarra para verificar el orden de las cosas y pedir algo nuevo. Organice una reunión diaria, como Scrum, para que el equipo pueda hablar sobre el trabajo que han hecho y planean hacer. Revisar semanalmente lo que se hizo.

Progreso medible La única forma de medir verdaderamente es a través del envío de software probado y en funcionamiento. Intente llegar a un entorno de compilación continua tan pronto como pueda. Cuando alguien registra el código, sabe instantáneamente si funcionó o no en función de si elimina la compilación. Como mínimo, intente tener hitos mensuales en los que el producto pase por una construcción y se muestre.

Puede encontrar más consejos sobre proyectos ágiles en el foro Project Management Stack Exchange.

Por la forma en que describe la situación, deduzco que su autoevaluación es correcta: necesita apoyo adicional. En primer lugar, necesitas formación. Hay muchos cursos, entre $ 500 y $ 5000. Libro uno.

En segundo lugar, desea mantener las cosas simples. Scrum puede ser bastante abrumador, así que reduzca las cosas . Sugiero comenzar solo con lo siguiente:

• Mantenga algo parecido a Scrum Sprints, pero simplifique. Acuerde una meta con el equipo, pídales que piensen en lo que quieren lograr para el final de la semana. Esto les ayudará a determinar por sí mismos en qué trabajar cuando una tarea se termina antes de tiempo . Mejor descubra qué lograr la próxima semana para el final del jueves.

• Mantenga el Standup diario, pero que sea breve. Nunca permita que dure más de 10 minutos o la gente se aburrirá y saboteará la reunión. Si se necesita discutir algo más, acuerde una reunión de seguimiento para discutirlo inmediatamente después del Standup: solo las personas relevantes para la discusión específica deben unirse a la reunión de seguimiento, y eso podría significar que incluso usted no necesita asistir. Standup debe ser un informe de estado para el equipo (no para el líder del equipo) y lo que todos planean hacer para el día para que las personas puedan coordinar mejor su trabajo .

Recuerde: no quiere decirles en qué trabajar, quiere que descubran en qué trabajar. No desea coordinar su trabajo, desea que ellos coordinen su trabajo entre ellos.

Una vez que estas dos cosas funcionen de manera confiable durante 3 semanas seguidas, puede comenzar a buscar otras partes de Scrum, y tendrán mucho más sentido con la experiencia que ganó en estas 3 semanas. Como alguien que no ha recibido muchos comentarios, es casi seguro que encontrará lo siguiente de Scrum que querrá implementar y luego serán Retrospectivas. También puede cambiar las cosas usando Kanban como inspiración para Standups.

En lo de Facebook/Twitter, usa la autoridad prestada si puedes. Deje que el jefe le diga al equipo que ha notado mucho tráfico en las redes sociales y que está contento con las personas que usan estos servicios ocasionalmente durante los descansos o cuando es necesario para el trabajo, pero que apreciaría si no se abusa de los privilegios. no está obligado a bloquear los servicios.