Сходил на лекцию и тренинг Максима Дорофеева про организацию дел. Максим рассказывал про иррациональность в работе, о правильном формулировании задачи, работе с электронной почтой.

Я много читал про Максима и его джедайскую технику пустого инбокса, и вот сходил на семинар. Семинар было обо всём сразу, но получилось интересно. Во-многом это из-за образцовой организации лекции: слайды, стиль, шутки, практика — всё это было идеально. Я много хожу на лекции и конференции, но впервые получил такое удовольствие от организации. Сходить на тренинг стоило просто ради этого чувства.

Вёл конспект семинара, публикую его. Предупреждаю, что это просто конспект для себя, а не подробный пересказ.

1. Правила не гарантируют нам результата, а могут только влиять на его вероятность.
2. Большинство из нас очень хорошо знают, как мы должны себя вести. Проблема - не отсутствие знания, а выполнение.
3. У нас в голове есть идеал аристотелевского человека: каждое действие человека имеет причину, направлено на результат. Но самом деле большую часть времени большинство мы иррациональны, импульсивны, действуем на автомате (переоцениваем свой уровень осознанности). Но мы не считаем такое поведение нормой.
4. Думать - больно.
5. Мы все работаем над срочными делами. Ну а зачем работать над несрочными делами, пока они не станут срочными?
6. У ответственного человека пендель приходит изнутри, у безответственного - от руководства.
7. Оценивая задачу, мы часто накидываем буфер «на всякий случай». Надо сделать через два дня, оцениваем срок в неделю. Но мы такую задачу считаем несрочной. Дата завершения задачи превращается в дату, раньше которой ничего не происходит.
8. Когда человеку даешь задачу за задачей, он решает их легко в отведенное время. Даёшь их все сразу - она начинает придумывать планирование и часть не успевает.
9. Словосочетание «расставить приоритеты» звучит как «составить список моих единственных жоп». Когда люди расставляют приоритеты, они выбирают между важным и срочным. Но на самом деле выбирают понятное.
10. Память работает криво: краткосрочная мешает думать, в долговременную плохо записать.
11. У человеческой памяти нет гарантии подлинности. Есть психологический эксперимент, когда людям показывали их отфотошопленные детские фотографии. Уже на третьем интервью люди в деталях вспоминают события, в которых они не участвовали.
12. Чтобы делать больше, нужно экономить мыслетопливо. Для этого нужно минимизировать «повторные мысли» - правильно формулировать задачи. Нужно разгрузить рабочую память - перенести все данные в компьютер. Еще нужно уменьшать внешние переключения.
13. Кому слабо приехать в Икею за батарейками и купить батарейки?
14. Есть даже приложение для смартфона для медитации. Люди три тысячи лет как-то обходились без этого.
15. Если хотите сэкономить на работе с почтой, обрабатывайте письма пачкой.
16. Обработать письмо - значит выделить из него смысловые части, расщепить. После прочтения у вас должны быть задачи, встречи, новая информация.
17. Нет правильных и неправильных людей. Есть люди, чья картина мира отличается от вашей.
18. Правильная формулировка задачи - словно вы рассказываете последовательность действий не очень умной служанке. Только эта служанка - это вы сам.
19. Хорошая задача отвечает на вопрос «Что надо сделать?». Важно не выпендриваться, а написать просто. Не «Разобраться с годовым отчётом», а «Добавить таблицу на последний слайд».
20. «Построить дом» — это не задача, а проект. В проекте «Построить дом» куча задач: «Позвонить в банк», «Позвонить в строительную компанию».
21. Хорошая задача содержит глагол в начальной форме, сказуемое.
22. Хорошая задача звучит так, что вы в любой момент времени можете схватить её и делать.
23. Формулировка хорошей задачи совпадает с первым шагом, которым нужно сделать для её выполнения.
24. Полезная задача: «Потупить 15 минут на тему». Речь о том, чтобы просто подумать о задаче, не хватаясь сразу за её выполнение.
25. Сроки должны быть у проектов, у задач сроков нет.
26. Если не хочется делать задачу, полезно подумать о том что будет, если её не делать. Иногда станет понятно, что можно и не делать. Иногда захочется взять и сделать.
27. Если к вам приходят люди и отвлекают, и такое случается регулярно — договоритесь о регулярных встречах. Пускай человек копит идеи и приносит их списком.
28. Не нужно путать многозадачность и многопроектность. Читать пять книг одновременно тяжело, это многозадачность. А читать книгу, заряжать телефон и строить дом — можно.
29. Метод маленькой волшебной феи. Берёте задачу, смотрите на неё и думаете: а что бы я сделал, если бы прилетела фея и дала мне только 20 минут на выполнение этой задачи?
30. Генерация идей и их оценка — это два разных процесса.
31. В компаниях бывает календарное домогательство: люди сами бронируют время на встречи в календаре других людей. Полезно забивать себе самому время на работу.
32. Всесторонняя оценка проекта описывается вопросами: Что? Что еще? Что бы что? Кому и для чего? А как еще?
33. Часто, выбирая между «Сделать хорошо» и и «Сделать плохо», мы на самом деле можем только влиять на момент, когда работа будет сделана через жопу. Огромный пласт проектов нельзя сразу делать хорошо.
34. Вместо «Вы в жопе» надо говорить «У вас есть потенциал для роста».
35. Хватит теребить адженду!

