jueves, 31 de octubre de 2013

Acercarnos al negocio (back-office)







En post anteriores se mencionó varias veces el tema de acercarnos al negocio y su relación con la calidad. ¿Pero qué significa y cómo se hace?

Básicamente es entender cómo gana plata la compañía, qué la hace crecer, etc.

El negocio final de la Compañía puede estar cerca o lejos de los productos de software, nuestros productos pueden ser el back-office del negocio, uno de los canales de venta o el negocio mismo de la compañía. Los escenarios no son excluyentes. En otra entrada veremos aquellas compañías cuyo negocio es desarrollar software para terceros.

Comencemos por el primer caso.

La finalidad de la empresa: no está relacionada con el software. (ej. Una maderera) y nuestros productos de software soportan la operación del negocio (back-office).

Los requerimientos: conocidos, pueden estar especificados con cierta precisión.

Los usuarios: conocidos, incluidos en sectores / jerarquías, su demanda de información se conforma por niveles, es decir los niveles de más abajo registran las operaciones y la información se condensa para los usuarios de la capa superior. Pueden tener herramientas de apoyo, pero están cautivos del sistema que les construimos o adquirimos.

Los modelos de trabajo: tradicionales de desarrollo de software y administración de proyectos funcionan correctamente en este entorno.

La calidad: en este contexto significa cumplir con los requerimientos predefinidos del producto y del proyecto.

Acercarnos al negocio: es entenderlo, conocer las novedades tecnológicas de nuestra especialidad para mejorar el negocio, ayudar a la empresa a adquirir el sistema más adecuado técnicamente para su fin (desarrollo o enlatado),  soportarlo y administrar la tecnología.

Contexto: complicado pero ordenado.


Para una explicación más amplia de estos contextos ver http://ideassobresoftware.blogspot.com.ar/2013/09/todavia-quiere-seguir-jugando.html 

miércoles, 30 de octubre de 2013

Fotocopiadoras, calidad y negocio


La calidad sin entender ni ayudar directamente al negocio es sólo un  ejercicio intelectual que finalmente terminará por ser abandonado.

¿Cuántos proyectos de “mejora” se abandonan, se olvidan o simplemente se ignoran?
Difícil saber el número pero seguramente son más de los que terminan con éxito.

Evitando ser negativos veamos entonces los que concluyen exitosamente y se sostienen en el tiempo (como en todo lo importante no sólo es llegar sino mantenerse).

La calidad por la calidad misma es algo vacío. Puede ser de interés intelectual, pero de poca utilidad para la empresa. Podremos sobrevivir un tiempo, pero finalmente alguien pensará: ¿Por qué estamos gastando en eso? (“eso” es nuestra mejora) y nuestro presupuesto desaparecerá para ser reasignado a otras áreas.

¿Pero por qué ocurre esto? No les interesa la calidad (la excusa más fácil que tenemos a mano).

No creo que sea eso, que no les interese, simplemente no logran conectar nuestra propuesta de calidad con el negocio de la Compañía.
Entonces, excepto que la mejora, certificación o como sea que se corporice sirva para lograr un beneficio (por ejemplo una subvención, baja de impuestos, ingresar en mercados donde no nos conocen y el certificado/evaluación es requisito, etc.) caso en el cual ayuda al negocio, difícilmente se mantendrá. Es un gasto, por lo tanto tratará de reducirse.
Podríamos seguir pero creo que quedó claro.

¿Cuál es entonces el camino para que realmente un movimiento de calidad se instale y permanezca en la Organización?

Mi respuesta es: entendiendo el negocio en el que estamos (no siempre todos en la empresa lo tienen en claro) y diseñar las acciones de calidad para ayudar a ese negocio.
Podemos tomar modelos pre-hechos y  adecuarlos (CMMI, ISO 9000, ISO 25000 y otros) o desarrollar  algo propio siguiendo la idea de calidad que el negocio necesita.
Pero siempre, al menos en este razonamiento, el negocio está primero y la calidad es la que requiere para competir.

Finalmente la parte dura. Nosotros o nuestro sector seremos reemplazables cuando lo que ofrecemos es lo mismo que ofrece un tercero (y hasta posiblemente más barato), pero difícilmente nos podrán reemplazar si formamos parte del negocio, lo entendemos y lo ayudamos.
Pero eso hay que ganarlo, si seguimos encerrados en nuestra zona de confort técnica y pensando que la responsabilidad del negocio es de otro y no nuestra, finalmente nos van a reemplazar.

Que lo del reemplazo está lejos, puede ser, la fotocopiadora parecía y fue un excelente negocio durante bastante tiempo. Pero hoy, ¿invertiríamos en un negocio de fotocopiadoras?
               
Saludos,
Raúl

TW: @RaulMartinez582

martes, 29 de octubre de 2013

Calidad no es testing, ni procesos, ni certificaciones


Calidad no es testing, ni procesos, ni certificaciones, es más. Es ser competitivos, en aquello que nos hará crecer. 

Parece obvio recordarlo pero calidad no es ninguna de las tres cosas enumeradas, posiblemente porque tenga que ver más con las expectativas que con los requerimientos. 

El testing nos permitirá, sobre el entregable en prueba, comprobar si este cumple o no un requerimiento. Los procesos nos dirán cuál es la mejor forma, o la más adecuada para mi organización de realizar una actividad y las certificaciones nos permitirán conocer y en algunos casos ayudarnos a aplicar buenas/mejores prácticas para llevar adelante una disciplina determinada. 

