El viejo programador desapareció. A punto de contratar a otro programador. ¿Cómo me acerco a esto? [cerrado]

Después de pasar más de un año trabajando en un proyecto de red social para mí usando WordPress y BuddyPress , mi programador ha desaparecido, a pesar de que le pagaron todas las semanas, durante todo el período. Sí, no está muerto, ya que usé un rastreador de correo electrónico para confirmar y ver que abre mis correos electrónicos, pero no responde. Parece que consiguió otro trabajo. Me pregunto por qué simplemente no podía decirlo. E incluso le pagué un salario anticipado por el trabajo que no ha realizado.

El problema es que nunca solicité documentación completa para la mayoría de las funciones que codificó. Y hubo MUCHAS funciones para este período de un año, y algunas de ellas tienen errores que aún no solucionó. Ahora parece todo confuso.

¿Qué es lo primero que debo hacer ahora? ¿Cómo procedo?

Supongo que lo primero que debe hacer es conseguir otro programador, pero quiero comenzar con el pie derecho documentando todo el código actual para que cualquier programador pueda trabajar en todas las funciones sin problemas.

¿Es eso lo primero que debo hacer? En caso afirmativo, ¿cómo lo hago?

¿Cuál es el tipo estándar de documentación requerida para algo como esto? ¿Puedo obtener un programador que solo haga la documentación de todos los códigos y repare los errores o la documentación no es realmente importante?

Además, ¿cree que obtener otro programador "individual" es mejor o conseguir una empresa que tenga programadores trabajando para ellos, de modo que si el programador asignado a mi proyecto desaparece, otro puede reemplazarlo, sin mi participación? Siento que este es el enfoque que debería haber tomado al principio.

Según esa interacción que tuvimos en los comentarios, asumiré que no expulsó a su único desarrollador por cuestiones personales. Sin embargo, basándome en esa conversación, haré otra suposición de que este revés sigue siendo principalmente su responsabilidad como gerente de contratación. Como mencionaste, no tienes NINGUNA experiencia con los desarrolladores, pero ¿cómo tomas una decisión sobre cómo contratar uno?

Parece que hiciste lo mejor que pudiste, pero contrataste a alguien que simplemente no podía manejar la escala de este proyecto, construyó una base inestable que se derrumbó debajo de él y luego simplemente se fue. Desafortunadamente, la diferencia entre los desarrolladores y los empresarios es que a los primeros se les paga por hora / salario, pero pueden elegir ir y venir cuando quieran. Le pagaron por las horas que trabajó y se fue cuando decidió no volver a pagar. Nada puedes hacer sobre eso.

¿Y ahora qué? Parece que comenzaste a seguir el camino de reemplazar a las personas con el proceso. Si solo tuvieras suficiente documentación, las personas podrían irse y otros podrían retomar donde lo dejaron. OMI que no funciona y si funciona, aún será mucho más costoso que tener un equipo confiable de empleados permanentes. La gerencia de varias compañías en los últimos 30 años ha tratado de reemplazar a las personas con suficiente documentación (incluido mi último trabajo) y fallaron cada vez. Es por eso que decidí cambiar de trabajo y ahora están atrapados con sus documentos obsoletos y nunca precisos, mientras estoy teniendo el mejor momento de mi vida en una nueva startup.

Lo que haría si fuera usted sería tratar de encontrar a la persona adecuada con suficientes habilidades y experiencia para retomar este proyecto y llevarlo a término. Esto no solo incluye habilidades de codificación, sino también diseño, arquitectura y gestión básica de proyectos. No intente definir cómo hace su trabajo o cuántos documentos necesita producir. Solo concéntrese en encontrar a la persona adecuada y esté preparado para pagar en consecuencia. Cuando lo encuentres, asegúrate de que tu rol sea apoyarlo y eliminar los obstáculos de su camino, no monitorearlo / microgestión. No estoy insinuando que hiciste eso antes, pero sé que muchos gerentes tienden a hacerlo y eso es contraproducente.