Еще недавно Максим Дорофеев был крутым инженером, руководил отделом разработки в IT-департаменте в «Лаборатории Касперского» и рассмеялся бы в лицо любому, кто сказал бы, что скоро он станет консультантом по личной эффективности.

Сегодня Максим консультирует первые лица крупных компаний. Его систему управления мыслетопливом все чаще рекомендуют друг другу прокачанные эксперты, нам вот, например, тоже порекомендовал. Или Тина Канделаки, к слову. В общем, слава подкралась к Максиму незаметно.

В нашей голове живет три персонажа

Человечек, ответственный за рациональное принятие решений , с ним все по названию понятно, он все время пытается быть логичным и рациональным, думает, что будет все делать по плану.

Обезьянка сиюминутого удовольствия думает только о том, чтобы получить удовольствие прямо сейчас. Для нее самое главное не делать ничего сложного. Есть, когда хочется есть, спать, когда хочется спать, сидеть в ФБ, когда хочется сидеть в ФБ. То есть всегда.

И панический монстр — это страх перед дедлайном, страх потерять лицо из-за невыполненной задачи, только он может отогнать обезьянку от руля и вернуть управление рациональному человечку.

Рациональный человечек пытается управлять процессом, но у него это плохо получается, потому что обезьянка все время вырывает руль. И напугать эту обезьянку может только панический монстр. Вот такой зоопарк творится у нас в голове, когда мы сидим, например, в фейсбуке, вместо того чтобы готовить важный отчет.

«Вообще с чего я пошел в сторону обезьянки в своей джедайской технике? С одного простого утверждения, которое является пресуппозицией вообще всего, на чем я основываюсь. Оно заключается в том, что большую часть времени большая часть людей импульсивны, нелогичны, иррациональны и при этом считают такое поведение ненормальным. Думают про себя: «Я вот опять нелогично поступил, но все остальные нормальные, логичные, везет же им, а я какой-то дурак вообще». Но это не так.

Я, например, могу сидеть выбирать тариф на мобилу, чтобы сэкономить себе 50 или 100 рублей в месяц и при этом продалбывать стотысячный проект. И кто может сказать, что с ним ничего подобного не бывает?

Вот такие мы. И мы ничего с этим поделать не можем, мы можем к этому только приспособиться. Мы не станем на 100% рациональными людьми. У нас рациональный человечек у руля находится не так много времени. По большей части нами управляет эта обезьянка».

Ключевые мысли

• Почему Дэвид Аллен больше не работает и нужно составлять один список дел, а не несколько.
• Как полностью очистить свою голову с помощью 31 спускового крючка.

• Какие вопросы нужно задать себе, чтобы выйти из тупика и найти прорывную идею для вашего проекта или бизнеса.

• Что за 20 вопросов нужно задавать себе каждый день и каждую неделю, чтобы в делах был полный порядок.

Забирайте вебинар Максима Дорофеева, который поможет вам освоить технику пустого инбокса за 2 часа

