¿Cómo mejoro el proceso de desarrollo en nuestra pequeña startup?

Trabajo para una pequeña empresa de desarrollo de software independiente. Hemos estado en el negocio durante casi tres años y las cosas van bastante bien. Tenemos un flujo bastante constante de proyectos para una base de clientes en constante expansión y, como resultado, hemos comenzado cuidadosamente a contratar personal nuevo y ayuda temporal. Ahora contamos con cinco miembros permanentes del personal, de los cuales dos son desarrolladores de tiempo completo y uno divide su tiempo entre el desarrollo, el diseño y la administración del negocio.

Debido a que la carga de trabajo ha aumentado, nos hemos encontrado con algunos problemas: trabajamos muchas horas, no cumplimos con los plazos, no podemos dar estimaciones precisas sobre cuándo se completará un proyecto y la calidad de nuestro código está disminuyendo. Me han pedido que presente un proceso de desarrollo que se adapte mejor a nuestra empresa y proyectos.

Por lo general, trabajamos en varios proyectos a la vez; esto es inevitable debido a la cantidad de proyectos que hemos asumido y la pequeña cantidad de desarrolladores que tenemos. Actualmente, más o menos dividimos esto en intervalos de dos semanas: trabajo en el proyecto A durante dos semanas, trabajo en el proyecto B durante dos semanas y luego, inevitablemente, aparecerá algún problema con el proyecto A o C y pasaremos el día previsto. para el proyecto B en el proyecto A y C.

Nuestros clientes son de todo el país y de diversos orígenes. Algunos son habladores, otros no. Algunos esperan actualizaciones semanales, otros no tienen problemas con no tener noticias nuestras durante dos meses. Preferimos trabajar en iteraciones pequeñas: sacar un prototipo y ponerlo en manos del cliente lo más rápido posible (generalmente alrededor de un mes después de que comenzó el desarrollo) y luego repetirlo cada dos o cuatro semanas. Descubrimos que esto es esencial para el tipo de proyectos que hacemos y el hecho de que nuestros clientes a menudo no tienen una idea real de lo que quieren hasta que tienen algo parecido a lo que quieren en sus manos por un tiempo.

En este momento, nuestro proceso de desarrollo es bastante sencillo, pero obviamente deficiente. A nuestro diseñador se le ocurre una idea para una aplicación y un diseño gráfico rudimentario, y nuestros desarrolladores (uno, dos o los tres) dividen el trabajo ad hoc y comienzan a construir. De vez en cuando, comprobamos dónde estamos y ajustamos si es necesario. No hay mucho más que eso.

He estado pensando en hacer revisiones de código: cada pieza de código es revisada por al menos un desarrollador que no lo escribió. Esta parece una buena manera de comenzar a mejorar la calidad de nuestro código, pero lleva mucho tiempo que simplemente no tenemos. Lo mismo ocurre con las pruebas unitarias: pasamos semanas escribiendo pruebas y, a menudo, nos encontramos constantemente teniendo que modificar las pruebas porque descubrimos que no estaban probando las cosas correctas o que no estaban probando lo suficiente. Ese proyecto tomó mucho más tiempo que los proyectos en los que no hicimos pruebas unitarias y simplemente eliminamos los errores cuando los encontramos. Además, no tuvimos nada que mostrar al cliente durante semanas. Posiblemente lo estábamos haciendo mal, por supuesto.

También he estado pensando en agregar un probador dedicado a nuestro equipo: alguien que encuentre, categorice e informe de errores, para que los desarrolladores tengan que dedicar menos tiempo a encontrar errores y brindar soporte a nuestros clientes, y tengan más tiempo para dedicarlo a en realidad corrigiendo errores y desarrollando la aplicación. Obviamente, esta es una inversión significativa para un equipo pequeño como el nuestro, pero tengo la sospecha de que es una forma más efectiva de gastar dinero que simplemente enviar más desarrolladores a un proyecto.

En cuanto a proporcionar mejores estimaciones, no tengo una idea real. Hemos incursionado en la planificación del póquer, pero en mi experiencia eso equivalía a poco más que las conjeturas tremendamente inexactas que ya estábamos haciendo. Finalmente, quiero formalizar más el proceso de diseño, hasta cierto punto. Obviamente, debido al desarrollo iterativo, realmente no podemos establecer ningún diseño en piedra, pero probablemente no estaría de más si dedicáramos más tiempo al principio a formalizar tanto la arquitectura de la aplicación como el diseño gráfico.