Hable con otros empresarios, posiblemente aquellos con más experiencia en ingeniería de software. Lea estos foros y formule una serie de preguntas para hacer su posible contratación. Presente el problema y pregunte cuál sería el enfoque. Si él es el tipo correcto (y suponiendo que no haya visto esta página), debería poder sugerir muchas de las cosas que otras personas ya sugirieron en términos de lo que se debe hacer en su empresa a medida que comienza a recuperarse. Pídale que defina un plan desde el momento en que lo contratan hasta que se envíe su v1.0. ¿Cómo te llevará allí? Pida ayuda para entrevistar a esa persona.

Solo algunos de mis propios pensamientos: el seguimiento de errores es imprescindible (Jira cuesta $ 10 para un equipo de hasta 10 personas). El control de la fuente es imprescindible (git es gratis. Por fuerza cuesta cacahuetes para un equipo de hasta 5 personas). Tu código es tu documentación. No son tus documentos escritos. Debería revisar el código y guardar lo que sea recuperable; deseche el resto y concéntrese en escribir código fácil de leer y mantener. Guarde la documentación para algunos documentos de diseño de alto nivel y pocas páginas. Debe conocer la tecnología en la que está trabajando. No contrates a alguien con buenas intenciones; no puede permitirse que aprendan en su tiempo. Pregúnteles qué otros proyectos han realizado (desafortunadamente, usted o alguien que encuentre podría tener que mantenerse al día con el aspecto técnico de las cosas). Estás buscando a alguien con suficiente experiencia pero al mismo tiempo no demasiado como para que esa chispa de emoción ya se haya apagado. Encuentre a alguien que tenga hambre para causar un impacto. La metodología que propone o sigue debería permitirle ver el trabajo de forma regular (períodos de una o dos semanas) y proporcionar comentarios instantáneos. No contrates a NADIE que diga, estará listo en exactamente 7,4 meses, te avisaré cuando termine.

Buena suerte

Esta es una situación extraña, y estoy bastante seguro de que no estás contando toda la historia. Trabajé con muchas personas, algunas de las cuales se fueron por varias razones (yo soy su colega), pero no traten de decirnos que todo fue súper bueno y que un día simplemente no hubo contacto.

Pero eso no es problema. Al menos ya no; debe aprender de su error e intentar no repetirlo en el futuro. Y sí, estoy sugiriendo fuertemente que el 50% es tu culpa de que él / ella se vaya.

Ahora sobre resolver el problema actual:

1. Intenta contactar a tu programador. Él lee su correo electrónico: ofrézcale dinero para la documentación / corrija los errores más importantes. Nadie más podrá arreglarlos más rápido que él. No funciona? Intenta encontrar dónde trabaja, contacta a esa compañía y cuenta tu historia. Una buena compañía no contratará a una persona que pueda hacer lo mismo por ellos. Al menos le dirán que termine la documentación por usted.

   NOTA: no desea recuperar a esa persona, solo necesita documentación terminada

2. Esté preparado para que su trabajo de un año sea nulo. Podría haber huido cuando le pediste resultados y sabía que no podía cumplir. Es posible que el código esté lleno de hacks, implementación sucia y mala calidad general. Incluso si regresa, probablemente no tendrá las habilidades ni el tiempo para hacerlo bien.

3. Busca a otra persona. Necesita conocer las mismas tecnologías (lenguaje de programación, marcos, etc.). Si la calidad del código es buena, podría continuar, de lo contrario, podrá refactorizarla. Sí, la refactorización lleva tiempo sin la implementación de nuevas funciones, pero hace que el código se pueda mantener y eso es lo que necesita. Además, una persona que puede refactorizar un código incorrecto es un programador realmente bueno, consérvelo.

   NOTA: es una tontería pagar por adelantado. La idea general del salario es pagar por el trabajo realizado. No por una promesa hecha :)

4. Hacer listas. Le conviene tener un plan. Una especificación técnica que una vez leída permitirá al nuevo programador comprender el trabajo y los hitos. Tener al menos tres documentos importantes:

   • Descripción general del proyecto: un documento que permitirá que incluso un no programador sepa de qué se trata el proyecto.

   • Cronología: ¿qué parte y cuándo espera estar listo? ¿Qué ya está hecho?

   • Especificaciones técnicas: esta es larga. Es EL documento que un programador quiere leer. Sepárelo en partes lógicas y describa con el mayor detalle posible las características y el flujo de trabajo de esa parte específica.

