Как выглядит задача

Как правильно поставить задачу для разработки

«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов. Как это сделать, рассказывает руководитель проектного офиса “CleverPumpkin” Лада Ларкина.

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

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

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

Декомпозиция задач

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

Название задачи

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

[версионная особенность] [раздел] — [часть экрана] — [что сделать]

Разберем каждую часть названия:

• [версионная особенность] — это может быть версия платформы, MacOS/iPad фичи;
• [раздел] — описывает, в каком разделе добавляется функциональность;
• [часть экрана] — указывает конкретный блок на экране, если изменения касаются его;
• [что сделать] — суть изменения или фичи;

Примеры хороших названий:

• «Подключить Firebase Performance»
• «Профиль (авторизованный) — добавить пункт история заказов»
• «История заказов — реализовать загрузку и отображение списка заказов»
• «Заказ из истории — Блок итого — Добавить строку дополнительных услуг»
• «[iPad] История заказов — Реализовать просмотр конкретного заказа в split view режиме»
• «[iOS 13+] Настройки — Добавить пункт «Siri shortcuts»

Примеры неудачных названий:

• «Подключить экран к API» — (какой раздел, экран?)
• «Цветовая индикация» — (ее нужно добавить? изменить? где находится?)

Описание задачи

Описание должно быть необходимым и достаточным.

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

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

Не забудьте описать:

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

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

Лайфхаки и советы

1. Структурируйте и будьте аккуратны. Разделяйте задачу на логические блоки, чтобы удобно было читать и находить информацию. Для начального заполнения задачи пользуйтесь шаблоном (например, YouTrack, который мы используем в работе, автоматически добавляет формат базовой задачи с местом для верстки, логики и сразу с базовым чек-листом, всем советуем, очень удобно).
2. Не допустите пересечения параллельных задач между разработчиками. Так вы получите увеличение трудозатрат на разрешение конфликтов и дублирование.
3. Ставьте задачи на любые изменения. Без этого вы не сможете доказать разработчику, что он сделал что-то не так. Устные договоренности ничего не значат! Без задачи изменения не будут протестированы тестировщиком. Кроме того, часто поставленные задачи служат единственным источником информации о поведении приложения. Отсутствие задачи в начале — недостаток информации потом.
4. Связь задач между платформами. Обязательно свяжите задачи про одинаковые фичи между двумя платформами в системе постановки задач. Так проще поддерживать актуальность описаний задач при изменениях на обеих платформах, догоняющий разработчик сможет узнать, кто делал задачу на другой платформе, и прочитать обсуждение.
5. Визуализация для задачи. Иногда схема, диаграмма или картинка опишет разработчику что-то понятнее, чем сложный текст — или хотя бы поможет быстрее разобраться в задаче.

Чек-лист для разработчика

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

1. наиболее старую поддерживаемую версию платформы — она же обычно и самая проблемная;
2. работу на маленьком девайсе;
3. темную тему;

Кроме того, в зависимости от задачи чек-лист может дополняться следующими пунктами:

• крайние кейсы для проверки;
• пустые состояния;
• состояния ошибок;
• подгрузка данных (если она постраничная);
• обновление данных (PTR);
• большие/маленькие данные;
• заглушки для текстов/картинок;
• горизонтальная ориентация.

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

Ожидаемый эстимейт по задаче

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

Шаги описания задачи

Итак, зафиксируем пройденный материал:

• Получите все необходимые требования. Убедитесь, что сами понимаете, что требуется реализовать.
• Подберите правильное название задачи.
• В самом начале описания задачи поясните разработчику ценность изменения.
• Добавьте путь до изменяемого экрана, если это не очевидно.
• Добавьте ссылки на макеты, если фича визуальная. Если есть разные состояния в зависимости от условий, описываемых в задаче, то добавьте ссылки в контексте конкретного кейса.
• Добавьте дополнительные ссылки на артефакты, которые требуются для выполнения задачи.
• Если предполагается переиспользование для реализации, явно укажите это.
• Укажите, если в будущем будет переиспользоваться, масштабироваться или меняться результат задачи.
• Если необходимо сохранение данных для будущего использования, укажите.
• Опишите функционально задачу и убедитесь в отсутствии пробелов в логике.
• Опишите всю необходимую информацию по сетевым запросам (запрос, ответ, что парсим, опциональность; не описывать неиспользуемые поля и указать, что их не парсим).
• Укажите, если данные получаются при каком-то условии — например, касаются только авторизованных пользователей, специальных заказов или аккаунтов и т.д.
• Укажите прошлые локальные данные, если они используются.
• Пропишите логику загрузки данных: есть ли постраничная подгрузка, активити и т.д.
• Укажите логику для пустых данных.
• Опишите разные форматы отображения для разных региональных параметров, форматов дат и т.д.
• Пропишите логику для обработки специальных ошибок.
• Если требуются какие-то ключи, то добавьте их для каждого типа сборки – QA/RC/Release.
• Убедитесь, что разработчики имеют доступ ко всем необходимым артефактам или сервисам.
• Добавьте аналитику по данной функции (возможно в другой задаче – подумайте и не забудьте).
• Дополните базовый чек-лист.
• Свяжите с задачей для другой платформы и другими задачами, если есть такая зависимость.
• Перечитайте всю задачу от начала до конца!

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

