La segunda parte con mis errores, la primera
aquí .
Permítame recordarle que soy el propietario del producto en un equipo compuesto únicamente por desarrolladores, y estamos creando una plataforma de TI para administrar redes afiliadas de estaciones de servicio.
Error cuatro
Factor del bus: lo que al principio parecían muchos errores, pero de hecho resultó ser un premio gordo claro para el equipo
¿Para reclutar a 8 personas que no pueden reemplazarse entre sí, sin un probador y primero sin un analista? Parece que me volví loco y decidí hundir el producto.
De hecho , necesito hacer 6 grupos diferentes de servicios, para cada uno de ellos ya existe "la mejor práctica", que se implementan rápida y fácilmente, el mercado de desarrolladores experimentados es grande.
¿Qué
significa para mí un
equipo así ? La capacidad de encontrar rápidamente un equipo con las competencias adecuadas, implementar MVP rápidamente y comenzar a validar las hipótesis de negocio, y ocupar ese nicho muy libre en el mercado.
¿Qué es esto
para el equipo ? En el nivel inicial, hay muchas competencias diferentes que pueden compartir entre sí, la capacidad de cada característica de usar la solución más rápida posible y, lo más importante, aprenden algo nuevo constantemente, y esto, como ven, es interesante incluso para los adultos mayores. (Al menos mi equipo de desarrollo comparte estos principios).
Mientras prueba las hipótesis de negocios, el equipo de desarrollo se enfrenta entre sí y con el tiempo comienza a probar hipótesis técnicas dentro de sí mismos, por lo tanto, en las disputas, se forma la arquitectura objetivo de la plataforma que creó el EQUIPO, y no solo un arquitecto. "Todo arquitecto" es una persona, en mi opinión, inútil, costosa y no existe :) Cuando un equipo tiene la misma responsabilidad, el producto se convierte en una idea común, todos lo aplauden, ya no quiero cambiar la responsabilidad. De una manera tan espinosa, el equipo crece, toma decisiones, CÓMO hacer que el producto avance, se expanden las competencias, aparecen la intercambiabilidad y la autoorganización. Todavía no hemos pasado por este camino, pero tarde o temprano pasaremos. Por supuesto, ahora estamos ampliando el equipo a un probador dedicado, pero al principio, el equipo es bastante capaz de ocuparse de esta función.
Sí, es más fácil tomar 6 desarrolladores de Java y ahora son intercambiables de inmediato, pero rápidamente desde cero no harán un producto que funcione y estarán muy limitados por sus competencias.
Por cierto, es extremadamente difícil ser el propietario de un producto de TI sin experiencia en esa TI, por ejemplo, un desarrollador, analista de sistemas o consultor (cualquiera excepto los gerentes de proyecto), e incluso si tiene un arquitecto gurú, será su producto, no el suyo. . Aquí puede discutir, pero la práctica y las estadísticas son las siguientes.
Error cinco
Es un inconveniente para mí, por lo que a otros no les gustará
Nuestro equipo a menudo preguntaba "¿Quién necesita esto?", "El cliente lo quiere así", "Definitivamente es un inconveniente porque no me gusta", etc. Al principio, por supuesto, puede pensar en el cliente, ofrecerle algo y, basándose en los comentarios, completar el trabajo atrasado. Lo principal aquí es realizar un estudio cualitativo y escuchar dolores, no soluciones preparadas, de lo contrario, pedirán un "caballo más rápido" y no una máquina que funcione perfectamente.
Es necesario sumergir al equipo en el dolor del
cliente , llamar a los
clientes y al equipo para que lo arreglen, darle al equipo los contactos de aquellos clientes a quienes siempre pueden pedirles una opinión o verificar rápidamente la funcionalidad.
Comencé a decirme más a menudo: "Nunca intentes el papel de un cliente si no estabas en su lugar y no dejes que el equipo lo haga". ¿Por qué discutir en vano si puede preguntarle a la persona por quien está haciendo esto?
Error seis.
Nadie necesita prototipos
Un error muy grande para un RO principiante es no hacer prototipos o probar hipótesis. Me gustaría crear rápidamente lo bello e inmediatamente lo productivo.
Si el dolor del cliente: él no ve las estrellas por la noche debido al mal tiempo, y usted crea una nave espacial para él de inmediato, tratando de superar sus expectativas y hacerlo 100 veces mejor de lo que podría haber imaginado, entonces este es un claro error. Tenía una tarea diferente, dolor y deseos.
Puede pasar tres días o una semana, dibujar a mano cómo se verá el producto y también mostrárselo al cliente. Pídale que descubra cómo lo usará y no olvide hacerlo cada vez que las ideas se transfieran a la cartera de pedidos del producto.
Bueno, cuando se te ocurrió una característica brillante, la creaste un prototipo, tu usuario aplaude y realmente la quiere, no, todavía no puedes llevarla a trabajar :) No te olvides de las métricas de las características, tanto de la tienda de comestibles como de los negocios. Las métricas son generalmente una historia especial con errores, más sobre ellos más adelante y con más detalle en la próxima entrega. Mientras que el anuncio ...
Error siete.
Métrica de omnipotencia
Permítame recordarle que nuestro equipo es parte de una startup muy grande en una gran empresa. Tratar las métricas del producto con las partes interesadas fue difícil. Poner una métrica comercial en una solución de TI que todavía está en la etapa de diseño es una mala idea. Pero los inversores deben mostrar su trabajo, incluso si todavía no hay incrementos para el usuario.
Cualquier métrica de dinero desmotivará tanto a usted como al equipo, pero es precisamente sobre ellos que las partes interesadas querrán observar. Y ahora ya está en la pista resbaladiza PI, luchando con confianza hacia abajo, no puede influir en esta métrica en un sentido positivo. Y en todos los sentidos, a partir de ahora, el producto parece ineficiente y no rentable.
Si no cometió un error número 6, entonces tiene todas las oportunidades de convencer a las partes interesadas, usar y mostrar el prototipo a los usuarios, recopilar comentarios y poner métricas de atracción en él. Haga que el desarrollo sea lo más transparente posible, muestre lo que está haciendo en este prototipo, qué botón o formulario funcionará, qué le permitirá hacer y cómo usar un calendario hermoso que aparecerá muy pronto. Lo principal aquí es no
prometer demasiado y cumplir todas sus
promesas.Resumen de conclusiones:
- Primero, si es tuyo, ve a la escuela RO
- No eres inmortal, no agarres todo de una vez, recluta un equipo en el que estés listo para confiar
- Definitivamente necesitas un scrum master. A tiempo completo.
- Toma una oportunidad. El equipo de scrum se volverá intercambiable tarde o temprano, y las hipótesis de negocio no quedan en el suelo, es mejor tomar un asiento vacío en el mercado más rápido con su MVP, aunque con los riesgos del factor de graves al comienzo, que no tener tiempo para tomarlo.
- Comunícate más con el cliente, recuerda su dolor, intenta resolverlo.
- Cuestiona todas tus ideas, crea prototipos y prueba hipótesis, mira la reacción del cliente, estamos aquí para reunirnos :)
- Elija las métricas usted mismo, deberían ayudarlo a hacer un producto de calidad y iterativamente bueno. Recuerde que hay muchos productos que permanecieron en el "valle de la muerte" debido a la falta de calidad.