La responsabilidad sin autoridad no tiene sentido: ¿una solución de base técnica?

Question

Mi papá siempre dice "La responsabilidad sin autoridad no tiene sentido".

Sin embargo, encuentro que como desarrolladores, nos quedamos atascados en situaciones en las que estamos:

• Responsable de garantizar que el software esté " libre de errores " ;, pero no tiene la autoridad para implementar un sistema de seguimiento de errores
• Responsable de cumplir los plazos del proyecto, pero no puede influir en los requisitos, la calidad o los recursos del equipo (las tres partes de la gestión del proyecto)
• etc.

Por supuesto, hay un montón de cosas que podrías decir para solucionar esto: encontrar un nuevo trabajo, pelear con el jefe, etc. ...

Pero ¿qué pasa con una solución técnica a este problema? Es decir, qué tipo de cosas de codificación puede hacer por su cuenta sin tener que convencer a un equipo para que corrija algunos de estos problemas, o qué tipo de herramientas puede usar para demostrar por qué los errores no rastreados le están haciendo daño , que los plazos se están perdiendo debido a problemas de calidad, y cómo puede usar estas herramientas para obtener más " autoridad " sin tener que ser el jefe?

---

*** Un ejemplo: el jefe se acerca a usted y le dice: "¿Por qué hay tantos errores?" - la mayoría de nosotros diríamos "No tenemos un buen sistema para rastrearlos", pero esto generalmente se ve como una excusa en mi experiencia. Entonces, ¿qué pasaría si pudiera señalar algún informe (a los gerentes les encantan los informes) y decir " Ver, esta es la razón " ;?

Answer 1

Todo lo que puede hacer es dar lo mejor de sí mismo, no sienta que la clave para un software exitoso está solo en sus manos, su parte de un equipo y no tiene que ser responsable de todo.

Obviamente, se encuentra en un entorno que afecta negativamente a su software, pero no puede cambiar todo su comportamiento, por lo que le recomiendo que comience con el suyo, comience a trabajar en equipo con sus propios errores, plazos, requisitos, calidad y recursos. no te preocupes por el resto del desastre, sino trata de ser el mejor en tu trabajo.

Trabajando como un equipo autodirigido de uno que le muestra a su jefe sus planes e informes de su progreso, solicitando más recursos cuando los necesita y mostrándole cómo se ven afectados sus planes cuando se los entrega o no.

Puede encontrar más consejos sobre esto en PSP y TSP artículos de wikipedia

Después de mostrarle a tu jefe un buen trabajo y cumplir con tus propios plazos, seguramente él confiará más en ti y dejará que algunas de tus ideas fluyan a todo el equipo.

Answer 2

No necesita un sistema de seguimiento de errores, necesita pruebas automatizadas: pruebas unitarias o de otro tipo. Puede configurar pruebas automatizadas con un Makefile. Siempre puede encontrar rutas bloqueadas por la administración, pero eso no significa que no haya cosas que pueda hacer dentro de las limitaciones de su trabajo. Por supuesto, la respuesta podría ser " buscar otro trabajo " Si no puedes encontrar otro trabajo ahora, aprende algunas habilidades para poder hacerlo.

Answer 3

La respuesta simple es: usted puede comenzar a utilizar las herramientas usted mismo.

Mejora tu propio trabajo. Si la gente quiere que corrijas el código, diles que presenten un error. Muéstrales cómo. Asegúrese de que puedan hacerlo sin instalar nada. ¿Quieren una actualización de estado? Diles que revisen el error. ¿Le piden un cambio de código que hizo? muéstreles cómo hacer una consulta del historial de control de origen. o simplemente muéstralas en tu caja. Comienza a mostrarles estas cosas funciona .

Y cuando necesite los mismos resultados que ellos, exija que hagan el trabajo de piernas. Cuando no pueda encontrar los cambios en su control de origen, pídales que comiencen a diferenciar sus revisiones manualmente de las cintas de respaldo. No hagas su trabajo, o el trabajo de control de fuente y seguimiento de errores, por ellos.

