Конспекты к итоговому занятию.
«От проекта к делу».
Руководим разработкой и реализацией проекта
Роль планирования в жизненном цикле проекта
Мы с вами поговорим о том, как планировать работу проекта. Давайте вернемся к схеме жизненного цикла проекта.
На втором этапе мы зафиксировали планирование и формулирование того образа результата, которого мы хотим достичь. А в этом модуле мы поговорим про продуктовый результат:
Также мы обсудим образовательный результат: как заложить в работу проекта то, что вы хотите в образовательном плане получить на выходе.
Поговорим про то, как создать программу достижения результата. Для начала нам надо определиться, что такое результат. Мы уже говорили о том, что детско-взрослый проект включает в себя образовательный и продуктовый результаты. Про образовательный результат мы поговорим в конце недели, а начнем с результата продуктового.
Продуктовый результат
Самое простое понимание продуктового результата — это некоторый конечный осязаемый продукт, который в итоге должен получиться. Однако это достаточно упрощенное понимание, это по сути это только образ результата, идеализированное видение его. Результатом проекта может быть не то, что появилось какое-то итоговое финальное изделие, результатом может быть то, что целевая система просто продвинулась по своему жизненному циклу.
Например, на старте проекта у нас был лишь замысел нового беспилотного конвертоплана, а в результате проекта замысел трансформировался в набор 3d-моделей общих видов и сопутствующую документацию (аванпроект/техническое предложение). Разработка такого пакета документов может и быть конечной целью отдельно взятого проекта. Команда не получила готовый конвертоплан (конечный продукт), но продвинула его по жизненному циклу.
Может быть и так, что за время одного проекта целевая система, с которой работает команда, пройдет сразу несколько стадий своего жизненного цикла.
В зависимости от вида проекта конечный результат может быть исследовательским, инженерным или художественным. Когда мы говорим не про инженерный проект, а про художественный или научный, то все равно логика жизненного цикла, целевых и окружающих систем сохраняется. Целевой системой в арт-проекте может быть художественное произведение, в научном — экспериментальная установка, на которой проводится исследование и т. д.
Рис. 1. У разных видов технических систем — разные виды жизненного цикла, состоящие из разных стадий.
1
SEMAT
Метамодель Software Engineering Method and Theory (SEMAT)1 — методы и теория программной/системной инженерии (Айвар Джейкобсон). Она была разработана, чтобы обобщить все возможные методологии разработки программного обеспечения, а в дальнейшем оказалось, что она успешно переносится и на методологии разработки «хардверных» инженерных проектов, притом любого масштаба — от гаджетов до подводных лодок, атомных электростанций и космических зондов.
Рис. 2. Схема инженерного проекта из метамодели SEMAT.
Мы будем рассматривать самую простую часть метамодели SEMAT — схему инженерного проекта. В схеме есть три главных области интересов: потребитель (customer), решение (solution) и усилия (endeavour). Внутри этих областей прописаны те аспекты проекта, к которым надо проявлять особое внимание, чтобы он шел успешно. В метамодели они называются называются
«альфами» (ALPHA), и это слово является аббревиатурой фразы Abstract Level Progress and Health Attribute. Она раскрывает смысл этого понятия, «альф» — это показатели прогресса и здоровья вашего проекта, выраженные на максимально обобщенном уровне.
A — Abstract
L — Level
P — Progress
H — Health
A — Attribute
1 Более подробное ознакомление с метамоделью можно начать с краткого руководства
2
3
В базовой версии SEMAT «альф» выделяют семь штук, и они точно присутствуют в каждом проекте:
Стейкхолдеры (stakeholders) — все, кто каким-то образом вовлечен в проблемную ситуацию, вокруг которой возник проект. Либо они на нее влияют, либо она влияет на них, и если вокруг этой ситуации будет создаваться решения, то оно также будет подвержено влиянию или само будет влиять на стейкхолдеров. Типичные примеры стейкхолдеров: пользователи решения, клиенты/заказчики, приобретающие его, ремонтники, обслуживающие решение в ходе эксплуатации, наладчики, которые его запускают в эксплуатацию. В каждой отдельной проектной ситуации набор стейкхолдеров будет свой и задача проектантов — не упустить из внимания тех, кто существенно влияет на успех проекта.
Проблемная ситуация (opportunity, дословно — возможность) — та ситуация в жизни, вокруг которой и возник проект. Для кого-то из стейкхолдеров она может являться проблемой, для проектной команды же любая такая ситуация является возможностью создать решение для этой проблемы.
Техническая система (в оригинале software system — программная система, однако по смыслу обобщается до любой технической системы): то решение, которое проектная команда предполагает реализовать для того, чтобы трансформировать проблемную ситуацию ко всеобщей пользе.
Требования (requirements) — то, какой должна быть система, чтобы правда соответствовать проблемной ситуации. Требования к системе не берутся напрямую от стейкхолдеров: до определенного момента они и вовсе могут не знать, что кто-то вознамерился реализовать для них какое-то решение. Проектной команде необходимо цели, интересы и ограничения стейкхолдеров переводить в требования к конкретной системе, которую команда реализует. Помимо стейкхолдеров-пользователей, существует большое количество других источников требований: смежные технические системы, с которыми нужно устанавливать интерфейсы, стейкхолдеры- регуляторы, регламентирующие и ограничивающие создание тех или иных категорий технических систем, и множество других.
Команда (team), которая производит решение — все множество людей и организаций, вовлеченных в создание решения. В зависимости от масштаба решения, это может быть как одна проектная группа, разрабатывающая какой-нибудь программный продукт, так и сотни смежных предприятий, которые все вместе строят самолет или электростанцию.
Работа (work) — та деятельность, которую выполняет команда, чтобы решение появилось в соответствии с требованиями. Эта альфа посвящена планированию, бюджетированию, управлению рисками и собственно выполнению работ.
Технология работы (way of working) — те инструменты и методы, которые используют команды, чтобы выполнять работы.
Выводы
Продуктовый результат — не обязательно сам конечный продукт, это может быть и продвижение целевой системы с одной стадии жизненного цикла на другую.
4
У каждого проекта есть «альфы» — зоны особого внимания.
Если не уделять внимания какой-либо зоне, в проекте начнут появляться неопределенности, влекущие за собой риски. Риски же могут реализоваться в виде проблем, которые могут проект задержать или вовсе сорвать.
Всякая техническая система или продукт, о которых мы сейчас будем говорить, представляет собой единство двух составляющих:
Их можно изобразить как «гамбургерную» диаграмму:
Функция — это тот полезный эффект, который система предоставляет тем, кто ей пользуется. Конструкция — это то, за счет чего система становится способна предоставлять полезный эффект.
Пример: такси. Его функцией будет перемещение пассажира по городу с предсказуемой скоростью из точки А в точку Б. Какие существуют альтернативные решения для выполнения данной функции? Например, автомобиль, велосипед, мотоцикл, общественный транспорт.
Когда система уже реализована, функция и конструкция неделимы. Однако когда мы ее проектируем, мы можем задуматься о том, какая конструкция будет оптимальной для выполнения той или иной функции. Обычно это изображают как некое разветвление возможных вариантов:
Задача команды, которая воплощает проект: найти, какое из предложенных решений будет оптимально соответствовать потребностям всех вовлеченных сторон. Идеальный конечный результат — это когда функция выполняется, а конструкция, которая ее обеспечивает, каким-то образом растворена в среде.
Итак, мы разобрали, что такое функция и конструкция, интерфейсы между функциональными элементами, теперь давайте посмотрим, как система выглядит снаружи. Понятно, что кто-то пользуется системой, и кем-то пользуется она. Существует стандарт ИСО 15288, который показывает, как управлять созданием схожих технических систем: все системы друг с другом могут находиться в следующих отношениях:
Пример: самолет, это средний «этаж» (целевая система). Когда авиаконструктор занимается проектированием самолета, он видит эту систему как целевую. Если мы начинаем разрабатывать
двигатель самолета, то он становится для нас целевой системой. Окружение целевой системы: те, кто пользуется самолетом (авиакомпания), это использующая система. В свою очередь, самолету нужна взлетная полоса, диспетчерская вышка и т. д. Все эти системы — обеспечивающие.
Пассажирские трапы, автобусы — от них самолет не зависит, но должен с ними взаимодействовать, это «системы в операционном окружении».
Таким образом, самолет должен иметь интерфейс, совместимый с операционным окружением и с теми системами, которые он использует. Использующая система накладывает на него какие-то свои требования. Такое соотношение позволяет нам понять, где границы той системы, которой мы занимаемся, а где находится все остальное.
Обеспечивающие системы
Пример
Проблема: учителю трудно составлять индивидуальные расписания для детей (надо держать в голове пожелания преподавателей и возможности детей)
Решение: приложение для составления расписания
Вопрос: кто будет обеспечивать поддержку этого приложения?
Обращайте внимание на то, что участники проекта сами часто включают в себя в обеспечивающую систему проекта, не учитывая, что закончат школу/проектную деятельность, и приложение/проект некому будет поддерживать.
Стейкхолдер (от англ. stake — ставка, интерес) — это всякие лицо, вовлеченное в проблемную ситуацию. Это может быть юридическое лицо (организация), физическое лицо (отдельный человек). Бывает, что проблемная ситуация влияет на этого человека, а бывает, что ситуация подвергается влиянию от этого человека/организации.
Важно понимать, что стейкхолдер — это роль, в которой могут быть человек или организация, состоящая в наличии у этой роли интереса к системе, в том числе к ее функционированию или конструкции, назначению, продукту, обладанию системой какими-либо характеристиками.
У стейкхолдеров есть присущие им цели, интересы, ограничения:
Зачем нам анализировать стейкхолдеров? Если мы наживем себе влиятельных врагов, они могут заблокировать наш проект, использование нашей системы и т.п.
Рассмотрим наиболее действенные методы анализа стейкхолдеров:
(регуляторы — ими могут быть гос-е органы; держатели места внедрения)
горизонтали (либо человек «за», либо «против»). Карта строится для какой-то ситуации, когда происходит выбор. Мы либо пытаемся переманить на нашу сторону тех, кто против, либо стараемся снизить их уровень влияния.
Всякий стейкхолдер-анализ делается для разных ситуаций. Вы можете один и тот же инструмент применить несколько раз, на разных этапах внедрения системы, до ее внедрения, после или в процессе.
История про стейкхолдеров
Одна из наших школьных команд нашла проблему: большие очереди в столовой. Ребята решили повесить камеру, сделать специальную страничку, чтоб каждый желающий мог зайти, посмотреть и решить, когда пойти кушать. Проект поддержали, выделили деньги на камеру, сделали страничку и уже все было готово к внедрению, но тут к ним пришел замдиректора
по безопасности и закрыл проект. Оказывается, следить за происходящим в школе запрещено, только если это не происходит внутри самой школы, то есть на собственном сервере,
а не на внешнем сайте.
Важно учитывать всех стейкхолдеров, потому что они могут не знать о требованиях друг друга.
С течением времени вокруг нашей системы появляются новые стейкхолдеры, исчезают старые. Как сделать так, чтобы ничего не забыть и учесть все требования? Для этого есть такой подход как управление жизненным циклом проекта.
Жизненный цикл системы — это все то время, которое проходит от ее замысла до ее забвения. Там нет зацикленности, но такое название просто сложилось (как в биологии, когда говорят о жизненном цикле животных).
Стадия жизненного цикла системы — это какой-то период, в течение которого с ней работает определенный набор стейкхолдеров, под обеспечением какого-то определенного набора систем.
Как это визуализируют? Рисуют временную линию, на которой ставят засечки (границы между стадиями). Стадии должны как-то называться:
П И Т Э
П — проектирование системы И — изготовление системы
Т — тестирование системы Э — эксплуатация системы
Важно понимать, что у разных видов систем будут разные стадии. Есть типичные жизненные циклы, которые используют как эталон, на который можно опираться. Одна из таких моделей называется V-модель:
замысел эксплуатация утилизация
сбор требований
приемка
(соответствует ли система требованиям)
архитектурное проектирование (как именно будет
устроена наша система)
опирается на
интеграция
рабочее проектирование
изготовление
Это некий типовой цикл, а как же нам работать, если система в этот типовой цикл никак не укладывается? В таком случае нам необходимо пользоваться следующим приемом: стадия жизненного цикла целевой системы меняется в тот момент, когда меняется набор обеспечивающих ее систем. Давайте попробуем это проиллюстрировать:
Целевая система
Замысел
Проектирование
Изготовление
Приемка
Эксплуатация
Утилизация
Обеспечивает изготовление
эксплуатация
Обеспечивает проектирование
Обеспечивает эксплуатацию
эксплуатация
эксплуатация
Таким образом, у нашей целевой системы на каждой стадии есть кто-то, кто используется, чтобы обеспечить ее жизнь. Команда тоже является обеспечивающей системой. Предметом нашего детско-взрослого проекта является совокупность стадий Проектирование — Изготовление — Приемка. Кроме того, когда проект закончится, жизнь системы продолжится, поэтому надо понимать, кто будет заниматься системой после нас. Это важно запланировать заранее.
Пример жизненного цикла системы (стадия эксплуатации)
Проблема: много ребят учится дистанционно, школе нужна платформа для онлайн-обучения. Решение: кастомизация существующей платформы с открытым кодом.
Мы приехали на приемку проекта, куда был также приглашен учитель. Вдруг оказалось, что учитель впервые видит данную систему и не знал об этой работе. Проблема, когда ученики делают проект и думают о пользователях, но забывают о тех, кто обеспечивает функционал системы, встречается довольно часто.
Мы разобрались, кто такие стейкхолдеры, понимаем, в каком окружении система (кому нужна она, а кто нужен ей), знаем о разных стадиях жизненного цикла проекта. Теперь надо расписать требования к системе, таким образом спланировав продуктовый результат.
Что такое требование? Кто-то называет эту дисциплину «инженерия требований», а кто-то —
«управлением требованиями». Требование — это не просто техническое задание (ТЗ), не только
«user story» по шаблону и т.д. Так какие должны быть требования к требованиям?
Из чего же состоит требование? Давайте рассмотрим схему, которая приведена в книге, которую я вам рекомендую к прочтению («Alexander, Ian (Ian F.). Discovering requirements: how to specify products and services»).
На схеме видно, что требование окружено большим количеством сопутствующей информации.
Само требование может быть функцией (полезной работой, которую выполняет система для пользователя), характеристикой (качество системы) или ограничением (накладываются на систему).
Требования должны быть описаны понятным словарем, в котором содержатся определения всех слов, которые используются. Обоснование требований: есть стейкхолдер с какими-то целями, есть контекст, в котором эти требования будут использоваться; достигая своей цели в этом контексте, стейкхолдер пошагово будет идти по какому-то сценарию. Таким образом, система будет обеспечивать этот сценарий.
Что еще важно: у нас должны быть приоритеты этих требований (что в первую очередь реализовывать, а что можно отложить?). Требования проистекают также от окружения, в котором эта система используется.
Все это в совокупности дает нам качественно сформулированное требование.
Существует цикл работы с требованиями, который состоит из нескольких шагов:
Обнаруживаем требования → документируем → проверяем, все ли мы поняли (валидация)→ отдаем требования в разработку
Источники требований:
Пример инженерных развилок: выбор топлива для ракет SpaceX. Изначально планировалось, что это будет водородно-кислородная смесь, но оказалось, что с таким топливом двигатель быстро приходит в негодность. Пришлось выбрать смесь метана и кислорода — это и была развилка, которую пришлось пройти, проанализировав различные виды топлива.
Мы поговорили об источниках требований, а теперь посмотрим, как их документировать. Проблема: учет рабочего времени учителя
Решение: аналитическое приложение для учителя
Команда сделала бумажный прототип и попросила его протестировать учителя школы. Оказалось, что учителю важно понимать, куда уходит время во время урока (ДЗ, объяснения новой темы
и т. д.). Что же произошло? Сначала требования собрали среди пользователей в школе, затем, когда появился прототип, возникли требования, которые дополнили предыдущие.
Мы научились выявлять требования, у нас масса источников, они откуда-то приходят. Возникает потребность их как-то задокументировать. Что должно быть в документе требований к системе? В нашем случае хватит списка с пояснениями:
прохождения по сценарию могут быть еще какие-то необходимые характеристики, например, по производительности, по удобству использования. Это тоже надо где-то фиксировать. Также у нас могут быть какие-то неявные допущения, поэтому хорошо просмотреть какой-то наш набор утверждений и проверить, нет ли среди них каких-то неявных смыслов.
происхождение которых мы не можем проследить. Поэтому мы прописываем: это является сценарием по обеспечению такой-то цели или такого-то стейкхолдера.
оно или нет, важно ли это требование (должно реализовываться в первую очередь или может подождать).
После того как мы задокументировали требования, хорошо бы проверить, соответствуют ли они реальным, фактическим потребностям наших стейкхолдеров. Для этого существует несколько методов:
нашей системой, а ты ее пользователем, давайте пройдемся по этим сценариям». Возможна еще такая роль как «человек-вдруг», который спрашивает: «А что, если? А вдруг…?». В ходе такого процесса выявляется масса разных пробелов.
«Можешь ли ты достичь той цели, которая заявлена?». На этой стадии приходится доделывать огромную часть работы.
Таким образом, если у нас есть полный набор валидированных, задокументированных прозрачных требований, если мы знаем все про стейкхолдеров и про то, как в жизненном цикле они проявляются в нашей системе, с чем она взаимодействует по интерфейсам и т.д., мы все понимаем про наш продукт. Но мы все еще не понимаем как, когда и за какие сроки
и в какой бюджет мы будем укладываться, чтобы это воплотить и где нам найти необходимые ресурсы. Про это мы будем говорить в следующем разделе.
Валидация требований
Рассмотрим пример одного из способов валидации требований. На тренинге мы дали ребятам задание сыграть две сценки.
Сценка 1: как сейчас живет ваш пользователь, когда у него существует проблема? Сценка 2: как в будущем будет жить ваш пользователь, когда проблемы не станет?
Также мы ввели персонажа «вдруг». Модератор мог в любой момент войти в кадр и сделать что-то, чтобы ситуация изменилась.
Вот одна из таких сценок. Учитель стоит у доски и что-то пишет, скучно рассказывая материал,
а на заднем плане засыпает ученик. Сценка о том, как будет в будущем: учитель стоит у доски, что-то пишет, а на заднем плане засыпает ученик. После урока ученик выходит из класса
и нажимает кнопку «dislike», который приходит учителю на телефон. Казалось бы, проблема
решена: учитель получил обратную связь о своем уроке. Но ведь учитель может по-разному трактовать подобное замечание. Например: «Наверное, было мало формул и теории!»,
«В каком из восьми классов я сделала что-то не так? Придется усилить программу во всех!». Тогда ребята поняли, что необходимо уточнить обратную связь.
У данного способа есть ограничения: модератор сам должен очень хорошо понимать, что
именно может пойти не так.
У нас есть понимание того, какой продуктовый результат мы хотим получить. Необходимо претворить это понимание в программу конкретных действий: какие задачи мы будем решать, какими ресурсами эти задачи должны быть обеспечены и т. д.
Для начала определим, какие задачи нам надо делать. Этот критерий обычно называется целью: конечный результат, эффект деятельности, на достижение которого направлен результат. Цель необходимо сформулировать так, чтобы все участники команды ее понимали и разделяли.
Цели бывают только у сущностей, обладающих субъектностью (умеют думать, рефлексировать, принимать решения).
Уровни целей
Когда мы формулируем цель, нам необходимо придерживаться определенного набора критериев.
Критерии SMART
S — specific (конкретная)
M — measurable (измеримая)
A — attainable/achievable (достижимая)
R — relevant/realistic (реалистичная)
T — time-bound (привязанная ко времени)
Применение критериев SMART
Уже сформулировали цель, проверяем ее по критериям
Подбираем формулировку из множества вариантов, так, чтобы соответствовать критериям
Зачем нужно целеполагать?
к каким-то дедлайнам. В результате мы можем переходить к разбиению нашей цели на какие-то задачи
| Команда | Человек | Вопрос |
Стратегический | Миссия | Мировоззрение, предназначение | Зачем все? |
Тактический | Цель | Достижение | Чего мы хотим достичь на этом этапе? |
Операционный | Задача | Дело | Что нужно сделать, чтобы достичь цели? |
История о работе с критериями SMART
В программе «Школа IT-решений» процесс построен так:
Однажды к нам пришла команда с очень понятной проблемой — тяжелые рюкзаки. Но когда ребята в мастерской проверяли свою идею, в том числе по критериям SMART, оказалось, что они не в их силах ее реализовать за такой короткий срок: нужно много ресурсов, существует много ограничений и т. д. Команда огорчилась, но мы предложили им взять еще неделю для того, чтобы провести исследования и найти другую школьную проблему.
Мы могли бы сгладить какие-то углы, позволить ребятам делать этот проект. Но тогда могло получиться так, что через пару месяцев команда бы потеряла веру в проект, в себя и в то, что они вообще могут сделать что-нибудь настоящее. Критерии SMART помогают разговаривать
с ребятами без каких-либо личных оценок их проектов.
Когда у вас поставлена цель проекта, она измерима и привязана ко времени, и хочется начать планировать свою работу. Проблема в том, что мы не можем начать планировать до того,
как поймем, как будем организовывать свою работу.
Жизненный цикл проекта — это то, как организованы во времени практики работы команды
(разработка, проектирование, эксперименты).
Жизненный цикл проекта — это совсем не то же самое, что жизненный цикл продукта. Есть различные метода разработки, которые по-разному смотрят на практики жизненного цикла проекта. Надо помнить, что есть фазы (стадии) жизни системы и есть практики работы, и все эти циклы по-разному с этим работают.
Виды жизненных циклов:
1. Waterfall (каскадный)
Был неверно понят из исходной статьи Winston W. Royce, который говорил о необходимости работать итеративно.
Создание фазы работы над системой, которая будет состоять только из одной практики: в один период вы занимаетесь только разработкой, до этого вы занимаетесь только проектированием, до этого собираете требования.
Это не самый лучший метод: большинство проектов, которые делаются по данному методу, либо не укладываются в сроки, либо не укладываются в бюджет.
2. Spiral (спиральный)
Автор: Барри Боэм (Barry Boehm) модифицировал каскадную модель: разделил практики деятельности и стадии жизни системы. Есть одна фаза концептуального проектирования, фаза разработки системы, ее совершенствования, расширения, фазы эксплуатации. На всех этих фазах применяются одни и те же практики (общение с заказчиками, планирование, анализ рисков и т. д).
3. Incremental (итеративный/инкрементальный)
Применялся еще до каскадного и спирального процессов.
4. Agile (гибкий)
Большое количество разных методов.
Включают в себя лучшие части всех методов:
Что же выбрать?
В реальном проекте необходимо индивидуально подбирать практики работы, наиболее подходящие по ситуации (ситуационная инженерия требований).
Прежде чем что-то планировать, надо разделить задачи на небольшие подзадачи. Для этого мы обычно используем метод под названием User Story Mapping. Рассмотрим этот метод на примере проекта «Система для координации волонтеров в школе». Этот проект можно представить в виде облака, «Системы», но как из этой системы вытащить какие-то задачи и начать планирование, пока совсем непонятно. Метод User Story Mapping как раз позволит разбить путь пользователя на маленькие шаги.
Проще всего объяснять это на примере поисковика: давайте представим, что мы с вами
пользователи поисковой системы, и нам надо наш пользовательский путь разбить на маленькие шаги. При этом мы точно знаем, что мы хотим от поисковика как пользователи: найти информацию в Интернете. Какие мы предпримем шаги?
Дальше мы прописываем каждому шагу наши пользовательские требования:
3. При переходе на сайт я хочу, чтобы:
- …
4. На странице поисковика:
5. На странице результатов поиска:
6. На странице результатов поиска:
7. При переходе на результаты поиска:
- …
8. На странице результатов поиска:
- результат открывается на новой странице
Теперь нам нужно приоритизировать эти требования к 8 шагам. Например, нам очень важно, чтобы адрес был коротким, но не очень важно, чтобы название сайта соответствовало теме нашего поиска. Или нам важно, чтобы переход осуществлялся быстро, но ничего не будем делать с рекламой. Когда мы выстраиваем требования, у нас появляется план, потому что из каждого требования может появиться задача. Все основные требования на языке Agile и будут называться backlog, который мы будем помещать в первую колонку нашей доски.
Таким образом, backlog — это список приоритетных задач, которые нам нужно выполнить в рамках первой итерации нашего проекта. Чтобы планировать работу в рамках итераций, используют kanban-доску, которую можно нарисовать на школьной доске, на специальной белой доске маркером, на ватмане. Главное, чтобы доска была достаточно большой. Обычно на kanban- доске три колонки, но мы нарисуем еще четвертую, опциональную, назовем ее «backlog» (список наших задач). Такой список может делиться на релизы R1, R2 … Например, стикеры с задачами Б, Г, В, которые наиболее важны, находятся на R1, а менее приоритетные задачи располагаются на R2. Эти буквы на стикерах здесь для наглядности, при работе с проектами пишите на стикерах сами задачи, например, «Разработать главную страницу».
Первая колонка таблицы «To Do» («То, что мы сейчас будем делать»).
Вторая колонка «In Progress» («То, что мы уже начали делать»). Третья колонка «Done» («То, что мы уже сделали»)
Берем приоритетные задачи и располагаем в колонке «To Do». Далее команда решает, что и кто, в каком порядке будет делать. Потихоньку стикеры будут перемещаться из одной колонки
в другую.
После первого релиза мы решаем, правильно ли мы распределили оставшиеся задачи. Может,
что-то менее важно? Перемещаем это в R3. А что-то новое и важное мы, наоборот, добавляем в R2.
Также удобно проводить на доске горизонтальные линии. Например, в первой части вы занимаетесь разработкой buckend, а строкой ниже идет frontend. Таким образом, люди, которые в вашей команде выполняют разные функции, не будут залезать в поле деятельности других, но при этом понятно, кто за что отвечает. Смысл этих горизонтальных линий может быть каким угодно.
Также kanban-доску можно дробить на большее количество колонок. Например, вы сначала рисуете что-то, потом макетируете, потом реализуете в форме каких-то готовых изделий, а потом проверяете на прочность — значит, у вас будет пять колонок. Главное, чтобы ваша доска с чего-то начиналась и чем-то заканчивалась.
Вы понимаете, какие задачи вам нужно выполнить в проекте, чтобы достичь своей цели. Важно также учесть, какие вам необходимы для этого ресурсы.
Ресурсы бывают двух видов:
Неправильно будет сказать, что у нас есть бюджет, на который мы все купим: навыки, репутацию купить невозможно.
Покупать или «доставать»? Если мы что-то не можем купить, то мы находим кого-то, у кого мы можем это позаимствовать так, чтобы он не остался в накладе. Хорошо, когда эти ресурсодержатели заинтересованы в нашем проекте, в его результате, то есть являются стейкхолдерами. Таким образом, процесс «доставания» — это процесс заинтересовывания этих людей. В этом нам поможет реестр ресурсов (райдер):
В ней можно вести как учет материальных, так и нематериальных ресурсов. Другая полезная таблица — «Дефициты навыков» («вакансии):
Сначала мы смотрим на весь список задач по проекту, затем смотрим, какие для этого понадобятся навыки. Если каких-то навыков не хватает, мы начинаем выписывать их в таблицу. Таким образом у нас получается план учебной работы в рамках проекта.
Когда у нас есть план по ресурсам и навыкам, мы готовы приступать к работе над проектом.
История про планирование ресурсов
Проект «Автоматизация школьной библиотеки»: возможность брать книги в библиотеке
с помощью сканирования штрих-кодов. Для того, чтобы проект заработал, необходимо было оприходовать все книги в школьной библиотеке. Мы спросили у ребят, какие они видят ограничения для того, чтобы закончить свой проект. Когда они сказали, что справятся за пару недель, мы предложили им подсчитать: сколько старых книг в библиотеке, сколько времени тратится на оприходование каждой книги, сколько времени в день готовы работать помощники.
Ресурс | Когда нужен | У кого есть | Как связаться | Как уговорить |
| | | | |
| | | | |
| | | | |
Навык | Когда нужен | Кто изучит | Как изучить | Зачем нужен |
| | | | |
| | | | |
| | | | |
У вас все готово для проекта: цели определены, задачи поставлены, план по ресурсам готов.
Но все равно в команде сохраняется какая-то нервозность. Это нормальная ситуация. Страх и тревога — это неотрефлексированные риски. Это индикатор, который говорит о том, что внутри проекта существуют еще зоны некой неопределенности.
Риск — это абстрактное понятие, которое начали изучать в 20-2 гг. XX века.
Есть такое явление как «событие риска» (то нежелательное, что может наступить), событие это вероятностное (может наступить или не наступить), приводит к нежелательным последствиям (вещам, которые несут ущерб для проекта, организации). Этот ущерб можно измерить в каких-то натуральных единицах (деньги, время). Вероятности событий и потерь раздельные: событие может произойти, а последствие не произойти, и наоборот. Это связано с тем, что у событий и последствий есть свои причины, «драйверы». Можно отдельно влиять на «драйверы» причин, отдельно — на драйверы «последствий».
Риски бывают:
Типичные риски, про которые уже известно в теории, про них написаны учебники; их уже не называют рисками
Все, что свойственно только отдельно взятому конкретному проекту, что не опишешь в учебнике
Шаги по управлению рисками:
Что можно сделать, когда мы планируем меры по работе с рисками? Есть две категории мер:
Меры по работе с рисками:
Как получить образовательный результат? Через осознание и присвоение опыта.
Смысл проектов с образовательной точки зрения — создание безопасной среды, в которой можно совершать ошибки и набираться опыта.
Рефлексия — процесс присваивания, «переваривания» опыта; обращение человеком своего внимания на свое (или чужое) мышление и поведение, на приобретенные знания и совершенные поступки, понимание и анализ своих мыслей, чувств и мотивов.
Виды рефлексии:
Важно: Рефлексия всегда связана с действием, которое поддерживает и уточняет. Если мы делаем что-то без рефлексии, то получается что-то необдуманное. Другой вариант, если мы только рефлексируем, не поддерживаем размышления конкретными делами, то происходит зацикливание на себе без какого-либо развития.
С точки зрения работы наставника надо помнить, что рефлексия должна быть запланирована заранее, на нее должно быть выделено время.
Что можно осознавать?
возникали конфликты, как мы могли бы их по-другому разрешить
Как создать безопасную среду, в которой можно ошибаться и получать из этого опыт? Всегда ли стоит команде избегать негативного опыта?
Существует так называемый метод контролируемого облома (quick fails), когда мы даем команде
«обжечься» в естественной ситуации и создаем запрос на получение знания (как не «обжигаться» в следующий раз?).
Естественные ловушки:
Как проводить рефлексию? Чтобы дойти до каких-то методов рефлексии, сперва надо ее запланировать. Существуют различные методы проведения рефлексии. Разберем каждый из них:
Метод «3 вопроса»
Этот метод можно проводить:
Поиск корневых причин
Выявление факторов, которые привели к чему-то желательному или нежелательному. Какие факторы, на которые мы могли бы повлиять сейчас или в будущем, приводят к тому, что появляется что-то, чего нам не подходит? Как нам это предотвратить? Главное: как сделать так, чтобы это не повторилось? Здесь недопустимо переходить на личности, надо анализировать другие вещи, которые можно представить в виде пирамиды:
делать так-то и так-то, потому что вот это правильно»). Возможно появление конфликтов, которые
необходимо предотвращать, например, просить человека проявить уважение к чему-то значимому для других, несмотря на свои убеждения. Надо найти ценности, которые важны человеку, через них выразить то, что важно для других.
Этот метод требует достаточно длительного обсуждения.
Какой еще есть хороший метод, чтобы разговорить ребят в команде?
Можно сказать: «Если представить проект как компьютерную игру, в которой вы сохранились в начале проекта, как бы вы теперь этот уровень проходили? Что бы вы поменяли?». Или «Если бы у вас была машина времени, и вы могли бы переместиться в прошлое, в начало проекта, что бы вы себе сказали?».
Всеми этими методами мы находим кусочки опыта, разбираемся, какие можем сделать выводы, какую успешную стратегию можем выработать на основе проведенной рефлексии.
Как же показать школьным командам самостоятельную ценность их опыта, независимо от того,
успешно ли они реализовали свой проект? Мы приезжаем в школу, где ученики рассказывают нам, как они реализовали свой проект, какие ресурсы затратили. Им можно задать вопрос: «Если к вам придет
команда из другой школы и скажет, что хочет сделать такой же проект, смогли бы вы сказать, сколько человек им понадобится в команде, что эти люди должны будут уметь, какие им понадобятся ресурсы, сколько у них уйдет времени на проект, и какие риски могут перед ними оказаться?».
Мы разобрались с тем, как планировать получение продуктового и образовательного результата, теперь рассмотрим, кто за что отвечает в проектной деятельности.
В идеальном случае наставник не должен заниматься продуктовой работой. Задача наставника состоит в том, чтобы произошла какая-то трансформация с командой (зона присвоения опыта командой), но фокус часто смещается. Старайтесь не допускать такого смещения.
Что касается образовательного результата, то за него не могут нести ответственность, например, школьники, потому что у них не хватает навыков рефлексии. В идеале, эта зона ответственности лежит на наставнике (он решает, как организовать рефлексию у команды).
Мотивация участников проекта
Задайте себе вопрос: правда ли необходимо мотивировать команду? У людей бывает внутренняя (цели, стремления) и внешняя мотивация. Если человек занимается проектом без внешней мотивации — это замечательно. Если человека надо уговаривать, мотивировать извне, может оказаться, что внутренней мотивации к этому проекту у него нет вообще. Что это значит? Если внешняя мотивация в какой-то момент ослабнет, человек из этого проекта сразу уйдет. Тут надо учитывать то, какая цель стоит перед наставником.
Цель работы наставника
Задача наставника: дать участникам проектный опыт во всей его полноте. В проектной деятельности негативный опыт тоже ценен. Например, когда ребята попадут во взрослую рабочую ситуацию, они уже будут знать, что может настать момент, когда проект перестанет быть интересным. Благодаря негативному опыту они будут знать, как действовать в подобной
ситуации. Поэтому не стоит мотивировать извне, надо дать детям получить негативный опыт, но, главное, отрефлексировать его. Помните: ценен только тот опыт, который отрефлексирован!
Методы текущей рефлексии
∉ «daily scrum» (ежедневная 15-минутная летучка)
∉ ретроспектива (групповое обсуждение по итогам этапа)
В этих беседах наставнику важно сохранять следующие фокусы:
«Зачем?» воспринимается как «Прекрати это делать!»)
| Команда | Наставник |
Продуктовый результат | В пределах навыков команды | Может брать на себя аналитику и менеджмент |
Образовательный результат | Пропорционален уровню навыков рефлексии | Прямая зона ответственности наставника |
Пройдя школу наставника (руководителя проекта),
Вам необходимо:
акции «Весенняя неделя добра
Удачной реализации вашего проекта
ИТОГОВОЕ ЗАДАНИЕ