Básicamente, tengo una idea razonable de lo que podemos mejorar y lo que nos falta actualmente, pero no tengo ideas concretas sobre cómo podemos lograr este objetivo. Por lo tanto, recurro a Stack Exchange. Probablemente hay muchos de ustedes en empresas similares a la nuestra que lucharon con los mismos problemas. ¿Cómo los superaste o en qué trampas caíste que sugieres que evitemos?

¿Cuál es la duración promedio de su proyecto en términos de tiempo calendario y tiempo de horas-hombre?
Algunas reflexiones sobre las pruebas unitarias: lo ideal es que las pruebas unitarias se escriban antes que el código de producción. Escribir pruebas unitarias como una ocurrencia tardía, como parece que ha estado haciendo, lleva mucho tiempo sin ningún beneficio obvio a corto plazo. Las pruebas unitarias se pagan solo a largo plazo. Entonces, si valen la pena depende del tipo de proyectos que estés haciendo. Cuanto más larga sea la vida útil de sus productos, más vale la pena invertir en pruebas unitarias. En cualquier caso, intente hacerlo de la manera TDD adecuada al menos una vez antes de dar un veredicto.
Tiempo medio del proyecto: entre seis y 12 meses. Horas hombre, diría aproximadamente entre dos o tres veces eso.
No escribimos las pruebas unitarias después de escribir el código de producción. Escribimos las pruebas y luego implementamos el código de producción necesario para que cada prueba pase. El problema era que, a medida que avanzábamos, nos encontrábamos con que las pruebas no probaban las cosas correctas, que las reescribíamos constantemente debido a cambios en los requisitos, etc.

Respuestas (5)

Centrarse en la calidad y las estimaciones

Usted identificó cuatro problemas. De esos, vería los siguientes dos como sus principales problemas (es probable que estos sean el resultado de largas horas y plazos incumplidos):

  1. La calidad de su código está cayendo : cuando la calidad es mala, termina haciendo mucho trabajo no planificado. Esto da como resultado largas horas y plazos incumplidos sin olvidar el impacto en la moral del equipo.

  2. No se pueden dar estimaciones precisas sobre cuándo se completará un proyecto : esto también daría como resultado muchas horas y una mala calidad del código o plazos incumplidos o ambos.

Parece que ha probado o considerado varias opciones para mejorar la calidad de su código:

  1. Revisiones de código : en mi asignación anterior, tuvimos problemas con la calidad del código. Al introducir la revisión del código, pudimos detectar errores antes del lanzamiento y mejorar sustancialmente la calidad del lanzamiento. Como mínimo, revise el código de alto riesgo.

  2. Pruebas unitarias : Nos costó mucho intentar introducir las pruebas unitarias. Si ya lo ha introducido, mi sugerencia es continuarlo al menos en algunos proyectos. Algunos usuarios han reportado grandes beneficios de las pruebas unitarias. Determina por ti mismo que no está dando los beneficios antes de abandonarlo.

  3. Probador dedicado : Sugiero encarecidamente un probador dedicado. Los desarrolladores tienen puntos ciegos. Además, los desarrolladores no tienen la paciencia para realizar tareas repetitivas, que a menudo son necesarias para realizar pruebas meticulosas.

Para mejores estimaciones, tengo tres sugerencias:

  1. Continúe planificando el póquer : como mínimo, divide el proyecto monolítico en partes más pequeñas (epopeyas/historias). Al revisar las estimaciones con los datos reales, puede ver cuáles son las áreas en las que su equipo tiende a equivocarse. Además, hace que los miembros del equipo hablen sobre el alcance del trabajo, el enfoque de desarrollo y cualquier riesgo/suposición en una etapa temprana. Capture estos en la historia/epopeya.

  2. Disposiciones de cronograma : haga las siguientes disposiciones al elaborar cronogramas para nuevos proyectos:

    • 10% (un día de cada sprint de dos semanas) para trabajos de mantenimiento en proyectos existentes.

    • 10% para vacaciones, capacitación y ayuda con la licitación de proyectos futuros.

  3. Refine sus estimaciones y cronograma después de la retroalimentación del prototipo : cuando recibe la retroalimentación de su cliente, es cuando el alcance es más claro (para su cliente y para usted). Es hora de afinar tu estimación e indicar cualquier cambio de horario a tu cliente.

