Soy el CEO de una startup SaaS. Mi equipo de desarrollo se queja de que los requisitos no están lo suficientemente detallados aunque somos ágiles. Siento que están pidiendo ser albañiles en lugar de arquitectos. ¿Les digo que tomen más iniciativa para comprender el problema del cliente o les digo qué construir?

Es realmente imposible decirlo sin conocer los detalles de su situación. Lo más probable es que caigas en algún punto entre dos extremos. He visto ambos extremos “en la naturaleza”, por lo que no son completamente hipotéticos. Pero, aún así, lo más probable es que estés en algún punto intermedio:

Extremo # 1: todos sus ingenieros necesitan ser despedidos.

Está cargado con un equipo perezoso de punzones que solo quieren cobrar sus exorbitantes salarios sin tener que pensar. Prefieren la compañía de las computadoras y evitan la exposición a personas reales a toda costa. Piensan que el mundo les debe regalías solo porque saben la diferencia entre Linux y Unix y cualquier cosa que hagan que no sea escribir comandos en una consola es una pérdida de sus preciosos talentos. No se ría, realmente existen equipos completos de estas personas (principalmente en grandes empresas).

Extremo # 2: necesitas ser despedido

Cree que “hacer Agile” significa que los requisitos surgen mágicamente de la frente de sus desarrolladores sin que usted u otra persona tengan que hacer un trabajo adicional. No comprende por qué su equipo lo molesta constantemente para acceder a usuarios reales y desearía que ya lo abandonaran. Ágil es algo maravilloso porque significa que nunca tienes que escribir nada ni comprometerte con una dirección. Cada día que ingresa a la empresa y simplemente le dice a los ingenieros que implementen la última tendencia que escuchó en Marketplace mientras conduce su Tesla al trabajo y lo harán al día siguiente. No te rías, esta persona también existe.

Lo más probable: en algún punto intermedio

Tienes un equipo de ingenieros en su mayoría talentosos que quieren hacer lo correcto pero están frustrados por algunos obstáculos. Estos obstáculos deben eliminarse y el equipo debe ser remotivado y luego comenzarán a tomar posesión de su producto nuevamente. Aquí hay tres victorias rápidas para abordar problemas comunes con “hacer ágil”:

1) Si los ingenieros no tienen acceso directo y sin restricciones a un usuario real cuyo trabajo diario está trabajando con los problemas que resuelve su software, consígalos de inmediato. Es imposible “hacer ágil” sin esa condición previa o una aproximación muy buena.

2) Si no tiene un ciclo de retroalimentación abierto y consistente en su proceso de desarrollo, comience uno de inmediato. La manifestación común de esto es un ciclo de iteración de una a dos semanas en el que su equipo lanza * software de trabajo * a * usuarios finales reales * al final de cada iteración, recopila comentarios de esos usuarios finales, examina su propio proceso para buscar por ineficiencias, y utiliza todos los comentarios anteriores para impulsar lo que hacen en la próxima iteración. Este es el corazón de Agile y si no lo estás haciendo, solo te estás engañando a ti mismo. Sí, es mucho trabajo que no es codificación y muchas reuniones. Lo siento.

3) Si tiene una cultura de desarrollo basada en establecer fechas límite con listas de funciones destacadas que están entre 3 y 6 meses y luego llevar al equipo a cumplir esas fechas límite, deje de hacerlo de inmediato. El objetivo de “hacer Agile” es ajustarse constantemente a los comentarios de los usuarios y entregar exactamente lo que es necesario, comenzando por lo más importante primero. Esto es, por definición, imposible de predecir al nivel de una lista de funciones destacadas de 3 a 6 meses.

La conclusión es…

Si está haciendo declaraciones como la suya en foros públicos como Quora, entonces su equipo (y, por extensión, su empresa) está en serios problemas. He trabajado y ejecuto startups, así que entiendo que esto es difícil, pero: debes dejar de desarrollar productos durante una semana y ordenar tu equipo. Traiga a un tercero imparcial para facilitar y ayudar a su equipo a llegar a una comprensión colectiva de cómo quieren hacer el trabajo. Y este ejercicio debe incluir a * todos *, incluido usted. Y si no ha despedido a alguien al final del ejercicio, entonces probablemente haya pasado por alto algunas verdades difíciles en lugar de enfrentarlas de frente.

Esta es una queja común, y una que he escuchado articulada por todos lados. Los ingenieros se quejan de la falta de estructura y detalles, mientras que los ejecutivos / gerentes se sienten frustrados por la falta de iniciativas propias. Y, la realidad generalmente se encuentra en algún lugar en el medio.

Sin haber hecho referencia a sus requisitos, cualquier respuesta sería insuficiente, pero aquí hay algunos consejos para ayudarlo a comenzar:

• Asegúrese de que cada lanzamiento tenga un objetivo / propósito claro. Es importante comprender que los puntos de decisión se toman en cada paso del camino (y no solo en la fase de idea visionaria). Un objetivo claro ayuda a guiar a su equipo a tomar decisiones clave.
• Acuerde con el equipo una forma estructurada de preparar las solicitudes. Si bien los programadores han normalizado las formas de trabajar y codificar, no necesariamente tenemos eso para preparar las especificaciones. Es importante comprender que las especificaciones tienen dos propósitos clave: (a) Dar forma a una idea (también conocida como Concepto), (b) Herramienta de comunicación. Al igual que cualquier otra habilidad, la persona que prepara las especificaciones debe ser buena para concebir y saber cómo comunicar el concepto al equipo. He estado usando BDD (Presentación de BDD) durante años, y he tenido un gran éxito. Pero tenga en cuenta que si no es bueno para concebir, no comprende el medio con el que está trabajando, ningún método (ni siquiera BDD) lo ayudará.
• Acuerde con el equipo reducir el nivel de detalle con el tiempo. Necesitará al menos una ronda para familiarizarse entre sí. Simplemente externalizar y comunicar su deseo de minimizar el nivel de detalle es muy útil. La mayoría de las personas asumen que es un hecho, pero la realidad es que en realidad estás entregando decisiones clave al equipo. ¿No esperarías que el jefe tenga una opinión muy fuerte y una participación en las decisiones que se toman? Si no puede confiar en su equipo o maniobrar el arte de guiarlos para tomar buenas decisiones, realmente no tiene sentido volverse ágil.