Примеры хорошо описанных задач

Эти задачи описаны достаточно полно, не вызвали вопросов у разработчиков.

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

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

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

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

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

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

Как решать логические и математические задачи

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

Решаем логические задачи

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

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

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

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

Основные методы решения логических задач

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

Попробуйте занятия на сайте ЛогикЛайк!

Выберите возраст ученика для старта
15+ для себя

На платформе LogicLike.com 5500 логических заданий с ответами: ребусы, задачи, вопросы и головоломки.

Давайте рассмотрим подробнее с примерами три популярных способа решения логических задач, которые мы рекомендуем использовать в начальной школе (детям 6-12 лет):

• метод последовательных рассуждений;
• разновидность метода рассуждений — «с конца»;
• табличный способ.

Метод последовательных рассуждений

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

На столе лежат Голубой , Зеленый , Коричневый и Оранжевый карандаши.

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

Разложи карандаши в описанном порядке.

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

• Больше всего букв в слове «коричневый», значит, он лежит третьим.
• Известно, что голубой карандаш лежит между коричневым и оранжевым. Справа от коричневого есть только одна позиция, значит, расположить голубой между коричневым и другим карандашом возможно только слева от коричневого.
• Следующий вывод на основе предыдущего: голубой карандаш лежит на второй позиции, а оранжевый — на первой.
• Для зеленого карандаша осталась последняя позиция — он лежит четвертым.

Метод «с конца»

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

Бабушка испекла для троих внуков рогалики и оставила их на столе. Коля забежал перекусить первым. Сосчитал все рогалики, взял свою долю и убежал.
Аня зашла в дом позже. Она не знала, что Коля уже взял рогалики, сосчитала их и, разделив на троих, взяла свою долю.
Третьим пришел Гена, который тоже разделил остаток выпечки на троих и взял свою долю.
На столе осталось 8 рогаликов.

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

Начинаем рассуждение «с конца».
Гена оставил для Ани и Коли 8 рогаликов (каждому по 4). Получается, и сам он съел 4 рогалика: 8 + 4 = 12.
Аня оставила для братьев 12 рогаликов (каждому по 6). Значит, и сама она съела 6 штук: 12 + 6 = 18.
Коля оставил ребятам 18 рогаликов. Значит, сам съел 9: 18 + 9 = 27.

Бабушка положила на стол 27 рогаликов, рассчитывая, что каждому достанется по 9 штук. Поскольку Коля уже съел свою долю, Аня должна съесть 3, а Гена — 5 рогаликов.

Как ЛогикЛайк может помочь родителям?

Выберите основную цель занятий

Решение логических задач с помощью таблиц истинности

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

Три спортсмена ( красный , синий и зеленый ) играли в баскетбол.
Когда мяч оказался в корзине, красный воскликнул: «Мяч забросил синий».
Синий возразил: «Мяч забросил зеленый».
Зеленый сказал: «Я не забрасывал».

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

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

Затем таблицу последовательно заполняют: верные утверждения отмечают знаком «+», а ложные утверждения — знаком «-«.

Рассмотрим первый вариант ответа («мяч забросил красный «), проанализируем утверждения, записанные слева, и заполним первый столбик.
Исходя из нашего предположения («мяч забросил красный «), утверждение «мяч забросил синий» — ложь. Ставим в ячейке «-«.
Утверждение «мяч забросил зеленый» также ложь. Заполняем ячейку знаком «-«.
Утверждение зеленого «Я не забрасывал» – истина. Ставим в ячейке «+».