Desde entonces, llegué a la misma conclusión de que una mejor garantía de calidad puede ser la forma más efectiva de solucionar estos problemas (o al menos contribuir de manera sustancial a remediarlos). Desde entonces, he recibido la sugerencia de otros de que las revisiones de código no servirán de mucho para un equipo tan pequeño, a menos que haya problemas de comunicación graves. Ese no es el caso, pero realmente no vemos el código de los demás porque todos estamos escribiendo cosas para nuestras propias especializaciones y constantemente parecemos estar en modo "cállate y envía".
Me gusta la idea de revisar el código de alto riesgo, aunque creo que tendremos que determinar de alguna manera qué es de alto riesgo y qué no. Las pruebas unitarias es algo que personalmente quiero que funcione, pero hasta ahora ha absorbido mucho tiempo. Obviamente, no tengo forma de medir si eso compensa el tiempo dedicado a corregir errores que puede haber detectado, pero aún así es frustrante. Estoy pensando en presentarlo para partes de proyectos (código central, etc.) y probar más cosas para proyectos a más largo plazo. El probador dedicado es algo que todo el mundo parece recomendar. Espero poder conseguir que esto suceda.
Planificación del póquer: le daré otra oportunidad, pero aún no estoy muy convencido de que proporcione algo de valor. Refinar las estimaciones y los cronogramas después de los comentarios parece una obviedad. No estoy seguro de por qué no parecemos poder hacer eso ahora mismo.
Edité mi respuesta y agregué un elemento más en las estimaciones.
  • No asuma más trabajo adicional, existe la tentación, pero si su organización se adapta, el dinero llegará. Solo mantén lo suficiente para mantener tu flujo de efectivo. La codicia es una fuerza muy destructiva en los negocios.
  • Use algo como un análisis FODA para determinar su posición actual.
  • Produzca una matriz de riesgos para encontrar dónde están las emergencias para que pueda producir un plan de acción.
  • Use los principios SMARTER para ayudar a producir metas o hitos.
  • Obtener algunos buenos controles en su lugar. Encuentre en su análisis de riesgo algunos indicadores que mostrarán un deterioro en su programa de cambio. Primero estabilícese, luego busque mejorar, gradualmente.
  • Quitar la iniciación de proyectos de trabajo a los diseñadores. Su trabajo consiste en diseñar lo que el cliente necesita... sus clientes deberían ser los que lo impulsen. Si está produciendo productos, tener que encontrar compradores para usted es desperdiciar recursos de la peor manera. Economía simple: oferta y demanda.
  • Reúna a todo el equipo, incluya a todas las partes interesadas (cualquiera que interactúe con su empresa de alguna manera) y comience a encontrar dónde puede estandarizar sus procedimientos. ¿Hay alguna manera de estandarizar sus métodos de informes? Cuanto más pueda juntar elementos comunes, más tiempo ahorrará.
  • Comience a buscar áreas de restricción o "cuellos de botella" en su proceso de producción. Esto ayudará a encontrar dónde se pueden obtener ganancias rápidas.
  • No busque actualizar sus prácticas de una sola vez, esto puede generar mucha inestabilidad. Debe crear un plan con aportes de todos en su organización.
  • Mire las habilidades del personal: ¿hay algún cruce? ¿Hay alguno que sea polivalente? Su personal es su mayor recurso, intente encontrar la manera de utilizar mejor todas sus habilidades, se sentirán más apreciados y su productividad aumentará.
  • Fíjese en el estado de ánimo del personal; las largas horas y los plazos incumplidos pueden provocar una disminución de la motivación con un efecto en cadena en la producción. Mantenga un ojo en la gestión; su trabajo es administrar, puede sonar condescendiente, pero con demasiada frecuencia pueden olvidar sus roles; Arremangarse para ayudar a los trabajadores a veces no es la mejor manera de ayudar.
  • Para la gestión del tiempo, encuentre un par de buenas herramientas e indicadores y apéguese a ellos. Demasiadas veces las personas buscan la próxima gran cosa, se quedan con ella durante cinco minutos y luego buscan la siguiente herramienta. Asegúrese de entender cómo funcionan y si son lo que necesita. Humildemente, siempre sugeriría las cosas más simples: diagramas de Gantt, diagramas de flujo de productos, Takt time, por nombrar algunos. Mantenlo simple ; todos en su organización deben poder entenderlos para que todos puedan trabajar al mismo ritmo hacia las mismas metas.
  • Consigue un consultor. Debe equilibrar la pérdida de ingresos con el costo de contratar a un profesional que lo ayude a resolver estos problemas. La gestión del cambio debe estar a cargo de alguien que no se deje atrapar por los asuntos habituales de la empresa.

