×Закрыть

Мультитаскинг, или Как работать над несколькими проектами и не сойти с ума

[Материал опубликован в рамках конкурса статей на DOU]

Секрет того, чтобы добиться чего-то, — начать.
Секрет того, чтобы начать, заключается в том, чтобы разбить сложное и неподъемное задание на маленькие и простые задачки и приступить к решению первой из них.
Марк Твен

Данная статья будет интересна людям, работающим как на одном, так и на нескольких проектах одновременно, начиная с разработчиков и заканчивая менеджерами. В начале моей карьеры в IT мне повезло прийти не на один большой проект, а на протяжении длительного периода времени работать параллельно на 2-6 проектах. Я бы хотел рассказать о своем опыте, поделиться интересными примерами и опробованными на практике лайфхаками. Работаю я в QA-направлении, поэтому большинство примеров будет из кухни моей профессии.

Рано или поздно у каждого возникают ситуации, когда необходимо не просто работать, а и правильно организовать рабочий процесс. Человек, к сожалению или к счастью (это как посмотреть — привет Скайнет!), — не компьютер, и у него нет такого свойства, как многопоточность/мультитаскинг. При большом количестве задач мы делаем первую, потом вторую, потом третью и так далее. Многие, возможно, мнят себя великими мультитаскерами, как Гай Юлий Цезарь, о котором историки писали, что он мог одновременно читать, писать и слушать доклады, не прерывая при этом беседы со своим секретарем. Но современные исследователи сделали вывод: человеческий мозг может хорошо сфокусироваться только на одной задаче, и если в это время параллельно заниматься другой задачей, возрастает вероятность потерь в качестве работы и допущения ошибок.

Увы, мир не идеален и многие из нас рискуют быть погребенными под горой задач, которых нахватались, и сами не заметили как. Все начинается с нескольких тасков. Вы беретесь за первый, параллельно запускаете в работу второй. Третий, четвертый... Вот вас подключают на второй проект, на горизонте маячат дедлайны. Вы стараетесь все успеть, нервничаете, напоминаете самому себе артиста цирка с крутящимися тарелочками, который мечется между ними, пытаясь удержать все в равновесии. А тем временем силы истощаются и вы начинаете замечать первые признаки эмоционального выгорания. Закономерный вопрос — что делать? Как же отладить эту самую многопоточность и оставаться адекватным человеком? Читайте дальше.

Зачем все это нужно?

Сначала необходимо понять важные цели планирования/организации работы и с помощью различных инструментов к ним стремиться.

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

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

Недопущение одного из самых отрицательных результатов напряженного графика — профессионального выгорания. Не успеть сделать всю работу = плохо, успеть и сделать все некачественно = плохо, успеть и сделать все качественно, при этом получить истощение иммунитета и психологическую нестабильность = выгорание = плохо. Многое зависит от индивидуальности человека, как он справляется со стрессом, как отдыхает. Здесь поможет правильная приоритизация задач и способность переключаться между ними. Это позволяет достичь некой точки баланса в бушующем океане работы.

Где находятся подводные камни?

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

Разные проекты: команды, заказчики и задачи. В итоге приходится работать с большим количеством людей. Это может быть и один очень большой проект, где задачи разбиты по командам. Команды могут быть разбиты по разным странам и городам, а у ваших коллег может быть разный рабочий график. Я стараюсь работать с 09:00 до 18:00, но мне знакомы разработчики, работающие с 14:00 до 23:00. Потому важно учитывать рабочий график коллег, которые с вами на проекте. Если весь проект ведется в рамках одной компании, то считайте, что вам повезло. А если вы делаете только определенную часть, возможны непредвиденные ситуации. Пример № 1: клиент-серверное веб-приложение. Ваша компания делает только клиентскую часть, серверная часть у другой зарубежной компании. Я по натуре жаворонок и, придя утром на работу, сделав кофе, сажусь за проверку фикса багов и прогон чек-листа, а ничего не работает, из-за отвалившегося Backend-a. В итоге большая часть дня прошла за апдейтом документации во время ожидания восстановления работоспособности сервера. Пример № 2: тот же проект. Команда Backend-a без предупреждения меняет API... И поверьте, таких примеров сотни.

