Сейчас практически невозможно представить бизнес без интернет-представительства — даже у самых маленьких компаний есть свои сайты. Часто на начальном этапе у организации нет возможностей для разработки полноценного ресурса с хорошим дизайном и функционалом. В этом случае многие ограничиваются бесплатными платформами и стандартными шаблонам, однако по мере развития компании возникает необходимость в создании качественного сайта, например, интернет-магазина, не зависящего от ограничений бесплатных инструментов. Многим непонятно, с чего начать его разработку.
Прежде всего определитесь с типом сайта. Все интернет-проекты можно поделить на три большие группы.
- Маркетинговые — создаются, чтобы привлечь новых пользователей / клиентов, рассказать им о продукте и перевести на следующий этап взаимодействия. Яркий пример — лендинговые страницы. Их цель — конверсия, они должны отсечь случайных посетителей и заинтересовать целевую аудиторию. С точки зрения разработки это самые простые сайты, главное здесь — сформулированное УТП, выверенные характеристики продукта и четко определенная ЦА.
- Информационные — сайты-визитки и корпоративные сайты. С их помощью компания рассказывает о себе, своих проектах и товарах, предоставляет потребителям контактные данные. Многим организациям, таким как госкомпании, сайт необходим для публикации предусмотренной законом публичной отчетности и т.д. С точки зрения реализации это также несложные проекты, главную роль здесь играют дизайн и контент. Самое главное — заказчик должен знать, что он хочет получить в итоге.
- Сложные веб-проекты взаимодействуют с пользователями / клиентами; это интернет-магазины, B2B-порталы, веб-сервисы, личные кабинеты. Сложность заключается в том, что эти проекты, как правило, интегрированы во внутренние учетные системы клиента (1С, CRM, ERP) и должны органично встроиться в их функционал. Если что-то поменялось на сайте, изменения должны отобразиться во внутренних системах, и наоборот: изменения в системах должны отразиться в личных кабинетах, пользователи должны получить уведомления и пр.
Далее мы будем говорить именно о сложных проектах, т.к. в процессе их разработки возникает наибольшее количество проблем. Рассмотрим пошаговый алгоритм создания сайта.
ШАГ 1. ПОДБОР РУКОВОДИТЕЛЯ ПРОЕКТА
Самая большая ошибка заказчика — думать, что от него требуется только заплатить за работу. Из-за этого руководить созданием сайта со стороны клиента часто назначают менеджера по продажам. Логика проста: раз специалист умеет продавать, он должен отвечать за создание интернет-магазина, но при этом менеджер не знает, чем отличается поведение покупателя офлайн и онлайн, не понимает, что такое сайт, что может сделать разработчик, а что не может.
Важно, чтобы в команде заказчика был сотрудник, который не только умеет общаться, но и понимает, что такое IT-проект. Многим кажется, что штатный специалист по 1С справится с этим, но назначить его на роль руководителя проекта — тоже ошибка: у него всегда много своих дел, сайтом он будет заниматься по остаточному принципу.
Нужен человек, который может погрузиться в разработку сайта и не будет отмахиваться от исполнителя со словами: «Это ваши проблемы, вы профессионалы, вот и сделайте», — при подобном подходе проекты обычно проваливаются. Невовлеченный руководитель может поверхностно следить, что делают, «рисуют» и программируют другие. Он практически не глядя принимает работу, а после запуска сайта оказывается, что все работает не так, как задумано: первый же заказ не попадает в обработку или попадает, но по неверному сценарию, и т.д. Минимальными правками проблему не решить, все приходится переделывать заново, а это подразумевает финансовые и временные затраты и потерю прибыли.
ШАГ 2. ВЫБОР ПОДРЯДЧИКА
Как показывает наш опыт, компания с низкой стоимостью проектов может создать очень хороший сайт, а раскрученная большая компания с дорогими проектами может разработать плохой. Вторые обычно страхуют себя сложными формулировками в договорах и фактически перекладывают вину на заказчика (чаще всего это касается сроков предоставления данных, форматов этих данных и т.п.). Претензий они не принимают, но соглашаются внести правки — естественно, за отдельную плату. От крупных веб-разработчиков клиенты нередко уходят недовольными и дорабатывают проект с компаниями, предлагающими более низкую цену.
Чтобы не ошибиться при выборе подрядчика, можно предпринять следующие шаги:
- Просмотреть рейтинги («Тэглайн», Ruward, Рейтинг Рунета и др.). Компании в верхних строчках рейтинга, скорее всего, будут иметь соответствующие цены и условия. Если вы все же решитесь обратиться к ним, то имейте в виду, что у них часто есть очередь заказов, которую они не будут двигать ради нового клиента.
- Поговорить со знакомыми. Личные рекомендации — самый оптимальный вариант. Узнайте у партнеров или коллег в профильных группах в социальных сетях, кому они заказывали разработку сайта, понравилось им сотрудничество или нет.
- Изучить опыт конкурентов или аналогичные проекты в вашей отрасли. Если вам нравится какой-то сайт, то можно обратиться в компанию, которая его сделала.
После сбора информации вы сформируете перечень потенциальных исполнителей, из которых будете выбирать. Чаще всего заказчик идет по самому простому пути: «Мне нравится такой-то сайт, сколько стоит сделать такой же?» В ответ он получает несколько предложений. На данном этапе у заказчика есть собственное представление о стоимости проекта, и он выбирает тех, кто предложил чуть меньшую, чуть большую или подходящую сумму. Дальше он пытается сбить цену, обсуждает нюансы заказа и сотрудничества, знакомится с портфолио потенциальных исполнителей и выбирает, с кем будет заключен договор. Важно помнить, что каждый разработчик назначает цену исходя из своих представлений о «таком-то сайте», которые могут не совпадать с видением заказчика. Даже если сначала удалось договориться, то в дальнейшем сумма может измениться — как правило, в большую сторону.
Как этого избежать? Заказчик должен подготовить бизнес-требования к проекту — самостоятельно или силами квалифицированного внешнего консультанта или эксперта со стороны исполнителя. Мы просим составить такой документ почти ко всем проектам, потому что детализация очень важна для грамотной оценки стоимости. В этом документе отражены следующие параметры:
- Общее словесное описание проекта — основное резюме. Например: требуется интернет-магазин таких-то товаров в таких-то сегментах, планируется такой-то объем продаж через столько-то лет.
- Основной перечень объектов. Особенно важен этот пункт для разработки личных кабинетов и сложных B2B-проектов. Например: в личном кабинете должен отображаться заказ, отгрузочные документы, договоры, просрочки по договорам, все объекты, которые важны для проекта.
- Роли пользователей. Самые простые из них — незарегистрированные пользователи, зарегистрированные клиенты и администратор магазина. В B2B-проекте можно выделить роли главного бухгалтера клиента, менеджера, директора и т.п. У всех ролей может быть разный функционал, разные интерфейсы, разный уровень доступа к данным.
- Сценарии работы. Они могут варьироваться от минимальных (покупатель зашел на сайт, зарегистрировался, положил товар в «корзину», купил) до сложных (один человек положил товар в «корзину», другой подтвердил заказ, третий оплатил). В сценарии должны быть включены важные моменты, влияющие на работу или решения пользователя. Например, если у заказчика есть склады в разных городах, то важно, чтобы клиент мог видеть наличие товара в своем регионе, это обязательная часть сценария.
- Внешние системы, с которыми должен быть интегрирован проект. Например, у заказчика «остатки» и «цены» по товарам выгружаются из 1С, а информация о клиентах — из CRM; все продажи должны учитываться в бонусной программе.
- Показатели назначения. Когда заказчик хочет «такой-то сайт», исполнитель обращает внимание на каталог сайта-образца, фильтры и т.д., но может не учесть в своем предложении, что там размещено одновременно 6 млн товаров. Количество товаров — важный показатель назначения, на основании этого можно предлагать соответствующие системы. Например, если использовать для интернет-магазина с 6 млн товаров систему «Битрикс» со стандартными настройками, то при первом же запуске сайт упадет — стандартные настройки не предназначены для таких нагрузок. Если заказчик работает в сегменте b-2-b с оптовыми клиентами, то нужно понимать, сколько примерно у него клиентов: тысяча или сто тысяч. Если речь о заказах, то нужно знать примерное количество заказов в день, неделю, месяц, год. Если предполагается, что к заказу подгружаются документы, то нужно понимать их количество и «вес». Все это нужно, чтобы рассчитать, какие нагрузки должен выдерживать сервер. Шаблон бизнес-требований Представлен в Приложении 1.
Таким образом, при формировании бизнес-требований у заказчика появляется более осмысленное представление о будущем проекте. После составления бизнес-требований приходит очередь коммерческого предложения. В идеальной ситуации клиент должен предоставить потенциальному исполнителю request for proposal (RFP) — запрос на предложение, который должен быть грамотно оформлен. Иногда ограничиваются стандартным брифом, на основе которого формируют смету из 20 строчек: разработка дизайна, верстка, программирование каталога, интеграция и т.д. Некоторым заказчикам кажется, что эта смета позволяет подготовить шаблон для всех потенциальных исполнителей и просто сравнить, сколько стоит та или иная работа у разных подрядчиков. Например, один исполнитель берет за разработку функции поиска 20 руб., а другой — 200 руб. Очевидно, что сотрудничать с первым более выгодно, но так ли это на самом деле? Первый подрядчик просто проставит галочку в стандартной версии движка, а второй разработает отдельную поисковую систему, научит ее взаимодействовать с каталогом, она будет искать синонимы, узнавать ошибки и неправильную раскладку и т.д. Если у вас есть подробный RFP, то проблем с выбором подрядчика будет на порядок меньше.
ШАГ 3. НАЧАЛО РАБОТЫ
Техническое задание
Выбрав исполнителя, надо договориться о техническом задании (ТЗ), примеры ТЗ можно просмотреть вместе с представителями компании-исполнителя. Все зависит от уровня проекта. Например, в проектах крупных компаний на этапе сдачи должно быть передано огромное количество документации: архитектура проекта, ТЗ, документация для интеграции, руководства пользователя.
ТЗ должен составлять профессионал. Хорошо если заказчик обладает такой компетенцией, но лучше поручить эту задачу профессионалу. По ТЗ будет разрабатываться и сдаваться проект, в нем не может быть пять-десять страниц. Например, в нашей компании ТЗ на разработку интернет-магазина занимает более 100 страниц, и в нем описано все: подробные сценарии пользователя, все возможные передвижения по сайту, все реакции системы на клики пользователей и т.д. Возможно, иногда детализация излишня, но это многократно сокращает количество вопросов на этапе приемки. Например, во время приемки клиент может сказать: «На странице оформления заказа должно быть десять полей для заполнения с функцией проверки электронного адреса и телефона». Если эти условия не были описаны в ТЗ, то подрядчик может либо отказаться их выполнять, либо согласиться сделать это за дополнительную плату. Подробное ТЗ предотвращает конфликты в таких ситуациях.
С помощью ТЗ можно провести отбор компании-исполнителя. Вы выбираете подрядчика, поручаете ему сделать ТЗ и в это время определяете, насколько вам комфортно взаимодействовать. Стоимость написания ТЗ составляет 10–30% от стоимости проекта. Таким образом, проверка подрядчика обойдется относительно недорого: если он плохо работает уже на этом этапе, то и дальнейшее сотрудничество не сложится, а ТЗ пригодится вам в любом случае — его можно отправить другим исполнителям с просьбой оценить стоимость конкретного задания.
Гарантии
Перед началом работы необходимо выяснить, на каких условиях предоставляется гарантия. Обычно она длится год с момента сдачи, но небольшие компании часто не включают в договор никаких мер ответственности за то, что гарантия не будет предоставлена. Обязательно настаивайте, чтобы была указана скорость реакции на гарантийную проблему. Бывает так, что недостаток обнаруживается через месяц после запуска, но исполнителей ничто не обязывает быстро приступить к его устранению. Сколько денег вы за это время потеряете, представить сложно.
Также обратите внимание на условия оплаты (предоплата, постоплата, поэтапная оплата), на работу с выделенным менеджером в течение всего проекта. Мы советуем поэтапную оплату, чтобы в случае серьезных разногласий прекратить взаимодействие без серьезных финансовых потерь.
План-график
Разработка сайта — это услуга, а не товар, и ценность этой услуги создают обе стороны. Заказчик всегда должен участвовать во всех этапах разработки. Минимальное участие заключается в:
- предоставлении контента;
- согласовании структуры и дизайна сайта;
- своевременном заключении нужных договоров со сторонними подрядчиками (например, с банком, службой доставки и т.д.);
- проработке внутренних процедур, документации, регламентов.
Например, вы хотите, чтобы в интернет-магазине продавались товары, осуществлялась доставка, рассчитывалась ее стоимость, принимались платежи, но к моменту, когда исполнитель предоставляет вам готовый дизайн и почти готовый магазин, выясняется, что банк и компания для доставки не выбраны, внутренние регламенты обработки заказов не продуманы. В результате работа останавливается на неопределенное время.
План-график является приложением к договору. В нем должно быть расписано, какая информация и когда должна быть предоставлена заказчиком. Ответственность заказчика очень важна. Если компания-разработчик об этом не говорит, то стоит подумать о смене исполнителя — с вероятностью 90% ничего хорошего из сотрудничества не выйдет.
Методология разработки проекта
Сейчас распространены две методологии разработки проектов: Waterfall (классическая) и Agile (гибкая).
В методологии Waterfall проект делается последовательно: ТЗ, проектирование, запуск сайта. Некоторое время эта схема хорошо работала, но если мы говорим о разработке сложного проекта, то за полгода, прошедших с момента написания ТЗ, многие технологии могут измениться и проект устареет уже на момент релиза. Главное (и единственное) преимущество этой методологии — управляемость: из ТЗ заказчик понимает полную стоимость проекта и точное время, нужное для его реализации, но часть заложенного функционала может не сработать, а то, что могло бы принести прибыль, не будет заложено в ТЗ, поскольку в тот момент казалось неважным.
В методологии Agile проект делается не последовательно, а частями — спринтами. Команда составляет список необходимых функций (backlog) и определяет длительность спринтов: три недели, месяц, полтора месяца и т.д. Дальше backlog ранжируется по степени важности для проекта: жизненно важные функции реализуются в первом спринте, средней важности — во втором и т.д. В процессе работы перечень функций может пополняться, могут меняться приоритеты. Такой подход позволяет гораздо быстрее выполнять ключевые задачи проекта, гибко реагировать на внешние изменения и появление новых технологий. Еще один плюс Agile — возможность запустить проект с частичным функционалом. При работе по методике Waterfall это невозможно.
Например, интернет-магазин можно запустить уже после первого спринта, в рамках которого создан каталог товаров. Пока программисты продолжают создавать функционал, заказы можно принимать по телефону, маркетологи компании могут работать над привлечением трафика и увеличением конверсии. В процессе работы неизбежно всплывут проблемы, которые можно оперативно исправить (например, при создании каталога не учли важные характеристики товаров, о которых постоянно спрашивают покупатели).
Однако есть и минусы. Например, иногда приходится переделывать какую-то функцию целиком. В конце разработки может обнаружиться, что сделанное в самом начале неоптимально. Еще один минус — заказчик не знает точной стоимости проекта. На начальном этапе исполнитель может назвать только стоимость работы команды за единицу времени и примерную продолжительность работы.
Мы рекомендуем использовать Agile в работе со стартапами, когда неизвестно, как новый сервис будет воспринят на рынке.
Риски
Грамотные исполнители в самом начале работы составляют перечень рисков проекта — таблицу, в которой указаны: риск, степень его влияния на проект и способы его минимизации. Пример такой таблицы представлен в Приложении 2. Этот документ может показаться лишним, потому что некоторые риски проговариваются на более ранних этапах сотрудничества. Например, если на будущем сайте предусмотрен эквайринг, то существует риск не заключить договор с банком вовремя. Этот риск имеет низкое влияние на проект, способ его избежать — заранее начать выбор банка и заключить договор на обслуживание. Более серьезный риск возникает, если заказчик и исполнитель никак не могут согласовать дизайн, идет череда доработок по замечаниям, но окончательный вариант все не утверждается. Здесь есть вероятность вообще не начать работу над сайтом.
Мелочи, такие как простой с договором на эквайринг, обычно тормозят проект в самый неподходящий момент. Опытные исполнители могут составить примерный перечень рисков исходя из собственной практики. Эти риски желательно заранее проработать, их должны знать и учитывать менеджеры с обеих сторон.
Отдельно стоит обратить внимание на риск затягивания проекта. Составляя вместе с клиентом ТЗ, исполнитель считает, сколько потребуется времени — например, 200 часов. Разработчик не может работать больше 140 часов в месяц, значит, для реализации требуется 1,5 месяца, но по истечении срока проект оказывается не готов. К этому могут привести несколько причин.
- Информация от заказчика передана несвоевременно (такого рода проблемы встречаются в 99% случаев). Например, нужно интегрировать сайт с 1С, но специалист со стороны заказчика уходит в отпуск, потому что заказчик не подумал об этом заранее. Для исполнителя такая ситуация невыгодна, поскольку обычно заказчик оплачивает только время работы над проектом, но не простои. Чтобы не терять время и деньги, исполнитель переводит разработчика на другой проект. К тому времени, когда клиент предоставляет информацию, разработчик уже не может быстро вернуться к исходному проекту — сначала он должен закончить текущую работу. Получается, что время упущено с обеих сторон.
- Нет контроля со стороны заказчика. Хотя задача рассчитана на 140 часов и полтора месяца, исполнитель может получить срочный или более выгодный заказ от другого клиента, и разработчик с вашего проекта переключится на него, потому что он лучше всех справляется с такого рода задачами.
- Медленное реагирование заказчика при согласовании. Например, исполнитель разработал дизайн и ждет утверждения неопределенное время, вносит правки — и снова ждет. Это тоже ведет к простоям и риску, что разработчики переключатся на другие проекты. Менеджер заказчика должен знать, когда ему пришлют дизайн, и заранее договориться о встрече с директором, чтобы все утвердить и избежать потерь времени.
- Недооценка стоимости проекта. Чем хуже ТЗ, тем больше будет недооценка. Недооценка — большой минус для заказчика, потому что при кажущейся экономии он получит на выходе сырой продукт. Если разработчикам потребуется больше оговоренного в договоре времени, то задача окажется финансово неинтересна исполнителю, и он вступит в конфликт, добиваясь увеличения бюджета всеми способами или перекинет команду на более выгодный проект. Заказчик при этом рискует либо не получить нужный функционал, либо вообще остаться без сайта.
Промежуточный контроль
На старте проекта очень важно определить, как будет осуществляться промежуточный контроль. Оптимальное решение — назначить точки контроля и подготовить соответствующее приложение к договору. Например, написано ТЗ, создан и согласован дизайн интернет-магазина. Разработчики обещают, что все будет готово через три месяца. Как заказчик может понять, что что-то идет не так? Он может, например, поинтересоваться ходом работы через месяц и получить от исполнителя ответ: «Все хорошо, уже готово 45% проекта». Как понять, что входит в эти 45%?
Наш опыт показывает, что выстраивать контроль можно в любой удобной форме, главное — договориться об этом. С кем-то из клиентов мы устраиваем еженедельные встречи с презентациями, с кем-то достаточно регулярных звонков и переписки с отчетами.
Помните, что в работе у исполнителя всегда находится несколько проектов, и в приоритете будут те, которые находятся под постоянным контролем заказчиков. Работа с остальными будет выстроена по остаточному принципу. Кроме того, исполнители назначают на проекты беспокойных клиентов больше разработчиков, чем на проекты нетребовательных. Если подрядчик категорически отказывается подчиняться контролю, то есть повод задуматься, надо ли продолжать взаимодействие с ним.
ЗАКЛЮЧЕНИЕ
Итак, для разработки качественного сайта заказчику необходимо:
- подготовить бизнес-требования;
- составить ТЗ;
- определить риски проекта;
- выбрать методологию разработки;
- провести конкурс подрядчиков;
- выбрать сотрудника, который будет курировать проект.
Возможно, вам покажется, что не все эти пункты важны, но чем больше времени и сил вы потратите на подготовительном этапе и при заключении договоренностей с исполнителем, тем меньше проблем у вас будет в процессе работы и эксплуатации сайта.
ПРИЛОЖЕНИЕ 1.
Шаблон бизнес-требований проекта
Аннотация
В настоящем документе зафиксированы верхнеуровные бизнес- и функциональные требования к реализации проекта _______.
ОБЩИЕ ПОЛОЖЕНИЯ
Сокращения и термины
Термины, которые будут использованы в документации.
|
Термин |
Определение |
|---|---|
|
ТЗ |
Техническое задание. |
|
… |
… |
Ссылки
Все внешние ссылки и названия документов, которые встречаются в ТЗ.
|
№ |
Ссылка |
Описание |
|---|---|---|
|
1 |
Веб-сайт Amazon.com |
|
|
… |
… |
… |
Наименование системы
Полное и короткое.
Краткий обзор проекта
Краткое описание сути проекта: разработка нового или доработка существующего сайта, его предназначение и др.
Сведения об объекте автоматизации
Описание текущего положения вещей в компании заказчика: какие информационные системы используются, как работают затрагиваемые проектом функции в данный момент.
ОПИСАНИЕ СИСТЕМЫ
Бизнес-сценарий
Краткие сценарии работы всех ролей пользователей с точки зрения бизнеса (без исключительных ситуаций и деталей реализации).|
Шаг |
Актор |
Действие |
|---|---|---|
|
1 |
Потенциальный участник программы |
|
|
2 |
Сотрудник компании |
Утверждает заявку в 1С |
|
3 |
Участник программы |
Получает уведомление о подтверждении заявки |
|
4 |
Участник программы |
Знакомится с функциональностью и правилами бонусной программы в личном кабинете |
|
5 |
Клиент |
Совершает покупку при содействии участника программы |
|
6 |
Сотрудник компании |
Связывает в 1С покупки клиента с участником программы |
|
7 |
1С |
Выгружает связку на сайт |
|
8 |
1С |
Начисляет бонусы на счет участника программы через 30 календарных дней |
|
9 |
1С |
Обновляет баланс бонусного счета на сайте |
|
10 |
Участник программы |
При достаточном балансе бонусного счета заказывает дисконтные карты для себя и своих сотрудников |
|
11 |
– |
Сценарий завершен |
Роли пользователей
Список ролей пользователей, краткое описание основных функций каждой роли. Например: Гость — любой неавторизованный посетитель сайта. Он просматривает каталог, формирует заказ.
Ограничения системы
Искусственные ограничения проекта, которые озвучены заказчиком (не путать с показателями ожидаемой нагрузки и требованиям к функциональности).
Компонентная структура системы
Перечень всех подсистем и внешних систем с их кратким описанием, схема потоков данных, компонентная схема.
Логическая структура системы
Перечень всех ключевых сущностей и крупных функций системы и их описание, правила создания, управления, взаимодействия и прочая информация, полученная от заказчика.
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К СИСТЕМЕ
- Требования к дизайну
- Требования к верстке
- Требования к языковым версиям
- Требования к программному обеспечению
- Требования к показателям нагрузки
- Требования к надежности системы
ПРИЛОЖЕНИЕ 2.
Таблица рисков проекта
|
Риск |
Описание |
Уровень риска |
Мероприятия |
|---|---|---|---|
|
Недостаточная поддержка проекта со стороны заказчика |
Недостаточный уровень администрирования и знания специфики бизнеса со стороны заказчика может привести к задержке планирования, выделения ресурсов, приемки проекта |
Низкий |
Снижение риска
Преодоление риска Информирование куратора проекта |
|
Недостаточная поддержки со стороны пользователей |
Недостаточная поддержка может привести к увеличению стоимости или продолжительности работы над проектом. Отсутствие фидбэка от определенных подразделений ведет к неполному / неправильному пониманию требований заказчика. |
Средний |
Снижение риска
Преодоление риска Мотивация сотрудников |
|
Несоответствие реализованных бизнес-процессов ожиданиям заказчика |
Возникает вследствие недопонимания бизнес-процессов заказчика и отсутствия согласования |
Низкий |
Снижение риска
|
|
Расширение функциональных требований |
Расширение функциональных требований к системе после завершения предыдущего этапа приведет к увеличению сроков и бюджета проекта. Из-за изменения архитектуры проекта может оказаться, что часть работы выполнена напрасно. |
Средний |
Снижение риска
Преодоление риска При назревающей необходимости расширения функциональных требований — обсуждение ситуации, принятие одного из следующих решений:
|
|
Недоступность членов рабочей группы (РГ) |
Физическое отсутствие пользователей, включенных в состав РГ, может замедлить решение вопросов, входящих в сферу их компетенции, и как следствие увеличить сроки. |
Низкий |
Снижение риска
|
|
Неполнота отражения ожидаемых результатов проекта |
Возникает, если не все решения, озвученные на встречах, зафиксированы в документах и выполнены. |
Средний |
Снижение риска
Преодоление риска
|
Статья опубликована в журнале “Менеджмент сегодня” №2(110), 2020
Оставить заявку на разработку интернет-магазина, маркетплейса, b2b-портала, личного кабинета