что такое вопрос проекта

Что такое основополагающий вопрос проекта?

Ищем педагогов в команду «Инфоурок»

ЧТО ТАКОЕ ОСНОВОПОЛАГАЮЩИЙ ВОПРОС?

Вопрос, полагающий основы будущей деятельности.

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

Это неординарный и многослойный вопрос, отражающий богатство и сложность изучаемого предмета.

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

Вопрос возникает снова и снова на протяжении обучения.

Поиск ответа на основополагающий вопрос приводит к появлению других важных вопросов.

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

Упражнение «Да или Нет?»

Из предложенного списка выберите вопросы, которые, на Ваш взгляд, являются основополагающими:

Что радует природу?

Кому ставят памятник?

Кто главный в семье?

Какой материал самый прочный и самы й непрочный?

Как перестать беспокоиться ?

Почему болит голова у моей бабушки?

Как влияет атмосферное давление на кровеносную систему человека?

Почему на крыльях стрекозы возникает радуга?

Как можно передать художественный образ героя?

О чем может рассказать портрет?

Курс повышения квалификации

Дистанционное обучение как современный формат преподавания

Курс повышения квалификации

Специфика преподавания предмета «Родной (русский) язык» с учетом реализации ФГОС НОО

Курс повышения квалификации

Скоростное чтение

Номер материала: ДБ-633333

Международная дистанционная олимпиада Осень 2021

Не нашли то что искали?

Вам будут интересны эти курсы:

Оставьте свой комментарий

Авторизуйтесь, чтобы задавать вопросы.

Безлимитный доступ к занятиям с онлайн-репетиторами

Выгоднее, чем оплачивать каждое занятие отдельно

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

Время чтения: 1 минута

На Госуслугах ввели запись детей на кружки и секции

Время чтения: 2 минуты

Российские школьники завоевали пять медалей на олимпиаде по физике

Время чтения: 1 минута

В России выбрали топ-10 вузов по работе со СМИ и контентом

Время чтения: 3 минуты

Минпросвещения будет стремиться к унификации школьных учебников в России

Время чтения: 1 минута

Путин попросил привлекать родителей к капремонту школ на всех этапах

Время чтения: 1 минута

Подарочные сертификаты

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

Все материалы, размещенные на сайте, созданы авторами сайта либо размещены пользователями сайта и представлены на сайте исключительно для ознакомления. Авторские права на материалы принадлежат их законным авторам. Частичное или полное копирование материалов сайта без письменного разрешения администрации сайта запрещено! Мнение администрации может не совпадать с точкой зрения авторов.

Источник

Этап подготовки проекта в теории

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

Что же такое проект?

Проект – одноразовая, неповторяющаяся деятельность или совокупность действий, в результате которых за определенное время достигаются четко поставленные цели.

В определенном смысле все проекты одинаковы. У всех есть потребитель (и) и \ или покровитель (и), которые ждут от реализации проекта достижения в определенное время результатов. Проекты часто реализуются с целью создания чего-то нового или осуществления больших изменений, которые можно рассматривать как завершенный вид деятельности. Проект может возникнуть исходя из новых запросов потребителей или пользователей услуг, либо из возможности получить выгоды для организации, либо на основании новых потребностей организации.

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

Часто встречающиеся недостатки в реализации проектов:

На основании своих исследований Элбейк и Томас указали 10 факторов, которые многие определяют как критические для успеха проекта (расположены в соответствии с приоритетами):

Определение границ проекта

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

Проблемы недостаточно точного определения потребностей:

Для того, чтобы понять масштабы проекта необходимо иметь следующую информацию:

ЗС и их потребности

В зависимости от особенностей проекта многие другие группы или отдельные люди могут быть заинтересованы в нем:

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

Определение предназначения и целей проекта

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

Цели должны соответствовать критериям SMART:

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

Возможности и угрозы

Исследование возможностей и угроз на начальной стадии проекта может быть важным для определения его масштаба. Постоянные обсуждения с ЗС могут выявить многие потенциальные возможности и угрозы, связанные с проектом. Управление рисками (возможными угрозами проекту) будет рассмотрено ниже.

Проверка осуществимости проекта

Затраты и выгоды для оценки проекта

Риски и ситуационное планирование

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

Оценка риска и анализ влияния: ключевые вопросы

Основание для действий по проекту

Источник

10 вопросов-индикаторов состояния проекта

