Ver un lenguaje de programación nuevo y hasta ahora poco conocido en una pequeña startup o proyecto favorito con amigos es algo común. Preguntarán por qué lo tomaron, dirán que lo aprendieron por curiosidad, les gustó y decidieron experimentar, porque están cansados del eterno Java / .Net / JS en el trabajo.
Pero si una empresa habla de sí misma en frases como "negocios internacionales", "oficinas en todo el mundo", "culto a la productividad", "el resultado es importante para nosotros, no el proceso", "necesitamos ojos ardientes y el deseo de desarrollarnos", por lo general no esperando sorpresas Algunos incluso ponen listas de paro en las nuevas tecnologías hasta que ganan peso en la industria. A las preguntas sobre los inconvenientes de las herramientas, evasivamente diga: "lo principal son las personas, no los idiomas".
Wrike, con alrededor de 400 desarrolladores, tiene un enfoque diferente. No hicieron la vista gorda ante las deficiencias de JavaScript y ni siquiera eligieron un compromiso, como Flow o TypeScript, sino que fueron de una manera completamente radical. Reescribieron el frente en un idioma que miles de personas apenas sabían en ese momento y, al parecer, todavía tienen absoluta confianza en sí mismos.
Wrike obtuvo un honorable tercer lugar entre las medianas empresas en el ranking de los mejores empleadores en My Circle IT con una calificación promedio de 4.82. Las principales cualidades más valoradas de la empresa incluyen: paquete social, condiciones de trabajo cómodas, relaciones con colegas, salario adecuado y crecimiento profesional.
- Wrike fue fundada por Andrey Filev en 2007 en San Petersburgo. Luego comenzó a desarrollar negocios en Estados Unidos, en Silicon Valley. Entonces era una empresa completamente diferente, y ahora hemos crecido mucho.
Al principio, Andrey tenía una empresa de outsourcing. Comenzaron a buscar software que le permitiera trabajar de manera más eficiente: administrar el tiempo y los recursos. No había una herramienta realmente genial en ese momento, y surgió la idea de crear la suya. Entonces nació Wrike.
Comenzamos con cosas simples, pero gradualmente el producto comenzó a crecer. Esto fue hace 12 años, y podemos decir que participamos en la formación de un mercado para tales sistemas de gestión del trabajo. Wrike ahora es utilizado por más de 18,000 compañías en todo el mundo.
- ¿Sigue existiendo esa empresa de outsourcing?Sí, se llama Murano Software. Pero ella no tiene nada que ver con nosotros. Wrike es una empresa de un solo producto en toda regla, que fue un experimento en el marco de una empresa de outsourcing, pero se disparó y se separó muy rápidamente.
"¿Todavía lo están usando allí?"Si aun.
¿Qué es Wrike?
Wrike es una plataforma para la gestión y colaboración de proyectos en un sentido muy amplio: desde una lista personal de tareas hasta un sistema adecuado para grandes empresas.
En el interior, puede crear proyectos con muchas tareas y subtareas, configurar informes para la recopilación de datos, mostrar gráficos de Gantt, realizar un seguimiento de las tareas en el calendario y editarlas simultáneamente con otros participantes. Los complementos de Wrike lo ayudan a administrar su carga de trabajo en tiempo real o ejecutar complejas campañas de marketing multicanal. Hay una API para la integración en otras herramientas. Hay extensiones, por ejemplo, para Adobe Creative Cloud. Le permite ver y comentar archivos sin salir del sistema.
Wrike no busca enfocarse en una función, industria o profesión en particular. Se posiciona como una herramienta universal para todo, hasta reemplazar el sistema de correo, mensajería, base de conocimiento, rastreador de errores y mucho más.
- ¿Desenfocarse en todos y para todo no empeora las partes individuales?- No entramos deliberadamente en nichos de perfil estrecho. Por ejemplo, no queremos hacer exclusivamente sistemas de seguimiento de errores para desarrolladores como Jira. No queremos hacer software solo para programadores o solo para diseñadores. Estamos interesados en hacer un producto universal. Al mismo tiempo, entendemos que hay casos altamente especializados que no cubrimos.
Pero este no es nuestro objetivo: complacer a todos o ocupar completamente el nicho de TI. Aunque nosotros, desarrollando Wrike, lo usamos como un sistema para tareas y un rastreador de errores.
- Es decir, puede llevar el rastreador de errores más rápido, el mensajero es más rápido, pero serán cinco herramientas diferentes y será difícil sincronizarlas.
- Pero luego tienes que competir con todos. Atlassian por un lado. Flojo como un mensajero, por el otro.- Sí, ahora solo los perezosos no están desarrollando sistemas de gestión de proyectos y productos.
- Pero, de hecho, no hay tantas compañías que compitan con nosotros en todos los aspectos.
- ¿No es así Atlassian?- Está más enfocado en el mercado de TI. Por ejemplo, para los diseñadores, Jira es demasiado complicado.
Es muy difícil de personalizar. Incluso hay una profesión: Jira Setup Manager. Intentamos asegurarnos de que vaya al sitio, tome una cuenta gratuita y eso es todo: desde el primer día puede usarlo sin problemas.
- Pero usted dice que también trabaja en estrecha colaboración con los clientes y también con los gerentes directos que establecen los procesos.Sí, tenemos un equipo de gerentes de implementación y éxito del cliente, así como un sistema completo de tours, guías, libros electrónicos y todo tipo de documentación. Hay gerentes que lo ayudarán a configurar Wrike para procesos listos para usar. A veces trabajan con grandes clientes uno a uno. A veces inmediatamente con muchos (por ejemplo, grabación de seminarios web). Incluso si una persona registró una prueba y no entendió el producto, tendrá la oportunidad de chatear en vivo con uno de los rikers y comprender cómo funciona.
- En general,
introducir un producto en una empresa con miles de usuarios es otra tarea.
- ¿Sucedió que fue muy difícil con uno de los grandes clientes?Por lo general, cuanto más grande es la empresa, más procesos de trabajo tiene, más difícil es trabajar. Por supuesto, no estamos subcontratando. No existe tal cosa que venga algún tipo de bolsas de dinero y diga: "aquí hay mucho dinero para ti, hazme tal cosa". Nuestros gerentes de producto determinan las rutas de desarrollo de productos ellos mismos. Pero hay clientes con solicitudes interesantes.
Airbnb, por ejemplo, utiliza la plataforma en casos muy inusuales. Cada apartamento y cada persona que lo alquila es un proyecto separado en Wrike.
O la compañía de automóviles Coil [nombre cambiado]. Los clientes les ordenan piezas de repuesto. Dar a estas personas cuentas de Wrike es solo una idea. No será cada propietario de Coil haga su cuenta. Pero la compañía realmente quería una oportunidad conveniente para trabajar con los clientes.
Por supuesto, no dijimos que en este momento haremos una función para ellos. Pero los gerentes se dieron cuenta de que ella mejoraría el producto en su conjunto. Así es como aparecieron los "formularios de solicitud externos" para las personas que no tienen una cuenta Wrike.
- Resultó, ¿lo hiciste para Coil [nombre cambiado], pero ¿se adaptaba a todos los demás?"En realidad no". Simultáneamente analizamos el mercado y planteamos la hipótesis: esta tarea se encuentra en una hoja de ruta potencial. Si hubiera una solicitud que no nos satisface en absoluto, no lo haríamos.
La estructura interna de Wrike
Trabajamos en Scrum. La compañía está dividida en equipos por características: aproximadamente 10 personas cada una. Son de composición diferente, pero cada uno tiene un back-end, frontend, scrum-master, QA, QA automation, UX-designer, product obouner, analista de producto (los analistas a veces vienen en varios equipos). Tal composición es completamente funcional y puede hacer una característica desde y hacia.
Hay equipos internos que crean marcos, componentes, kits de diseño y participan en la transición de una versión de un lenguaje de programación a otra.
Algunos equipos son comunes a toda la empresa. Por ejemplo, estos son SysOps, que se dedican a la infraestructura del servidor, y DevOps: se dedican a la implementación y entrega de productos. Tenemos lanzamientos de una a 3 veces al día.
También utilizamos parcialmente la conocida estructura de Spotify con gremios. Por ejemplo, el frontend, donde el front-end consta de todos los equipos. Hay clientes potenciales que se ocupan de la gestión y la arquitectura. Y hay pistas de gremio.
Todavía no hemos llegado al punto de aislarlos de los equipos. Pero en general es lógico y orgánico. Ahora las personas con altas habilidades de arquitectura técnica están en equipos de infraestructura.
Wrike no se trata realmente de una estructura burocrática. Pero esto no significa que el caos esté sucediendo en nuestro país. Si una persona hace lo que le gusta y lo hace bien, tendrá oportunidades de crecimiento, independientemente de la posición que ocupe.
- ¿Y en qué oficina se está haciendo?- En San Petersburgo y Voronezh, oficinas de ingeniería. Tenemos 400 personas en San Petersburgo y 40 en Vorónezh. Hay oficinas en San José, San Diego. Se abrirá una oficina en Praga este año. Oficina recientemente ampliada en Dublín. En enero de este año, se abrió una oficina en Melbourne, Australia.
- En las oficinas estadounidenses tenemos un departamento de ventas, marketing, gerentes (CSM). Dublín también tiene CSM y ventas. También hay un equipo de analistas. En San Petersburgo, la oficina más grande y unificadora. Aquí tenemos gerentes de servicio al cliente, gerentes de producto, analistas, diseñadores, desarrollo y back office.
- ¿Todos trabajan en oficinas o estás abierto a una ubicación remota?- Los comandos de scrum remoto son muy difíciles. Queremos que las personas estén cerca y en contacto entre sí. En los departamentos que pueden involucrar trabajo remoto (por ejemplo, Atención al cliente), no limitamos mucho a los muchachos.
- Udalenka en desarrollo: un punto discutible. Ahora se habla mucho al respecto, en Twitter en inglés hablamos constantemente sobre este tema. Hay pros y contras. En nuestra opinión, hay más "contras". Como gerente de equipo, sería difícil para mí garantizar la productividad y un espíritu común, crecer y entrenar a empleados remotos.
Tenemos un horario bastante flexible, las personas no se sientan en la oficina estrictamente de diez a seis. Si hay un stand-up, sea amable, venga, y cuando pase y cuánto tiempo llevará, los equipos eligen por sí mismos. Si algo sucede, también sin problemas, la persona escribe que trabaja desde casa.
- Cuando el producto es internacional, a menudo se requiere que los desarrolladores tengan un buen conocimiento del inglés para poder hablar con los clientes.- No tenemos clientes, no somos subcontratistas. La compañía es internacional, y parte de las comunicaciones se lleva a cabo en inglés, pero esto no se aplica a todos. Para los desarrolladores en Rusia, no tenemos un requisito especial para saber inglés.
Una vez al mes hay reuniones en las que hablamos sobre todos los cambios en la empresa y el desempeño financiero. La comunicación con el soporte se lleva a cabo en inglés. Las entradas con errores de los clientes también están, por supuesto, en inglés. Para aquellos que quieren aprender o aprender un idioma, existe la oportunidad: tenemos clases continuas con maestros, para los empleados son gratuitos.
Pero mi opinión es que si un desarrollador no comenzó a desarrollar ayer, sabe inglés al menos a nivel de lectura de documentación. Sin lengua, ni siquiera puedes googlear nada.
Por supuesto, los desarrolladores pueden no tener un acento británico verdadero y no hay Oxford detrás de ellos, pero generalmente pueden hablar y leer algo.
Por qué Dart es mejor que JavaScript y TypeScript
- Ahora todo esto es un gran sistema complejo. Pero surgió del desarrollo interno hace mucho tiempo y ha cambiado mucho desde entonces. Debido a esto, ¿no hubo errores de cálculo arquitectónicos que ahora interfieren con la vida?- Por supuesto, el proyecto es grande. Tenemos en el backend una y media o dos millones de líneas de código Java. El frente también es comparable. Pero no conozco a una sola persona que pueda diseñar el sistema con cinco años de anticipación, y se desarrollará sin reconstrucción.
Sucede que algo cae. A veces nos damos cuenta de que hace dos años eran más tontos. Pero esto es natural desde el punto de vista del ingeniero. Como mas?
- Por lo tanto, hay equipos internos que periódicamente reescriben partes viejas.
- Sí, a veces digo que necesitamos sentarnos y refactorizar, de lo contrario, disparará para que todo se dispare. Nos sentamos y refactorizamos. La arquitectura interfiere: hacemos arquitectura.
- ¿Cuál es tu pila?- En el backend de Java. Base de datos SQL En la parte delantera, una cosa interesante. Érase una vez que teníamos JavaScript, pero nos dimos cuenta de que no se escalaba en absoluto y elegimos Dart.
- ¿Qué has elegido?- Dart. Sí, esta es una reacción normal. Un lenguaje escrito de Google, que ahora tiene casi siete años. Probablemente somos los evangelistas más importantes de este grupo en Rusia.
- ¿Los más importantes o los únicos?- Por cierto, ahora se está desarrollando activamente. Google lanzó Flutter: este es un marco para dispositivos móviles escrito solo en Dart. Hay una
comunidad rusa de dardos que hemos creado y apoyamos. Ya hay alrededor de mil quinientas personas. Por supuesto, según los estándares de JavaScript, esto no es muy impresionante, pero también mucho.
En diciembre pasado, organizamos
la conferencia DartUp : había un gran salón y mucha gente vino. Y muchos realmente usan Dart en la producción. El lenguaje se está desarrollando gradualmente y es muy bueno.
"Así que ahora estamos a caballo". Decir "en el mundo" es probablemente pretencioso, pero, de hecho, lo es. DartUp es la conferencia de Dart más grande del mundo. Incluso más que Google.
- Había unas trescientas personas en la conferencia. Aunque hace dos años parecía que estábamos solos en el campo de los guerreros.
- Todo esto es interesante, pero cómo trabajar en un proyecto a gran escala, si no contratas personas, no hay bibliotecas ni marcos.- Esto es una falacia. Recientemente, contratamos al equipo con un hombre para quien Dart fue generalmente el primer lenguaje de programación.
- En Dart, todo está ahí. Este es un lenguaje de la categoría de C # y Java: todo lo que necesita está integrado allí. Y, en general, no es cierto que todo esté vacío allí y que la caída ruede. Hay incluso más incorporado que en algunos idiomas de veinte años. Bibliotecas, herramientas, soporte de marco: Angular también está allí.
Por supuesto, no hay infraestructura como en JS. Pero el problema es que cuando las personas escriben millones de bibliotecas, obtienen millones de bibliotecas malas. Y tal vez solo cien normales.
Y si las bibliotecas están escritas por Google, que usa Dart en AdWords y AdSense, entonces la calidad promedio es mucho mayor.
La belleza del lenguaje es que es simple y similar a C. Es decir, contratamos desarrolladores en C ++, C #, Java, JavaScript, cualquiera. No requerimos conocimiento de Dart. Naturalmente, no hay desarrolladores de dardos en la calle.
En mi equipo hay un desarrollador con la experiencia de C Sharp, quién sabe. En el frente, él ni siquiera escribió. Y en cinco días bajó una característica. Porque el lenguaje es como si hubieras estado escribiendo sobre él toda tu vida.
En el buen sentido, los ingenieros de desarrollo escriben lógica empresarial, sin importar el idioma.
"¿Pero las personas no comienzan a escribir en su idioma anterior?" Los mismos apodos de JS vinieron de un lenguaje dinámico a uno estático.- Por lo tanto, nuestro proceso de selección no es el más fácil. Pero justo y honesto.
- Ok, ¿por qué es bueno el idioma?Yo diría que es uno de los más fuertemente tipados que compila en JS. Cuando nos sentamos en el front-end hace cuatro años y éramos aproximadamente 8 de nosotros, al menos puedes cubrirte con todo tipo de linters, reglas, todo en el mundo, pero él todavía echará de menos algo. Necesitábamos un tipeo estático, lo más estricto posible.
En Dart, si escribes algo mal, lo entenderás de inmediato. Tiene detección de errores anterior, lo que permite, incluso sin probar el código, comprender si funciona o no.
No hay caos en la biblioteca integrada cuando uno se actualiza y el otro se cae. Porque el SDK se suministra con el idioma, lo que garantiza que todo funcione después de la actualización. No necesita conectar un millón de bibliotecas para obtener transmisiones y transmisiones: todo ya está allí.
Ahora en el mundo hay dos idiomas que le permiten escribir para todas las plataformas: para dispositivos móviles, backend, computadoras de escritorio y web. Esto es JS y Dart. JS contras saber cuántos. Y Dart tiene una gran ventaja: escribir.
Por lo tanto, solo hay un lenguaje de tipo rígido que le permite escribir para todas las plataformas con ajuste normal. Muchos citan a Kotlin como ejemplo, pero para la web no es muy.
- Ahora no te arrepientes de que, por ejemplo, TypeScript no fue elegido?- Ahora no, pero en principio no nos arrepentimos. Le aconsejo que vea el informe de Victor Logov de JetBrains en la conferencia HolyJS [
El orador probablemente confundió el nombre, y fue un informe de Anton Lobov ].
Hacen soporte de TypeScript en sus productos, y simplemente pone TS en los estantes allí, razonablemente. Y después de eso no hay ningún deseo de tomarlo. Uno tiene la sensación de que las características aparecen en el principio de "¿Vamos a agregar esto? Vamos.
- Para que yo crea, dime ¿qué hay de malo en Dart? Puede que no sea que todo sea perfecto.Fácilmente Hay problemas, pero no con el idioma, sino con Google. Usan muchas herramientas en su interior, que no sacan a la basura. Ahora tenemos un canal directo con Google, somos parte de una serie de organizaciones internas y poco a poco están regalando estas herramientas.
Pero esto es relevante solo para nosotros, para una base de código muy grande. Los proyectos pequeños no tienen ningún problema.
- Después de la experiencia con Dart, ¿no querías reemplazar Java con Go?- por qué? Seleccionamos Dart de acuerdo con ciertos parámetros. Fue una decisión equilibrada.
- Uno de nuestros oradores dice que hay compañías que reescriben todo con nuevas tecnologías, y hay compañías que ganan dinero. Reescribir no debería ser un fin en sí mismo. Hay tareas comerciales y hay herramientas que deberían implementarlas.
- Estamos experimentando con diferentes tecnologías. Si en algún momento entendemos que Go funciona mejor, entonces lo intentaremos.
En la parte delantera, nos estamos moviendo hacia aplicaciones independientes. Hay un monorepository en el backend. Hay muchas ventajas en esto, pero también hay ciertas desventajas: puede hablar de esto durante mucho tiempo. Miramos hacia la arquitectura de microservicios basada en lo que será útil en nuestro entorno.
La arquitectura de microservicios funciona bien donde hay pocas conexiones. Si tiene muchas conexiones, los microservicios se convierten en dolor. No hay bala de plata. Para hacer esto, tenemos un equipo completo que explora lo que se usa mejor en nuestro entorno.
Contratación de ingenieros, no expertos en idiomas.
- ¿Qué necesitas ser para llegar a ti?- Tomamos personas que están interesadas en lo que hacen. Este es un cliché, sobre ojos ardientes. Sin embargo, esto es importante. Incluso si es un buen desarrollador, pero no le importa qué recortar, aunque solo sea para trabajar de diez a seis y recibir dinero, con una alta probabilidad de que esto no nos convenga.
- Tomamos personas que quieren aprender, desarrollarse. Si crees que todo ya se ha logrado y ahora el rey del mundo tampoco es nuestra opción.
- Dado que tenemos un canal de comentarios bastante bueno desde el desarrollador hasta el negocio y viceversa, el enfoque de "aquí, trabajar" no es muy adecuado. Intentamos contratar personas que estén listas para ofrecer su visión, que tengan opiniones y preguntas.
Esto hace que el proyecto avance mucho más rápido que si contratas a tres súper adultos mayores que dicen "mi tiempo de trabajo ha terminado y, en general, no me pagas lo suficiente". Harán menos que la persona que corta el proyecto en un día en el hackathon, lo lleva a producción.
- Estamos buscando personas que se interesen, que estén interesadas en seguir adelante.
- Así que vine a ti, dije que soy tan decidida, tengo mucha opinión, mis ojos están ardiendo. Todavía los empujé con algo para brillar, digo, tómame. Entonces tómalo?- Las entrevistas no son tan simples. Creamos condiciones cercanas a los procesos de trabajo y observamos cómo se muestra una persona. Si eres desarrollador, escribirás código. Si eychar - se entrevistará.
- ¿El desarrollador escribirá el código en la entrevista?— , , .
, , . , , , , .
: « React-», — . React, ?
, . . , JS. : « Jira Wrike. ?»
, — Go, . , . , , .
— , , « », ?— . , . . , , . — . . , .
, , . , , ? . , … — , « ».
— . ?— .
Wrike , , . , . , , , .
— ?— . Gantt-. Canvas, . , , Google — , Dart . , .
— , - , ?— . . , -. Wrike, . , - , .
— ? , 400 . ?— . — . , . Cultural fit, , .
— . , ?— -5 . — . , . , , ? , .
— , , ?— , - . , , , .
— , , . . . . , , — .
— , ?— . . - .
— , ?— . , . , , , . .
— . Wrike — safe place. Google , — . , .
, , — .
— , ?— — . . , — , .