Maneras de resolver problemas max dorofeev. Entrevistas de Counter Strike

Fui a una conferencia y capacitación de Maxim Dorofeev sobre la organización de asuntos. Maxim habló sobre la irracionalidad en el trabajo, sobre la correcta formulación de la tarea y el trabajo con el correo electrónico.

Leí mucho sobre Maxim y su técnica Jedi de bandeja de entrada vacía, y luego fui a un seminario. El seminario fue sobre todo a la vez, pero resultó ser interesante. Esto se debe en gran parte a la organización ejemplar de la conferencia: diapositivas, estilo, bromas, práctica: todo fue perfecto. Asisto mucho a charlas y conferencias, pero por primera vez disfruté tanto de la organización. Ir al entrenamiento valió la pena solo por la sensación.

Dirigí el resumen del seminario, lo publico. Les advierto que esto es solo un resumen para mí, y no un recuento detallado.

1. Las reglas no nos garantizan el resultado, sino que solo pueden influir en su probabilidad.
2. La mayoría de nosotros sabemos muy bien cómo debemos comportarnos. El problema no es la falta de conocimiento, sino la ejecución.
3. Tenemos en la cabeza el ideal del hombre aristotélico: toda acción humana tiene una razón, está encaminada a un resultado. Pero, de hecho, la mayoría de las veces la mayoría de nosotros somos irracionales, impulsivos, actuamos en la máquina (sobreestimamos nuestro nivel de conciencia). Pero no consideramos este comportamiento como la norma.
4. Pensar duele.
5. Todos estamos trabajando en asuntos urgentes. Bueno, ¿por qué trabajar en casos no urgentes hasta que se vuelven urgentes?
6. Para un responsable el pendel viene de adentro, para un irresponsable viene del liderazgo.
7. Al estimar una tarea, a menudo agregamos un búfer "por si acaso". Se debe hacer en dos días, estimamos el plazo de una semana. Pero consideramos que tal tarea no es urgente. La fecha de finalización de la tarea se convierte en una fecha antes de la cual no sucede nada.
8. Cuando le das a una persona una tarea tras otra, las resuelve fácilmente en el tiempo asignado. Los das todos a la vez: ella comienza a pensar en la planificación y algunos no tienen tiempo.
9. La frase "priorizar" suena como "hacer una lista de mis únicos pendejos". Cuando las personas priorizan, eligen entre lo importante y lo urgente. Pero, de hecho, eligen lo comprensible.
10. La memoria funciona torcidamente: el corto plazo dificulta pensar, es malo escribir a largo plazo.
11. La memoria humana no tiene garantía de autenticidad. Hay un experimento psicológico en el que a las personas se les muestran sus fotos de la infancia retocadas con Photoshop. Ya en la tercera entrevista, las personas recuerdan en detalle los hechos en los que no participaron.
12. Para hacer más, necesita ahorrar combustible mental. Para hacer esto, debe minimizar los "pensamientos repetidos": formular correctamente las tareas. Es necesario descargar la memoria de trabajo: transfiera todos los datos a la computadora. También necesita reducir la conmutación externa.
13. ¿Quién es débil para venir a Ikea por baterías y comprar baterías?
14. Incluso hay una aplicación de teléfono inteligente para la meditación. La gente durante tres mil años de alguna manera se las arregló sin él.
15. Si desea ahorrar en el manejo del correo, procese las cartas en lotes.
16. Procesar una letra significa extraer partes semánticas de ella, dividirla. Después de leer, debe tener tareas, reuniones, nueva información.
17. No hay personas correctas e incorrectas. Hay personas cuya imagen del mundo es diferente a la tuya.
18. La formulación correcta de la tarea es como si le estuvieras diciendo la secuencia de acciones a una criada no muy lista. Sólo esta doncella eres tú.
19. Una buena tarea responde a la pregunta "¿Qué hay que hacer?". Es importante no presumir, sino escribir con sencillez. No "Tratar con el informe anual", sino "Agregar una tabla a la última diapositiva".
20. “Construir una casa” no es una tarea, sino un proyecto. El proyecto "Construir una casa" tiene muchas tareas: "Llamar al banco", "Llamar a la empresa constructora".
21. Un buen problema contiene un verbo en su forma inicial, un predicado.
22. Una buena tarea suena para que puedas agarrarla y hacerla en cualquier momento.
23. La formulación de una buena tarea es lo mismo que el primer paso que hay que dar para completarla.
24. Tarea útil: "Bajar 15 minutos en el tema". Se trata simplemente de pensar en la tarea, no de aferrarse a ella de inmediato.
25. Los proyectos deben tener plazos, las tareas no tienen plazos.
26. Si no tiene ganas de hacer una tarea, es útil pensar en lo que sucederá si no la hace. A veces queda claro lo que se puede y lo que no se puede hacer. A veces quieres tomar y hacer.
27. Si la gente se le acerca y lo distrae, y esto sucede regularmente, organice reuniones periódicas. Deje que la persona acumule ideas y tráigalas en una lista.
28. No confundas multitarea y multiproyecto. Leer cinco libros al mismo tiempo es difícil, es multitarea. Y puedes leer un libro, cargar tu teléfono y construir una casa.
29. El pequeño hada mágica. Tomas una tarea, la miras y piensas: ¿qué haría si un hada volara y me diera solo 20 minutos para completar esta tarea?
30. Generar ideas y evaluarlas son dos procesos diferentes.
31. En las empresas, existe el acoso de calendario: las propias personas reservan citas en los calendarios de otras personas. Es bueno darse tiempo para trabajar.
32. Una evaluación integral del proyecto se describe mediante las preguntas: ¿Qué? ¿Qué más? ¿Para qué? ¿A quién y para qué? ¿De que otra forma?
33. A menudo, eligiendo entre "Hazlo bien" y "Hazlo mal", realmente solo podemos influir en el momento en que el trabajo se hará por el culo. Una enorme capa de proyectos no se puede hacer bien a la vez.
34. En lugar de "Estás en problemas", deberías decir "Tienes potencial para crecer".
35. ¡Deja de jugar con la ajenda!

