Me encargaron gestionar un proyecto que se subcontrató a algunos desarrolladores ucranianos.
La compañía los contrató a través de Elance a un precio fijo . En ese momento, mi jefe me dejó solo para manejarlos y hacer el trabajo. Creé una especificación detallada de todo lo que debía hacerse.
El proyecto implicó lidiar con cosas como XMPP, RabbitMQ y Database. En mi primer encuentro con ellos (siempre MI) les expliqué a fondo lo que tenían que hacer. Parecían entenderlo, y estaban muy seguros de que se haría fácilmente.
Hasta aquí todo bien. Pero después de una semana, cuando nos volvimos a encontrar, estaban llenos de malentendidos sobre lo que había que hacer. Cuando le pregunté a uno de los desarrolladores si conocía XMPP, dijo que estaba trabajando con él por primera vez. En nuestra primera reunión, mencioné muy específicamente la complejidad del proyecto y las tecnologías involucradas. Además, repetidamente les pedí que escribieran una especificación funcional de exactamente CÓMO lo harían. Pero dijeron NO e insistieron en que preferirían escribir el código. Dije ok.
El proyecto se completó después de 3 semanas y entregaron lo que se necesitaba. En ese momento comencé a revisar el código. Estuvo bien en su mayor parte, pero hay algunos problemas importantes:
- codificaron algunas de las cosas que debían separarse en un archivo de configuración
- había múltiples archivos de configuración que necesitaba consolidar en uno
- escribieron absolutamente NINGUNA documentación
- algunos otros cambios menores
Les pedí que hicieran estos cambios (excepto la documentación). Y tuvimos una discusión.
Dijeron que, dado que el precio era fijo, estaba siendo injusto al pedirles que hicieran algún cambio una vez que completaran el código de trabajo. Que habían trabajado durante un tiempo razonable en el proyecto y que ahora era completamente incorrecto pedir algo.
Finalmente, ahora han realizado los cambios y el proyecto ha terminado. Pero deja algunas preguntas en mi mente ...
Hicieron lo que era necesario pero yo lo necesitaba correctamente , y de ahí los cambios. ¿Fui realmente injusto?
¿Por qué acepté dejarles codificar sin tener una especificación funcional?
¿Por qué no me aseguré de que entendieran todo la primera vez?
¿Alguien se encuentra en la misma posición? ¿Crees que hay una mejor manera de gestionar proyectos subcontratados?
- ACTUALIZACIÓN -
Gracias por todas las opiniones: después de reflexionar sobre toda la experiencia, puedo concluir ...
Aunque no era vago en las especificaciones de mi lado, ciertamente no las hice revestidas de hierro como se sugiere. Entonces, la conclusión es: siempre sea lo más específico posible: lea sus especificaciones también desde su perspectiva y vea si se perdió algo. Repítalo al menos tres veces.
Solo especificar lo que el código debería hacer no es suficiente. Debe especificar el aspecto que debe tener el código. Cuál será la estructura del directorio; incluso los nombres de los archivos si es posible. Esto te salvará de muchas molestias más adelante. Especifique estrictamente las pautas de codificación, las convenciones de nomenclatura variable, el formato de documentación interna, etc. Asegúrese de que cumplan con esas pautas, y si no, grite.
Exija una especificación funcional por su parte: insista en que se escriba antes de cualquier código. Esto eliminará muchas confusiones y malentendidos.
Revise el código mientras se está desarrollando para identificar las anomalías antes y corregirlas. Hable con ellos al menos una vez cada dos días.
Por último, trate de hacer una buena relación con ellos. Hazles sentir que aprecias su trabajo. No los presione exageradamente para que se ajusten a sus pautas; en su lugar, solicíteles que lo hagan y dígales que esto le facilitaría mucho más el mantenimiento del código una vez que completen el proyecto.
fuente
Respuestas:
En primer lugar, esto no es un problema de off shoring, es un problema de gestión de proveedores
Sí, cometiste MUCHOS errores ...
Sí, es justo. Si quisiera que se hiciera de cierta manera, debería haberlo dicho antes de que se acordara el precio, para que puedan ofertar en consecuencia.
¿Por qué acepté dejarles codificar sin tener una especificación funcional? ¡Porque no querías PAGAR por la especificación! La documentación lleva mucho tiempo y es costosa, ¿deberían hacerlo de forma gratuita?
Ellos entendieron. ¡Pero en su primera reunión DESPUÉS de que se firmó el contrato (y el precio fijo acordado) es cuando lo EXPLICÓ! Por lo tanto, necesitaban reducir los costos (horas) donde podían. Básicamente, al celebrar solo una reunión por semana, sin ofrecer opciones de confutación.
Aquí está cómo hacer esto la próxima vez ... En dos fases ...
Fase 1: haga que recopilen los requisitos, realicen el análisis de sistemas y escriban el diseño técnico y / o la especificación funcional (o escríbanlo usted mismo). Acuerde un precio para esta fase. Asegúrese de explicar que no hay compromiso de su parte para darles la fase de desarrollo. Asegúrese de incluir el tiempo de reunión en el precio.
Fase 2: haga que oferten por el desarrollado en función de la especificación ahora que ellos (y usted) tienen, y realmente sepan que el esfuerzo está involucrado. Nuevamente, asegúrese de incluir tiempo para las reuniones en el precio. Porque incluir un pequeño presupuesto opcional para cambios.
Editar: Quiero agregar un punto adicional. El proveedor también tiene la culpa aquí, parte del trabajo de allí también es ayudarlo a guiarlo con la gestión del proyecto y hacerle saber dónde faltan en el proceso.
fuente
Luego, no lo subcontrate, o si lo hace, asegúrese de que trabajen en su equipo de proyecto y de que usted participe en las revisiones de código en ese momento.
Nuevamente, debería haber estado revisando el código durante el proyecto, no después.
Les pagaste un precio fijo por el código de trabajo. Ups Eso no es culpa de ellos, es tuyo. Pague por su tiempo para participar en sprints que controle y no se encontrará con este problema. Debe pagarles el tiempo y las historias de usuario aceptadas, no por código.
Cuando se trata de un proyecto completamente subcontratado, debe asegurarse de que sus especificaciones sean férreas. Si tiene que explicar algo que lleva más tiempo que unas pocas oraciones, entonces su especificación no está completa. Por eso se desviaron de la especificación.
Es común cuando se subcontrata a países populares de deslocalización de bajo costo para que los desarrolladores inflen demasiado sus currículums y habilidades solo para conseguir el trabajo. A menudo no se preocupan por sus habilidades hasta que lo consiguen, porque muchos de ellos simplemente continúan construyendo para conseguir el concierto que realmente paga un salario digno cómodo.
Solo usted puede responder esto por sí mismo, pero tómelo como una experiencia de aprendizaje para la próxima vez.
fuente
¿Entonces ustedes dos primero hicieron un contrato y luego le dejaron escribir una especificación, y aceptaron esa especificación para formar parte de su contrato? Si así fue, entonces no es tu culpa, es culpa de tu contratista. Podría haber escrito fácilmente una especificación dándoles 3 meses de trabajo en lugar de 3 semanas, todo por el mismo precio.
¿Eran estas cosas parte de su especificación? Si lo fueran, es su culpa. Si no, es tuyo. Si no estaba realmente claro si estas cosas están contenidas en la especificación, entonces también es su culpa, ya que escribió el documento. Intenta escribir una mejor especificación la próxima vez.
fuente
Hice una presentación hace un tiempo sobre la deslocalización. Se llamó "Outsourcing global, 10 consejos para potenciar su negocio". Aquí hay un resumen de los 10 consejos (esto proviene de hasta 400 proyectos subcontratados):
Una elección
Evite los postores más bajos y más altos . Esto es simplemente obvio, no desea correr riesgos con los postores más bajos y los postores más altos tienden a ser menos valiosos (valor / precio) que la mediana.
Verifique las calificaciones (o referencias) . Siempre verifico referencias y calificaciones.
Priorizar la motivación . Al mismo precio, elijo la oferta que fue motivada. Por ejemplo, hacer que el postor hable sobre su proyecto correctamente es una muy buena señal.
B. Supervisión
Protege tu propiedad intelectual . Este es uno de los mayores errores. Generalmente lo maneja la plataforma que usa (como vworker o elance).
Rechazar marcos personalizados . O corre el riesgo de estar atado a él, o más específicamente al desarrollador que lo escribió;)
Imponer estándares . Relacionado con el consejo anterior. El uso del estándar aumenta el valor de su código fuente, ya que es comprensible para una mayor cantidad de desarrolladores.
Revise temprano, revise con frecuencia . La mayoría de los problemas se pueden "ajustar" si revisa el código fuente después de la primera semana o del trabajo.
C. Estrategia
Proveedores de prueba con pequeños proyectos . Antes de dar un gran proyecto a un proveedor, lo pruebo con uno o dos proyectos más pequeños.
Acepte múltiples postores para reducir el riesgo . Para proyectos críticos, selecciono dos o tres postores y luego tomo la mejor implementación. Trabaja mejor con proyectos pequeños (menos de $ 5000).
Ensamblar componentes . Otra estrategia es externalizar componentes que ensambles más tarde. Una ventaja es que puede cambiar fácilmente entre proveedores y ninguno realmente tiene acceso a todo (reduce los riesgos de propiedad intelectual).
fuente
Estoy totalmente de acuerdo con la respuesta de maple_shaft.
Usted aceptó el código y supongo que escribió el cheque, luego lo revisó, de alguna manera hizo todo al revés.
Porque no lo escribiste en el contrato. Como quería que se hiciera el trabajo, aceptó sus razones, a pesar de que es lo que lo metió en problemas.
Deberías haberles proporcionado un diseño que creías que habría funcionado. Entonces realmente no importaría si no entendieran completamente. Quiero decir que no les pagaste para hacerlo, ¿quién lo va a hacer? ¿Cómo se mantendrá este código sin ninguna documentación y especificación de diseño? La respuesta probablemente no será .
Tienes suerte de que hayan hecho los cambios que querías. Podrían haber dicho: mala suerte
Por supuesto, otras personas están en su posición, de lo contrario, toda la industria "externalizada" no se vería perjudicada, muchas empresas están empezando a darse cuenta de que tener que pagar (o esperar) para hacerlo 3 y 4 veces es más costoso que hacerlo bien una vez .
Al menos haciéndolo usted mismo, puede verificar el estado del proyecto diariamente. Si está detrás, hay cosas que puede hacer para controlar el daño, al menos en teoría.
fuente
companies are starting to realize having to pay ... to do it 3 and 4 times is more expensive then doing it right once.Es más que esto, solo creo que la fase de luna de miel de la industria con el desarrollo de software de deslocalización está llegando a su fin y más empresas están comenzando a darse cuenta de que no es el becerro de oro que pensaron que sería ( o se les dijo que lo haría). ser por consultores ). La mayoría de la gerencia apesta y no tienen idea de por qué, así que buscan la bala de plata del día para resolver todos sus problemas. La deslocalización es excelente si lo haces bien, pero la mayoría no tiene ese tipo de disciplina.