Автор статьи Анастасия Поветкина, менеджер проектов INOSTUDIO.

Если вы слышите вопросы от клиента: «Когда начнем еще один проект? Где оставить положительный отзыв о вас?», вы понимаете, что все идет хорошо.

Если вы слышите от команды вопросы: «Что мы еще можем сделать для проекта? А сколько наш проект принес клиенту прибыли?», вы тоже понимаете, что на верном пути. Но есть такие вопросы, которые заставляют вас задуматься, — а все ли хорошо с проектом, — и предпринять срочные меры по их устранению.

Ниже представлена подборка ТОП-10, на наш взгляд, таких вопросов и способы исправления ситуации в лучшую сторону.

Вопросы от членов вашей команды:

1. Что мне сейчас делать?

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

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

Планируйте и еще раз планируйте!

2. Когда у нас релиз?

Вопрос возникает из-за отсутствия планирования либо плохой коммуникации внутри команды. Команда должна четко видеть даты всех будущих вех, релизов, этапов тестирования, демонстраций для клиента и тому подобного. Это позволяет мобилизовать силы перед важными событиями, распределять нагрузку в течение каждой итерации проекта, планировать график работы (ранний уход с работы, отгул, отпуск).

Планируйте детально и долгосрочно, насколько это возможно.

Обеспечьте команде быстрый доступ к информации о важных датах.

Составьте вместе с командой календарь событий на проекте и разошлите его всем.

3. А где мне взять пароль для этого сервиса?

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

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

4. Вопрос в середине или конце проекта: «А для чего вообще этот продукт и какова цель проекта?»

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

Важно! Формулируйте цель проекта для конкретно вашей компании и команды (получат ли ребята определенный опыт, поставят ли новый рекорд и т. д.)

Вопрос от QA-специалиста:

5. А как это тестировать?

Этот вопрос вовсе не означает, что у вас не самый лучший QA-специалист. Возможно, вы не лучшим образом документируете происходящее, описываете или ставите задачи.

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

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

Вопросы от Клиента:

6. С кем обсудить этот вопрос?

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

К примеру, если вопрос срочный и важный — телефонный звонок, если не срочный — почта или мессенджер.

7. А как работает мое приложение?

Если возник такой вопрос, значит вы не смогли вовлечь клиента в проектную работу, или степень его вовлечения была низкой. Вероятно, концепция проекта не обсуждалась детально на старте работ, не было хорошо налаженных коммуникаций, не проводились демонстрации решения. (подробнее о том, зачем нужны демонстрации и как их проводить, вы можете прочитать в статье Все на демонстрацию!).

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

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

8. Как мне зайти в админку сайта?

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

Расскажите, для чего она и какие действия можно в ней совершать.

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

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

Вопрос, который менеджер проекта задает сам себе:

9. Что нужно клиенту?

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

Общайтесь с клиентом.

Задавайте ему вопросы.

Слушайте внимательно ответы.

Вопрос каждого члена команды самому себе:

10. Как заставить себя работать эффективно?

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

Эти 10 вопросов помогут вам идентифицировать проблемы на проекте. Надеемся, чтобы подобных вопросов в вашей проектной деятельности становилось меньше. Если у вас есть свои особые индикаторы проблем в проекте, будем рады их обсудить в комментариях.

Источник

Разработка учебного проекта

Часть 2

Разработка основополагающего вопроса и проблемных вопросов учебной темы

Прочитайте отрывок из книги Гранта Виггинса и Джея Мактайя «Понимание через проектирование»* 1 Из книги «Understanding by Design Handbook» Grant Wiggins and Jay McTighe; Alexandria, VA. Association for Supervision and Curriculum Developmentc 1998 ASCD. Reprinted with permission. All rights reserved. и еще раз обдумайте основополагающие и проблемные вопросы своего учебного проекта, при необходимости внесите в них изменения.

Bопросы, ответы на которые невозможно списать: пути к пониманию сути вещей, процессов и явлений

С чего может начинаться разработка учебного проекта?

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

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

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

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

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

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

На эти вопросы нельзя ответить одним предложением. Чтобы достичь глубокого понимания сути дела, мы должны использовать неординарные и многослойные вопросы, отражающие богатство и сложность изучаемого предмета. Такие вопросы называют «основными», «основополагающими» (Essential questions), так как они затрагивают ключевые идеи изучаемой дисциплины.

