Governance on Sharepoint or Who's responsability is this?

Hi all.

Very tricky post this about Governance. Microsoft defines governance as "...the set of policies, roles, responsibilities, and processes that control how an organization's business divisions and IT teams work together to achieve its goals".  SO it's basically a list that specifies Who does what, and who's responsible for a specific point in Sharepoint, wether it's infrastructure, content or regulations.

I 'd rather stay with this definition: a list of who's responsible and who's to blame, that is: who takes the decission regarding a specific doubt.

Usually, a good rule is that Servers are managed by the IT team, and the Developments are managed by the DEV team (duh!).  However, there are a few gray areas between:
- Content Publishing.  Usually should be definied a team inside the company (or Department) that mantains the content of the site, managed by someone aware of company highlights (release dates, news, etc).  An usual good practice is that if company has a Public Relations/Press group/communications they're in charge of this part.
- Dev alignment with Business requirements.  This is usually the Analyst job.  But at some point a decission has do be made: if the development is OK or is missing functionality, how far they're from the business requirement and/or, a previous step: if the Business Requirement is even achievable with current Technology.  At some point, the analyst has to face the owners (those folks who define the business requirements, and that in the end, should be paying for all this) and present all this info, so they take the decission.

Regards,

Sharepoint Roles & profiles

Last week I was checking my Linkedin profile and found this excelent article which describes the major roles in a sharepoint deployment:  Sharepoint Administrator, Developer, Architect and designer.  However, I find it incomplete.  There are several other options that do not state there (or they might be a detailed specification of what they proppose).  Surfing the web I've found this other article which describes a better approach:  

• Support,
• Tester,
• Trainer,
• EndUser,
• PowerUser,
• SiteOwner,
• Information Owner,
• SiteCollection Administrator,
• Web Designer,
• Developer,
• Several administrators profiles,
• Business Analyst
• Architect.

They also provide the best book-style explanation. However, based on my experience, I'll try to provide a clarification on several roles:  EndUser, PowerUser, SiteOwner, SiteCollection Administrator, Web Designer... by providing an example:
Some guy builds a building. He has no idea on how the real-state business works. However, he makes this fantastic building. SO he is now the InformationOwner.  As he's a sharp mind, he decides to hire someone to manage the administration of the building: bills, rent offices/floors, hire/outsouce maintenance/cleaning provider.
So far, we have 2 roles identified:
- The Information owner, which took the decisions.
- the Administrator (siteCol Administrator)

At some point, this 4 stories builiding is rented by 4 different companies (one by floor).  Each one of the is a different company, and they manage their own internal resources.  So they can allocate people inside each floor, and perform some minor modifications (installation of vending machines, distribution of desktops, etc).  However mayor modifications requires approval from the Administration: bathrooms, general access doors, maintenance providers.  Now we have: the SiteOwners identified.

Each siteOwner can have it's floor personalized until certain limits, by a decorator.. or WebDesigner.   You can also have your own IT Dept/service Department, which will make the installation/allocation of Computers, phones, generate identification badges... or PowerUsers.  A good idea would be that the ID badges also allow access to the building, so this guys must follow certain rules/procedure (like notifying the personal data to the Administration for security reasons) and align with Administration some of these tasks.

The Administration (or one of the Floor companies) might as well perform certain improvements on the building. This improvements might be related to a specific floor or affecting several/all of them. This modifications should be contracted to some company with experience, and should an engineer/architect checking the floor layout, generating a plan, and giving some instructions to technicians (Developers)...

I guess this is a nice way to remember. You might follow some certifications and add complexity (project managers, service Managers, etc), but in the basis, it's the same as managing a building...