Por último, pero no menos importante, le insto a que se familiarice con la administración de productos o contrate a un gerente de productos experimentado. Los buenos gerentes de producto son hábiles no solo para traducir una idea en un concepto estructurado, sino que tienen el talento organizacional y de liderazgo para impulsar la entrega de extremo a extremo. Un gerente de producto experimentado sabe exactamente qué esperar de los ingenieros y cómo maniobrar con el nivel de detalle adecuado para guiarlos. A menos que esté buscando una construcción rápida para vender (razas raras que es uno en un millón), invertir en un PM por adelantado bueno y experimentado realmente le ayuda a ahorrar dinero, tiempo y frustración en el futuro.

El desafío que usted cita resuena con nuestra experiencia, hasta cierto punto. Lo peor que puede hacer es caer en la trampa de especificar los requisitos con gran detalle porque cree que su equipo no puede construir sin ellos. Creo que lo que enfrenta es una desconexión entre un negocio ansioso y un equipo de desarrollo desautorizado. .

Comparto parte de nuestra experiencia, que con suerte le proporcionará una idea.

Hace aproximadamente un año, en el segundo trimestre de 2013, enfrentamos algunos desafíos importantes. Con un equipo de desarrollo de menos de 10 desarrolladores,

• Estábamos haciendo ~ 5-10 lanzamientos al mes en nuestra pila de productos
• Nuestro tiempo promedio transcurrido desde la conceptualización de una característica o mejora hasta la entrega en producción fue de ~ 100 días

Nuestro mandato era entregar valor a los usuarios más rápido al acelerar la tasa de lanzamientos y reducir el tiempo de producción tanto como pudiéramos. Esencialmente, queríamos ser más receptivos a las necesidades de nuestros clientes y el negocio.

Viejo mundo
Si bien hubo muchas áreas de mejora, a continuación enumero lo que notamos como características principales de nuestro proceso de desarrollo

• Desarrollo de historias de usuarios, casos de uso y escenarios : nuestra gestión de productos sirvió como un fuerte proxy para el cliente y diligentemente detalló historias de usuarios y casos de uso para ayudar a los desarrolladores a conocer las necesidades de nuestros clientes. Esto era lo razonable, ya que nuestro producto requiere un aporte significativo de expertos en el dominio y la preparación de casos de uso para ayudar a los desarrolladores a comprender los problemas que nuestros clientes quieren resolver.
• Fuerte competencia en áreas específicas de nuestra pila : nuestros desarrolladores han cultivado una competencia significativa en áreas claramente identificadas de nuestra pila de desarrollo. Nuevamente, como muchos equipos, combinamos las habilidades con las áreas de código. Esto nos permitió mover las áreas respectivas de código cada vez más rápido
• Aseguramiento de la calidad por parte del equipo de control de calidad y la gestión del producto antes del envío : habíamos desarrollado una cultura de aseguramiento de la calidad como la última puerta de desarrollo antes del envío al cliente. Esto nos permitió detectar áreas donde no habíamos satisfecho las necesidades de nuestros clientes, o la historia del usuario no estaba completamente satisfecha antes de enviar el producto. Esto es difícil de argumentar en contra.

Por extraño que pueda parecer, estas fueron las prácticas que nos detuvieron. Miremos de cerca

• Desarrollo de historias de usuarios, casos de uso y escenarios : a primera vista, esta es una muy buena idea. Sin embargo, esto abstrajo a nuestros desarrolladores de los clientes, lo que dificultó la comprensión de los dolores de nuestros clientes. Buscaron más especificidad en los requisitos. La respuesta aquí fue clara. Necesitábamos acercar el centro de gravedad de nuestro equipo de productos al cliente y eliminar la gestión del producto como un cuello de botella. En cambio, la gestión del producto serviría como un puente para el cliente, no como un guardián.
• Fuerte competencia en áreas específicas de nuestra pila : esto funcionó muy bien para nosotros en los primeros días. Sin embargo, dado que todo lo que enviamos es multifuncional, necesitábamos desarrolladores de cada área de código para enviar cualquier cosa. Esto condujo a dependencias clave del hombre que obstaculizaron nuestros esfuerzos de desarrollo.
• Aseguramiento de la calidad por parte del equipo de control de calidad y la gestión del producto antes del envío : dado que la gestión del producto tenía la mejor comprensión de los problemas de nuestros usuarios, este se consideró un paso importante y crítico. La administración del producto solicitaría expertos en el dominio de nuestro equipo para validar el producto contra el comportamiento esperado antes del envío. Esto llevó a un tiempo significativo agregado después del desarrollo y antes del envío.

El nuevo Mundo
Desarrollamos principios que seguiríamos para romper con esta práctica y reducir nuestro tiempo de producción al tiempo que aumentamos nuestra velocidad (medida por el número de lanzamientos)

• Acerque nuestro centro de gravedad a nuestro cliente : el propósito aquí era singular. Necesitábamos que nuestro equipo de desarrollo tuviera una comprensión visceral de los objetivos y dolores de nuestros clientes. Hicimos esto mediante la celebración de múltiples seminarios sobre el flujo de trabajo del arquitecto, así como la construcción de la física interna. Paralelamente, comenzamos a realizar entrevistas con los usuarios y sesiones de usabilidad, con la advertencia de que estos últimos serían liderados por nuestros desarrolladores, coordinados por la administración del producto.
• Reduzca el tamaño del lote : decidimos que trabajaríamos sin descanso para minimizar la cantidad de mejora del producto que se puede enviar de manera significativa a nuestros clientes. También hicimos movimientos acordes a través de nuestra pila técnica para facilitar esto
• Descentralizar lanzamientos : queríamos que los desarrolladores fueran responsables del envío del producto, desde la etapa de conceptualización del boleto para el lanzamiento. Esto solo podría hacerse si redujimos el tamaño de cada versión, en cuanto al producto, a algo que pudiera ser administrado por un desarrollador. Además, requería que nuestros servicios se movieran independientemente el uno del otro cuando era necesario.
• Mejora de la cobertura del código : decidimos hacer un esfuerzo consciente, incluso a costa del beneficio a corto plazo, de compartir el código en todo el equipo. Esto se hizo para permitir que múltiples desarrolladores muevan el código a través de la pila.