Maxim Dorofeev - Jefe de desarrollo de Kaspersky Lab (en el momento de la entrevista - aprox. Smartia), un irónico profesional al que le encanta compartir conocimientos y experiencias. Hablamos de la gestión de proyectos de desarrollo software: libros útiles, teorías cuánticas y los beneficios del juego Starcraft en entrevistas a programadores.

- ¿Cómo fue que empezaste a gestionar proyectos?

Hace 19 años, me encontré con un libro de Peter Abel "Programación en lenguaje ensamblador". Tenía 12 años. Aprendí los sistemas binario y hexadecimal (asustando así a la maestra de matemáticas), y luego fui al club de computación de los niños. Me pusieron detrás de un viejo Comodoro y me dijeron: ¡programa! Sin cursos, sin formación. Me senté y comencé a programar.

Espiando a los chicos, inventando acertijos para sí mismo. Luego escribió el primer juguete en Pascal.

Un par de años después, el amigo de mi padre preguntó si era posible hacer informes para su empresa compilados por una computadora. Pensé: ¡Dios mío! Lo tomé y lo hice. Sufrí durante unos seis meses, gané hasta $ 500, me compré una computadora XT. Así empezó todo.

- Y te convertiste en programador.

Si. Fue genial: tomas una computadora y la haces hacer lo que quieres. Pero uno era difícil. Entonces comencé a pensar en cómo hacer algo con una computadora, pero ¿más rápido y más? Esto claramente necesitaba un equipo.