Next post (related): that funny thing called Governance (or how decissions should be taken and who's to blame)

Esas típicas excusas...

Hace algún tiempo conseguí un blog donde comentaban los 10 mandamientos de los programadores. En http://www.devtopics.com/10-commandments-for-programmers/ los hay a montones. Sin embargo, voy a dar un nuevo enfoque: esas excusas/peticionies que nos damos/hacemos unos a otros en esto de soporte, desarrollo e infraestructura:

1. Si desarrollas, el tradicional "en local me funciona". LO ODIO. Por supuesto que en local te funciona! eres administrador, tienes todos los privilegios, eres SA de la BBDD! pero eso NO ES SEGURO, y cuando vas a otro entorno, suele explotar por todas partes.
2.  "qué versión estás usando de..." o "qué nivel de parches..".  De verdad! Hay diferencia entre 32bits/64 bits. Por lo menos en lo relacionado a Windows. NO es lo mismo trabajar con el Framework 2.0 que el 3.5 o el 4! y mucho menos con los Service Packs, por lo que suelen haber problemas entre las distintas versiones de Java, .Net, SQL, MySQL...
3. Pelea diaria entre cliente/managers/desarrolladores:  "Eso no está especificado" o "No está documentado".  Suele venir seguida de la siguiente frase en la lista:
4. "Haz un RFC con..". Vale. Nos equivocamos. Consideramos que una tarea era más sencilla que lo que al final resulta ser. Pero por DIOS! una cosa es que se documenten los cambios que pide un cliente en inferfaz gráfica (UI) y otra muy distinta es que no contemples el tiempo para documentar, probar debidamente y un laaaargo etc.
5. De esta estoy cansado: "ponlo hard-coded (a cañón, cableado, directo.. etc) y luego lo cambiamos". NO!. Error crucial. Las cosas deben hacerse 1 vez y bien, porque si no, implica re-trabajo. He visto muchos ficheros de configuración con Passwords/usuarios/Cadenas de conexión sin encriptar como para pasar esto por alto...
6. Cuando una persona hace las cosas de una forma, y ahora tiene que hacerlas de otra: "Es que esto en la versión TAL se hace de otra forma". Anécdota: esto se lo escuché a un comercial de Microsoft, cuando en una consultoría para SharePoint 2007, cada 5 minutos que no conseguía algo, decía que en SharePoint 2010 estaba en otro sitio o se hacía de otra forma... SI, eso lo sé: Que se hace de otra forma en otro producto. Pero el que ahora nos preocupa este, es el que estamos trabajando y deja el fastidio!!!!
7. El típico peloteo entre áreas: que si una incidencia es de Operaciones, de Desarrollo, de BBDD, de comunicaciones, de Servidores.. en fin. Va pasando entre tantas cosas que llega un punto en que cuando te dan una respuesta oficial... ya ni te acuerdas porqué lo abriste..  siempre sale alguno que dice "Pero esto no es nuestro" y en vez de reenviarlo a quien corresponde, te lo retorna...
8. En un mundo tan altamente dinámico como el de la tecnología, no puedo creer que todavía hoy tenga que escuchar cosas como "es que está en inglés..." y te pongan carita de perro pisao y te lo digan con una voz de niñita llorosa.  A ver. Esto es tecnología. Cuando terminas de traducir un libro al español, el producto probablemente ya es obsoleto y hay una nueva versión. Así que acostúmbrate! No digo que se hable inglés nativo, pero al menos entiende lo que te pone una ventana... Esto tiene muchos vértices, porque cuando te sale algún mensaje de error, basta con googlearlo en Inglés y tienes N resultados. Pero si lo buscas en Español.. debo informarte amigo, que vas a tener apenas una fracción de los resultados posibles...
9. Hay cosas que van contra-natura. Yo entiendo que trabajando en una consultora o en un departamento de informática, quien paga mi salario suelen ser comerciales/negocio/clientes.. y como tal, hay que tratar de satisfacer sus necesidades. Pero eso es una cosa y otra muy distinta es el "pero es que el cliente quiere"... Eso a veces se traduce en cosas como que cuando presionen el botón de "TAB", en vez de ir a la sección que está a la derecha, vaya hacia abajo. Esto no estaría mal, si luego no te piden que no haga Scroll, teniendo 100 campos que llenar!
10. "Arregla en Producción y luego lo bajamos al resto de entornos". Todos los años consigo uno así... y al final, los entornos son distintos, las pruebas en los otros entornos luego fallan por esta corrección y bueno....

Si sabéis alguno más, espero sus comentarios!

Limitaciones de navegadores con SharePoint 2010

Microsoft ha liberado un pequeño artículo donde indica el soporte que tienen
los distintos navegadores al usar SharePoint 2010. Aunque el nuevo ServicePack1 incluye
algunas mejoras y soportes adicionales (Google Chrome por ejemplo), hay ciertas cosas interesantes.

Browser	Soportado	Soportado con Limitaciones	No Probado
Internet Explorer 9(32-bit)	X
Internet Explorer 8(32-bit)	X
Internet Explorer 7(32-bit)	X
Internet Explorer 9(64-bit)		X
Internet Explorer 8(64-bit)		X
Internet Explorer 7(64-bit)		X
Internet Explorer 6(32-bit)			X
Mozilla Firefox 3.6 (en Sistemas Operativos Windows)		X
Mozilla Firefox 3.6 (Con Sistemas Operativos No-Windows)		X
Safari 4.04(Con Sistemas Operativos No-Windows)		X

Uno de los aspectos fundamentales de esto es que Internet Explorer 7,8 y 9 para 64 Bits
tienen problemas reconocidos con SharePoint 2010. Traduzco y resumo a continuación
los principales problemas reconocidos.

Característica	Limitación	IE7	IE8	IE9
Conectar con Outlook, Conectar con Office y Sincronización con el Workspace de SharePoint	Funciona con un control ActiveX y el protocolo stssync://. Las funcionalidades pueden estar limitadas sin un control ActiveX como el incluido en Microsoft Office 2010. También requiere una aplicación compatible con el protocolo stssync:// como Microsoft Outlook.	X	X	X
Vista de Hoja de Datos	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Editar en aplicación de Microsoft Office	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Vista del Explorador	Eliminado en SharePoint Server 2010. Las bibliotecas que hayan sido migradas de una versión anterior de Sharepoint pueden contener Vistas de Explorador y puede que las vistas no funcionen.	X	X	X
Exportar a Excel	Descarga un fichero con una extensi&ocute;n .iqy al navegador. Si Microsoft Excel no está instalado y no hay otra aplicación configurada para abrir estos ficheros, la característica no funcionará.	X	X	X
Subir ficheros y Copiar	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Integración con Microsoft InfoPath 2010	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Integración con Biblioteca de Imágenes de Microsoft PowerPoint 2010	Requiere un control ActiveX de 64Bits como el provisto en Microsoft Office 2010. Pueden usarse los siguientes workarounds cuando no se ha instalado ningún control: -Si se desean subir varias imágenes en una Biblioteca de Imágenes, el usuario debe subirlas una a una usando Upload.aspx -Si se desea editar una imagen en una Biblioteca de Imágenes, hay que descargar la imagen, editarla y subirla nuevamente a la biblioteca. -Si se desea descargar más de una imagen de una Biblioteca de Imágenes, hay que descargarse imagen por imagen haciendo clic en el link de la imagen.	X	X	X
Creación de Diagramas con Microsoft Visio 2010	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Nuevo Documento	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control. Aunque la opción “Nuevo Documento” puede no funcionar, puede usarse la funcionalidad “Subir Documento”. Si se instala y configura Office Web Applications en el servidor, laopción “Nuevo Documento” funciona y pueden crearse documentos Office en el Navegador	X	X	X
Enviar a	Puede necesitar un control ActiveX 64 bits. Microsoft Office 2010 no provee una versión 64 Bits de este control. Sin el control, los archivos no pueden ser enviados de una granja a otra de SharePoint. Sin embargo, pueden ser enviados de un sitio web a otro.	X	X	X
Firmar Formularios (InfoPath Form Services)	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control.	X	X	X
Integración con Hojas de Datos y Bases de Datos	Requiere un control ActiveX de 64Bits. Microsoft Office 2010 no provee una versión 64bits de este control. Pueden usarse los siguientes workarounds cuando no se ha instalado ningún control: -Si el usuario quiere editar un documento, debe descargarse el documento, editarlo y subirlo al sitio nuevamente. -En una lista que requiera hacer un CheckOut del documento para su edición, debe usarse el menú “Edición…” para hacer el CheckOut, editarlo y luego hacer el CheckIn usando el menú “Edición...” -Expotar a hoja de datos. Puede realizarse haciendo clic en “Exportar a Hoja de Datos” en la pestaña “Lista” en el Ribbon.	X	X	X
Conexiones entre Web Part	Puede requerir la desactivación del bloqueo de Popups del Navegador para los sitios de SharePoint.	X	X	X
Integración entre Biblioteca de Presentación y PowerPoint 2010	Requiere un control ActiveX de 64Bits. Puede utilizarse el siguiente mecanismo cuando no se ha instalado un control: -Eliminar una diapositiva. Se pueden eliminar las diapositivas seleccionando la diapositiva y haciendo clic sobre “Eliminar Diapositiva”. Esto debe repetirse para cada diapositiva que se desee eliminar.	X	X	X

En esta URL pueden apreciar más información:

http://technet.microsoft.com/en-us/library/cc263526.aspx

Nuevo mecanismo para los updates de Microsoft

Hola!

Tiempo sin escribir. Pero les dejo algo de info interesante. Es una de esas tonterias a las que no les prestamos atencion pero que posteriormente, cuando no tienes mas nada que hacer y te das cuenta, te parecen super interesantes.

Microsoft ha mejorado el proceso de actualizacion de parches. He probado con el SP1, el SP2 de SQL Server 2008 y con uno para Windows 2008 Server. Lo que me sorprende es que ya los parches no solo se ejecutan y punto, sino que vienen varias pantallas para indicarnos los ficheros que pueden ser conflictivos, hace un pre-run para ver si se cumplen ciertas condiciones.

He aqui unos pantallazos...

Aqui se puede ver el PreScan. Nos dice si falta algun elemento.

Luego tenemos una segunda pantalla, donde podemos seleccionar los elementos a instalar/actualizar

Una tercera pantalla novedosa, que nos indica que procesos/ficheros estan siendo utilizados y pueden afectar nuestro proceso de instalacion 

Una cuarta pantalla nos muestra el resumen de todo aquello cuanto hemos seleccionado.

Una quinta pantalla con el proceso como tal de actualizacion (esta si es tipica)

Creo que esto es todo por ahora. Tengo un par de chorradas mas que compartir, veremos si las actualizo pronto

Tercerización de servicios (y la seguridad asociada)

Una de las cosas con las que frecuentemente solemos toparnos los desarrolladores, consultores y tecnócratas en general, es con la administración de permisos y seguridad en las redes. Si se tiene una empresa pequeña, unos 25 empleados en plan Fabrica de Software, pues.. lo normal es que todos los desarrolladores sean administradores locales, se establezca una política para subir cambios a un entorno de Desarrollo común, estable. Pasadas las pruebas del equipo de desarrollo, pasamos a un ambiente de pre-producción donde otras personas ejecutan sus test. Esto.. en plan pequeño.
Que sucede cuando nuestra compañía es una empresa de mas de 100 empleados, con personas con computadores portátiles, y donde hay tercerizados (esto es, nuestra empresa sub-contrata a otras empresas para labores específicas)? Cómo se determinan los privilegios administrador/usuario avanzado/colaborador/solo lectura?
En mi recorrido, creo que una práctica sana sería: los desarrolladores como usuarios restringidos en sus equipos, pero con una máquina virtual con la que puedan "trastear" y desarrollar. Políticas de supervisión de navegación en el proxy para limitar las cosas que pueden acceder (dudo que Youtube tenga algo interesante para un programador). Si el requerimiento es prohibir a los usuarios estar todo el dia conversando por MSN/GTALK (que me parece iluso, uno puede ser tan o incluso mas productivo y usar estas herramientas), algun cliente de mensajería que puedan usar los miembros del equipo de desarrollo, pero que no permita comunicación web (algo tipo MS Comunicator). Un servidor de fuentes, y una política acertada de cambios en servidores (a desarrollo puede ser diaria, mientras que a otros entornos, semanales o mensuales). A los miembros tercerizados, se les pudiese crear un "grupo" de Active Directory con pemisos similares a los del grupo de desarrollo local.
El asunto que vendría a complicar todo es: quien maneja el AD? personal de la empresa, o se subcontrata? esto es un asunto espinoso, ya que hay empresas en las que la burocracia y procedimiento de cambios en ambientes de explotación, suelen demorar mucho y pasar por tantos niveles, que mas que controlar la seguridad, entorpecen el desarrollo y mantenimiento de aplicaciones.

Rompiendo los ladrillos

De jovencito, recuerdo mi fascinación por los tipos que rompían ladrillos a punta de golpes: Manos, cabeza, piernas, rodilla. Todo era permitido. Me los imaginaba super fuertes. Un día, mi primo, que de eso sabía bastante, me indicaba no lo rompes solo con una parte del cuerpo, sino con todo el cuerpo. El peso ejerce un enorme poder al momento de transmitir algo....

Recuerdo también la "estela de la destrucción": los ladrillos que estaban arriba tenian pequeñas fracturas que a medida que se descendía, era mayor. Hasta llegar a los últimos ladrillos que quedaban desmenuzados.

Ya de "mayorcito" me he fascinado al ver como ese mismo fenómeno se repite en las oficinas. El Jefe Superioris está haciendo algo y le falla un sistema (digamos, un hipervínculo no se muestra en una página web). Comienza el proceso de "estela de destrucción": el dichoso jefe transmite a un gerente de primera linea (el CIO, el responsable de TI, etc, etc etc) la "incidencia" con un "sabes que me pasó esto". Empieza allí el calvario: "ya te envío a alguno de los muchachos para que lo resuelva" o "Que raro? ese comportamiento no es normal". Sigue un "vamos a escalarlo con el personal apropiado para verificar el porqué ocurre eso". Frases acartonadas van y vienen cual manual de protocolo. Y así comienza la estela. El gerente de primer nivel le dice al de segundo "el Jefe me manifestó que hay algo en la aplicación X que no le funciona". El de segundo al de tercero: "el jefe/dueño/manda más/chivo que mas mea/papá de los helados le dijo al gerente qe algo no le funciona". y sigue con un "el XXX le armó un rollo al gerente porque algo no le funcionó, y nos están presionando para que lo resolvamos lo mas pronto posible" hasta que llega al último nivel:
- Se presentó una incidencia, la aplicación falló totalmente (la desmesura de las palabras y lo exagerado de la situación) mientras la usaba el sr. Fulanito, se han encendido varias alarmas porque es algo que no salió en ninguna prueba...
- Disculpa, fulano... una pregunta..... según veo aquí, la incidencia es porque las palabras que constituyen un hipervínculo.. el mouse no cambia de puntero a la manito típica ni se subraya...
- Eso es correcto, pela_patatas_01
- Vale.. Es que.. según el correo enviado por el subgerente_posición_51 cuando la definición de requerimientos, dijeron que no querían que los hipervínculos tuviesen el subrayado ni el cambio del mouse, ya que querían que fuese un texto lo mas compacto, ultraliviano y que nada destacase por encima del resto de las palabras.....

Sorpresa, sorpresa. Comienza entonces una serie de reuniones con usuarios, gerents, desarrolladores, el Papa Juan Pabl.. ahh, que ahora es Ratzinger. Bueno.. en fin. La negociación típica de plazos, de eso no estaba en los requisitos iniciales, que el cambio cuesta tanto, que eso es mucho dinero para algo tan minúsculo, que si, que si no.. que es para el gerente, que se aprueban los 200 mil $ presupuestados... y al final, son los pobres programadores luchando para ver donde rayos estaba el condenado 'a href' que fallaba, con un plazo de 2 días, y si no lo cumples, corre que te despido!!

En fin.. que la terminan pagando los curritos, mientras que el jefe superioris se sorprende que el gasto de su departamento de TI se gaste 200mil $ colocando un 'a href'.. ahh.. no.. en un "proyecto de actualización, mejora y upgrade de las capacidades gráficas de la aplicación"...

Ya decía yo, El peso ejerce un enorme poder al momento de transmitir algo.... sobre todo si es el jefe superior quejándose de algo a los "mortales" que tiene por debajo en el organigrama

El español como idioma de desarrollo

Apenas entraba a la universidad y recuerdo los cientos de errores que Borland C me daba cuando creaba variables "castellanas": 'año', 'adición', etc. Entendí entonces que en lo que respecta al código, el español no es un idioma.. 'bonito', sobre todo por el hecho de tener que interpretar caracteres 'extraños'. Recuerdo también un consejo que decía "los libros de tecnología en español son una utopía, porque cuando llegan a ver la luz, ya la aplicación a la que se refieren, es obsoleta o tiene varios parches encima". Por todo esto pues, siempre me he acostumbrado a las versiones "inglesas" de las cosas: Sistemas operativos, IDE's, Suites de oficina, documentación, etc.


Es que verdaderamente, eso de "ir a Definición", no me cuadra mucho (a pesar de que es muy literal y fácilmente deducible de "go to Definition"). Pero hay conceptos que verdaderamente escapan a mi mente, como el porqué una persona instala aplicaciones en inglés y luego aplica parches de idioma.. cuando va a programar en un lenguaje pseudo-inglés...


Algunas cosas inevitablemente deben ser en español (He conocido sitios donde por política, el nombre de tus métodos debe ser en inglés, y en otros sitios, en español -aunque sin acentos y sin ñ- o en portugués). Usualmente, una de ellas es la documentación / Comentarios de código. Sin embargo pues.... colocarlos en inglés tampoco está mal (sobre todo si se trabaja en equipos con varias locaciones internacionales). Y verdaderamente tiene su ventajas trabajar en inglés, sobre todo el hecho de no tener que descargar paquetes adicionales de idioma (uno para Office, otro para Sistema Operativo, otro para el Framework).. y empiezas a acumular megas y megas de "paquetes" para simplemente poder leer "Archivo" en vez de "file"...

Tiene sentido esto?

Sobre la ética profesional

YO siempre he tratado de ser comprensivo con las personas, sus motivaciones y su forma de hacer las cosas. Espero no haber juzgado a nadie, ni haberle ofendido durante mis cortos 28 años de vida. Sin embargo, hay varias cosas que he observado, que me han afectado directamente y que me gustaría compartir.. y están relacionadas con ese sitio donde pasamos 9 hrs al día (incluyendo el almuerzo) de lunes a viernes...
Recientemente cambié de empleo. Nada fuera de lo corriente en esto. Las motivaciones de siempre. Al salir de la que fue mi empresa durante dos años, me tocó entregar el portátil que tenía asignado. 1 hr antes de entregarlo, procuré eliminar mis archivos personales, dejar todos los archivos y código fuente en repositorio compartido, verificar (de forma doble) que no tuviese archivos "sueltos", que todos los Login/passwords estuviesen en una hoja al momento de entregar todo, para que mi reemplazo o el que sea, pueda acceder de forma "libre" e "inmediata" a lo que fueron mis cosas. Reconozco que durante 2 años he instalado ciertos programas que aunque no estaban en la lista, me ayudaban a desempeñar mis funciones: Firefox, programas para comparar versiones y un laargo etc.
Sin embargo, en el nuevo empleo me he conseguido con un portátil, fuera de lo "estándar". Perteneció a otra persona, y como "logicamente" hubiese hecho, eliminó muchos programas que en principio no debieron estar ahi: clientes P2P (como Ares y eMule), MP3 y videos. Aun así, empleé un par de días en limpiar la compu de reproductores multimedias (VLC, QuickTime, VideoRa etc), Programas de transferencia de datos con Celulares/Moviles.
Entiendo que muchas personas guarden con gran recelo el "secreto profesional". Tal vez porque no soy 100% Microsoft y mas bien soy un anarquista, nunca me ha gustado llevarme el código fuente conmigo. Aquí hay un punto interesante: los pro-Software libre dicen "el código es de todos, distribúyelo", mientras que los de Software privativo.. no. Sin embargo, como programador del lado "privativo" entiendo que el código no es de mi propiedad, sino que es propiedad del cliente o de la empresa para la que trabajo. Y como tal, debo dejar constancia de ello (notificar al jefe o al "heredero" la ubicación de los fuentes, etc). Inclusive, siempre he sido un fanático de dejar todo comentado, estructurado, con explicaciones cuando el código es medio confuso. Pero.. que carajo, eso es lo que YO hago, porque a lo largo de 7 años de trabajo, he tenido buenos compañeros y maestros que me han dejado esas enseñanzas... pero creo que a no todos nos enseñan igual....

Comentarios y algo mas

Uff. Tenia tiempo sin escribir. Bueno, espero poder retormarlo. Unas cuantas cosas han cambiado desde la ultima vez que lo hice. He cambiado las actividades que venia realizando (de soporte a una aplicacion desarrollando en VStudio 2005 con C# a soporte de Project Server y Portfolio server en general).

Un par de cosas que he visto recientemente, cuando me ha tocado dar el soporte a este par de herramientas, es la forma como algunas personas echan codigo. NO digo que todos lo hagamos igual... Echar codigo depende un poco de tu cultura, tu experiencia y muchas cosas mas. Pero he visto cosas interesantes, que espero poder colocar.

Una de ellas por ejemplo, es cuando desarrollan una aplicacion con un pedazo de codigo que nadie entiende... y nadie coloca ni un comentario ni nada por el estilo. Algo sencillo que diga:
/*
Desarrollado por: Daniel
Fecha: 20-Nov-208
Descripcion: Esta funcion recibe como entrada el identificador de persona, y se encarga de actualizar la edad que lleva hasta la fecha. Esto lo hace obteniendo la fecha de nacimiento de la persona, obtiene la fecha de hoy. Convierte estos valores a Milisegundos, los resta.. y la diferencia, la convierto luego a dias.
*/

Es increible la cantidad de veces que algo asi de sencillo puede facilitar la vida de un desarrollador/analista...

Salud laboral

En estos dias recibi un mail del Joex, con algo simpatico:
http://www.codinghorror.com/blog/archives/001115.html

Este caballero que escribe (algo polémico en sus comentarios) dice (a muy resumidas cuentas) dos cosas interesantes:
a) todo el que toca un monitor, es un cerdo
b) los componentes de trabajo (teclados, ratón, teléfono) pueden acumular una cantidad de asquerosidades enormes.

