Структура деятельности человека включает в себя несколько компонентов, начиная от потребности и заканчивая результатом. Потребность — это внутреннее состояние, которое побуждает человека к действию. Потребности могут быть физиологическими, духовными и социальными. Наличие потребности сопровождается эмоциями, которые могут быть отрицательными или положительными.
Для удовлетворения потребности необходимо определить мотив, который будет побуждать человека к действию. Мотив — это внешние и внутренние условия, которые побуждают субъект выполнять действия. Цель — это то, что человек хочет достичь, выполняя действия. Средства — это инструменты, которые используются для достижения цели.
Результат — это то, что было достигнуто как итог деятельности. При получении желаемого мотивация гаснет, и теряется необходимость поддерживать интерес к удовлетворению этой потребности.
Результат, являющийся целью реализации проекта, считается продуктом проекта. Продукт проекта — это конечный результат проекта, который может быть продуктом, услугой или результатом деятельности. Он является основным продуктом, который создается в рамках проекта и который должен соответствовать потребностям заказчика и целям проекта.
5 Причин почему бизнес-план нужно составлять самостоятельно
Продукт проекта является целью проекта и описывает, как изменится ситуация в результате реализации проекта при заданных условиях. Продукт проекта может быть физическим продуктом, таким как новый продукт или оборудование, или он может быть виртуальным продуктом, таким как программное обеспечение или веб-сайт. Кроме того, продукт проекта может быть услугой, такой как консультационные услуги или обучение.
Продукт оценивается определенными метриками успеха. Продукт проекта должен быть определен и описан в проектной документации, такой как техническое задание или спецификация продукта. Важно, чтобы продукт проекта был ясно определен и описан, чтобы заказчик мог оценить его соответствие своим потребностям и целям проекта, а также чтобы команда проекта могла оценить свой прогресс и успешность достижения целей проекта.
Цель проекта — достижение заданного результата и получение продукта проекта.
На пути удовлетворения потребности может возникнуть проблема — это сложный теоретический или практический вопрос, требующий решения и исследования. Проблема возникает, когда прошлые успешные модели поведения перестают работать или не подходят для новой ситуации, возникает осознание невозможности разрешить трудности и противоречия, возникшие в данной ситуации, средствами наличного знания и опыта.
Иногда говорят о «проблемной ситуации» как ситуации, в которой возникает противоречие между текущим состоянием и желаемым состоянием, или между текущими условиями и целями. Таким образом, проблемная ситуация говорит сразу и о наличии потребности, и мотива, а также о наличии проблемы, не дающей эту потребность удовлетворить.
Ситуация желаемая, в которой хотелось бы оказаться, чтобы выйти из ситуации проблемной, обычно называется целевой ситуацией.
Partner cyber network Cyber_Link
Целевая ситуация может быть определена в различных форматах, например, в виде требований к качеству продукта или услуги, к срокам выполнения работ, к бюджету проекта и т.д. Целевая ситуация определяется на основе требований и ожиданий заказчика, а также целей и задач проекта. Важно, чтобы целевая ситуация была конкретной и измеримой, чтобы можно было оценить, насколько успешно была решена проблемная ситуация.
Определение целевой ситуации является важным этапом решения проблемной ситуации, так как это помогает проектной команде и заказчику иметь общее представление о том, к чему стремятся и какие результаты ожидаются от решения проблемы.
Достижение целевой ситуации является конечным результатом, продуктом проекта, который определяет, был ли проект успешным. Если целевая ситуация была достигнута, то можно считать, что проект был выполнен успешно. Если же целевая ситуация не была достигнута, то необходимо провести анализ и выявить причины неудачи, а также принять меры для улучшения процесса выполнения проектов в будущем.
Потребность — всегда персонализирована. Субъект, оказавшийся в проблемной ситуации, и заинтересованный в ее разрешении, считается потребителем соответствующего решения, а в проекте — потребителем продукта проекта.
Важно: субъект, которому будет принадлежать результат, продукт проекта, считается заказчиком проекта, и заказчик и потребитель в проекте могут быть одним лицом, а могут быть разными. К примеру, либо с ограниченными возможностями может заказать разработчику инвалидную коляску для решения своих проблем, но ее может заказать и передать ему некий благотворительный фонд — тогда либо остается потребителем данного решения, но результат разработки как продукт проекта разработчик передает фонду, как заказчику.
Следует также от заказчиков и потребителей отличать пользователей — тех, кто с продуктом взаимодействует, его использует. Так, издательство заказывает автору детскую книгу, которую будут «потреблять» родители, покупающие ее для своих детей.
Заказчик, потребитель и пользователь — это три разных роли в проекте, которые выполняют разные функции и имеют различные интересы и потребности.
Заказчик — это лицо или организация, которая владеет продуктом проекта; обычно это видно из того, что она оплачивает и заказывает проект. Обычно он или она является инициатором проекта, определяет его цели, бюджет, сроки, и требования к результату. Заказчик также может контролировать процесс выполнения проекта и принимать решения о его изменении или прекращении.
Потребитель — это человек или группа людей, которые будут использовать или потреблять результат проекта, разрешая свою проблемную ситуацию. Они определяют требования к качеству, функциональности и удобству использования продукта или услуги. Важно, чтобы проект был выполнен с учетом потребностей и ожиданий потребителей, чтобы обеспечить их удовлетворенность результатом.
Пользователь — это конечный пользователь продукта или услуги, который будет использовать его в своих целях. Он может иметь особые требования к продукту или услуге, связанные с его специализированной деятельностью или индивидуальными потребностями. Важно учитывать потребности и ожидания пользователей при проектировании и разработке продукта или услуги.
Таким образом, заказчик, потребитель и пользователь выполняют разные функции и имеют разные интересы в проекте, и учитывание их требований и потребностей помогает обеспечить успешное выполнение проекта и удовлетворение всех заинтересованных сторон.
Обратите внимание: когда начальник говорит, что «у нас запрос от министерства — свяжитесь с ними и отправьте требуемые материалы к среде!», то заказчиком будет министерство, а если говорит, что «у нас запрос от министерства — подготовьте мне требуемые материалы, чтобы я отправил им к среде!», то заказчиком для вас будет начальник!
Итак, потребитель оказался в проблемной ситуации и заинтересован выбраться из нее, перебравшись в ситуацию целевую. Субъекта, который разрешает проблемную ситуацию, выполняя проект, будем в данном случае считать исполнителем, имея в виду, что и заказчик в данной схеме взаимодействий обязательно явно или неявно присутствует.
Но зачем именно потребитель обращается к исполнителю, в чем, содержательно, может быть этот запрос?
Переход из проблемной ситуации в целевую осуществляете через деятельность как совокупность действий и операций, сознательно организованных и направленных на достижение какой-либо цели. Для осуществления действий нужны средства — инструменты, орудия, приборы, материалы, информация и другие ресурсы, используемые субъектом для воздействия на предмет. Наконец, даже имея нужные средства и будучи способным совершить необходимые действия, нужно знать, что делать.
Если потребитель имеет необходимые средства, может осуществить необходимые действия и знает, что делать, так и проблемы нет. Проблема возникает, когда у потребителя отсутствует какие-либо из этих компонентов, за чем он и обращается к исполнителю.
Таким образом, потребитель может обратиться к исполнителю:
— за средствами решения проблемы, будучи готовым совершить сам необходимые действия;
— за совершением необходимых действий при наличии необходимых средств;
— за знанием, что делать с данной ситуации, даже обладая необходимыми средствами и будучи готовым совершить сам необходимые действия;
— за любой комбинацией из необходимого для осуществления деятельности, включая осуществление деятельности как таковой «под ключ».
То, что потребитель ожидает от исполнителя для разрешения свой проблемной ситуации — как сказали выше, это продукт проекта. Таким образом, продуктом проекта может быть любая комбинация средств, действий или знаний, в зависимости от потребностей потребителя.
Тут важно различать цель деятельности исполнителя, или цель проекта, и цель деятельности потребителя по «перемещению» из проблемной ситуации в целевую: они могут совпадать, а может быть и нет. Например, целью больного, может быть вылечиться (стать здоровым), но к врачу он может обращаться, «чтобы вылечил», а может — чтобы прописал необходимые средства, дал курс лечения, либо даже чтобы лишь поставил диагноз.
— кто потребитель, в чьих интересах будет делаться проект, кто будет использовать продукт проекта;
— кто заказчик, кому будет принадлежать продукт проекта, если это не сам потребитель, и как строятся его отношения с потребителем;
— в чем потребность, нужда, проблемная ситуация потребителя;
— в чем проблема потребителя, что он не может разрешить проблемную ситуацию сам и обращается к нам, как к «исполнителю»;
— какой продукт как образ желаемого будущего ожидает получить от нас потребитель, чтобы разрешить свою проблемную ситуацию (т.е. оказаться в ситуации целевой).
Здесь важно понимать, насколько точно может идентифицировать свои потребности, проблемы и средства для их разрешения сам потребитель или заказчик. Это классическая ситуация, знакомая всем по «Сказке о рыбаке и рыбке»: старуха видит новые возможности, но не понимает, как их использовать, поэтому не может четко поставить задачу, а старик, как «исполнитель», хоть и формально точно выполняет ее распоряжения, все равно оказывается виноватым, и аргументы «А так было в техзадании!» или «Так вы же сами так велели!» не срабатывают.
Еще сложнее ситуация, когда от потребителя нет формального заказа или даже запроса, в проект — инициативный, по сути — предпринимательский: «Мы уверены, что если мы вот это сделаем, то это обязательно будет ему нужно!».
Однако, во-первых, надо иметь доказательства, что потребность или проблема действительно существуют, а, во-вторых, оценить степень «нужды»: реализация проекта требует затрат времени, усилий, ресурсов, и надо быть уверенным, что ценность для потребителя эти затраты перекроет.
Источник: boosty.to
Продукт или вид услуг
В этом разделе, открывающем основную часть бизнес-плана, дается подробное описание будущего продукта, товара или услуги, которые Вы хотите предложить покупателям (потребителям). Здесь Вы излагаете свою «главную идею».
При разработке данного раздела требуется предельно четко ответить на ряд вопросов: — Какие потребности призван удовлетворить Ваш продукт (или услуга)? — Что особенного в нем и почему потребители будут отличать его от товаров (услуг), предоставляемых другими компаниями, и отдавать ему предпочтение? — Почему Вы выбрали этот продукт (услугу) и этот рынок, чем они привлекательны для Вас? — Каков жизненный цикл товара или, другими словами, как скоро он устареет? Правильные ответы на первые два вопроса требуют ясного понимания, что в действительности приобретают покупатели, делая ту или иную покупку.
Это сердцевина понятия товара и «не попробовав» ее, невозможно правильно разработать сам товар (ведь Вы не осознали потребность), его рекламу, систему распространения и т.п. Давайте задумаемся. Что мы приобретаем, покупая зубную пасту? В чем состоит наша потребность? Неужели нам просто хочется купить этот тюбик? Конечно, нет.
Покупая зубную пасту, мы покупаем здоровые зубы, ощущение свежести и обворожительную улыбку. Именно в этом состоит наша потребность, удовлетворяемая зубной пастой. Глава известной косметической фирмы «Ревлон, инк.» считает: «На фабрике мы делаем косметику. В магазине мы продаем надежду».
Отвечая на третий вопрос, уверенно изложите свои основные способности и умения и как они повлияли на Ваш выбор в бизнесе. Последующая информация, содержащаяся в этом разделе, должна дать ответы на такие вопросы: — Какими патентами или авторскими свидетельствами уже защищены, или могут быть, защищены особенности Вашего продукта или технологии? — В чем состоят особенности дизайна и упаковки товара?
Ответы на эти вопросы особенно важны для товаров, предназначенных к продаже на внешнем рынке, но скоро, мы в этом уверены, они будут иметь большое значение и для внутреннего рынка. Очень важный и часто забываемый нашими деловыми людьми момент — наглядное изображение товара или изделий, полученных с помощью новой технологии.
Для успеха бизнес-плана желательно включить в него фотографию или же очень хороший рисунок товара, позволяющий составить о нем ясное представление. Если в Вашем бизнес-плане речь идет о высокотехничном изделии, не забудьте охарактеризовать систему послепродажного сервиса. В целом в этом разделе бизнес-плана постарайтесь описать комплекс дополнительных услуг, предоставляемых покупателю в случае совершения покупки, то есть то «подкрепление», которое получит выпускаемый фирмой товар в конкурентной борьбе с аналогичными изделиями других фирм. Ведь «конкуренция по-новому — это не конкуренция между собой того, что произведено фирмами на своих заводах и фабриках, а то, чем они дополнительно снабдили свою продукцию в виде упаковки, услуг, рекламы, консультаций для клиентов, финансирования, особенностей поставки, услуг по складированию и прочих ценимых людьми вещей» (Левитт Теодор). И завершающим штрихом этого раздела бизнес-плана является свод данных о предполагаемой цене товара, затратах на его производство и величине прибыли, приносимой каждой единицей товара.
Ограничение
Для продолжения скачивания необходимо пройти капчу:
Источник: studfile.net
Разработка проекта vs разработка продукта — в чем разница
Сегодня разберем отличия продуктовой и проектной разработки. А потом соберем обратно. И даже лишних деталей не останется (наверное).
Есть проекты, а есть продукты. Причем оба термина применимы далеко не только к айтишной сфере. Батон и бублик — продукты, а запуск на хлебокомбинате новой линии по выпечке капкейков — проект. Но если бы всё было так же просто, как хлебушек, то не было бы статьи. А она есть. Как еще можно отличить продукт от проекта: Ну то есть в целом понятно. Если говорить про айтишные дела, то когда у тебя есть сервис, который ты бесконечно улучшаешь, меняешь, измеряешь реакцию целевых пользователей, снова меняешь, ищешь под него инвестиции, кусаешь локти, если что-то идет не так, закладываешь свой УАЗ в ломбард ради новой фичи — у тебя стартап продукт. И у тебя, вероятно, продуктовая команда. Когда у тебя есть краткосрочная задача запилить что-то по определенным требованиям (сайт, логотип, рекламную кампанию и т.д.) забрать деньги и отдать то, что получилось, в руки заказчика — у тебя проект. Вернее, проекты — потому что один закончился, начался второй, конвейер крутится, профиты мутятся. Здесь и далее, чтобы не путаться, будем считать так:
- Когда говорим о продукте, подразумеваем, что все делается внутри одной компании, все менеджеры, маркетологи, технари, дизайнеры и прочие сидят под одной крышей. Мысленно представляем команду, которая изо дня в день пилит, например, те же «Яндекс.Пробки».
- Когда говорим о проекте, имеем в виду именно какой-то ограниченный во времени квест, переданный заказчиком каким-то парням из Барнаула. Мысленно каждый представляет свою веб-студию. Ну или если не имеет студии, пусть представляет нашу.
Казалось бы, разница невелика — проекты, продукты, один хрен те же самые специалисты сидят и делают примерно одно и то же. Так же за ними присматривает менеджер. Также бюджет берется из кармана владельца бизнеса. Но нет, всё работает по-разному.
Разберем различия с точки зрения владельца-заказчика, команды исполнителей и руководителя.
Работа над проектом и продуктом: в шкуре владельца
Проектная разработка
Хотя адепты гибких методологий и называют заказчика сайта Product Owner’ом — на деле же он таких функций не выполняет. Банкет оплачивает, иногда вторгается в уютный мирок заказной разработки со своей картиной мира и правочками. Но не больше.
- Ему некогда, сайт не в приоритете. Объективно — нужно бизнес делать, а сайтом пусть займутся профессионалы. Все вы тут знаете, сколько килоджоулей надо сжечь, чтобы вытянуть из среднестатистического заказчика заполненный бриф.
- Он не всегда. Продакт-овнер — это работа, требующая подготовки, узкоспециальных знаний и опыта. Само собой, работая в обычном веб-продакшене вы таких уникумов в живой природе будете встречать довольно редко.
Вообще аутсорсинговая природа проекта формирует отношение владельца ко всему процессу. Команду он не хантит по человеку в месяц, никого не собеседует (и своего эйчара не напрягает). У него не болит голова насчет того, что с этими людьми делать дальше, когда работа закончится. Он не парится о мотивации или поиске компетентного менеджера на проект. Не рассчитывает окупаемость, не планирует бюджет.
Вместо этого он поступает просто: берет рейтинг самых-самых, выбирает из него кусок с подъемным для себя бюджетом, из него выбирает подрядчика, который больше понравился.
И дальше уже пошло-поехало: ТЗ, презентации, правочки. Стоп, снято, в продакшен.
Нет, само собой, бывают и совсем другие истории — когда заказчик компетентный в разработке ИТ-проектов, у него сильная команда на своей стороне, маркетологи, техдиректор, проект-менеджер, дизайнеры, контентщики. А на аутсорс он пошел просто потому, что своих ресурсов не хватило (или не хватило специализации).
Еще случай «другой истории» — когда у бизнеса есть доверенное агентство, взявшее на себя весь диджитал. Разные возникающие проекты агентство отдает аутсорс-продакшену.
В обоих случаях уровень работы приближается к продуктовому — тоже KPI, внятные постановки с самого начала, меньше неопределенности. Но это, скорее, исключение из правил, как вы поняли.
Продуктовая разработка
Здесь всё иначе. Продукт, то есть программный продукт — это и есть конечная цель для владельца бизнеса. Вернее, бесконечная — потому что нельзя просто так взять и выложить программный продукт, а потом забить на его улучшения.
- Поиск кадров и их последующий, простите, груминг становится одной из самых приоритетных задач владельца продукта.
- Прибыльность всего мероприятия определяет благосостояние самого продакт-овнера. Нет успеха продукта — нет денег, владелец сильно рискует.
- Продукт требует настоящего стратегического планирования, бюджетирования и всего остального. В отличие от работы над проектом — где достаточно тактического и чуть-чуть операционного планирования.
- Всё это обязывает владельца осваивать профессиональные приемы и методики управления, несоизмеримо сильнее погружаться в тему, жить ей.
Теперь о том, как себя чувствует команда там и там.
Продуктовая команда и команда «на потоке»
Проектная разработка
Жизнь команды, которая делает проекты, похожа на сплав по горной реке — течение крутит так и сяк, приходится то и дело активно грести веслами, чтобы не напороться на скалу, лодку подбрасывает, адреналин, кайф, ушибы, ссадины. Гребущие активно тренируют мускулатуру и учатся обращаться с инвентарем.
Причем в процессе такой яростной гонки один из гребцов встает посреди лодки и говорит: «ребята, меня позвали вон на тот круизный лайнер, до свидания!». После чего включает свой реактивный ранец и улетает в голубую даль.
Работа команды, делающей проекты на потоке — это очень много стресса, переключений между задачами, подгорающий фитилек дедлайна и. чемодан опыта. Так что можно сказать, что потоковая разработка — для молодых и энергичных, здесь как нельзя быстрее можно научиться всему. Такой непрекращающийся интенсив длиною в несколько лет.
- Набить шишек под присмотром ментора.
- Научиться новым интересным технологиям или инструментам.
- Поработать над разноплановыми проектами — как по тематике, так и по сложности.
- Заработать себе портфолио.
- Научиться работать в команде.
- Научиться работать в команде в условиях постоянного стресса.
- Стать гибким, уметь переключаться с одной задачи на другую и при этом минимально терять темп.
- Научиться работать быстро.
- Узнать азы устройства бизнеса.
- Уяснить, как устроен процесс работы над программным продуктом: методологии, стандарты.
В продуктовой команде всё немного по-другому.
Продуктовая разработка
Программисты, которые ушли из студии и устроились в продукт — как правило, говорят о том, что там спокойнее. «Бесконечный» характер работы и отсутствие того самого подгорающего фитилька (и плеяды новых проектов на очереди) делают рабочий темп медленнее и вдумчивее.
У потоковой разработки в фокусе сроки — для студии их очень нежелательно сдвигать вперед (да и назад тоже). При плотной загрузке любой сдвиг идет в ущерб остальным проектам. Если при этом сроки растягиваются — то студия упускает прибыль.
В продуктовой разработке сроки важны, но не критичны. Здесь придерживаются философии: если сдвигаем — значит, совершенствуем, а значит, создаем потенциально более успешный продукт.
Ну это утрированно, но в целом так.
В продукте сильнее бизнес-составляющая. Собственно, та система координат, в которой работает вся команда, от продакт-директора до стажера — это целевые пользователи, конверсии, маркетинговые исследования и так далее. Просто так собраться кучкой и решить «а давайте следующий сайт запилим на Реакте!» — не получится. Маркетологи скажут, на чем, почему и зачем вы будете делать следующий сайт.
- Думать как конечный пользователь проекта и решать его задачи.
- Смириться с тем, что маркетинг и задачи бизнеса важнее технологий.
- Побыть внутри устоявшейся команды (возможно, даже с тимбилдингом, но это не точно).
- Брать на себя ответственность за успех или неуспех продукта.
Сложно сказать, где команде работается лучше. Потоковая разработка — это отличное место для прокачки и развития «по горизонтали». Продуктовая — для углубления в какую-то одну тему. Вряд ли вы встретите человека, который бы хотел вернуться в потоковую разработку после продуктовой — как ни крути, а в продукте спокойнее (правда, если это типичный стартап, то «спокойствие» будет выражаться во впахивании по 12 часов в сутки).
Теперь о менеджменте всего этого.
Менеджер продукта и менеджер проекта — в чем разница
Проектная разработка
Менеджер проекта — это «свой парень». То есть, конечно, он немного из другой касты, но команда понимает: менеджер их защитит от неадекватных правок и нервотрепки.
Однако тот же самый менеджер плохо защищает от внутренних марш-бросков с одного проекта на другой, работы над несколькими проектами сразу и так далее. Получается, что парень свой, но себе на уме — так думает команда.
С точки зрения экспертности проект-менеджера — он выступает для заказчика «консультантом по технологиям», дает экспертное мнение именно с точки зрения работы над проектом (а никак не с точки зрения бизнеса, здесь любая студия целиком полагается на экспертизу заказчика).
В чем заключаются главные функции проект-менеджера: обеспечить равномерную нагрузку на ресурсы, не промотать сроки, проконтролировать результат и продать готовую работу заказчику.
Продуктовая разработка
Вроде бы это тот же менеджер, вид сбоку, но нет. Главное отличие — продакт-менеджер является представителем бизнеса (умное слово: стейкхолдером).
На проектной разработке главным источником угрозы был заказчик — со всеми этими «я вам правочек принес», внезапными новыми идеями и поездками в отпуск. Поэтому менеджер был таким «фильтром», смягчающим внешнее воздействие на команду, защитником.
На продукте внешней угрозы нет — все работают над одним большим делом. Следовательно менеджер для команды сам становится источником угрозы. Для них он — как номенклатурный работник для простых работяг.
Соответственно, если менеджер переходит из потоковой разработки в продуктовую, его главная боль — научиться жить с тем, что он теперь еще в большей степени другая каста, нежели был раньше.
Что еще стоит добавить. Все умные методологии и роли, которые в них есть — изначально разрабатывались для продуктовых команд. Где реально делать ежедневные стендапы со всей командой и владельцем продукта. Где продакт-овнер — роль настоящая, а не номинальная. Где скрам — так скрам.
Всё-таки на заказной разработке мало когда нужны эти самые поэтапные запуски, тестирование гипотез и прочая. Наше дело простое.
Применение всего этого опыта на заказной разработке — допустимо, иногда полезно, но не всегда обязательно.
Ну всё вроде бы
Понятно, что всех аспектов одной маленькой статьей не охватить, но мы хотя бы попытались. Есть ли третий путь, что-то между потоковым «клепанием» проектов одного за другим и усердным бдением над продуктом? Да, есть — но об этом расскажем потом.
Кстати, можно подписаться на наши пуши (вон там снизу справа колокольчик) — тогда свежие статейки будут поступать вам сразу по готовности.
Источник: spark.ru