Luego me gradué de la escuela secundaria, ingresé a la Universidad Estatal de Moscú y pronto me encontré en una empresa que se ocupaba del software integrado para aviación Civil. Y a los 23 años volvió la idea del equipo: quería tener manos y cerebro extra, para programar no solo, calladamente cerrado, sino con un montón de gente. Fui a la librería pensando: "Dirigir un equipo se llama gestión; ve a la estantería con libros sobre gestión y toma algo de allí".

Tuve mucha suerte: encontré el libro de Peter Drucker The Practice of Management. Encontrar buen libro sobre este tema es muy difícil - y ese libro era bueno. Lo leí, luego un libro de Harrington Emerson "12 Principios de la Productividad"(¡1909!) y comenzó, como me pareció entonces, a comprender el tema. De repente se hizo evidente que mi gerente estaba cometiendo errores.

Empecé a decirle: amigo, lo estás haciendo mal, cortemos esta tarea ahora, hazlo en mi opinión, luego lo configuraremos antes y tendremos tiempo para hacer otra cosa. En general, comenzó a enseñarle la vida.

Tuve suerte de nuevo. Un jefe joven y caliente diría: "Fuera de aquí, programador joven y estúpido, el jefe sabe mejor". Actuó de manera más inteligente: dio instrucciones para liderar el proyecto. Me llené de alegría, pero, al tomar el control, rápidamente comencé a comprender de dónde crecían las piernas de las decisiones equivocadas; muchas de ellas me parecían equivocadas, porque no sabía toda la verdad.

Solía ​​creer que para convertirse en gerente basta con dibujar salchichas en un diagrama de Gantt en MS Project. Dibujé todas las salchichas, pero después de una semana ninguna coincidía con la realidad. Dije: "¡Maldita sea!" y dibujó otras salchichas. Una semana después, no volvió a pasar nada. Entonces me di cuenta de que no entendía nada y comencé a leer libros, muchos libros, tratando de averiguar cuál era el problema. En la Facultad de Física de la Universidad Estatal de Moscú, siempre nos enseñaron: "Si algo no funciona, no inventes nada, todo se ha inventado antes que tú, lee muchos libros".

Otra regla: si inventaste algo, te parece correcto, mira si alguien más lo inventó antes que tú. Si nadie lo inventó, o te equivocaste o te quedó mal.

El mayor fastidio fue en la escuela de posgrado, cuando comencé a escribir una disertación sobre la formación de flujos hidrodinámicos cerca de cuerpos oscilantes, inventé una fórmula, inventé un modelo y luego descubrí accidentalmente que 60 años antes de mi nacimiento, alguien ya me había robado esta idea. yo. Fué embarazoso.

Habiendo encontrado al predecesor, ¿puede ver de inmediato lo que alcanzó al final, para no recorrer todo el camino él mismo?

Si. Esto dejó una huella en mis habilidades de programación. Como gerente, realizo una "terapia de código" con regularidad. Tengo un par de proyectos que programo, solo para entender lo que están haciendo mis muchachos, para hablar el mismo idioma con ellos.

Mi concepto de desarrollo es “todo ya está escrito antes que nosotros”. ¿Qué significa esto? En este momento, por ejemplo, estoy desarrollando un pequeño servicio genial que recuerda mi programa de entrenamiento y calcula el perfil de los músculos involucrados. Entonces: probablemente haya cinco pantallas mías allí. Cuando, por ejemplo, se requiere un componente de arrastrar y soltar, no empiezo a escribirlo yo mismo, sino que pienso: "¿dónde más podría usarse?" Y, por ejemplo, en el tablero de gestión de tareas o en alguna herramienta de gestión. Voy a SourceForge, a Codeplex, y de hecho encuentro una docena de tales proyectos. Ocho de ellos no encajan en el idioma, la plataforma, y ​​uno o dos son bastante adecuados. Cuidadosamente elimino una parte de la funcionalidad y la uso si la licencia lo permite.

- ¿Adónde fuiste a trabajar después de la aviación?

