Diarios de Praga I: Como Aplicar Scrum en un Ambiente Desfavorable

Praga es una ciudad hermosa, con una historia muy interesante, una arquitectura impresionante, mujeres hermosas y cerveza de excelente calidad a un precio muy accesible (increíblemente es más barata que el agua).

La razón por la que fui llamado de esta empresa de Praga es simple, no consiguieron Project Managers experimentados en el mercado local. Contrataron un par, pero no tenían la experiencia necesaria o eran muy estructurados o poco flexibles para adaptarse al trabajo.

Esta empresa desarrolla sitios de E-Commerce y provee servicios de hosting y soporte sobre ellos. Adicionalmente realizan campañas de marketing para estos clientes y los asesoran en cualquier tema relacionado. El equipo humano es muy bueno (en general), pero hay innumerables as aspectos para mejorar que les voy a comentar:

• No utilizan procesos formales, y tienen a un mismo equipo desarrollando nuevas funcionalidades y resolviendo bugs. Trabajan con un SLA con los clientes, ya que al tratarse de sitios transaccionales donde grandes sumas de dinero están en juego. Claramente no se pueden dar el lujo de no resolver bugs críticos inmediatamente luego de recibirlos. El equipo de desarrollo recibe tareas de dos fuentes, la gente de soporte que recibe los bugs del cliente y del Project Manager que maneja el desarrollo de nuevas funcionalidades (su humilde servidor).
• Los clientes tiene una mala imagen de la empresa porque bajo estas condiciones los planes de desarrollo de nuevas funcionalidades no pueden cumplirse ya que la resolución de bugs en el sitio en producción rompe con cualquier tipo de plan.
• Otro tema es que los clientes tardan mucho en responder preguntas, aprobar especificaciones y diseño. Esto también hace que las funcionalidades se retrasen y el cliente piensa que el equipo se sienta de brazos cruzados en ese tiempo.
• Los clientes no son empresas de software con las que siempre trabajé, sino empresas muy tradicionales que tienen un sitio web de E-Commerce, y la gente de sistemas son generalmente dinosaurios incompetentes pro PMI con nula capacidad de cambio.
• Finalmente, sus procesos técnicos son medievales, no hacen code reviews, no automatizan tests, no hacen unit tests, no corren pruebas de regresión, no tienen ambientes de staging (solo tienen ambientes de QA y producción bastante distintos entre ellos). Ni hablar de test driven development (algo con lo que francamente nunca trabaje todavía) o metodologías agiles.
• Como los clientes no confían completamente en ellos, no lograron estar contratados como time and materials. Tienen un contrato fijo de soporte y hosting, y luego por cada nuevo feature que se desarrolla, se prepara un contrato de costo fijo, incluso para cambios de pocas horas. Con ese esquema es imposible controlar costos, manejar un P&L o hacer un forecasting.
• Los clientes tienen picos de trabajo descontrolados, urgencias todo el tiempo, y esperan una reacción rápida a estos pedidos.

Estoy tratando de implementar scrum tailorizado a su forma de trabajo. Por suerte logre convencerlos de que es la solución para ellos, pero todavía no sabemos como aplicarlo en este esquema.  Con la necesidad de resolver bugs por el mismo equipo (con el SLA) la capacidad del equipo nunca va a ser igual y la velocidad va a fluctuar. Nunca se va a poder hacer un release planning (tener un plan a largo plazo)  predecible y confiable.

En fin, además de darme la posibilidad de viajar por Europa los fines de semana, el trabajo un gran desafío, con muchos problemas para resolver. Espero mantenerme entretenido en los próximos meses. Los mantengo al tanto, Na shledanou!