Consulting y Joel Test

Question

El Joel Test suena como una lista de atributos con los que me gustaría trabajar (¿y no para la mayoría de nosotros?) Pero en un contexto de consulta, puede variar mucho. Me han dicho que depende del cliente, que en algunos casos ni siquiera tiene control de fuente (egad!)

¿Está justificado rechazar un trabajo de consultoría en base al puntaje de prueba Joel potencialmente bajo en algunas situaciones? ?

Además, ¿cómo podría remediarse un bajo puntaje de Joel Test? ¿Es factible el control de versiones on-the-go (supongamos que lo tiene en una computadora portátil que trae en cada trabajo)? ¿Sería eso aceptado en todas partes? Ideas? Anécdotas?

(haciendo de esta una wiki de la comunidad desde el primer momento, ya que es obviamente muy subjetiva)

Answer 1

Usted es libre de rechazar todos los trabajos de consultoría que no pasan la prueba de Joel.

También eres libre de morir de hambre.

Elija uno.

Answer 2

La mayoría de los trabajos que tuve que completaron 8+ de estas pruebas no tuvieron necesidad de consultores.

Los clientes (de mis años de consultor) o no tienen necesidad de los 12 (contrato rápido) no están interesados ​​("Le pago código, así que codifique") o si su suerte estará feliz de escuchar y ayudar traes un sistema así y deberías tener una oferta permanente de trabajo cerca del final.

Lo mejor de ser un consultor es poder elegir con quién trabajar. La razón número 1 para rechazar otro contrato con un cliente es la forma en que me trató anteriormente, y eso incluye cómo puedo aplicar buenas prácticas de codificación. Adivina a quién culpar cuando todo se apresura sin especificaciones, pruebas mínimas y software de desarrollo beta y pirateado. Al principio genera más trabajo (llamadas de soporte), pero el cliente pronto se queja de cómo las cosas nunca se terminan.

Answer 3

La prueba de Joel aproximadamente califica la calidad de un equipo equipo. Puede hacer cosas como individuo para tratar de elevar un puntaje de prueba bajo, pero eso no cambiará los problemas básicos endémicos de un equipo en particular. Si un equipo de software no utiliza el control de fuente, puede estar absolutamente seguro de que van a ser seriamente disfuncionales en muchas otras formas.

En primer lugar, muchas compañías que necesitan contratar consultores no van a obtener exactamente una puntuación alta en Joel Test. Dicho esto, como consultor, puede encontrarse en una buena posición para influir positivamente en ese equipo: podría ser la persona que instale SVN o git en algún lugar y convenza a todos para que lo utilicen. A veces, un equipo malo solo necesita a alguien con nuevas ideas para ayudar a mejorar las cosas.

Tienes que decidir por ti mismo dónde trazarás la línea en Joel Test. Personalmente, quisiera NUNCA aceptar un trabajo en un lugar sin control de fuente a menos que estuvieran literalmente descargando camiones cargados de efectivo en la puerta de mi casa, e incluso entonces podría pensarlo dos veces. Simplemente no vale la pena el estrés.

Answer 4

En más de 30 años de consultoría, casi ninguno de mis clientes ha obtenido más de 1 o 2 en la prueba Joel. Algunos puntuaron en los 8 altos, pero esos fueron la excepción, no la regla.

"¿Está justificado rechazar un trabajo de consultoría en función de un puntaje de prueba de Joel potencialmente bajo en algunas situaciones? "

Puede bajar cualquier cosa que desee por cualquier motivo desea. Nadie se preocupa por la justificación.

serio. Eres opinión no cuenta para nada.

Los clientes que están desesperado por personal no se preocupará por qué que los rechazó. Su rechazo no dará lugar a la repentina crisis moral en la que replantearse sus errores.

Su opinión de sus prácticas de desarrollo no importa en absoluto. Su razón de giro ellos abajo hacen no es importante No necesita "justificar" nada.

De hecho, generalmente se reirán si explica por qué los rechazó. Saben que lo que están haciendo es el mejor nivel bajo sus circunstancias. Saben absolutamente que no pueden, por ejemplo, usar el control de código fuente porque no tienen el tiempo o el presupuesto o espacio en el servidor o alguna otra excusa ridícula.

Puede indicarlo todo lo que desee. Por lo general, no les importará. No les importa, ya que saben que lo que están haciendo ya es ideal bajo sus circunstancias únicas.

"Además, ¿cómo podría remediarse una puntuación baja Test de Joel?"

No puede ser. Una cultura que funciona mal, continuará teniendo un bajo rendimiento hasta que se realicen cambios significativos en la estructura de la cultura y la recompensa.

Una forma de efectuar el cambio es trabajar y hacer que el caso dentro de la organización sea que las cosas podrían ser mejores. Si tiene éxito, algunas personas pueden tratar de emular lo que está haciendo que sea exitoso. Rechazarlas no demuestra prácticas exitosas de desarrollo de software.

"está en la marcha de control de versiones factible?"

Sí.

Tengo una computadora portátil que traigo en cada trabajo.

"¿Sería eso aceptado en todas partes?"

Mayormente. Algunas ubicaciones se ponen nerviosas cuando los consultores traen dispositivos "externos". También se quejan de que los dispositivos de grabación de video y sonido están estrictamente prohibidos, sin embargo, se permiten iPhones. Por lo tanto, si quieren crear problemas para usted, pueden hacerlo.

Algunos lugares no le permiten crear código en su computadora portátil. Algunos te dejarán.

Answer 5

Esto es similar a las preguntas de los empleados directos acerca de la introducción de un mejor proceso (o mejor agilidad) en un entorno en el que no se ha aceptado la gestión.

Creo que es más fácil mejorar las cosas por sí mismos sin comprar en la administración si el problema es negligencia benigna ("Control de fuente, ¿qué es eso?") Y sabotaje no activo ("No pagaré un centavo en ningún momento gastado en seguimiento de errores, control de fuente, pruebas unitarias o automatización de compilación! ")

Se pueden realizar algunas mejoras del proceso. Ejecute un rastreador de problemas y subversión en su propia máquina y realice un seguimiento de su propio trabajo.Utilice aplicaciones portátiles como XAMPP para alojar Apache y cualquier rastreador de fallos de php si lo necesita, o un rastreador de errores accesible a través de Internet y un host de código fuente si el cliente no lo está prohibiendo específicamente. Si no superan la prueba de Joel, no tienen ni idea de lo que es capaz de administrarle, por lo que debe tener la flexibilidad para automatizar su compilación, utilizando TeamCity o Luntbuild si no hay dinero en el contrato. para herramientas. La mayoría de los clientes quieren que los desarrolladores estén en el entorno más ruidoso posible, así que invierta en buenos auriculares, algunos auriculares pueden bloquear hasta 20 decibelios de ruido de fondo.

Incluso Joel (en uno de los podcasts de SO) ha dicho que las especificaciones como herramienta de comunicación prometen más de lo que pueden ofrecer. Si el cliente está fallando en todo excepto en tener una especificación, entonces tampoco confiaría en que sus especificaciones sean útiles. Puede codificar según la especificación, pero eso no los hará felices porque a un cliente sofisticado le exige saber en detalle qué es lo que quieren al comprar un software personalizado. Un contratista siempre puede optar por escribir una especificación, es solo cuestión de tiempo y podrá facturarla.

El resto de los elementos de prueba Joel son problemas de gestión que la iniciativa individual (ya sea un contratista o contratación directa) no puede influir (aparte de una recomendación no vinculante): presupuesto, proceso de entrevista, diseño de la oficina, quién disponible para pruebas, etc.