El artículo Un programador no debería resolver problemas de negocios causó una fuerte discusión (e incluso una respuesta con la afirmación exactamente opuesta).Y es curioso que todo se redujera al razonamiento dogmático de la categoría de "programador debe" o "negocio debería". Como si estuviéramos hablando de un sistema que funciona para un objetivo común, y el único problema es configurarlo correctamente.De hecho, todo es mucho más complicado y una empresa con un programador tiene objetivos muy diferentes. Por lo tanto, al hablar sobre quién, quién y qué debería, parece una declaración de que el comprador no debe robar bienes en la tienda. Si, no deberia. Más precisamente, no debe robar, si habla de acuerdo con las reglas de la lógica formal. Simple, comprensible, aceptado por la abrumadora mayoría. ¿Y qué? ¿Esto significa que la tienda puede disparar guardias y derribar cámaras?En mi primer artículo sobre Habré, consideré la situación desde la perspectiva del empleador (empresa) y expliqué los principios que sigo para encontrar personas que resuelvan los problemas de la empresa . Y por qué es tan importante.Pero hay una advertencia, y es que las personas que no son entrevistadas por entrevistadores como yo, con la debida destreza, logran más que los que se benefician. Y hay una buena razón para esto: maximizan con éxito la habilidad que más se correlaciona con los ingresos del programador: la capacidad de venderse uno mismo. Cómo, lo diré en esta publicación.Descargo de responsabilidad, . . , , , , Junior -> Middle -> Senior -> Lead dev -> Tech lead -> Architect -> Chief architect -> CTO.
Formulación del problema
En primer lugar, descubriremos lo que cada una de las partes quiere lograr: lasempresas desean una solución económica y oportuna para sus tareas de TI, satisfacer expectativas y, en el caso de una gestión avanzada, también crear nuevas oportunidades de desarrollo empresarial.El programador quiere cultivar su valor en el mercado laboral, maximizar las condiciones de trabajo (incluyendo $, horario, rigidez de control, beneficios y beneficios), resolver problemas por los cuales puede aumentar su credibilidad y obtener satisfacción de la solución.Conflicto
En realidad, es fácil encontrar un ejemplo cuando hay un beneficio mutuo, como el desarrollo de un núcleo DBMS patentado, donde un programador resuelve aplicaciones atípicas del nivel de olimpiada, se aleja de esto, habla en conferencias y luego las ventas aumentan las ventas, mostrando a los clientes cuánto más eficiencia y estabilidad del núcleo que los competidores, ahorrarán en infraestructura.Pero no hablaremos de tales casos. Hablemos de los casos que enfrenta la gran mayoría de los programadores que toman decisiones ordinarias una y otra vez. Otra tienda en línea, otro casino en línea, otro día de operaciones para un negocio bancario ordinario no tecnológico ...Y hay un conflicto agudo. Porque las soluciones oportunas, confiables, predecibles, baratas y bien respaldadas se realizan en tecnologías probadas con el tiempo. Condicionalmente, si el panel de administración de su tienda en línea con un núcleo ASP.NET está escrito en WebForms, y los autores del código aún no van a irse con usted, entonces el panel de control del sistema de recomendación recién creado también debería estar escrito en WebForms, aunque el paquete .NET Core + Angular + TypeScript 1000 veces mejor, y de hecho WebForms es un desastre. Después de todo, el equipo que escribió los 500 formularios redactará el 501º de manera rápida y confiable, evitando el rastrillo. Y el negocio obtendrá una buena solución.Para los programadores que se han dado cuenta del valor de WebForms en el mercado, escribir en él puede ser como una tortura, porque entienden perfectamente que durante la redacción de este formulario, aumentarán el valor del negocio, pero al mismo tiempo disminuirán el suyo, porque mientras se detiene, la industria corre a tu lado. Por lo tanto, en esta situación, cualquier programador sensato (incluso si es copropietario, después de todo, nadie garantizará que la tienda viva para siempre, y será muy doloroso buscar trabajo en caso de quiebra de la tienda) tratará de obtener de alguna manera el derecho de completar la tarea en algo luego fresco y en demanda, por supuesto, pasando más tiempo al mismo tiempo, permitiendo más errores, pisando más rastrillos.Está claro que esta situación es exagerada. Pero la esencia sigue siendo la misma independientemente del dominio y la tecnología.Un código simple en una solución de equipo conocida, no probada por el tiempo, que no sea HYIP, brinda previsibilidad y confiabilidad empresarial, y el equipo se degrada. El código en un nuevo marco publicitario y / o con alta complejidad algorítmica da desarrollo al equipo, pero el negocio sufre riesgos por esto. El enfoque en una comprensión profunda del área temática por parte del programador puede aumentar significativamente el valor del negocio (escribir exactamente lo que se requiere y no escribir lo que no es necesario), pero no aumenta el valor del programador (el conocimiento de la contabilidad rara vez se solicita en el mercado para los programadores) sobre tecnologías y algoritmos, por el contrario.Después de todo, un programador que conoce bien los algoritmos y las tecnologías encuentra fácilmente el trabajo con un impulso, mientras que para los negocios la mayor parte del conocimiento es redundante e inaplicable. Y un servicio escrito en marcos de moda con el uso correcto de patrones y la complejidad algorítmica correcta no ayudará mucho al negocio si no hace lo que se esperaba.Sí, hay factores secundarios. Por ejemplo, los temas exagerados simplifican la contratación, y el legado infernal reduce la salida del personal existente (a la gente le gustaría irse, pero a ninguna parte), pero estos son matices y no son tan importantes.Soluciones
Entonces, imaginemos el momento en que el programador se dio cuenta de que el negocio quería recompensarlo un poco (bueno, digamos, posponer su desarrollo) por una causa común. ¿Qué se puede hacer?Obedecer. Y perder en sus propios intereses. Los comentarios son redundantes.Ir directamente al conflicto. Por decirlo así, dicen que no soy un esclavo para ti. Si desea un código primitivo de copiar y pegar con un profundo conocimiento de la contabilidad, busque un tonto. No voy a hacer eso. Quizás un paseo una vez. Pero no hay necesidad de hablar de una carrera aquí.Para convencer a la empresa de que necesitan exactamente lo que usted necesita.Esta es una opción correcta para el programador. Sí, es difícil de lograr con un alto nivel técnico del gerente y bajas habilidades de persuasión del programador. Pero siempre vale la pena intentarlo. Después de perder, siempre puedes elegir p1 y guardar hasta la próxima vez. Y al ganar, obtienes respeto y un sentido de valor de la empresa y tu crecimiento profesional al mismo tiempo.La única pregunta es ¿cómo obtener este santo grial?Aquí veremos algunas historias fascinantes.Historia 1. Sobre el jefe del departamento Vasily
Vasily fue uno de los programadores más experimentados de la corporación. En el transcurso de una carrera de veinte años, pasó de ser un programador junior a un jefe de departamento. Tenía 40 personas con subordinados directos, resolviendo problemas directamente con el fundador, y no con el CEO y su adjunto, como otros gerentes de su nivel. Y aún orinar código para mantenerse en forma. Hizo su carrera debido al hecho de que tenía una inteligencia excepcional y, además, los negocios podían comunicarse con él en el mismo idioma. Antes de esto, Vasily estaba en una carrera constante. Hizo promesas y con todas sus fuerzas las alcanzó. Por esto fue adorado. Sí, se rumoreaba que siempre solicitaba plazos demasiado largos, pero, por otro lado, los movía con mucha menos frecuencia que otros jefes de departamento.Y luego fue reconocido como el mejor gerente del año, comenzaron a poner a todos como ejemplo, y Vasily (quien en su corazón nunca dejó de ser programador) se dio cuenta de que era hora de aprender nuevas tecnologías, y a expensas de sus subordinados, experimentar con nuevos enfoques, en particular, con DDD.El producto estrella del departamento de Vasily, la estación de trabajo automatizada (AWP) del comerciante de futuros, ayudó a ganar mucho dinero y, a lo largo de los años de operación, casi todos los errores quedaron atrapados y pulidos para que brillaran. El problema era que era una aplicación de escritorio para Windows (mientras que todos los que estaban cambiando a la web), y usaba MSSQL como DBMS, lo que, según Vasily, también era una edad de piedra, porque los DBMS relacionales se usaban mientras las personas No aprendí a hacer bases normales.Y ahora estamos hablando de la necesidad de escribir un lugar de trabajo automatizado para un operador opcional. El proyecto tuvo una duración de alrededor de 6 meses, incluido el tema de un nuevo equipo y las pruebas beta, si bifurcamos los nabos de la terminal de futuros y reemplazamos una serie de módulos. Pero, maldita sea, hacer otro producto utilizando tecnologías obsoletas ... Bueno, esto no es interesante. Sí, y la gente tendrá que cazar por encima del mercado, porque nadie quiere aprovechar esas cosas (y la capacidad de cazar y mantener a las personas un 20% por debajo del mercado era la característica asesina de Vasily), y por lo tanto, el hecho de cazar por encima del mercado habría sacudido su reputación.Por lo tanto, qué hizo Vasily: convenció al CEO de que, en aras de las ganancias y la estabilidad del negocio, todo debería escribirse con 0, un nuevo equipo, asegúrese de ir a la web y no tomar un solo byte de la solución anterior, aunque tomará 2 años. Dada su reputación y experiencia profesional, no fue tan difícil.Dos años después, la decisión fue en picado. Los marcos nuevos, MongoDB, DDD, funcionan desde el navegador, ni un solo byte desde el terminal para futuros ... Verdadero, montañas de copiar y pegar, arquitectura que no permite integrar algoritmos sin muletas, reescrita desde 0 módulos, donde los elegantes algoritmos de la estación de trabajo de futuros fueron reemplazados por toneladas de código repetitivo. Basilio, sin embargo, elevó su autoridad bastante bien. La estación de trabajo opcional durante mucho tiempo citada como ejemplo para otros gerentes. Después de un par de años, Vasily todavía cayó en desgracia, pero esa es otra historia.En total, el resultado final: Vasily descubrió nuevas tecnologías, infló al personal, aumentando su importancia, y el negocio permaneció completamente seguro de que ayudó al negocio y una vez más cumplió sus promesas.Historia 2. Sobre la virgen principal Anton
A Anton, de unos 30 años, le encantaba aprender nuevas tecnologías y resolver problemas de olimpiadas. Ocupaba un lugar casi ideal para su tipo, era la doncella principal del equipo de infraestructura. Anton conocía muy bien las especificaciones y las últimas tendencias arquitectónicas. Y el desafío intelectual favorito de Anton era encontrar la justificación de cómo la tecnología publicitaria ayudaría al negocio y dónde valdría la pena empujarlo. En esto, fue apoyado por el arquitecto, que tampoco era reacio a sondear el nuevo rastrillo con la frente de Anton. Como resultado, Anton fue invitado a hablar con FAANG, donde revisó toda la parte teórica sin problemas y completó brillantemente la tarea de diseñar la arquitectura de Ebay (aunque no se requería nada de eso en el trabajo anterior). Luego zarpó en los EE. UU., Y dejó detrás de él 3 módulos altamente cargados en el producto, que ahora nadie quiere mantener y desarrollar,porque nadie entiende cómo (y por qué) funcionan.Total, en el fondo: Anton claramente sabía lo que quería y llegó a su objetivo, tomando el máximo de su empleador. El negocio también estaba seguro de que Anton era un empleado muy valioso, porque, como ya mencioné, siempre pensó cuidadosamente en la razón, incluso cuando eran salvajes para las personas en el tema.La historia del arquitecto Ivan.
Timlid Ivan y Timlides Vladimir y Yuri vieron el producto bajo el liderazgo del arquitecto Sergey. Sergey los trajo a los tres a la compañía, y los cuatro tomaron decisiones clave. Después de que el producto salió a la venta en 4 años de operación, pero aún estaba lejos de la estabilidad, el liderazgo atacó a Sergey y se fue con la cabeza en alto. Siguiéndolo, Vladimir y Yuri se fueron.En un momento, Iván se convirtió en el único portador de conocimiento sobre lo que estaba escrito (excepto el superior y el medio, a quienes Sergei no dedicó particularmente a la visión general). Sintiendo que huele a frito, el liderazgo designó a Ivan como arquitecto con el personal correspondiente con la esperanza de que no se fuera. A lo que Ivan dijo, dicen, esto, por supuesto, es bueno, pero esto no es suficiente para que no me vaya. Si quieres que apoye lo que vimos con Sergey, déjame reescribir todo con 0. Las empresas aceptaron a regañadientes. Ivan recibió un salario, un puesto y la capacidad de escribir todo desde 0 en un día.Total: Ivan entendió correctamente cuál era el problema comercial: el negocio está asustado por el temor de que lo que vieron durante el tiempo de Sergey pueda fallar, y no hay nadie que lo resuelva. Y presionó el negocio al máximo.Total
Ya sea que lo desee o no, pero por el bien de una carrera, $ y la oportunidad de hacer cosas interesantes para usted, al menos tendrá que hablar y pensar en el valor comercial. Sí, puedes traerlo, no traerlo, o incluso traer lo negativo. Pero en este sistema de relaciones, cuanto más larga sea la cadena de valor que controlas para quien paga, más fuerte será la posición de negociación y la capacidad de hacer lo que quieras, en lugar de declarar.