El resultado, hasta ahora

Tiempo de producción vs fecha de creación

• Redujimos nuestro tiempo de producción (definido como tiempo desde la conceptualización hasta la producción) de 100 días en promedio a 10 días. Como resultado, ahora somos muy receptivos tanto a las necesidades de nuestros clientes como a nuestra visión del producto.

# de lanzamientos por mes

• Casi hemos cuadruplicado la cantidad de lanzamientos que hacemos. Esto realmente valió la pena para nosotros en el cuarto trimestre, donde lanzamos 2 nuevos productos: Sefaira para SketchUp y Sefaira para Revit, e hicimos varios lanzamientos que beneficiaron a nuestros clientes.
• En términos de cobertura de código, el 80% de nuestros desarrolladores contribuyeron a áreas de nuestro código donde invertimos el 80% del presupuesto de desarrollo

tl; dr
Debe empoderar a sus desarrolladores para que resuelvan los problemas, y puede hacerlo ayudándoles a comprender el dolor del cliente. No caiga en la trampa de especificar requisitos con gran detalle. Dado que eres una startup, es probable que estés inventando la mayoría de las cosas.

Un poco más leyendo aquí
Buen proceso, mal proceso
Buen desarrollador, mal desarrollador
http: //benhorowitz.files.wordpre …

tl; dr
“¿Debería ser un granero? ¿Un centro comercial? ¿Pensaste en la ventilación? ¿Cuántas personas vivirán allí? ¿Deberíamos construir una bodega? ¿Y cuándo finalmente nos mostrarás el lote? ¿Qué quieres decir con que no hay mucho?”
—-

Trabajé como desarrollador en dos startups, y regularmente me quejaba de la falta de requisitos / especificaciones en ambos. Su situación puede ser diferente, pero puedo darle una idea de cómo puede suceder esto:

Pero primero: por qué creo que la parte “ágil” de la pregunta es irrelevante:

• Todos hoy en día dicen “¡Somos ágiles!” y tal vez realmente creen eso, pero de hecho, tienen un Gerente en algún lugar dentro o fuera del equipo que inhibe un proceso “ágil” real por sus preferencias o acciones.
• Cada equipo tiene un enfoque ligeramente (a veces muy) diferente de ágil. Por lo tanto, personalmente creo que declaraciones como: “¡Tu equipo obviamente apesta! ¡Agile no tiene requisitos!” No son útiles. De hecho, puede tener un equipo ágil, que utiliza requisitos extensos, pruebas, características y lanzamientos planificados cada 3 meses, etc. Lo sé, porque lo vi yo mismo durante una pasantía. Este fue en realidad el lugar más ágil que he visto hasta ahora.

Ahora, las dos razones me obligaron a decir: “Bueno, si solo tuviéramos los requisitos …”:

• Microgestión
  Algunas respuestas ya lo señalaron. Si los desarrolladores son constantemente culpados y avergonzados por sus implementaciones “incompletas” e “incorrectas”, sus pobres casos de prueba y su falta de comprensión del problema real, intentarán evitar estas situaciones en el futuro. Esto solo es posible si se les dan más detalles sobre sus tareas, que el CTO les asignó durante una de sus noches de insomnio, pensando que estaba haciendo un gran trabajo. Si el CTO ajustará los requisitos durante el desarrollo debido a su gusto, tener requisitos definidos es el único seguro que un desarrollador pobre tiene contra la arbitrariedad. En defensa del CTO, porque nunca escribió ningún detalle, simplemente no puede recordar lo que quiso decir hace 4 semanas mientras escribía estas 50 tareas detalladas.
  Ya hay muchas cosas que van mal en esta situación, y no debería haber necesidad de despedir a los desarrolladores. Esta es una situación terrible e irreparable para los desarrolladores y nadie debería verse obligado a trabajar en estas condiciones.
• Sin gestión de producto.
  Esto es más sutil y la forma en que formula su pregunta me recuerda esta situación.
  Usted fundó una startup, porque ayer tuvo una o más visiones sobre productos increíbles que desea lanzar al mercado, si es posible. Felicidades, pronto serás rico, obviamente. Desafortunadamente, usted y su socio no son desarrolladores y no tienen intención de cambiar esto. Entonces contratas desarrolladores para hacer lo que se supone que deben hacer: poner ladrillos. Como todavía desea hacerse rico, obviamente no desea contratar a un grupo de material de Google y darles acciones de capital. Recuerde, esta sigue siendo su idea, su visión y su nombre, usted debe ser el que tenga grandes ganancias y se les pagará, ¿qué más quieren? Estos son tus ladrillos.
  Y aquí está la cosa: espera que lo hagan : tomar su visión, darle una forma realista, derivar hipótesis, diseñar y construir prototipos, probarlo con los clientes, definir las restricciones, diseñar y construir productos, acordar compromisos, probarlo minuciosamente, reescriba todo de nuevo, etc. y todo esto es un trabajo duro y estresante , lleva meses, si no años, de esfuerzo constante (que no puede saber, porque no tiene antecedentes), y ya saben que serán responsables de cada decisión Y, sin embargo, espera que lo hagan, por un mal pago, mientras que en una tienda tradicional se les pagará mucho más por solo colocar ladrillos, tal vez haciendo algún trabajo de arquitectura en función de requisitos bien definidos, que obviamente pagarán mucho más de lo que usted paga. págales. La pregunta es: ¿por qué deberían hacer todo este trabajo por usted? ¿Y qué estás haciendo exactamente para ayudarlos? Escupir características que vio en el competidor e ideas para futuros productos y proyectos no es suficiente. Lo menos que podría hacer es definir el objetivo de las próximas semanas, exponer el problema, darles acceso a requisitos o restricciones, o al menos a clientes potenciales, para que puedan refinar los requisitos ellos mismos.

