Manifiesto Código Ético en Desarrollo de Software

Versión	Fecha	Notas
1.0	Marzo 2019	Versión revisada y publicada en github.
0.2	Noviembre 2018	Versión compartida con los colaboradores.
0.1	Agosto 2018	Borrador inicial.

¿Quieres firmar este documento y/o colaborar en su mejora? Escribe aquí por favor: https://github.com/javichur/codigo-etico-desarrollo-software/issues

I. INTRODUCCIÓN

• Este manifiesto está destinado a desarrolladores, organizaciones que crean software y a clientes de software, que quieran un código ético común en el que trabajar.
• El documento no se centra en la forma de programar software; sino en las relaciones entre la Organización de desarrollo de software, los Trabajadores, los Clientes, los Proveedores y la Sociedad. Se prioriza la transparencia, honestidad, compromiso y reconocimiento de todas las partes. El respeto de estos principios hace que sea valioso para todas las partes implantarlo en las organizaciones.
• El desarrollo ético de software es un compromiso duradero de las organizaciones y de los trabajadores; no es un "logo" o "sello" que se pueda poner en unos proyectos de software sí y en otros no. Las organizaciones y profesionales que adopten este texto deberán respetarlo de forma continua y no puntualmente.
• La primera versión fue inspirada tras leer acerca del código ético para la Inteligencia Artificial (AI) en el libro "Pulsa actualizar" de Satya Nadella (CEO Microsoft).
• La siguiente agrupación en secciones es orientativa, ya que la mayoría de los puntos afecta a más de una parte: sociedad, trabajadores, proveedores, clientes y la organización de desarrollo de software.

II. SOCIEDAD

1. Al menos el 1% de los beneficios del proyecto se destinará a Responsabilidad Social Corporativa. La organización comunicará, en el presupuesto entregado al cliente potencial, este porcentaje y qué proyectos solidarios tiene planificados.
2. Los impuestos a cargo de la organización se pagarán en el país en el que se encuentre ésta. El cliente conocerá cuál es dicho país desde el inicio de las conversaciones de solicitud de presupuesto. Los datos de facturación (dirección, país y nº de identificación fiscal) aparecerán en el presupuesto.

III. TRABAJADORES

3. Las categorías laborales y los puestos de los trabajadores serán acordes a las funciones que desempeña cada persona en la organización.

4. Para elaborar el presupuesto de un proyecto, se contará con la estimación de esfuerzo realizada por los programadores de la organización. Estos programadores serán aquellos que estén disponibles en el momento de realizar el presupuesto pero que tengan un nivel de experiencia similar al de los programadores de la organización que potencialmente participarían en el desarrollo de dicho proyecto. Es decir, no harán las estimaciones los programadores Senior y la programación los Junior, ni viceversa.

5. Las horas extra se acuerdan por escrito entre la organización y el trabajador antes de realizarlas, son voluntarias y se remuneran una vez realizadas. El pago se hará efectivo en los 60 días naturales posteriores a su realización.

6. Las horas ordinarias y posibles horas extra realizadas en el proyecto se registrarán diariamente, de forma que sea fácil conocer, para los desarrolladores y los Jefes de Proyecto: el progreso del proyecto, su rentabilidad, horas consumidas, horas pendientes y posibles desvío en la estimación. Es responsabilidad de la empresa proporcionar los medios para anotar esta información, es responsabilidad del trabajador anotarlo y es responsabilidad del Jefe de Proyecto validar esta información.

7. El equipo de desarrollo conocerá desde el inicio del proyecto la identidad del cliente, la documentación aprobada por éste y el presupuesto.

8. El trabajador se compromete a mantener al día sus conocimientos técnicos. Es responsabilidad del trabajador solicitar a la organización cursos de formación cuando necesite mejorar o adquirir nuevos conocimientos para desempeñar sus funciones. Antes de aprobarse la formación, se acordará entre las partes en qué horario y días se realizará (pudiendo ser por ejemplo 100% en horario de oficina, 50-50 ó en horario fuera de oficina).

9. Los trabajadores comunicarán a la organización los proyectos externos en los que participen (opensource, proyectos personales u otros), con el fin de buscar colaboraciones, mejorar el plan formativo de la organización y evitar incompatibilidades.

10. El periodo de descanso de los trabajadores será respetado. No se llamará ni escribirá mensajes instantáneos a personas que estén fuera de su jornada laboral o en días de vacaciones. Como única excepción, y solo en casos de urgencia, se intentará localizar a un trabajador si éste olvidó subir código fuente, claves o documentación a los repositorios de la organización y dicha información está en un equipo o cuenta del trabajador.

IV. PROVEEDORES

11. La organización comunicará las externalizaciones al cliente, indicando la organización/profesional con quien se colaborará en una parte del trabajo, el coste, el porcentaje respecto del total del proyecto y la tarea que desempeñará dicho experto. La externalización no es mala si se hace de forma controlada y planificada en el proyecto. Por ejemplo, para contar con un experto en una tecnología concreta.

12. La cadena de externalización está limitada a estos niveles: cliente -> organización proveedora de software -> experto. Tanto la organización proveedora como el experto pueden ser empresas y tener personas contratadas.

13. El límite máximo de externalización de un proyecto será de 30%.