Como consultor, he tenido que ir a varios clientes, y no suelo mantener un puesto (o equipo/ordenador/computador) por mas de 1 año. Algunas de las cosas mas fantásticas que he visto:

1. Hoy en día son comunes los ratones ópticos. Sin embargo, no hace mucho eran "de bolita". Cuantas veces hubo que abrirlos para eliminar el sucio que se acumulaba en los rodillos sensores? en ocasiones había que insistirle con algún objeto afilado (destornilladores, llaves, etc) porque la mugre pegada, podía servir como cemento para una construcción anti huracanes.
2. Particularmente tengo la manía de tomar el teclado y darle unos toques suaves, esto con el fin de hacer que salgan del mismo algunas impurezas que se quedan entre las teclas: cabellos, sucio, migas de comida. He llegado a conseguirme cosas horribles: creo que eran pedazos de uñas, de piel y de mocos....
3. He visto y conocido personas que cuando hablan, tienen complejo de aspersor: llenan todo a su alrededor de saliva. He aprendido a evitarles, colocándome a un lado de ellos, de forma que cuando hablen, mi cara no sea un obstáculo para sus "salibasos". Sin embargo, hay algo horrible: cuando llenan tu monitor de su saliva y empiezas a ver los pequeños pixelados multicolores. Y algo mas horrible: cuando usan tu teléfono. Es que solo de pensar que luego yo pondré mi boca cerca de un sitio previamente ensalibado, me da algo....
4. Muchas veces no estamos de acuerdo con nuestros trabajos. Y tratamos de hacerlos mas "agradables" personalizándolo y colocando objetos con los que nos identificamos. Pero todo tiene un límite. Me refiero a esas personas que colocan fotos de sus prim@s, herman@s, ti@s, lugares en los que estuvieron, novi@s, mascotas y un laaargo etc. Unas veces, las fotos estan puestas unas encimas de otras, que la foto original.. ni aparece.
5. Continuando el punto anterior, recuerdo personas que para personalizar sus escritorios, colocaban cualquier cantidad de: peluches, llaveros, tazas de café (mugs), Al final, el espacio disponible dentro de su escritorio es mínimo, por lo que invadían los computadores: stickers (pegatinas, calcomanías o como quieran llamarle) adornando los monitores.
6. El punto mas difícil de todos: los que llevamos la comida a la oficina en pequeños empaques plásticos (tupperware). He visto personas maniáticas que apenas terminan de comer, lavan sus envases, los secan con el papel de los baños y lo guardan íntegro. Pero he visto personas que dejan parte de la comida dentro del envase. Esto es algo personal, y que no afecta a mas nadie, salvo cuando esa persona deja dicho envase en la oficina, a la vista de los compañeros. Señores: la comida es orgánica, se descompone. He visto envases que han tenido hongos (blancos, verdes, negros, etc) porque su dueño los olvida dos, tres y hasta cinco días en la oficina