Hubo bastantes preguntas de Quora formuladas recientemente en esta dirección, por lo que me estoy inclinando hacia la segunda explicación. Parece que muchos fundadores sin experiencia en CS tienen dificultades para comprender que los desarrolladores no son estas personas locas, que felizmente codificarán alimentos y café. Aunque existen los burocráticos, una buena parte de nosotros disfruta trabajar en las empresas de nueva creación, porque no hay cascada, requisitos predefinidos y mapas de carreteras que se extiendan hasta el año 2030. Estamos aburridos por los requisitos y los mapas de carreteras, y nos enojamos mirando tareas predefinidas que no tienen sentido para nosotros.
Pero al mismo tiempo, tenemos dificultades para hacer girar productos de la nada . Simplemente entregarnos una de sus visiones simplemente no es suficiente. ¿Tienes idea de cuántas visiones ya tuvimos nosotros mismos? Realmente buenos también, porque vimos a alguien más implementarlos y hacerse increíblemente ricos. ¿Ya somos ricos? La idea es el más fácil de todos los pasos.

O míralo de esta manera si quieres: eres un tipo aleatorio y quieres construir algo. Pero por qué algo, quieres una mansión. Una villa. Un castillo al menos . Desafortunadamente, no tienes idea de cómo colocar ladrillos. Contratemos capas de ladrillos, y como no sabemos nada sobre las capas de ladrillos, la construcción de casas o las mansiones, sabemos que no se les debe pagar mucho. Y aquí hay 5 chicos mexicanos, parados en tu porche y preguntándote qué quieres y dónde. “¿Debería ser un granero? ¿Un centro comercial? ¿Pensaste en la ventilación? ¿Cuántas personas vivirán allí? ¿Deberíamos construir una bodega? ¿Y cuándo finalmente nos mostrarás el lote? ¿Qué quieres decir con que no hay mucho?”
¿Es así como abordarías la aventura de construir una casa?

Nos enorgullecemos de nuestra profesión, y sabemos cuánto valemos, y que nuestro conocimiento y sabiduría son esenciales para el éxito de su empresa. Sabemos lo que necesitamos para construir algo, por lo que, en nuestra opinión, su trabajo es escuchar y tratar de responder nuestras preguntas, o ayudarnos a responderlas. La “sabiduría” que escupe regularmente es principalmente ruido para nosotros. No seremos felices si nos tratan como una gallina ponedora, solo para hacerte rico. Puede pensar que este es nuestro trabajo, nosotros no.

1.) ¿Qué sabor de Agile estás usando? El método más popular, Scrum, tiene el rol de propietario del producto, quien tiene la responsabilidad de documentar los requisitos a través de las historias de los usuarios. XP también usa historias de usuarios. Desafortunadamente, algunas personas creen que “Agile” significa que no necesita especificar requisitos. Este es el sabor Dilbert de ágil. Desafortunadamente, Dilbert Agile es una práctica bastante común, pero generalmente se entiende que no es una mejor práctica en la industria.

2. No conozco ninguna compañía de software que solicite a los desarrolladores que determinen los requisitos del software que se va a construir. Sí, son participantes valiosos en el proceso. En general, tienen grandes ideas e ideas que deberían incorporarse al producto, pero no son “propietarios del producto”.

3. Todas estas empresas emplean gerentes de producto para documentar los requisitos: Google, Facebook, Apple, Amazon, eBay, PayPal y Salesforce. (Verifiqué esto buscando en sus ofertas de trabajo).

4. Si es una startup realmente pequeña y no tiene un Product Manager, puede elegir: 1.) documentar los requisitos (lo hice como CEO de mi propia startup) 2.) contratar un PM / PO o 3.) pedirle a alguien del equipo de desarrollo que asuma este rol . (Debe hacer esta solicitud explícita y elegir bien porque es un rol crítico y generalmente no forma parte de su función).

PD.
Aquí hay una buena descripción del trabajo para un PM de Facebook si decide contratar uno:
Gerente de producto

Buenas respuestas a todos. Déjame hablar con los albañiles / arquitectos. Por alguna razón, generalmente una contratación deficiente o un liderazgo deficiente, algunos desarrolladores han optado por actuar como albañiles, o como me gusta pensar, quieren ser trabajadores de fábricas. Pero el trabajo en la fábrica se puede externalizar fácilmente. Si su equipo de desarrollo está diciendo “dígame exactamente lo que quiere”, debe estar preparado para ser subcontratado a una fábrica que realmente desarrollará exactamente lo que desea.

Por el contrario, esta mentalidad de trabajador de fábrica proviene de la frustración. Su equipo ha trabajado durante meses en un nuevo conjunto de capacidades y el liderazgo ha dicho MAL MAL MALO a todo lo que han hecho. En un ataque de angustia, dicen: “¡Bien! Dinos exactamente lo que quieres y eso es exactamente lo que obtendrás”.

Nunca he entendido la inclinación de esta industria a mantener el desarrollo bloqueado o enviar el trabajo a otra parte debido a la creencia de que la programación es trabajo de fábrica. Al final, un gran trabajo proviene de equipos con pasión. Un buen gerente de producto debe inspirar al equipo a crear una excelente experiencia para el cliente.

¿Qué haces para inspirar a tu equipo?

A decir verdad, a veces puede ser el cliente quien no proporciona información suficientemente detallada sobre el producto y sus requisitos. Hay muchos clientes que tienen varias visiones de su proyecto y, a menudo, simplemente no saben cómo explicar su visión. Cuando agrega mala comunicación, diferencias culturales y problemas de idioma además de eso, es probable que encuentre los problemas que describió.