Y lo más importante, al aplicar esta presión de grupo, sé amable al respecto . Moscas y miel y todo.

Si no lo consiguen, puede seguir siendo el único desarrollador profesional en su empresa o grupo. O al menos ayudará a rellenar su currículum: 'experiencia en configurar e instruir a otros en CVS y FogBugs para mejorar la calidad del producto' y similares.

Answer 4

En cuanto a las herramientas específicas para demostrar que los errores no rastreados están dañando la capacidad del equipo para producir un código de calidad, tiene un catch-22 aquí ya que necesita algo para rastrear los errores antes de poder mostrar su efecto. No puedes medir lo que no puedes rastrear. Entonces, ¿qué hacer?

Como ejemplo análogo, recientemente hicimos que un chico se uniera a nuestro equipo que sentía que la forma en que hacíamos las revisiones de código por correo electrónico era absurda. Entonces, encontró una herramienta de código abierto, la instaló en su caja, consiguió que algunos de los miembros de nuestro equipo de mente abierta lo probaran por un tiempo y luego se lo mostraran al líder de nuestro equipo. En pocas semanas tuvo la oportunidad de mostrarlo a todos nuestros equipos. El nuevo tipo estaba influyendo en toda la empresa. He escuchado muchas historias sobre esta adopción de herramientas de estilo guerrillero.

El truco consiste en identificar quién tiene la autoridad para tomar la decisión, descubrir qué valoran y recopilar pruebas suficientes de que lo que se quiere implementar les dará lo que valoran.

Para una visión más amplia de cómo liderar desde la mitad o la parte inferior de una organización, consulte The 360 ??Degree Leader de John Maxwell.

Answer 5

Si desea un informe sobre la calidad y su impacto en la productividad, aquí está el mejor: http://itprojectguide.blogspot.com/2008/ 11 / caper-jones-2008-software-quality.html Caper Jones tiene algunos libros y todavía se presenta en las conferencias. Fuera de un buen IDE, un desarrollador / grupo de TI necesita control de código fuente (VSS, SubVersion, etc.) y seguimiento de problemas

Answer 6

Si se le pide a un contador que produzca un conjunto de cuentas sin usar doble entrada y no balancear, nadie esperaría que el contador lo haga.

Sin embargo, la entrada doble ha sido utilizada por los contadores desde el siglo XIII.

Pasará mucho tiempo antes de que, como profesión, tengamos una práctica estándar tan arraigada que uno pueda trabajar sin ellas.

Entonces, lo siento, espero que tengamos que enfrentar este tipo de problema durante muchos años por venir.

Answer 7

Lo siento por no responder a tu pregunta directamente, pero ...

Creo firmemente que el fracaso al que se refiere es uno de comunicación, y nos corresponde a nosotros como profesionales desarrollar nuestras habilidades de comunicación hasta el punto en que seamos lo suficientemente respetados y confiables para aprovechar la autoridad que necesitamos para mejorar nuestro trabajo Entornos y procesos de la forma que sugieras.

En resumen, no creo que haya una solución técnica que pueda resolver todos los problemas creados a través de una comunicación deficiente en el lugar de trabajo.

En todo caso, la tecnología ha provocado el desgaste de la comunicación directa cara a cara.

Lo siento, estoy en una tangente de nuevo, siéntase libre de bajar.

Answer 8

Codificando solo usted solo puede mantener sus propios archivos fuente ordenados, bien comentados, mantenga el recuento de errores bajo con las pruebas. Pero va a necesitar herramientas externas para rastrear el progreso y los errores (bugzilla, yoxel, trac, gantt diagram tools, Mylyn para Eclipse, un blog, lo que sea). En estos casos, las personas y la disciplina y los buenos hábitos y el liderazgo son la fuerza abrumadora, no hay herramientas de software y ninguna ofensa del individuo puede ganar solo.