Hay muchas cosas mas.. pero creo que dentro de las desagradables, estas son las que más recuerdo. Si tienen alguna otra idea, o punto que me falte, por favor, escribe tu comentario sobre esto.

Puntos importantes sobre Conversión Monetaria

Después de conversión monetaria, me han quedado algunas cosas de aprendizaje. Son cosas que, desde mi punto de vista, aplican para todos los proyectos como consejos generales. Son

- Pruebas con los usuarios. Es probablemente uno de los más grandes pilares de un proyecto grande: El proceso de prueba con los usuarios. Debe ponerse especial cuidado en que el usuario certifique que sus aplicaciones sigan funcionando de la misma forma: Las pantallas se le deben presentar a los usuarios con una distribución lo más similar posible a la que se tenía antes de los cambios. De esta forma todas las Entradas/Salidas (input/output) deben permanecer de la forma más amigable posible para los usuarios.

- Interfaces. Hay que tener cuidado con los sistemas Legacy y las interfaces. Probablemente, junto con las pruebas de usuarios, son uno de los puntos más críticos de cualquier proceso de cambio grande. Debe asegurarse un proceso de pruebas lo suficientemente amplio, como para que todas las posibles entradas en un sistema se transfieran a otra: campos en numero, letras, boléanos. También hay que tener en cuenta que. Cualquier proceso que se lleva a cabo en uno de los sistemas que implique información de otro, debe ponerse a prueba.