А мы приготовили для вас бесплатный вебинар Максима Дорофеева, который поможет вам освоить технику пустого инбокса. Забирайте, скачивайте и внедряйте в течение 72 часов.

Ииии слушайте!

Имена и названия, упомянутые в подкасте

• Тим Урбан, блог Waitbutwhy. Почему я всегда опаздываю

Книги

Книга «18 минут. Как повысить концентрацию, перестать отвлекаться и сделать действительно важные дела» Питер Брегман — купить на OZON.ru книгу 18 Minutes: Find Your Focus, Master Distractoin, and Get the Right Things Gone с быстрой доставкой | 978-5-91657-893-5

Что такое подкаст и зачем он вам нужен? Подкаст - это аудиозапись. Ее можно слушать со страницы «Вебсарафана», можно скачать и слушать в машине\дома\в метро с iPhone или планшета. В каждом эпизоде подкаста я разговариваю с людьми на две темы: как клевые предприниматели продвигают свой бизнес, и как они живут и работают (чтобы иметь энергию, время и желание заниматься своим делом).

Как пользоваться подкастом?

1) Вы можете слушать прямо здесь, в браузере, нажав на кнопку play.

2) Хотите слушать на iPhone? Это можно сделать вот . На этой же странице можно подписаться на наш подкаст - и вы будете получать нотификации на ваш iPhone, как только будет добавлен новый эпизод.

3) Если вы хотите скачать подкаст, вы можете сделать это
4) Если вам понравился подкаст, оставьте, пожалуйста, на него отзыв вот . Это поднимет наш подкаст выше в рейтинге и даст возможность прослушать его большему количеству людей.

5) Если не хотите слушать подкаст, полный текст можете прочитать ниже.

И вот он, бесплатный вебинар Максима Дорофеева, который поможет вам освоить технику пустого инбокса. Забирайте, скачивайте и внедряйте в течение 72 часов.

Полный текст подкаста читайте

Понравилась статья? Поделись с друзьями!

Максим Дорофеев - руководитель отдела разработки в Лаборатории Касперского (на момент взятия интервью - прим. Смартии) , ироничный профессионал, обожающий делиться знаниями и опытом. Мы обсудили управление проектами по разработке программного обеспечения: полезные книги, квантовые теории и пользу игры Starcraft на собеседованиях программистов.

- Как вышло, что ты начал управлять проектами?

19 лет назад мне попалась книжка Питера Абеля «Программирование на языке Ассемблера» . Мне было 12. Я выучил двоичную и шестнадцатеричную системы исчисления (чем эпатировал учительницу по математике), а потом пошёл в детский компьютерный клуб. Меня посадили за старый Commodore и сказали: программируй! Ни курсов, ни обучения. Я сел и начал программировать.

Подглядывал за ребятами, выдумывал себе задачки. Потом написал на Паскале первую игрушку.

Через пару лет папин знакомый спросил, можно ли сделать так, чтобы отчеты для его фирмы составлял компьютер? Я подумал: фигли! Взял и сделал. Помучался где-то полгода, заработал целых 500 долларов, купил себе компьютер XT. Так всё и началось.

- И ты стал программистом.

Да. Это было здорово: берёшь компьютер и заставляешь его делать то, что хочется. Но одному было тяжело. Поэтому я начал задумываться о том, как бы делать что-то при помощи компьютера, но быстрее и больше? Для этого явно нужна была команда.

Потом я окончил школу, поступил в МГУ и вскоре оказался в компании, занимавшейся бортовым ПО для гражданской авиации. И в 23 года мысль про команду вернулась: захотелось иметь дополнительные руки и мозги, программировать не в одиночку, тихо замкнувшись, а кучкой людей. Я пошел в книжный магазин, думая: «Управление командой называется менеджмент - идём к полке с книжками про менеджмент и берём что-нибудь оттуда».

Мне очень повезло: в руки попалась книжка Питера Друкера «Практика менеджмента» . Найти хорошую книгу по этой теме очень тяжело - и та книга была хорошая. Я прочитал её, затем книжку Гаррингтона Эмерсона «12 принципов производительности» (1909 года!) и начал, как мне тогда казалось, разбираться в теме. Вдруг стало очевидным, что мой руководитель совершает ошибки.