Es por eso que necesita tener un propietario de producto confiable que esté constantemente en contacto con el cliente, escuchando sus necesidades, convirtiendo las necesidades en requisitos y eventualmente agregándolos a la cartera de pedidos. Puede ser un trabajo realmente duro, pero de esta manera obtendrá tareas detalladas que pueden ser más fáciles de entender y realizar para su equipo.

Debe recordar que Agile es solo una herramienta en manos de las personas y no puede culpar a la herramienta por sus problemas.

Las revisiones de Sprint también son una forma muy valiosa de comprender mejor los requisitos. Este es el momento en que el equipo puede decirle al cliente directamente qué piensa sobre el Sprint y sus tareas. También pueden indicar qué está bloqueando su progreso adicional. De esta manera, los desarrolladores tendrán más claridad sobre qué construir. Al mismo tiempo, comprenderán los problemas del cliente mucho mejor. Con esa comprensión, pueden concentrarse en el proyecto en su conjunto.

Hace unos días encontré esta interesante publicación de blog sobre la gestión de desarrolladores de software que puede serle muy útil: http://bit.ly/devs-managing . En el mismo blog también hay una publicación sobre las responsabilidades del Propietario del producto http://bit.ly/stxpowner , que puede ayudarlo a encontrar a la persona adecuada para este puesto.

Puedo pensar en algunos casos diferentes donde este problema había surgido antes :

1. Ha contratado (explícitamente) un equipo de programadores (y no un socio técnico).
2. Sus definiciones son bastante vagas (es decir, “Construye un motor de búsqueda”).
3. Su hoja de ruta está cambiando demasiado rápido (causando fricción en el extremo técnico).
4. Establece un límite estricto en el tiempo / presupuesto, pero a menudo introduce un desplazamiento de alcance dentro del marco de tiempo inicial que requiere una refactorización sólida.

He estado a ambos lados de la mesa y me he enfrentado a todos esos problemas.

1. Contratación de “Taskers”

Muchas agencias de outsourcing son de hecho “albañiles”. Algunos de mis amigos alquilan desarrolladores por una tarifa mensual y requieren un alcance bien definido que funcione como se definió inicialmente.

También trabajamos con una agencia de outsourcing hace 5 años cuando aún éramos un equipo pequeño. La gente eran grandes desarrolladores pero no podían entender los problemas comerciales. Los presentamos intencionalmente al propietario del producto, pero las historias de los usuarios no sirvieron de nada.

Nuestro líder técnico en ese entonces estaba traduciendo todas esas historias de usuarios en requisitos técnicos para cada uno de los casos de usuarios. Fue una sobrecarga que incluimos por separado, que fue una de las razones por las que ya no estamos trabajando con ellos.

Nuestros retenedores hoy en día están profundamente encarnados en el modelo de negocio de nuestras cuentas. Nuestra gente de tecnología, creatividad y mercadeo trabaja en conjunto para identificar áreas de mejora, programar iteraciones para limpiar “deudas técnicas” y revisar a los competidores por posibles características que podríamos presentar en su lugar. Pero algunas agencias simplemente no tienen los recursos (o el deseo) para implementar un flujo de trabajo similar (ni todos los clientes, para el caso).

2. Definiciones vagas

Algunos de nuestros antiguos clientes fueron bastante vagos en términos de definición de requisitos comerciales.

En la mayoría de los casos, trabajamos con un propietario de producto en una pequeña empresa (una startup financiada) que se ocupaba de docenas de actividades a la vez. Fueron algo descuidados al definir el alcance y trataron de descargar todo eso al equipo técnico.

Lo cual está bien, hasta que entras en un ciclo infinito de iteraciones e interpretaciones que dependen de diferentes partes interesadas en el extremo del cliente.

Eso es especialmente cierto en términos de iteraciones de diseño o características generales grandes, como un comercio electrónico, una plataforma de capacitación, un LMS y similares.

3. La hoja de ruta sin fin

Claro, ágil se trata de flexibilidad y cambio.

Pero hay un paso limitado de conjuntos de cambios que un desarrollador debe comprender hasta que pueda mezclar diferentes instrucciones para las mismas características en el transcurso de unas pocas semanas.

Idealmente, el producto definiría un MVP que es algo “fijo”. Y construir sobre ese MVP. Los cambios serían modificaciones menores del flujo de trabajo, características adicionales u otras formas de mejoras que no requieren la reconstrucción de todo el producto.

Además de eso, es importante definir la flexibilidad de la arquitectura desde el principio.

• Si diseña en exceso la aplicación, puede ser una sobrecarga que demorará una eternidad en reconstruirse.
• Si te vuelves delgado y simple, la introducción de nuevas capas genéricas más tarde puede ser problemático (especialmente después de la vida en la que los clientes en vivo interactúan con la aplicación).

Esta hoja de ruta “siempre en evolución” debe limitarse en cierta medida para lograr la máxima eficiencia y productividad.

4. Límites duros

Las personas no técnicas pueden tener dificultades para comprender cómo un cambio aparentemente menor puede llevar semanas. Esto ejerce cierta presión sobre el equipo técnico siempre que el alcance y el presupuesto estén algo predefinidos.

Recientemente, lanzamos el portal público para un sitio web. El cliente fue excelente y el sitio web fue bastante interesante. La plataforma interactuó con algunas otras aplicaciones que tuvimos que integrar nosotros mismos.

El plan de retención era de 250 horas al mes y nuestra planificación inicial incluía algo de amortiguación para sorpresas inesperadas.

De repente, resultó que nuestra capa de front-end integrada con las otras plataformas causó un amplio conjunto de conflictos. Había 4 versiones diferentes de jQuery definidas en diferentes páginas (incluida una de 2009), con otro conjunto de bibliotecas dependientes para cada una de ellas. Estábamos usando jQuery para algunas animaciones, elementos de menú interactivos y similares.