Различные предметные области. Среди ваших проектов одновременно могут быть web, мобильные (нативные/кроссплатформенные), десктопные приложения. Главное, не запутаться что, где и как у вас на разных проектах, например, утвержденные тестовые окружения в разрезе браузеров, девайсов и т. д. У меня как QA, в зависимости от проекта, свой индивидуальный подход к процессу тестирования. У разработчиков же часто возникают проблемы с имплементацией новых фич на новых технологиях, с которыми они не работали раньше. Знать все в нашей жизни невозможно. Чем больше разнообразных проектов у вас в работе, тем выше вероятность столкнуться с чем-то незнакомым. Никогда не надо бояться работать с чем-то новым, но обязательно учитывайте это в эстимейтах по своей работе, а также особенности и различия в разных технологиях.

Документация по проектам: ее наличие или отсутствие, а также разнообразные ее виды. Пример: вы пришли на проект и документация уже была, возможно, она устарела — значит надо актуализировать. На другом проекте ее нет — процесс создания на вас, в разрезе ваших функциональных обязанностей. На действующих проектах вы предоставляете отчеты о проделанной работе: на одном хотят табличку в Excel, на втором 10 страниц в Word. Если есть возможность унифицировать и упростить — делайте! Ваше начальство не согласно — аргументируйте свою точку зрения. Как-то раз мне рассказали байку про большой проект с регулярными отчетами, где их никто не читал. Узнайте, для чего и для кого эти отчеты, и в каком виде они будут эффективны. Это касается всей документации на проекте. Холивар о необходимости документации ради документации не будем затрагивать. Это уже совсем другая история.

Даты спринтов/релизов могут совпадать на разных проектах, также одновременно могут возникать проблемные ситуации. Сроки и важные даты выясняйте сразу, все, что можно спланировать, — надо планировать. Все риски, которые могут всплыть, надо заложить в эстимейт. Вы можете прекрасно начать работать параллельно на разных проектах. Но сможете ли вы сохранять этот ритм на всех стадиях? Учитывая, что особенно непредсказуемы последние этапы проекта. Например, как QA в конце проекта я провожу регрессионное тестирование. Если все хорошо, проект переходит в релизную стадию. А если все хуже, чем ожидалось, и найденные баги не позволяют выполнить релиз, то снова начинается заведение багов, багфикс, проверка резолвов и т. д. Теперь умножьте негативный вариант изложенного примера на количество ваших проектов. Тут есть о чем задуматься. Никто из нас не застрахован от широко известного Закона Подлости, а научный закона Мерфи гласит:

Eсли есть вероятность того, что какая-нибудь неприятность может случиться, то она обязательно произойдёт.

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

Большой поток информации. Рабочий день начинается не с кофе, а с чтения почты и чатов проекта/проектов. Важно не только держать всю информацию в голове, но и успевать следить за всеми изменениями (а они будут!), важно научиться структурировать информацию и выделять главное. В этом вам могут помочь ежедневники, доски для записей. Пример: вы разработчик и внедряете определенный функционал, ПМ написал в общий чат, что клиент отказался от него, вы это не прочитали. Прошло несколько дней, новые пожелания клиента не были учтены, в результате разгребаем проблемы. Маленькое лирическое отступление: мне вспоминается старый фильм «Джонни-мнемоник» с Киану Ривзом, где главный герой умирал из-за большого объема информации, находящегося у него в голове. Так вот, не надо так :) Что же касается наших реалий, запоминайте основное: если вы обычный человек — записывайте!

Что же делать?

Пришло время делиться лайфхаками.

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

Знай своего врага и знай себя, и ты сможешь провести тысячу битв без поражений (Сунь Цзы, «Искусство войны»).

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

Распределите время (тайм-менеджемент) и поставьте в известность команды. Если за своим временем не будете следить вы, никто за вас этого делать не будет. Если вы на проекте парт-тайм, ваша команда должна об этом знать. Выстраивайте временные границы по проектам, например: на проекте Х я работаю до 13:00, на проекте Y и Z после 13:00. На проект Х я трачу в день не более 3 часов, а на проект Y и Z — не более 5. Составьте план и следите за графиком. Тем, кто глубоко погружается в работу и забывает про время, имеет смысл заводить будильник или делать напоминания — кому что удобно. Совет: прочтите пару книг о тайм-менеджменте. Мне не знаком человек, которому это повредило.

Договоритесь с членами команды по основным моментам сотрудничества. Правильная организация флоу в проекте облегчит всем жизнь. Можно договориться с разработчиками о способах и времени выкатки билдов, заливки изменений на сервер и т. д. Пример из жизни: ПМ хочет получить сегодня отчет по тестированию промежуточного билда мобильного приложения, чтобы отправить определенный результат на ревью заказчику. Разработчик фиксит критические баги, ориентирует нас на после обеда, но билда все нет и нет. Уже в 18:00 вам в скайпе приходит сообщение с линкой на билд, девелопер идет домой, а вы садитесь за проверку. Не надо так.