Характеристики основополагающих вопросов

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

Мы считаем целесообразным выделять два типа вопросов, которые мотивируют обучение: проблемные вопросы и вопросы конкретной темы учебной программы (unit questions). Вопросы учебной темы более конкретны в отношении изучаемого предмета и таким образом оказывают направляющее влияние на усвоение содержания темы.

Характеристика проблемных вопросов учебной темы

Важно отметить, что между основополагающими вопросами и вопросами учебной темы (проблемными) нет четкой разницы. Главное не в том, каким является вопрос, а в том, как сосредоточить внимание учащегося на главных целях обучения, связать конкретные вопросы с более общими, направить исследование и процесс раскрытия важных понятий в нужное русло.

Дополнительные примеры и презентация об основополагающих вопросах и вопросах учебной темы:

интенсивный тренинг для тьюторов по материалам Шелли Шотт, менеджера образовательных программ для средней школы программы Intel ® «Инновации в образовании», Институт компьютерных технологий, США.

Значения основополагающего вопроса помогут понять 2 фрагмента из фильма «Улыбка Моны Лизы» © Sony Pictures, 2003:

Если Вы владеете английским языком, то можете дополнительно просмотреть следующие ресурсы.

Для просмотра этой страницы на Вашем компьютере должна быть установлена программа Adobe Acrobat Reader.

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

Источник

Как управлять командой на проекте

Чтобы не облажаться перед заказчиком и не разругаться с коллегами

Я пять лет проработала менеджером проектов в креативных агентствах.

Любой проект — результат совместной работы множества специалистов. Например, нужно сделать промосайт для банка. Этим проектом будут заниматься дизайнеры, редакторы, фронтенд- и бэкенд-разработчики.

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

В чем проблема с управлением командой

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

Но мы не в идеальном мире, поэтому, если не контролировать каждую мелочь, все идет наперекосяк. Вот типичные проблемы, которые сваливаются на менеджера проектов:

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

Планируйте проект вместе с командой

Я не сторонник диктаторского подхода, когда руководитель спускает план сверху и ставит сотрудников перед фактом: «Это нужно сделать до вторника, а вот это — уже к завтрашнему дню. Что значит „нереально успеть“? Я вам плачу за работу, а не за рассуждения о том, что реально, а что нет».

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

А еще такой подход добавляет команде мотивации и ответственности. Специалисты работают не по моему плану, а по своему: они придерживаются сроков, которые сами предложили.

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

Схема обычно такая:

Вот как я это делаю:

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

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

Обозначайте роли на проекте

Если упростить, то на любом проекте можно выделить три роли:

На разных проектах в разнообразных связках работают разные специалисты, поэтому команды постоянно перемешиваются. Хорошая практика — «знакомить» исполнителей между собой. Когда я начинаю работу с новой командой, то обязательно обозначаю, кто чем занимается и за что отвечает. Выглядит это так:

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

Планируйте нагрузку специалистов

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

Еженедельные планерки помогают синхронизироваться. До планерки менеджеры проектов распределяют часы загрузки специалистов в специальной программе Harvest. Это удобно: можно зафиксировать, кто, что и в какой день делает. Чтобы не тыкать пальцем в небо, на этом этапе снова просим специалистов оценить, сколько времени им нужно.

А уже на планерке сверяем расписание. Иногда случаются конфликты интересов: например, двум менеджерам нужен один и тот же разработчик на всю неделю. В таких случаях мы передоговариваемся и корректируем планы.

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

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

Убраться самому или позвать уборщицу?

Внятно ставьте задачи

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

Я использую подход SMART, который подразумевает, что задача должна быть:

Пример постановки задачи

Письменно фиксируйте задачи и договоренности

Когда все договоренности устные, получаются примерно такие диалоги:

— Игорь, сегодня уже десятое. Ты обещал запустить сайт девятого, а он до сих пор не работает. Почему?

— Саша, ты что-то путаешь. Я обещал не девятого, а девятнадцатого. И не октября, а ноября. Наверное, ты меня неправильно поняла.

У нас действует правило: нет письма — нет задачи. Если что-то не записано — значит, не зафиксировано и это можно игнорировать. Раньше для постановки и объяснения задач мы пользовались электронной почтой, но это было неудобно: письма терялись, приходилось часами искать какие-нибудь правки по проекту Х от клиента Y с десятой итерации. Потом перешли на таск-менеджер — программу для обмена задачами и материалами. Теперь у нас все зафиксировано и записано, а каждый специалист понимает, где лежит эта информация.

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

