¿Cómo puedo cambiar la cultura de la empresa descuidada? [cerrado]

A veces, cuando tengo un problema que necesita ser resuelto, encuentro que la forma más fácil de resolverlo es escribiendo un pequeño programa como herramienta personal. No lo hago súper usable o súper robusto, ya que soy el único que lo va a usar, y no tengo tiempo para refinarlo y probarlo a fondo.

Luego, un compañero de trabajo ve el programa y lo solicita, porque se ha encontrado con el mismo problema y la herramienta podría ayudar. Le doy el descargo de responsabilidad "No es bonito pero hará el trabajo" y le dejo que lo haga.

Lo siguiente que sé es que mi superior me está llamando y me dice que está tratando de hacer que el software funcione en la computadora de un cliente, pero muestra un mensaje de error X. WTF ?? Ese software no está listo para su lanzamiento, ni me dijeron que necesitaba estar listo para su lanzamiento. Pero por alguna razón, mi superior pensó que era lo suficientemente bueno y lo lanzó sin decirle al desarrollador original.

Ahora, este problema en particular es fácil de solucionar con a MessageBox.Show("DO NOT GIVE TO CLIENTS!");. Sin embargo, el problema es indicativo de un problema mucho más profundo: la cultura de nuestra empresa es descuidada. El software descuidado está bien y los procesos descuidados están bien. No se preocupe por el futuro: haga todo lo posible para que apenas funcione ahora, coloque los archivos binarios en un archivo .zip y envíelo. Lo suficientemente bueno para el trabajo del gobierno.

Esta es una pequeña empresa con 10 empleados a tiempo completo, está creciendo y ha existido por un tiempo. No me malinterpretes; Amo trabajar aquí y amo la compañía. No me digas que corra; Quiero ser parte de mejorar la empresa. ¿Cómo comienzas a traer un buen cambio a este tipo de cultura?

La única forma de cambiar es hacer que todos los demás vean las desventajas de una cultura descuidada y, quizás lo más importante, que la gerencia acepte su solución. Sin embargo, en realidad, eso no sucede y no podrás cambiarlo. Esa podría no ser la respuesta que esperaba escuchar, pero después de cinco años de intentar y fallar en varios trabajos para cambiar la cultura descuidada, puedo decir con cierta autoridad que generalmente no vale la pena hacer el esfuerzo.

El primer paso sería descubrir si alguien más conoce o se preocupa por la cultura descuidada; Si usted es la única persona que ve algún problema, sus esfuerzos serán en vano.

Es posible que deba reunirse con un compañero de trabajo y un jefe y explicarle que lo que tenía era un prototipo y que no estaba listo para que lo utilizaran los clientes. Si querían que estuviera listo para que los clientes lo usaran, podría hacer esos cambios con el tiempo suficiente, pero no tome las cosas "rápidas y sucias" y se las pase a los clientes. El hecho de que algo funcione no hace que sea una buena lección para aprender. Si bien dio un descargo de responsabilidad, hay algo que decir para darle un poco de respeto, de lo contrario, esto es lo que puede suceder.

No puedes arreglar estúpido. Si su jefe está haciendo cosas como usted describe, es poco probable que pueda cambiar eso. Especialmente si él no es el dueño; recuerde, tiene presión proveniente de la otra dirección, y esa dirección firma su cheque de pago. Lo mismo con tus otros compañeros de trabajo. El mejor primer curso de acción que puede tomar es adquirir el hábito de protegerse. Use técnicas como el cuadro de mensaje que describe. Guarde todos los correos electrónicos. Obtenga todo lo que pueda en forma escrita. De esta manera, no se lleva la peor parte cuando se produce la estupidez. Luego, a medida que asciende, instituya los cambios que desee con aquellos bajo su supervisión.

El otro día, un colega me contó una historia de una herramienta de prueba simple para permitir que un ingeniero en un laboratorio emita un solo comando a un widget y cambie una variable que vaya con el comando. Esto fue escrito hace 9 años, y lo último que supo, todavía está en uso hoy. Una herramienta que fue escrita en un par de horas con pruebas mínimas para demostrar, en el laboratorio, que algo funciona, fue la base de toda una herramienta de prueba de laboratorio de ingeniería. Una vez que escribe el código, existe. Si hace algo útil y lo ven otras personas, la gente va a quererlo. Si es bueno en lo que hace, la gente va a pedir que haga X. Lo siguiente que sabes es que tu herramienta simple es un componente importante.

Creo que la primera responsabilidad recae en el desarrollador de software para asegurarse de que cualquiera que mire el código o use la herramienta entienda que es un prototipo o no un sistema de producción y diga por qué ese es el caso. Parece que lo hiciste, sin embargo, tus compañeros de trabajo no cumplieron con esa responsabilidad. Para abordar esto, recomendaría hablar con ellos, reiterando que este no era un código de producción y que solo estaba escrito para facilitar su trabajo. Si lo encuentran útil, quizás ofrezca trabajar en la herramienta o ayudar a otras personas que trabajan en la herramienta para mejorarla y hacerla más adecuada para la producción.