Рассмотрим второй вариант ответа (предположим, что мяч забросил зеленый ) и заполним второй столбик.
Утверждение «мяч забросил Синий» — ложь. Ставим в ячейке «-«.
Утверждение «мяч забросил зеленый « — истина. Заполняем ячейку знаком «+».
Утверждение зеленого «Я не забрасывал» – ложь. Ставим в ячейке «-«.

И, наконец, третий вариант: предположим, что «мяч забросил синий «.
Тогда утверждение «мяч забросил синий « — истина. Ставим в ячейке «+».
Утверждение «мяч забросил зеленый» — ложь. Заполняем ячейку знаком «-«. Утверждение зеленого «Я не забрасывал» – истина. Ставим в ячейке «+».

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

Значит, правильный ответ – мяч забросил синий.

Метод блок-схем

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

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

• графически (блок-схемой) описываем последовательность выполнения операций;
• определяем порядок их выполнения;
• в таблице фиксируем текущие состояния.

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

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

Подключайтесь к ЛогикЛайк!

Учим детей 5-12 лет решать любые логические и математические задачи. Более 3500 занимательных заданий с ответами и пояснениями.

Как сформулировать эффективную задачу проекта (с примерами)

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

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

Что такое задачи проекта?

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

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

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

Задачи проекта и цели проекта

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

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

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

Задачи проекта и бизнес-задачи

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

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

• Пример задачи проекта. Повысить Индекс потребительской лояльности нашей компании до 62 пунктов к концу квартала.
• Пример бизнес-задачи. Стать ведущим поставщиком услуг в нашей категории.

Задачи проекта и план проекта

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

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

• Пример задачи проекта. К концу 3 квартала повысить кликабельность (CTR) писем на 10%.
• Пример плана проекта. Посмотрите пример плана в нашем руководстве по планированию проектов.

Задачи проекта и вехи проекта

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

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

• Пример задачи проекта. Получить 20 000 подтверждений участия в нашем онлайн-мероприятии до даты закрытия регистрации (23 июня).
• Пример вехи проекта. 8 июня 2021 г.: публикация веб-страница с информацией о предстоящем виртуальном мероприятии.

Задачи проекта и ожидаемые результаты проекта

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

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

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

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

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

Когда у персонала нет чёткого понимания того, как его труд связан с более крупными целями проекта и компании, люди менее мотивированны и вовлечены. Согласно Отчёту Asana о целях только 26% сотрудников хорошо понимают, как их личная работа влияет на цели компании. Конечно, задачи проекта не то же самое, что цели компании, но именно они являются связующим звеном между работой отдельных сотрудников, задачами, выполняемыми в рамках проекта, и целями компании.

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

Пять советов о том, как правильно сформулировать задачи проекта

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

• Specific — конкретными
• Measurable — измеримыми
• Achievable — достижимыми
• Realistic — реалистичными
• Time-bound — ограниченными по времени

Полное руководство по этой методологии приведено в нашей статье о том, как ставить SMART цели.

1. Формулируйте задачи проекта в начале работы над ним

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

2. Привлекайте команду проекта к процессу постановки задач

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

3. Создавайте короткие, но чётко сформулированные задачи проекта

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

4. Задачи проекта должны быть вам подконтрольны

Здесь в игру вступает методология SMART, позволяющая создать чётко сформулированные, реалистичные и контролируемые задачи проекта. В состав этой структуры входит пять элементов:

• Specific — конкретные. Задача проекта должна иметь чёткую связь с проектом, которым занимается ваш коллектив. Избегайте слишком широких задач, которые напрямую не связаны с результатами проекта.
• Measurable — измеримые. После завершения проекта вам потребуется возможность оценить его и определить, был ли он успешным. В связи с этим задачи проекта должны быть легко измеримыми — это может изменение в процентах или определённое количество активов.
• Achievable — достижимые. Поставили ли вы задачи, которых действительно сможете достичь в рамках проекта? Этот вопрос связан с объёмом проекта — если объём проекта нереалистичен, то и задачи, скорее всего, также не будут реалистичными. Без достижимых целей проекта он может пострадать от разрастания объёма, задержек или переработок.
• Realistic — реалистичные. Формулируя задачи проекта, у вас должно быть общее представление об имеющихся ресурсах проекта. Убедитесь в том, что поставленные задачи можно выполнить за отведённое время, располагая ресурсами, которые выделены на проект.
• Time-bound — ограниченные по времени. Задачи проекта должны учитывать его хронологию. Обязательно примите в расчёт то количество времени, которое отведено для работы над проектом.