Trabajar con empresas no es realmente tan bueno; Sus posibilidades no mejorarán. Y pagará en exceso 10 veces si contrata a un solo programador. Si tiene un equipo pequeño, digamos 3-5 personas, simplemente contrate a un programador dispuesto a ser el líder del equipo. Hará un trabajo mucho mejor administrando el equipo.

¿Documentar el código luego por otro programador? Es simplemente mi propia experiencia y opinión decirle que no debe tomar ese camino.

Sin un conocimiento más detallado de la calidad de esa base de código, mi opinión es que su mejor enfoque es contratar un nuevo programador para corregir los errores, mantener y posiblemente realizar las modificaciones que necesite.

Esa opinión tiene el punto clave de posibles modificaciones (cambiar o agregar), ya que necesitan cumplir un requisito. Esto significa que se debe escribir algún tipo de especificación de requisitos. Este es un documento.

Lo que lleva a un punto de mantener todo el proyecto. No dijo en su pregunta si existen requisitos de programas actuales o incluso documentación funcional aproximada, pero ahí es donde debe centrarse ahora.

En caso de que no tenga ninguna documentación, en este momento, le corresponde a usted llenar ese vacío. No puede contratar a un programador para realizar ingeniería inversa en su aplicación y milagrosamente moldear la documentación de eso . Debe "explicar" lo que quiere que haga el programa (incluso si significa volver a explicar lo que ya ha sido programado).

Cuando tenga ese documento escrito (ya sea en forma de requisito o especificación funcional), obtendrá mejores resultados al contratar a un nuevo programador, ya que puede entregar la documentación y comenzar a trabajar desde allí.

También hay muchos programas que producen documentos a partir del código fuente, que es una buena manera de generar un esqueleto de explicación del código fuente real (esto está en el área de la especificación técnica) que solo puede trabajar en el contexto de explicar los aspectos técnicos de la funcionalidad especificada en la especificación funcional, que especifica la funcionalidad de los requisitos especificados en la especificación de requisitos.

Entonces, sí, mi opinión es contratar a un programador para corregir los errores. Después de que él haya solucionado los errores que usted acordó que deberían arreglarse, podría discutir el aspecto de la documentación como otro contrato. Con suerte, contrató a un programador que tiene algo de experiencia y puede contribuir a los pasos que debe seguir a partir de ahí.

Así es como abordaría el problema:

• Tienes el conocimiento del dominio. Ahora sabe qué funciones están disponibles en el sitio web, cuáles le gustaría agregar en el futuro, y probablemente pueda enumerar algunos errores que también informaron los usuarios.

• Ahí está este montón de código, dejado solo en una esquina. Puede tener errores, pero aún ofrece valor ya que el sitio tiene usuarios activos. Por lo tanto, una reescritura completa sería un error de la OMI.

El puente entre su experiencia de dominio y el código se rompió cuando el programador se fue. Debe reconstruirlo para que la base del código pueda sincronizarse nuevamente con sus requisitos y para que puedan desarrollarse futuras actualizaciones.

La cuestión es que ese puente no puede estar completamente hecho de documentación. El software es un asunto humano tanto como técnico. Si no le explica al nuevo programador lo que espera con gran detalle, tendrá dificultades para deducirlo solo del código, más aún si el programador anterior escribió un código críptico, mal documentado y mal probado. Y si no trabaja en estrecha colaboración con el nuevo programador para encontrar una forma automática y continua de verificar que el código coincida con sus requisitos, en otras palabras, para hacer que el puente sea más robusto, el problema está condenado a repetirse.