Terminamos con una lista de más de 100 páginas que causaban diferentes problemas con algunas de las páginas, algunas veces. Había una fecha de lanzamiento prevista para la versión 1 que tuvimos que ordenar lo antes posible. Se requirió reescribir una gran parte de nuestra integración, incluido el SSO y algunas de las API creadas inicialmente que funcionaron en nuestro lado.

Otra instancia fue una plataforma de WordPress que migró de un generador visual a otra solución dinámica con campos editables. Hubo 4 equipos diferentes involucrados y 3 sitios actualizando contenido simultáneamente. El proveedor de alojamiento era inadecuado, soporte técnico limitado (sin ssh), una función de sincronización y migración rota y similares. Eso trajo cien horas adicionales a nuestra tarea de 30 horas previamente asignada.

Claro, todo eso podría manejarse antes, pero no todas las partes interesadas son plenamente conscientes del impacto de esos cambios o la complejidad de los diferentes componentes en la pila técnica.

Volviendo a su pregunta original: averigüe si su hoja de ruta está realmente definida y cuál es el impacto de los cambios regulares en términos de horas facturables. Comprenda la complejidad de la capa subyacente y la arquitectura, y sugiera un enfoque más ligero si es necesario.

Y por último, mantenga una conversación abierta con su equipo técnico . Si desea que tomen más iniciativa y se conviertan en un socio técnico suyo, infórmeles. Si se oponen a invertir en una mentalidad de crecimiento empresarial, probablemente deba buscar un tipo diferente de proveedor.

Tu analogía es informativa. Dices que quieres arquitectos, no albañiles, pero si realmente estuvieras erigiendo un edificio, necesitarías ambos.

Ágiles o no, los ingenieros se benefician de requisitos detallados. En ágil, los requisitos se comunican cara a cara, en pizarras, bocetos, historias de usuarios y cualquier otra cosa que funcione para el equipo, a diferencia de los documentos de especificaciones funcionales masivas. Pero estos son requisitos iguales.

Usted pregunta: “¿Les digo que tomen más iniciativa para comprender el problema del cliente o les digo qué construir?” La respuesta podría ser cualquiera, pero probablemente sea una combinación de ambos. Como CEO, es su trabajo asegurarse de que comprendan el problema del cliente, para armarlos con la información u oportunidades necesarias para recopilarlo, si desea que tomen una iniciativa. También es su trabajo a veces decirles qué construir.

Agile debería permitirle ver los resultados del trabajo de sus ingenieros temprano y con frecuencia, y deberían comunicarse entre sí todo el tiempo. Así es como se asegura de que (todos ustedes, no “ellos”) estén construyendo las cosas correctas.

Finalmente, el último principio en el manifiesto ágil dice que debe evaluar y ajustar su proceso con la mayor frecuencia posible. Y si descubre que sus ingenieros necesitan requisitos más detallados, entonces ese es un ajuste que debe hacer.

Claramente, alguien tiene la culpa aquí. El resultado final es que el producto no se está desarrollando según sea necesario. Es posible que deba analizar por qué el equipo de desarrollo culpa al equipo de administración de productos. ¿Existe una cultura de plazos poco realistas y juegos de culpa? ¿Le está pidiendo a los desarrolladores que proporcionen detalles estimados si están siendo rastreados en comparación con los reales? ¿Las estimaciones se convierten en compromisos? ¿Estás buscando informes de sprint para jugadores débiles del equipo?
En ese entorno, se levantarán muros de defensa. Las personas no se arriesgarán y se comprometerán con lo más bajo posible y siempre tendrán a alguien o algo a quien culpar.
Por otro lado, ¿hay una responsabilidad compartida y autogestión? Esto animará a los desarrolladores a trabajar con el PM en requisitos incompletos. Sugeriría que haga las estimaciones y la planificación para un par de sprints. solo tenga los requisitos y deje que los desarrolladores trabajen en él con total libertad y vea si hay algún cambio en el comportamiento.
El desarrollo de software es un trabajo creativo y, como todos los trabajos creativos, es una gran alegría para el creador. Hay algo que no le permite al creador sentir esa alegría y es cuando se convertirán en meros recursos. encuentre una manera de llevar a cabo ese trabajo creativo: el bucle de retroalimentación de alegría está en su lugar El acceso al cliente final que puede apreciar el trabajo es una forma.

Hay algunas buenas respuestas en este hilo que describen posibles soluciones, por lo que tomaré una perspectiva diferente y me enfocaré en una de las causas del problema que ha descrito. He estado en ambos lados de esta situación, por lo que es interesante escribir al respecto.

La situación que describe sucede mucho.

Los equipos de desarrollo generalmente disfrutan de la oportunidad de interpretar los requisitos de alto nivel en acciones de nivel inferior. Les gusta la sensación de control y la oportunidad de ser creativos. Cuando ejercen este control y creatividad, y lanzan una unidad de trabajo que incluye sus interpretaciones, la forma en que la recibe el equipo de negocios es muy importante.

Esta próxima situación también sucede mucho.

Los usuarios de negocios o, en el caso de un CEO nuevo, miran un comunicado y en sus detalles puede no coincidir con lo que estaban en su imaginación. La forma en que el equipo de desarrollo ha interpretado los requisitos de alto nivel ha dado como resultado algo diferente a cómo interpretarían los mismos requisitos. La forma en que los individuos manejan esta brecha puede cambiarlo todo.

Aquí está la forma positiva de lidiar con la brecha:

Los usuarios de negocios / CEO aprecian la alternativa, hacen algunas solicitudes para ajustar un poco más las partes del lanzamiento hacia su interpretación y el resultado final es una combinación de interpretaciones: un enfoque de ‘lo mejor del pensamiento disponible’. El equipo de desarrollo se siente bien con esto y también los usuarios de negocios. Ambos han aprendido algo sobre las interpretaciones del otro y con el tiempo comienzan a anticipar cómo piensan cada uno.

