Confidencial de Windows: Envíelo
¿Quién Obtiene un premio "Barco It"? Necesita han contribuido al envío del producto real, de lo contrario sólo está escribiendo código.
Raymond Chen
Hay un premio otorgado internamente en Microsoft llamado "Enviarlo". Recibirá este premio cada vez que enviar un producto.
Uno de los deberes de jefe de proyecto ocultos es decidir quién es elegible para recibir un premio de barco que cuando envía el producto. Para las personas que han trabajado en un proyecto de todo el camino a través de, la decisión es fácil. Para la gente que se unió a o abandonó el proyecto comenzada a través de, sin embargo, la decisión no es tan obvia.
La clave para el barco que es el buque: Tienes que han contribuido al proceso de código de envío. Para los programadores, esto significa no sólo las tareas obvias de diseñar e implementar características, pero todo el trabajo que acompaña a lo largo de ese proceso. Aquí hay un puñado de ejemplos:
- Mantener el código a lo largo del ciclo de vida del proyecto.
- Solucionar problemas de rendimiento.
- Depurar fallos y errores, incluso aquellos que no son culpa del código.
- Ir a través de todos los informes de errores y corregir errores, especialmente los que realmente desagradables que tendrá un mes para averiguar.
- Revisar código debido a un descuido en el diseño original o una característica de última hora (y estas revisiones pueden ser extensa).
- Decidir qué partes de su función de abandonar. Como señala Larry Osterman en el blog Engineering Windows 7, en una entrada titulada "Ingeniería 7: Vista desde la parte inferior, "Corte está a la venta. Es mejor renunciar a algo que no está uniendo a que el riesgo de retrasar todo el producto esperando indefinidamente a una problemática.
Un directivo me dijo que después de que un proyecto está terminado y ofrece los barco, premios, que en ocasiones obtienen una pieza de correo electrónico de un miembro del equipo antiguo diciendo: "Hey, por qué no conseguir un barco Premio? He trabajado en el proyecto hasta la fecha tal y cual, y enviado mi componente en el producto final.
Su respuesta suele ser algo como, "Oh sí, me acuerdo de TI. Has trabajado en el equipo en el inicio, cuando el cielo era el límite y todo era posible. Escribió un montón de código y, a continuación, dejó. Han atascado su integración con el resto del producto, mantener el código, corregir los fallos, diagnosticar problemas de performance, tratar las secuelas de la compatibilidad de aplicaciones, depurar todos los bloqueos, todo lo que otras cosas que necesita hacer para enviar el producto. Estabas en el equipo del proyecto para la primera parte, la parte donde se escribe código."
En otras palabras: "You were here para la diversión forma parte del proyecto, y, a continuación, cuando comenzó la parte no-fun, rescatados. Comió el postre y nos dejó con las verduras.
¿Sabes quién realmente merece el Premio barco es su componente? La persona que se unió al equipo y le dio la responsabilidad de su código. Esa persona escribió el estado informes para la función, asistió a las reuniones de la función, respondió a un correo electrónico de las personas que tienen problemas para utilizar la función de depurar los bloqueos y corregido bugs no sólo en su componente sino en varios otros componentes.
Entonces la respuesta a "¿por qué no conseguir un barco Premio?" es siempre, "porque nos dio a esa otra persona en su lugar, la persona que haya enviado realmente tu código."
El miembro del equipo antiguo admite tanto en el mensaje original: “... y enviado mi componente en el producto final. Ellos reconocen que alguien haya enviado realmente su componente. Así no hay ningún barco que premio para ellos. Se llama el buque que premio — no el código que premio.
Adam Barr tiene un bonito resumen del Premio barco que en su sitio Web. El primer comentario en su artículo incluye la historia del premio. La controversia que rodeó el Premio del barco, en su introducción ha muerto desde hace mucho tiempo lejos. Ahora, es sólo una parte del trabajo.
.jpg)
**Raymond Chen**idénticamente titulado libro (Addison-Wesley, 2007) y del sitio Web, The Old New Thing, ocuparse de la historia de Windows, programación de Win32 y cómo no hacer una presentación a un ejecutivo.