Tengo un concepto de aplicación de alto potencial, pero el desarrollador que tengo no es el mejor. Tiene que aprender ciertas características en el camino. A este ritmo, podría tomar 3 meses más para completar el V1 (ya llevamos 2 meses en desarrollo). ¿Qué tengo que hacer?

Puede que sea hora de cambiar los desarrolladores / socios o asignar suficientes recursos para traer a alguien más al equipo que ayudará. Asegúrese de medir los esfuerzos necesarios para hacer esto (tanto monetario como de tiempo, así como equidad) para asegurarse de que tomará una decisión inteligente. Algunas veces, la predicción inicial era la que estaba lejos y una nueva persona también necesitará 2 meses, lo que significa que podría ser más fácil resistirlo.

Otra opción es revisar su MVP. ¿Es realmente un MVP o lo estás llenando con características que no son MVP y, por lo tanto, retrasas el desarrollo unas semanas? Además, estructure el back-end para que sea lo más simple y MVP posible (aquí es donde la gente intenta disparar a la luna y piensa “oh, tenemos que pensar en el millonésimo usuario y cientos de miles que usan al mismo tiempo”). “… No es cierto. Piensa en enviar tu aplicación y medir las estadísticas. U puede mejorar las cosas más adelante.

Obviamente esto depende de lo que estés construyendo …

Sea feliz. Vista llegó dos años tarde. OS / 360 tenía dos años de retraso. Hurd tiene 20 años de retraso. Duke Nukem Forever tenía 14 años de retraso.

Muchos proyectos que calculé que tomaron dos semanas terminaron tomando meses.

Todos estos proyectos fueron realizados por personas bastante inteligentes.

Moraleja: es imposible estimar cuánto tiempo llevará un proyecto. Los gerentes de proyecto requerirán un número, y los codificadores sacarán un número del aire. Si los codificadores estiman que son demasiado bajos, se les culpa por repasar el horario. Si lo estiman justo o demasiado alto, el gerente del programa dirá que es demasiado largo, córtelo en un tercio o en la mitad. Siempre, siempre, siempre pierde, pierde para los codificadores, sin importar el número que den. El gerente del programa tiene meses para llevar a la alta gerencia a jugar golf y beber con ellos y meses para inventar excusas para una alta gerencia por qué no es culpa de la Autoridad Palestina.

Mientras tanto, los programadores están demasiado ocupados para dedicar tiempo a la política de la oficina o para cubrirse el trasero con excusas.

Un extenso estudio de investigación de personas que se ganan la vida estimando la duración de los proyectos de software determinó que al comienzo de un proyecto, los mejores estimadores solo son buenos dentro de un factor de cuatro de cualquier manera (es decir, el proyecto realmente puede tomar entre un cuarto y cuatro veces más de lo estimado). Ver Estimación de software: Desmitificando el arte negro , por Steve McConnell.

La estimación del desarrollo de software es difícil, y debe esperar que las estimaciones iniciales sean incorrectas, especialmente si la persona que realiza la estimación no tiene experiencia en ello. Sin embargo, lo que también debe hacer es volver a estimar cada cierto tiempo (por ejemplo, cada dos semanas). Eso le dará una mejor idea de cómo está progresando el proyecto. Si la fecha de finalización se mueve cada vez más (y especialmente si el movimiento parece estar acelerándose), entonces sabe que tiene un problema real. Si parece que la fecha de finalización está comenzando a estabilizarse, lo está haciendo tan bien como se puede esperar.

Bienvenido a la realidad del desarrollo de software.

Los proyectos de software son esfuerzos grandes y complejos llenos de sorpresas y detalles diabólicos. Por lo general, es mejor evitar las estimaciones optimistas, ya que provocan expectativas tontas que solo esperan ser engañadas. Se esperan problemas imprevistos y los equipos de desarrollo deben adaptarse a medida que aprenden a resolver nuevos problemas. Algunos incluso pueden argumentar que no tiene sentido hacer un trabajo si no hay nada nuevo que aprender de él.

Podría estar agradecido de haber contratado a un desarrollador que sea capaz de adaptarse, pero su optimismo puede ser un signo de inexperiencia o falta de preocupación con el lado comercial de las cosas. Quizás un desarrollador más experimentado y más completo podría actuar como un guía / socio más confiable para su proyecto, a pesar de que también podría tener que hacer su propia parte del aprendizaje en el sitio.

Recuerda, estás creando algo nuevo; No armar una estantería Ikea. Los proyectos de software son bestias orgánicas, que evolucionan para siempre a medida que gradualmente descubrimos más sobre ellos. No estaría tan preocupado por su tasa de progreso como lo estaría de su confianza en este desarrollador. Tal vez no necesites tanto para subcontratar las cosas tecnológicas tanto como para hacer socios con un colaborador tecnológico …

¡Quedarse con eso! Su desarrollador está dispuesto a aprender por usted y ya ha comenzado el proyecto, incorporar a alguien nuevo solo aumentará su estrés y lo retrasará. Si su desarrollador aumenta constantemente su conocimiento de programación, imagine dónde estará en el futuro, tendrá un programador sólido y alguien en quien pueda confiar, un verdadero compañero de equipo. Es hora de que seas el líder y confíes en el niño.

Si decides cortarlo, mándamelo. 😉

¿Cómo es la calidad del código? ¿Está bien estructurado, bien pensado? ¿Mucha codificación o falta de flexibilidad?