Aquí está la forma negativa de lidiar con esto, y esto puede crear el problema.

El usuario comercial / CEO se queja de que el equipo de desarrollo no ha interpretado las cosas de la manera “correcta”. Las declaraciones se hacen directamente o mediante insinuaciones de que el equipo de desarrollo “no lo entiende”. Algunos tipos de personalidad pueden ir más allá de esto. Se elabora una lista de “arreglos”, que se entregarán en una atmósfera de “arreglo de lo que se equivocaron en su interpretación original”. La moral del equipo de desarrollo baja una muesca o dos, y surge una reticencia tácita para interpretar los requisitos en el futuro. Cuando llegue la próxima unidad de trabajo, pedirán requisitos de bajo nivel.

No estoy sugiriendo que esto es lo que ha ocurrido en su situación. Estoy reflexionando sobre el hecho de que la situación que describiste sucede mucho. Probablemente tiene muchas razones diferentes para recurrir. Tres observaciones:

• Parece ser más común en las nuevas empresas. Creo que esto se debe a que un solo personaje CEO enérgico tiende a ser dominante en el entorno. Cuando brindan aliento o desaliento, su ‘impacto se amplifica por el hecho de que a menudo es’ su compañía ‘, y los barrios generalmente cerrados de personas en un entorno inicial.
• Esta situación puede ocurrir sin pasar por este ciclo, si el equipo de desarrollo cree que los usuarios comerciales / CEO serán muy críticos si su interpretación no coincide. Por ejemplo, si los miembros del equipo han observado este ciclo jugar con otras funciones en el negocio (marketing …) se puede formar la misma reticencia.
• Si bien puede suceder en cualquier proyecto, parece ocurrir con mayor frecuencia en proyectos ágiles. Creo que esto se debe a que los proyectos ágiles son generalmente proyectos de ‘documentación liviana’, lo que se traduce en descripciones de requisitos comparativamente ligeros. Estos proyectos adoptan rápidamente los requisitos de documentación reducida, pero no necesariamente aumentan su inversión en tiempo cara a cara para hablar, debatir y comunicar sus ideas. Creo que cuando se trata de requisitos, realmente no se puede encontrar un atajo para dedicarles tiempo, pero se puede expresar de diferentes maneras.

Los otros pensamientos son todos válidos y buenas respuestas. Un pensamiento adicional que arrojaría por ahí:

¿Sus ingenieros realmente tienen control creativo? Cuando construyen algo que no es exactamente lo que imaginabas, ¿haces que lo cambien?

Si desea tener requisitos poco estrictos y ser ágil de esa manera, debe estar muy bien integrado con ellos (vea los pensamientos de William) o dejar que controlen el resultado final. Si tienen control, estarán más interesados ​​en determinar sus propios requisitos.

Estar en un lugar donde ambos no tienen control Y no tienen buenos requisitos lo convierte en un desarrollador miserable.

en primer lugar
No dices cuántos años tiene tu equipo. Te aconsejaría que reflexiones sobre sus experiencias pasadas en otros equipos. Históricamente, los desarrolladores a menudo estaban protegidos de los clientes. Necesitan apoyo y el entorno adecuado para trabajar en colaboración con las partes interesadas. Necesitan construir confianza y confianza. Necesitan inclinarse para trabajar en colaboración. Ayudarlos a hacer eso es un trabajo para su líder.

En segundo lugar
Tenga en cuenta cómo se miden los miembros del equipo. Si las personas se miden en la salida del código, hablar con los clientes es solo una sobrecarga. Reducir la necesidad de hablar = mejor desempeño individual. En su lugar, asegúrese de que sepan que están respaldados a un nivel de liderazgo que funciona, las características útiles son lo que importa y la producción de su equipo que se mide, no los individuos.

En pocas palabras, lo que tienes es trabajo de liderazgo que hacer.

Esto es puramente una opinión, no una respuesta.
He estado en una situación así, siendo el ingeniero principal motivado que tiene que alentar a otros ingenieros a tratar de tomar más posesión y ‘resolver’ el problema en cuestión. Tuve que empujar a los ingenieros 10 años mayores que yo … que me pagaran más que a mí … un poco desmotivante ¿eh?

Pero aquí está la cosa, vienen a trabajar para hacer lo que les gusta hacer y en lo que quieren ser mejores: codificación. Sin convencer a los requisitos de que las personas sean vagas o estén paradas frente a una pared todo el día moviendo trozos de papel. Quieren codificar y ser desafiados por problemas lógicos, no por problemas de comunicación. Ser ‘ágil’ no tiene ninguna relación con el hecho de que esta persona solo quiere ‘codificar’ para ganarse la vida, porque debe haber alguien que pueda poner ladrillos BRILLANTEMENTE.

Me harté de ser el tipo motivado y me fui a otro trabajo que era más “albañilería”. Por la razón: no estaba haciendo suficiente codificación para ser mejor como ‘arquitecto’. Todavía tengo suficiente sentido común para seguir las cosas cuando sea necesario, porque al final del día, el producto debe salir y todo el equipo es juzgado por ello si el proyecto falla.

Entonces, supongo que una pregunta es: ¿se lastiman cuando el proyecto falla? ¿O es solo el pobre Project Manager? Si no, hazlos responsables. Nadie se libera del gancho.

A medida que crezca, es posible que tenga que reconocerlos como albañiles y centrarse en la contratación de ‘arquitectos’. Muchas empresas tienen demasiados albañiles y no hay suficientes arquitectos o viceversa. Son más difíciles de encontrar, pero deberían ser fáciles de detectar en las entrevistas. Lánceles un problema que nunca habrían resuelto antes y no pueden saber la respuesta. por ejemplo, un problema mecánico para un ingeniero de software. Si hacen preguntas intuitivas, no hacen suposiciones, piden la oportunidad de ayuda de otros y realmente ‘quieren’ encontrar una buena respuesta, se comportarán como tales. Este es tu analista de negocios. No tendrán tiempo suficiente para codificar, por lo que sus habilidades de codificación no tienen que ser altas, ¡pero deben combinarse con albañiles fuertes y la cantidad correcta de albañiles para el trabajo!

