Управление проектом с чего начать
Как управлять проектом? Самый простой пошаговый план для новичков
Сегодня я расскажу о самом простом плане работы с проектом от его начала до его завершения. Этот план отлично подойдет для новичков. Если вы еще не освоили Agile, не знаете всех инструментов и лучших практик, но проект сделать нужно, то эта статья для вас.
Совсем немного введения
При разработке нового продукта важно выяснить каким конкретным требованиям он должен соответствовать, необходимо продумать основные функции и интерфейс, а также некоторые важные детали реализации.
Как правило, до начала процесса разработки подготавливается описание основных, самых важных компонентов и достаточно поверхностно, некоторые детали могут быть описаны подробнее, при необходимости. Детализация требований происходит параллельно с процессом программирования и фиксируется, обычно, в ТЗ, а также в виде задач для команды. Такой подход позволяет на этапе инициации проекта достаточно быстро подготовить информацию по проекту, которую можно использовать в оценке проекта, а также дает большую гибкость в реализации проекта, так как требования имеют свойство меняться в процессе (закладываем на это время в оценке).
Итак, ниже я опишу материалы, которые необходимо подготовить для проекта, а также основные этапы работы над проектам от инициализации до запуска и что вам нужно делать на каждом из них.
Для полноценного проектирования и детализации требований продукта необходимо подготовить следующее:
Техническое задание, где мы описываем в текстовом виде и с помощью диаграмм все требования и детали проекта.
Прототипы дизайна, где в общем виду показать какая информация будет размещаться на основных экранах
Смета проекта, где указаны все виды работ на проекте и их оценка в человеко-часах или в днях, а также стоимость проекта
Из второстепенных материалов:
Роадмап проекта, где указываем календарный план работ и майлстоуны
Устав, который часто разрабатывается вместе с контрактом на этапе инициации и где указываем правила работы над проектом (полезная вещь, особенно в неопытных командах)
Ниже я буду описывать процесс работы над проектом, где опишу немного подробнее разработку материалов:
Этап Инициации
На этом этапе идея продукта формируется в виде более подробных требований. Необходимо описать в техническом задании следующее:
Общая информация о проекте
Целевая аудитория проекта и ее проблемы (потребности), которые будет решать продукт
Ожидаемые выгоды от проекта (для ЦА)
Основные функции, которые пользователи смогут выполнять в системе. Составляется в общем виде с базовым описанием. Нужно разбить проект на компоненты, в состав которых может входить несколько функций.
Основные экраны и информация на них (в текстовом виде), которая составляется на основе требований к функциям из пункта выше.
На основе этого Технического Задания делаем Прототипы дизайна, где отображаем информацию, которая описана в последнем пункте. Стоит учесть, что в процессе могут возникнуть изменения и дополнения в ТЗ и это нормально.
После того, как готовы базовое ТЗ и прототипы, формируем Смету проекта, где указываем все виды работ, их оценку в часах, а также бюджет проекта. Иногда там же можно указать майлстоуны. Что касается оценки, то существует масса вариантов, но лично я предпочитаю оценку через бета-распределение (упрощенную версию)
Также можно составить Роадмап проекта на этом этапе, где указать календарный план работ и майлстоуны:
Этап Разработки
На этом этапе подготовленное ранее Техническое задание разбивается на части (функциональные компоненты, например), затем каждая часть описывается более детально, затем разбивается на конкретные задачи для команды и идет в разработку. Таким образом, пока идет проектирование и описание второй части, первая часть уже разрабатывается.
Для каждого компонента системы указывается следующее:
Список use cases (можно постепенно дополнять use case диаграмму или сразу сделать ее в полном объеме) с описанием каждого use case
Описание экранов (также можно постепенно составлять схему экранов или карту сайта)
База данных для компонента (может постепенно дополняться или разрабатываться сразу полностью)
Стоит отметить, что есть разные подходы к разработке Дизайна. В некоторых проектах дизайн полностью подготавливается до разработки, но я часто сталкиваюсь с тем, что дизайн делается частями в момент разработки. Таким образом, сперва подготавливаются основные экраны и компоненты, затем начинается разработка и по мере описания частей решения (о чем я писал выше) составляется дизайн для соответствующих компонентов, который также частями передается в разработку
Этап Запуска
Этап разработки завершается полноценным приемочным тестированием системы. Когда основные баги исправлены, проект запускается на сервере или (если это не серверное решение) отправляется в стор, после чего могут понадобится дополнительные настройки, которые лучше заранее расписать в ТЗ в виде требований к окружению (серверу).
Кроме того, в материалах, описанных выше, могут быть и другие составляющие или, напротив, отсутствовать некоторые из описанных, что вполне нормально и индивидуально для каждого проекта.
Это, конечно, очень упрощенное описание работы над проектом, но достаточное для понимания того, какие материалы и как нужно готовить. Самое важное при работе над проектом пользоваться не только правилами, а также и здравым смыслом.
Управление проектом: с чего начать
В современной литературе по бизнесу написано немало про управление проектом. Ведущие мировые компании накопили весьма значительный опыт в этой области. В своей статье я не стану их все перечислять и давать оценку применимости каждого с позиции собственного опыта. Здесь я хотел бы рассказать о тех подходах, которые могут помочь менеджерам в случае самостоятельного ведения своего первого проекта внутри компании. Если у вас нет за плечами огромного проектного опыта, то данные советы, возможно, позволят немного компенсировать его на первом этапе. Итак, чтобы уже до конца определить периметр обсуждаемой темы: в статье речь идет о «низко висящих фруктах» проектного менеджмента. Рассмотрение проводится на примере консалтинговой компании, что, однако, не ограничивает применимость подходов только в рамках данного бизнеса. Консалтинг подразумевает всего лишь дополнительное звено цепочки взаимодействия в виде заказчика проекта и постоянную оценку эффективности работы проектной команды.
Итак, после очередной аттестации или по иным причинам, связанным с ростом бизнеса, ухода предыдущего менеджера проекта и т.д., руководство принимает решение доверить вам ведение проекта. Такое решение является не чем иным, как изменением правил игры. Эти правила очень просты: необходимо выполнить проект в установленные сроки, с качеством конечных результатов не ниже минимально допустимого уровня и с максимально возможным уровнем рентабельности. В случае невыполнения этих правил все спишется на обстоятельства непреодолимой силы или на ваш непрофессионализм как менеджера проекта. В отношении первого вы бессильны, а чтобы не произошло второго, вам необходимо подготовиться: заранее увидеть потенциальные проблемы и незадействованные ресурсы.
С самого начала необходимо определить объекты влияния. Если вы работаете в консалтинге, то здесь вы управляете:
Все описанные в статье подходы имеют отношение либо к отдельному объекту влияния, либо одновременно к нескольким. Важно оценить возможности их применимости и потенциал улучшений в проектной работе.
Ниже описаны десять подходов, которые помогли мне в свое время успешно реализовать первые самостоятельные проекты.
1. Тщательно подбирайте участников проектной команды
2. Соблюдайте баланс управления
Соблюдайте баланс демократичного и более жесткого менеджмента на проекте в зависимости от возникающей ситуации, но не ограничивайте команду в проектных подходах; лишь четко формулируйте ожидания в отношении будущих результатов:
3. Угадывайте правильное распределение проектных задач
4. Исключайте излишний перфекционизм на проекте
Помните о балансе трех важнейших составляющих проектной работы:
5. Балансирйте загрузку
Стремитесь к балансу загрузки различных категорий участников проектной команды в виде пирамиды:
6. Вовлекайте в работу заказчика
Вовлекайте в проектную работу представителей заказчика, что позволит:
7. Следите за тайм-менеджментом
8. Пользуйтесь общими ресурсами компании
9. «Примеряйте» на себе модели поведения
«Примеряйте» на себе модели поведения, замеченные в поведении ваших знакомых и коллег, пока не найдете ту, которая подходит вам наибольшим образом; такая модель должна позиционировать вас как минимум в отношении:
10. Смотрите вперед
We are sorry that this post was not useful for you!
Гид для начинающего project-менеджера: управляй велосипедом, который горит
Мы собрали этот гид для тех, кто хочет рулить, страдать, ну и проектами управлять. Советы, лайфхаки, ресурсы для получения полезных знаний и даже ссылка на крутую возможность для начала карьеры 😉
Расскажем, как ворваться в проектный менеджмент или развиваться в этом направлении. Разберемся, какие навыки важны для проджектов, как их развивать и как найти работу менеджером проектов, если у вас не техническое образование.
Кто такой менеджер проектов и почему быть им круто?
И ещё один большой плюс для представителей поколений Z и Y — такого рода позиции, как менеджер проектов, всегда располагают к неформальному общению. Просто потому, что вы очень хорошо узнаете всех своих коллег и будете с ними 24/7.
Важно и то, что в процессе работы вы взаимодействуете не только с людьми из вашей команды. Вы общаетесь и с остальными заинтересованными сторонами: обсуждаете правки с руководителем проекта, проводите скрам-планерки и объясняете заказчику, что девять женщин не могут выносить одного ребенка за месяц (ведь большие проекты так не делаются!). Это и делает работу менеджера проектов интересной, но иногда и сложной.
Все приходят к менеджеру проектов с каким-нибудь очередным очень важным вопросом, поэтому приходится быть вовлеченным во все детали процесса. Так что приходить на работу первым, а уходить последним — это не новость. Ну и нужно быть всегда на связи, выслушивать и говорить: “узбагойзя!”. Короче, это не просто работа, а подход к жизни, вынуждающий уметь разруливать разные ситуевины. И это отличный опыт.
Быть менеджером проекта — это точно не скучно. Всегда какой-нибудь новый косяк, задачка, ну или баг. Научитесь справляться с самыми сложными задачами.
Окей, ну и что надо делать
Это всё эмоциональные аспекты работы. Важно, конечно, любить то, что вы делаете, но есть формальные задачи и обязанности, которые нужно будет выполнять.
Итак, чем занимается проджект?
* если хотите реально узнать, чем он занимается, гоу на стажировку сразу проджектом в классный банк
1. Собирает требования к проекту, анализирует бизнес-кейсы для понимания потребностей заказчика / покупателя продукта. PM понимает, что нужно клиентам, умеет ставить цели команде. Хороший менеджер проектов всегда работает вместе с коллегами. В этом суть.
2. Ищет решения. А точнее — вырабатывает их. Менеджер проектов — стратег, который может к правильному решению привести команду. Для этого он фасилитирует брейнштормы, заставляет команду мыслить “out of the box”. Ну или просто достает ремень. Шутка.
3. PM контролирует, чтобы любые коммуникации были запланированы и эффективны. Что, конечно, возможно далеко не всегда. Он точно не будет отслеживать ваши звонки бабушке, ну или куда вы там ещё звоните. В крупных проектах он также может взять на себя мониторинг общения со СМИ.
4. Ещё менеджер проектов обрабатывает задачи: он беспощадно рубит их на маленькие и делегирует, делегирует, делегирует. А ещё является повелителем дедлайнов.
5. Выстраивание последовательности событий. Это вообще краеугольный камень планирования и управления проектом. Надо же точно понимать, что и за каким действием следует? Так что план проекта — это своего рода карта, которой лучше следовать, чтобы не профакапить всё.
6. Доводит проект до конца ценой своей жизни (*опы). Это его основная задача — доделать! Быть “менеджером нереализованного проекта” как-то не круто, согласитесь! Поэтому шутки про PM, которые сами все допиливают в последнюю ночь – не всегда шутки.
7. Контролирует в том числе бумажную работу. И тут без бюрократии никуда: договора, техническое задание, план проекта, устав проекта и еще очень много всяких бумажек. Будьте готовы постоянно менять картридж в принтере.
8. Ну и рассказывает о процессе работы над проектом всем заинтересованным. В основном, конечно отчитывается перед заказчиком.
Навыки, которые следует прокачать будущему менеджеру проектов
Как вы уже поняли, чтобы стать настоящим проджект-менеджером, одной теории об управлении проектами недостаточно. Есть еще soft и hard skills, без которых никуда.
Soft skills
Коммуникации, общение, взаимодействие
Менеджеру проектов приходится общаться с разными людьми и находить общий язык со всеми: и с руководителем отдела, и с младшим разработчиком, и с маркетологом. Главное — уметь доносить информацию так, чтобы всем было понятно. Достаточно понятно для того, чтобы выполнить вашу просьбу или поставить задачу.
Иностранные коллеги и культурные различия
Никакая разница во времени, как и особенности менталитета не должны мешать менеджеру проекта наводить мосты. А книга «Методы убеждения итальянца путем гастрономических кейсов» вообще является вашим настольным пособием.
Знание языка
Да, международные проекты — это всегда круто. Новый рынок, неизведанная аудитория и куча возможностей для компании и менеджера. И вот, руководитель поручает вам провести одну из таких встреч на английском языке, а вы такой «я твоя не понимать».
Бумажная работа
Работа менеджера проектов — это не только брейнштормы, креативный идеи и digital-тусовки. Помните, что предстоит вести большие объемы документов: строить сводные таблицы в Excel, составлять соглашения и согласовывать счета.
ПМ как мозаика из миллиона пазлов
Менеджер проекта должен быть внимательным к деталям, а еще иметь аналитическое, критическое и абстрактное мышление одновременно.
О — ответственность, Р — решительность
Важно быть готовым нести ответственность за свои решения, которые вы будете принимать каждый день. А еще важно находить их быстро — так что решительность тоже пригодится.
3D-мышление вне рамок + взгляд сверху
Чтобы убедиться в верности своих решений, вы должны быть погружены в тему и мыслить шире — уметь посмотреть на ситуацию сверху.
Терпение
Ваша команда постоянно будет задавать тысячу вопросов, а вам как седовласому мудрецу предстоит оценить ситуацию в целом и разделить все по четким задачам. ПМ для команды — альфа и омега, инь и ян.
Менеджер проектов — командный игрок
Он не только лидер, но еще и командный игрок. Вы не можете быть изолированы от команды и просто распределять задачи. Вы — капитан корабля: входите на борт первым, а покидаете последним.
Hard skills
Если рассматривать профессиональные навыки менеджера проектов, то он скорее универсал, а, как уже было сказано выше, не специалист в какой-нибудь одной области.
PM знает разные стороны и особенности своей области, понимает, как устроены бизнес-процессы и даже разбирается в юридической части. Но он не погружается в детали глубоко: достаточно понимания, как связаны процессы, отделы и сотрудники — менеджеру проектов не нужно самому быть исполнителем.
Profit: чтобы быть профессионалом, менеджеру проектов необязательно уметь кодить
А чтобы разработчику стать хорошим менеджером проектов, необходимо понимать психологию, основы коммуникации, постоянно общаться с людьми и быть решительным лидером.
Поэтому, дорогой PM, развивайте свои знания и навыки вширь, а не вглубь.
Не забывайте про постоянное саморазвитие
Изучайте разные особенности и методики управления проектами и никогда не останавливайтесь только на одном. Несмотря на то, что сейчас Agile всему голова, полезно интересоваться другими методиками вроде Waterfall и экстремального проджект-менеджмента.
Подпишитесь на каналы или страницы, где публикуют статьи и лайфхаки по общению с людьми, грамотному управлению, особенностям риск-менеджмента или простой работе с документами — упростите свою профессиональную жизнь и сохраните нервы.
Не тяните время и начните вашу карьеру сегодня
Тем, кто не знает, как начать путь проджект-менеджера, подсказываем: со стажировки в крупной компании, где наставники и коллеги помогут вам быстро вырасти.
Кстати, сейчас в одном крутом банке идет набор на летнюю IT-стажировку — еще успеете подать заявку до 24 апреля и получить возможность развиться в финтехе. Будете работать над реальными проектами с личным наставником и индивидуальным планом развития — через 3 месяца станете уверенным молодым специалистом. Скорее отправляйте заявку.
Получать ли диплом?
Безусловно, образование в сфере IT и бизнес-информатики будут хорошим преимуществом для будущего проджект менеджера. В России релевантными также считаются специальности реклама и маркетинг. Но отсутствие профильного образования отнюдь не означает, что дорога в IT вам закрыта.
На самом деле проджекты с IT бэкграундом часто слишком сильно вдаются в технические подробности и начинают копаться в коде вместо того, чтобы управлять командой. Как мы говорили раньше, хороший PM должен разбираться во многих смежных областях, так что не ограничивайте себя ни в чем. А для пущей уверенности пройдите несколько технических курсов или осмельтесь на второе высшее.
А если я школоло
Если вы еще не получили степень бакалавра, обратите внимание на сферы менеджмента и бизнес управления — попробуйте найти подходящие лекции/курсы в своем университете, изучайте матчасть самостоятельно или попробуйте начать со стажировки.
Конечно, работа в IT проектах требует технической подкованности, поэтому работодатели и требуют соответствующий бэкграунд. Если такого нет — срочно получайте релевантный опыт, он порой значит гораздо больше, чем диплом. Попробуйте начать со стартапа или небольшого проекта: да, придется работать за небольшое вознаграждение, зато вы получите незаменимый опыт, с которым уже можно стучаться в более серьезные компании.
Опыт важнее всего?
Опытные проджекты советуют для начала поработать в сфере, а потом уже получить образование. Почему?
1. Понять, действительно ли вам это нужно. Убедитесь, что вы не приукрашиваете действительность: управлять проектами круто, но не просто так родилась шутка про «ехать на велосипеде, который горит». Постоянный стресс, редкое чувство своей значимости и давление со всех сторон — к такому не каждый готов. Из приятного будет облегчение после разрешения нерешаемой задачи, гордость за найденное изящное решение и выруливание из тупиковых ситуаций. Да, это бывает приятно.
2. Многие сертификаты PMI требуют до 3-х лет опыта работы. Сначала нужно попасть в сферу, получить реальный опыт работы, а потом уже формальное образование. Это значит, что многим вещам придется учиться на своих ошибках, а потом переучиваться, но без опыта вы не сможете понять важных деталей работы.
Как взращивать скиллы проджекта?
Это будет происходить само собой в процессе работы, но мы настаиваем на необходимости самообразования. Читайте статьи и книги — профессиональные и художественные. Задавайте вопросы. Просите советов. Гуглите. Ищите ответы, даже если их нет на первой странице Гугла. Кто ищет, тот всегда найдет.
Потребность в получении новой информации — то, что отличает хорошего проджекта от плохого. Будьте хорошим менеджером, фокусируйтесь на следующих знаниях:
Формальные, проджект-менеджерские. Нет ничего проще: учебник по менеджменту, несколько книг по лидерству и охапка TED Talks. Нужно знать всё и даже больше о том, как управлять, мотивировать и делать счастливыми самых важных людей — вашу команду.
Узкие, специализированные. Вы обязаны знать всё о сфере, в которой работает ваш проект. Создаете медицинские гаждеты — вперед изучать биологию и химию, делаете софт для защиты данных — становитесь асом кибербезопасности. Без таких знаний вы рискуете упустить несколько маленьких, но очень важных деталей.
Личные, софтскилльные. Мы уже об этом говорили: надо развиваться как личность, иначе вам конец. Курсы, книги, общение с умными людьми — не упускайте ни одного шанса.
Как только вы почувствуете, что самообразование уже не прет, идите на курсы. Такое часто случается на втором годе работы, когда мозг начинает требовать постоянных тренировок. Если вы достаточно самостоятельны, учитесь в сети.
Вот маленький список онлайн-школ, где можно получить степень, не отходя от экрана:
Как управлять командой на проекте
Чтобы не облажаться перед заказчиком и не разругаться с коллегами
Я пять лет проработала менеджером проектов в креативных агентствах.
Любой проект — результат совместной работы множества специалистов. Например, нужно сделать промосайт для банка. Этим проектом будут заниматься дизайнеры, редакторы, фронтенд- и бэкенд-разработчики.
На таком проекте работают от 8 до 20 человек. Когда мы не можем решить задачу своими силами, нанимаем еще и подрядчиков. А менеджер проектов управляет всей этой ордой: ставит задачи, контролирует выполнение, решает проблемы и делает так, чтобы к назначенному сроку клиент получил качественный продукт. Расскажу, как с этим справиться.
В чем проблема с управлением командой
В идеальном мире не нужно никем управлять: все работают сами. Дизайнер берет задание, рисует прототип и макет сайта, показывает результат заказчику. Тот доволен и хлопает в ладоши — никаких правок. Дизайнер передает макеты разработчику, а потом бац — и сайт готов. Заказчик с самосвала выгружает мешки с деньгами в благодарность за работу и уезжает в закат. Все счастливы.
Но мы не в идеальном мире, поэтому, если не контролировать каждую мелочь, все идет наперекосяк. Вот типичные проблемы, которые сваливаются на менеджера проектов:
За годы работы я научилась не допускать таких проблем, а если уж они случились, то оперативно их решать. Спойлер: мой секрет успеха — грамотная коммуникация в команде и ультимативная ответственность менеджера. Об этом расскажу дальше в статье.
Планируйте проект вместе с командой
Я не сторонник диктаторского подхода, когда руководитель спускает план сверху и ставит сотрудников перед фактом: «Это нужно сделать до вторника, а вот это — уже к завтрашнему дню. Что значит „нереально успеть“? Я вам плачу за работу, а не за рассуждения о том, что реально, а что нет».
Моя команда — это специалисты, которые выполняют задачу руками. Именно от них зависит, в какой срок мы выполним проект, поэтому я всегда привлекаю коллег к планированию. Так я получаю реалистичную оценку задачи. Заказчик может думать, что проект элементарный и его можно сделать за пару дней. Это нормально, ведь он не специалист, а со стороны многие процессы кажутся проще, чем есть. Члены команды, которые уже выполняли похожие проекты, способны точно оценить временные затраты, учесть детали и увидеть сложности там, где я не замечу.
А еще такой подход добавляет команде мотивации и ответственности. Специалисты работают не по моему плану, а по своему: они придерживаются сроков, которые сами предложили.
Представьте ситуацию: начальник установил срок, который сотрудник считает нереальным. Сотрудник попробовал поспорить, но безрезультатно. Он пожимает плечами и как будто бы уходит работать, но на самом деле занимается саботажем: зачем стараться, если все равно не успеешь и получишь нагоняй от шефа. В итоге задача провалена, руководитель в ярости, а сотрудник твердит: «Я же сразу предупреждал, что не успею».
Схема обычно такая:
Вот как я это делаю:
Катя, нам нужно отрисовать четыре адаптивных макета на основе твоей концепции. Задание и концепт — по ссылкам. Прошу тебя оценить срок отрисовки в часах, как обычно. Заказчик очень хочет уложиться в неделю, но это обсуждаемо. Оценку, предложения и вопросы буду ждать сегодня до 19:00. Если нужно созвониться, говори.
Бывает, что оценка специалиста сильно отличается от моих ожиданий или сроков клиента. Но это не повод продавливать исполнителя. Например, заказчик хочет видеть два макета через неделю, а дизайнер говорит: «Нет, так не получится. Мне нужно две недели». Тогда мы можем попробовать:
Обозначайте роли на проекте
Если упростить, то на любом проекте можно выделить три роли:
На разных проектах в разнообразных связках работают разные специалисты, поэтому команды постоянно перемешиваются. Хорошая практика — «знакомить» исполнителей между собой. Когда я начинаю работу с новой командой, то обязательно обозначаю, кто чем занимается и за что отвечает. Выглядит это так:
Иногда клиенты начинают бомбардировать комментариями всех, чьи контакты знают, — это мешает процессу. Поэтому важно установить понятные правила коммуникации: например, что общение с заказчиком ведется только через менеджера проектов и никак иначе.
Планируйте нагрузку специалистов
Один и тот же сотрудник может одновременно участвовать в нескольких проектах. Например, дизайнер два часа в день тратит на разработку идеи посадочной страницы для авиакомпании, а шесть часов — на отрисовку интерфейса личного кабинета для банка. Задача менеджеров разных проектов — договориться друг с другом и поделить рабочее время специалистов так, чтобы те не перерабатывали и не бездельничали.
Еженедельные планерки помогают синхронизироваться. До планерки менеджеры проектов распределяют часы загрузки специалистов в специальной программе Harvest. Это удобно: можно зафиксировать, кто, что и в какой день делает. Чтобы не тыкать пальцем в небо, на этом этапе снова просим специалистов оценить, сколько времени им нужно.
А уже на планерке сверяем расписание. Иногда случаются конфликты интересов: например, двум менеджерам нужен один и тот же разработчик на всю неделю. В таких случаях мы передоговариваемся и корректируем планы.
Мы стараемся делать так, чтобы специалистам не нужно было постоянно переключаться между проектами: это занимает время. Принцип такой: ежедневно не более 2—3 задач из разных проектов. Идеально, когда человек занимается одним и тем же весь день или даже неделю, но так получается не всегда.
Долгосрочное планирование времени всей команды — удобная и полезная вещь. Она позволяет предсказать и предотвратить следующие проектные проблемы:
Убраться самому или позвать уборщицу?
Внятно ставьте задачи
Чтобы человек правильно выполнил задачу, он должен ее понять. Мой совет: не жалейте времени и сил на объяснение задачи. Иначе потеряете гораздо больше, когда специалист сделает не то, что нужно, и придется все переделывать.
Я использую подход SMART, который подразумевает, что задача должна быть:
Пример постановки задачи
| Задача | Пример |
|---|---|
| Даем конкретную задачу | Вася, нужно сделать баннер 3 × 6 м, согласованное ключевое изображение и слоган — во вложении. Верстка макета — на основе гайдлайна, он тоже во вложении |
| Ставим критерии выполнения задачи | Сначала делаем концепт — просто джипег и мокап, показываем клиенту. Потом доделываем и готовим к печати |
| Определяем ограничения по времени | Концепт нужен завтра до 16:00. Вечером покажем клиенту и послезавтра доработаем |
| Определяем, достижима ли задача | Что думаешь по срокам, успеешь? |
| Согласуем задачу с исполнителем | Все понятно? Если нет, то жду вопросов. Если да, то отпишись, что взял задачу |
Письменно фиксируйте задачи и договоренности
Когда все договоренности устные, получаются примерно такие диалоги:
— Игорь, сегодня уже десятое. Ты обещал запустить сайт девятого, а он до сих пор не работает. Почему?
— Саша, ты что-то путаешь. Я обещал не девятого, а девятнадцатого. И не октября, а ноября. Наверное, ты меня неправильно поняла.
У нас действует правило: нет письма — нет задачи. Если что-то не записано — значит, не зафиксировано и это можно игнорировать. Раньше для постановки и объяснения задач мы пользовались электронной почтой, но это было неудобно: письма терялись, приходилось часами искать какие-нибудь правки по проекту Х от клиента Y с десятой итерации. Потом перешли на таск-менеджер — программу для обмена задачами и материалами. Теперь у нас все зафиксировано и записано, а каждый специалист понимает, где лежит эта информация.
Есть разные таск-менеджеры — выбирайте тот, что подходит вам по функциям и внешнему виду. Например, для меня важно, чтобы в программе был список задач по проекту с назначенными исполнителями и сроками выполнения. И обязательно нужны шаблоны типовых задач, чтобы быстро разворачивать однотипные проекты.
В последнем агентстве, где я работала, использовали «Эктив-коллаб». В компании, где тружусь сейчас, разработчики, финансисты и юристы пользуются «Джирой», а все остальные — «Асаной».
Как ставить задачу: чек-лист для менеджера
Одной реальной задаче соответствует одна задача в таск-менеджере. Не стоит плодить лишние сущности и путать коллег.
У задачи есть понятное название, которое соответствует ее содержанию. Удобно, когда можно прочитать заголовок и сразу понять, о чем речь.
Неверно: «Правки № 136 от Иван Иваныча».
Верно: «Внести изменения в логотип интернет-магазина игрушек для собак».
Есть описание. Расписывайте задачу максимально подробно, чтобы исполнитель однозначно ее понял.
Есть ссылки на источники материалов. Сделайте так, чтобы специалисту было удобно выполнить задачу. Пусть у него под рукой будет все, что нужно для работы.
Вот так не надо: «Миша, поправь макеты в соответствии с гайдлайном. Макеты я скидывала на файлообменник, ссылка должна быть у тебя на почте, поищи. А сам гайдлайн был где-то на сайте. Если не найдешь, то свяжись с Васей: он вроде говорил, что у него все есть».
Хуже этого описания только то же самое, но в аудиосообщении. Если так поставить задачу, специалист взвоет и постарается подольше не притрагиваться к ней. А когда приступит, потеряет целый день на сбор информации.
Установлен срок выполнения задачи. Важно не только обговорить конечный срок, но и письменно его зафиксировать. Иначе менеджер и исполнитель быстро забудут, о чем договаривались, особенно если задач много.
Есть план работы и промежуточные сроки. Если задача сложная, то стоит разбить ее на части, расписать каждую подзадачу и установить контрольные точки. Тогда, если что-то пойдет не так, менеджер узнает об этом сразу, а не к моменту сдачи проекта.
Специалист может задать вопросы и высказать мнение по задаче. Проблема в том, что некоторые люди стесняются спрашивать и уточнять. Они думают, что профессионал должен схватывать все на лету и не задавать лишних вопросов. Это опасное заблуждение приводит к проблемам в проекте.
Например, специалист столкнется с трудностями, но промолчит об этом, чтобы не показаться некомпетентным. Вместо того чтобы предупредить и попросить о помощи, он начнет решать проблему самостоятельно, не справится и подставит всю команду.
Поэтому всегда оставляйте дверь, в которую исполнитель может постучаться, чтобы обсудить проблемы и вопросы. Уточняйте: «А тебе точно все понятно? А у тебя есть все материалы, чтобы выполнить задачу?»
Есть просьба подтвердить, что задача принята. Нужно получить от исполнителя однозначное свидетельство, что он взял задачу в работу. Молчание — это не знак согласия. Согласие выглядит примерно так: «Все понял, материалов достаточно, вопросов нет, по срокам — ок, задачу забрал». Или в виде плюсика, как договоритесь.
Оберегайте команду от комментариев заказчика
Заказчик не обязан уметь формулировать комментарии так, чтобы они были понятны техническим специалистам. Если ему не нравится цвет, он может сказать: «Этот красный какой-то не такой, давайте что-то повеселее». Дизайнер читает эту правку и думает, что повеселее — это, например, желтый. Но на самом деле заказчик хотел просто сделать красный более ярким.
Чтобы дизайнер мог понять клиента, ему нужен более конкретный комментарий. Он бы предпочел услышать что-то вроде этого: «В файле ads.png используется составной черный цвет. В типографии опасаются, что этот цвет в печати провалится или его поведет в синий. Предлагают заменить его черным пантоном, чтобы все было в цвет».
И задача менеджера проектов — перевести замечания с языка клиента на тот, что будет понятен команде. Когда я получаю правки, то делаю три вещи:
Вместо того чтобы перенаправлять письмо заказчика напрямую исполнителю, я разбираюсь в сути информации. И только когда мне все уже понятно, иду с задачей к специалисту. Так я выступаю защитным фильтром от всяческого мусора, непродуманных задач и правок.
Организовывайте рабочие процессы и общение на проекте
Очень важно, чтобы люди свободно общались друг с другом, несмотря на расстояние и разницу во времени. По моему опыту, большинство проблем на проекте возникает из-за кривой коммуникации: кто-то не сказал, не предупредил, не уточнил информацию, не попросил о помощи.
Представьте, что все члены команды общались бы разными способами. Один сотрудник пишет всем через «Вайбер», другой предпочитает «Телеграм», третий — видеозвонки в «Скайпе». В итоге — полная анархия. Поэтому моя задача — чтобы каждый понимал, какие способы коммуникации есть в компании и как их правильно использовать.
Обычно я организую три пространства для общения: доска проекта в «Эктив-коллабе», канал в «Слаке» и видеоконференции в «Зуме».
«Эктив-коллаб» нужен, чтобы хранить задачи и материалы в одном месте, а также планировать и обсуждать проекты. Благодаря этому сервису нам не приходится общаться по работе в десяти разных мессенджерах, а потом часами искать нужные ссылки и файлы. Все находится в одном месте — на доске проекта в «Эктив-коллабе».
Мы стараемся максимально все стандартизировать, поэтому оформляем проекты по шаблонам: в них заранее созданы списки материалов и план работы. Благодаря такому подходу сотрудникам не приходится ломать голову и угадывать, где лежат нужные файлы.
Канал проекта в корпоративном мессенджере «Слак» — здесь мы обсуждаем текучку и мелкие вопросы. Этот мессенджер не хранит переписку, поэтому все серьезные дискуссии и решения мы переносим из «Слака» в «Эктив-коллаб».
«Зум» используем для созвонов. Здесь есть свои правила: нельзя просто взять и позвонить человеку. Предварительно нужно списаться в «Слаке»: договориться о времени звонка и теме разговора. Это делается, чтобы не застать собеседника врасплох и не отвлечь от других важных дел.
О подобных принципах мы рассказываем сотрудникам с первых недель работы. Если человек их нарушает, мы отдельно встречаемся с ним, напоминаем, кидаем ссылку на внутренние документы компании. Обычно одного-двух напоминаний хватает, чтобы договориться об одинаковых правилах игры.
Контролируйте работу над проектом
Выполнение любых задач нужно контролировать. Без контроля не будет и результата. Либо же вы получите результат, но не тот, что нужен заказчику, или не в те сроки, о каких договаривались.
Контроль важен, даже если в вашей команде одни гении. Особенно если в ней одни гении.
Есть большие задачи: например, разработать мобильное приложение для банка. В таких случаях я делаю подробный план: разбиваю задачу на множество мелких кусочков и прописываю, когда каждый кусочек должен быть готов и кто за это отвечает.
Но важно не перебарщивать с контролем: бюрократизация — это зло. Например, есть мелкие задачи: нарисовать баннер или логотип, написать статью для сайта. Если по подобным задачам я заставлю исполнителя отчитываться мне каждые полчаса, это будет только мешать и тормозить рабочий процесс. Достаточно где-то в середине выполнения задачи спросить, как дела и не нужна ли помощь.
Разрешайте конфликты и проблемы
Если люди работают в команде, то проблемы и ошибки одного участника неизбежно отражаются на других. Например, если дизайнер поздно сделал макет, то разработчику придется работать в ускоренном темпе, чтобы команда успела сдать проект. Либо руководителю придется договариваться с заказчиком об изменении сроков, что совсем не здорово.
Конфликты и проблемы возникают на проектах постоянно: все мы люди и каждый может ошибиться, что-то забыть, не учесть. Иногда все это происходит одновременно.
Конечно, лучше всего не допускать ошибок, а еще — быть здоровым, красивым и богатым. Но мы живем не в идеальном мире, так что проблемы случаются. Считаю, что систему характеризует не ошибка, а реакция на нее, поэтому я стараюсь превращать провалы в опыт.
Задача руководителя — вовремя выявлять и разрешать проблемы и конфликты. Вот как я это делаю.
Решаю проблемы своевременно. Если вопрос возник сегодня, то и обсуждать его нужно сегодня. Бывает, что руководитель внезапно вспоминает о какой-то ситуации, которая произошла полгода назад, и вызывает работника на разговор. Обычно конструктивного диалога не получается, так как сотрудник уже забыл, в чем там было дело, — или делает вид, что забыл.
— Юра, ты задолбал опаздывать, рабочий день начинается в 10:00, пора уже запомнить. С тобой одни проблемы!
— А какие еще проблемы?
— А помнишь, в позапрошлом месяце ты проигнорировал правки заказчика и сдал макеты, которые пришлось переделывать?!
— Да толком-то и не помню. О каком проекте речь? Вроде бы мне никаких правок не присылали.
— Юра, привет. Я хочу обсудить ситуацию на проекте «Ромашка»: вчера ты сдал макет без учета части вводных из задания. Давай обсудим, почему так произошло.
Сначала устраняю последствия, а потом разбираюсь в причинах. Если начался пожар, то нужно тушить пламя, а не выяснять, кто оставил зажженный бычок. Так и здесь: если команда не успевает сдать проект, то сначала надо решить проблему с горящими сроками. А уже потом спокойно разобраться, что именно произошло, и сделать выводы.
— Так, мы не успеваем сдать проект, заказчик в ярости. Я хочу знать, кто в этом виноват. Поэтому до конца дня у меня на почте должны быть объяснительные с отчетами о проделанной работе от каждого сотрудника.
— Кажется, мы не успеваем сдать проект, заказчик очень нервничает. На кону наша репутация и деньги. Потом мы обязательно обсудим, как так получилось и как этого не допустить в будущем, а сейчас нужно спасать положение. Через два часа планерка, прошу всех подготовить предложения, как решить проблему.
Сохраняю спокойствие. В любой спорной ситуации я стараюсь действовать без эмоций. Если положение серьезное, то люди уже и так сильно переживают — незачем их дополнительно накручивать. А если проблема пустяковая, то она просто не стоит нервов.
Любой проект — это клубок конфликтов, споров и проблем. Если руководитель будет реагировать чересчур эмоционально и агрессивно, то команда устанет от бесконечных истерик и перестанет воспринимать его всерьез.
Когда я только стала менеджером и вела свой первый проект, то так разозлилась на дизайнера, что послала его на три русских буквы. Уже через десять минут я поняла, как ужасно поступила, и побежала извиняться.
С дизайнером мы помирились и до сих пор дружим. Детали той ссоры давно забылись: мы даже не можем вспомнить, что меня взбесило и почему я так отреагировала. Осталось только воспоминание об этой некрасивой ситуации.
Думаю, что если бы тогда я не поняла свою ошибку и не извинилась, то у меня не было бы ни проекта, ни работы, ни друга.
Если и критикую, то осторожно. У большинства людей есть фильтр — он автоматически включается, когда приходится слушать то, что не хочется. Этот фильтр превращает гневные высказывания начальника в белый шум: работник вроде бы стоит с виноватым видом и даже кивает в такт словам, но по факту он вас не слышит. Проверено на себе в роли сотрудника.
Чтобы человек воспринимал мою критику, я стараюсь говорить не о том, какой он плохой, а о проблеме. Никогда не критикую специалистов в присутствии других членов команды. В такой ситуации человек думает не о решении проблемы, а о том, как не выглядеть слабаком в глазах коллег. Если и нужно высказать сотруднику что-то не очень приятное, то делаю это лично и без свидетелей.
Если же нас разделяет расстояние, то стараюсь критиковать только на созвоне — никаких мессенджеров и электронной почты. Причина простая: в письме не видны эмоции, поэтому я не понимаю, что чувствует человек и как он реагирует на мои слова. Ну а коллега может не разобраться, что имею в виду я, если не слышит мой голос и интонацию.
— Ваня, бесишь меня! Нельзя было, что ли, нормально сделать?
— Ваня, привет. Я хочу обсудить ситуацию на проекте «Ромашка»: у нас с тобой сорвались сроки. Давай обсудим? У тебя есть минут пятнадцать?
— Пойдем в переговорку тогда.
— Ваня, как ты знаешь, у нас был план проекта. Ты обещал сверстать две страницы до среды. Сегодня четверг, у нас нет ни одной страницы. Клиент немного в ужасе. Расскажи, что случилось? Почему не получилось?
Извлекаю пользу из ошибок. Любая проблемная ситуация — это урок для всей команды. После решения проблемы стоит подумать, как не допустить ее повторения. Например, изменить инструкции или рабочие процессы, пересмотреть подходы к планированию, постановке и контролю задач.
— Ваня, давай вместе разбираться, что именно не вышло. Боюсь, что если такое повторится — клиент от нас сбежит. Расскажи, с какими проблемами ты столкнулся, что непонятно? Покажи прямо на макете.
— Ну смотри, макеты какие-то кривые. Вот тут нет правильного шрифта и сетка странная.
— И правда. А чего ты сразу не спросил об этом меня или дизайнера?
— Думал, что разберусь, но не вышло.
— Ладно, поняла тебя. Давай так: сейчас я позову дизайнера, организуем созвон, обсудим твои вопросы. Потом перепланируем неделю, и я предупрежу клиента об изменении сроков. Договорились?
— Ну да, понял. Стеснялся просто.
Принимайте ответственность за все, что происходит на проекте
Есть простой принцип, которого я придерживаюсь. Он помогает не злиться на людей из-за ошибок и не винить высшие силы, когда все идет не по плану.
Звучит он так: менеджер отвечает за все, что происходит на проекте. Когда я это поняла и приняла, мне стало легче работать с командой, а команде — со мной. Если сотрудник не выполнил задачу или сдал результат с опозданием, отвечает менеджер. Если работа не устроила заказчика, то виноват не «криворукий дизайнер», а менеджер.
Если я уверена, что проблема не во мне, а в ком-то или чем-то еще, то решить ее сложно. Все же мое влияние на других людей и внешние факторы сильно ограничено. А вот если принять идею, что все сложности — на моей совести, тогда только я и могу со всем разобраться. Разумеется, бывают ситуации, когда виноват все же исполнитель, клиент или ретроградный Меркурий. Но разгребать-то все равно мне, поэтому первым делом надо понять, что конкретно я могу сделать для решения проблемы.
Покажу, как это работает. Специалист не выполнил задачу. Вызываю его на приватный разговор и спрашиваю: «А что пошло не так, почему не получилось?»
Опытный работник без труда найдет ответ, но начинающий специалист может и сам до конца не понимать, что пошло не так. Тогда нужно подбодрить и помочь уточняющими вопросами: «Может, не хватило материалов, знаний или ты чего-то не понял? Либо эта задача тебе неинтересна? Давай разберемся. Я хочу помочь тебе, чтобы такая проблема не повторилась».
В итоге работник даст какое-то объяснение. Менеджер должен внимательно выслушать и понять, в чем ошибка и как ее исправить.
Как перевести объяснения сотрудников на менеджерский язык
| Почему сотрудник не выполнил задачу | Неправильный подход: виноваты все вокруг | Правильный подход: виноват менеджер | Что делать менеджеру |
|---|---|---|---|
| Думал, что нужно сделать что-то другое | Специалист тупой и не понял задачу | Я не объяснил задачу по-нормальному | Научиться ставить задачи и проверять, что они поняты |
| Не получилось, думал, что разберусь, но не смог | Специалист ничего не умеет, понабирают тут всяких | Я поставил задачу не тому специалисту |
Я не предупредил специалиста, что нужно сообщать о проблемах и просить о помощи
Я не прописал четкий план с контрольными точками
Я не согласовал или не зафиксировал сроки проекта
Я как-то дал понять специалисту, что задача не очень важная, и этим его демотивировал
Поработать над постановкой задач в части договоренностей о сроках
Объяснить работникам, что о возможном опоздании нужно предупреждать как можно раньше — до дедлайна, а не после
Тщательней планировать работу, усилить промежуточный контроль над выполнением задач
Я поставил задачу не тому специалисту
Я не предупредил специалиста, что нужно сообщать о проблемах и просить о помощи
Разобраться с компетенциями своих коллег. Брать в команду тех, кто может решать поставленные задачи
Научиться правильно ставить задачи. Так, чтобы люди знали: в подобных ситуациях нужно не молчать, а бить в колокола и просить о помощи
Я не распланировал нагрузку
Я не прописал четкий план с контрольными точками
Я не согласовал или не зафиксировал сроки проекта
Я как-то дал понять специалисту, что задача не очень важная, и этим его демотивировал
Проанализировать причины опоздания
Поработать над постановкой задач в части договоренностей о сроках
Объяснить работникам, что о возможном опоздании нужно предупреждать как можно раньше — до дедлайна, а не после
Тщательней планировать работу, усилить промежуточный контроль над выполнением задач
Проводите ретроспективу проекта
По завершении проекта я стараюсь собрать команду и обсудить, что было хорошо, а что стоит улучшить. Кажется, что это не так важно, ведь в потоке задач нет времени оглядываться назад: новое будто бы в приоритете перед старым. Но это не совсем так: ретроспектива нужна, чтобы извлечь полезный опыт, который поможет эффективнее работать над следующими проектами. То есть мы оглядываемся в прошлое, чтобы стать лучше в будущем.
На ретроспективе можно узнать впечатления команды от работы и собрать идеи по улучшению процессов.
Например, недавно мы с внутренним заказчиком обсуждали прошедший проект. Заказчик пожаловался, что ему не хватало обратной связи: он не всегда понимал, на каком этапе находится проект и что именно происходит. Тогда мы договорились о новых правилах взаимодействия: с моей стороны — более четкое планирование и отчеты, а с его — более внятная постановка задач. Все договоренности зафиксировали письменно, придерживаемся их уже несколько месяцев — полет нормальный.
Как руководить командой на проекте
