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

За материал выражаем благодарность dou.ua

Секрет того, чтобы добиться чего-то,— начать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что же делать

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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