Como cuidarse de los desarrolladores (por uno mismo)
Hace unos dias en una charla de horas (cerveza por medio) con otro amigo desarrollador, nos pusimos a ver los problemas del "desarrollo", intentamos definir culpables, culpas, motivos, orígenes, problemas comunes para intentar entender el "porque pasa lo que pasa"...
Fue una charla laaaarga, y me quedaron algunas ideas, que quizas le puedan servir a otros.
El desarrollo de un producto para una pequeña empresa, es una misión muy cumplicada, siempre genera muertos y ademas de ser bueno codeando, es que debes ser bueno en gestion, comunicación, análisis de las personas, temas legales, etc.
* Un desarrollo siempre se extenderá en tiempo, por diversas razones, si eres desarrollador deja claro que "no hay fecha de FIN".
* Si contratarás a un desarrollador, define una fecha, no puedes estar años esperando que acabe lo que prometió. Al menos el 99% de lo que necesitas a diario.
* Intenta poner en papel las limites del desarrollo, siempre te pediran mucho mas, y al final no acabas nada. Si piden mas, pon claro el tiempo "adicional" y el costo "asociado".
* Intenta poner en papel lo que quieres. Asi le simplificas las cosas. Intenta limitarte en todo lo que necesitas, si necesitas mas funciones, piensa que deberas pagarlas y aumento el tiempo de desarrollo.
* Trata de no firmar ningún papel, porque se lo considerará un contrato privado y está regulado por ley.
* Trata de hacer un contrato si quieres que vea que vas en serio y que no quieres perder el tiempo con chapuzas.
* Haz una demo para mostrar la interfaz, metodos, formas, colores, ideas. Así el cliente entiende "el que".
* Mira con detenimiento la demo, fíjate que te parece el producto, si es serio, intenta meter cualquier dato para ver si falla. Úsalo varios dias. Piensa que es como comprar un coche, no es para unos dias.
* Si tienes dudas de que no te pagará, intenta no tenerlo como cliente. Piensalo bien antes de poner una bomba de tiempo en el soft. Si crees que la vas a usar, es que va todo mal... No sigas.
* Intenta pedir un contrato indicando las condiciones de uso, pon metas en tiempo para ir pagando por partes, de ser posible el ultimo pago de 50%... Un soft a medio acabar, no sirve para nada.
* Si tienes dudas, haz un contrato, pero cuidado, tiene doble filo.
* Si tienes dudas, pide un contrato, podras asustarlo o demandarlo si no cumple.
* Todo desarrollo requerirá trabajo de mantenimiento, que puede darte dinero, trabaja seriamente.
* Todo desarrollo requiere mantenimiento, piensa que ademas del desarrollo pagarás mas dinero para que todo siga funcionando bien.
* No creas que el desarrollo que harás lo podras vender 100 veces... es mentira. Con suerte unas pocas.
* Piensa que tu desarrollo será para tí. No pidas precios de productos enlatados, tu producto es único. adaptado a tus necesidares.
* Mira los demas productos similares, busca las ventajas, mejoras, compara.
* Mira productos similares a lo que quieres, piensa lo que necesitarás, recuerda que un programa no es "maravilloso" por tener miles de opciones, sinó, porque las que necesitas a diario, las tienes.
* Intenta trabajar en equipo, dos o tres personas es suficiente.
* Intenta identificar el responsable y fijalo como persona referente, si hay uno o 20 detrás no es tu problema. Siempre ten el mismo interlocutor.
* No aceptes peticiones de cualquier persona de la empresa. Deben venir de la persona que coordina el desarrollo y por escrito. Identifica si son bugs/areglos o mejoras/peticiones nuevas.
* Intenta fijar un canal de comunicacion en tu empresa, si tu eres el comprador y gestor, obliga a que te informen a ti. Todo debe ir escrito. Ya sabes eso de "las palabras se las lleva el viento"
* Controla el tiempo de desarrollo, eso de "en 6 meses lo tengo", representa 6 x 30 dias = 180 dias x 24 hs IGUAL 4320 horas de trabajo... pero todos sabemos que trabajaras unas horas por dia, 4320 / 4 hs = 1080 dias. (3 años)
* Indica claramente que tu buscas una solución parcial/total para el dia XX-XX-XXXX (indica el año tambien), que haga lo que quiera con su tiempo, tu problema es el producto. Fija metas semanales y mide el avance, en unas pocas semanas verás si cumplirá (seguramente no) y el porcentaje de desviación en tiempo. (del 1% a 3000 %)
Puedes poner penalizaciones (en dinero) por retrasos.
* Ten cuidado con lo que dices y escribes, la penalizacion puede ser que hayas trabajado mucho, cobrado poco y que pierdas cliente, o hasta que tengas una demanda.
* Intenta hablar y negociar antes de la penalizaciones, si necesitas usarlas, es mala señal, y seguramente todo acabará mal. Recuerda que el tiempo es un recurso finito y que no tiene UNDO.
* Intenta probar el producto con grandes volúmenes de datos, las pruebas deben exigir y buscar el colapso. No son solamente para verificar el tipo de datos.
* Intenta exigir pruebas escritas y volúmenes de carga mínimos, todo aplicativo funciona bien para 100 registros. Mide los volúmenes que tendras.
* Controla muy bien tu tiempo y tus gastos. Lo que haces es un negocio, no eres una ONG, pero tampoco eres un casino.
* Define el valor monetario del producto, intenta NO PAGAR lo minimo posible, seguramente tendras mala calidad del producto final. Y generaras mala relacion con el desarrollador.
* Intenta ser equilibrado en las peticiones, no puedes decir SI a todo, pero tampoco NO a todo. Mide seriamente cada pedido, en horas y dinero.
* Intenta no modificar las peticiones originales, para ti agregar cosas te parece facil, pero puedes alterar el modelo de datos y habra muchisimos cambios.
* Prueba todo muchas veces, eso de "ya lo probe" no vale, tocar codigo, puede alterar partes que venian funcionando bien, intenta que lo pruebe alguien que no sea desarrollador, verificará muchas cosas, pregunta si entiende que tiene que poner en cada lugar.
* Prueba todo muchas veces antes de ponerlo en producción, es un viaje de ida, luego no puede decir "son demasiados problemas, no lo quiero usar mas"
* Recuerdo que los datos son el 90% del producto, no pierdas un solo dato, no cambies nada en produccion, no "cocines" datos, muestra un excesivo respeto por la información del cliente, arma lotes de pruebas (grandes) con datos demos. Las pruebas NO SE HACEN en produccion.
* Recuerda que los datos son el 99% de tu producto. Exige controles, backups, recoverys, mediciones de crecimiento, garantias de privacidad, exige privacidad y respeto por la informacion.
* Lee muy bien los contratos de "non-disclosure". De ser posible con tu asesor legal.
* Si tu información es muy sencible, tienes datos de personas, lee las leyes de privacidad, normativa de confidencialidad y SIEMPRE exige un contrato "non disclosure" y que se respete la normativa vigente, y pon todo por escrito.
* Informa de una casilla de correo y un teléfono para contactarte, que sean comerciales y fija horarios de servicio. Tu no trabajas 24 hs unicamente para el.
* Solicita telefono, email y pacta un servicio de mantenimiento y atención telefónica. Evalúa cuando tienes problemas, cuantas veces, en que partes y tambien si es por errores del programa o por terceros.
* Los bugs los deben arreglar sin cobrarlos, se un profesional, acepta tu error, documento y arregla y nada de pedir mas dinero.
* Los bugs los debe arreglar y NUNCA debes pagar por ellos. Diferencia bugs de cambios.
Esto es solo la punta del iceberg.... el tema da para escribir varios libros.
Fue una charla laaaarga, y me quedaron algunas ideas, que quizas le puedan servir a otros.
El desarrollo de un producto para una pequeña empresa, es una misión muy cumplicada, siempre genera muertos y ademas de ser bueno codeando, es que debes ser bueno en gestion, comunicación, análisis de las personas, temas legales, etc.
* Un desarrollo siempre se extenderá en tiempo, por diversas razones, si eres desarrollador deja claro que "no hay fecha de FIN".
* Si contratarás a un desarrollador, define una fecha, no puedes estar años esperando que acabe lo que prometió. Al menos el 99% de lo que necesitas a diario.
* Intenta poner en papel las limites del desarrollo, siempre te pediran mucho mas, y al final no acabas nada. Si piden mas, pon claro el tiempo "adicional" y el costo "asociado".
* Intenta poner en papel lo que quieres. Asi le simplificas las cosas. Intenta limitarte en todo lo que necesitas, si necesitas mas funciones, piensa que deberas pagarlas y aumento el tiempo de desarrollo.
* Trata de no firmar ningún papel, porque se lo considerará un contrato privado y está regulado por ley.
* Trata de hacer un contrato si quieres que vea que vas en serio y que no quieres perder el tiempo con chapuzas.
* Haz una demo para mostrar la interfaz, metodos, formas, colores, ideas. Así el cliente entiende "el que".
* Mira con detenimiento la demo, fíjate que te parece el producto, si es serio, intenta meter cualquier dato para ver si falla. Úsalo varios dias. Piensa que es como comprar un coche, no es para unos dias.
* Si tienes dudas de que no te pagará, intenta no tenerlo como cliente. Piensalo bien antes de poner una bomba de tiempo en el soft. Si crees que la vas a usar, es que va todo mal... No sigas.
* Intenta pedir un contrato indicando las condiciones de uso, pon metas en tiempo para ir pagando por partes, de ser posible el ultimo pago de 50%... Un soft a medio acabar, no sirve para nada.
* Si tienes dudas, haz un contrato, pero cuidado, tiene doble filo.
* Si tienes dudas, pide un contrato, podras asustarlo o demandarlo si no cumple.
* Todo desarrollo requerirá trabajo de mantenimiento, que puede darte dinero, trabaja seriamente.
* Todo desarrollo requiere mantenimiento, piensa que ademas del desarrollo pagarás mas dinero para que todo siga funcionando bien.
* No creas que el desarrollo que harás lo podras vender 100 veces... es mentira. Con suerte unas pocas.
* Piensa que tu desarrollo será para tí. No pidas precios de productos enlatados, tu producto es único. adaptado a tus necesidares.
* Mira los demas productos similares, busca las ventajas, mejoras, compara.
* Mira productos similares a lo que quieres, piensa lo que necesitarás, recuerda que un programa no es "maravilloso" por tener miles de opciones, sinó, porque las que necesitas a diario, las tienes.
* Intenta trabajar en equipo, dos o tres personas es suficiente.
* Intenta identificar el responsable y fijalo como persona referente, si hay uno o 20 detrás no es tu problema. Siempre ten el mismo interlocutor.
* No aceptes peticiones de cualquier persona de la empresa. Deben venir de la persona que coordina el desarrollo y por escrito. Identifica si son bugs/areglos o mejoras/peticiones nuevas.
* Intenta fijar un canal de comunicacion en tu empresa, si tu eres el comprador y gestor, obliga a que te informen a ti. Todo debe ir escrito. Ya sabes eso de "las palabras se las lleva el viento"
* Controla el tiempo de desarrollo, eso de "en 6 meses lo tengo", representa 6 x 30 dias = 180 dias x 24 hs IGUAL 4320 horas de trabajo... pero todos sabemos que trabajaras unas horas por dia, 4320 / 4 hs = 1080 dias. (3 años)
* Indica claramente que tu buscas una solución parcial/total para el dia XX-XX-XXXX (indica el año tambien), que haga lo que quiera con su tiempo, tu problema es el producto. Fija metas semanales y mide el avance, en unas pocas semanas verás si cumplirá (seguramente no) y el porcentaje de desviación en tiempo. (del 1% a 3000 %)
Puedes poner penalizaciones (en dinero) por retrasos.
* Ten cuidado con lo que dices y escribes, la penalizacion puede ser que hayas trabajado mucho, cobrado poco y que pierdas cliente, o hasta que tengas una demanda.
* Intenta hablar y negociar antes de la penalizaciones, si necesitas usarlas, es mala señal, y seguramente todo acabará mal. Recuerda que el tiempo es un recurso finito y que no tiene UNDO.
* Intenta probar el producto con grandes volúmenes de datos, las pruebas deben exigir y buscar el colapso. No son solamente para verificar el tipo de datos.
* Intenta exigir pruebas escritas y volúmenes de carga mínimos, todo aplicativo funciona bien para 100 registros. Mide los volúmenes que tendras.
* Controla muy bien tu tiempo y tus gastos. Lo que haces es un negocio, no eres una ONG, pero tampoco eres un casino.
* Define el valor monetario del producto, intenta NO PAGAR lo minimo posible, seguramente tendras mala calidad del producto final. Y generaras mala relacion con el desarrollador.
* Intenta ser equilibrado en las peticiones, no puedes decir SI a todo, pero tampoco NO a todo. Mide seriamente cada pedido, en horas y dinero.
* Intenta no modificar las peticiones originales, para ti agregar cosas te parece facil, pero puedes alterar el modelo de datos y habra muchisimos cambios.
* Prueba todo muchas veces, eso de "ya lo probe" no vale, tocar codigo, puede alterar partes que venian funcionando bien, intenta que lo pruebe alguien que no sea desarrollador, verificará muchas cosas, pregunta si entiende que tiene que poner en cada lugar.
* Prueba todo muchas veces antes de ponerlo en producción, es un viaje de ida, luego no puede decir "son demasiados problemas, no lo quiero usar mas"
* Recuerdo que los datos son el 90% del producto, no pierdas un solo dato, no cambies nada en produccion, no "cocines" datos, muestra un excesivo respeto por la información del cliente, arma lotes de pruebas (grandes) con datos demos. Las pruebas NO SE HACEN en produccion.
* Recuerda que los datos son el 99% de tu producto. Exige controles, backups, recoverys, mediciones de crecimiento, garantias de privacidad, exige privacidad y respeto por la informacion.
* Lee muy bien los contratos de "non-disclosure". De ser posible con tu asesor legal.
* Si tu información es muy sencible, tienes datos de personas, lee las leyes de privacidad, normativa de confidencialidad y SIEMPRE exige un contrato "non disclosure" y que se respete la normativa vigente, y pon todo por escrito.
* Informa de una casilla de correo y un teléfono para contactarte, que sean comerciales y fija horarios de servicio. Tu no trabajas 24 hs unicamente para el.
* Solicita telefono, email y pacta un servicio de mantenimiento y atención telefónica. Evalúa cuando tienes problemas, cuantas veces, en que partes y tambien si es por errores del programa o por terceros.
* Los bugs los deben arreglar sin cobrarlos, se un profesional, acepta tu error, documento y arregla y nada de pedir mas dinero.
* Los bugs los debe arreglar y NUNCA debes pagar por ellos. Diferencia bugs de cambios.
Esto es solo la punta del iceberg.... el tema da para escribir varios libros.
Comentarios