Consejos para freelance en desarrollo de software

Empezaré este post por decir que ni mucho menos soy experta en este tema, recien estoy ofreciendo servicios freelance para aplicaciones en Windows Phone y sitios web en MojoPortal, pero me gusta escribir sobre las cosas que me preguntan y compartirlas con personas a quienes algunos consejos empíricos podrían ayudarles.

Los que me conocen saben de mi amor por las mejores prácticas de Ingeniería de Software, pero la vida es la vida, y lo ideal es lo ideal, y la teoría es bonita, pero no aplica en todos los ámbitos, sin embargo antes de continuar no voy a dejar de invitarlos a leerse algunos de mis post y reflexiones sobre ingeniería de software.

¿Que tanto nos permite cada escenario aplicar mejores práctica? es tema de otro post, sin embargo haciendo pauta publicitaría a las buenas practicas los invito a conocer Personal Software Process (PSP) para aprender variadas cosas útiles. Aquí trataré de mencionar algunas ideas sencillas para tratar de no ser embaucados o salir tan mal librados de un contrato de construcción de software por internet.

Si hablamos bien, si escribimos mejor: No hay mejor consejo que darles, por favor, no se metan en lios sin necesidad, la buena práctica de escribir los correos con las conclusiones de una reunión o confirmando que algo que no es muy claro lo entendimos, nos puede librar de más de un dolor de cabeza. Escuchar a su cliente es tan importante como cuidarse ustedes mismos de un mal entendido, que podría provocar reprocesos u horas extras no pagas. Por favor guarden ordenadamente respaldos de sus correos por Cliente y por Proyecto, esto ante un proyecto problema servirá de muchísima ayuda.

Muchas de estas contrataciones son informales, pero no por que lo sean significa que no tenemos derechos y obviamente deberes, si bien en muchas ocasiones no tenemos un contrato legal, es importante que al conocer cual es nuestra labor, sea un cambio, afinación o construcción de algo nuevo, dejemos en un pequeño documento (si pequeño para que el cliente lo lea y valide de verdad), los acuerdos y el consenso al que se llegó con las funcionalidades acordadas, este documento lo podemos ir refinando a medida que vamos avanzando en la estimación de tiempos y siempre trataremos de pedir amablemente al cliente que lo valide, si no lo hace aduciendo que confía en nosotros, sería preciso justamente mostrarle que el documento es una evidencia de que queremos hacer las cosas bastante bien. Solo eviten hacer de este proceso de validación algo complejo, ya que el exceso de protocolo es algo con lo que algunos de estos "tipos de clientes" podrían no identificarse.

Y si el problema es que esté en un documento, envíe el texto en uno o varios correos y vaya obteniendo la aprobación de cada uno de los puntos.

¿Como sabemos cuanto cobrar?: Creo que este es el tema que más nos duele como freelance, cuanto cobrar sin que el cliente me diga no y sin tener que regalar mi trabajo. La verdad es que es bastante difícil medir esto, hasta las mejores casas de software se equivocan haciendo presupuestos y flujos de caja. Cobrar un trabajo de software tiene muchas implicaciones, de tiempo, de materiales (si, papel, internet, la depreciación misma de nuestros equipos de computo) como encontrar un punto equilibrado, creo que solo lo va ajustando el tiempo, si nosotros conocemos nuestro trabajo y cuanto tiempo tardamos en ejecutar una actividad es probable que cada vez seamos más precisos en determinar un proyecto nuevo cuanto esfuerzo podría tomarnos y eso lo pueden aprender ejecutando PSP, así que no olviden leer sobre eso.

Pero bueno, si yo no sé PSP y mucho menos tengo historia de las cosas que he realizado ¿que puedo hacer? Voy a tratar de listarle algunos pequeños consejos desde mi óptica.

• Enumere en forma detallada las funcionalidades que tiene que construir, no escatime en detalles si una funcionalidad del sistema le parece que lleva varias funcionalidades considerables dentro, enumere cada una de ellas hasta que sienta que ve la funcionalidad y puede determinar su complejidad, si al analizarla ve que dentro hay cosas que quedarían ocultas, construya una lista y por supuesto valide con el cliente.
• Trate de asignarle un nivel de complejidad a cada una de las funciones de la lista y determine cuanto tiempo le tomaría construirla, pero además incluya en ese tiempo un poco de análisis, documentación si así lo acordó, planificación e investigación si tiene que estudiar para poder construirla.
• Cuando estamos estimando es importante considerar los imprevistos, algunas técnicas de estimación plantean 10% o poco más en imprevistos, ¿que significa esto? Qué al tiempo que estimó le sume un 10% adicional, y como obviamente esto no es un rubro independiente, distribúyalo entre las funciones o los módulos del sistema si tiene que pasar alguna relación o estimación de tiempo a su cliente. 

¿Y las pruebas que?: Resulta que construir no es suficiente, aunque no sea de las mejores prácticas que probemos solos nuestros proyectos, tenemos que tratar de hacerlo, y mejor si alguien externo nos ayuda para que así las pruebas no se sesguen a nuestro conocimiento del software que construimos.

Hacer pruebas y llevar una bitácora sencilla de los errores que vamos encontrando es muy importante, además de tener escritas algunas pruebas básicas que siempre deberíamos hacer a nuestro software antes de una entrega, de esa forma los beneficiados somos nosotros, evitamos reprocesos y logramos entregar un producto de mejor calidad.

¿Son gratis las pruebas? No señor, hay que tratar de determinar cuanto tiempo nos toman e incluirlo como costo. No a muchos clientes que contratan de esta forma les parece que las pruebas se cobren (los equivocados son ellos) todo se cobra, si usted sabe que su cliente es así trate de distribuir este tiempo en los ítems relevantes de desarrollo que deba presentarle como relación de tiempo.

Los cambios cuestan: Dar por sentado o por entendido todo (incluso lo que no han dicho) es una de las prácticas favoritas de muchos clientes, sin embargo hacer software también se trata de eso, si como dije antes fuimos ordenados guardando los acuerdos que realizamos inicialmente y además creamos un pequeño documentos de acuerdos, tendremos más herramientas para mostrarle siempre amablemente al cliente, que lo que estaba pidiendo nunca lo había dicho, de nosotros depende que así sea, o entrar en pelas de "su palabra contra la mía" ya que muchos clientes tratarán de decir que eso lo dijeron de forma verbal.

Recuerden en ese pequeño documento de acuerdos, colocar una frase directa en donde se especifique que, cualquier cambio o modificación que pudiese sobrevenir después de validado el acuerdo podría incurrir en cobros adicionales.

Por otro lado, dije mucho de protegernos pero yo creo que es importante resaltar que tampoco estamos por aprovecharnos de los clientes, ser éticamente responsables, tener presentes los acuerdos y dar tiempos prudentes de garantía sobre nuestro trabajo es algo que seguramente será valorado y tenido en cuenta.

En fin, estos son algunos tips, de seguro muy alineados a algunas de las mejores prácticas de ingeniería de software, pero que podemos aprovechar en nuestros trabajos y evitarnos problemas innecesarios y trabajo extra injustificado.

¿Que tal si me cuentan sus tips para trabajar como freelance en construcción de software?

Sorey