Как составить понимание задачи

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

Называется «понимание задачи». 

Теперь погружаемся.

Ситуация со стороны специалиста

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

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

До вечера пятницы вы сделаете что-то такое:

Ситуация со стороны менеджера

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

В пятницу вечером вы ожидаете от исполнителя что-то такое:

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

Как можно было бы предотвратить проблему

Менеджер: «Вась, есть новая задача, такая-то. Принимаешь? Напиши, как понял»

Вася:

Это и есть понимание задачи. 

Обратите внимание: тут написано, что именно будет делать исполнитель, в каком объёме, какой будет результат. Не просто «сделать аналитику», а в деталях, что именно будет происходить. Что-то вроде технического задания для самого себя. 

Менеджер смотрит на это и такой: «Не, погодь!». Оказывается, аналитик Вася плохо понял задачу: нужно не Эксель, а презентацию. И не с 1 января, а более живую осеннюю статистику (потому что в январе люди отдыхают). И не просто кликов, а именно тех кликов, которые привели к фактической продаже — это разные вещи. И хорошо бы не впритык к пятнице, а пораньше.

Аналитик Вася смотрит на эти комментарии и такой: «В смысле?!» В частности: 

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

Вася и Костян посидят над этими противоречиями пять минут и придумают так:

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

Почему это проблема

Во-первых, у каждого человека своё представление о работе и результате. Примеры:

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

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

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

Почему обычно не составляют понимание задачи

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

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

Сами менеджеры часто не настаивают на составлении понимания задачи. Мол, «я же всё сказал, задача передана, работаем». Это признак неопытности: любой бывалый менеджер знает, что переданная задача — не значит понятая. 

Всегда ли это нужно?

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

На типовые задачи и которые уже много раз делали — уже нет необходимости. 

Дополнительные бонусы

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

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

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

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

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

Короче:

Лучше сейчас за 5 минут описать понимание задачи, чем потом 5 часов всё переделывать 🗡

Можно по разному относиться к «Бюро Горбунова» и его апологетам, но в одном им не откажешь — в Бюро умеют чётко формулировать идеи и их придерживаться. Это касается и методологии ФФФ (которую, впрочем, придумали в 37Signals), и принципов «делать ≠ сделать» или «исполнитель понимает задачу». Последний принцип особенно важен. Мало кто пытается на решить задачу клиента, а не просто её сделать. И это проблема.

Зачем понимать задачу

В идеальном мире работа над задачей происходит так:

Но в реальности клиент не принимает задачу, потому что исполнитель что-то сделал не так. Исполнитель переделывает, клиент снова недоволен, снова переделка и так пока клиент и исполнитель не придут к компромиссу или не разругаются. Так происходит из-за того, что клиент и исполнитель по-разному смотрят на задачу:

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

Единственный способ исполнителю удостовериться, что он правильно всё понял — задать клиенту вопросы и озвучить (или написать) своё понимание. Если клиент подтвердит, можно смело приступать к работе.

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

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

Как задавать вопросы

К пониманию задачи можно подходить по разному, в зависимости от сложности. Главное — убедиться, что ты всё правильно понял.

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

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

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

Что должно быть в понимании задачи

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

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

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

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

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

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

18 Апр 2023

2339

0

Термин: «Понимание задачи»

Что значит «Понимание задачи» и как появился этот термин

В 2007-2008 гг. Артём Горбунов, основатель одноимённого Бюро, придумал термин «Понимание задачи», который с тех пор продвигает и популяризирует. Сотрудники Бюро придерживаются этого принципа при реализации проектов.

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

Материалы на тему «Понимание задачи»

Как в бюро ставят задачи?

В этой статье Артём рассказал об универсальном правиле, которое называется «исполнитель понимает задачу».

В случае, когда студия взаимодействует с клиентом: исполнитель письменно описывает, что он собирается делать, а затем детально согласовывает с клиентом «понимание задачи».

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

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

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

Лекция Ильи Бирмана о понимании задачи

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

Короткий конспект лекции, который составил Сергей Король

Короткий конспект лекции, который составил Александр Сарычев

Ваш новый любимый рабочий инструмент — понимание задачи

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

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

Как меньше переделывать

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

Как разобраться в задаче

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

Этап исследования задачи в UX-проекте

Перевод статьи Nielsen Norman Group об исследовании задачи. Из статьи вы узнаете, как взаимодействовать с командой и бизнесом, чтобы все правильно понимали область проблемы и достигли согласия в отношении конечного результата.

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

Развёрнутый ответ креативного директора AGIMA Григория Коченова о том, какую ошибку чаще всего совершают начинающие дизайнеры

Источник: Журналус, Выпуск №245, 22 марта 2021

«Ошибка у начинающих, а часто и не очень начинающих, это понимание задачи как есть. Когда нет мясорубки вопроса «Зачем»! «Главный вопрос жизни, вселенной и всего такого» Дугласа Адамса. 42 мира дизайна! Убейте всех вопросами «зачем»! Пусть они вас ненавидят вначале, зато потом будут возвращаться и платить больше!

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

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

