Desde Genbeta Dev hemos querido recuperar esta serie de posts sobre trabajo autoempleado por varios motivos de peso. Primero porque nos han llegado varias solicitudes para ello por parte de nuestros lectores, y segundo porque tal y como se presenta el futuro creemos que es necesario estar formado e informado sobre el asunto.
Cuando un programador o ingeniero de sistemas se lanza a la aventura en solitario (o como socio en una SL o Coop) se le puede denominar de muchas maneras, Freelance, Autónomo, Emprendedor (Entrepreneur si vas de moderno), Valiente, Loco, etc.
Pero a lo que estamos acostumbrados es a que nos traten como prostitutas cuando decidimos no trabajar para terceros y eso es algo que no se debe permitir.
Autoempleo no es prostitución
Antes de iniciar ningún proyecto de autoempleo, bien sea éste como socio en una sociedad con su propia forma jurídica o bien a través del trabajo autónomo como freelance, lo primero que tenemos que hacer es una valoración lo más detallada posible de cuales son los recursos a nuestro alcance, cual va a ser nuestro modelo de negocio, cual es nuestro punto de partida y cuales son las metas que queremos alcanzar a largo plazo y aquellas más asequibles a corto plazo.
Sobre todo, tenemos que trazar un plan estratégico o un plan de empresa y definir una serie de normas y lineas invisibles que no estaremos dispuestos a cruzar, debemos saber valorar lo que cuesta nuestro trabajo y no rebajarnos a cobrar menos de lo que realmente creemos que merecemos, solo de esa manera conseguiremos que el autoempleo no sea igual a la prostitución.
Breve introducción al profesionalismo
En España estamos acostumbrados a lo que aquí se denomina “cárnica”, en otros países más “evolucionados” se les llama “consultoras repetitive”. En estas empresas no se vende profesionalidad ni conocimientos y mucho menos calidad sino mano de obra barata y horas, muchas horas de esa mano de obra.
Normalmente no se puede hacer carrera en ellas por lo que la calidad de sus productos es cuanto menos “sospechosa” puesto que no se siguen metodologías ni buenas prácticas y la implicación de los trabajadores es prácticamente nula debido a su alta precariedad y falta se sensación de pertenencia.
Así es como nos encontramos aplicaciones web con SQL Injection de libro y aberraciones que algunas personas se empeñan en denominar “software” salidas de las mismísimas puertas del hades de empresas que “buscan la excelencia y la pasión en su trabajo“.
El primer paso para iniciar un proyecto espléndido y con futuro ya no como desarrollador freelance, sino como profesional de las TIC es negarse en rotundo a trabajar para este tipo de empresas que lo único que saben es ganar concursos a base de prácticas cuestionables y vender a sus trabajadores como carne en oferta.
Hay que recordar lo que somos y casi que más importante, lo que no somos. No somos ni frikis, ni autónomos, ni personal laboral, ni personal externo, ni subcontratados, ni técnicos, somos profesionales y expertos en nuestra parcela de conocimientos que por otro lado, es lo suficientemente oscura y compleja como para que sea necesario cierto grado de conocimiento vetado para una inmensa mayoría de la población que sería incapaz de implementar las soluciones que requieren por si mismos.
Al igual que un abogado, un procurador, un médico o un asesor financiero, nosotros somos expertos en nuestra parcela laboral, sabemos lo que cuesta nuestro trabajo, sabemos llevarlo a cabo y por supuesto, sabemos como y por cuanto cobrarlo.
Lee el artículo completo.
La importancia de las metodologías en tu trabajo autoempleado
Muchos de los problemas que tienen los profesionales freelance es el de no definir una metodología de trabajo a la que adherir al cliente antes del inicio del proyecto.
Es común que una vez acabado y entregado el trabajo al cliente, su respuesta sea “esto no es lo que yo quería”. También es común que una vez entregado el proyecto se produzca el advenimiento de lo que en mi tierra viene a denominarse los “poyaques”. ¿Y que es eso del poyaque? te estarás preguntando. Pues es más fácil que te lo enseñe con un buen ejemplo gráfico a que te lo explique:
- Pues aquí le traigo el informe de fin de proyecto Don Lorenzo, verá que todo está conforme a lo acordado. – Estaba yo pensando “pos ya que” estamos, podrías añadir un formulario de contacto y un botón para vectorizar la junta de la trócola del condensador de forlayos. ¿Entra en el precio verdad?
Ahí tenemos el infame poyaque, “poyaque estamos”, “poyaque hemos arreglado…”, “poyaque vas a cambiar el color, podrías poner un botón, si eso no cuesta nada ¿no?”, “poyaque tal, poyaque cual”
La propuesta metódica
Casi más importante que la propuesta económica es sin duda una propuesta metódica que el cliente firme aceptando sus términos antes de iniciar cualquier tipo de relación comercial. La propuesta metódica es de facto un contrato que enmarcará el devenir de nuestra relación con el cliente desde el inicio del proyecto hasta su finalización independientemente de la naturaleza del mismo.
Usemos una metodología predictiva o ágil debemos implicar al cliente en nuestro proceso productivo y debemos hacer que se comprometa con la metodología de desarrollo convenida. El cliente debe validar el diseño de la aplicación antes de abordarlo y debe hacerlo de forma explícita.
De esta forma, si durante el desarrollo surgen cambios será posible legitimar que dichos cambios suponen una interferencia en el plan de desarrollo y que según se recoge en la metodología aceptada repercutirá de forma positiva o negativa en el precio final del bundle.
Bien usemos una metodología ágil com SCRUM o un waterfall debemos protegernos contra los temidos poyaques que de seguro el cliente va a enviarnos en forma de torpedo durante el desarrollo o la finalización del proyecto.
Así no solo construimos aplicaciones o sistemas, también construimos relaciones duraderas con nuestros clientes en donde ambas partes salen ganando y ninguna abusa de la otra, es decir, relaciones sanas.
Lee el artículo completo.
¿Por qué es importante definir y validar casos de uso?
En mayor o menor medida, todos conocemos lo que es un caso de uso y para que se utiliza. Muchos profesionales ven la tarea de definir casos de uso como algo tedioso y aburrido que al final, no vale para nada. No voy a entrar a valorar la magnitud del error que creo que comete ese tipo de profesional con ese tipo de aseveración. Definir un documento de especificación funcional es tarea fundamental a la hora de defender nuestros proyectos y legitimar los cambios facturables a los mismos.
El objetivo
El objetivo de un documento de especificación funcional es cerrar la funcionalidad y el diseño de una aplicación con el suficiente detalle como para crear un marco de trabajo donde vayamos desarrollando y cerrando casos de uso o escenarios y el cliente pueda ir revisándolos y enviando tickets si encuentra bugs o errores en el comportamiento de la aplicación según el documento de especificación.
El documento sirve como una guía tanto al desarrollo como al testeo de la aplicación. Escribimos código que cumple con las especificaciones redactadas en el documento de especificación funcional que ha sido validado por el cliente. En dicho documentos se especifican tantos casos de usos como sean necesarios con el mayor detalle posible.
Si no disponemos de un documento guía validado por el cliente en el que apoyarnos, ¿cómo pretendemos huir de los temidos poyaques?
La utilidad del documento
La utilidad principal del documento es la legitimación de facturabilidad y protección anti poyaques. Como estamos basando nuestro desarrollo en unos casos de uso bien definidos y validados por el cliente, si un buen día nuestro cliente aparece con 3 casos de uso más, eso es claramente un cambio no especificado y podemos defender de forma sencilla su facturabilidad futura.
Según la “Ingeniería del Software”, un documento de especificación funcional también especifica otro tipo de datos de carácter técnico como modelos de datos y análisis. Yo prefiero no añadir nada más que escenarios o casos de uso a éste documento y guiarme por la metodología de gestión de proyectos que se acuerde usar para documentar ese tipo de cosas. Habrá gente que este completamente en desacuerdo con esa práctica, es cuestión de gustos. Hay que recordar que el objetivo de este post es remarcar la importancia de definir escenarios
Lee el artículo completo
Conclusión
Recomiendo la lectura completa de los artículos originales pues en este resumen no se concentra todo el espíritu y contenido de los mismos. También ha pasado casi un año desde que se escribieron y como todo, hemos madurado y adquirido nuevos conocimientos. Por ejemplo, ahora estoy mucho más a favor de utilizar ATDD en lugar de casos de uso ya que al fin y al cabo, en un caso de uso se usa el lenguaje, y el lenguaje es algo abstracto que queda abierto a interpretaciones.
Más en Genbeta Dev | Cinco consejos para trabajar como freelance