Una relación equilibrada de arquitectos a albañiles hace maravillas. He visto que la proporción sale mal en ambos sentidos: demasiados cocineros y no suficientes albañiles para el arquitecto. Depende del proyecto. No agrupe a todos los ingenieros de software en una sola categoría. Haga que sus ingenieros principales le digan cuándo necesitan más albañiles o arquitectos.

Reiterar un tema en algunas de las otras respuestas.

La conversación es donde tiene lugar la reunión de requisitos. La historia del usuario es un “recordatorio para una conversación” y, por diseño, no se detalla.

Una excelente manera de abordar esta dinámica es programar una reunión de planificación de sprints relativamente larga. Deja tiempo para mucha conversación. Deje que los desarrolladores retrocedan en este punto, haga preguntas, obtenga aclaraciones, pizarras, reduzca las cosas. He visto que estas reuniones toman la mayor parte del día, pero rara vez se pierde el tiempo siempre que la reunión sea civil.

Con demasiada frecuencia, esto se reduce a algunos malentendidos básicos del proceso ágil. Especialmente en equipos remotos, es común hacer cambios cortos en la planificación del sprint y las reuniones iniciales. En una organización que funciona, usted deja estas reuniones con 1) un compromiso para proteger el sprint, y 2) un compromiso para terminar los elementos del sprint y que estén documentados con suficiente detalle.

Otra forma de abordar este problema es utilizar un proceso de tipo Kanban para la escritura de requisitos. Cree una cola para los requisitos de características y haga que los desarrolladores revisen los elementos en la cola antes de que entren en el sprint.

Mi experiencia después de ejecutar productos en seis compañías de software, ¡incluso ahora en Aha! es que lo que están pidiendo es más que solo más detalles requeridos.

¿Entienden la imagen más amplia y la estrategia para el negocio? Si le preguntara a cada persona individualmente, ¿podrían describir la estrategia en una oración y enumerar las 3-5 principales iniciativas de productos? No es agradable.

Sugerimos que comience allí y adopte un enfoque de “puño de gol”. Asegúrese de que todos estén en la misma página y luego asegúrese de que esté claro cuando explique las prioridades que los imperativos se pueden asignar a los requisitos.

La clave es que usted o el líder de un producto deben poseer el “por qué” y el “qué” y la ingeniería deben poseer el “cómo”. Hemos escrito sobre esto extensamente, incluido aquí: “Objetivo primero”: un tutorial sobre la hoja de ruta del producto.

Puede hacer todo esto usando post-its, PPT, Word, Excel y wikis, pero podría beneficiarse de una herramienta de mapa de ruta de administración de productos como Aha!

Muchas respuestas aquí acerca de involucrar a su equipo más, que definitivamente es el camino a seguir. Cada vez que hablo con las empresas y trato de descubrir qué desafíos tienen, lo primero que hago es sentarme con los miembros clave de diferentes equipos para preguntarles qué creen que hace su producto; la mayoría de las veces, todos dan respuestas diferentes. Esto en sí mismo describe un problema básico, nadie realmente comprende la visión o dirección del producto, y apenas entiende cuál es su propósito. Si este es un problema que tiene el equipo, ¿imagina qué problemas tienen los clientes?

La raíz del problema aquí es realmente hacer que su equipo trabaje como un todo. Una cosa que me encanta de ProdPad es que todos nos involucramos en diferentes áreas del producto, desde marketing hasta contenido, incluso hablando con los clientes. Todos podemos expresar nuestros pensamientos y participar en conversaciones, lo que realmente le da a todo lo que hacemos una perspectiva única.

Mis sugerencias para usted serían: involucrar a su equipo de desarrollo en ese proceso también. Pídales que piensen en la hoja de ruta de su producto, en las ideas, en lo que está por venir, etc. De esta manera, sentirán que en realidad son parte de algo en lugar de solo las personas a las que les asignan tareas. También comprenderán los dolores por los que atraviesan sus clientes y podrán priorizar sus sprints mucho mejor. ¡La comunicación es clave!

” ¿Les digo que tomen más iniciativa para comprender el problema del cliente o les digo qué construir?”

Debe tener un propietario de producto dedicado: esta persona desempeñará una serie de funciones: representa al cliente, es el experto en el dominio, trabaja con otras partes interesadas de la empresa (como los ejecutivos, etc.). Esta persona también es responsable de escribir las Historias de usuarios; escribir buenas historias de usuario es un trabajo * tedioso * que debe hacerse. Esta persona hará un seguimiento regular (stand-ups diarios) con los desarrolladores, y se preparará para el próximo Sprint en paralelo, y por supuesto, todas las demás tareas relacionadas con el lanzamiento al mercado, incluidas las hojas de ruta del producto, etc.

Como CEO y (presumiblemente) Director de Producto de una startup, es su trabajo comprender el problema del cliente y transmitir esa comprensión al equipo de desarrollo. Aún mejor si está trayendo anécdotas específicas de las conversaciones con los clientes, o haciendo arreglos para que escuchen las conversaciones de los clientes / llamadas de ventas.

Dicho esto, si el equipo de desarrollo no tiene una orientación al cliente o no tiene curiosidad sobre el problema del cliente, puede que no sea una buena opción y es posible que deba contratar a un gerente de producto o contratar diferentes tipos de ingenieros.

En un equipo de producto saludable, la naturaleza del problema del cliente y varias estrategias para resolverlo se debaten regularmente. Esas conversaciones forman la base de una intuición de equipo sobre qué compilación y por qué. Si el problema del cliente es vago o no está claro cómo lo soluciona la aplicación (aparte de ser un conjunto de características); de si los miembros del equipo son pensadores literales, entonces el equipo puede estar un poco perdido