Hay muchos libros sobre su situación y libros sobre cada punto que he mencionado aquí. Sin embargo, el punto más importante que repetiré es lidiar con su situación actual. Debes estabilizar y crear una base firme antes que nada. He visto demasiadas empresas en la situación de que han "construido casas sobre arena".

Creo que puede estar haciendo la pregunta equivocada aquí. Mencionó que el problema es que no cumple con los plazos y no puede dar estimaciones precisas de cuándo se completará el trabajo. El instinto natural de la mayoría de los técnicos es buscar una solución de gestión de entregas, que es lo que ha hecho.

Sin embargo, sugeriría que lo que está experimentando es un problema de relación con el cliente. Si los clientes se quejan de plazos incumplidos y estimaciones de entrega inexactas, puede abordar esos problemas administrando mejor la relación con sus clientes.

Recomendaría que asigne a alguien, tal vez una persona diferente por cliente, como punto de contacto para cada cliente. Deben establecer una relación con ese cliente que les permita negociar los plazos y las expectativas de entrega. Esto liberará la presión que siente actualmente de trabajar muchas horas y cumplir con plazos ajustados.

También puede encontrar algunas mejoras en los procesos que lo ayuden, pero la realidad es que la mayoría de las investigaciones en esta área se relacionan con equipos más grandes y mejor estructurados. Como ha descubierto, tratar de aplicar las "mejores prácticas" para la industria tiende a ser muy problemático para los pequeños grupos de empresas emergentes.

No podría estar más en desacuerdo con la respuesta que sugería "no aceptes más trabajo". El trabajo ganador es el elemento vital de las organizaciones pequeñas y absolutamente debe inscribir a todos los clientes que pueda. Pero no caiga en la trampa del ingeniero de pensar que la única solución a un problema de percepción del cliente es mejorar la calidad de la entrega. Los clientes pueden estar más satisfechos con un mejor servicio al cliente y alguna atención personalizada.

Sin embargo, no son los clientes los que se quejan de los plazos incumplidos y las estimaciones inexactas: somos nosotros. No estamos contentos con el incumplimiento de los plazos porque significa que se acumula más trabajo por delante. De hecho, diría que nuestros clientes no se quejan de los plazos incumplidos porque nuestras relaciones con los clientes ya son bastante buenas. Sin embargo, es un punto interesante y definitivamente algo que tendré en cuenta en caso de que surjan tales problemas en el futuro.

Recomiendo encarecidamente el "Arte del desarrollo ágil" de James Shore para impulsar la migración a una cultura ágil.

Dentro de las prácticas sugeridas en el libro se encuentran conceptos como 'menos es más' junto con una buena definición de 'éxito' (intersección del éxito técnico, personal y organizacional) y cómo lograrlo.

Parece que te enfrentas a la clásica situación de "víctima de tu propio éxito". El proceso que te ha hecho exitoso, está obstaculizando tu crecimiento futuro.

Sugeriría que el primer lugar para comenzar es comprender todas las razones por las que no cumple con los plazos. Es poco probable que sea solo uno. Sugeriría usar una herramienta como un diagrama de Ishikawa, http://en.m.wikipedia.org/wiki/Ishikawa_diagram . Asegúrese de que su equipo esté involucrado para ayudar a identificar todas las razones.

En segundo lugar, priorizar los temas, cuyas razones tendrán el mayor impacto, en el menor tiempo. Este es el tema a atacar primero.

Una vez que decidas mejorar un solo problema, sé tenaz. Por ejemplo, si determina que los errores le impiden no cumplir con los plazos, implemente revisiones tempranas del código. Siga así hasta que vea una mejora y el cambio se adopte en su cultura.

Además, intente capturar datos sobre su proceso siempre que sea posible, cuántos retrasos está encontrando, qué los causó. Esto le ayudará a demostrar el valor de sus esfuerzos de mejora.

También le aconsejaría a Ty que no solucione más de un problema a la vez.

¿Cómo mejoro el proceso de desarrollo en nuestra pequeña startup?
RespuestasAquíPolítica de privacidad1y, 0v