• Siéntese regularmente (incluso virtualmente) con el nuevo programador para sesiones de procesamiento de conocimiento de dominio. Durante cada una de estas sesiones, escriba juntas las especificaciones de una pequeña parte de su producto. Puede ser una sola página web, puede ser una característica. Hacerlos especificaciones ejecutables (a la Behavior-Driven Development ) aumentará su nivel de confianza de que el puente funciona, porque puede ejecutarlos continuamente y recibir una advertencia cuando hay algo mal. También facilitará la vida del desarrollador.

  Después de una sesión, el desarrollador puede volver a su trabajo y escribir pruebas de nivel inferior que validan que el código actual cumple con la especificación. Si no cumple, entonces el programador tiene todo lo que necesita para solucionarlo. También es importante permanecer disponible para cualquier pregunta que pueda tener.

• Intente mantener una estrecha y continua colaboración entre usted y los programadores en su proyecto, y asegúrese de que esto también sea cierto entre ellos. Esto es necesario si desea que viva la cultura funcional y técnica en torno a su proyecto, evitando problemas como el que está teniendo ahora. Por supuesto, esto requiere no solo 2+ desarrolladores trabajando en su proyecto, sino también que compartan entre ellos el conocimiento sobre todo lo que escriben. Por lo tanto, uno puede actuar como una conmutación por error cuando otro se pierde. Técnicas como la programación de pares y las revisiones de código son buenas maneras de lograrlo.

Solo agregando a lo que todos han dicho,

Si no puede hacer que el antiguo programador documente su código incluso a un precio, no espere que otra persona pueda documentarlo mejor. Aquí hay algunas opciones sobre lo que puede hacer por ahora para que el nuevo programador sea productivo desde el primer día.

1. Obtenga una base de datos de errores y comience a ingresar todos los errores que encontró en ella. Esta es la lista de tareas pendientes prioritarias del programador. Documente bien y ponga tantos detalles como sea posible (archivo fuente / causa raíz, qué hace y qué debería hacer). Hay muchos programas gratuitos de seguimiento de errores, como Bugzilla , Redmine y JIRA . Siéntase libre de usar lo que quiera.
2. Cree una hoja de especificaciones para su proyecto. Esto le dará al nuevo programador alguna dirección después de que se hayan borrado los errores. Puedes consultar la guía de Joel sobre especificaciones de escritura .
3. Cree un cronograma o una línea de tiempo para su proyecto. Deben tener plazos e hitos en los que se les pague por el trabajo que prestaron en lugar de pagarlos por adelantado.

Ahora que está fuera del camino, puede comenzar a buscar un programador. Y como dijo Creative Magic, externalizar el trabajo a las empresas puede llevar al desastre o elevar el precio al infinito y más allá.

Esta vez, comience a planificar adecuadamente el factor del bus al contratar programadores. La gente va y viene y no hay nada que puedas hacer al respecto, así que prepárate para lo peor esta vez consiguiendo dos programadores, o como dijo Uooo, obtén un programador y un probador.

Ahora, una vez que los programadores estén en la tienda con usted, puede comenzar a pedirles que documenten su código en el futuro en lugar de pedirles que documenten el código antiguo, realmente, olvídalo.

Otras cosas a tener en cuenta al obtener un nuevo programador, asegúrese de que conozcan el control de origen y las pruebas automatizadas. Además, intente obtener la mayor cantidad de controles posibles en la prueba de Joel con su ayuda, solo puede hacer mucho de esto por su cuenta.

Entonces, su único programador fue golpeado por un autobús , y necesita reemplazo ahora.

Puede intentar demandar a su antiguo programador, en función de su contrato, o averiguar qué le pasa. Suponiendo que no volverá, esto no te ayudará.

• Desea terminar su producto, así que busque un programador que tenga experiencia en el mantenimiento y desarrollo de sistemas existentes. No me enfocaría en decirle a su programador qué hacer en qué orden. Asegúrese de contratar a un profesional que escriba documentación y pruebas unitarias cuando sea necesario.
• Por su parte, puede asegurarse de que el nuevo programador tenga todo lo necesario para su trabajo : especificaciones de requisitos, una potente máquina de trabajo, etc. Desea un programador profesional, así que bríndele un ambiente de trabajo profesional.

Además, piense en contratar un segundo desarrollador para facilitar este tipo de situaciones difíciles en el futuro. Un probador también sería útil para garantizar la calidad.