Я начал ему говорить: чувак, ты делаешь не так, давай мы сейчас эту задачу распилим, сделаем по-моему, тогда мы её поставим раньше и успеем сделать ещё что-нибудь. В общем, начал его учить жизни.

Мне снова повезло. Молодой и горячий начальник сказал бы: «Иди отсюда, молодой и глупый программист, начальнику виднее». Тот поступил умнее: поручил вести проект. Я был вне себя от радости, но, взявшись за управление, быстро начал понимать, откуда росли ноги у неправильных решений - многие из них казались мне неправильными, потому что я не знал всей правды целиком.

Раньше я верил: чтобы стать менеджером, достаточно нарисовать колбаски на диаграмме Ганта в MS Project. Я нарисовал все колбаски, но через неделю ни одна из них не совпала с реальностью. Я сказал: «Чёрт!» и нарисовал другие колбаски. Через неделю опять ничего не совпало. Тогда я понял, что ничего не понимаю, и начал читать книжки, много книжек, пытаясь разобраться, в чём дело. На физфаке МГУ нас всегда учили: «Если что-то не получается, не изобретайте ничего, всё изобретено до вас, читайте много книжек».

Еще одно правило: если ты чего-то выдумал, тебе это кажется правильным, посмотри, не выдумал ли кто-то это до тебя. Если никто не выдумал, то ты либо ошибся, либо плохо искал.

Самый большой облом был в аспирантуре, когда я начал писать диссертацию про образование гидродинамических потоков вблизи колеблющихся тел, выдумал формулу, выдумал модель, а потом случайно обнаружил, что лет за 60 до моего рождения кто-то у меня эту идею уже украл. Было обидно.

Найдя предшественника, можно сразу посмотреть, до чего он дошел в конце, чтобы не проходить весь путь самому?

Да. Это оставило отпечаток и на моих программистских навыках. Будучи менеджером, я регулярно прохожу «кодотерапию». У меня есть пара проектиков, которые я программирую - просто для того, чтобы понимать, что делают мои ребята, чтобы говорить с ними на одном языке.

Моя концепция разработки – «всё уже написано до нас». Что это означает? Сейчас, например, я разрабатываю маленький прикольный сервис, который помнит мою программу тренировок и рассчитывает профиль задействованных мышц . Так вот: моих там, наверное, экранов пять кода. Когда требуется, например, drag’n’drop-компонент, я не начинаю его писать сам, а думаю: «где бы он мог еще использоваться?» А, например, в доске управления задачами или в каком-нибудь менеджерском инструменте. Иду на SourceForge, на Codeplex, и действительно нахожу десяток таких проектов. Восемь из них не подходят по языку, по платформе, а один-два вполне годятся. Аккуратно вырезаю кусочек функционала и использую, если лицензия позволяет.

- Куда ты пошел работать после авиации?

Поначалу был хаос, первый месяц казалось, что всё непредсказуемо и непонятно, что я буду делать завтра. Но Дэвид Аллен помог мне систематизировать всю работу. И рабочий день уже более-менее ложится в струю: приходишь на работу, смотришь, что ты хотел сделать сегодня, лезешь в список задач. Это, кстати, и для программистов полезно. Сначала именно в список задач, а не в почту. Потому что в списке задач было нечто, что ты вчера считал важным сделать именно сегодня.

Если полезешь в почту, то новые задачи в почте не дадут доделать запланированное со вчерашнего дня.

- То, что считают важным другие.

Да. Ты, конечно, тоже можешь считать это важным. Но если ещё не все задачи завершены из списка, зачем лезть за дополнительными задачами? Этому меня научила «Тойота», её «вытягивающая» система производства. Мы посылаем кусок работы на новый этап тогда и только тогда, когда следующие по потоку закончили предыдущую работу. Я беру новые задачки тогда, когда я готов их взять. Бывают исключения, но очень редкие – какие-то грандиозные факапы, которые происходят не так часто, как многим кажется.