5. Сверяйтесь с задачами проекта в процессе его реализации

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

Примеры хороших и плохих задач проекта

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

Пример 1. Задача бизнес-проекта

• Плохо. Обновить домашнюю страницу.

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

• Хорошо. Создать абсолютно новые материалы и текст для домашней страницы, основанные на четырёх историях успеха клиентов и примерах использования. Запустить обновлённую домашнюю страницу, упор на которой делается на ценности для клиентов, до конца 2 квартала.

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

Пример 2. Цель некоммерческого проекта

• Плохо. Повысить экологичность нашего производственного процесса на 5%

Хотя эта задача более конкретная, чем в предыдущем плохом примере, в ней всё равно не хватает нескольких важных параметров. Эта задача измерима (на 5%), но не конкретна и не ограничена по времени, так как мы не указали, что подразумевается под «экологичностью» и к какому времени нужно улучшить производственный процесс. В результате невозможно понять, является ли задача достижимой и реалистичной.

• Хорошо. Сократить отходы производства на 5% и повысить использование переработанных материалов на 20% за следующие 12 недель.

Эта задача проекта основана на предыдущей, и теперь она стала конкретной. Эта задача также позволяет измерить достижение целей (на 5%. на 20%). Задача достаточно сложная, но то, что она ограничена по времени (за следующие 12 недель), делает её достижимой и реалистичной.

Пример 3. Задача личного проекта

• Плохо. Улучшить оценки работы

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

• Хорошо. Получить как минимум 4 из 5 баллов за оценку работы в марте и сентябре 2021 года.

Здесь мы видим задачу проекта, отвечающую всем условиям: она конкретна (получить минимум 4 из 5 баллов), измерима (4 из 5), достижима и реалистична (4 из 5 баллов даёт возможность учесть трудности, которые могут неожиданно возникнуть), а также ограничена по времени (в 2021 году).

Говоря объективно, создавать задачи проекта — хорошая идея

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

Задачи на работу и производительность

На это уроке мы рассмотрим разные способы решения задач на работу, чтобы сэкономит время на экзамене!

Мы разберем более 11 примеров (и этого будет достаточно, чтобы решить любую задачу на работу на ЕГЭ)

Let’s do it! (Сделаем это!)

Задачи на работу — коротко о главном

Производительность – это объем работы, выполняемый за единицу времени: \( \displaystyle P=\frac\)

При совместной работе производительности складываются.

Основная формула задач на работу

Ты уже освоил тему «Задачи на движение»? Задачи на работу – это то же самое.

Основная формула здесь выглядит так:

Производительность – это объем работы, выполняемый за единицу времени (например, за час или за день).

По-другому, скорость выполнения работы. Вася решает \( \displaystyle 5\) задач в час. Это и есть производительность.

Как у тебя дела с физикой? В физике эта величина называется мощностью.

Как и в задачах на движение, нам нужно не зазубрить эти формула, а уметь выражать все эти три величины друг через друга:

\( \displaystyle P=\frac\)

\( \displaystyle t=\frac\)

\( \displaystyle A=P\cdot t\)

Пример:

Заказ на \( \displaystyle 112\) деталей первый рабочий выполняет на \( \displaystyle 2\) часа дольше, чем второй. Сколько деталей за час делает первый рабочий, если известно, что второй за час делает на одну деталь больше, чем первый?

Решение:

Пусть производительность первого равна \( \displaystyle x\) (ее нам и нужно найти). Тогда второго — \( \displaystyle (x+1)\). Если первый сделал заказ за время \( \displaystyle t\), тогда второй – за время \( \displaystyle t-2\). Работа равна \( \displaystyle 112\).

1-й способ решения — с помощью таблицы

Для каждой строки можем написать формулу:

Почему я выразил именно время?

У нас здесь система уравнений. А что происходит в системе, если выразить одну неизвестную через другую?

Мы таким образом можем от нее избавиться! Именно это я и собираюсь сделать!

Время нам известно? Нет. Его нам нужно найти? Нет.

