Начнем статью с интуитивно непротиворечивого представления, что все успешные стартапы похожи друг на друга четкостью своих намерений и точностью действий. «Ошибка выживших! — скажут критики. – Иногда важнее знать, почему люди терпят неудачу, а не почему они достигают успеха». Наиболее продвинутые будут искать брешь в логике: что необходимо или что достаточно для успешности. Оставляю пищу для рассуждений и посвящу дальнейший материал студенческим вузовским проектам начального уровня. Статья написана в преддверии старта комплексной программы повышения квалификации и прочтения модуля «Постановка целей и задач для трекшена проекта». Буду рада комментариям, откликам, поддержке и дополнениям.
Напомню, что трекшн (traction) – уникальное доказательство успеха и развития проекта, отражающее уверенность и экономически оправданные усилия команды. По тому, как меняется ключевая метрика, которую выбрала команда, дается оценка: трекшн прогрессивный, стабильный или нулевой. Детали обсуждала в предыдущем блоге "Трекшн-карта трекера при работе с проектом" .
Не первый год в стране реализуется масштабная поддержка университетского технологического предпринимательства. На рынке работают несколько операторов. У каждого – своя концепция, методология, программа, инструменты, шаблоны и своя команда трекеров. Есть пересечения по людям и названиям: трекшн-митинги, демодень, питч дек и т. д. Статья написана в…
Критическим моментом для трекшена является цель. Если ее нет, то и оценка трекшена будет лукавством.
— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно… — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
—… только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.
Вернемся к примеру вузовского навигатора с ценностным предложением про уверенное и безошибочное перемещение по зданию вуза. Пусть для реализации этого проекта собрана группа студентов, где есть IT специалисты, маркетологи, экономисты, дизайнеры и просто помощники, рассказчики и молчуны-наблюдатели. Список реально может быть таким впечатляющим. Оставим за кадром, как все они оказались в акселераторе, почему и зачем, какая у них у каждого и у всех вместе мотивация «от… » или мотивация «к… ». Не будем трогать и останавливаться на важной части проектной деятельности – превращение этой группы в слаженную минимальную жизнеспособную команду (Minimal Viable Team, MVT) . «Подвесим» этот вопрос по аналогии с «подвешенным» кофе до лучших времен, следующего блога.
Правило “3h” гласит, что в основе стартапа должны быть hipster, hustler, hacker: хипстер — дизайнер, который создает красивую обертку и вообще делает продукт привлекательным, хастлер — тот, кто развивает продукт и продвигает его (он же и продает по большому счету и делает продукт «хотибельным» всеми), хакер — разработчик или тот, кто отвечает за все технические вопросы, возникающие при создании продукта. Для MVT добавляют четвертого участника – аналитика. Он умеет работать с данными, собирать и обрабатывать их, ставить исследовательский вопросы, оценивать причинно-следственные связи и строить гипотезы.
Так вот предположим, что эта замечательная банда (в хорошем смысле этого слова) каждую неделю на трекшн-митинге рапортует, как идет разработка приложения и в целом развитие проекта, что в Figma уже отрисован (N+1) экран, конкурентов на рынке нет от слова «совсем», опросы показывают, что респонденты только и ждут выхода приложение. Осталось найти инвестора, получить от него 100500 миллионов и реализовать мечту практически всего человечества. Среднестатистическая ситуация. С минимальной погрешностью и… правом на ошибку. Скорее всего сейчас звучит «бинго!», и многие трекеры узнали своих подопечных. Наследие школьного образования, рефераты-сочинения, фантазии-галлюцинации. Путь воина в головах студентов – красивые картинки. И в этом для них весь сакральный смысл проектной деятельности. Спускаем студентов с небес на землю серией вопросов. «Что является конечным результатом вашей проектной деятельности?» В нашем примере в лучшем случае назовут приложение для смартфонов. «А как вы поймете, что достигли результата?» «А что для вас означает «успешный» проект?» И дальше у студентов или тупик, или прозрение.
Сделаем шаг в сторону и отвлечемся на теорию. Когда речь заходит о будущих результатах, то ключевым словом является «будущих». Мы (верю, что в подавляющем своем большинстве) не оракулы, не провидцы и, конечно, хотим отстроиться от шарлатанов. Как можно было бы больше или быстрее и лучше, показывает только история, когда с течением времени будущие результаты становятся сначала настоящими, а потом и прошлыми. Известно, история не терпит сослагательного наклонения, «если бы» к ней не применимо, реки впять не повернуть, и переписать случившееся невозможно. Доступна опция перенесения пережитого опыта в новые ситуации. Взгляд в будущее проекта – это соглашение сегодня с поправкой на ошибку (на риски, как скажут проджект менеджеры).
Существует множество способов, методов, инструментов прогнозирования или того самого «взгляда в будущее». Прогнозные сценарии бывают оптимистичными, реалистичными, маловероятными, пессимистичными и еще множество вариаций с концовкой «… ычными». Финальная точка в прогнозах – это определенное состояние проекта, веха в его дорожной карте, как срез на врачебных снимках МРТ. Об этом состоянии договаривается команда «на берегу» на старте проекта. Это состояние называется «цель». Это завтра, которое строит сегодня вся команда вместе и к которому идет одним из «… ычных» путей. И в этом неповторимость каждого проекта, его генетический код и уникальные отпечатки пальцев команды.
Цель проекта – это будущий результат совместных усилий команды сегодня, о котором договорились вчера
Возвращаемся к серии вопросов. Что нужно (речь идет о ресурсах) , чтобы прийти к цели? Что из необходимого уже есть? А чего нет и что может стать препятствием в развитии проекта и как его преодолеть? Какие есть ограничения по времени, и кто контролирует точность достижения цели?
Обычно эти и подобные вопросы трекер задает на диагностической встрече. Их же повторяет в разных контекстах на тематических трекшн-митингах, а по ответам сверяет намеченный курс проекта с путеводной звездой – целью. Кто путешествовал по Кижским шхерам, тот, скорее всего, видел на берегах извилистого пути похожие на горизонтальные жалюзи решетчатые треноги – осевые парные створчатые указатели рейда. Считайте, что это метафора для целеполагания в проектной деятельности.
Классическим (по частотной метрике интернет поисковиков) инструментом постановки цели стал фрейм SMART. Справедливости ради стоит сказать, что он является простым и понятным даже для новичков в проектной деятельности. SMART расшифровывается по первым буквам соответствующих английских слов:
- Specific (Конкретность)
- Measurable (Измеримость)
- Attainable (Достижимость)
- Relevant / Realistic (Уместность/ Реалистичность)
- Time-bound (Ограниченность во времени)
Фрейм SMART, как и любой другой: заимствованный, усовершенствованный или адаптированный под конкретный запрос акселератора, не является на 100% универсальным. Это карандашный набросок будущего шедевра проектной деятельности. Кстати, многие техники и инструменты так и рождались, исправляя недостатки или недосказанность предыдущих версий. Например, S.M.A.R.T.E.R.. Добавляем к вышеупомянутому SMART Evaluate (Оцениваемость) и Re-Do (Повторяемость) . Или S.M.A.R.T.T.A.: плюс Trackable (Отслеживаемость) и Agreed (Согласованность). Поупражняться можно и в трактовках начального SMART, если поискать релевантные английские слова, начинающиеся на эти буквы.
А в S.M.A.R.T.E.R. буква E может быть от Excite — восхищать, зажигать, или Emotional — эмоциональная.
Выбрав по одной расшифровке для каждой буквы, можно поупражняться в составлении комбинаций новых авторских SMART шаблонов. Как знать, может быть ваша версия станет популярной, войдет в список классических и будет транслироваться на широкую общественность.
Для нашего сквозного примера вузовского навигатора SMART цель может быть следующей.
Специфичная (Specific): Разработать приложение, которое обеспечивает эффективную навигацию студентов и сотрудников по корпусам университета, предоставляя точные карты, информацию о расположении аудиторий, а также оптимальные маршруты от одного корпуса к другому.
Измеримая (Measurable): В течение первого полугодия после открытия доступа к приложению достичь для метрик количество скачиваний, активные пользователи и среднее время использования в неделю соответствия не менее 80% студентам и сотрудникам университета.
Достижимая (Achievable): Разработать приложение, совместимое с основными мобильными платформами (iOS и Android) и легкое в использовании даже для людей с минимальным опытом в работе с мобильными приложениями.
Релевантная (Relevant): Повысить общую удовлетворенность студентов и сотрудников по метрике отношение к инфраструктуре университета, обеспечив им уверенность в быстрой и удобной навигации между корпусами вуза.
Временнáя (Time-bound): Запустить приложение и провести обучающие мероприятия для студентов и сотрудников в течение следующих шести месяцев.
В сборке в одно предложение цель может звучать так: «К… [календарная дата через шесть месяцев] обеспечили для не менее чем 80% студентов и сотрудников легкость в ориентировании и навигации по корпусам университета с помощью интерактивной карты в мобильном приложении (iOS и Android), что улучшило их удовлетворенность инфраструктурой вуза на 5 пп (процентных пунктов)».
Цель пишется в настоящем времени или фиксируется как свершившийся факт. Зачем? Чтобы команда попробовала встать в «тапки» будущего состояния, примерила их на себе, испытала чувства, высказала эмоции, оценила комфорт и полюбила свой же проект.
Цель позитивна, без частицы «не». Решение о вузовском навигаторе скорее всего строится из наблюдений негативного опыта опозданий и блужданий по длинным коридорам «храма науки». Респонденты проблемных интервью так и говорят: «Не нравится опаздывать» и «Не хочу блуждать». Меняем окраску и получаем «уверенное перемещение», «легкость в ориентации», «оптимальный путь».
Работа по целеполаганию может занимать много времени. Это творческий процесс, им можно увлечься. Лучше к сопровождению привлечь модератора или фасилитатора, кто держит в руках таймер и отстукивает такты командной работы. Хорошая новость в том, что процесс целеполагания конечен: как только команда договорилась, так в трекшн-карте заполнилась ячейка «цель проекта».
Небольшое отступление. Формулировку цели важно записать и держать в проектной работе перед глазами, например, на стикере в дашборде. Не нужно его сжигать, бросать пепел в новогодний бокал и выпивать вместе с шампанским в ожидании чуда. Цель – это не фокус волшебника. Это управляемая командой реальность, которая создается ее усилиями. Есть исследования, которые показывают, что те, кто записывали свои цели, достигали их чаще, чем те, кто этого не делали. Более того, люди, записавшие свои цели и рассказывавшие о своём прогрессе друзьям, были успешнее, чем те, которые боялись изначально насмешить своими планами. Мне нравится в это верить. Транслирую эту мысль дальше. Цель в голове — не более чем мечта. Ее легко исказить, перефразировать, домыслить или вообще забыть. А запись – это уже «улика» и факт. Тут сложно манипулировать и нет простора для интерпретации. Все попытки будут пресечены и отнесены к уловкам, прокрастинации, отмазкам.
«Съешьте лягушку на завтрак»: найдите самую крупную и важную задачу из своего списка дел и выполните её до конца
Хорошую новость описала. Теперь остановлюсь на другой.
Цель нужна, чтобы ее достигать. Цель проекта достигается командой. Команда – это люди со своим функционалом, которые что-то делают, и их совместный труд и усилия приводят в конечном итоге к цели. Хорошая цель дает больше энергии, чем ее забирает процесс достижения.
Сильным является вопрос трекера к команде про цель: «Представьте, что завтра цель должна быть достигнута. Какой последний шаг нужно сделать, чтобы это случилось?». Здесь не принципиально завтра или через месяц. Важно, чтобы команда накидала идеи по действиям: оформить канал в Телеграм и разместить пост, записать стрим, открыть доступ к приложению контрольной группе пользователей для теста и т. д. Повторяя вопрос, какой предыдущий шаг, трекер подводит команду к старту проекта. И звучат вопросы «А какой первый шаг? Что делаем сейчас?». Все, что говорит команда, фиксируется в бэклоге трекшн-карты. А приоритеты становятся задачами на ближайший спринт.
Важный психологический момент. Как бы "страшно" не звучала цель, какими бы не были у команды сомнения в возможности пройти весь путь до цели, "слон съедается по кусочкам". Итак, от цели, декомпозируя, идем «вперед в прошлое» к текущей точке А проекта, а потом собираем композицию «назад в будущее» по шагам. Шаги – это задачи, взвешенные по ресурсам, скорости и синхронности всех членов команды. Их можно «смартовать», применяя знакомый фрейм SMART. Их выхватывают из бэклога проекта и по мере готовности последовательно перемещают в "Приоритеты задач", "В работе", "На проверке" и, наконец, "Готово" на скрамбан доске, если используют гибкие методики проектной деятельности.
Задачи можно называть маленькими целями или подцелями, если, например, принципиальны финансовые, рыночные, технические и другие направления. В больших корпорациях в организационной структуре под это выделяют специальные департаменты и назначают их руководителей – финансового директора, директора по маркетингу, технического директора и т. д. В этом случае говорят о «дереве целей». В конечном итоге детализация подцелей приведет к формулировке задач. Они отвечают на вопросы действия и вопрос «чья задача?», т.е. имеют хозяина. Выше по тексту задачи начинались со слов «оформить», «разместить», «записать», «открыть» и т.п. Хозяин - это член команды с определенным функционалом. Он выполняет задачу и несет ответственность за ее решение. У каждой задачи, как в школьной математике, есть условие (дано) на входе, вопрос при постановке и решение на выходе. Сам процесс решения – мастерство хозяина, его секретный соус, конкурентные преимущества перед остальными участниками проектной деятельности.
Может так случится, что вакансия хозяина задачи свободна. Например, в нашем условном примере для принятия платежей за подписку на приложение нужен эквайринг. Что это и с чем его едят, может ответить специалист с соответствующими компетенциями. А его сейчас в команде, скажем, нет. Не беда. Не забываем про настройку эквайринга в бэклоге проекта, оцениваем риск свободной вакансии и решаем задачу закрытия вакансии, когда риск становится критическим.
Такой подход «задача – хозяин» помогает оценить нагрузку и усилия каждого члена команды. И самое важное – по вкладу разделить пирог успеха, когда цель достигнута.
Подведем итоги.
- В любом проекта должна быть цель
- Цель определяется командой и декомпозируется на задачи
- Цель позитивна и должна вызывать положительные эмоции у каждого члена команды
- Бокал шампанского по достижении цели не повредит
Поддерживаем традицию: в комментариях можно написать «Бинго», если вы попадали в аналогичные ситуации и прочитали статью, как будто про себя.