Cómo comunicarse con desarrolladores en otros lugares

Es común hoy en día que los gerentes de producto y los equipos de desarrollo estén en lados diferentes. Además del negocio indio de subcontratación de software, esta situación puede darse entre sucursales de grandes empresas, así como entre empresas y filiales adquiridas.

Si el equipo de desarrollo no está a tu lado, la dificultad de comunicación y ejecución se magnificará aún más. Los problemas que surgen del desarrollo externo a menudo conducen a una baja moral del equipo, y algunas personas incluso cuestionan abiertamente si el desarrollo externo puede realmente ahorrar costos.

Tengo tres sugerencias para mejorar la eficiencia de la comunicación con equipos de desarrollo remotos.

Cuanto más separado esté el equipo de desarrollo, mayor será la dificultad de comunicación causada por las diferencias de idioma, cultura y hora. Más importante será determinar un documento de descripción completo del producto. Si el gerente de producto no está seguro de qué producto construir (o cambia de opinión repetidamente), el equipo de desarrollo externo solo se agotará y desperdiciará esfuerzos. Esto es un desastre, no menos que un médico que prescribe la receta equivocada. Si está lejos del equipo de desarrollo, ya sea que esté comunicando el contenido de la documentación del producto o discutiendo modificaciones al diseño del producto, asegúrese de utilizar prototipos de alta fidelidad para comunicarse. Después de todo, leer documentos no es fácil si el documento está en un idioma no nativo o la explicación no es clara, la eficiencia de la comunicación será aún menor.

Los equipos de desarrollo locales pueden identificar y resolver conflictos fácilmente (por ejemplo, dos gerentes dando orientaciones contradictorias). Muchas situaciones inesperadas ocurren en los equipos de desarrollo remotos y, a menudo, pasan varios meses antes de que se descubran los problemas. Esto se debe a que los desarrolladores externos tienen que especular sobre una variedad de opiniones diferentes (y a menudo se equivocan). Por lo tanto, alguien debe ser responsable localmente de coordinar el trabajo con el equipo externo. Esto no significa que toda la comunicación deba pasar por esta persona, pero debe quedar claro que el equipo de desarrollo externo solo recibe órdenes de él. Este trabajo puede ser realizado por un gerente de proyecto local, un desarrollador senior u otro supervisor.

Hoy en día, existen muchos medios de comunicación empresarial, además del correo electrónico y la mensajería instantánea, también existen opciones de videoconferencia. Además, el servicio de telefonía por voz (VoIP) ha reducido considerablemente el coste de las llamadas de larga distancia internacionales. llamadas a distancia. Aun así, las ventajas de la comunicación cara a cara son irremplazables. Cada trimestre, los gerentes de producto deben viajar a otros lugares para reunirse con el equipo de desarrollo al menos una vez y comunicarse cara a cara con los arquitectos y gerentes de software. La comunicación cara a cara ayuda a mejorar las relaciones (cooperativas) y aumentar la eficiencia de la comunicación. Además, el intercambio de personal también es una forma eficaz de comunicación, que permite al programador principal trabajar localmente con el gerente de producto durante un período de tiempo, o que el gerente de producto trabaje en una ubicación diferente durante un período de tiempo.

Es un placer especial trabajar con un excelente equipo de desarrollo según el método que describo. Si trabaja con un equipo de subcontratación indio, la cooperación será más cómoda debido a la diferencia horaria. Cuando voy a trabajar todas las mañanas, el progreso del proyecto de la otra parte ya está frente a mí. Puede utilizar el día (la noche de la otra parte) para comprobar y probar el código y proporcionar comentarios, lo que acorta significativamente el ciclo del proyecto.

Tenga en cuenta que si está realizando trabajos relacionados con prototipos de productos fuera del sitio, debido a que el ciclo es muy corto (iteraciones varias veces al día), debe estar preparado para lidiar con los problemas de la otra parte en en cualquier momento e invertir más energía.

Otra forma de resolver el problema del desarrollo externo es contratar un equipo de producto externo. Esta tendencia está aumentando y creo que este modelo será adoptado por más empresas. No tienes que preocuparte por esto. Hemos pasado 10 años capacitando a desarrolladores y evaluadores profesionales en otros lugares, y probablemente tomará otros 10 años capacitar a gerentes y diseñadores de productos profesionales.

A los gerentes de producto les preocupa mucho escuchar a los desarrolladores quejarse así: ¡No se pueden agregar más funciones! Tenemos que detenernos y reescribir el código. La base del código era un desastre, como un tigre de papel, incapaz de hacer frente al continuo aumento de usuarios. ¡Ya no podemos mantenerlo!

