Consulting y Joel Test

Joel Test suena como una list de attributes con los que me gustaría trabajar (¿y no es así para la mayoría de nosotros?) Pero en un context 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 sobre la base de una puntuación de Joel Test potencialmente baja 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 esto una wiki comunitaria desde el principio, ya que obviamente es muy subjetiva)

Puede rechazar todos los trabajos de consultoría que no superen el Test Joel.

También eres libre de morir de hambre.

Elegir uno.

En más de 30 años de consultoría, casi ninguno de mis clientes obtuvo más de 1 o 2 en Joel Test. Algunos puntuaron en los 8 altos, pero esos fueron la exception, no la regla.

" ¿Está justificado rechazar un trabajo de consultoría sobre la base de una puntuación de Joel Test potencialmente baja en algunas situaciones? "

Puede rechazar cualquier cosa que quiera por el motivo que desee. A nadie le importa la justificación.

Seriamente. Tu opinión no count para nada.

A los clientes que están desesperados por el personal no les importará por qué los rechazaste. Su rechazo no conducirá a una crisis moral repentina en la que reconsideren sus errores.

Tu opinión sobre sus prácticas de desarrollo no importa en absoluto. Tu razón para rechazarlos no importa. No necesita "justificar" nada.

De hecho, generalmente se reirán si explicas por qué los rechazaste. 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 time o el presupuesto o espacio en el server o alguna otra excusa ridícula.

Puedes señalar todo lo que quieras. 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 un bajo puntaje de Joel Test? "

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

Una forma de lograr el cambio es trabajar y presentar el caso desde el interior de la organización de 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.

" ¿Es factible el control de la versión on-the-go? "

Sí.

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

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

Principalmente. 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 permitirán crear código en su computadora portátil. Algunos te dejarán.

La Prueba Joel califica aproximadamente la calidad de un equipo de software. Puede hacer cosas como individuo para tratar de elevar un puntaje de testing 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 forms.

En primer lugar, muchas compañías que necesitan contratar consultores no van a get una puntuación alta en Joel Test. Dicho esto, como consultor, puede encontrarse en una buena position 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 el Test Joel. Personalmente, NUNCA aceptaba un trabajo en un lugar sin control de fuente a less que literalmente estuvieran descargando camiones llenos de efectivo en la puerta de mi casa, e incluso entonces podría pensarlo dos veces. Simplemente no vale la pena el estrés.

La mayoría de los trabajos que tenía que llenaban más de 8 de estas testings no necesitaban consultores.

Los clientes (de mis años de consultor) o no tienen necesidad de los 12 (contrato rápido) no están interesados ​​("Te pago código, así que codifica") o si tu suerte estará feliz de escuchar y ayudarte a traer tal sistema arriba, y debe tener una oferta de trabajo permanente 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 encoding. Adivina a quién culpar cuando todo se apresura sin especificaciones, testings 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.

Esto es similar a las preguntas de los empleados directos acerca de la introducción de un mejor process (o mejor agilidad) en un entorno en el que no se tiene acceso a la administración.

Creo que es más fácil mejorar las cosas por sí mismos sin que la gerencia acepte si el problema es negligencia benigna ("Control de fuente, ¿qué es eso?") Y no sabotaje activo ("No pagaré ni un centavo por el time dedicado al seguimiento de errores" , control de fuente, testings unitarias o automation de compilation! ")

Algunas mejoras al process pueden hacerse por count propia. 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 testing de Joel, no tienen ni idea de lo que es capaz de administrarle, por lo que debe tener la flexibilidad para automatizar su compilation, 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 background.

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 time y podrá facturarla.

El rest de los ítems de testing de Joel son problemas de gestión que la iniciativa individual (ya sea contratista o contratación directa) no puede influir (aparte de una recomendación no binding): presupuesto, process de entrevista, layout de la oficina, quién está disponible para las testings, etc.