- La conversión de la BD: inventario de campos. Hacer un inventario de los campos que se están convirtiendo, indicando el tipo: varchar, int, decimal, etc. Debe tenerse en cuenta la forma como se utilizan estos campos, y si son usados en procesos de interfaces.

- Dejar una documentación: aprovechar hacerla a partir de la revisión que se hizo. Esto es un punto importante, siempre y cuando no implique un mayor esfuerzo y dedicación del personal.

- Contrario a lo que muchas personas pensarían, soy partidario de que si algo funciona bien, déjalo bien. YO probablemente no soy muy incondicional de esto, puesto que trato siempre de arreglar el código ajeno cuando me toca editarlo. Sin embargo, en proyectos de recursos limitados con énfasis en tiempos y resultados, si algo funciona bien y no precisa cambios, es mejor dejarlos fuera del impacto. Esto aplica también a una tendencia marcada en algunas empresas, donde a raíz de cambios grandes, deciden implementar “algunas mejoras” que por lo general, lejos de ayudar al proyecto, complican las estimaciones.

Esto es todo por ahora. Trataré de colocar algunas cosas adicionales a medida que las recuerde

Despues de Conversion

Escribo esto mucho tiempo después de haber terminado Conversión Monetaria. Después de un montón de peleas, horas extras, problemas con proveedores, mal comer, trabajos nocturnos, seguimiento de cambios, homologación de ambientes, horas de soporte, verificación de interfaces... ya.