Из регулярных ритуалов есть, например, «обход владений». Пройти по своим командам, спросить у ребят, как дела, что поменялось со вчерашнего дня. Вчера они могли пожаловаться, что у них возникла какая-нибудь проблема, тогда сегодня нужно рассказать, что изменилось, что я сделал, вылечил или не вылечил их беду. Беды бывают разные, но в основном руководителю приходится сталкиваться с бытовухой – второй экземпляр договора о работе, подписать заявление на отпуск, доковырять памяти в компьютер, помочь скоординироваться с другой командой.

Как выглядит мой список? Это зависит от того, какая основная тема у нас сейчас выбрана в команде управленцев.

В данный момент мы внедряем управление проектами по методу теории ограничений. И достаточно много времени каждый день отъедает так называемое обследование – надо помочь менеджеру проекта внедрения опросить сотрудников, получить нужную информацию, рассказать свое видение.

Если задать один и тот же вопрос 5 разным человекам в компании, получим 5 разных ответов, я сам даю шестой – все они неверные. Но чем больше этих вариантов, тем проще потом уже, получив общую картину, найти, где на самом деле правда.

Counter Strike на собеседованиях

Есть перманентная активность - собеседование новых ребят. Мы растём, постоянно кого-то берём, и за этим тоже я слежу. Помогаю девочкам из HR, да и самому нравится смотреть на людей, выбирать, задавать каверзные вопросы и слышать каверзные ответы.

На собеседованиях с разработчиками можно узнать многое о программировании. Ещё в «Ауриге», с самолётным прошлым, не имея никакого бэкграунда в.Net, я сидел на собеседованиях.Net-программистов и через месяц уже сам мог ребятам в команде помогать править багло.

- Как научиться выбирать людей? Только опытом?

Не знаю, я использую чувство жопы.

- То есть интуицию, порожденную опытом?

Технические навыки для программиста это не главное. Главное – впишется он в команду или нет. Если он чего-то не знает, парни научат.

Чувство жопы. Сидишь и смотришь на человека: видишь ты его в команде или не видишь. И я для себя сам решил – обнаружил, набив пару шишек – технические навыки для программиста это всё-таки не главное. Главное – впишется он в команду или нет. Если он чего-то не знает, парни научат. Если он с ними подружится, всё будет замечательно. Но и тут главное не перестараться. В свое время ещё в самолётной компании мы взяли человечка – дружелюбный, замечательный, но из-за него полкоманды стало играть в Starcraft по полдня. Это, конечно, интересно - социализация и все такое, но работать тоже иногда нужно.

Про игры, впрочем, у меня есть теория: как человек играет, так он и работает; по технике игры в Counter Strike, Quake или Starcraft можно понять, готов человек войти в команду, или нет.

- Командная игра.

Да. Если человечек в «Контре» берет «слона», шкерится в углу и пытается застрелить врага в затылок – он не наш боец. Если он до этого ни разу не играл, но смело с пистолетом рвется в бой, получает пулю в лоб, умирает первым, в следующий раунд беред пистолет, бежит вперед, получает пулю в лоб, умирает первым и так пять раз – он может чего-то стоить. И в Starcraft есть стратегия - застроиться на своей базе, закрыться вообще от внешнего мира и тихо строить battlecruiser – ну, вот люди так и работают, они садятся за свой комп, погружаются в свою проблему и, чтобы лишний раз не спрашивать, обрастают проблемами только сильнее. А бывают люди, которые первые 2 собачки пошлют тебе на помощь, и такие ребята очень ценны. Они попадаются не часто, но их сразу видно.

Поэтому, наверное, на собеседованиях было бы неплохо играть. Хотя я этого никогда не делал. Но когда здесь я набирал себе первых программистов, то собеседование вдвоём с моим верным товарищем проводили так: я приносил ноутбук, подключенный по SSH к консоли нашего вебсервера. Мы брали вполне боевую задачу из нашего списка, давали, не глядя на резюме, задачу и доступ к серверу. Говорили: вот у тебя компьютер, задача и мы, - два бойца, которые что-то могут подсказать, - и вот ссылочка на документацию. Понятно, что мы симулируем настоящую работу, поэтому попутно будем говорить, отвлекать, травить анекдоты, а ты работай.