В последнем агентстве, где я работала, использовали «Эктив-коллаб». В компании, где тружусь сейчас, разработчики, финансисты и юристы пользуются «Джирой», а все остальные — «Асаной».

Как ставить задачу: чек-лист для менеджера

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

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

Неверно: «Правки № 136 от Иван Иваныча».

Верно: «Внести изменения в логотип интернет-магазина игрушек для собак».

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

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

Вот так не надо: «Миша, поправь макеты в соответствии с гайдлайном. Макеты я скидывала на файлообменник, ссылка должна быть у тебя на почте, поищи. А сам гайдлайн был где-то на сайте. Если не найдешь, то свяжись с Васей: он вроде говорил, что у него все есть».

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

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

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

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

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

Поэтому всегда оставляйте дверь, в которую исполнитель может постучаться, чтобы обсудить проблемы и вопросы. Уточняйте: «А тебе точно все понятно? А у тебя есть все материалы, чтобы выполнить задачу?»

Есть просьба подтвердить, что задача принята. Нужно получить от исполнителя однозначное свидетельство, что он взял задачу в работу. Молчание — это не знак согласия. Согласие выглядит примерно так: «Все понял, материалов достаточно, вопросов нет, по срокам — ок, задачу забрал». Или в виде плюсика, как договоритесь.

Оберегайте команду от комментариев заказчика

Заказчик не обязан уметь формулировать комментарии так, чтобы они были понятны техническим специалистам. Если ему не нравится цвет, он может сказать: «Этот красный какой-то не такой, давайте что-то повеселее». Дизайнер читает эту правку и думает, что повеселее — это, например, желтый. Но на самом деле заказчик хотел просто сделать красный более ярким.

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

И задача менеджера проектов — перевести замечания с языка клиента на тот, что будет понятен команде. Когда я получаю правки, то делаю три вещи:

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

Организовывайте рабочие процессы и общение на проекте

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

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

Обычно я организую три пространства для общения: доска проекта в «Эктив-коллабе», канал в «Слаке» и видеоконференции в «Зуме».

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

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

Канал проекта в корпоративном мессенджере «Слак» — здесь мы обсуждаем текучку и мелкие вопросы. Этот мессенджер не хранит переписку, поэтому все серьезные дискуссии и решения мы переносим из «Слака» в «Эктив-коллаб».

«Зум» используем для созвонов. Здесь есть свои правила: нельзя просто взять и позвонить человеку. Предварительно нужно списаться в «Слаке»: договориться о времени звонка и теме разговора. Это делается, чтобы не застать собеседника врасплох и не отвлечь от других важных дел.

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

Контролируйте работу над проектом

Выполнение любых задач нужно контролировать. Без контроля не будет и результата. Либо же вы получите результат, но не тот, что нужен заказчику, или не в те сроки, о каких договаривались.

Контроль важен, даже если в вашей команде одни гении. Особенно если в ней одни гении.

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

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

Разрешайте конфликты и проблемы

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

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

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

Задача руководителя — вовремя выявлять и разрешать проблемы и конфликты. Вот как я это делаю.

Решаю проблемы своевременно. Если вопрос возник сегодня, то и обсуждать его нужно сегодня. Бывает, что руководитель внезапно вспоминает о какой-то ситуации, которая произошла полгода назад, и вызывает работника на разговор. Обычно конструктивного диалога не получается, так как сотрудник уже забыл, в чем там было дело, — или делает вид, что забыл.

— Юра, ты задолбал опаздывать, рабочий день начинается в 10:00, пора уже запомнить. С тобой одни проблемы!

— А какие еще проблемы?

— А помнишь, в позапрошлом месяце ты проигнорировал правки заказчика и сдал макеты, которые пришлось переделывать?!

— Да толком-то и не помню. О каком проекте речь? Вроде бы мне никаких правок не присылали.

— Юра, привет. Я хочу обсудить ситуацию на проекте «Ромашка»: вчера ты сдал макет без учета части вводных из задания. Давай обсудим, почему так произошло.

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

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

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

