Между заказчиком и разработчиками, особенно начинающими, нередко возникает недопонимание относительно создаваемого проекта.
Ситуация напоминает детскую игру «испорченный телефон». Заказчик рассказывает о своем проекте менеджеру. Проект-менеджер делает пометки, что должно быть на сайте или в приложении, но опускает часть задач, потому что они кажутся очевидными. Дизайнер получает неполную информацию и строит работу без точного учета первоначального замысла.
В результате при создании продукта принимают противоречивые решения, которых можно было бы избежать, наладив единое видение между всеми участниками процесса. Основой для единого видения является концепция проекта. На каждом этапе разработки концепция последовательно детализируется. Именно поэтому важно задать верный вектор в самом начале пути.
В этом может помочь простая формула, построенная на наблюдении (да простят меня читатели знакомые с теоретической физикой и высшей математикой за такой подход): в основе успешного проекта — работоспособная система. В основе работоспособной системы — учет интересов заказчика и целей пользователей, которые достигаются с помощью проекта. Любая формула — формальность. При использовании необходимо переводить на человеческий язык. ⌘ ⌘ ⌘ Концепция проекта = мы (краткое описание проекта) помогаем (описание основной аудитории проекта) достигать (описание целей пользователей) для (описание целей владельцев проекта). ⌘ ⌘ ⌘
КОНЦЕПЦИЯ — что это такое? значение и описание
Необъективные авторские примеры использования
Spark.ru Мы тусовка технологичных проектов, помогающая стартапам делиться знаниями и приобретать с их помощью новых клиентов, инвесторов и партнеров, созданная для получения профита от рекламы. Meduza.io Мы новостной портал для людей, уставших от официальных лент, созданный с целью создания и распространения новостей без указания свыше.
Где можно использовать формулировку?
- В брифе, на этапе обсуждения будущего проекта между заказчиком и разработчиками.
- В любой технической документации, описывающей проект.
- На сайте, в формате позиционирующего слогана, в упрощенном варианте: мы (краткое описание краткое описание проекта) помогаем (описание основной аудитории проекта) достигать (описание целей пользователей).
Источник: spark.ru
Почему вашему проекту нужна концепция
- Все статьи цикла:
- Почему вашему проекту нужна концепция (вы здесь)
- Состав и структура концепции цифрового продукта
Времена простых продуктов и гениальных одиночек безвозвратно прошли. Сейчас с проектированием чего-то сложнее лендинга уже не справится один-единственный специалист. Более того, даже сама подготовка к полноценному проектированию может отнимать значительное количество времени и ресурсов.
Концепция маркетинга
Я ещё помню дни, когда после первого контакта было нормой отправлять клиенту опросник. Затем его место занял более подробный бриф, некоторые даже составляли что-то вроде проектного задания. Названия менялись, и каждая компания вкладывала в них разные значения, но суть оставалась одна: собрать в едином месте первоначальные требования к будущему продукту.
Однако и по сей день эти требования частенько собираются кое-как. В лучшем случае это делает аналитик, чаще – вообще какой-нибудь аккаунт-менеджер. Даже в крупных компаниях, которые решают разработать собственный внутренний продукт, требования не всегда формируют действительно компетентные люди. Про грамотную обработку и систематизацию такой информации я даже не говорю. Всё это впоследствии провоцирует целый ряд проблем, иногда – довольно не очевидных на старте.
§ Почему концепция
Иногда я помогаю внешним проектам: уже запущенным или только разрабатываемым. И регулярно встречаюсь на них с одними и теми типовыми проблемами, которые спокойно можно было предупредить ещё до начала непосредственного проектирования – всего одним небольшим предварительным этапом.
Если говорить о терминологии, то мы в Eleven предпочитаем называть этот этап концепцией. Остальные определения, чаще всего, подразумевают банальный сбор информации без какой-либо её серьёзной обработки. Приступать к проектированию с такими вводными мне лично страшновато. Концепция же предполагает базовые исследования и аналитику уже на самом старте проектного процесса. Она включает в себя сразу несколько других документов и является, по сути, нулевым этапом проектирования.
В этой короткой серии постов мы поговорим о том, какие цели преследует концепция и что входит в её состав. И начнём с того, зачем вообще нужен этот самый «нулевой» этап.
§ 1. Единое информационное поле
Говоря об информационном поле, я подразумеваю комплексное, однозначное и единое представление о будущем продукте у всех участников проектной команды: от разработчиков до клиента, CEO или владельца продукта. Почему важно, чтобы каждая деталь концепции, основа и базовые границы проекта виделись всем участникам проекта одинаково? Если этого не сделать до начала непосредственного проектирования (а уж тем более, до начала разработки), то процесс пойдет намного медленнее и болезненнее. Клиент будет вносить спонтанные, как вам кажется, правки; разработка – использовать не те инструменты, которые следовало бы; а маркетинг готовить совсем другие метрики.
Представьте себе идеальный стартап. Например, сервис по передержке домашних животных. В команде с самого начала сидят CEO, продуктовый дизайнер, аналитики, разработчики и маркетологи. И вроде идея уже сформирована и даже кое-как описана на одном листе А4. Всем кажется, что они точно знают, что нужно делать.
Вот только маркетинг думает, что основная задача сервиса с точки зрения монетизации – свести клиентов и ситтеров, тогда как CEO планирует основной доход получать не с процентов за сделку, а с партнерских программ (например, продавать клиентам корм со скидкой).Разработчики, жадные до новых технологий, хотят сделать новомодное веб-приложение на последнем React’е и уже даже начали набрасывать технический прототип – но они понятия не имеют о том, что одной из фишек сервиса будет являться опция видеонаблюдения за своими питомцами. А у асинхронных библиотек есть определённые проблемы с потоковым видео, и это нужно учитывать.
О CEO и говорить нечего. На старте он почти всегда глубоко убежден, что знает проект досконально. Хотя по факту, чаще всего, не учитывает огромное количество нюансов и деталей: вроде платы за обращение к гугл-картам, необходимости подключать онлайн-кассу или особенностей управления персональными данными клиентов.
Грамотная концепция формирует у всей команды единую картинку продукта. А это довольно сильно влияет на стабильность дальнейшей работы на ним.
§ 2. Определение и фиксация границ проекта
Кроме того, проектное задание призвано свершить еще одно великое дело: очертить первоначальные границы проекта. Определить, что будет в проекте, а чего в нём быть не должно. Из каких частей будет состоять продукт, какие типы ресурсов потребуются для его создания, каким образом будет осуществляться коммуникация с клиентами, партнёрами и так далее.
У вас случалось когда-нибудь, что простенький с виду лендинг к релизу обрастал админкой, мобильным приложением, искусственным интеллектом, чат-ботом и собственным спутником на геостационарной орбите? Тогда вы понимаете, о чём я.
Чтобы проиллюстрировать этот момент, давайте вернёмся к нашему примеру про животных.
Итак, CEO говорит, что между пользователями возможны конфликты и споры. И что если сделка проходит через сервис, мы должны эти конфликты решать. А значит, нужен внутренний сервис тикетов – своеобразный арбитраж, через который любая сторона может подать жалобу на неисполнение условий договорённости.
Вы можете себе представить, сколько усилий уйдёт на создание внутренней арбитражной системы? При том, что она вовсе не является функциональным ядром сервиса – и стартап спокойно запустится без неё. Если дизайнер/проектировщик/аналитик умные, они кратко опишут арбитраж под грифом “следующие этапы развития” – и предложат ввести рейтинг, а спорные вопросы первое время решать через поддержку.
Зафиксируют это в концепции, и тогда в конце проектирования не придётся второпях запускать на орбиту спутник, изыскивая на это и так дефицитные ресурсы.
§ 3. Выявление рисков, недостатков и перспектив продукта
За годы в IT мне удалось поучаствовать в создании многих проектов, включая внутренние продукты крупных компаний. И ни разу – ни на простом стартапе, ни на какой-нибудь системе налоговой отчётности – не было случая, чтобы клиент продумал всё идеально. Всегда возникали проблемы, каждая идея претерпевала множество изменений.
Концепция – не «серебряная пуля», и она не защитит ваш проект от всех коллизий и мутаций. Но она способна свести их к минимуму. Попутно выявляя потенциальные недостатки и векторы развития будущего продукта. Давайте снова обратимся к нашему выдуманному примеру.
Допустим, у нас в стартапе есть гугл-карта с доступными ситтерами. Если пользователей станет много и они будут достаточно активны, то бесплатный лимит запросов к картам очень скоро закончатся. Тогда карта просто перестанет работать. И сделает это, возможно, весьма внезапно.
А значит, нам нужно завести в Google Cloud Platform платёжный аккаунт и подцепить к нему банковскую карту, на которой всегда будут какие-то деньги. Да, это можно решить и не на этапе концепции, но предусмотреть подобные вещи в начале не сложно – а они могут сказаться на финансовой модели.
Или представим, что на старте бизнес не уверен, в какую сторону развивать продукт: делать упор на безопасность и вводить платные аккаунты с видеонаблюдением или везде подсовывать продукцию партнёров, получая проценты с продаж. Аналитики рекомендуют сперва изучить потребительский спрос на конкретном продукте, и только потом принимать решение. В этом случае в концепции стоит отразить оба варианта. Чтобы дизайнер построил универсальный UX, а разработчики не блокировали один из них ошибочными технологическими решениями.
Предусмотреть базовые риски несложно. Описать предполагаемые векторы развития – тоже. Можно даже примерно представить, что может воспрепятствовать развитию продукта – и подумать, как обойти или убрать такие препятствия.
§ 4. Первичная оценка проекта и проектирования
Разумеется, на старте очень и очень редко можно дать даже примерную оценку стоимости создания проекта (если это, конечно, не какой-нибудь типовой e-commerce). Однако очертить хотя бы базовый горизонт, понять порядок объема ресурсов, которые потребуются, – можно вполне.
Кроме того, концепция за счёт предыдущих пунктов сильно стабилизирует затраты. Нам не придётся в середине проектирования столкнуться с тем, что продукт нежизнеспособен без какой-нибудь его части – а стоимость её создания сопоставима со всеми остальными работами.
Помните наш стартап? Пользователи в нём делятся на 2 типа:
- те, кто отдаёт животных на передержку;
- те, кто принимает питомцев в своих квартирах на обозначенный срок.
Подразумевается, что вторые должны проходить какую-то предварительную проверку, чтобы первые не отдавали своих мохнатых любимцев кому попало. Однако клиент попросту упустил этот момент, когда говорил с аналитиком, а дизайнеру банально не пришло это в голову. Если нет чётко описанной концепции, этот нюанс всплывет значительно позже – скорее всего, уже на этапе создания прототипа или даже дизайн-макетов. То есть придётся перерабатывать значительную часть пользовательских сценариев. А это может довольно серьёзно повлиять на стоимость проектирования и последующей разработки.
§ Что дальше?
Дальше вы можете отправить этот пост своему клиенту, когда понадобится подтвердить необходимость концептуального этапа проектирования.
А можете проследовать ещё дальше и перейти к следующему посту цикла – там я расскажу о составе этого самого «нулевого» этапа. О том, какая информация должна входить в концепцию и как она может быть структурирована.
Источник: sherer.pro
Управление программами: Создание Концепции программы (Programme blueprint)
Для того, чтобы дойти до Концепции программы (programme blueprint), Вам придётся преодолеть 80 страниц стандарта PRINCE2: Managing Successful Programmes (MSP). Но сделать это стоит, ведь Концепция программы – один из самых интересных инструментов из всего руководства. В этой статье мы рассмотрим, что такое Концепция программы и почему её нужно использовать, вне зависимости от того, каким подходом к управлению программой Вы пользуетесь.
Что такое Концепция программы (Programme Blueprint)?
Как правило, в самом начале разработки программы, создаётся Видение программы (vision statement). Это краткое описание результатов, которые планируется достичь в ходе программы. Концепция, в свою очередь, не просто описывает выгоды от реализации программы и свойства продукта. Она содержит в себе то, как должна измениться организация в сравнении с нынешним состоянием. И вот эта «будущая организация» и должна реализовать выгоды от программы.
Для чего нужна Концепция программы?
Как уже было сказано, Концепция определяет различия между состоянием бизнеса сейчас и его состоянием в будущем. Эти отличия — хорошая база для GAP-анализа. Более того, результаты GAP-анализа иногда даже включаются в документацию Концепции в качестве приложения.
После того, как в Концепции будут описаны все отличия между существующим и желаемым состоянием, станут видны разрывы между данными состояниями, которые необходимо преодолеть. После чего вырабатывается список проектов, необходимых для преодоления этих разрывов.
В терминологии MSP этот процесс называется Планированием реализации Концепции (planning the Blueprint delivery). В ходе планирования прорабатываются различные возможности достижения поставленной цели – будет это серия небольших проектов или один масштабный трансформационный проект. Будут ли эти проекты реализованы одновременно или последовательно и какие трудности могут возникнуть в ходе их совместной реализации.
Кроме того, Концепция может влиять на оценку уже реализуемых компанией проектов. Ведь когда мы получили подробное видение состояния компании в ходе реализации программы, становится очевидно, какие проекты, реализуемые в данный момент приближают желаемое состояние. Если проекты не делают этого, или ещё хуже, плохо укладываются в желаемую структуру – их реализацию целесообразно прекратить как можно скорее, а высвободившиеся ресурсы направить на реализацию программы по достижению желаемого состояния.
Как Концепция помогает структурировать программу?
На программном уровне ценность Концепции в первую очередь состоит в том, что она создаёт отправную точку. Концепция – это детальная картина успеха. Всё, что производит программа, всё, что станет результатом проектов программы, должно вести к желаемому состоянию. Именно концепция позволяет сохранять фокус и двигаться в нужном направлении.
Кроме того, Концепция позволяет достаточно чётко определить промежуточные шаги на пути к цели. Ведь зачастую в ходе масштабной трансформации организации реализуются несколько программ. И Концепция не только позволяет определить место программы в общей масштабной картине трансформации, но и позволит более точно составить Концепции последующих программ.
Как пишется Концепция программы?
Очевидно, Концепция программы – не тот документ, который можно сесть и написать в одиночку независимо от всех. Если программа посвящена трансформации организации, автору концепции не обойтись без помощи сотрудников из разных частей организации. Вам придётся приложить немало усилий для консолидации усилий команды. Для коллективного написания документа Вам потребуются не просто люди, хорошо знающие структуру организации и то, как работает её бизнес, но и люди с воображением, способные представить будущее компании, описать его и спрогнозировать. Для особо крупных и приоритетных программ, помимо внутренних экспертов, может понадобиться помощь консультантов, внешних экспертов и фасилитаторов – при правильном применении, затраты на них окупятся в будущем.
Шаблон Концепции
Раздел 1. Будущее состоянии организации
В первом разделе описывается будущее состояние организации, которого необходимо достичь. Этот раздел включает в себя:
1. Цели и действия
В этом разделе описывается способ достижения Видения компании, включая основные вехи, которые необходимо пройти на пути к достижению цели. На этом этапе определяется, что в принципе планируется сделать. Например, будет ли это масштабная трансформационная программа, несколько программ или серия небольших проектов по изменению.
2. Основные выгоды от программы
Этот раздел посвящён описанию выгод для организации от реализации программы в течение всего её жизненного цикла. Цель данного раздела – не упустить выгоды и не потерять фокус на цели программы в ходе реализации концепции.
3. Модель будущей организации
В данном разделе определяется вид, способ функционирования, создания ценности и бизнес-модель будущей организации. В этом разделе описывается состояние организации «как будет», чтобы сравнить его с тем, «как есть» на данный момент. Это раздел позволяет увидеть разрывы и понять изменения, необходимые для того, чтобы достичь желаемого состояния.
4. Операционные измерения
В этом разделе прогнозируется уровень издержек, производства и сервиса организации будущего. Целевые количественные показатели позволяют более чётко определить успешность реализации программы.
5. Организационная структура
Как понятно из названия, этот раздел описывает организационную структуру, количество персонала, а также роли и умения сотрудников «организации будущего». Это описание состава той организации, которая сможет показывать описанные в видении показатели и результаты.
6. Информационная система
В данном разделе описывается информационная система, а также другие инструменты, необходимые для функционирования будущей организации. Новые бизнес процессы, системы и персонал зачастую требуют технической поддержки и обеспечения функционирования для достижения целевых показателей.
7. Вспомогательные сервисы
Этот раздел целиком посвящён определению состава вспомогательных сервисов, необходимых для эффективного функционирования основных подразделений будущей компании. В разделе должен быть описан список необходимых подразделений, их функции, количество персонала, компетенции и роли.
Раздел 2. Нынешнее состояние
Во втором разделе Концепции программы описывается нынешнее состояние организации. Его можно сделать в произвольной форме, можно взять за основу первую часть Концепции. Главное, чтобы структура позволяла легко и наглядно сравнивать между собой. Зачастую компании не могут сходу ответить на все вопросы о нынешнем состоянии организации и им приходится провести анализ нынешнего положения дел. Это оказывает положительное влияние на процесс и иногда приводит к интересным открытиям, которые заставляют вносить изменения во всю программу.
Раздел 3. Сравнение состояний
Третий раздел концепции представляет собой собственно сравнение состояний и определение отличий между состояниями. Список различий затем используется для формирования пула проектов, позволяющих эти различия преодолеть и достичь желаемого состояния.
Руководство MSP никак не ограничивает Вас в использовании инструментов для написания концепции, лишь бы было удобно Вам. Рекомендуется использовать схемы, ментальные карты и другие инструменты визуализации. Чем Концепция понятнее – тем ниже вероятность разночтений и недопонимания между участниками процесса, а также того, что про Концепцию забудут и не будут в итоге использовать.
Чаще всего, одна трансформационная программа вряд ли сможет радикально изменить всю организацию и реализовать изначальную Концепцию реализации Видения. А потому можно определить несколько промежуточных шагов в достижении желаемого состояния бизнеса, и реализовывать программы по их достижению. Так процесс будет более управляемым и стабильным.
Обновление Концепции
Официально в MSP нигде не указывается, как часто нужно обновлять Концепцию программы. Но исходя из здравого смысла, делать это всё же стоит, и вот почему.
Организация не существует в вакууме – внешние условия оказывают влияние как на бизнес, так и на его развитие. Окружающий мир быстро изменяется, и чтобы ему соответствовать, необходимо подстраиваться под новые условия. А учитывая, что программы трансформации организации могут длиться и 5, и 10 лет – изменения неизбежны и должны быть учтены в концепции.
Кроме того, смена руководителя, например, уход генерального директора или руководителя важного подразделения, может оказать серьёзное влияние на развитие компании. А значит и Концепция должна быть пересмотрена и утверждена всеми участниками.
Насколько регулярно нужно пересматривать концепцию зависит от специфики конкретной организации, отрасли и программы. Тем не менее, данный процесс позволяет не забывать о наличии концепции, заставляет детально анализировать происходящие изменения и поступающие в организацию извне сигналы. А это крайне полезно.
Заключение
Концепция позволяет быть уверенными в том, что у реализуемой программы есть серьёзная база, согласующаяся с видением и стратегией организации. Концепция позволяет организации осознать, где она находится, куда она движется и чего стремится достичь.
Источник: pmservices.ru