Pero una expectativa es creer o sentir que algo resultará o se comportará de una manera determinada. Difícil de moldear como requerimiento ya que es algo asociado a las personas y sus emociones. 

Ahora bien, la calidad es en gran medida percibida a través de expectativas, una de ellas es que el producto/servicio cumpla los requerimientos, pero es eso, sólo una. 

Cumplir entonces los requerimientos nos hará crecer hasta un punto, podemos llamarlo hasta lo estándar. Pero ser competitivos implica pasar ese punto y sobresalir entre los iguales.

Saludos,
Raúl
@RaulMartinez582

viernes, 18 de octubre de 2013

La prueba y el contexto del producto

Más allá de los procesos y los aspectos técnicos de la prueba de un producto de software (planificar o no, escribir o no casos de prueba, a qué nivel de detalle, tipos de prueba que conviene realizar, ambientes, herramientas, buenas prácticas, modelos de calidad, …), están los equipos de trabajo que llevan adelante estas actividades. Las personas que los forman. Sus intereses y expectativas. Sus conocimientos. Su sentido ético y profesional. Podríamos seguir la lista.

Quedarse sólo a este nivel pensando que la prueba del software es meramente algo técnico y repetitivo que hace un equipo de trabajo, nos hace perder de vista muchos aspectos del contexto que impactan en la calidad del producto de software percibida o “vivida” por los interesados.
Puede conducir al fracaso del producto cuando es recibido por ellos, o a su éxito.
Las expectativas de los interesados se satisfarán o se frustrarán. 
Los requerimientos explícitos e implícitos estarán cumplidos o no, probados o no, se irán corrigiendo los defectos remanentes y evolucionando el producto según nuevos requerimientos aparezcan o se detecten otras necesidades o tendencias, o aparezcan nuevas tecnologías.


Y los interesados son muchos, diversos, internos o externos a las organizaciones que construyen o proveen el producto de software, conocidos o desconocidos, sujetos a control respecto a la forma en que interactúan con el producto o no, interrelacionados de alguna forma, simple o compleja, … 

Los productos (tanto tangibles como intangibles), además de ser de diferentes tipos, se utilizan de diversas maneras, en diferentes ambientes y lugares, por diferentes personas.
Los productos de software actualmente se ejecutan en plataformas complejas, se interconectan, y se regulan en muchos casos.

Los productos existen porque brindan algún valor, son parte de algún servicio que los contiene, o incluso son el centro del servicio.
Por ejemplo, escribimos con un lápiz, pero también podemos hacerlo con otros productos; podemos elegir y cambiar, según el valor que nos brinde el producto en un contexto dado, como el material sobre el que queremos escribir, en qué color, cuán permanente queremos que sea lo escrito, qué tenemos a mano en el momento en que queremos escribir.
El valor es percibido o no por los diversos interesados, a lo largo de su construcción y su vida útil, y el servicio tiene también evolución, aspectos de calidad, y hasta posibilidades de desaparecer la necesidad que le dio origen.
Los productos pueden contribuir a reducir los riesgos o preocupaciones de los interesados, o a su éxito en algún aspecto. O no aportar valor en esos sentidos.

También la cultura de las organizaciones en que los productos y servicios se construyen y/o se brindan, ocupa un lugar preponderante en el contexto del producto y el servicio. Y su facilidad o aversión a encarar cambios de ser conveniente, respecto a la calidad, la fluidez del conocimiento, la estructura, procesos, herramientas, valoración de su personal, entre otros aspectos. ¿Está realmente la organización dispuesta a mejorar la calidad para ser más exitosa? ¿Querrá transmitir a su gente qué es lo que aporta valor al negocio, y cuándo lo está perdiendo? ¿Querrá analizar por qué y emprender un camino de cambios?

¿Tenemos posibilidades de aportar como testers algún valor al negocio sugiriendo pequeños cambios que muestren beneficios en el corto plazo? ¿Estamos dispuestos a hacerlo saliendo de nuestra zona de confort técnica?

Los aspectos más relevantes en el contexto de la calidad del producto de software mencionados están resumidos en este gráfico:



Pero vayamos otra vez a lo técnico. ¿Y con la prueba qué hacemos?

Fundamentalmente, no olvidar que todo ese contexto existe. Si no lo consideramos, pueden quedar aspectos importantes no cubiertos por las pruebas, aunque hayamos pensado, elaborado, ejecutado y/o automatizado cientos de casos de prueba. La identificación de amenazas y riesgos del producto quedará incompleta. La utilización del producto más allá de su construcción podrá tener defectos más o menos fáciles de corregir, pero lo que es más grave, no habremos brindado un buen servicio: proveer a los interesados información valiosa para tomar decisiones respecto al producto de software.  

Las pruebas exploratorias y las planificadas, en cualquier tipo de proceso, pueden alimentarse del contexto para elaborar las ideas y estrategias de prueba. Independiente de nuestra misión específica respecto a un producto dado.

Considerar el contexto nos permitirá brindar un servicio de testing valioso y perdurable, que nos motive a seguir brindándolo, y que motive a nuestros clientes, internos o externos, a seguir comprándolo.

También nos dará la satisfacción de haber contribuido no sólo a elaborar un producto estándar o bueno, sino que deleite.