И другая сторона «зачем» уже со стороны дизайнера. Я делаю это проект чтобы что? Какой тут мой личный челлендж? Скорость? Новый стиль? Методология? Без такой игры в «зачем» сложно идти вперёд. Это внутренняя игра, дающая небывалую силу и быстрый рост. Трансформирует скучные задачи в интересные вызовы. А главное — продуцирует кучу офигенных историй! А где есть истории, там и огонь в глазах. Огонь важен. Всё мечтаю работать с теми, кому интересно».

Как ставить задачу на текст (и кто должен её ставить) — часть 2 из статьи «Как делать лендинги в 2022»

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

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

Things I Wish I’d Known Earlier In My Career

Виталий Фридман, основатель Smashing Magazine, поделился наблюдениями насчёт переговоров о зарплате и повышениях. В ней он, кроме прочего, затронул вопрос о том, почему необходимо составлять «понимание задачи» и согласовывать его с клиентом или менеджером

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

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

Что такое понимание задачи

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

Польза понимания задачи и приятные бонусы

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

Бонус четкости границ проекта. Сформировав понимание задачи, меньше рискуем свернуть с намеченного пути и потратить время на что-то лишнее. Любую идею, фичу или изменение в проекте прогоняем через фильтр ПЗ, чтобы понять, зачем это все.

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

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

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

Бонус лояльности. Это про клиентский сервис. Мы не просто удовлетворяем первичный запрос клиента «хочу сайт», а через разговор узнаем (а порой и помогаем узнать самому клиенту), что действительно принесет пользу ему и его бизнесу и почему.

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

Как выглядит понимание задачи “на бумаге”

Документ с пониманием задачи – это 3 основных тематических блока.

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

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

Третий блок — наше решение. Подробно объясняем, как будем решать задачу заказчика. Фактически это КП, в котором зафиксировано:

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

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

Как понять задачу: встреча с заказчиком и подготовка к ней

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

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

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

Как подготовиться

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

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

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

В конце встречи проговариваем, как в итоге мы поняли задачу. Тезисно повторяем всё, что удалось выяснить и сформулировать вместе с заказчиком во время разговора. Как правило, первичный запрос, с которым клиент к нам пришел, к этому моменту сильно меняется.

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

После встречи берём время на создание документа с пониманием задачи и формулировку решения, которое предложим заказчику.

Сколько времени нужно на понимание задачи

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

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

Когда надо понять задачу

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

Полезные материалы:

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

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

Первым делом нужно посмотреть мою Киевскую лекцию о понимании задачи. Там я рассказываю о том, как вообще формулировать задачу и из каких разделов состоит документ-понимание. Я называю три: 1. Задача. 2. Первая версия. 3. Организация работы. В случае с дипломным проектом структура будет другая, но эти три раздела в ней тоже будут, просто под другими названиями.

На странице договора с бюро есть ссылка «Задание». Там нужно взять шаблон для Гугль-документа с вашим будущим пониманием задачи. Это шаблон Задания, то есть приложения к нашему договору. В нём — вот такие разделы:

1. Цели и функции.
2. Элементы дизайна и функциональность.
3. Стоимость.
4. Этапы и сроки.
5. Технические требования.
6. Принципы совместной работы.

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

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

Пример первого абзаца из материалов школы:

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

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

Один из примеров первых двух абзацев, который был в киевской лекции:

Компания ‹…› 10 лет занимается промышленным альпинизмом, участвует в крупных строительных работах по всей России.

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

• что мы умеем делать;
• что мы уже сделали.

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

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

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

Здесь мы просто в назывном порядке перечисляем, что именно входит в проект из того, что мы нафантазировали в предыдущем разделе (а что — не входит). Если причина выбора определённой функциональности для первой итерации неочевидна, можно добавить короткое обоснование: «чтобы на защите сделать то-то, в первой версии реализуем сё-то».

Стоимость — этот раздел нужно убрать.

Этапы и сроки — надо всё заполнить в соответствии с планом третьей ступени. Тут почему-то иногда студенты ломают вёрстку таблицы, всё куда-то съезжает или вдруг появляются рамки. Пожалуйста, не ломайте!

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

Принципы совместной работы — это как раз «Организация работы» из лекции. Здесь надо внести минимум изменений в стандартный бюрошный текст так, чтобы это имело смысл для дипломного проекта. Там поменяются роли, уйдут оговорки о том, в каком случае бюро не несёт ответственности перед клиентом. Когда вы пришлёте мне первую версию понимания задачи, я обязательно спрошу у вас, что вы здесь поменяли. Рекомендую прям выделить жёлтеньким изменённые формулировки, чтобы я сразу это увидел.

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

Ну и приходите к нам учиться.