Al principio hubo caos, el primer mes parecía que todo era impredecible y no estaba claro qué haría mañana. Pero David Allen me ayudó a organizar todo el trabajo. Y la jornada laboral ya va más o menos fluida: llegas a trabajar, miras lo que querías hacer hoy, te subes a la lista de tareas. Esto, por cierto, también es útil para los programadores. Primero, está en la lista de tareas y no en el correo. Porque había algo en tu lista de pendientes que ayer considerabas importante hacer hoy.

Si ingresa al correo, las nuevas tareas en el correo no le permitirán terminar lo que estaba planeado ayer.

- Lo que otros piensan es importante.

Si. Por supuesto, también puedes considerarlo importante. Pero si aún no se han completado todas las tareas de la lista, ¿por qué buscar tareas adicionales? Toyota me enseñó esto, su sistema de producción "pull". Enviamos un trabajo a una nueva etapa si y solo si los siguientes en el flujo han terminado el trabajo anterior. Asumo nuevas tareas cuando estoy listo para tomarlas. Hay excepciones, pero muy raras: algunas cagadas grandiosas que no suceden tan a menudo como mucha gente piensa.

De los rituales regulares, hay, por ejemplo, un "bypass de las posesiones". Revisa tus comandos, pregunta a los chicos cómo estás, qué ha cambiado desde ayer. Ayer podían quejarse de que tenían algún tipo de problema, hoy necesitan decir qué ha cambiado, qué hice, curé o no curé su problema. Los problemas son diferentes, pero básicamente el gerente tiene que lidiar con la vida cotidiana: la segunda copia del contrato de trabajo, firmar una solicitud de vacaciones, recuperar la memoria en la computadora, ayudar a coordinar con otro equipo.

¿Cómo es mi lista? Depende de qué tema principal hayamos elegido en el equipo de gestión ahora.

V este momento Implementamos la gestión de proyectos según el método de la teoría de las restricciones. Y la llamada encuesta consume mucho tiempo todos los días: debe ayudar al gerente del proyecto de implementación a entrevistar a los empleados, obtener la información necesaria y contar su visión.

Si hace la misma pregunta a 5 personas diferentes en la empresa, obtenemos 5 respuestas diferentes, yo mismo doy la sexta: todas están equivocadas. Pero cuantas más de estas opciones, más fácil es más tarde, habiendo recibido el panorama general, encontrar dónde está la verdad.

Entrevistas de Counter Strike

Hay actividad permanente: entrevistar a nuevos chicos. Estamos creciendo, constantemente estamos tomando a alguien, y también sigo esto. Ayudo a las chicas de recursos humanos, y a mí me gusta mirar a las personas, elegir, preguntar. preguntas capciosas y escuchar respuestas engañosas.

Puedes aprender mucho sobre programación en entrevistas con desarrolladores. De vuelta en Auriga, con experiencia en aviones, sin ninguna experiencia en .Net, asistí a las entrevistas para los programadores de .Net y un mes después ya podía ayudar a los muchachos del equipo a corregir errores.

- ¿Cómo aprender a elegir personas? ¿Solo experiencia?

No sé, estoy usando el sentido del culo.

- Es decir, ¿intuición generada por la experiencia?

Las habilidades técnicas para un programador no son lo principal. Lo principal es si encajará o no en el equipo. Si no sabe algo, los chicos le enseñarán.

Sensación de culo. Te sientas y miras a una persona: lo ves en un equipo o no lo ves. Y decidí por mí mismo, descubrí, después de haber rellenado un par de conos, que las habilidades técnicas para un programador todavía no son lo principal. Lo principal es si encajará o no en el equipo. Si no sabe algo, los chicos le enseñarán. Si se hace amigo de ellos, todo estará bien. Pero lo principal aquí es no exagerar. En un momento, en la compañía de aviones, tomamos a un hombrecito: amable, maravilloso, pero gracias a él, la mitad del equipo comenzó a jugar Starcraft durante medio día. Esto, por supuesto, es interesante: la socialización y todo eso, pero a veces también necesitas trabajar.