V. CLIENTES

15. Asesoramiento en la viabilidad del proyecto. Debemos estar comprometidos, además de con la buena ejecución del proyecto, con la viabilidad del proyecto para nuestro cliente. La organización avisará al cliente si considera que:

• El proyecto no es económicamente viable para el cliente (por falta de inversión inicial, por modelo de negocio, por ser un océano rojo, etc…),
• El equipo del cliente no reúne las capacidades suficientes (falta de dedicación al proyecto, falta de conocimientos),
• La organización no cuenta con los medios técnicos y humanos para desarrollar el proyecto. Es decir, si el cliente piensa que va a recuperar la inversión pronto pero nosotros pensamos que su idea no es viable, es compromiso de la organización comunicar nuestra percepción al cliente.

15. Transparencia sobre proyectos similares. La organización comunicará al cliente si ha trabajado previamente en proyectos similares. Se respetarán los acuerdos de confidencialidad existentes (NDA), pudiendo por ejemplo, informar de proyectos ya publicados.

16. En el presupuesto, se transmitirá total transparencia en la estimación del esfuerzo, desglosando dicho esfuerzo por bloques funcionales y por roles (Jefe de Proyecto, Diseñador, Programador, Analista, Testing, Documentación, Proveedor). Cada bloque funcional nunca tendrá tamaño superior a un sprint.

17. Al finalizar el proyecto, se entregará al cliente el desglose de las horas invertidas por cada rol del equipo en el proyecto, tanto si se ha ganado más dinero del esperado como si se ha perdido.

18. Las horas dedicadas a testing se evidenciarán al cliente entregando el plan de pruebas realizado y el listado de defectos internos encontrados.

19. No se secuestra código fuente. En los desarrollos a medida que no son "Software as a Service", el contrato entre Organización y Cliente incluirá la entrega del código fuente al cliente.

20. Transparencia tecnológica. En los desarrollos a medida que no son "Software as a Service", el contrato entre Organización y Cliente incluirá la pila tecnológica que se va a utilizar, así como las librerías de terceros que se han tenido en cuenta para la estimación del esfuerzo.

21. Límite de margen. En la venta de software a medida (que no es "Software as a Service" ni software ya desarrollado), el margen teórico del proyecto no debe ser superior al coste del mismo, es decir, 50%.

VI. LA ORGANIZACIÓN DE DESARROLLO DE SOFTWARE

22. Las reuniones internas y reuniones con cliente estarán planificadas. Se convocarán con al menos 24 horas laborales de antelación.

23. Las reuniones tendrán un Orden del Día que se enviará junto con la convocatoria y, por tanto, con antelación suficiente.

24. La organización realizará un acta de la reunión con todos los temas tratados y decisiones tomadas, y la enviará a todos los asistentes. Elaborar y enviar este acta es responsabilidad de la persona que convocó la reunión.

25. La duración de las reuniones estará limitada a 2 horas. Es decir, se promoverá 2 reuniones de 2 horas cada una, antes que una reunión de 4 horas. Para ello se necesita un buen trabajo previo en el Orden del Día. Como recomendación, las reuniones próximas a las 2 horas deberían suceder solo en la fase inicial del proyecto y las reuniones más breves serían durante la fase de desarrollo.

26. Se adoptarán medidas para reducir las interrupciones a los desarrolladores, como por ejemplo implantar un Centro de Atención al Usuario (CAU) y el uso de canales asíncronos de comunicación en lugar de acudir a la mesa del compañero a interrumpir.

27. No desarrollamos software cuyo fin sea:

• Actividades consideradas ilegales en nuestro país.
• Discriminar a personas o colectivos por su raza, religión, sexo, orientación sexual o país de procedencia.
• Juegos de azar donde el usuario puede gastar dinero real, por los problemas de adicción.

28. La organización añadirá herramientas para aumentar la confianza en el código fuente creado por el equipo. Se realizarán al menos documentos de planes de pruebas que se enviarán al cliente junto con cada entrega de software.

29. La planificación de los proyectos tendrá en cuenta el tiempo destinado a "Formación Interna" (píldoras formativas) para transferir el conocimiento entre los compañeros del equipo. La planificación también respetará cursos de formación planificados en los planes de carrera de los trabajadores.

30. No marca blanca. Tanto en los casos de ser el proveedor principal como en los casos de ser parte externalizada por otro proveedor, el cliente conocerá la identidad de la organización que participa en el desarrollo.

31. Plan de carrera. La organización preparará un plan de carrera para cada trabajador. Este plan se elaborará durante los primeros 12 meses. El plan incluirá al menos metas individuales y ventajas individuales por alcanzar dichas metas en los plazos establecidos. Como recomendación, es posible incluir también metas grupales y beneficios grupales en estos planes.

VII. AGRADECIMIENTOS

Este documento ha sido posible gracias a la participación de muchas personas que se dedican al desarrollo de software, gestión y rrhh. Gracias por todas las aportaciones recibidas de Juan, Cecilio, Rubén, Isabel, Pepe, Paola, Pilar, Iván, Carlos, David y Javi.

VIII. LICENCIA

CC - The content on this site is licensed under a Creative Commons Attribution 4.0 International license (https://creativecommons.org/licenses/by/4.0/).