Мастер-класс Николая Товеровского о понимании задачи и плане проекта

• Приветствие участников.  

• Объяснение формата стрима: одновременная трансляция в Telegram и Zoom.  

• Представление Николая Таверовского и темы мастер-класса: понимание задачи.  

• Приглашение участников присылать свои понимания задач в чаты.  

• Фокус на основной части понимания задачи: полезное действие или модель решения.  

• Информация о новом потоке в школе бюро и минимальной стоимости участия.  

• Условия участия в конкурсе на бесплатное место.  

• Анонс других мастер-классов и курсов.  

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

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

• Важность написания и утверждения понимания задачи.  

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

• Критика армейского подхода, при котором исполнитель не понимает задачу.  

• Преимущества подхода, при котором исполнитель понимает задачу и обсуждает её с клиентом.  

• Пример с врачом и пациентом иллюстрирует важность обсуждения и понимания задачи.  

• Отсутствие понимания задачи может привести к неудаче проекта.  

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

• Разработчик должен написать спецификацию, отражающую понимание задачи.  

• Понимание задачи состоит из ядра — формулировки полезного действия и способа его достижения.  

• Полезное действие должно быть явно названо, а не обещано.  

• Необходимо объяснить механизм достижения результата.  

• Формулировка «разработать образовательный портал» не отражает реального понимания задачи.  

• Важно указать, кому нужен портал, какую проблему он решает и почему.  

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

• Если задача начинается со слова «сделать», это признак отсутствия понимания.  

• Лайфхак: начинать с фразы «помочь кому-то с чем-то» для объяснения пользы.  

• Заказчик часто не чётко формулирует конечный результат.  

• Исполнитель должен задавать вопросы, чтобы лучше понять задачу.  

• Вопросы помогают выявить недостатки в идее заказчика.  

• Пример структуры ТЗ: место для полезного действия, перечисление артефактов, указание, что точно не будет.  

• Шаблон ТЗ должен быть простым и понятным, без сложных диаграмм Ганта.  

• Важно чётко указать, что будет и чего точно не будет в результате работы.  

• Нефтяник из Тюмени покупает галстуки Versace, но не знает, какие именно.  

• Продавец спокойно вешает галстуки на руку, а на кассе удивляется выбору клиента.  

• Аналогично, можно придумать много идей, но важно чётко формулировать, что будет реализовано в текущую итерацию.  

• FFF — это подход к совместной работе, описанный юридическим языком.  

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

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

• Техническое задание должно включать описание полезного действия и его реализации.  

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

• Пример с заметкой о хобби сотрудника иллюстрирует необходимость чёткого понимания задачи.  

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

• Необходимо определить, кому будет полезна статья и как она поможет аудитории.  

• Отсутствие чёткого понимания задачи может привести к некачественному результату.  

• Заказчик требует оперативную графику, но внутренние разработки часто не используются после ухода заказчика.  

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

• Расточительство — бросать проекты или продукты после одного клиента.  

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

• Проекты и продукты следует рассматривать как SaaS-сервисы.  

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

• Технология «Карандашик» изначально создавалась для работы с книгами.  

• Изначально она была одноразовым решением, но со временем стала использоваться шире.  

• Пример показывает, как правильно развивать продукты, избегая «раковой опухоли» ненужных функций.  

• Максим приветствует участников и объявляет тему обсуждения: разбор формулировок задач дипломных проектов студентов прошлых потоков.  

• Студенты на третьей ступени школы бюро выполняют полноценный проект, который длится шесть недель.  

• Проект включает теорию, практику и прокачку навыков, а также участие арт-директора бюро.  

• Примеры проектов: лофт-огород, подставки для цветов, продаваемые на Ozon.  

• Студенты занимаются столяркой и другими видами деятельности.  

• Команды сами выбирают задачи для своих проектов.  

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

• Формулировки полезного действия часто основаны на страстях и желаниях людей.  

• Пример: помощь людям интересно провести время в Кишинёве.  

• Описание проекта: независимый журнал о студентах школы с системой передачи власти главреда.  

• Полезное действие: помощь читателям перенять профессиональный опыт героев интервью.  

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

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

• Уровни профессионализма: базовый уровень — грамотное построение ожиданий клиента, более высокий уровень — умение предугадывать потребности клиента.  

• Опасности: риск ошибиться и не попасть в пользу клиента.  

• Пример работы с клиентом: создание готового к продакшн макета в WordPress.  

• Последствия ошибок: конфликт с арт-директором и возможные последствия для стажёра.  

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

• Рекомендация начинать с базовых навыков и постепенно переходить к более сложным приёмам.  

• Формирование понимания задачи необходимо для любых задач, даже самых маленьких.  

• Пример с покупкой хлеба иллюстрирует важность уточнения деталей: какой хлеб, к какому времени, сколько.  

• Даже в микрозадачках нужно задавать вопросы: «А если того хлеба не будет? А если только зерновой есть, а какого-нибудь хоккайда нет, что тогда?»  

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

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

• Внутри проекта ответы на многие вопросы должны быть уже известны.  

• У директора Васи Паловнева есть шаблон спецификации с тремя полями: «Что», «Зачем», «Кому сдавать».  

• Эти поля помогают сформулировать задачу и понять её контекст.  

• Исполнитель должен относиться к задаче как к данности, а не как к роботу.  

• Минимальные поля для понимания задачи: «Что сделать», «Зачем», «Почему», «Кому сдавать».  

• Этих полей достаточно для минимального понимания задачи для разработчика.  

• Благодарность за вопросы и участие.  

• Анонс записи мастер-класса и обещание выложить её в течение недели.  

• Сюрприз: возврат 30% скидки на курс до 18 февраля с помощью промокода.  

• Промокод придёт на почту.  

• Благодарность за вопросы и участие.  

• Приглашение на курс или в школы.  

• Прощание.