Планирование каждого проекта (что вы будете делать сегодня, завтра, через неделю). Не приступайте к работе без плана. Намного эффективнее в начале проекта сделать план и в дальнейшем придерживаться его. Это могут быть основные моменты, это может быть план на неделю, месяц, спринт. Все индивидуально, что кому подходит и нравится. В идеале это может быть определенная тулза для планирования. В простейшем виде — табличка по дням с колонками: проект, запланированное время и таски, затраченное время и результат работы, проблемные моменты и т. д. Делая записи, после определенного времени можно вывести закономерности: что занимает большую часть времени, какие задачи даются с легкостью, а какие с трудом. «Звезду Смерти» (из Star Wars) не начинали строить без плана. И будь это хороший план, все закончилось бы плохо для повстанцев и джедаев.

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

20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата.

Это правило применимо и к рабочим процессам. Идентифицируйте основное и второстепенное и начинайте свою работу с основного.

Не отвлекайтесь на другие проекты и старайтесь не прыгать между ними. Руководствуясь вышеизложенным, вы спланировали и организовали свой рабочий процесс на проекте/проектах, но это только начало. Будьте готовы, что вас будут отвлекать по поводу и без повода. Например: вам пишут с вопросом и просят срочно ответить, ПМ просит собрать последний билд, необходимо проверить резолвы, а вы вообще заняты на другом проекте и там сейчас на созвоне с зарубежным клиентом. Переход на другую задачу/проект всегда занимает время, чтобы перестроиться и включиться в работу. Вы не только дробите свое рабочее время по проектам, а еще и тратите его на переключение между ними. Всегда старайтесь свести количество таких прыжков к минимуму. В конце дня после N-го количества переключений может оказаться, что ни одну задачу ни на одном из проектов вы не завершили и выхлоп от вашей работы минимальный.

Не будьте YES-person. Учитесь говорить «НЕТ». Этот принцип частично связан с переключениями между проектами. Говоря всегда «ДА», вы рискуете быть все тем же прыгающим Супер Марио. Нельзя соглашаться с любой просьбой или задачей. Когда вы видите, что определенную работу можно сделать лучше по-другому, сразу выносите свои предложения. Если вы заняты в данный момент и будете заняты еще определенное время, сразу отвечайте «НЕТ» другим участникам проекта на их обращения. Не лишним будет объяснить свою «отрицательную» позицию и сказать, когда вы сможете сказать «ДА» обратившемуся к вам человеку. Не будьте похожим на персонажа Джима Керри из фильма «Всегда говори „ДА“».

Коммуницируйте. Чем больше проект, тем больше риск некачественной коммуникации. Люди сложно устроены, и с ними часто трудно общаться. Софт скиллы тоже важны, умение правильно донести информацию — это тоже исскуство. При множестве людей на проекте не все могут быть всегда в курсе дел, даже уровень понимания целей проекта может быть разный. Не вы один можете быть заняты не на полную ставку. Не ожидайте того, что все будут знать о вашей ситуации и проделанной работе. Как правило, у проекта есть общий чат. Возьмите за привычку писать в чат проекта, когда подключаетесь на проект и когда отключаетесь, информировать свою команду о результатах проделанной работы. Всего несколько слов могут поставить всех в известность и решить множество возникающих проблемных ситуаций.

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

Ориентация на результат. Старайтесь заканчивать в день/неделю/спринт хотя бы одну задачу: реализуйте фичу, проведите рефакторинг вашего кода, допишите чеклист, завершите регрессионное тестирование. Когда работаешь в промышленной сфере, выработку человека видно сразу, в IT это несколько труднее. Когда видно результат проделанной работы, есть что показать, и вас не мучит вопрос «Что же я делал все это время?». Этот и предыдущий пункты важны и с точки зрения удовлетворенности своей работой.

Итог

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

Если у вас возникло желание поделиться своими историями, задать вопрос — буду рад! Спасибо, что дочитали до конца ;)

18 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

никак

Отлично работать. Это на одном можно сойти с ума

Еще один лайфхак
www.y-productive.com

Многое очевидно? Да, так и есть. Вот только мы зачастую даже эти прописные истины откладываем в дальний ящик... Так что любая статья на тему: как сделать свою работу/жизнь более грамотно организованной — это хорошо. Это хороший информационный повод задуматься. Ну а дальше — дело рук самих утопающих :)