¿El desarrollador está reinventando funciones que ya existen o está manipulando cadenas para resolver problemas matemáticos? ¿No aprovecha el potencial de SQL y, en cambio, recorre los conjuntos de registros para obtener el registro que realmente deseaban?

Vale la pena echarle un buen vistazo a la calidad del código: si es sólido, entonces podría seguirlo y revisar el alcance (cortarlo solo a lo esencial y construir a partir de ahí), pero si es una mezcolanza de cosas cribadas del Internet con poca comprensión de cómo encadenar todo, entonces podría ser el momento de encontrar otro desarrollador.

Por lo general, duplicar el poder humano no reduce automáticamente el tiempo de desarrollo a la mitad y poner a más personas en un proyecto retrasado no hará que se ponga al día con la línea de tiempo deseada. Lo que debe hacer es la ingeniería de proyectos. Primero, decida exactamente los requisitos que tiene el software. Luego, debe dividir el proyecto en subproyectos medibles. Divide esos subproyectos en tareas. Determine el tiempo requerido para completar esa tarea, asigne algo de tiempo libre entre tareas (no demasiado), asigne prioridades y orden de desarrollo, sume todos esos tiempos y tendrá el tiempo real que necesitará para desarrollar su proyecto. Sabrá cuántas personas necesitará para desarrollar su software a tiempo.

Exigir que las tareas se terminen en el tiempo requerido con la calidad requerida. Haz pruebas de unidad, muchas de ellas. Utilice sistemas de versiones. Esté cerca del desarrollo, incluso si no es desarrollador. Si no está en un equipo técnico, no necesita saber exactamente cómo está escrito el código, pero necesita saber qué hace cada módulo y cómo lo hace. O, en lugar de todo esto, contrate a un ingeniero de software capacitado formalmente que haga todo este PM por usted.

Un buen desarrollador no es necesariamente un buen administrador de proyectos de software.

Parece ser más complejo de lo que uno supondría después de leer la q.
Entonces, tiene un desarrollador que está dispuesto a hacerlo, pero tuvo que estimar cuánto tiempo lleva sin haber programado antes cosas similares, lo que significa un área desconocida de codificación.

Por lo general, las estimaciones en esa área se vuelven fácilmente muy vagas de esa manera. Experimenté que en mi pasado, por lo general, estaba equivocado por el factor 2 que suponía hacer cosas que nunca había hecho antes.

Si desea obtener mejores estimaciones, y a su desarrollador también le gusta la idea, tal vez intente recordar la estimación desde el punto en que se encuentra ahora y pruebe una de las formas simples de desarrollo ágil para tener una mejor idea de cómo podría ser en.

Intente desglosar la selección de características en otras más simples y definirlas describiéndolas y su uso para los usuarios finales. Estime las piezas más pequeñas, tal vez haciendo estimaciones como scrum (lo que da como resultado que cada entidad obtenga una cantidad de puntos que representan la complejidad de la entidad).
Deje que haga las cosas más importantes primero y haga prototipos, lo que creo que usted hace de todos modos. Dé retroalimentación (constructiva) para que trabajen juntos, no uno contra el otro como “Terminado, ¿Finalmente?” “Nah … lo siento” “¡Oh, eso es malo!”.
Mi idea es crear un ambiente motivador para los dos. Un desarrollador altamente motivado es mucho más eficiente que uno bajo presión negativa. Excepto que le gusta la presión, por supuesto …

Parece ser alguien que realmente quiere terminar el trabajo. Al menos de eso lo que leí en sus respuestas a las respuestas existentes. Entonces, desde mi punto de vista, hay un buen punto de seguir con él e intentar hacer el trabajo.

Es posible que desee agregar un desarrollador experimentado para cosas complejas que quizás necesite aprender primero para acelerar las cosas. Esto solo por un corto período de tiempo y solo si realmente es necesario y él está de acuerdo. Siento que si se hace ese desglose inicial de algo difícil, él podría hacer el resto …

Espero que ayude.

Pase 2 semanas para encontrar un mejor desarrollador.

Una pregunta, ¿cambió la característica durante el desarrollo, o el desarrollador simplemente no tuvo en cuenta la complejidad de la característica? Si es tan malo, tendrás más problemas cuando se lance el producto, entonces te enojará que la gente llame tu aplicación. Una cosa es tener éxito por iteración, otra es tener una base poco sólida.

Si sugirió 1 mes antes y según la nueva estimación, serían 5 meses en total. Eso no es aceptable en absoluto para mí. Algo está mal seguro. Falla rápidamente y recurre a un nuevo desarrollador lo antes posible. Otra cosa es no confiar en sus estimaciones y hacer una revisión adecuada del código y la arquitectura usted mismo o con alguien capaz.

El usuario de Quora lo dice mejor. Es imposible estimar cuánto tiempo lleva un proyecto.

Su “concepto de aplicación de alto potencial” es vaporware. Vaporware no requiere más energía que un pedo para generar. ¡Convertir ese pedo en un software real es difícil!

Si no está satisfecho con su desarrollador, busque uno diferente. Por supuesto, hay costos hundidos (el tiempo que ha pasado con este desarrollador y el dinero que le ha pagado) que no se pueden recuperar.

Obtenga clientes mientras se desarrolla.

Si cree en esta aplicación y se compromete a hacer que funcione, obtenga los mejores desarrolladores que su dinero puede comprar y pronto.