Fueron unos días difíciles, duros. Donde no solo trabajé en conversión monetaria, sino que también tuve la dicha de casarme. Donde el stress estaba a flor de piel. Pero donde en medio de tantas cosas, hubo grandes beneficios:
- Pude examinar mis límites, tanto físicos como mentales. Ver hasta que punto puedo trabajar sin parar, sin comer, y estar concentrado con la menor cantidad de fallas posibles.
- Adquirí una enorme experiencia en el manejo de stress, proyectos complejos, manejo de grupos multidisciplinarios y con sistemas altamente compartimentados.

Pero por sobre todo… aprendí mucho y gane muchísimos amigos. Debo agradecer a Inés, Shelly, Freddy, Ignacio, Wellington, Helen, Bárbara, Yusmeli, Miguel… y tantas personas que en este momento se me escapan. De verdad, muchas gracias…

Hi-Tech. A donde hemos llegado?

Puede ser paradójico. La tecnología avanza a un ritmo tan impresionantemente rápido, que lo que hoy es un adelanto tecnológico, dentro de apenas 1 mes ya es obsoleto. Y esto, sin contar las personas rezagadas, aquellas que no tienen mayor instrucción tecnológica ni contacto con las mismas.

Basta un ejemplo de ello: hace una década, los teléfonos celulares eran analógicos, con cobertura limitada, con costos elevados y poca penetración de mercado. Hoy, es una paradoja de lo esnobistas, avanzados tecnológicamente, y de la brecha existente.