Поэтому от неизвестного \( \displaystyle t\) надо избавиться!

Для этого теперь достаточно просто приравнять полученные выражения для \( \displaystyle t\):

\( \displaystyle \Leftrightarrow \left\< \begin^>+x-56=0\\x\ne 0\\x\ne -1\end \right.\Leftrightarrow \left[ \beginx=7\\x=-8\end \right.\)

Из этих двух ответов, естественно, выбираем положительный: \( \displaystyle x=7\).

2-й способ решения — без таблицы

Как обойтись без составления таблицы?

Сразу составить уравнение.

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

Производительность? Ее и надо найти. Работа? Она нам дана по условию, поэтому глупо от нее избавляться. Остается время: оно нам и неизвестно, и не нужно.

Слева от знака равно будем писать формулу времени для первого рабочего, а справа – для второго.

Напомню, что первый работал на \( \displaystyle 2\) часа дольше, поэтому к времени второго надо будет прибавить \( \displaystyle 2\):

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

А теперь вспомним, что я говорил в сааамом начале: задачи на работу и на движение – это то же самое. Спорное заявление, да? Ну, давай проверим, есть ли аналогия.

Во-первых, сравним формулы:

Движение	Работа
\( \displaystyle v=\frac\)	\( \displaystyle P=\frac\)
Скорость движения	Скорость выполнения работы, т.е. производительность
Пройденный путь	Выполненная работа
Потраченное на движение время	Потраченное на работу время

Теперь рассмотрим задачу:

Пример №1

Расстояние \( \displaystyle 112\) км первый велосипедист проезжает на \( \displaystyle 2\) часа дольше, чем второй.

Сколько км в час проезжает первый велосипедист, если известно, что второй за час проезжает на один километр больше, чем первый?

Ничего не напоминает? Да я же просто заменил слова: «Заказ» на «расстояние», «деталь» на «километр», «рабочий» на «велосипедист», «выполняет» на «проезжает». Суть осталась той же. Даже решение будет точно таким же (разберу здесь только II способ – без таблицы).

Пусть скорость первого \( \displaystyle x\), тогда второго \( \displaystyle x+1\). Сколько времени едет первый? \( \displaystyle \frac\). Сколько времени едет второй? \( \displaystyle \frac\). На сколько время первого больше, чем второго? На \( \displaystyle 2\) часа:

То же самое уравнение! Вот и получается, что работа и движение – одно и то же.

Как решать задачи на совместную работу

Задачи на совместную работу отличаются от обычных, представленных выше, тем, что в них работа выполняется одновременно (совместно) несколькими рабочими (трубами и т.д.).

Пример №2

Первая труба заполняет бассейн за \( \displaystyle 6\) часов, а вторая – за \( \displaystyle 4\).

За какое время они заполнят бассейн, работая вместе?

Решение

Во-первых, давай придумаем аналогию с движением.

Бассейн – это путь. Допустим, из \( \displaystyle A\) в \( \displaystyle B\). Итак, первый автомобиль проезжает путь \( \displaystyle AB\) за \( \displaystyle 6\) часов, второй – за \( \displaystyle 4\).

А теперь как сформулировать вопрос? За какое время они проедут весь путь, двигаясь вместе? Бред.

Если двигаться параллельно, то каждый проходит весь путь самостоятельно. А в какой ситуации нам важно, какой путь автомобили проходят в сумме? Все гениальное просто: если они движутся навстречу друг другу!

Тогда что нас просят найти? Время, через которое они встретятся.

Поразмысли немного над этой аналогией. Все понял? Тогда идем дальше.

Какова «скорость» (а по-настоящему, производительность) первого? Путь (работа) деленный на время: \( \displaystyle _>=\frac_>>=\frac\). А второго? \( \displaystyle _>=\frac_>>=\frac\).

С какой производительностью работают две трубы вместе (не забывай, это задачи на совместную работу)? Берем количество литров, которое налила в бассейн первая труба за один час, прибавляем количество литров, которое налила в бассейн вторая труба за один час, – именно столько наливают в бассейн обе трубы за один час. То есть производительности складываются:

То же самое, что и относительная скорость: с какой скоростью второй автомобиль приближается к первому? Со скоростью, равной сумме скоростей: \( \displaystyle v=_>+_>\).

Тогда время, за которое с такой производительностью будет выполнена работа \( A\):

При совместной работе производительности складываются