Сохраняю спокойствие. В любой спорной ситуации я стараюсь действовать без эмоций. Если положение серьезное, то люди уже и так сильно переживают — незачем их дополнительно накручивать. А если проблема пустяковая, то она просто не стоит нервов.

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

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

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

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

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

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

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

— Ваня, бесишь меня! Нельзя было, что ли, нормально сделать?

— Ваня, привет. Я хочу обсудить ситуацию на проекте «Ромашка»: у нас с тобой сорвались сроки. Давай обсудим? У тебя есть минут пятнадцать?

— Пойдем в переговорку тогда.

— Ваня, как ты знаешь, у нас был план проекта. Ты обещал сверстать две страницы до среды. Сегодня четверг, у нас нет ни одной страницы. Клиент немного в ужасе. Расскажи, что случилось? Почему не получилось?

Извлекаю пользу из ошибок. Любая проблемная ситуация — это урок для всей команды. После решения проблемы стоит подумать, как не допустить ее повторения. Например, изменить инструкции или рабочие процессы, пересмотреть подходы к планированию, постановке и контролю задач.

— Ваня, давай вместе разбираться, что именно не вышло. Боюсь, что если такое повторится — клиент от нас сбежит. Расскажи, с какими проблемами ты столкнулся, что непонятно? Покажи прямо на макете.

— Ну смотри, макеты какие-то кривые. Вот тут нет правильного шрифта и сетка странная.

— И правда. А чего ты сразу не спросил об этом меня или дизайнера?

— Думал, что разберусь, но не вышло.

— Ладно, поняла тебя. Давай так: сейчас я позову дизайнера, организуем созвон, обсудим твои вопросы. Потом перепланируем неделю, и я предупрежу клиента об изменении сроков. Договорились?

— Ну да, понял. Стеснялся просто.

Принимайте ответственность за все, что происходит на проекте

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

Звучит он так: менеджер отвечает за все, что происходит на проекте. Когда я это поняла и приняла, мне стало легче работать с командой, а команде — со мной. Если сотрудник не выполнил задачу или сдал результат с опозданием, отвечает менеджер. Если работа не устроила заказчика, то виноват не «криворукий дизайнер», а менеджер.

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

Покажу, как это работает. Специалист не выполнил задачу. Вызываю его на приватный разговор и спрашиваю: «А что пошло не так, почему не получилось?»

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

В итоге работник даст какое-то объяснение. Менеджер должен внимательно выслушать и понять, в чем ошибка и как ее исправить.

Как перевести объяснения сотрудников на менеджерский язык

Я не предупредил специалиста, что нужно сообщать о проблемах и просить о помощиНаучиться правильно ставить задачи. Так, чтобы люди знали: в подобных ситуациях нужно не молчать, а бить в колокола и просить о помощиНе нашел материалыНадо было в папке поискать, там же все есть. Эх, никто ничего не соображает, вот если бы все были умные, как яЯ не сделал так, чтобы у специалистов под рукой было все для работыОрганизовать систему хранения задач и материалов. Убедиться, что каждый сотрудник знает, как она работает. Внедрить шаблоны проектовНе успелА в курилку сходить успел?!Я не распланировал нагрузку

Я не прописал четкий план с контрольными точками

Я не согласовал или не зафиксировал сроки проекта

Я как-то дал понять специалисту, что задача не очень важная, и этим его демотивировалПроанализировать причины опоздания

Поработать над постановкой задач в части договоренностей о сроках

Объяснить работникам, что о возможном опоздании нужно предупреждать как можно раньше — до дедлайна, а не после

Тщательней планировать работу, усилить промежуточный контроль над выполнением задач

Я поставил задачу не тому специалисту

Я не предупредил специалиста, что нужно сообщать о проблемах и просить о помощи

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

Научиться правильно ставить задачи. Так, чтобы люди знали: в подобных ситуациях нужно не молчать, а бить в колокола и просить о помощи

Я не распланировал нагрузку

Я не прописал четкий план с контрольными точками

Я не согласовал или не зафиксировал сроки проекта

Я как-то дал понять специалисту, что задача не очень важная, и этим его демотивировал

Проанализировать причины опоздания

Поработать над постановкой задач в части договоренностей о сроках

Объяснить работникам, что о возможном опоздании нужно предупреждать как можно раньше — до дедлайна, а не после

Тщательней планировать работу, усилить промежуточный контроль над выполнением задач

Проводите ретроспективу проекта

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

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

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

Как руководить командой на проекте

Источник