En este país, tenemos situaciones como las siguientes:
- Competimos por el Telf. mas moderno, con menos botones y mayor cantidad de funciones que pueda tener el mercado. EL índice de rotación de teléfonos es algo bárbaro. He sabido de personas que cada 3 meses cambian sus equipos. En muchas ocasiones es por el simple hecho de tener el teléfono de moda, ya que fuera de enviar mensajes y hacer llamadas, la aplicación de tonos, el uso como radio y reproductor de música, son contadas las funciones extras nuevas que puede ofrecer un teléfono móvil
- Competimos por teléfonos cada vez más pequeños, preferiblemente de colores. Altamente resistentes. A pesar de la existencia de equipos de marcas como alcatel, huawei y otros, los teléfonos por excelencia suelen ser Motorolla, Nokia, LG y Samsung.
- Cada vez los planes son más económicos. Desde llamar a teléfonos de la misma compañía, ínter compañías o a teléfonos fijos. Planes diseñados para cada nicho de mercado, con tarifas para todo…
Tal vez lo mas extraordinario de esto es la anécdota que tengo de hace unos pocos días, cuando mi mama me envió a casa de mi abuela (cerca de 80 anos) para que le explicara como utilizar su teléfono para enviar y recibir mensajes… y conseguirme no menos de 3-4 viejitos (mayores de 65 anos todos) con teléfonos móviles, y bastante diestros en su uso…