Sobre los juegos, sin embargo, tengo una teoría: cómo juega una persona, así trabaja; de acuerdo con la técnica de jugar Counter Strike, Quake o Starcraft, puede comprender si una persona está lista para unirse al equipo o no.

- Juego de equipo.

Si. Si un hombrecito en "Contra" toma el "elefante", se esconde en la esquina e intenta dispararle al enemigo en la parte posterior de la cabeza, no es nuestro luchador. Si nunca ha jugado antes, pero se lanza valientemente a la batalla con una pistola, recibe una bala en la frente, muere primero, en la siguiente ronda toma la pistola, corre hacia adelante, recibe una bala en la frente, muere primero y así sucesivamente. cinco veces: puede hacer algo y luego cuesta. Y en Starcraft hay una estrategia: construir en tu base, aislarte del mundo exterior y construir silenciosamente un crucero de batalla. Bueno, así es como trabaja la gente, se sientan frente a su computadora, se sumergen en su problema y, en Para no volver a preguntar, solo se llenan de problemas más fuertes. Y hay personas que enviarán los primeros 2 perros para ayudarlo, y esos tipos son muy valiosos. No aparecen a menudo, pero puedes verlos de inmediato.

Por lo tanto, probablemente sería bueno jugar en las entrevistas. Aunque nunca lo he hecho. Pero cuando recluté aquí a mis primeros programadores, la entrevista con mi fiel amigo se llevó a cabo de la siguiente manera: Traje una laptop conectada vía SSH a la consola de nuestro servidor web. Tomamos una misión de combate completa de nuestra lista, le dimos, sin mirar el resumen, la tarea y el acceso al servidor. Dijeron: aquí tienes una computadora, una tarea y nosotros, dos luchadores que pueden sugerir algo, y aquí hay un enlace a la documentación. Está claro que estamos simulando trabajo real, así que por el camino hablaremos, distraeremos, envenenamos bromas y tú trabajas.

Y esas dos personas que todavía están trabajando en mi equipo pasaron esta prueba.

Uno de los chicos se sorprendió por el hecho de que resolvió el problema en solo 10 minutos sin documentación. Fue simplemente impactante: un servidor web desconocido, no está claro cuándo y quién escribió el marco, ¡pero lo tomó y lo descubrió! Este hombre sigue deleitando.

Y otro personaje llegó a la entrevista con chaqueta de cuero, cuello, tachuelas, con el pelo negro hasta las rodillas. La apariencia engañaba, vimos que el tipo es inteligente. Y nuevamente, muchas gracias al "enfoque de la misión de combate"; sin él, se habrían reído de la apariencia.

Envenenamos historias, anécdotas, distraemos y observamos: si una persona está irritada, es una señal de peligro. Si no se molesta, pero también envenena algunas bromas, entonces esto es bueno, y si también hizo frente a la tarea, generalmente es excelente.

No le diré ahora cómo reclutar gerentes, aunque esta es la tarea que tengo ante mí. Ahora reclutaremos gerentes de proyecto. Cómo, no lo sé, y por ahora me centraré solo en la sensación de un imbécil y en la opinión de la persona que llevaré conmigo.

Cómo hacer amigos y números.

- Por lo general, los gerentes de proyecto pasan mucho tiempo en el rastreador de tareas. ¿Cuál es su relación con los rastreadores de tareas?

Los amo, los implemento! Los rastreadores de tareas muestran información objetiva según tu modelo de gestión: números. Los gerentes los quieren mucho, estos números. Como dicen, las personas deben ser respetadas, pero aún así confiar en los números y los hechos. Pero no me gusta el uso estúpido de ellos.

Muchos, muy a menudo, toman un rastreador de tareas, terminan el proceso en vano, complican el flujo de trabajo, dicen que si ha hecho algo, el resultado debe probarse y, después de la prueba, hacer algo nuevamente: escribir un informe, escribir fuera de horario, y asegúrese de que en ese orden, y no al revés.