En cuanto al proceso organizacional o la cultura de cambio, espere que tome un tiempo. Comience por dar un ejemplo. Si no has leído El programador pragmático , hazlo. Tome nota sobre consejos como Cuidar de su oficio, Ser un catalizador para el cambio (mostrar a las personas mejores formas), No vivir con ventanas rotas, Arreglar el problema, no la culpa. Parece que reconoce algunos problemas abordados por estos consejos, así que comience a trabajar y vivir un ejemplo para sus colegas.

Hasta que los tomadores de decisiones ya no toleren las consecuencias del código incorrecto y estén dispuestos a pagar / cambiar sus formas de solucionar el problema.

Estas son decisiones difíciles para las empresas pequeñas y en crecimiento. No saben dónde poner todos sus esfuerzos. Existe el riesgo de que el código sea demasiado robusto cuando las reglas comerciales y, a veces, líneas enteras de negocios aparecen, cambian y desaparecen durante la noche.

Esfuércese por escribir un buen código. Asegúrese de informar a todos sobre las consecuencias para que puedan tomar decisiones informadas. Si el código incorrecto se pone en producción, vigílelo si puede y continúe sugiriendo mejorarlo, especialmente si esa parte del negocio se vuelve crítica.

Hacer que la gente espere lo que ves como un código mínimamente viable parece estar más allá de sus expectativas actuales.

Señalaría que parte del problema aquí es que has escrito una herramienta rápida y sucia en primer lugar. De acuerdo, había buenas razones. Por supuesto, hizo el trabajo. Pero descubrí que cualquier cosa que resuelva un problema caerá en la trampa de una solución "suficientemente buena", si comienza a pasarla por alto.

Si su compañero lo quiere, cortésmente dígale que no es completamente funcional y que se queda con las llaves. Puedes ejecutarlo para él de vez en cuando. O bien, agregue la funcionalidad adicional, preferiblemente desde el comienzo del proyecto.

Todas mis herramientas rápidas y sucias en este punto provienen de un archivo esqueleto muy probado. Me permite comenzar rápidamente, me proporciona un punto de partida funcional y me permite olvidarme de agregar todos los bordes romos necesarios. No tengo que preocuparme por la biblioteca de getopts y sus peculiaridades. No necesito recordar detalles sobre la administración de memoria cuando uso Python. Cree el programa para que realice una tarea simple y solo una . Eso hace que sea fácil probar si están tratando de doblarlo.

Finalmente, aproveche la arquitectura de máquinas de estados finitos. Si sabe ir en todos los estados posibles, es mucho más fácil asegurarse de que, pase lo que pase, el usuario nunca pueda saltar las pistas. Tengo un programa que escribí para seguir este paradigma. Acepta archivos de entrada arbitrarios, que lee byte a byte. Incluso si el cliente le dijera que leyera un ejecutable binario, no tendría ningún problema. Como no encontraría ninguna de las cosas que estaba buscando, su búfer interno se llenaría. Eso haría que limpiara, cerrara e informara al usuario que necesita que lo mire.

Bueno, la respuesta no tiene mucho que ver con la programación, excepto que el software es bueno y es difícil juzgar fácilmente la calidad.

Es posible que no pueda cambiar la cultura, porque las personas pueden no tener un motivo real para no ser descuidado, porque las personas afectadas por la calidad del software no tienen mucho que ver con el proceso. Por ejemplo, a sus clientes se les puede pedir que compren y usen software para hacer su trabajo, pero tienen poco interés personal en la eficacia de ese software, porque no se les culpará personalmente por sus problemas ni se les recompensará por sus virtudes (en gran parte porque nadie sabe realmente si el software de la competencia sería mejor). Por lo tanto, es posible que solo tenga que cumplir con sus solicitudes de funciones sin demorar demasiado , pero no tener que preocuparse demasiado por si tiene errores. Entonces, todos pueden ser bastante descuidados sin consecuencias (para cualquiera que tome decisiones que lo afecten).

No sé si es así, pero si es así, puede ser difícil cambiar la cultura, ya que las personas que está tratando de cambiar no estarán mejor si lo hacen.

Si estarán mejor, puede que sea más fácil, ya que puede convencerlos potencialmente de por qué lo harán. Desafortunadamente, si no hubiera algún tipo de situación política que hiciera bien el descuido, probablemente no serían descuidados en primer lugar, por lo que es probable que sea difícil. Siempre puedes probar el argumento "algún día podrías tener un trabajo que requiera hacer las cosas bien" (quizás más diplomáticamente redactado ...)