Esta escena ha ocurrido en muchas empresas y sigue sucediendo una y otra vez. Cuando eBay se encontró con esta escena en 1999, la empresa estaba al borde de un colapso más allá de la imaginación de cualquiera. Esto también sucedió con Friendster hace unos años, cuando abrieron la red social a los usuarios de MySpace. Algo similar ocurrió cuando Netscape y Microsoft iniciaron una guerra de navegadores, y todo el mundo conoce el resultado final. De hecho, pocas empresas pueden capear la tormenta.

Cuando una empresa se encuentra en esta situación, el equipo de desarrollo suele ser el chivo expiatorio. La experiencia me dice que este tipo de problemas muchas veces son causados ​​por errores en la gestión del producto. Porque el gerente de producto ha estado obligando al equipo de desarrollo a trabajar a plena capacidad y desarrollar tantas funciones como sea posible.

Todas las arquitecturas de software tienen límites funcionales. Si se ignora la arquitectura técnica básica del producto, una vez que el sistema cruce el punto crítico de colapso, se producirán consecuencias irreparables.

Durante el proceso de reescritura del código, los usuarios no pueden ver ninguna mejora en el producto. Se podría pensar que reescribir el código sólo llevará unos meses como máximo, pero en realidad lleva mucho más tiempo. Sólo puede quedarse al margen y observar cómo los usuarios se pasan a la competencia, y en este momento, los competidores mejoran constantemente sus productos.

Si no se ha encontrado con una situación así, es necesario prepararse para un día lluvioso. Debe reservar una cierta cantidad de capacidades técnicas de I + D, lo que se llama margen de maniobra en eBay. Muchos problemas causados ​​por la rápida expansión de los productos están relacionados con la escala de expansión. Margen significa evitar tocar el límite superior de las capacidades técnicas, reservar espacio para el crecimiento del número de usuarios, reservar espacio para el crecimiento de transacciones, reservar espacio para nuevas funciones y garantizar. La arquitectura técnica básica del producto puede cumplir con los requisitos del equipo.

Trabajar con el equipo de desarrollo debe seguir los siguientes principios: Reservar un 20% de tiempo independiente para el equipo de desarrollo en la gestión de productos y dejarles usarlo libremente. El equipo de desarrollo puede utilizar este tiempo para reescribir el código, mejorar la arquitectura, refactorizar partes defectuosas del código base o reemplazar el sistema de administración de la base de datos para mejorar el rendimiento del sistema y evitar la situación en la que necesitemos detenernos y reescribir el código.

Si ya estás en una mala situación, deberías destinar al menos el 20% de tus recursos a hacer ajustes, pero me preocupa que algunos equipos no estén dispuestos a destinar ni siquiera el 20%. Si ya tiene problemas para reescribir, significa que la empresa está en peligro, aquí tiene algunas sugerencias para su referencia.

El primer paso es desarrollar un plan y un cronograma prácticos basados ​​en los objetivos de modificación del producto determinados por el equipo de desarrollo. Por lo general, el tiempo de desarrollo estimado de los equipos de desarrollo experimentados es cercano a diez, pero la reescritura de código es una excepción, porque la mayoría de los equipos no tienen experiencia real en la reescritura de código y las estimaciones suelen ser demasiado optimistas. Debe evaluar la situación cuidadosamente y verificar cada detalle para asegurarse de que el plan sea viable.

El segundo paso es que, siempre que sea posible, es mejor dividir el objetivo de reescritura en varias partes grandes para lograr modificaciones incrementales de modo que los usuarios puedan sentir la mejora del producto, incluso si extenderá el 9- mes de trabajo a 2 años, también se debe adoptar este método. Al reescribir código, garantizar que los usuarios puedan ver mejoras funcionales, incluso si requiere tan solo el 25% y hasta el 50% de los recursos de desarrollo, es crucial para mantener la participación de mercado del producto (especialmente los productos de Internet).

En el tercer paso, debido a los recursos limitados para desarrollar funciones visibles para el usuario, se debe tener cuidado de seleccionar las características correctas del producto y garantizar la exactitud de la definición del producto.

Después de que eBay resucitó, nos comprometimos a no repetir los mismos errores e inmediatamente comenzamos una nueva ronda de reescritura de código para dejar atrás la crisis. De hecho, debido a su rápido crecimiento, eBay ha reescrito su código tres veces, la última vez utilizando un lenguaje de programación y una arquitectura completamente diferentes. El equipo de desarrollo pasó varios años reescribiendo masivamente millones de líneas de código mientras desarrollaba una gran cantidad de funciones nuevas sin afectar a la base de usuarios. Esta es la historia más emocionante sobre la reconstrucción de un sitio web a mitad de camino que yo sepa.

Es mejor cavar un pozo cuando se tiene sed que prepararse para un día de lluvia. Para evitar problemas de raíz, no olvides reservar un 20% de margen.