De vuelta en la oficina de aviones, recuerdo, los muchachos y yo peleamos solo por interés deportivo, eliminando clics innecesarios de nuestro flujo de trabajo. Y ahí en todo ciclo vital tareas desde el momento de aparición hasta el momento de cierre hay 6 clics en todo el departamento de contabilidad.

A los gerentes novatos les encantan las hojas de tiempo: informes sobre cuántas horas ha trabajado una persona en qué tarea. Dicen: chicos, aquí hay un nuevo campo para ustedes en el rastreador de tareas, ahora todos escriban allí cuántas horas pasaron allí.

Fui iluminado por uno de mis muchachos, un desarrollador muy bueno y sabio. En algún momento de su informe semanal, vi la línea "Escribí un informe semanal: dos horas". Entendí, no, por tal precio no necesito esta información.

- ¿Pero esto también reduce la cantidad de números que finalmente recibe el gerente?

En realidad, no siempre. Se me ocurrió una forma alternativa de conseguirlos. Un buen rastreador de tareas recuerda cuándo se creó la tarea, cuándo el desarrollador dijo que comenzó a trabajar en ella, cuándo dijo que podía probarla y cuándo se cerró. Por supuesto, puedo abrir una tarea a las 9 pm, decir "lo hago mañana", ir a casa, hacerlo en 5 minutos mañana y cerrarlo. Como resultado, resulta que la tarea estuvo activa durante 13 horas. Pero esto solo complica la tarea, no la hace imposible.

Aquí hay otro mantra: necesitas ser capaz de separar lo que es imposible de lo que es difícil. Podemos estimar aproximadamente, tomar el tiempo de actividad de todas las tareas durante un mes, normalizarlo por el número total de horas que una persona estuvo en el lugar. Sabemos que hay 40 horas a la semana; Pongo 50 horas si veo que aran de verdad. Dividir uno por el otro - obtener un tiempo aproximado.

Y lo que ingresan a mano son en realidad números aleatorios. Yo mismo me imagino cómo se hace esto, ya que yo era desarrollador. Te sientas al final de la semana y empujas el 54 para que el total sea 40.

Y cuando, por ejemplo, quieras que los programadores no tomen tareas antes de irse, ¿les mandarás o les preguntarás sobre esto?

Si realmente necesito datos más precisos, vendré, preguntaré, diré: “Chicos, miren, en lugar de escribir hojas de tiempo, tengo una supermáquina que hice con mis torpes manitas de gerente, ella calcula las hojas de tiempo ella misma, ayúdala, por favor.”

Hasta hace poco, Maxim Dorofeev era un ingeniero genial, jefe del departamento de desarrollo en el departamento de TI de Kaspersky Lab, y se reía en la cara de cualquiera que dijera que pronto se convertiría en un consultor de efectividad personal.

Hoy Maxim aconseja a las primeras personas grandes compañias. Su sistema de gestión de combustible de pensamiento es cada vez más recomendado entre sí por expertos bombeados, por ejemplo, también nos lo recomendó a nosotros. O Tina Kandelaki, por cierto. En general, la gloria se deslizó hasta Maxim imperceptiblemente.

Tres personajes viven en nuestra cabeza

La persona responsable de la toma racional de decisiones., con él todo está claro por nombre, siempre trata de ser lógico y racional, piensa que hará todo según lo planeado.

Mono de placer momentáneo ahora solo piensa en divertirse. Para ella, lo más importante es no hacer nada complicado. Come cuando quieras comer, duerme cuando quieras dormir, siéntate en FB cuando quieras sentarte en FB. Es decir, siempre.

Y monstruo de pánico es el miedo a una fecha límite, el miedo a perder la cara debido a una tarea incumplida, solo él puede alejar al mono del timón y devolver el control al hombrecito racional.