Цікавий досвід, дякую. Я впевнений тільки в одному, більшість пунктів з цього тексту — це чисто індивідуально, все залежить від конкретної особи.Собливо про «НЕТ», тут в більшості як склалася психіка, або наскільки якісно ти використовуєш ввесь накопичений досвід

Различные предметные области. Среди ваших проектов одновременно могут быть web, мобильные (нативные/кроссплатформенные), десктопные приложения. Главное, не запутаться что, где и как у вас на разных проектах, например, утвержденные тестовые окружения в разрезе браузеров, девайсов и т. д. У меня как QA, в зависимости от проекта, свой индивидуальный подход к процессу тестирования. У разработчиков же часто возникают проблемы с имплементацией новых фич на новых технологиях, с которыми они не работали раньше.

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

Договоритесь с членами команды по основным моментам сотрудничества.

А с клиентом как договориться?

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

Опять мимо. Всегда надо быть exited !!!!!!. В США всегда есть таких один-два человека в отделе. Неважно все а они громко говорят о своей эрекции на все инициативы.
Завтра надо гуано кушать? Урааааа я эксайтед, узнаем столько новых вкусов и запахов!!!!

Задавайте вопросы и не прекращайте, пока не получите понятный вам ответ.

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

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

Есть проекты, когда детали, становятся известны через год и чисто случайно :)

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

вы какой-то негативный, вот с такими людьми вечно самые длинные email threads :)

Параллельно можно работать над небольшими «операционными» задачами типа «сделал и забыл», или над проектами, которые однородны по тому, что приходится делать. Как только появляется неоднородность или задачи становятся чуть более сложными и продолжительными по времени, эффективность снижается настолько существенно, что проще оказывается все сериализовать.

Довольно часто работаю на нескольких проектах.
Это стрессово, добавляются переживания и метушня на счет сроков, коммуникаций по обоим проектам и как всё утрясти и ни о чем не забыть. Из личного опыта, продуктивность лучше если сосредоточен на одном проекте и одной задаче «at a time», мультитаскинг и мультипроектность — это вынужденная мера, эффективность снижается.
Самым важным принципом (и спасением) для меня было: четкое время для одного проекта и для другого, по часам. Жестко пресекать попытки даже мыслями переключиться на задачи другого проекта, потому что тогда исчезает состояние сосредоточенности и потока на проекте, который сейчас активен, и приходится всё больше времени тратить на задачи.
Жестко подойти к вопросу коммуникаций, исключить ненужные, раставить напоминалки на необходимые события, чтобы не держать их в голове, больше писем и меньше разговоров и звонков.
П.С. И не забывать сохранять дружелюбное и конструктивное настроение даже если по обоим проектам решили спросить в одно и то же время, и ответить надо сиюминутно.

Зі свого досвіду, не претендую на жодну абсолютну істину. Активно працювати вже на 2 проектах одночасно дуже важко. Не виходить ні те, ні друге.

Якщо все таки доводиться, то стараюся звести все до:
1. Фіксований час в місяць (напр. 1-ий тиждень на одному проекті, 2-4-ий на другому). Це бажаний варіант, бо він виключає перемикання по максимуму.
2. Фіксований час в тиждень (напр. 1-2ий день на одному проекту, 3-5-ий на другому). Трохи гірше, але doable.

Тут я маю на увазі як активну роботу так і баги, які треба пофіксити вже зараз — всьому свій час. При цьому дуже важливо, щоб всі учасники процесу знали розклад.

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

Ага, я теж таке помітив. Якщо бачили або читали Барбару Оуклі («Думай як математик») там це пояснюється — коли перемикаєшся на іншу задачу, мозок продовжує працювати над попередньою в «розсіяному» режимі.

Я ее курс смотрел про «Учиться учиться» (не помню, как он правильно называется. Очень познавательно.

Заголовок надо сменить на: «Я меньше года работаю в айти и поэтому счас я вас всех научу как правильно работать!»
:)

«Как прыгнуть с 9го этажа и не умереть». Может, всё-таки не прыгать?..)

Отличный стиль написания, статья читается с удовольствием, спасибо!
P.S. А про позитивный настрой — отличный совет. Когда ты горишь и все вокруг горит, а участники проекта сохраняют бодрость духа, это здорово помогает))

НИКАК...

Особенно умилил пункт:

Не отвлекайтесь на другие проекты и старайтесь не прыгать между ними.

Подписаться на комментарии