Bonjour, citoyens Habrovsk!
Récemment, j'ai pu parcourir un bon nombre d'entretiens et même obtenir des offres de certaines entreprises bien connues et pas si européennes, mais je ne vous dirai pas aujourd'hui comment se préparer à résoudre des problèmes de programmation délicats ou comment démontrer au mieux les compétences générales. Aujourd'hui, nous parlerons de l'open source et des contrats de travail, de leur correspondance et de leurs pièges. Il n'y a rien de plus triste qu'un départ forcé de la course après 3 étapes d'entretiens et une semaine de devoirs, quand il s'agit de comprendre que vous ne signerez pas ce contrat de travail même sous la menace d'une arme. J'ai vu de nombreux contrats de travail et j'ai appris à distinguer entre très mauvais et mauvais, mauvais de tolérable et tolérable de bon. En savoir plus sur tout sous la coupe.
Avertissement: dans cet article, je décrirai non seulement mon expérience, mais aussi l'expérience de mes amis. Pour des raisons évidentes, je ne nommerai pas les entreprises par leur nom dans cet article.
Alors, imaginez la situation: vous effectuez une tâche de test pendant une semaine, passez par 3 étapes de l'entretien, ils vous envoient une offre avec une relocalisation en Europe de l'Ouest pour un prix relativement bon, vous êtes prêt à tout laisser tomber et déjà récupérer vos valises, mais quelque chose vous inquiète, vous demandez un peu plus de temps réfléchissez et demandez à vous envoyer un projet de contrat de travail. Vous étudiez attentivement le contrat, plongez dans toutes les nuances et comprenez qu'il s'agit d'un exemple de très mauvais contact, aux termes duquel vous:
- Vous n'avez aucun droit de divulguer quoi que ce soit, du mot du tout. Sinon - une grande amende.
- Vous pouvez oublier vos projets. Sinon - une grande amende.
- S'il y a au moins un lien entre ce que vous faites / inventez longtemps après l'emploi et ce que vous avez travaillé ou même appris / acquis de l'expérience de cet employeur, vous devez alors lui transférer tous les droits en conséquence. Même si pour cela, vous devez vous rendre dans un autre pays et demander des brevets et une cession de droits. Sinon - une grande amende.
- Vous faites des heures supplémentaires sans compensation supplémentaire.
- Les termes du contrat, l'employeur peut changer unilatéralement.
Et ce n’est pas tout. En général, la question est claire - passé la caisse enregistreuse.
Même avant cet incident, je réfléchissais sérieusement à la clause de propriété intellectuelle ou au paragraphe sur les droits de propriété intellectuelle dans les contrats de travail des travailleurs de l'industrie informatique et des programmeurs en particulier. Écrire un code de qualité est souvent la seule compétence que nous avons et nous perfectionnons depuis de nombreuses années dans l'espoir de le vendre plus cher, mais à un moment donné, il s'agit de comprendre que la compétence peut non seulement être vendue, mais aussi investie dans l'open source, qui est de plus en plus appelée la matière noire de l'industrie du logiciel, où sa "gravité" et d'autres "lois de la physique" opèrent. Contribuer à des projets open source est possible pour l'auto-développement et le réseautage avec d'autres développeurs, mais souvent aussi pour que les employeurs potentiels vous remarquent. Un profil sur Github est souvent en mesure d'en dire plus sur un développeur qu'un profil sur Linkedin et d'écrire du code open source, participer à une révision collective du code, corriger des bugs et rédiger de la documentation pour des projets open source fait partie de la vie des développeurs les plus actifs et les plus orientés vers les objectifs.
Lors de différentes conférences informatiques en Europe, j'ai pris connaissance du terme IP-friendly en relation avec les contrats de travail. Ce terme fait référence à de tels accords, qui ne limitent en rien les travailleurs en termes de direction de leurs efforts intellectuels dans leur temps libre ou introduisent des restrictions raisonnables pour protéger l'employeur de la concurrence. Par exemple, les termes du contrat, qui stipulent que "tout ce qui a été fait sur l'équipement de l'employeur et selon les instructions directes de l'employeur, appartient à l'employeur" est plus convivial pour l'individu que "tout ce qui a été fait pendant la durée du contrat de travail appartient inconditionnellement à l'employeur". Comme on dit, sentez la différence!
Google a été le premier à comprendre l'importance du soutien aux projets open source par les développeurs, ce qui a permis à ses employés de consacrer jusqu'à 20% de leur temps à des projets open source; d'autres grandes entreprises ont suivi la tendance et n'étaient pas loin derrière. L'avantage pour les entreprises est évident, il s'agit d'une stratégie gagnant-gagnant, car l'entreprise a la réputation d'être une plaque tournante pour les développeurs les plus talentueux, ce qui attire à son tour des professionnels encore plus puissants. Le seuil d'entrée dans ces sociétés est très élevé et les meilleurs des meilleurs y sont sélectionnés.
La plupart des entreprises sont moins au courant des nouvelles tendances que par ouï-dire et essaient d'inclure autant de restrictions que possible dans le contrat de travail. J'ai dû rencontrer de telles formulations, sans exagération, comme «L'employeur est propriétaire de tout et de tout ce que crée l'employé». C'est un fait triste, mais de nombreux développeurs acceptent de telles conditions en raison d'un manque de connaissances dans le domaine des droits de propriété intellectuelle ou en raison d'une situation de vie difficile (ici, ce n'est que lors du processus d'appel d'offres). Comment améliorer la situation? À mon avis, il existe plusieurs façons:
- Sensibiliser les travailleurs de l'industrie informatique aux droits de propriété intellectuelle.
- Promouvoir les idées de contrats respectueux de la propriété intellectuelle auprès des employeurs.
- Participez non seulement à des projets open source, mais soyez des évangélistes open source.
- Pour soutenir les développeurs dans leur différend avec les entreprises, s'efforcer de s'assurer que l'opinion publique est du côté du développeur si l'entreprise essaie de «serrer» le projet.
Au final, j'ai trouvé un travail avec de bien meilleures conditions contractuelles. L'essentiel est de ne pas se précipiter sur la première phrase et de continuer à chercher. Et pour contribuer à l'open source, parce que l'héritage culturel du développeur est son code, et si le développeur écrit tout le code pour les entreprises, alors son héritage, son empreinte visible et tangible sur le paysage numérique est nul .
PS Si vous avez aimé cet article, devenez mes abonnés sur Habré - j'ai encore beaucoup d'idées non réalisées sur lesquelles je veux écrire, vous serez donc les premiers à les connaître.
PPS L'article prévoit de continuer ...