И те два человека, которые до сих пор работают в моей команде, прошли этот тест.

Один из ребят удивил тем, что он решил задачу буквально за 10 минут без документации. Это просто потрясло: неизвестный веб-сервер, непонятно когда и кем написанный фреймворк, а он взял и разобрался! Этот человек до сих пор продолжает радовать.

И ещё один персонаж пришел на собеседование в косухе, ошейнике, заклепках, с черными волосами до колен. Внешность оказалась обманчива, мы увидели, что парень умный. И опять большое спасибо «подходу боевой задачи» - без него так бы и хохмили над внешним видом.

Мы травим байки, анекдоты, отвлекаем и смотрим: если человек раздражается - это сигнал опасности. Если не раздражается, а тоже какие-нибудь анекдоты травит, то это хорошо, а если еще и с задачей справился – вообще отлично.

Как набирать менеджеров, я сейчас не скажу, хотя передо мной стоит именно такая задача. Мы сейчас будем набирать именно менеджеров проектов. Как – не знаю и пока буду ориентироваться только на чувство жопы и на мнение человека, которого возьму с собой.

Как подружить людей и цифры

- Обычно менеджеры проектов много времени проводят в таск-трекере. Какие у тебя отношения с таск-трекерами?

Я люблю их, я их внедряю! Таск-трекеры показывают объективную информацию согласно твоей модели управления: циферки. Менеджеры их любят очень, эти циферки. Как говорится, людей надо уважать, а доверять все-таки цифрам и фактам. Но не люблю бестолкового их использования.

Многие - очень часто встречал - берут таск-трекер, зря наворачивают процесс, усложняют workflow, говорят, что если вы что-нибудь сделали, результат обязательно надо протестировать, а после тестирования опять что-нибудь сделать: написать отчет, списать часы, и обязательно в таком порядке, а не наоборот.

Еще в самолётной конторе, я помню, мы с ребятами просто из спортивного интереса боролись, вычищая лишние клики из нашего рабочего процесса. И там на всем жизненном цикле задачи от момента появления до момента закрытия осталось 6 кликов на всю бухгалтерию.

Начинающие менеджеры любят таймшиты: отчеты, сколько часов человек проработал над какой задачей. Они говорят: ребята, вот вам новое поле в таск-трекере, теперь все пишите туда, сколько вы часов туда потратили.

Меня просветил один из моих ребят, очень хороший и мудрый разработчик. В какой-то момент в его недельном отчете я увидел строчку «Писал недельный отчет: два часа». Я понял, нет, за такую цену мне эта информация не нужна.

- Но это же уменьшает количество циферок, которые в итоге получает менеджер?

На самом деле – не всегда. Я выдумал альтернативный способ их получения. Хороший таск-трекер помнит, в какой момент задача была создана, в какой момент разработчик сказал, что он начал над ней работать, когда он сказал, что можно тестировать, и когда она была закрыта. Конечно, я могу открыть задачу в 9 вечера, сказать «Я завтра её делаю», уйти домой, а завтра сделать за 5 минут и закрыть. В итоге получится, что задачка была активной 13 часов. Но это лишь усложняет задачу, а не делает ее невозможной.

Вот ещё одна мантра: нужно уметь отделять то, что невозможно, от того, что сложно. Мы можем грубо оценить, взять за месяц время активности всех задач, отнормировать его на общее число часов, которое человек был на месте. Мы знаем, что в неделю 40 часов; я ставлю 50 часов, если я вижу, что они реально впахивают. Поделим одно на другое - получим примерное время.

А то, что руками вводят - это на самом деле случайные числа. Я сам представляю, как это делается, поскольку был разработчиком. Ты в конце недели садишься и распихиваешь 54 числа, чтобы в сумме вышло 40.

А когда тебе, например, захочется, чтобы программисты не брали задачки перед уходом, ты им об этом скомандуешь или попросишь?

Если мне действительно нужны более точные данные, приду, попрошу, скажу: «Ребятки, смотрите, вместо того, чтобы писать таймшиты, у меня есть супермашинка, которую я своими корявыми манагерскими ручонками налабал, она считает таймшиты сама, помогите ей, пожалуйста».