Pablo Fernando Sanchez te ha enviado un enlace a un blog:
Comparto este post que hace referencia a un artículo sobre métricas en Scrum y el Agile Balanced Scorecard.
Blog: El Blog de Pablo Fernando Sanchez
Entrada: Métricas Ágiles Aplicables a Scrum para el Balanced Scorecard
Enlace: http://pfsanchez.blogspot.com/2008/12/mtricas-giles-aplicables-scrum-para-el.html
SEPG LA 2008
12-14 Noviembre, Mar del Plata, Argentina
Mas información: sepgla@... / www.esi.es/SEPGLA/ .
El PROGRAMA: con más de 30 presentaciones, seminarios, paneles y
charlas magistrales con los mejores oradores de todo Latinoamérica,
Europa y USA está disponible en la web: www.esi.es/SEPGLA/ .
CAPACITACION: Además del programa oficial de la conferencia los
asistentes tendrán la oportunidad de asistir a los cursos
complementarios organizados entorno a la misma:
• ISO/IEC 20000 Auditor (mas info:
• ITIL ® Foundations v3
• Intro to CMMI
• Reutilización
• SOA
• CMMI for Acquisition
• CMMI for Services
• Introduction to the People CMM
EXAMENES: SEI ha previsto además completar y extender el alcance de
la conferencia organizando en ella los siguientes exámenes:
• SCAMPI Lead Appraiser
• CMMI for Services and CMMI for Acquisition.
• SCAMPI High Maturity LA Entry Exam (Tentative-PSP Developer)
• TSP Coach
II ENCUENTRO SPIN Latinoamericano: que tendrá lugar por segunda vez
durante la conferencia.
I ENCUENTRO DE LA COMUNIDAD MORFEO DE SOFTWARE LIBRE EN IBEROAMERICA:
el martes 11 por la tarde en Mar del Plata está prevista la reunión
de lo que será el primer encuentro de la comunidad internacional
desarrollado en la región.
Buenas tardes. Les envío las búsquedas que estamos llevando a cabo actualmente en Cubika.
Quienes estén interesados en la posición o conozcan referidos en la búsqueda envien su cv con remuneración pretendida a rrhh@....
Muchas gracias!!
Buena semana para todos
Saludos,
Giselle
REF ANAQAING10: ANALISTAS DE QA
Nos encontramos en la
búsqueda de Analistas de QA para la conformación de nuestro equipo de Quality
Assurance. Los profesionales deberán contar con acreditada experiencia en el testeo de software;
desarrollando, ejecutando y documentando casos de prueba funcional y técnica.
Orientamos la búsqueda a profesionales con alta
capacidad de análisis, estricta orientación a la calidad y muy buen nivel de
relaciones interpersonales en equipos descentralizados.
Herramientas requeridas: SQL,
TOAD, Metodologías de QA, Unix.
Es necesario el manejo
fluido del idioma Ingles.
REF
TEST10: TESTERS
Para integrar nuestro
equipo de QA&QC incorporamos Testers semi seniors que posean acreditada
experiencia en
el testeo de software; desarrollando, ejecutando y documentando casos de prueba
funcional y técnica. Se requieren conocimientos de sistemas de seguimiento de
defectos y metodologías de testing.
Valoraremos conocimientos básicos de UML yprogramación orientada a objetos.
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo..com.ar
Quinta Conferencia SEPG LA copatrocinada por European Software
Institute (ESI) y Software Engineering Institute (SEI), Carnegie
Mellon University, y organizada localmente por ESICenter Cono Sur
como Anfitrión Local de la misma.
Tema: "Combinando Disciplina con Métodos Ágiles": Calidad y mejora
continua a partir de la implementación de Mejores Prácticas para el
Desarrollo de Software y Gobierno de TI.
Fecha: 12, 13 y 14 de Noviembre 2008.
Lugar: Mar del Plata, Argentina. (Hermitage Hotel)
Inscripciones: on line - www.esi.es/SEPGLA
El PROGRAMA con más de 30 presentaciones con los mejores oradores de
todo Latinoamérica, Europa y USA ya está disponible en la web:
www.esi.es/SEPGLA/
Como ejemplos del interesante contenido técnico:
KEYNOTE SPEAKERS:
Manel Benazet, CIO, Telefónica. Brasil
Hillel Glazer, CEO, ENTINEX.USA
SEMINARIOS:
- Mind the Gaps
James McHale & James Over, Software Engineering Institute. USA
- Quantitative Thinking and the High Maturity Practices of the CMMI
Kent Johnson, AgileDigm Incorporated. USA
- Agregando valor a la Mejora de Procesos a través de Gestión de
Conocimiento
Alejandro Bianchi, Liveware. Argentina
- ITIL & CMMI
Jesús Salillas & Guillermo Leruga, European Software Institute &
GRUPO TEKNE. España & Argentina
- A Holistic Approach to Process Improvement: People, Process,
Technology and Culture.
Palma Buttles, Software Engineering Institute. USA
- A six sigma practical approach to software estimation
Luiz Antonio Bernardes & Martín Miceli, Motorota Brasil & Motorola
Software Center Argentina
Alguien del grupo tiene un formato para realizar un contrato de distribución de software. y cuanto debe ser el porcentaje a cobrar
Gracias
Henry.
--- El sáb 9-ago-08, Luis R. Gordillo <gordilloluis@...> escribió:
De: Luis R. Gordillo <gordilloluis@...> Asunto: RE: [ACS] Software con codigo fuente A: AsegCalidadSoftware@... Fecha: sábado, 9 agosto, 2008, 2:05 am
Muchas gracias todos por sus comentarios que realmente aclaran mucho el tema.
Con respecto al incremento de precio: seria justo aplicar un aumento al precio final del proyecto si incluye los fuentes y que porcentaje se estima conveniente?
Estamos hablando de incluir los fuentes bajo las condiciones de liberarlos solo en caso de no poder continuar por alguna razón. (esto podría pasar después de varios años)
Saludos.
Luis
De: AsegCalidadSoftware @gruposyahoo. com.ar [mailto:AsegCalidad Software@ gruposyahoo. com.ar] En nombre de Carlos Maradiaga Enviado el: Viernes, 01 de Agosto de 2008 12:40 p.m. Para: AsegCalidadSoftware @gruposyahoo. com.ar Asunto: Re: [ACS] Software con codigo fuente
En la empresa donde yo trabajo sucediò algo similar. Se le solicito el codigo fuente a la empresa desarrolladora del software, logicamente la empresa se negò, pero se llego al acuerdo de que, como el software es un Activo de mucho valor, tanto para la empresa como para la empresa que desarrolla el soft (ya que ambas dependende totalmente del software, una para comerciallizarlo y la otra para manejar sus operaciones) , el codigo fuente esta en una caja de seguridad en un banco y la empresa solamente tendra derecho a utilizar dicho còdigo solamente cuando la empresa desarrolladora por cualquier motivo (los motivos se pueden detallar en un documento) no pueda continuar con el mantenimiento del software, ya sea porque no le interesa, la empresa desaparezca, o cualquier otra razon. Los cambios que se hagan al software también se depositan en la caja de seguridad del
banco una vez que se comprueba que funcionan correctamente.
Y asi lograron solucionar el eterno problema que tenian ambas empresas.
Luis se debe establecer en una clausula del contrato que se entrega el código fuente, en el caso que se manupule por alguna necesidad la empresa de Software ya deja de tener responsabilidad sobre el código.
Luis, coincido con vos, y entiendo que una buena práctica puede ser la última que mencionas.
De hecho, me consta que en algunos lugares es la decisión que se toma sobre los fuentes de proveedores.
Saludos. Sandra
--- El mié 30-jul-08, Luis R. Gordillo <gordilloluis@ yahoo.com. ar> escribió:
De: Luis R. Gordillo <gordilloluis@ yahoo.com. ar> Asunto: [ACS] Software con codigo fuente Para: AsegCalidadSoftware @gruposyahoo. com.ar Fecha: miércoles, 30 de julio de 2008, 3:24 pm
Hola a todos:
Este grupo puede conocer o tener experiencias sobre comercializació n de software y es por eso que me dirijo a ustedes.
El dilema sobre entregar o no el código fuente del software desarrollado para una empresa debido a razones que se comenta a continuación.
Una empresa X contrata a una empresa de software para que desarrolle una solución a medida.
Entonces la empresa de software desarrolla una aplicación en base a su experiencia utilizando técnicas propias que fueron evolucionando en rutinas de gran calidad técnica y que producen al final un software de gran calidad.
La empresa X obtiene una solución a medida de gran calidad técnica que cumple con los objetivos solicitados.
Al transcurrir el tiempo la empresa necesita algunos cambios en el sistema.
Aquí surgen los problemas y pueden darse los siguientes casos:
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio razonable.
Esto sería lo mejor y todos contentos.
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio abusivo ya que nadie mas puede hacer estos cambios.
- La empresa desarrolladora no puede hacer estos cambios por diferentes razones. (Quiebra, falta de tiempo, desinterés en el proyecto, o simplemente por que ya no existe).
En estos casos (y cualquier otro similar que se les ocurra) perjudica a la empresa X que compró el software ya que no puede adaptarlo a sus necesidades.
Como puede cubrirse la empresa X?
Al comprar el software puede solicitar el código fuente y la documentación necesaria para no depender del proveedor.
Ventajas.
No depende del proveedor.
Puede adaptarlo a sus necesidades cada vez que se necesite.
Garantiza que su inversión inicial de compra no se pierda al no tener que recurrir a un nuevo software.
Desventaja
Costo muy elevado de adquisición.
Curva de aprendizaje por parte de 3ro en realizar la actualización muy pronunciada.
Costo elevado en dinero y tiempo hasta poder realizar las actualizaciones.
Aun al no depender del proveedor original es posible que los costos sean mayores por actualización.
Deberá mantener a la misma empresa 3ro para futuras actualizaciones, ya que de lo contrario deberá buscar uno nuevo con las consiguientes desventajas.
Pero hasta aquí solo se habla de la empresa X.
La otra parte, la empresa de desarrollo probablemente no quiera vender sus código fuentes ya que sería develar el "secreto" de su negocio y por lo tanto quedar expuesto a copias y competencias desleales, perder su ventaja técnica fruto de su trabajo y experiencia.
E aquí el problema como desarrollador.
Como debería pactarse el contrato en un caso como éste donde la empresa X desee estar protegido según todo lo expuesto anteriormente?
Debería cobrarse un precio mucho mas elevado para entregar el código fuente? Y cuanto mas elevado?
Puede conservar su propiedad intelectual aun cediendo el código fuente para uso interno de la empresa X?
Que pasa con las filtraciones de información al contratar a terceros? Que garantía puede dar la empresa X?
No sería mejor establecer una cláusula en la que se entregue los código fuentes y solo se recurra a un tercero en caso de que el desarrollador original no pueda cumplir o sea abusivo?
La idea sería entregar los fuentes ante una entidad jurídica que libere los fuentes para la empresa X solo en caso de que la empresa desarrolladora incumpliese el contrato o se viese imposibilitada de continuar.
No, no corresponde porque el cliente no puede hacer uso de esos
fuentes en otras condiciones que no sean las pactadas.
Si en un futuro la empresa de software no puede prestar más el
servicio, por el motivo que fuera, no es responsabilidad del cliente por lo que
no debería cargarle esto en el precio (en criollo le estoy diciendo “te
voy a cobrar más por las dudas que en un futuro no pueda prestarte el servicio”).
Como dicen los abogados, hay que entender el espíritu del
acuerdo, y en estos casos, creo yo, el tema pasa más por transmitirle algún
tipo de seguridad y tranquilidad a mi futuro cliente y no por tratar de sacar
algún provecho de esto.
Saludos.
Gabriel
From: AsegCalidadSoftware@...
[mailto:AsegCalidadSoftware@...] On Behalf Of Luis R.
Gordillo Sent: viernes, 08 de agosto de 2008 12:06 To: AsegCalidadSoftware@... Subject: RE: [ACS] Software con codigo fuente
Muchas gracias todos por sus comentarios que realmente aclaran
mucho el tema.
Con respecto al incremento de precio: seria justo aplicar un
aumento al precio final del proyecto si incluye los fuentes y que porcentaje se
estima conveniente?
Estamos hablando de incluir los fuentes bajo las condiciones de
liberarlos solo en caso de no poder continuar por alguna razón. (esto podría
pasar después de varios años)
Saludos.
Luis
De: AsegCalidadSoftware@...
[mailto:AsegCalidadSoftware@...] En nombre de Carlos
Maradiaga Enviado el: Viernes, 01 de Agosto de 2008 12:40 p.m. Para: AsegCalidadSoftware@... Asunto: Re: [ACS] Software con codigo fuente
En la empresa donde yo trabajo sucediò algo similar. Se le
solicito el codigo fuente a la empresa desarrolladora del software, logicamente
la empresa se negò, pero se llego al acuerdo de que, como el software es un
Activo de mucho valor, tanto para la empresa como para la empresa que
desarrolla el soft (ya que ambas dependende totalmente del software, una para
comerciallizarlo y la otra para manejar sus operaciones), el codigo fuente esta
en una caja de seguridad en un banco y la empresa solamente tendra derecho
a utilizar dicho còdigo solamente cuando la empresa desarrolladora por
cualquier motivo (los motivos se pueden detallar en un documento) no pueda
continuar con el mantenimiento del software, ya sea porque no le interesa, la
empresa desaparezca, o cualquier otra razon. Los cambios que se hagan al
software también se depositan en la caja de seguridad del banco una vez que se
comprueba que funcionan correctamente.
Y asi lograron solucionar el eterno problema que tenian
ambas empresas.
Espero que te sirva de algo.
Saludos.
El día 31/07/08, fabiana
gutierrez <fabgut@...>
escribió:
Luis se debe establecer en una clausula
del contrato que se entrega el código fuente, en el caso que se manupule por
alguna necesidad la empresa de Software ya deja de tener responsabilidad
sobre el código.
Esta cláúsula debe estar dentro del
contrato.
----- Mensaje original ----
De: Sandra Lía Benvenuto <slbenvenuto@...> Para: AsegCalidadSoftware@...
Enviado: jueves 31 de julio de 2008, 14:14:49
Asunto: Re: [ACS] Software con codigo fuente
Luis, coincido con vos, y entiendo que una buena práctica puede ser la
última que mencionas.
De hecho, me consta que en algunos lugares es la decisión que se toma
sobre los fuentes de proveedores.
Saludos. Sandra
--- El mié 30-jul-08, Luis R. Gordillo <gordilloluis@ yahoo.com. ar> escribió:
De:
Luis R. Gordillo <gordilloluis@ yahoo.com.
ar>
Asunto: [ACS] Software con codigo fuente
Para: AsegCalidadSoftware @gruposyahoo. com.ar
Fecha: miércoles, 30 de julio de 2008, 3:24 pm
Hola a todos:
Este grupo puede conocer o tener experiencias sobre comercializació n de
software y es por eso que me dirijo a ustedes.
El dilema sobre entregar o no el código fuente del software desarrollado
para una empresa debido a razones que se comenta a continuación.
Una empresa X contrata a una empresa de software para que desarrolle una
solución a medida.
Entonces la empresa de software desarrolla una aplicación en base a su
experiencia utilizando técnicas propias que fueron evolucionando en rutinas
de gran calidad técnica y que producen al final un software de gran calidad.
La empresa X obtiene una solución a medida de gran calidad técnica que
cumple con los objetivos solicitados.
Al transcurrir el tiempo la empresa necesita algunos cambios en el sistema.
Aquí surgen los problemas y pueden darse los siguientes casos:
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio
razonable.
Esto sería lo mejor y todos contentos.
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio
abusivo ya que nadie mas puede hacer estos cambios.
- La empresa desarrolladora no puede hacer estos cambios por diferentes
razones. (Quiebra, falta de tiempo, desinterés en el proyecto, o simplemente
por que ya no existe).
En estos casos (y cualquier otro similar que se les ocurra) perjudica a la
empresa X que compró el software ya que no puede adaptarlo a sus necesidades.
Como puede cubrirse la empresa X?
Al comprar el software puede solicitar el código fuente y la documentación
necesaria para no depender del proveedor.
Ventajas.
No depende del proveedor.
Puede adaptarlo a sus necesidades cada vez que se necesite.
Garantiza que su inversión inicial de compra no se pierda al no tener que
recurrir a un nuevo software.
Desventaja
Costo muy elevado de adquisición.
Curva de aprendizaje por parte de 3ro en realizar la actualización muy
pronunciada.
Costo elevado en dinero y tiempo hasta poder realizar las actualizaciones.
Aun al no depender del proveedor original es posible que los costos sean
mayores por actualización.
Deberá mantener a la misma empresa 3ro para futuras actualizaciones, ya
que de lo contrario deberá buscar uno nuevo con las consiguientes desventajas.
Pero hasta aquí solo se habla de la empresa X.
La otra parte, la empresa de desarrollo probablemente no quiera vender sus
código fuentes ya que sería develar el "secreto" de su negocio y
por lo tanto quedar expuesto a copias y competencias desleales, perder su ventaja
técnica fruto de su trabajo y experiencia.
E aquí el problema como desarrollador.
Como debería pactarse el contrato en un caso como éste donde la empresa X
desee estar protegido según todo lo expuesto anteriormente?
Debería cobrarse un precio mucho mas elevado para entregar el código
fuente? Y cuanto mas elevado?
Puede conservar su propiedad intelectual aun cediendo el código fuente
para uso interno de la empresa X?
Que pasa con las filtraciones de información al contratar a terceros? Que
garantía puede dar la empresa X?
No sería mejor establecer una cláusula en la que se entregue los código
fuentes y solo se recurra a un tercero en caso de que el desarrollador
original no pueda cumplir o sea abusivo?
La idea sería entregar los fuentes ante una entidad jurídica que libere
los fuentes para la empresa X solo en caso de que la empresa desarrolladora
incumpliese el contrato o se viese imposibilitada de continuar.
Muchas gracias todos por sus comentarios
que realmente aclaran mucho el tema.
Con respecto al incremento de precio:
seria justo aplicar un aumento al precio final del proyecto si incluye los
fuentes y que porcentaje se estima conveniente?
Estamos hablando de incluir los fuentes
bajo las condiciones de liberarlos solo en caso de no poder continuar por
alguna razón. (esto podría pasar después de varios años)
Saludos.
Luis
De: AsegCalidadSoftware@...
[mailto:AsegCalidadSoftware@...] En nombre de Carlos Maradiaga Enviado el: Viernes, 01 de Agosto
de 2008 12:40 p.m. Para:
AsegCalidadSoftware@... Asunto: Re: [ACS] Software con
codigo fuente
En la empresa donde yo trabajo sucediò algo similar. Se le solicito el
codigo fuente a la empresa desarrolladora del software, logicamente la empresa
se negò, pero se llego al acuerdo de que, como el software es un Activo de
mucho valor, tanto para la empresa como para la empresa que desarrolla el soft
(ya que ambas dependende totalmente del software, una para comerciallizarlo y
la otra para manejar sus operaciones), el codigo fuente esta en una caja
de seguridad en un banco y la empresa solamente tendra derecho a utilizar
dicho còdigo solamente cuando la empresa desarrolladora por cualquier motivo
(los motivos se pueden detallar en un documento) no pueda continuar con el
mantenimiento del software, ya sea porque no le interesa, la empresa
desaparezca, o cualquier otra razon. Los cambios que se hagan al software
también se depositan en la caja de seguridad del banco una vez que se comprueba
que funcionan correctamente.
Y asi lograron solucionar el eterno problema que tenian ambas empresas.
Luis se debe establecer en una clausula del contrato
que se entrega el código fuente, en el caso que se manupule por alguna
necesidad la empresa de Software ya deja de tener responsabilidad sobre el
código.
Luis,
coincido con vos, y entiendo que una buena práctica puede ser la última que
mencionas.
De
hecho, me consta que en algunos lugares es la decisión que se toma sobre los
fuentes de proveedores.
Saludos.
Sandra
--- El mié 30-jul-08, Luis R. Gordillo <gordilloluis@ yahoo.com. ar> escribió:
De: Luis R. Gordillo
<gordilloluis@ yahoo.com.
ar>
Asunto: [ACS] Software con codigo fuente
Para: AsegCalidadSoftware @gruposyahoo. com.ar
Fecha: miércoles, 30 de julio de 2008, 3:24 pm
Hola a
todos:
Este
grupo puede conocer o tener experiencias sobre comercializació n de software
y es por eso que me dirijo a ustedes.
El
dilema sobre entregar o no el código fuente del software desarrollado para
una empresa debido a razones que se comenta a continuación.
Una
empresa X contrata a una empresa de software para que desarrolle una solución
a medida.
Entonces
la empresa de software desarrolla una aplicación en base a su experiencia
utilizando técnicas propias que fueron evolucionando en rutinas de gran calidad
técnica y que producen al final un software de gran calidad.
La
empresa X obtiene una solución a medida de gran calidad técnica que cumple
con los objetivos solicitados.
Al
transcurrir el tiempo la empresa necesita algunos cambios en el sistema.
Aquí
surgen los problemas y pueden darse los siguientes casos:
- La
empresa desarrolladora puede hacer estos cambios y cobrar un precio
razonable.
Esto
sería lo mejor y todos contentos.
- La
empresa desarrolladora puede hacer estos cambios y cobrar un precio abusivo
ya que nadie mas puede hacer estos cambios.
- La
empresa desarrolladora no puede hacer estos cambios por diferentes razones.
(Quiebra, falta de tiempo, desinterés en el proyecto, o simplemente por que
ya no existe).
En
estos casos (y cualquier otro similar que se les ocurra) perjudica a la
empresa X que compró el software ya que no puede adaptarlo a sus necesidades.
Como
puede cubrirse la empresa X?
Al
comprar el software puede solicitar el código fuente y la documentación
necesaria para no depender del proveedor.
Ventajas.
No
depende del proveedor.
Puede
adaptarlo a sus necesidades cada vez que se necesite.
Garantiza
que su inversión inicial de compra no se pierda al no tener que recurrir a un
nuevo software.
Desventaja
Costo
muy elevado de adquisición.
Curva
de aprendizaje por parte de 3ro en realizar la actualización muy pronunciada.
Costo
elevado en dinero y tiempo hasta poder realizar las actualizaciones.
Aun al
no depender del proveedor original es posible que los costos sean mayores por
actualización.
Deberá
mantener a la misma empresa 3ro para futuras actualizaciones, ya que de lo
contrario deberá buscar uno nuevo con las consiguientes desventajas.
Pero
hasta aquí solo se habla de la empresa X.
La otra
parte, la empresa de desarrollo probablemente no quiera vender sus código
fuentes ya que sería develar el "secreto" de su negocio y por lo
tanto quedar expuesto a copias y competencias desleales, perder su ventaja
técnica fruto de su trabajo y experiencia.
E aquí
el problema como desarrollador.
Como
debería pactarse el contrato en un caso como éste donde la empresa X desee
estar protegido según todo lo expuesto anteriormente?
Debería
cobrarse un precio mucho mas elevado para entregar el código fuente? Y cuanto
mas elevado?
Puede
conservar su propiedad intelectual aun cediendo el código fuente para uso
interno de la empresa X?
Que
pasa con las filtraciones de información al contratar a terceros? Que
garantía puede dar la empresa X?
No
sería mejor establecer una cláusula en la que se entregue los código fuentes
y solo se recurra a un tercero en caso de que el desarrollador original no
pueda cumplir o sea abusivo?
La idea
sería entregar los fuentes ante una entidad jurídica que libere los fuentes
para la empresa X solo en caso de que la empresa desarrolladora incumpliese
el contrato o se viese imposibilitada de continuar.
En la empresa donde yo trabajo sucediò algo similar. Se le solicito el codigo fuente a la empresa desarrolladora del software, logicamente la empresa se negò, pero se llego al acuerdo de que, como el software es un Activo de mucho valor, tanto para la empresa como para la empresa que desarrolla el soft (ya que ambas dependende totalmente del software, una para comerciallizarlo y la otra para manejar sus operaciones), el codigo fuente esta en una caja de seguridad en un banco y la empresa solamente tendra derecho a utilizar dicho còdigo solamente cuando la empresa desarrolladora por cualquier motivo (los motivos se pueden detallar en un documento) no pueda continuar con el mantenimiento del software, ya sea porque no le interesa, la empresa desaparezca, o cualquier otra razon. Los cambios que se hagan al software también se depositan en la caja de seguridad del banco una vez que se comprueba que funcionan correctamente.
Y asi lograron solucionar el eterno problema que tenian ambas empresas.
Espero que te sirva de algo.
Saludos.
El día 31/07/08, fabiana gutierrez <fabgut@...> escribió:
Luis se debe establecer en una clausula del contrato que se entrega el código fuente, en el caso que se manupule por alguna necesidad la empresa de Software ya deja de tener responsabilidad sobre el código.
Esta cláúsula debe estar dentro del contrato.
----- Mensaje original ---- De: Sandra Lía Benvenuto <slbenvenuto@...>
Para: AsegCalidadSoftware@... Enviado: jueves 31 de julio de 2008, 14:14:49
Asunto: Re: [ACS] Software con codigo fuente
Luis, coincido con vos, y entiendo que una buena práctica puede ser la última que mencionas.
De hecho, me consta que en algunos lugares es la decisión que se toma sobre los fuentes de proveedores.
Saludos. Sandra
--- El mié 30-jul-08, Luis R. Gordillo <gordilloluis@ yahoo.com. ar> escribió:
De: Luis R. Gordillo <gordilloluis@ yahoo.com. ar>
Asunto: [ACS] Software con codigo fuente Para: AsegCalidadSoftware @gruposyahoo. com.ar Fecha: miércoles, 30 de julio de 2008, 3:24 pm
Hola a todos:
Este grupo puede conocer o tener experiencias sobre comercializació n de software y es por eso que me dirijo a ustedes.
El dilema sobre entregar o no el código fuente del software desarrollado para una empresa debido a razones que se comenta a continuación.
Una empresa X contrata a una empresa de software para que desarrolle una solución a medida.
Entonces la empresa de software desarrolla una aplicación en base a su experiencia utilizando técnicas propias que fueron evolucionando en rutinas de gran calidad técnica y que producen al final un software de gran calidad.
La empresa X obtiene una solución a medida de gran calidad técnica que cumple con los objetivos solicitados.
Al transcurrir el tiempo la empresa necesita algunos cambios en el sistema.
Aquí surgen los problemas y pueden darse los siguientes casos:
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio razonable.
Esto sería lo mejor y todos contentos.
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio abusivo ya que nadie mas puede hacer estos cambios.
- La empresa desarrolladora no puede hacer estos cambios por diferentes razones. (Quiebra, falta de tiempo, desinterés en el proyecto, o simplemente por que ya no existe).
En estos casos (y cualquier otro similar que se les ocurra) perjudica a la empresa X que compró el software ya que no puede adaptarlo a sus necesidades.
Como puede cubrirse la empresa X?
Al comprar el software puede solicitar el código fuente y la documentación necesaria para no depender del proveedor.
Ventajas.
No depende del proveedor.
Puede adaptarlo a sus necesidades cada vez que se necesite.
Garantiza que su inversión inicial de compra no se pierda al no tener que recurrir a un nuevo software.
Desventaja
Costo muy elevado de adquisición.
Curva de aprendizaje por parte de 3ro en realizar la actualización muy pronunciada.
Costo elevado en dinero y tiempo hasta poder realizar las actualizaciones.
Aun al no depender del proveedor original es posible que los costos sean mayores por actualización.
Deberá mantener a la misma empresa 3ro para futuras actualizaciones, ya que de lo contrario deberá buscar uno nuevo con las consiguientes desventajas.
Pero hasta aquí solo se habla de la empresa X.
La otra parte, la empresa de desarrollo probablemente no quiera vender sus código fuentes ya que sería develar el "secreto" de su negocio y por lo tanto quedar expuesto a copias y competencias desleales, perder su ventaja técnica fruto de su trabajo y experiencia.
E aquí el problema como desarrollador.
Como debería pactarse el contrato en un caso como éste donde la empresa X desee estar protegido según todo lo expuesto anteriormente?
Debería cobrarse un precio mucho mas elevado para entregar el código fuente? Y cuanto mas elevado?
Puede conservar su propiedad intelectual aun cediendo el código fuente para uso interno de la empresa X?
Que pasa con las filtraciones de información al contratar a terceros? Que garantía puede dar la empresa X?
No sería mejor establecer una cláusula en la que se entregue los código fuentes y solo se recurra a un tercero en caso de que el desarrollador original no pueda cumplir o sea abusivo?
La idea sería entregar los fuentes ante una entidad jurídica que libere los fuentes para la empresa X solo en caso de que la empresa desarrolladora incumpliese el contrato o se viese imposibilitada de continuar.
Creo que el planteamiento que Gabriel le hace a Luis, en relación al tema en discusión, es el que se emplea en la mayor parte del mundo, lo que faltó nada mas, es incluir un tarifario en US$ ó Euros del costo de los servicios de mantenimiento y/o desarrollo, de tal manera que podamos tener una cobertura al intento de cobros abusivos o especulativos que pueda presupuestar la empresa desarrolladora.
El depósito, aqui en Perú, lo hacemos en una Notaría Pública, y los Srs. Notarios administran perfectamente este asunto.
Hasta pronto.
José Aparicio S.
Lima - Perú
To: AsegCalidadSoftware@... From: gcaricari@... Date: Fri, 1 Aug 2008 13:34:02 +0000 Subject: [ACS] Re: Software con codigo fuente
Hola Luis, te cuento, esto es muy común de parte de los clientes, por lo menos acá en la Argentina, me ha pasado en varias de las empresas que he trabajado.
El tema se resuelve así, los fuentes son propiedad de la empresa desarrolladora, el cliente no compra los fuentes sino un producto terminado el cual surge de estos fuentes, por lo que el cliente no tiene derechos para solicitarlos. Además, la empresa desarrolladora no puede ni está obligada a entregar estos fuentes porque es un componente vital y principal de su negocio, además de los derechos intelectuales, de propiedad y todo lo legal. Por lo tanto, para satisfacer la inquietud del cliente, lo que se hace es dejar una copia de los fuentes en custodia en una escribanía, a través de un acuerdo o contrato ante escribano, el cual contiene una o varias cláusulas que indican que el cliente no puede, bajo ningún punto de vista, hacer uso, lectura, modificación ni ningún tipo de operación con esos fuentes, salvo que, la empresa desarrolladora deje de existir, quiebre, o que por algún motivo se compruebe que no puede prestar más el servicio.
Actualmente nosotros tenemos varios contratos de este estilo con algunos de los clientes que lo solicitan, y esta es la manera en que se resuelve.
Espero te sirva.
Saludos. Gabriel.
--- En AsegCalidadSoftware@gruposyahoo.com.ar, "Luis R. Gordillo" <gordilloluis@...> escribió: > > Hola a todos: > > > > Este grupo puede conocer o tener experiencias sobre comercialización de > software y es por eso que me dirijo a ustedes. > > > > El dilema sobre entregar o no el código fuente del software desarrollado > para una empresa debido a razones que se comenta a continuación. > > > > Una empresa X contrata a una empresa de software para que desarrolle una > solución a medida. > > Entonces la empresa de software desarrolla una aplicación en base a su > experiencia utilizando técnicas propias que fueron evolucionando en rutinas > de gran calidad técnica y que producen al final un software de gran calidad. > > La empresa X obtiene una solución a medida de gran calidad técnica que > cumple con los objetivos solicitados. > > Al transcurrir el tiempo la empresa necesita algunos cambios en el sistema. > > Aquí surgen los problemas y pueden darse los siguientes casos: > > > > - La empresa desarrolladora puede hacer estos cambios y cobrar un precio > razonable. > > Esto sería lo mejor y todos contentos. > > > > - La empresa desarrolladora puede hacer estos cambios y cobrar un precio > abusivo ya que nadie mas puede hacer estos cambios. > > - La empresa desarrolladora no puede hacer estos cambios por diferentes > razones. (Quiebra, falta de tiempo, desinterés en el proyecto, o simplemente > por que ya no existe). > > > > En estos casos (y cualquier otro similar que se les ocurra) perjudica a la > empresa X que compró el software ya que no puede adaptarlo a sus > necesidades. > > > > Como puede cubrirse la empresa X? > > Al comprar el software puede solicitar el código fuente y la documentación > necesaria para no depender del proveedor. > > Ventajas. > > No depende del proveedor. > > Puede adaptarlo a sus necesidades cada vez que se necesite. > > Garantiza que su inversión inicial de compra no se pierda al no tener que > recurrir a un nuevo software. > > > > Desventaja > > Costo muy elevado de adquisición. > > Curva de aprendizaje por parte de 3ro en realizar la actualización muy > pronunciada. > > Costo elevado en dinero y tiempo hasta poder realizar las actualizaciones. > > Aun al no depender del proveedor original es posible que los costos sean > mayores por actualización. > > Deberá mantener a la misma empresa 3ro para futuras actualizaciones, ya que > de lo contrario deberá buscar uno nuevo con las consiguientes desventajas. > > > > Pero hasta aquí solo se habla de la empresa X. > > La otra parte, la empresa de desarrollo probablemente no quiera vender sus > código fuentes ya que sería develar el "secreto" de su negocio y por lo > tanto quedar expuesto a copias y competencias desleales, perder su ventaja > técnica fruto de su trabajo y experiencia. > > > > E aquí el problema como desarrollador. > > > > Como debería pactarse el contrato en un caso como éste donde la empresa X > desee estar protegido según todo lo expuesto anteriormente? > > Debería cobrarse un precio mucho mas elevado para entregar el código fuente? > Y cuanto mas elevado? > > Puede conservar su propiedad intelectual aun cediendo el código fuente para > uso interno de la empresa X? > > Que pasa con las filtraciones de información al contratar a terceros? Que > garantía puede dar la empresa X? > > No sería mejor establecer una cláusula en la que se entregue los código > fuentes y solo se recurra a un tercero en caso de que el desarrollador > original no pueda cumplir o sea abusivo? > > > > La idea sería entregar los fuentes ante una entidad jurídica que libere los > fuentes para la empresa X solo en caso de que la empresa desarrolladora > incumpliese el contrato o se viese imposibilitada de continuar. > > > > Agradecería sus opiniones, ideas y experiencias. > > > > Desde ya muchas gracias. > > > > Luis. >
Hola Luis,
te cuento, esto es muy común de parte de los clientes, por lo menos
acá en la Argentina, me ha pasado en varias de las empresas que he
trabajado.
El tema se resuelve así, los fuentes son propiedad de la empresa
desarrolladora, el cliente no compra los fuentes sino un producto
terminado el cual surge de estos fuentes, por lo que el cliente no
tiene derechos para solicitarlos.
Además, la empresa desarrolladora no puede ni está obligada a entregar
estos fuentes porque es un componente vital y principal de su negocio,
además de los derechos intelectuales, de propiedad y todo lo legal.
Por lo tanto, para satisfacer la inquietud del cliente, lo que se hace
es dejar una copia de los fuentes en custodia en una escribanía, a
través de un acuerdo o contrato ante escribano, el cual contiene una o
varias cláusulas que indican que el cliente no puede, bajo ningún
punto de vista, hacer uso, lectura, modificación ni ningún tipo de
operación con esos fuentes, salvo que, la empresa desarrolladora deje
de existir, quiebre, o que por algún motivo se compruebe que no puede
prestar más el servicio.
Actualmente nosotros tenemos varios contratos de este estilo con
algunos de los clientes que lo solicitan, y esta es la manera en que
se resuelve.
Espero te sirva.
Saludos.
Gabriel.
--- En AsegCalidadSoftware@..., "Luis R. Gordillo"
<gordilloluis@...> escribió:
>
> Hola a todos:
>
>
>
> Este grupo puede conocer o tener experiencias sobre comercialización de
> software y es por eso que me dirijo a ustedes.
>
>
>
> El dilema sobre entregar o no el código fuente del software desarrollado
> para una empresa debido a razones que se comenta a continuación.
>
>
>
> Una empresa X contrata a una empresa de software para que desarrolle una
> solución a medida.
>
> Entonces la empresa de software desarrolla una aplicación en base a su
> experiencia utilizando técnicas propias que fueron evolucionando en
rutinas
> de gran calidad técnica y que producen al final un software de gran
calidad.
>
> La empresa X obtiene una solución a medida de gran calidad técnica que
> cumple con los objetivos solicitados.
>
> Al transcurrir el tiempo la empresa necesita algunos cambios en el
sistema.
>
> Aquí surgen los problemas y pueden darse los siguientes casos:
>
>
>
> - La empresa desarrolladora puede hacer estos cambios y cobrar un precio
> razonable.
>
> Esto sería lo mejor y todos contentos.
>
>
>
> - La empresa desarrolladora puede hacer estos cambios y cobrar un precio
> abusivo ya que nadie mas puede hacer estos cambios.
>
> - La empresa desarrolladora no puede hacer estos cambios por diferentes
> razones. (Quiebra, falta de tiempo, desinterés en el proyecto, o
simplemente
> por que ya no existe).
>
>
>
> En estos casos (y cualquier otro similar que se les ocurra)
perjudica a la
> empresa X que compró el software ya que no puede adaptarlo a sus
> necesidades.
>
>
>
> Como puede cubrirse la empresa X?
>
> Al comprar el software puede solicitar el código fuente y la
documentación
> necesaria para no depender del proveedor.
>
> Ventajas.
>
> No depende del proveedor.
>
> Puede adaptarlo a sus necesidades cada vez que se necesite.
>
> Garantiza que su inversión inicial de compra no se pierda al no
tener que
> recurrir a un nuevo software.
>
>
>
> Desventaja
>
> Costo muy elevado de adquisición.
>
> Curva de aprendizaje por parte de 3ro en realizar la actualización muy
> pronunciada.
>
> Costo elevado en dinero y tiempo hasta poder realizar las
actualizaciones.
>
> Aun al no depender del proveedor original es posible que los costos sean
> mayores por actualización.
>
> Deberá mantener a la misma empresa 3ro para futuras actualizaciones,
ya que
> de lo contrario deberá buscar uno nuevo con las consiguientes
desventajas.
>
>
>
> Pero hasta aquí solo se habla de la empresa X.
>
> La otra parte, la empresa de desarrollo probablemente no quiera
vender sus
> código fuentes ya que sería develar el "secreto" de su negocio y por lo
> tanto quedar expuesto a copias y competencias desleales, perder su
ventaja
> técnica fruto de su trabajo y experiencia.
>
>
>
> E aquí el problema como desarrollador.
>
>
>
> Como debería pactarse el contrato en un caso como éste donde la
empresa X
> desee estar protegido según todo lo expuesto anteriormente?
>
> Debería cobrarse un precio mucho mas elevado para entregar el código
fuente?
> Y cuanto mas elevado?
>
> Puede conservar su propiedad intelectual aun cediendo el código
fuente para
> uso interno de la empresa X?
>
> Que pasa con las filtraciones de información al contratar a
terceros? Que
> garantía puede dar la empresa X?
>
> No sería mejor establecer una cláusula en la que se entregue los código
> fuentes y solo se recurra a un tercero en caso de que el desarrollador
> original no pueda cumplir o sea abusivo?
>
>
>
> La idea sería entregar los fuentes ante una entidad jurídica que
libere los
> fuentes para la empresa X solo en caso de que la empresa desarrolladora
> incumpliese el contrato o se viese imposibilitada de continuar.
>
>
>
> Agradecería sus opiniones, ideas y experiencias.
>
>
>
> Desde ya muchas gracias.
>
>
>
> Luis.
>
Título...: NORMAS BÁSICAS DE COMPORTAMIENTO EN EL GRUPO
Versión..: 1.1
Fecha....: 2003-09-01
_____________________________________________________________________
1. Intentá no enviar mensajes en formato HTML u otros distintos al
básico. Pesan más sin aportar gran cosa. Podés saber si estás
escribiendo un mensaje en HTML porque tu mailer (el programa de
correo electrónico) te ofrecerá opciones de edición extra, como
letra en negrita o color.
2. No envíes al grupo archivos adjuntos de un tamaño superior a los
100 Kb por medio del correo electrónico. En su lugar, utilizá el
área de archivos del grupo que para ello está.
Además, si bien Yahoo! Grupos entrega todos los archivos adjuntos
que se envían por medio del correo electrónico, estos no se
guardan en el área de mensajes; por ello, los archivos e imágenes
que quieras subir y compartir deberán estar en las áreas de
archivos y fotos del grupo.
3. No pidas confirmación automática de los mensajes que envíes. Es
de pésima educación, pues supone colocar al receptor de tu
mensaje en la disyuntiva de elegir entre que pienses que no lo
recibió y enviarte información personal que no tiene por qué
compartir con vos.
4. No envíes correos masivos y, sobre todo, no los reenvíes. Si
enviás por necesidad un correo a una lista de personas, colocá
sus direcciones en el campo de "Copia Oculta" (CCO). Muchas
personas pueden querer que tengas su correo electrónico, pero no
todos tus contactos y menos tanta gente que participa de un grupo
de discusión.
5. Nunca envíes mensajes en cadena. Las alarmas de virus y las
cadenas de mensajes son por definición FALSAS y su único objetivo
es saturar los servidores y con ellos la red. En los viejos
tiempos, tus privilegios en la red hubieran sido cancelados.
6. Saludá antes del mensaje indicando a quién o a quiénes te
dirigís, y despedite con tu nombre, exactamente igual que harías
con una carta física. Añadí una línea o dos al final de tu
mensaje con información de contacto. Esto es importante ya que
dirigirse a quién sea sin decir quién sos es una actitud pueril,
propia de niños en rebeldía, y una enorme falta de respeto. Es
muy desagradable responder anónimos o a entes que no aportan la
suficiente información para tratarlos con cortesía.
7. Cuando hagas una pregunta al grupo, destacá lo que hayas
aprendido a partir de haber intentado encontrar una respuesta
leyendo material bibliográfico, buscando en la web, preguntándole
a un amigo con más experiencia, etcétera. Generalmente, a los
miembros más experimentados de los grupos de discusión les gusta
responder a la gente que ha demostrado ser capaz de aprender de
las respuestas. Prepará tu pregunta. Pensá en ella. Las preguntas
precipitadas reciben respuestas precipitadas o ni siquiera eso.
Cuanto más hagas para demostrar que has puesto pensamiento y
esfuerzo en resolver tu problema antes de pedir ayuda, más cerca
estarás de recibirla realmente. Realmente, te ganarás una
respuesta si hacés una pregunta sustancial, interesante y que
haga pensar, una que contribuya implícitamente a la experiencia
de la comunidad antes que solicitar de manera pasiva conocimiento
de los demás.
Por otra parte, un muy buen comienzo es dejar claro que podés y
querés participar en el proceso de desarrollar la solución.
"¿Tiene alguien alguna pista?", "¿Qué le falta a mi ejemplo?" y
"¿Hay alguna página que debiera haber consultado?" tendrán más
probabilidades de ser respondidas que "Publicá por favor el
procedimiento exacto que debería seguir", porque estás dejando
claro que estás realmente deseoso de completar el proceso si
alguien simplemente te orienta en la dirección correcta.
8. Sabemos por experiencia que los escritores descuidados y
chapuceros también piensan de manera desordenada y chapucera --a
menudo lo suficiente como para apostar por ello, no obstante.
Responder a pensadores descuidados y chapuceros no recompensa;
mejor estaríamos usando nuestro tiempo en cualquier otro lugar.
Por esto, es importante expresar tu pregunta de manera clara. Si
no podés molestarte en hacer eso, el resto de los miembros del
grupo no pueden molestarse en prestarte atención. Aprovechá el
esfuerzo añadido en pulir tu lenguaje. No tiene que ser nada
estirado ni formal; de hecho, la cultura de los grupos de
discusión valora el lenguaje informal y cómico usado con
precisión. Pero tiene que ser preciso: tiene que haber alguna
indicación de que estás pensando y prestando atención.
Deletreá correctamente. Escribir como un lammer --hAzI3Nd0t3
pAzAr p0r iNt3lIg3nT3 3zKrIbI3Nd0 k0m0 iMb3zIl-- es el beso de la
muerte absoluto y te garantiza que no recibirás otra cosa que
un silencio sepulcral o, si tenés suerte, un montón de desprecio
y sarcasmo como devolución.
9. La cortesía nunca hiere e, incluso, a veces hasta ayuda. Sé
cortés. Usá "Por favor" y "Gracias por adelantado". Dejá claro
que apreciás el tiempo que emplea la gente ayudándote gratis.
Esto no es tan importante como --y no puede sustituir a-- ser
correcto gramaticalmente, claro, preciso y descriptivo, evitar
formatos propietarios, etcétera, pero ayuda. De todos modos, si
obtuviste tus conocimientos técnicos en una tómbola, la educación
incrementará tus posibilidades de recibir una respuesta útil.
10. Recordá que la gente con quienes te comunicás, incluidos los
administradores y los miembros de los grupos a los que pertenecés
o que visitás, no cobran por responderte ni tienen obligación de
hacerlo. Son personas que si te atienden te estarán haciendo un
favor. Nunca asumas que tenés derecho a una respuesta. No lo
tenés.
11. Utilizá las mayúsculas y las minúsculas correctamente. LAS
MAYÚSCULAS DAN LA IMPRESIÓN DE QUE ESTUVIERAS GRITANDO. No hace
falta decir que escribir líneas, párrafos y mensajes enteros en
mayúscula es de pésima educación.
12. Utilizá símbolos para dar énfasis: esto *es* lo que quiero decir.
Utilizá guiones bajos para dar a entender un subrayado: _La
Guerra y la Paz_ es mi libro favorito.
13. Sé breve sin ser demasiado conciso. Cuando contestés un mensaje,
incluí el suficiente material original como para ser entendido
pero no más. Es una mala forma contestar un mensaje simplemente
incluyendo todo el mensaje anterior: borrá todo el material
irrelevante.
14. Usá títulos específicos y con sentido. En los grupos de
discusión, el título o asunto (subject) del mensaje es tu
oportunidad de oro para atraer la atención de expertos
calificados en aproximadamente 50 caracteres o menos. No los
desperdicies en balbuceos. No intentes impresionar al resto de
los miembros del grupo con lo profundo de tu angustia; usá el
espacio para una descripción superconcisa del problema en vez de
eso: el mensaje debe tener un asunto que refleje el contenido del
mismo. Los asuntos vacíos como "Urgente", "Una pregunta",
"Necesito ayuda", "Ayuda" y demás frases que no tienen nada que
ver con el contenido sino con su intención, no son adecuados para
la publicación en un grupo de discusión.
15. No envíes mensajes que estén fuera de tema para el grupo, ya que
esto puede molestar a muchos de los miembros del grupo. Tené
cuidado al elegir dónde planteás tu pregunta. Seguramente te
ignorarán o te tildarán de perdedor si publicás tu pregunta en
un grupo en el que se encuentra fuera de lugar (off-topic). Los
miembros más experimentados de los grupos de discusión suelen
descartar las preguntas inapropiadas para intentar proteger sus
canales de comunicación de lo irrelevante. No querés que te
suceda eso.
Muchas veces podés tener la respuesta a tu alcance en otro grupo
dedicado más específicamente al tema sobre el cual trata tu
consulta. Para ello, podés ayudarte con el mensaje titulado
"Grupos de Sistemas, Software, Management y Tecnologías" o
mediante el índice de Yahoo! Grupos. Si aún tomando en cuenta
estas consideraciones necesitás enviar un mensaje fuera de tema,
iniciá el asunto (subject) del mismo con las siglas "OT:", que
significan "off-topic" o "fuera de tema".
16. Tené cuidado cuando escribas la dirección de correo. Hay
direcciones que llegan a un grupo, pero la dirección parece que
va sólo a una persona. Fíjate a quién lo estás mandando.
17. Mirá el campo de "Copia" (CC) cuando contestes. Si la primera
persona que envió el mensaje se lo mandó a varios en su lista de
correo, no hagas lo mismo.
18. A no ser que usés un dispositivo de encriptación por hardware o
software, cosa que no debe hacerse cuando se escribe a un grupo
público de discusión, debés asumir que el correo en Internet no
es seguro. Nunca pongas nada en un correo electrónico que no
pondrías en una postal. Por otro lado, algunos mensajes pueden
aparecer como provenientes de otra persona distinta del autor.
Aplicá tu sentido común antes de asumir que un mensaje es válido.
19. Si pensás que la importancia de un mensaje lo justifica, contestá
inmediatamente a la dirección particular del remitente para que
sepa que lo has recibido y que estás trabajando en la respuesta,
aunque vayas a mandarle una respuesta más larga más tarde por el
grupo de discusión.
20. Las expectitivas razonables sobre conducta en el correo
electrónico dependen de tu relación con la persona y el contexto
de la comunicación, para el caso este grupo. Las normas
aprendidas en este ambiente puede que no sean aplicables para tu
comunicación por correo electrónico con gente a través de
Internet en otros contextos. Ten cuidado con el argot o siglas
locales.
21. La publicidad por correo electrónico no es bienvenida. Abstenete
de hacer publicidad que no haya sido previamente aceptada por el
administrador del grupo, en especial si se trata de publicidad
fuera de tema o que, estando en tema, sean desleales al ofrecer
beneficios inexistentes. Sólo se considerarán ofertas académicas,
bibliográficas o de software que estén relacionadas con el tema
de discusión y que les aporte una ventaja a los miembros del
grupo.
22. Si alguien ofrece un archivo y lo querés, NUNCA se lo pidas por
el grupo, sino mediante su dirección de correo privada. Los
mensajes que sólo incluyen frases como "Quiero ese archivo", "A
mí también", etcétera, son una verdadera falta de consideración
hacia el resto de los miembros del grupo, quienes no tienen por
qué soportar tales abusos.
23. Si ofrecés algún archivo, fijate primero si podés subirlo al área
de archivos del grupo. Si esto es posible, subilo y seleccioná la
opción para que se avise al grupo sobre la carga; de esta forma,
no hará falta ofrecerlo. Si no podés subirlo al área de archivos,
podés ofrecerlo al grupo mediante un mensaje, indicando en qué
formato está y su tamaño: recordá que no todo el mundo tiene
banda ancha ni buzones de 50 Mb.
24. Si alguna de las respuestas que querés enviar son de tipo
personal, incluyendo agradecimientos sin contenido adicional,
hacelo a la dirección de correo privado de la persona
destinataria de tal mensaje personal, nunca al grupo. Por el
contrario, de no ser personal es importante que lo envíes al
grupo, para que todos los miembros puedan aprender de la
experiencia y/o participar de la discusión: eso es bueno para el
grupo.
25. Si por alguna razón alguna de tus consultas se soluciona por vías
privadas, podría ser bueno para el grupo que te tomes la molestia
de avisar que la solucionaste, incluyendo la forma en que se
resolvió. Esto sería bueno para que todos aprendan de tu propia
experiencia.
26. Las medidas punitorias, si es que fueran necesarias por el bien
del grupo, quedan a consideración de la administración del mismo.
Las mismas pueden, dependiendo de la gravedad del incidente, ir
desde la cancelación temporal de determinados beneficios --envío
de mensajes sin moderación (revisión), envío de adjuntos,
etcétera-- hasta la suspensión definitiva de este y otros grupos
--en especial para el caso de insultos gratuitos, publicidades
desleales y/o fuera de tema, repetidos envíos de virus (aunque
sean involuntarios), etcétera.
27. Los antivirus, incluso gratuitos, existen. No te expongas ni
expongas al grupo a los virus. Si no tenés instalado un antivirus
en tu equipo, hacelo a la brevedad. Si no sabés de dónde bajar
uno, podés usar el AVG Anti-Virus System, que puede descargarse
gratuitamente desde http://www.grisoft.com/
28. NUNCA pidas ser desuscripto enviando un mensaje al grupo. Ninguno
de los miembros puede hacer nada para llevar a cabo tal tarea.
Por otro lado, al suscribirte recibís un mensaje que te explica
cómo desuscribirte, ya sea por correo electrónico o por el sitio
del grupo. Asimismo, al pie de todos y cada uno de los mensajes
que se publican en el grupo TAMBIÉN están las instrucciones
necesarias para desuscribirse. Los miembros más experimentados de
los grupos de discusión suelen considerar como "poco inteligente"
a quien solicita su desuscripción mediante un mensaje al grupo.
No querés que te suceda eso.
Una vez que pidas la desuscripción mediante alguno de los medios
adecuados, tené paciencia. La misma se llevará a cabo
automáticamente y la demora en hacerlo está dada por la carga de
trabajo que tengan los servidores de Yahoo! Grupos: puede ser
inmediata o tardar varias horas.
_____________________________________________________________________
Estas reglas están basadas en los lineamientos de netiquette básicos
para correo electrónico propuestos por Netiqueta, un sitio web de la
Sociedad de las Indias Electrónicas (URL: http://www.netiqueta.org/),
el documento "Cómo Hacer Preguntas de Manera Inteligente" escrito por
Eric S. Raymond, por la propia experiencia después de varios años de
administrar foros, listas y grupos de discusión, y por las
sugerencias que los miembros de este y otros grupos van haciendo en
la búsqueda de la mejora de este, su espacio, el espacio de todos.
Cuidémoslo y mejorémoslo entre todos.
Si bien no se plantean como obligatorias, su cumplimiento es
importante por una cuestión de respeto al espacio y al resto de los
miembros.
Luis se debe establecer en una clausula del contrato que se entrega el código fuente, en el caso que se manupule por alguna necesidad la empresa de Software ya deja de tener responsabilidad sobre el código.
Esta cláúsula debe estar dentro del contrato.
----- Mensaje original ---- De: Sandra Lía Benvenuto <slbenvenuto@...> Para: AsegCalidadSoftware@... Enviado: jueves 31 de julio de 2008, 14:14:49 Asunto: Re: [ACS] Software con codigo fuente
Luis, coincido con vos, y entiendo que una buena práctica puede ser la última que mencionas.
De hecho, me consta que en algunos lugares es la decisión que se toma sobre los fuentes de proveedores.
Saludos. Sandra
--- El mié 30-jul-08, Luis R. Gordillo <gordilloluis@ yahoo.com. ar> escribió:
De: Luis R. Gordillo <gordilloluis@ yahoo.com. ar> Asunto: [ACS] Software con codigo fuente Para: AsegCalidadSoftware @gruposyahoo. com.ar Fecha: miércoles, 30 de julio de 2008, 3:24 pm
Hola a todos:
Este grupo puede conocer o tener experiencias sobre comercializació n de software y es por eso que me dirijo a ustedes.
El dilema sobre entregar o no el código fuente del software desarrollado para una empresa debido a razones que se comenta a continuación.
Una empresa X contrata a una empresa de software para que desarrolle una solución a medida.
Entonces la empresa de software desarrolla una aplicación en base a su experiencia utilizando técnicas propias que fueron evolucionando en rutinas de gran calidad técnica y que producen al final un software de gran calidad.
La empresa X obtiene una solución a medida de gran calidad técnica que cumple con los objetivos solicitados.
Al transcurrir el tiempo la empresa necesita algunos cambios en el sistema.
Aquí surgen los problemas y pueden darse los siguientes casos:
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio razonable.
Esto sería lo mejor y todos contentos.
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio abusivo ya que nadie mas puede hacer estos cambios.
- La empresa desarrolladora no puede hacer estos cambios por diferentes razones. (Quiebra, falta de tiempo, desinterés en el proyecto, o simplemente por que ya no existe).
En estos casos (y cualquier otro similar que se les ocurra) perjudica a la empresa X que compró el software ya que no puede adaptarlo a sus necesidades.
Como puede cubrirse la empresa X?
Al comprar el software puede solicitar el código fuente y la documentación necesaria para no depender del proveedor.
Ventajas.
No depende del proveedor.
Puede adaptarlo a sus necesidades cada vez que se necesite.
Garantiza que su inversión inicial de compra no se pierda al no tener que recurrir a un nuevo software.
Desventaja
Costo muy elevado de adquisición.
Curva de aprendizaje por parte de 3ro en realizar la actualización muy pronunciada.
Costo elevado en dinero y tiempo hasta poder realizar las actualizaciones.
Aun al no depender del proveedor original es posible que los costos sean mayores por actualización.
Deberá mantener a la misma empresa 3ro para futuras actualizaciones, ya que de lo contrario deberá buscar uno nuevo con las consiguientes desventajas.
Pero hasta aquí solo se habla de la empresa X.
La otra parte, la empresa de desarrollo probablemente no quiera vender sus código fuentes ya que sería develar el "secreto" de su negocio y por lo tanto quedar expuesto a copias y competencias desleales, perder su ventaja técnica fruto de su trabajo y experiencia.
E aquí el problema como desarrollador.
Como debería pactarse el contrato en un caso como éste donde la empresa X desee estar protegido según todo lo expuesto anteriormente?
Debería cobrarse un precio mucho mas elevado para entregar el código fuente? Y cuanto mas elevado?
Puede conservar su propiedad intelectual aun cediendo el código fuente para uso interno de la empresa X?
Que pasa con las filtraciones de información al contratar a terceros? Que garantía puede dar la empresa X?
No sería mejor establecer una cláusula en la que se entregue los código fuentes y solo se recurra a un tercero en caso de que el desarrollador original no pueda cumplir o sea abusivo?
La idea sería entregar los fuentes ante una entidad jurídica que libere los fuentes para la empresa X solo en caso de que la empresa desarrolladora incumpliese el contrato o se viese imposibilitada de continuar.
Agradecería sus opiniones, ideas y experiencias.
Desde ya muchas gracias.
Luis.
¡Buscá desde tu celular! Yahoo! oneSEARCH ahora está en Claro http://ar.mobile. yahoo.com/ onesearch
¡Buscá desde tu celular!
Yahoo! oneSEARCH ahora está en Claro
http://ar.mobile.yahoo.com/onesearch
Luis, coincido con vos, y entiendo que una buena práctica puede ser la última que mencionas.
De hecho, me consta que en algunos lugares es la decisión que se toma sobre los fuentes de proveedores.
Saludos. Sandra
--- El mié 30-jul-08, Luis R. Gordillo <gordilloluis@...> escribió:
De: Luis R. Gordillo <gordilloluis@...> Asunto: [ACS] Software con codigo fuente Para: AsegCalidadSoftware@... Fecha: miércoles, 30 de julio de 2008, 3:24 pm
Hola a todos:
Este grupo puede conocer o tener experiencias sobre comercializació n de software y es por eso que me dirijo a ustedes.
El dilema sobre entregar o no el código fuente del software desarrollado para una empresa debido a razones que se comenta a continuación.
Una empresa X contrata a una empresa de software para que desarrolle una solución a medida.
Entonces la empresa de software desarrolla una aplicación en base a su experiencia utilizando técnicas propias que fueron evolucionando en rutinas de gran calidad técnica y que producen al final un software de gran calidad.
La empresa X obtiene una solución a medida de gran calidad técnica que cumple con los objetivos solicitados.
Al transcurrir el tiempo la empresa necesita algunos cambios en el sistema.
Aquí surgen los problemas y pueden darse los siguientes casos:
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio razonable.
Esto sería lo mejor y todos contentos.
- La empresa desarrolladora puede hacer estos cambios y cobrar un precio abusivo ya que nadie mas puede hacer estos cambios.
- La empresa desarrolladora no puede hacer estos cambios por diferentes razones. (Quiebra, falta de tiempo, desinterés en el proyecto, o simplemente por que ya no existe).
En estos casos (y cualquier otro similar que se les ocurra) perjudica a la empresa X que compró el software ya que no puede adaptarlo a sus necesidades.
Como puede cubrirse la empresa X?
Al comprar el software puede solicitar el código fuente y la documentación necesaria para no depender del proveedor.
Ventajas.
No depende del proveedor.
Puede adaptarlo a sus necesidades cada vez que se necesite.
Garantiza que su inversión inicial de compra no se pierda al no tener que recurrir a un nuevo software.
Desventaja
Costo muy elevado de adquisición.
Curva de aprendizaje por parte de 3ro en realizar la actualización muy pronunciada.
Costo elevado en dinero y tiempo hasta poder realizar las actualizaciones.
Aun al no depender del proveedor original es posible que los costos sean mayores por actualización.
Deberá mantener a la misma empresa 3ro para futuras actualizaciones, ya que de lo contrario deberá buscar uno nuevo con las consiguientes desventajas.
Pero hasta aquí solo se habla de la empresa X.
La otra parte, la empresa de desarrollo probablemente no quiera vender sus código fuentes ya que sería develar el “secreto” de su negocio y por lo tanto quedar expuesto a copias y competencias desleales, perder su ventaja técnica fruto de su trabajo y experiencia.
E aquí el problema como desarrollador.
Como debería pactarse el contrato en un caso como éste donde la empresa X desee estar protegido según todo lo expuesto anteriormente?
Debería cobrarse un precio mucho mas elevado para entregar el código fuente? Y cuanto mas elevado?
Puede conservar su propiedad intelectual aun cediendo el código fuente para uso interno de la empresa X?
Que pasa con las filtraciones de información al contratar a terceros? Que garantía puede dar la empresa X?
No sería mejor establecer una cláusula en la que se entregue los código fuentes y solo se recurra a un tercero en caso de que el desarrollador original no pueda cumplir o sea abusivo?
La idea sería entregar los fuentes ante una entidad jurídica que libere los fuentes para la empresa X solo en caso de que la empresa desarrolladora incumpliese el contrato o se viese imposibilitada de continuar.
Agradecería sus opiniones, ideas y experiencias.
Desde ya muchas gracias.
Luis.
¡Buscá desde tu celular!
Yahoo! oneSEARCH ahora está en Claro
http://ar.mobile.yahoo.com/onesearch
Este grupo puede conocer o tener experiencias sobre comercialización de
software y es por eso que me dirijo a ustedes.
El dilema sobre entregar o no el código fuente del software
desarrollado para una empresa debido a razones que se comenta a continuación.
Una empresa X contrata a una empresa de software para que desarrolle
una solución a medida.
Entonces la empresa de software desarrolla una aplicación en base a su
experiencia utilizando técnicas propias que fueron evolucionando en rutinas de
gran calidad técnica y que producen al final un software de gran calidad.
La empresa X obtiene una solución a medida de gran calidad técnica que
cumple con los objetivos solicitados.
Al transcurrir el tiempo la empresa necesita algunos cambios en el
sistema.
Aquí surgen los problemas y pueden darse los siguientes casos:
- La empresa desarrolladora puede hacer estos cambios y cobrar un
precio razonable.
Esto sería lo mejor y todos contentos.
- La empresa desarrolladora puede hacer estos cambios y cobrar un
precio abusivo ya que nadie mas puede hacer estos cambios.
- La empresa desarrolladora no puede hacer estos cambios por diferentes
razones. (Quiebra, falta de tiempo, desinterés en el proyecto, o simplemente
por que ya no existe).
En estos casos (y cualquier otro similar que se les ocurra) perjudica a
la empresa X que compró el software ya que no puede adaptarlo a sus
necesidades.
Como puede cubrirse la empresa X?
Al comprar el software puede solicitar el código fuente y la
documentación necesaria para no depender del proveedor.
Ventajas.
No depende del proveedor.
Puede adaptarlo a sus necesidades cada vez que se necesite.
Garantiza que su inversión inicial de compra no se pierda al no tener
que recurrir a un nuevo software.
Desventaja
Costo muy elevado de adquisición.
Curva de aprendizaje por parte de 3ro en realizar la actualización muy pronunciada.
Costo elevado en dinero y tiempo hasta poder realizar las actualizaciones.
Aun al no depender del proveedor original es posible que los costos
sean mayores por actualización.
Deberá mantener a la misma empresa 3ro para futuras actualizaciones, ya
que de lo contrario deberá buscar uno nuevo con las consiguientes desventajas.
Pero hasta aquí solo se habla de la empresa X.
La otra parte, la empresa de desarrollo probablemente no quiera vender
sus código fuentes ya que sería develar el “secreto” de su negocio
y por lo tanto quedar expuesto a copias y competencias desleales, perder su
ventaja técnica fruto de su trabajo y experiencia.
E aquí el problema como desarrollador.
Como debería pactarse el contrato en un caso como éste donde la empresa
X desee estar protegido según todo lo expuesto anteriormente?
Debería cobrarse un precio mucho mas elevado para entregar el código
fuente? Y cuanto mas elevado?
Puede conservar su propiedad intelectual aun cediendo el código fuente
para uso interno de la empresa X?
Que pasa con las filtraciones de información al contratar a terceros? Que
garantía puede dar la empresa X?
No sería mejor establecer una cláusula en la que se entregue los código
fuentes y solo se recurra a un tercero en caso de que el desarrollador original
no pueda cumplir o sea abusivo?
La idea sería entregar los fuentes ante una entidad jurídica que libere
los fuentes para la empresa X solo en caso de que la empresa desarrolladora
incumpliese el contrato o se viese imposibilitada de continuar.
SEPGSM LA Conferencia
Quinta conferencia anual SEPGSM Latinoamérica
12-13 y 14 noviembre, Mar del Plata, Argentina
"Combinando Disciplina con Métodos Ágiles"
Web: http://www.esi.es/SEPGLA/
CONVOCATORIA DE PONENCIAS PARA PRESENTACIONES, PANELES Y SEMINARIOS
Plazo para la entrega de las propuestas ampliado: 2de julio, 2008
FECHAS CLAVE DE LA CONVOCATORIA
Entrega de resúmenes: 2 de julio
Notificación a ponentes: 5 de agosto
Entrega documentación final: 2 de septiembre
ENTREGA DE RESUMENES ON LINE: http://www.esi.es/SEPGLA/
TEMAS
Los temas para los que solicitamos resúmenes son:
1. Combinando disciplina con métodos ágiles
2. Que significa competitividad en el mercado global de TI?
3. Mejora de Procesos en situaciones de estrés
4. Mejora de procesos interoperable
5. Cómo prepararse para las evaluaciones y sobrevivir a ellas
6. Iniciación a la mejora de procesos
7. Mejora de procesos en entornos pequeños
8. Mejora de procesos en entornos diversos
9. Mejora de procesos en entornos de servicios
10. Alcanzando y trabajando en entornos de alta madurez
11. Herramientas, técnicas y conocimientos para la mejora de
procesos
12. Implementación de procesos específicos
INFORMACION MAS COMPLETA SOBRE LOS TEMAS DE LA CONFERENCIA:
http://www.esi.es/SEPGLA/sepglaProposals_spa.php
Para más información: sepgla@...
Título...: NORMAS BÁSICAS DE COMPORTAMIENTO EN EL GRUPO
Versión..: 1.1
Fecha....: 2003-09-01
_____________________________________________________________________
1. Intentá no enviar mensajes en formato HTML u otros distintos al
básico. Pesan más sin aportar gran cosa. Podés saber si estás
escribiendo un mensaje en HTML porque tu mailer (el programa de
correo electrónico) te ofrecerá opciones de edición extra, como
letra en negrita o color.
2. No envíes al grupo archivos adjuntos de un tamaño superior a los
100 Kb por medio del correo electrónico. En su lugar, utilizá el
área de archivos del grupo que para ello está.
Además, si bien Yahoo! Grupos entrega todos los archivos adjuntos
que se envían por medio del correo electrónico, estos no se
guardan en el área de mensajes; por ello, los archivos e imágenes
que quieras subir y compartir deberán estar en las áreas de
archivos y fotos del grupo.
3. No pidas confirmación automática de los mensajes que envíes. Es
de pésima educación, pues supone colocar al receptor de tu
mensaje en la disyuntiva de elegir entre que pienses que no lo
recibió y enviarte información personal que no tiene por qué
compartir con vos.
4. No envíes correos masivos y, sobre todo, no los reenvíes. Si
enviás por necesidad un correo a una lista de personas, colocá
sus direcciones en el campo de "Copia Oculta" (CCO). Muchas
personas pueden querer que tengas su correo electrónico, pero no
todos tus contactos y menos tanta gente que participa de un grupo
de discusión.
5. Nunca envíes mensajes en cadena. Las alarmas de virus y las
cadenas de mensajes son por definición FALSAS y su único objetivo
es saturar los servidores y con ellos la red. En los viejos
tiempos, tus privilegios en la red hubieran sido cancelados.
6. Saludá antes del mensaje indicando a quién o a quiénes te
dirigís, y despedite con tu nombre, exactamente igual que harías
con una carta física. Añadí una línea o dos al final de tu
mensaje con información de contacto. Esto es importante ya que
dirigirse a quién sea sin decir quién sos es una actitud pueril,
propia de niños en rebeldía, y una enorme falta de respeto. Es
muy desagradable responder anónimos o a entes que no aportan la
suficiente información para tratarlos con cortesía.
7. Cuando hagas una pregunta al grupo, destacá lo que hayas
aprendido a partir de haber intentado encontrar una respuesta
leyendo material bibliográfico, buscando en la web, preguntándole
a un amigo con más experiencia, etcétera. Generalmente, a los
miembros más experimentados de los grupos de discusión les gusta
responder a la gente que ha demostrado ser capaz de aprender de
las respuestas. Prepará tu pregunta. Pensá en ella. Las preguntas
precipitadas reciben respuestas precipitadas o ni siquiera eso.
Cuanto más hagas para demostrar que has puesto pensamiento y
esfuerzo en resolver tu problema antes de pedir ayuda, más cerca
estarás de recibirla realmente. Realmente, te ganarás una
respuesta si hacés una pregunta sustancial, interesante y que
haga pensar, una que contribuya implícitamente a la experiencia
de la comunidad antes que solicitar de manera pasiva conocimiento
de los demás.
Por otra parte, un muy buen comienzo es dejar claro que podés y
querés participar en el proceso de desarrollar la solución.
"¿Tiene alguien alguna pista?", "¿Qué le falta a mi ejemplo?" y
"¿Hay alguna página que debiera haber consultado?" tendrán más
probabilidades de ser respondidas que "Publicá por favor el
procedimiento exacto que debería seguir", porque estás dejando
claro que estás realmente deseoso de completar el proceso si
alguien simplemente te orienta en la dirección correcta.
8. Sabemos por experiencia que los escritores descuidados y
chapuceros también piensan de manera desordenada y chapucera --a
menudo lo suficiente como para apostar por ello, no obstante.
Responder a pensadores descuidados y chapuceros no recompensa;
mejor estaríamos usando nuestro tiempo en cualquier otro lugar.
Por esto, es importante expresar tu pregunta de manera clara. Si
no podés molestarte en hacer eso, el resto de los miembros del
grupo no pueden molestarse en prestarte atención. Aprovechá el
esfuerzo añadido en pulir tu lenguaje. No tiene que ser nada
estirado ni formal; de hecho, la cultura de los grupos de
discusión valora el lenguaje informal y cómico usado con
precisión. Pero tiene que ser preciso: tiene que haber alguna
indicación de que estás pensando y prestando atención.
Deletreá correctamente. Escribir como un lammer --hAzI3Nd0t3
pAzAr p0r iNt3lIg3nT3 3zKrIbI3Nd0 k0m0 iMb3zIl-- es el beso de la
muerte absoluto y te garantiza que no recibirás otra cosa que
un silencio sepulcral o, si tenés suerte, un montón de desprecio
y sarcasmo como devolución.
9. La cortesía nunca hiere e, incluso, a veces hasta ayuda. Sé
cortés. Usá "Por favor" y "Gracias por adelantado". Dejá claro
que apreciás el tiempo que emplea la gente ayudándote gratis.
Esto no es tan importante como --y no puede sustituir a-- ser
correcto gramaticalmente, claro, preciso y descriptivo, evitar
formatos propietarios, etcétera, pero ayuda. De todos modos, si
obtuviste tus conocimientos técnicos en una tómbola, la educación
incrementará tus posibilidades de recibir una respuesta útil.
10. Recordá que la gente con quienes te comunicás, incluidos los
administradores y los miembros de los grupos a los que pertenecés
o que visitás, no cobran por responderte ni tienen obligación de
hacerlo. Son personas que si te atienden te estarán haciendo un
favor. Nunca asumas que tenés derecho a una respuesta. No lo
tenés.
11. Utilizá las mayúsculas y las minúsculas correctamente. LAS
MAYÚSCULAS DAN LA IMPRESIÓN DE QUE ESTUVIERAS GRITANDO. No hace
falta decir que escribir líneas, párrafos y mensajes enteros en
mayúscula es de pésima educación.
12. Utilizá símbolos para dar énfasis: esto *es* lo que quiero decir.
Utilizá guiones bajos para dar a entender un subrayado: _La
Guerra y la Paz_ es mi libro favorito.
13. Sé breve sin ser demasiado conciso. Cuando contestés un mensaje,
incluí el suficiente material original como para ser entendido
pero no más. Es una mala forma contestar un mensaje simplemente
incluyendo todo el mensaje anterior: borrá todo el material
irrelevante.
14. Usá títulos específicos y con sentido. En los grupos de
discusión, el título o asunto (subject) del mensaje es tu
oportunidad de oro para atraer la atención de expertos
calificados en aproximadamente 50 caracteres o menos. No los
desperdicies en balbuceos. No intentes impresionar al resto de
los miembros del grupo con lo profundo de tu angustia; usá el
espacio para una descripción superconcisa del problema en vez de
eso: el mensaje debe tener un asunto que refleje el contenido del
mismo. Los asuntos vacíos como "Urgente", "Una pregunta",
"Necesito ayuda", "Ayuda" y demás frases que no tienen nada que
ver con el contenido sino con su intención, no son adecuados para
la publicación en un grupo de discusión.
15. No envíes mensajes que estén fuera de tema para el grupo, ya que
esto puede molestar a muchos de los miembros del grupo. Tené
cuidado al elegir dónde planteás tu pregunta. Seguramente te
ignorarán o te tildarán de perdedor si publicás tu pregunta en
un grupo en el que se encuentra fuera de lugar (off-topic). Los
miembros más experimentados de los grupos de discusión suelen
descartar las preguntas inapropiadas para intentar proteger sus
canales de comunicación de lo irrelevante. No querés que te
suceda eso.
Muchas veces podés tener la respuesta a tu alcance en otro grupo
dedicado más específicamente al tema sobre el cual trata tu
consulta. Para ello, podés ayudarte con el mensaje titulado
"Grupos de Sistemas, Software, Management y Tecnologías" o
mediante el índice de Yahoo! Grupos. Si aún tomando en cuenta
estas consideraciones necesitás enviar un mensaje fuera de tema,
iniciá el asunto (subject) del mismo con las siglas "OT:", que
significan "off-topic" o "fuera de tema".
16. Tené cuidado cuando escribas la dirección de correo. Hay
direcciones que llegan a un grupo, pero la dirección parece que
va sólo a una persona. Fíjate a quién lo estás mandando.
17. Mirá el campo de "Copia" (CC) cuando contestes. Si la primera
persona que envió el mensaje se lo mandó a varios en su lista de
correo, no hagas lo mismo.
18. A no ser que usés un dispositivo de encriptación por hardware o
software, cosa que no debe hacerse cuando se escribe a un grupo
público de discusión, debés asumir que el correo en Internet no
es seguro. Nunca pongas nada en un correo electrónico que no
pondrías en una postal. Por otro lado, algunos mensajes pueden
aparecer como provenientes de otra persona distinta del autor.
Aplicá tu sentido común antes de asumir que un mensaje es válido.
19. Si pensás que la importancia de un mensaje lo justifica, contestá
inmediatamente a la dirección particular del remitente para que
sepa que lo has recibido y que estás trabajando en la respuesta,
aunque vayas a mandarle una respuesta más larga más tarde por el
grupo de discusión.
20. Las expectitivas razonables sobre conducta en el correo
electrónico dependen de tu relación con la persona y el contexto
de la comunicación, para el caso este grupo. Las normas
aprendidas en este ambiente puede que no sean aplicables para tu
comunicación por correo electrónico con gente a través de
Internet en otros contextos. Ten cuidado con el argot o siglas
locales.
21. La publicidad por correo electrónico no es bienvenida. Abstenete
de hacer publicidad que no haya sido previamente aceptada por el
administrador del grupo, en especial si se trata de publicidad
fuera de tema o que, estando en tema, sean desleales al ofrecer
beneficios inexistentes. Sólo se considerarán ofertas académicas,
bibliográficas o de software que estén relacionadas con el tema
de discusión y que les aporte una ventaja a los miembros del
grupo.
22. Si alguien ofrece un archivo y lo querés, NUNCA se lo pidas por
el grupo, sino mediante su dirección de correo privada. Los
mensajes que sólo incluyen frases como "Quiero ese archivo", "A
mí también", etcétera, son una verdadera falta de consideración
hacia el resto de los miembros del grupo, quienes no tienen por
qué soportar tales abusos.
23. Si ofrecés algún archivo, fijate primero si podés subirlo al área
de archivos del grupo. Si esto es posible, subilo y seleccioná la
opción para que se avise al grupo sobre la carga; de esta forma,
no hará falta ofrecerlo. Si no podés subirlo al área de archivos,
podés ofrecerlo al grupo mediante un mensaje, indicando en qué
formato está y su tamaño: recordá que no todo el mundo tiene
banda ancha ni buzones de 50 Mb.
24. Si alguna de las respuestas que querés enviar son de tipo
personal, incluyendo agradecimientos sin contenido adicional,
hacelo a la dirección de correo privado de la persona
destinataria de tal mensaje personal, nunca al grupo. Por el
contrario, de no ser personal es importante que lo envíes al
grupo, para que todos los miembros puedan aprender de la
experiencia y/o participar de la discusión: eso es bueno para el
grupo.
25. Si por alguna razón alguna de tus consultas se soluciona por vías
privadas, podría ser bueno para el grupo que te tomes la molestia
de avisar que la solucionaste, incluyendo la forma en que se
resolvió. Esto sería bueno para que todos aprendan de tu propia
experiencia.
26. Las medidas punitorias, si es que fueran necesarias por el bien
del grupo, quedan a consideración de la administración del mismo.
Las mismas pueden, dependiendo de la gravedad del incidente, ir
desde la cancelación temporal de determinados beneficios --envío
de mensajes sin moderación (revisión), envío de adjuntos,
etcétera-- hasta la suspensión definitiva de este y otros grupos
--en especial para el caso de insultos gratuitos, publicidades
desleales y/o fuera de tema, repetidos envíos de virus (aunque
sean involuntarios), etcétera.
27. Los antivirus, incluso gratuitos, existen. No te expongas ni
expongas al grupo a los virus. Si no tenés instalado un antivirus
en tu equipo, hacelo a la brevedad. Si no sabés de dónde bajar
uno, podés usar el AVG Anti-Virus System, que puede descargarse
gratuitamente desde http://www.grisoft.com/
28. NUNCA pidas ser desuscripto enviando un mensaje al grupo. Ninguno
de los miembros puede hacer nada para llevar a cabo tal tarea.
Por otro lado, al suscribirte recibís un mensaje que te explica
cómo desuscribirte, ya sea por correo electrónico o por el sitio
del grupo. Asimismo, al pie de todos y cada uno de los mensajes
que se publican en el grupo TAMBIÉN están las instrucciones
necesarias para desuscribirse. Los miembros más experimentados de
los grupos de discusión suelen considerar como "poco inteligente"
a quien solicita su desuscripción mediante un mensaje al grupo.
No querés que te suceda eso.
Una vez que pidas la desuscripción mediante alguno de los medios
adecuados, tené paciencia. La misma se llevará a cabo
automáticamente y la demora en hacerlo está dada por la carga de
trabajo que tengan los servidores de Yahoo! Grupos: puede ser
inmediata o tardar varias horas.
_____________________________________________________________________
Estas reglas están basadas en los lineamientos de netiquette básicos
para correo electrónico propuestos por Netiqueta, un sitio web de la
Sociedad de las Indias Electrónicas (URL: http://www.netiqueta.org/),
el documento "Cómo Hacer Preguntas de Manera Inteligente" escrito por
Eric S. Raymond, por la propia experiencia después de varios años de
administrar foros, listas y grupos de discusión, y por las
sugerencias que los miembros de este y otros grupos van haciendo en
la búsqueda de la mejora de este, su espacio, el espacio de todos.
Cuidémoslo y mejorémoslo entre todos.
Si bien no se plantean como obligatorias, su cumplimiento es
importante por una cuestión de respeto al espacio y al resto de los
miembros.
Es la opinión Sharon Cichelli, que esta semana volvía a cuestionar el valor real de la certificación ScrumMaster:
"Basta con asistir a dos días de clase. Esto es todo. Suena realmente peligroso... ...Pregúntale a un directivo a quién preferiría contratar, si a alguien con tres años de experiencia trabajando en equipos scrum, o a un Scrum Master Certificado (trompetas y fanfarrias). Los que conocen Scrum saben que ScrumMaster es el nombre de un rol, pero a los que no saben de Scrum les suena a dos palabras, con un espacio en medio: Srum Master, el experto del proceso"
Título...: NORMAS BÁSICAS DE COMPORTAMIENTO EN EL GRUPO
Versión..: 1.1
Fecha....: 2003-09-01
_____________________________________________________________________
1. Intentá no enviar mensajes en formato HTML u otros distintos al
básico. Pesan más sin aportar gran cosa. Podés saber si estás
escribiendo un mensaje en HTML porque tu mailer (el programa de
correo electrónico) te ofrecerá opciones de edición extra, como
letra en negrita o color.
2. No envíes al grupo archivos adjuntos de un tamaño superior a los
100 Kb por medio del correo electrónico. En su lugar, utilizá el
área de archivos del grupo que para ello está.
Además, si bien Yahoo! Grupos entrega todos los archivos adjuntos
que se envían por medio del correo electrónico, estos no se
guardan en el área de mensajes; por ello, los archivos e imágenes
que quieras subir y compartir deberán estar en las áreas de
archivos y fotos del grupo.
3. No pidas confirmación automática de los mensajes que envíes. Es
de pésima educación, pues supone colocar al receptor de tu
mensaje en la disyuntiva de elegir entre que pienses que no lo
recibió y enviarte información personal que no tiene por qué
compartir con vos.
4. No envíes correos masivos y, sobre todo, no los reenvíes. Si
enviás por necesidad un correo a una lista de personas, colocá
sus direcciones en el campo de "Copia Oculta" (CCO). Muchas
personas pueden querer que tengas su correo electrónico, pero no
todos tus contactos y menos tanta gente que participa de un grupo
de discusión.
5. Nunca envíes mensajes en cadena. Las alarmas de virus y las
cadenas de mensajes son por definición FALSAS y su único objetivo
es saturar los servidores y con ellos la red. En los viejos
tiempos, tus privilegios en la red hubieran sido cancelados.
6. Saludá antes del mensaje indicando a quién o a quiénes te
dirigís, y despedite con tu nombre, exactamente igual que harías
con una carta física. Añadí una línea o dos al final de tu
mensaje con información de contacto. Esto es importante ya que
dirigirse a quién sea sin decir quién sos es una actitud pueril,
propia de niños en rebeldía, y una enorme falta de respeto. Es
muy desagradable responder anónimos o a entes que no aportan la
suficiente información para tratarlos con cortesía.
7. Cuando hagas una pregunta al grupo, destacá lo que hayas
aprendido a partir de haber intentado encontrar una respuesta
leyendo material bibliográfico, buscando en la web, preguntándole
a un amigo con más experiencia, etcétera. Generalmente, a los
miembros más experimentados de los grupos de discusión les gusta
responder a la gente que ha demostrado ser capaz de aprender de
las respuestas. Prepará tu pregunta. Pensá en ella. Las preguntas
precipitadas reciben respuestas precipitadas o ni siquiera eso.
Cuanto más hagas para demostrar que has puesto pensamiento y
esfuerzo en resolver tu problema antes de pedir ayuda, más cerca
estarás de recibirla realmente. Realmente, te ganarás una
respuesta si hacés una pregunta sustancial, interesante y que
haga pensar, una que contribuya implícitamente a la experiencia
de la comunidad antes que solicitar de manera pasiva conocimiento
de los demás.
Por otra parte, un muy buen comienzo es dejar claro que podés y
querés participar en el proceso de desarrollar la solución.
"¿Tiene alguien alguna pista?", "¿Qué le falta a mi ejemplo?" y
"¿Hay alguna página que debiera haber consultado?" tendrán más
probabilidades de ser respondidas que "Publicá por favor el
procedimiento exacto que debería seguir", porque estás dejando
claro que estás realmente deseoso de completar el proceso si
alguien simplemente te orienta en la dirección correcta.
8. Sabemos por experiencia que los escritores descuidados y
chapuceros también piensan de manera desordenada y chapucera --a
menudo lo suficiente como para apostar por ello, no obstante.
Responder a pensadores descuidados y chapuceros no recompensa;
mejor estaríamos usando nuestro tiempo en cualquier otro lugar.
Por esto, es importante expresar tu pregunta de manera clara. Si
no podés molestarte en hacer eso, el resto de los miembros del
grupo no pueden molestarse en prestarte atención. Aprovechá el
esfuerzo añadido en pulir tu lenguaje. No tiene que ser nada
estirado ni formal; de hecho, la cultura de los grupos de
discusión valora el lenguaje informal y cómico usado con
precisión. Pero tiene que ser preciso: tiene que haber alguna
indicación de que estás pensando y prestando atención.
Deletreá correctamente. Escribir como un lammer --hAzI3Nd0t3
pAzAr p0r iNt3lIg3nT3 3zKrIbI3Nd0 k0m0 iMb3zIl-- es el beso de la
muerte absoluto y te garantiza que no recibirás otra cosa que
un silencio sepulcral o, si tenés suerte, un montón de desprecio
y sarcasmo como devolución.
9. La cortesía nunca hiere e, incluso, a veces hasta ayuda. Sé
cortés. Usá "Por favor" y "Gracias por adelantado". Dejá claro
que apreciás el tiempo que emplea la gente ayudándote gratis.
Esto no es tan importante como --y no puede sustituir a-- ser
correcto gramaticalmente, claro, preciso y descriptivo, evitar
formatos propietarios, etcétera, pero ayuda. De todos modos, si
obtuviste tus conocimientos técnicos en una tómbola, la educación
incrementará tus posibilidades de recibir una respuesta útil.
10. Recordá que la gente con quienes te comunicás, incluidos los
administradores y los miembros de los grupos a los que pertenecés
o que visitás, no cobran por responderte ni tienen obligación de
hacerlo. Son personas que si te atienden te estarán haciendo un
favor. Nunca asumas que tenés derecho a una respuesta. No lo
tenés.
11. Utilizá las mayúsculas y las minúsculas correctamente. LAS
MAYÚSCULAS DAN LA IMPRESIÓN DE QUE ESTUVIERAS GRITANDO. No hace
falta decir que escribir líneas, párrafos y mensajes enteros en
mayúscula es de pésima educación.
12. Utilizá símbolos para dar énfasis: esto *es* lo que quiero decir.
Utilizá guiones bajos para dar a entender un subrayado: _La
Guerra y la Paz_ es mi libro favorito.
13. Sé breve sin ser demasiado conciso. Cuando contestés un mensaje,
incluí el suficiente material original como para ser entendido
pero no más. Es una mala forma contestar un mensaje simplemente
incluyendo todo el mensaje anterior: borrá todo el material
irrelevante.
14. Usá títulos específicos y con sentido. En los grupos de
discusión, el título o asunto (subject) del mensaje es tu
oportunidad de oro para atraer la atención de expertos
calificados en aproximadamente 50 caracteres o menos. No los
desperdicies en balbuceos. No intentes impresionar al resto de
los miembros del grupo con lo profundo de tu angustia; usá el
espacio para una descripción superconcisa del problema en vez de
eso: el mensaje debe tener un asunto que refleje el contenido del
mismo. Los asuntos vacíos como "Urgente", "Una pregunta",
"Necesito ayuda", "Ayuda" y demás frases que no tienen nada que
ver con el contenido sino con su intención, no son adecuados para
la publicación en un grupo de discusión.
15. No envíes mensajes que estén fuera de tema para el grupo, ya que
esto puede molestar a muchos de los miembros del grupo. Tené
cuidado al elegir dónde planteás tu pregunta. Seguramente te
ignorarán o te tildarán de perdedor si publicás tu pregunta en
un grupo en el que se encuentra fuera de lugar (off-topic). Los
miembros más experimentados de los grupos de discusión suelen
descartar las preguntas inapropiadas para intentar proteger sus
canales de comunicación de lo irrelevante. No querés que te
suceda eso.
Muchas veces podés tener la respuesta a tu alcance en otro grupo
dedicado más específicamente al tema sobre el cual trata tu
consulta. Para ello, podés ayudarte con el mensaje titulado
"Grupos de Sistemas, Software, Management y Tecnologías" o
mediante el índice de Yahoo! Grupos. Si aún tomando en cuenta
estas consideraciones necesitás enviar un mensaje fuera de tema,
iniciá el asunto (subject) del mismo con las siglas "OT:", que
significan "off-topic" o "fuera de tema".
16. Tené cuidado cuando escribas la dirección de correo. Hay
direcciones que llegan a un grupo, pero la dirección parece que
va sólo a una persona. Fíjate a quién lo estás mandando.
17. Mirá el campo de "Copia" (CC) cuando contestes. Si la primera
persona que envió el mensaje se lo mandó a varios en su lista de
correo, no hagas lo mismo.
18. A no ser que usés un dispositivo de encriptación por hardware o
software, cosa que no debe hacerse cuando se escribe a un grupo
público de discusión, debés asumir que el correo en Internet no
es seguro. Nunca pongas nada en un correo electrónico que no
pondrías en una postal. Por otro lado, algunos mensajes pueden
aparecer como provenientes de otra persona distinta del autor.
Aplicá tu sentido común antes de asumir que un mensaje es válido.
19. Si pensás que la importancia de un mensaje lo justifica, contestá
inmediatamente a la dirección particular del remitente para que
sepa que lo has recibido y que estás trabajando en la respuesta,
aunque vayas a mandarle una respuesta más larga más tarde por el
grupo de discusión.
20. Las expectitivas razonables sobre conducta en el correo
electrónico dependen de tu relación con la persona y el contexto
de la comunicación, para el caso este grupo. Las normas
aprendidas en este ambiente puede que no sean aplicables para tu
comunicación por correo electrónico con gente a través de
Internet en otros contextos. Ten cuidado con el argot o siglas
locales.
21. La publicidad por correo electrónico no es bienvenida. Abstenete
de hacer publicidad que no haya sido previamente aceptada por el
administrador del grupo, en especial si se trata de publicidad
fuera de tema o que, estando en tema, sean desleales al ofrecer
beneficios inexistentes. Sólo se considerarán ofertas académicas,
bibliográficas o de software que estén relacionadas con el tema
de discusión y que les aporte una ventaja a los miembros del
grupo.
22. Si alguien ofrece un archivo y lo querés, NUNCA se lo pidas por
el grupo, sino mediante su dirección de correo privada. Los
mensajes que sólo incluyen frases como "Quiero ese archivo", "A
mí también", etcétera, son una verdadera falta de consideración
hacia el resto de los miembros del grupo, quienes no tienen por
qué soportar tales abusos.
23. Si ofrecés algún archivo, fijate primero si podés subirlo al área
de archivos del grupo. Si esto es posible, subilo y seleccioná la
opción para que se avise al grupo sobre la carga; de esta forma,
no hará falta ofrecerlo. Si no podés subirlo al área de archivos,
podés ofrecerlo al grupo mediante un mensaje, indicando en qué
formato está y su tamaño: recordá que no todo el mundo tiene
banda ancha ni buzones de 50 Mb.
24. Si alguna de las respuestas que querés enviar son de tipo
personal, incluyendo agradecimientos sin contenido adicional,
hacelo a la dirección de correo privado de la persona
destinataria de tal mensaje personal, nunca al grupo. Por el
contrario, de no ser personal es importante que lo envíes al
grupo, para que todos los miembros puedan aprender de la
experiencia y/o participar de la discusión: eso es bueno para el
grupo.
25. Si por alguna razón alguna de tus consultas se soluciona por vías
privadas, podría ser bueno para el grupo que te tomes la molestia
de avisar que la solucionaste, incluyendo la forma en que se
resolvió. Esto sería bueno para que todos aprendan de tu propia
experiencia.
26. Las medidas punitorias, si es que fueran necesarias por el bien
del grupo, quedan a consideración de la administración del mismo.
Las mismas pueden, dependiendo de la gravedad del incidente, ir
desde la cancelación temporal de determinados beneficios --envío
de mensajes sin moderación (revisión), envío de adjuntos,
etcétera-- hasta la suspensión definitiva de este y otros grupos
--en especial para el caso de insultos gratuitos, publicidades
desleales y/o fuera de tema, repetidos envíos de virus (aunque
sean involuntarios), etcétera.
27. Los antivirus, incluso gratuitos, existen. No te expongas ni
expongas al grupo a los virus. Si no tenés instalado un antivirus
en tu equipo, hacelo a la brevedad. Si no sabés de dónde bajar
uno, podés usar el AVG Anti-Virus System, que puede descargarse
gratuitamente desde http://www.grisoft.com/
28. NUNCA pidas ser desuscripto enviando un mensaje al grupo. Ninguno
de los miembros puede hacer nada para llevar a cabo tal tarea.
Por otro lado, al suscribirte recibís un mensaje que te explica
cómo desuscribirte, ya sea por correo electrónico o por el sitio
del grupo. Asimismo, al pie de todos y cada uno de los mensajes
que se publican en el grupo TAMBIÉN están las instrucciones
necesarias para desuscribirse. Los miembros más experimentados de
los grupos de discusión suelen considerar como "poco inteligente"
a quien solicita su desuscripción mediante un mensaje al grupo.
No querés que te suceda eso.
Una vez que pidas la desuscripción mediante alguno de los medios
adecuados, tené paciencia. La misma se llevará a cabo
automáticamente y la demora en hacerlo está dada por la carga de
trabajo que tengan los servidores de Yahoo! Grupos: puede ser
inmediata o tardar varias horas.
_____________________________________________________________________
Estas reglas están basadas en los lineamientos de netiquette básicos
para correo electrónico propuestos por Netiqueta, un sitio web de la
Sociedad de las Indias Electrónicas (URL: http://www.netiqueta.org/),
el documento "Cómo Hacer Preguntas de Manera Inteligente" escrito por
Eric S. Raymond, por la propia experiencia después de varios años de
administrar foros, listas y grupos de discusión, y por las
sugerencias que los miembros de este y otros grupos van haciendo en
la búsqueda de la mejora de este, su espacio, el espacio de todos.
Cuidémoslo y mejorémoslo entre todos.
Si bien no se plantean como obligatorias, su cumplimiento es
importante por una cuestión de respeto al espacio y al resto de los
miembros.
B. Crosby en su libro "Quality is Free" (1979) definió l a Quality Management Maturity Grid" (QMMG) para determinar el grado de desarrollo y asentamiento de los procesos de una organización en un rango de cinco escalones que denominó:
Es el concepto que tomó CMM / CMMI para definir sus cinco niveles de madurez, y que empleado para representar, no la dimensión de la organización en madurez de procesos, sino la dimensión en agilidad se podría esbozar como algo así:
Please distribute this email. Data on both agile and plan-driven
projects are welcome.
To Whom It May Concern,
My name is Donald Buresh, and I am a Ph.D. student at Northcentral
University located in Prescott Valley, Arizona. The reason that I am
writing to you is because I would like you to participate in an
internet survey for my dissertation. The topic of my dissertation is
assessing agile project management and customer satisfaction. The web
site where you can find my survey is: www.assessingagilepm.com.
The questionnaire will ask you about a software development project
that was recently completed within your organization. It will take
you about 15 minutes to answer the questions. The questionnaire will
ask you a series of questions about the project, including whether
the software product was developed using agile-driven or plan-driven
methods. If you do not know the answer, the questionnaire will ask
you a series of three questions, and based on your responses, it is
smart enough to decide what software methodology was employed. The
questionnaire will then ask you other questions about the software
development project. If at any time you decide not to participate in
the survey, you need only exit the survey window, and your data will
not be collected. When you have completed the survey, please press
the appropriate button to submit your responses, and then close the
survey window.
All of your responses will be anonymous and all of your data will be
held in the strictest confidence. From your responses, it will not be
possible to identify you or your organization. Since the data
obtained from this questionnaire will be used in my doctoral
dissertation, the results may possibly appear in an academic or trade
publication. None of your responses will ever be revealed.
Thank you for considering to participate in this survey. If you do
participate in the survey, and want to obtain a copy of my
dissertation, please do not hesitate to respond to this email, and
let me know. When the degree has been granted, and the dissertation
has been accepted and published, I will be more than happy to send
you an electronic copy. Again, thank you for your time.
Donald L. Buresh
3115 Enoch Avenue
Zion, IL 60099
Home Tele: 847-872-1659
Título...: NORMAS BÁSICAS DE COMPORTAMIENTO EN EL GRUPO
Versión..: 1.1
Fecha....: 2003-09-01
_____________________________________________________________________
1. Intentá no enviar mensajes en formato HTML u otros distintos al
básico. Pesan más sin aportar gran cosa. Podés saber si estás
escribiendo un mensaje en HTML porque tu mailer (el programa de
correo electrónico) te ofrecerá opciones de edición extra, como
letra en negrita o color.
2. No envíes al grupo archivos adjuntos de un tamaño superior a los
100 Kb por medio del correo electrónico. En su lugar, utilizá el
área de archivos del grupo que para ello está.
Además, si bien Yahoo! Grupos entrega todos los archivos adjuntos
que se envían por medio del correo electrónico, estos no se
guardan en el área de mensajes; por ello, los archivos e imágenes
que quieras subir y compartir deberán estar en las áreas de
archivos y fotos del grupo.
3. No pidas confirmación automática de los mensajes que envíes. Es
de pésima educación, pues supone colocar al receptor de tu
mensaje en la disyuntiva de elegir entre que pienses que no lo
recibió y enviarte información personal que no tiene por qué
compartir con vos.
4. No envíes correos masivos y, sobre todo, no los reenvíes. Si
enviás por necesidad un correo a una lista de personas, colocá
sus direcciones en el campo de "Copia Oculta" (CCO). Muchas
personas pueden querer que tengas su correo electrónico, pero no
todos tus contactos y menos tanta gente que participa de un grupo
de discusión.
5. Nunca envíes mensajes en cadena. Las alarmas de virus y las
cadenas de mensajes son por definición FALSAS y su único objetivo
es saturar los servidores y con ellos la red. En los viejos
tiempos, tus privilegios en la red hubieran sido cancelados.
6. Saludá antes del mensaje indicando a quién o a quiénes te
dirigís, y despedite con tu nombre, exactamente igual que harías
con una carta física. Añadí una línea o dos al final de tu
mensaje con información de contacto. Esto es importante ya que
dirigirse a quién sea sin decir quién sos es una actitud pueril,
propia de niños en rebeldía, y una enorme falta de respeto. Es
muy desagradable responder anónimos o a entes que no aportan la
suficiente información para tratarlos con cortesía.
7. Cuando hagas una pregunta al grupo, destacá lo que hayas
aprendido a partir de haber intentado encontrar una respuesta
leyendo material bibliográfico, buscando en la web, preguntándole
a un amigo con más experiencia, etcétera. Generalmente, a los
miembros más experimentados de los grupos de discusión les gusta
responder a la gente que ha demostrado ser capaz de aprender de
las respuestas. Prepará tu pregunta. Pensá en ella. Las preguntas
precipitadas reciben respuestas precipitadas o ni siquiera eso.
Cuanto más hagas para demostrar que has puesto pensamiento y
esfuerzo en resolver tu problema antes de pedir ayuda, más cerca
estarás de recibirla realmente. Realmente, te ganarás una
respuesta si hacés una pregunta sustancial, interesante y que
haga pensar, una que contribuya implícitamente a la experiencia
de la comunidad antes que solicitar de manera pasiva conocimiento
de los demás.
Por otra parte, un muy buen comienzo es dejar claro que podés y
querés participar en el proceso de desarrollar la solución.
"¿Tiene alguien alguna pista?", "¿Qué le falta a mi ejemplo?" y
"¿Hay alguna página que debiera haber consultado?" tendrán más
probabilidades de ser respondidas que "Publicá por favor el
procedimiento exacto que debería seguir", porque estás dejando
claro que estás realmente deseoso de completar el proceso si
alguien simplemente te orienta en la dirección correcta.
8. Sabemos por experiencia que los escritores descuidados y
chapuceros también piensan de manera desordenada y chapucera --a
menudo lo suficiente como para apostar por ello, no obstante.
Responder a pensadores descuidados y chapuceros no recompensa;
mejor estaríamos usando nuestro tiempo en cualquier otro lugar.
Por esto, es importante expresar tu pregunta de manera clara. Si
no podés molestarte en hacer eso, el resto de los miembros del
grupo no pueden molestarse en prestarte atención. Aprovechá el
esfuerzo añadido en pulir tu lenguaje. No tiene que ser nada
estirado ni formal; de hecho, la cultura de los grupos de
discusión valora el lenguaje informal y cómico usado con
precisión. Pero tiene que ser preciso: tiene que haber alguna
indicación de que estás pensando y prestando atención.
Deletreá correctamente. Escribir como un lammer --hAzI3Nd0t3
pAzAr p0r iNt3lIg3nT3 3zKrIbI3Nd0 k0m0 iMb3zIl-- es el beso de la
muerte absoluto y te garantiza que no recibirás otra cosa que
un silencio sepulcral o, si tenés suerte, un montón de desprecio
y sarcasmo como devolución.
9. La cortesía nunca hiere e, incluso, a veces hasta ayuda. Sé
cortés. Usá "Por favor" y "Gracias por adelantado". Dejá claro
que apreciás el tiempo que emplea la gente ayudándote gratis.
Esto no es tan importante como --y no puede sustituir a-- ser
correcto gramaticalmente, claro, preciso y descriptivo, evitar
formatos propietarios, etcétera, pero ayuda. De todos modos, si
obtuviste tus conocimientos técnicos en una tómbola, la educación
incrementará tus posibilidades de recibir una respuesta útil.
10. Recordá que la gente con quienes te comunicás, incluidos los
administradores y los miembros de los grupos a los que pertenecés
o que visitás, no cobran por responderte ni tienen obligación de
hacerlo. Son personas que si te atienden te estarán haciendo un
favor. Nunca asumas que tenés derecho a una respuesta. No lo
tenés.
11. Utilizá las mayúsculas y las minúsculas correctamente. LAS
MAYÚSCULAS DAN LA IMPRESIÓN DE QUE ESTUVIERAS GRITANDO. No hace
falta decir que escribir líneas, párrafos y mensajes enteros en
mayúscula es de pésima educación.
12. Utilizá símbolos para dar énfasis: esto *es* lo que quiero decir.
Utilizá guiones bajos para dar a entender un subrayado: _La
Guerra y la Paz_ es mi libro favorito.
13. Sé breve sin ser demasiado conciso. Cuando contestés un mensaje,
incluí el suficiente material original como para ser entendido
pero no más. Es una mala forma contestar un mensaje simplemente
incluyendo todo el mensaje anterior: borrá todo el material
irrelevante.
14. Usá títulos específicos y con sentido. En los grupos de
discusión, el título o asunto (subject) del mensaje es tu
oportunidad de oro para atraer la atención de expertos
calificados en aproximadamente 50 caracteres o menos. No los
desperdicies en balbuceos. No intentes impresionar al resto de
los miembros del grupo con lo profundo de tu angustia; usá el
espacio para una descripción superconcisa del problema en vez de
eso: el mensaje debe tener un asunto que refleje el contenido del
mismo. Los asuntos vacíos como "Urgente", "Una pregunta",
"Necesito ayuda", "Ayuda" y demás frases que no tienen nada que
ver con el contenido sino con su intención, no son adecuados para
la publicación en un grupo de discusión.
15. No envíes mensajes que estén fuera de tema para el grupo, ya que
esto puede molestar a muchos de los miembros del grupo. Tené
cuidado al elegir dónde planteás tu pregunta. Seguramente te
ignorarán o te tildarán de perdedor si publicás tu pregunta en
un grupo en el que se encuentra fuera de lugar (off-topic). Los
miembros más experimentados de los grupos de discusión suelen
descartar las preguntas inapropiadas para intentar proteger sus
canales de comunicación de lo irrelevante. No querés que te
suceda eso.
Muchas veces podés tener la respuesta a tu alcance en otro grupo
dedicado más específicamente al tema sobre el cual trata tu
consulta. Para ello, podés ayudarte con el mensaje titulado
"Grupos de Sistemas, Software, Management y Tecnologías" o
mediante el índice de Yahoo! Grupos. Si aún tomando en cuenta
estas consideraciones necesitás enviar un mensaje fuera de tema,
iniciá el asunto (subject) del mismo con las siglas "OT:", que
significan "off-topic" o "fuera de tema".
16. Tené cuidado cuando escribas la dirección de correo. Hay
direcciones que llegan a un grupo, pero la dirección parece que
va sólo a una persona. Fíjate a quién lo estás mandando.
17. Mirá el campo de "Copia" (CC) cuando contestes. Si la primera
persona que envió el mensaje se lo mandó a varios en su lista de
correo, no hagas lo mismo.
18. A no ser que usés un dispositivo de encriptación por hardware o
software, cosa que no debe hacerse cuando se escribe a un grupo
público de discusión, debés asumir que el correo en Internet no
es seguro. Nunca pongas nada en un correo electrónico que no
pondrías en una postal. Por otro lado, algunos mensajes pueden
aparecer como provenientes de otra persona distinta del autor.
Aplicá tu sentido común antes de asumir que un mensaje es válido.
19. Si pensás que la importancia de un mensaje lo justifica, contestá
inmediatamente a la dirección particular del remitente para que
sepa que lo has recibido y que estás trabajando en la respuesta,
aunque vayas a mandarle una respuesta más larga más tarde por el
grupo de discusión.
20. Las expectitivas razonables sobre conducta en el correo
electrónico dependen de tu relación con la persona y el contexto
de la comunicación, para el caso este grupo. Las normas
aprendidas en este ambiente puede que no sean aplicables para tu
comunicación por correo electrónico con gente a través de
Internet en otros contextos. Ten cuidado con el argot o siglas
locales.
21. La publicidad por correo electrónico no es bienvenida. Abstenete
de hacer publicidad que no haya sido previamente aceptada por el
administrador del grupo, en especial si se trata de publicidad
fuera de tema o que, estando en tema, sean desleales al ofrecer
beneficios inexistentes. Sólo se considerarán ofertas académicas,
bibliográficas o de software que estén relacionadas con el tema
de discusión y que les aporte una ventaja a los miembros del
grupo.
22. Si alguien ofrece un archivo y lo querés, NUNCA se lo pidas por
el grupo, sino mediante su dirección de correo privada. Los
mensajes que sólo incluyen frases como "Quiero ese archivo", "A
mí también", etcétera, son una verdadera falta de consideración
hacia el resto de los miembros del grupo, quienes no tienen por
qué soportar tales abusos.
23. Si ofrecés algún archivo, fijate primero si podés subirlo al área
de archivos del grupo. Si esto es posible, subilo y seleccioná la
opción para que se avise al grupo sobre la carga; de esta forma,
no hará falta ofrecerlo. Si no podés subirlo al área de archivos,
podés ofrecerlo al grupo mediante un mensaje, indicando en qué
formato está y su tamaño: recordá que no todo el mundo tiene
banda ancha ni buzones de 50 Mb.
24. Si alguna de las respuestas que querés enviar son de tipo
personal, incluyendo agradecimientos sin contenido adicional,
hacelo a la dirección de correo privado de la persona
destinataria de tal mensaje personal, nunca al grupo. Por el
contrario, de no ser personal es importante que lo envíes al
grupo, para que todos los miembros puedan aprender de la
experiencia y/o participar de la discusión: eso es bueno para el
grupo.
25. Si por alguna razón alguna de tus consultas se soluciona por vías
privadas, podría ser bueno para el grupo que te tomes la molestia
de avisar que la solucionaste, incluyendo la forma en que se
resolvió. Esto sería bueno para que todos aprendan de tu propia
experiencia.
26. Las medidas punitorias, si es que fueran necesarias por el bien
del grupo, quedan a consideración de la administración del mismo.
Las mismas pueden, dependiendo de la gravedad del incidente, ir
desde la cancelación temporal de determinados beneficios --envío
de mensajes sin moderación (revisión), envío de adjuntos,
etcétera-- hasta la suspensión definitiva de este y otros grupos
--en especial para el caso de insultos gratuitos, publicidades
desleales y/o fuera de tema, repetidos envíos de virus (aunque
sean involuntarios), etcétera.
27. Los antivirus, incluso gratuitos, existen. No te expongas ni
expongas al grupo a los virus. Si no tenés instalado un antivirus
en tu equipo, hacelo a la brevedad. Si no sabés de dónde bajar
uno, podés usar el AVG Anti-Virus System, que puede descargarse
gratuitamente desde http://www.grisoft.com/
28. NUNCA pidas ser desuscripto enviando un mensaje al grupo. Ninguno
de los miembros puede hacer nada para llevar a cabo tal tarea.
Por otro lado, al suscribirte recibís un mensaje que te explica
cómo desuscribirte, ya sea por correo electrónico o por el sitio
del grupo. Asimismo, al pie de todos y cada uno de los mensajes
que se publican en el grupo TAMBIÉN están las instrucciones
necesarias para desuscribirse. Los miembros más experimentados de
los grupos de discusión suelen considerar como "poco inteligente"
a quien solicita su desuscripción mediante un mensaje al grupo.
No querés que te suceda eso.
Una vez que pidas la desuscripción mediante alguno de los medios
adecuados, tené paciencia. La misma se llevará a cabo
automáticamente y la demora en hacerlo está dada por la carga de
trabajo que tengan los servidores de Yahoo! Grupos: puede ser
inmediata o tardar varias horas.
_____________________________________________________________________
Estas reglas están basadas en los lineamientos de netiquette básicos
para correo electrónico propuestos por Netiqueta, un sitio web de la
Sociedad de las Indias Electrónicas (URL: http://www.netiqueta.org/),
el documento "Cómo Hacer Preguntas de Manera Inteligente" escrito por
Eric S. Raymond, por la propia experiencia después de varios años de
administrar foros, listas y grupos de discusión, y por las
sugerencias que los miembros de este y otros grupos van haciendo en
la búsqueda de la mejora de este, su espacio, el espacio de todos.
Cuidémoslo y mejorémoslo entre todos.
Si bien no se plantean como obligatorias, su cumplimiento es
importante por una cuestión de respeto al espacio y al resto de los
miembros.
Hola, soy una estudiante de Ingenieria en Informática en Argentina. Estoy realizando mi tesis y el tema es "Modelos de Calidad para aplicaciones cliente servidor". Todo lo que encontre hasta el momento es muy poco, así que agradeceria toda información que puedierán compartir conmigo.
GRACIAS!!!
Yahoo! Encuentros Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! Encuentros. Visitá http://yahoo.cupidovirtual.com/servlet/NewRegistration
ARELANCE: Consultor de Gestión de la Configuración - Madrid
Si piensas que este es tu momento para buscar un cambio,
conseguir una mejora laboral en una de las consultoras más
importantes de este país, si no te conformas con desarrollar tu
carrera profesional en cualquier empleo.. esta puede ser tu
oportunidad...
Si tienes experiencia como Consultor de Gestión de la Configuración,
y además te consideras una persona con carisma, con talento, con
inquietudes, y quieres tener un auténtico plan de carrera, eres el
profesional que buscamos
Los detalles de los puestos solicitados son los siguientes:
- Centro de trabajo: Madrid
- Tipo de contrato: A determinar
- Fecha de incorporación: Inmediata
- Imprescindible: Experiencia mínima de 1 a 2 años
técnica de sistemas. Conocimiento en administración básica de
sistemas operativos Unix y Windows
- Deseable: Conocimiento en desarrollo de
scripting (preferiblemente Perl), conocimiento Cruise Control,
conocimiento de herramientas de Gestión de la Configuración (Visual
Source Safe, ClearCase, PVCs, CVS, etc.)
Se ofrece una interesante retribución que será fijada de acuerdo a la
experiencia aportada por el profesional.
En el caso de que esta oferta despierte tu interés y quieras saber
más sobre los puestos, envíanos tu CV a la mayor brevedad.
Respecto a la confidencialidad de la información de tu CV, sólo lo
enviaremos al cliente que nos ha realizado esta petición; no lo
tendremos en cuenta ni para otras peticiones del mismo cliente ni
para otros clientes.
Si necesitas cualquier aclaración al respecto, no dudes en contactar
con nosotros.
Muchas gracias
Un saludo
Dpto. de Selección
seleccion@...
www.arelance.com
Tel: 95 202 85 85 - Fax: 95 202 06 66
---------- Forwarded message ---------- From: Pablo Fernando Sanchez <p.f.sanchez@...> Date: 01-dic-2007 11:34
Subject: Disponible presentación en línea To: "Gestión de Departamentos de Cómputo, Sistemas, Tecnología y Automatización" <gestioncomputo@...
>
Estimados:
Comparto con ustedes la presentación que usé para apoyar mi disertación sobre el Proyecto Nombre Clave "Menarva" en el "Foro de Iniciativas y Proyectos TIC"
realizado el pasado jueves 29 de noviembre de 2007 en Bucaramanga, Departamento de Santander, Colombia, organizado por la Asociación Colombiana de Usuarios de Internet (ACUI)
con el auspicio del Instituto Municipal de Empleo y Fomento Empresarial de Bucaramanga (IMEBU). Enlace:
http://www.expertika.com/index.php?option=com_content&task=view&id=63&Itemid=2
Para quienes estén interesados, también se encuentra en línea la presentación correspondiente a la charla introductoria "Mejora de Procesos para Desarrollar Software Mejor" que facilité en junio pasado en el marco de las actividades de SPIN Colombia. Enlace: http://www.expertika.com/index.php?option=com_content&task=view&id=50&Itemid=2
Por último, aprovecho para recordarles sobre los próximos seminarios-talleres de apoyo gerencial en el Oriente Colombiano, que se desarrollarán el miércoles 5 de diciembre en la Cámara de Comercio de Bucaramanga: "Estrategias de Negocio Centradas en el Cliente" y "Técnicas para Reuniones de Trabajo Efectivas"
. Enlace: http://www.expertika.com/p0726
Saludos cordiales.
Pablo
-- _________________________________
Pablo Fernando Sanchez, MIEEE
p.f.sanchez@...
En línea 
Enviar correo
Sin conexión 
Es la opinión Sharon Cichelli, que esta semana volvía a cuestionar el valor real de la certificación ScrumMaster: 
