¿Cómo podemos prepararnos para "ser atropellados por un autobús"?

Question

Como autónomo que trabaja para un cliente (por ejemplo, creando una página web), tiene una factor de bus de 1:

El factor bus es el número total de desarrolladores clave que tendrían que ser incapacitados (por ejemplo, al ser atropellados por un autobús/camión) para que el proyecto se desestabilizara de tal manera que no pudiera seguir adelante; el proyecto conservaría información (como el código fuente) con la que ningún miembro del equipo restante está familiarizado.

Si algo le sucede a usted, el cliente podría tener un problema.

• El trabajo podría no estar terminado. ¿Y si el cliente ya lo ha pagado (en parte)? ¿Y si el cliente aún no ha recibido las contraseñas de acceso, etc.?
• La obra puede estar terminada. ¿Y si el proyecto es tan complejo que el cliente no puede dejarlo en manos de otra persona? ¿Y si el sitio web funciona en su servidor? ¿Y si has registrado el dominio?
• Es posible que haya firmado un acuerdo de confidencialidad. ¿Qué pasa si sus herederos se topan con datos sensibles de su cliente?
• ( ¿Qué más hay que tener en cuenta?)

¿Cómo podemos prepararnos para ello?

Answer 1

Sin querer sonar demasiado cortante al respecto, yo diría que esto es firmemente el problema del cliente y no el tuyo. A ellos les interesa asegurarse de que tienen el código fuente en un lugar en el que puedan conseguirlo y que tienen pleno acceso a todo lo que necesitan para acceder al sistema.

Si le preocupa esto y quiere mostrar la debida diligencia hacia su cliente en lo que respecta a esto, podría hacer uso de una de las plataformas en la nube, como Amazon Web Services o Windows Azure, para alojar el sitio web, y asegurarse de que alguien dentro de la organización del cliente tenga los datos de acceso. Asimismo, puedes utilizar un proveedor de control de código fuente en la nube, como Bitbucket, para asegurarte de que puedan acceder al código fuente en cualquier momento.

Desgraciadamente, esto es un riesgo en cualquier organización que confíe en un solo individuo para construir un sistema de sitio web/software.

Answer 2

Lo mejor es tener una red de otros profesionales a los que el cliente sabe que puede contratar si no le gustas o te pasa algo. En mi negocio, soy el desarrollador más activo en LedgerSMB Pero somos una solución de múltiples proveedores y si los clientes quieren despedirme hay más opciones en el sitio web, los clientes pueden buscar en los archivos de correo electrónico para obtener ideas sobre a quién dirigirse o similares. Por lo general, estoy bastante seguro de que si me atropella un autobús, estamos en un punto en el que el cliente puede encontrar a otros que puedan ponerse al día con relativa rapidez.

Answer 3

Por defecto, comparte el acceso de entrada, utiliza VCS y comenta bien...

Piénsalo desde otra perspectiva: Si fueras un desarrollador que se hiciera cargo de la mitad del proyecto de otra persona, ¿qué querrías tener a tu disposición?

Obviamente, vas a tener que asegurarte de que el cliente tiene acceso SSH y FTP al servidor, y preferiblemente acceso a tu bzr (u otro sistema de control de versiones) para obtener el trabajo que está hecho pero que aún no se ha publicado.

Los comentarios son importantes. Como desarrollador que recoge el 'efecto bus' de otra persona, vas a entender mucho mejor la base de código si tiene una documentación completa de sus clases, métodos, etc. que si los comentarios son inconsistentes (o peor, ausentes).

Hay más cosas que se pueden hacer, pero requieren mucho tiempo...

A partir de ahí, hay que hablar con el cliente sobre los requisitos específicos, que difieren de un proyecto a otro. Si utilizas un marco bastante común con un conjunto de requisitos bastante lineal, puede que no necesites más.

Si, por el contrario, estás trabajando en un monstruo de C++ de 300KLOC con bibliotecas personalizadas, etc., probablemente vas a querer documentar adecuadamente. Obviamente, esto lleva mucho tiempo y muchos clientes te rechazarán por ello, pero en ese momento habrás hecho lo que puedes.

Siempre ofrezco una planificación UML completa para mis proyectos y trato de presupuestar una tarifa razonable.

Answer 4

Creo que sólo hay un consejo general que se puede aplicar en todas partes. Deberías tener una lista ICE (In Case of Emergency), al menos una persona cercana debería saber dónde está (alguien en quien confíes para seguirla realmente) y en esa lista un punto sería "Llamar a todos mis clientes actuales y decirles que no podré terminar el contrato a tiempo / nunca por lo que ha pasado. La lista de mis clientes actuales con los contactos adecuados está aquí: (ubicación)"

En realidad, es responsabilidad de tus clientes asegurarse de que no dependen únicamente de ti; ese es el precio de aumentar la calidad del trabajo y reducir los costes al mismo tiempo recurriendo a los autónomos. Tu responsabilidad es únicamente asegurarte de que saben que tienen que llevar a cabo su plan de contingencia.

Answer 5

El trabajo podría no estar terminado. ¿Y si el cliente ya ha pagado (en parte) por él? ¿Y si el cliente aún no ha recibido las contraseñas de acceso, etc.?

Intenta buscar en sistemas de control de versiones (SVN, Git) y suba sus cambios en cuanto los haga. De esta manera, tu cliente siempre tendrá acceso a estos cambios. Si tienes miedo de que cojan los últimos cambios y se vayan sin pagarte la última parte (o el total), puedes guardar el login del sistema de control de versiones y dárselo a alguien de confianza.

Es posible que haya firmado un acuerdo de confidencialidad. ¿Qué pasa si sus herederos se tropiezan con datos datos sensibles de su cliente?

Aunque no es 100% seguro, siempre deberías proteger con contraseña tu portátil/servidor/carpetas de proyectos. Si te preocupa tanto, puedes incluso encriptarlas.