La noticia de hoy es que un desarrollador hackeó github . Encontró una vulnerabilidad en Ruby on Rails, la reportó y como no había pasado nada -fue ignorado y considerado como un troll-, usó la vulnerabilidad y hackeó el segundo servicio más famoso que usa Ruby on Rails (github).
Aunque este incidente no tiene nada que ver con la gestión de proyectos, me hizo pensar; hay muchos desarrolladores que carecen de las habilidades de comunicación necesarias y actúan en lugar de hablar. Conozco a un puñado de desarrolladores que actuarían de la misma manera que el tipo que pirateó github: causarían daño, solo para demostrar que tienen razón. Sin duda, su intención es cuestionable, pero son buenos en lo que hacen, pero carecen de algunas habilidades blandas útiles.
Entonces mis preguntas:
1: En primer lugar, haga lo correcto lo más fácil posible y asegúrese de que se entienda bien.
En este caso particular, un portavoz de Github respondió:
No hemos sido tan claros como deberíamos haber sido sobre cómo divulgar de manera responsable los problemas de seguridad, y lo siento.
Además, piensa en qué sería lo incorrecto y considera que puede haber diferentes grados de lo correcto . Por ejemplo, puede invitar a personas a que vengan y pirateen su sitio en un entorno más seguro, a cambio de una recompensa o prestigio. O simplemente podrías perdonar a personas como Egor, que en realidad no causó ningún daño, aunque podría haberlo hecho.
No creo que fuera Egor quien careciera de las habilidades de comunicación necesarias en este caso. Estaba brindando información, de forma gratuita, y la comunidad de Rails no tenía las habilidades de comunicación para alentarlo a compartir. La responsabilidad de comunicarse de manera efectiva recae en la persona que se beneficiará.
2: Sea persuasivo. Haz otras cosas para ayudarla a confiar en ti. Cuente historias sobre otras personas que no escucharon. Entonces, si hablar no funciona, actúa.
Entonces, ¿el desarrollador se sintió ignorado cuando intensificó una amenaza, así que les mostró y les mostró lo bueno? Las organizaciones tienen todo el derecho de mitigar sus amenazas o simplemente aceptarlas y continuar. Es una decisión comercial basada en el nivel de amenaza y los costos para mitigar y otras consideraciones. No necesitan que una escala de riesgos les demuestre que están equivocados haciendo realidad una amenaza con una probabilidad que es menos que segura.
¿Te imaginas reemplazar el desarrollador con un agente de la TSA y hackear una bomba? '¡Boom!' '¡Ves, te lo dije!'
Despidelo.
Si yo fuera el gerente de proyectos de Egor, consideraría que le he fallado a Egor.
Mi segundo principio es "La comunicación es el 100% de su trabajo (el gerente de proyecto, el maestro de scrum, el entrenador)". Este asunto cae justo en esta máxima.
Como gerente de proyecto, nuestro trabajo es comprender a todos en nuestro equipo. En cualquier esfuerzo con mentes creativas (la codificación de software es definitivamente uno de esos) tendrá personas brillantes que no son buenas para comunicarse de la manera que la mayoría de la gente seguirá. Como gerentes de proyecto, no podemos exigir que todo el equipo hable en diapositivas de PowerPoint redactadas en una sílaba que el director ejecutivo entienda. En cambio, es nuestro trabajo escuchar al equipo y traducir.
Utilicé el sistema de perfil DISC para esto, con gran efecto. En pocas palabras, DISC es un modelo de comunicación basado en el estilo de comunicación "predeterminado" de las personas. Ds son tu tormenta la colina Generales, corto, al grano. Es su alegre entrega de vendedores, "suficiente sobre mí hablando de mí, ¿por qué no hablas de mí". Ss son la mamá del equipo, "¿no podemos llevarnos bien todos?" Y los C son los trituradores de datos, "Eso sería ilógico".
Mi apuesta es que Egor calificaría como una C alta con tendencias S altas. Él le proporcionará un informe escrito de veinte páginas sobre todo lo que ha encontrado mal con Ruby. Tampoco comenzará con el punto, sino que comenzará desde el principio y explicará todo, paso a paso. La cabeza de su CEO promedio habría explotado en la página dos.
Los gerentes de proyecto (scrum masters, entrenadores) deben ser mejores que su CEO promedio. Tenemos que aprender a escuchar en la forma en que nuestros equipos se comunican. Tenemos que saber cómo tomar esa información y luego traducirla en algo que cualquier otra persona pueda entender: "Oiga, director general, la pérdida de confianza del cliente resultará en un derrumbe total de ingresos y prensa negativa que dejará a la empresa sin suficiente dinero para financiar su paracaídas dorado". ."
Si yo fuera el jefe de proyecto de Egor, sentiría que le había fallado tanto a mi compañero de equipo como a mi empresa.
Nota: Este es un concepto hipercondensado y generalizado de DISC y traducción de comunicaciones. Esta no es una recomendación de acción específica.
Pregunta 1:
Después del evento, es posible que tenga un alcance limitado para "ayudar" al desarrollador, especialmente si ha actuado de alguna manera que podría considerarse ilegal. En tal caso, lo mejor que puede esperar es discutir el problema con el desarrollador, mostrar qué daño ha causado a su empresa como resultado de las acciones del desarrollador y pedirle que brinde su perspectiva sobre las opciones que son. disponible para ti. Es posible que aún tenga que separarse de él, desafortunadamente, para protegerse a sí mismo y a su empresa, sin importar cuán reacio pueda ser a seguir ese camino.
Para evitar una situación similar en el futuro, considere introducir una política de uso aceptable dentro de la empresa, que establezca explícitamente que tal comportamiento no es aceptable y, lo que es más importante, explique por qué. Asegúrese de que esto se comunique a todos los empleados y existentes, y que tengan la oportunidad de discutirlo en reuniones de equipo / sesiones individuales, o lo que le parezca correcto. Explique que esto es para protegerlos a ellos y proteger a la empresa, y anime a sus empleados a hablar sobre la necesidad de esto. Cubra esto también en las sesiones de inducción para los nuevos empleados.
Pregunta 2:
Creo que la primera acción es poner sus preocupaciones por escrito y plantear un riesgo de proyecto formal si eso es posible. Eso debería llamar su atención. Haga un seguimiento con una llamada telefónica o incluso una reunión cara a cara, en la que explica lo peor que podría pasar si no se soluciona el error. Al fin y al cabo, es su responsabilidad actuar para reparar la avería, pero tú tienes la responsabilidad (que ya has reconocido) de comunicárselo. Sin embargo, habiendo presentado su caso con la mayor solidez posible y sugerido soluciones si puede, la responsabilidad final recae en el cliente. Tiene una decisión adicional: si el problema es tan grave que también podría dañar su reputación, es posible que desee alejarse en lugar de asociarse con el problema, pero con suerte no llegará a eso.
jmort253