Un hombrecito racional trata de controlar el proceso, pero no lo logra bien, porque el mono saca el volante todo el tiempo. Y solo un monstruo de pánico puede asustar a este mono. Este es el tipo de zoo que pasa por nuestra cabeza cuando nos sentamos, por ejemplo, en Facebook, en lugar de preparar un informe importante.

“En general, ¿por qué fui hacia el mono en mi técnica Jedi? De un simple enunciado, que es el presupuesto de todo en lo que me baso. Yace en el hecho de que la mayoría de las veces la mayoría de las personas son impulsivas, ilógicas, irracionales y al mismo tiempo consideran anormal tal comportamiento. Piensan para sí mismos: "Otra vez actué ilógicamente, pero todos los demás son normales, lógicos, tienen suerte, pero yo soy una especie de tonto en general". Pero no lo es.

Por ejemplo, puedo elegir una tarifa para un teléfono móvil para ahorrarme 50 o 100 rublos al mes y, al mismo tiempo, realizar un proyecto cienmilésimo. ¿Y quién puede decir que nada de esto le sucede a él?

Eso es lo que somos. Y no podemos hacer nada al respecto, solo podemos adaptarnos. No nos convertiremos en personas 100% racionales. Tenemos un hombre racional al timón no es tanto tiempo. En su mayor parte, este mono nos controla”.

pensamientos clave

• Por qué David Allen ya no funciona y por qué necesita hacer una lista de tareas pendientes, no varias.
• Cómo despejar completamente tu cabeza con 31 factores desencadenantes.

• Qué preguntas necesitas hacerte para salir del callejón sin salida y encontrar una idea rompedora para tu proyecto o negocio.

• Cuáles son las 20 preguntas que debes hacerte todos los días y todas las semanas para que todo esté en orden.

Realice el seminario web de Maxim Dorofeev, que lo ayudará a dominar la técnica de la bandeja de entrada vacía en 2 horas

Y hemos preparado para usted un seminario web gratuito de Maxim Dorofeev, que lo ayudará a dominar la técnica de la bandeja de entrada vacía. Recoja, descargue e implemente en 72 horas.

¡Sí, escucha!

Nombres y títulos mencionados en el podcast

• Tim Urban, blog Waitbutwhy. ¿Por qué siempre llego tarde?

Libros

El libro "18 minutos. Cómo aumentar el enfoque, detener las distracciones y obtener las cosas realmente importantes por Peter Bregman - Compre 18 minutos: encuentre su enfoque, domine la distracción y obtenga las cosas correctas en OZON.ru con envío rápido | 978-5-91657-893-5

¿Qué es un podcast y por qué necesitas uno? Un podcast es una grabación de audio. Puedes escucharlo desde la pagina "Websarafan", puedes descargarlo y escucharlo en el carro \ en casa \ en el metro desde tu iPhone o tablet. En cada episodio del podcast, hablo con la gente sobre dos temas: cómo los empresarios geniales promueven su negocio y cómo viven y trabajan (para tener la energía, el tiempo y el deseo de hacer su trabajo).

¿Cómo usar el podcast?

1) Puede escuchar aquí mismo en el navegador haciendo clic en el botón de reproducción.

2) ¿Quieres escuchar en iPhone? Se puede hacer aquí. En la misma página, puede suscribirse a nuestro podcast, y recibirá notificaciones en su iPhone tan pronto como se agregue un nuevo episodio.

3) Si desea descargar el podcast, puede hacerlo
4) Si te gustó el podcast, deja una reseña aquí. Esto elevará nuestro podcast más alto en las clasificaciones y brindará a más personas la oportunidad de escucharlo.

5) Si no desea escuchar el podcast, puede leer el texto completo a continuación.

Y aquí está, un seminario web gratuito de Maxim Dorofeev, que lo ayudará a dominar la técnica de la bandeja de entrada vacía. Recoja, descargue e implemente en 72 horas.

Leer el texto completo del podcast