Otherside: El otro lado del espejo

Bueno. No se si esto sea algo válido de escribir. Es como cuando aquellos magos se molestaron con uno de sus compañeros cuando expuso varios de los trucos. Entiendo ahora porqué lo hizo: porque consideraba que había que renovarse. Inventar nuevos trucos. Porque no podían seguir con los mismos trucos anticuados.

A que viene esto? pues... En mi background, tengo como experiencia, el haber trabajado en 2 consultoras de sistemas (ambas partners de Microsoft). Muchos de mis ex-compañeros (que estan en otras consultoras ahora) me han llamado para trabajar con ellos. Yo por mi parte, no quiero seguir trabajando en otra consultora... considero que ya he cumplido mi etapa en ellas (aunque uno no debe decir "nunca"), y por eso he rechazado unas 6 propuestas de empleo, en algunas de ellas duplicando o triplicando mi salario actual (y vaya que lo necesito).

Ahora bien. Eso de haber trabajado en consultoras, no tiene mayor inconveniente, de no ser porque... hoy, que estoy trabajando en el bendito proyecto de Conversión monetaria, me encuentro "del otro lado del espejo". Ya no soy yo la consultora, sino que tengo que vérmelas con ellas: una que haga el desarrollo, y otra que "coordina" las acciones....

Nada en especial. Muchas veces he admirado al equipo (consultores) brasileño que trabaja conmigo. Son unas personas que trabajan a conciencia, con productos de calidad, que en la medida de lo posible no piden reuniones, sino tiempo para trabajar. Que cuando llegas tarde a una reunión te meten tremenda multa. Supongo que ellos, al igual que las consultoras a las que he pertenecido, y a las otras tantas en este pais (y en cualquier otro pais) facturan bajo el concepto de "horas": hacer tal o cual cambio, son tantas horas. La diferencia radica, en que ellos "aprendieron nuevos trucos": no son la clase de consultores que buscan "marear la perdiz", "pajarear", etc.. en fin.. poner todo del lado del cliente.. y cobrarte altos salarios por las horas muertas en las que ellos no hacen nada. NO....

Ahh!! como agradezco haber leido al maestro Fuckowski (http://www.despacho101.com/) y ver tantas cosas que hoy veo... y cuanto me lamento de haber sido un "consultor" mas.. con escoba incluida...

Entrando en funcionamiento

Entrando en funcionamiento: o puede llamársele tambien "productiva", "producción", "explotación", "pda" (como abreviación de Productiva?). En todos los casos hace referencia al sufrimiento (porque esto es lo que es: el proceso que uno sufre) para poder colocar algo al servicio de los demas.

Es que resulta paradójico: colocar algo suele ser un proceso complicado: se hace un desarrollo, se prueba y cuando todas las partes estan satisfechas... se "agenda" el pase . Pues nada, que suele pasar de todo:

1. Que la versión que se tiene de los archivos no es la misma entre los ambientes.
2. Que la base de datos, tampoco es igual.
3. Que los scripts de pruebas están mal hechos.
4. Que no pases algunas cosas, porque eso les complicaría la vida a los usuarios.
5. Conseguir el tiempo para que los usuarios puedan darte unas horas para hacer las pruebas.
6. Conseguir que los gerentes firmen el script de pruebas
7. Verificar que cuando actualicen los archivos, copien los archivos que son, y en los lugares correctos.

En fin... que a medida que tenemos mas responsabilidad, las cosas suelen complicarse mas...

De la reconversion monetaria

Saludos pues... les comento que... que bromas con este gobierno... resulta que desde hace algun tiempo se venia cocinando aca en Venezuela, una reconversion monetaria. Pues bien, les cuento que es en serio la cosa... y que ya el 85% de los bancos, aseguradoras y otras empresas ya comenzaron a definir sus procesos. Es algo medio complicado, porque implica la reduccion de 3 ceros de la moneda.. hay que aplicar unos redondeos.. y se podran imaginar lo FEO que se va a poner con historicos, cuentas por cobrar, y un laaaargo etc.

Por mi parte, fui designado lider de proyecto de la empresa para la que estoy contratado, para llevar adelante los cambios en 1 de los 4 sistemas. EN mi caso, del area de venta... Todo esta hecho en Java/javascript/SQL Server/HTML...y eso es lo unico que he visto. No he visto mas nada (gracias a Dios), pero se ve bien compleja la cosa...

Primera vez

Esta NO es la primera vez que escribo, pero pa este post si... sera que funciona? vamos a ver.. espero que si..

Por lo pronto, estoy haciendo una quiniela para la copa america, de a 5 Bs F. por cada día de juegos.... mientras mando y recibo correos