Требования к интернет проект

Менеджер интернет-проектов

Профессия «менеджер интернет-проектов» появилась в России недавно, но уже сегодня является весьма востребованной и перспективной благодаря наличию возможностей для реализации творческих замыслов и потенциалу для карьерного роста. Предложения работодателей и ожидания претендентов на позицию «Менеджер интернет-проектов» изучил в январе 2008 года Исследовательский центр портала SuperJob.ru.

На россиян, избравших эту профессию, возлагается ответственная миссия по решению комплекса задач по созданию и/или поддержке, продвижению и развитию интернет-проектов. Нужно демонстрировать различные навыки — от пользовательских до руководящих. В качестве управленца менеджер интернет-проектов должен участвовать в разработке стратегии интернет-проекта, его концепции и структуры, грамотно руководить и координировать действия подчиненных (программистов, дизайнеров, конструкторов и проч.). Потребуются также навыки проведения рекламных и маркетинговых кампаний, и все это в условиях ограниченных временных и финансовых ресурсов. Кроме того, менеджер интернет-проектов ответственен за сбор и анализ статистики посещаемости сайтов компании, составляет соответствующие отчеты. Одна из составляющих этой профессии – умение работать в бешеном ритме, оперативно реагировать на происходящие изменения и принимать ответственные решения, и, видимо, поэтому 70% людей, избравших эту профессию, моложе 30 лет, а 64% — представители сильного пола.

Специалистов в данной сфере пока не готовит ни один вуз страны, поэтому оптимальным образованием для менеджера интернет-проекта считается сегодня высшее техническое образование в области информационных технологий. Имеют диплом об окончании вуза 85% менеджеров интернет-проектов, остальные же пока могут похвалиться только незаконченным высшим образованием.

Средняя зарплата менеджера интернет-проекта в Москве составляет 50 000 руб., 36 000 руб. — в Питере, 25 000 руб. — в Нижнем Новгороде.

Требования к начинающим менеджерам интернет-проектов таковы: высшее или неполное высшее образование, знание основ интернет-технологий, опыт работы web-мастером, администратором сайта, контент-менеджером, seo-оптимизатором или менеджером по интернет-рекламе от 1 года. Как и 60% соискателей, претендент на эту должность должен продемонстрировать владение английским языком на базовом уровне, кроме этого необходимо хорошо знать пакет MS Office, иметь основные сведения об HTML и графических редакторах. Обладая вышеперечисленными навыками, можно рассчитывать на зарплату от 20 000 до 40 000 руб. в столице, от 15 000 до 27 000 руб. в Санкт-Петербурге, от 10 000 до 20 000 руб. в Нижнем Новгороде.

Более опытный соискатель, претендующий на 40 000–60 000 руб. в Москве, 27 000–45 000 руб. в городе Петра, 20 000–30 000 руб. в Нижнем Новгороде, помимо вышеперечисленного должен проработать не менее года в аналогичной должности, иметь опыт ведения интернет-проектов с «нуля», уметь составлять технические задания, а также обладать навыками бюджетирования и финансового планирования. Приветствуется также более уверенное владение английским языком (как минимум, на разговорном уровне) и прохождение специализированных курсов и тренингов, свидетельством об окончании которых, кстати, могут похвастаться 30% подобных специалистов.

Вы проработали в сходной должности более 3 лет, имеете опыт ведения переговоров, Вам удалось успешно реализовать несколько сложных проектов одновременно и при этом Вы считаете, что способны на большее? Смело можете претендовать на заметно более высокую оплату труда: 60 000-120 000 руб. в столице, 45 000-90 000 руб. в городе на Неве, 30 000-50 000 руб. в Нижнем Новгороде!

Регионы исследования: гг. Москва, Санкт-Петербург, Екатеринбург, Нижний Новгород, Новосибирск, Ростов-на-Дону.
Время исследования: январь 2008г.
Единица измерения: российский рубль.
Объект изучения: предложения работодателей и ожидания претендентов на позицию «Менеджер интернет-проектов».

Типичный функционал:
Решение комплекса задач по созданию, поддержке, продвижению и развитию интернет-проектов:
— Разработка стратегии интернет-проекта;
— Разработка концепции и структуры сайта;
— Постановка и контроль выполнения технических заданий;
— Подготовка материалов для информационного и графического наполнения сайта;
— Оптимизация и поисковое продвижение сайта;
— Анализ статистики посещаемости сайта;
— Планирование, проведение и анализ результатов рекламных и маркетинговых кампаний;
— Внедрение новых сервисов и проектов;
— Планирование и контроль сроков исполнения и бюджета интернет-проекта;
— Координация действий команды специалистов.

Требования к позиции: тип занятости — полный рабочий день;

Уровень оплаты труда специалиста определяется благосостоянием компании, переченем должностных обязанностей, опытом работы по специальности, уровнем развития профессиональных навыков.

Анализ информации по уровням оплаты труда специалиста:
(без учета бонусов, дополнительных льгот и компенсаций)

Регион Минимальный Максимальный Мода Медиана Нижний
квартиль
Верхний
квартиль
Среднее
арифметическое
Москва 20 000 120 000 40 000 50 000 40 000 60 000 48 620
Санкт-Петербург 15 000 90 000 30 000 36 000 27 000 45 000 36 150
Екатеринбург 12 000 80 000 30 000 30 000 24 000 36 000 29 570
Нижний Новгород 10 000 50 000 24 000 25 000 20 000 30 000 23 120
Новосибирск 12 000 60 000 20 000 28 000 22 000 35 000 28 160
Ростов-на-Дону 10 000 50 000 21 000 24 000 19 000 30 000 23 530

Исследование массива данных о заработных платах в исследуемых регионах позволяет выделить несколько основных зарплатных диапазонов, каждый из которых характеризуется определенным типичным набором требований и пожеланий к кандидату. Каждый последующий зарплатный диапазон включает в себя требования, сформулированные для предыдущих.

7 причин провала вашего интернет-проекта

Заметка написана для тех руководителей, кто имел негативный опыт заказной разработки сайтов для своей компании. Не поленитесь, дочитайте до конца. Может быть, это сэкономит вам несколько сотен тысяч рублей.

Возможно, прямо сейчас ваш сайт нужно переделать. Поводов для переделки может быть много: от банального устаревания дизайна до желания интегрировать сайт с внутренней инфраструктурой компании. Или добавить ему мобильности.

Нужно звать веб-разработчиков. И если у вас был опыт общения с этими милыми, добрыми людьми, и вам периодически хотелось подкрутить у них чего-нибудь в голове (отверткой), чтоб лучше работали — тому есть причины!

1. Цена вопроса

Допустим, вы решили переделать ваш устаревший сайт. Какой вопрос будет интересовать вас в первую очередь? В большинстве случаев — цена. Действительно, «сколько стоит сайт» — обычно первый вопрос, с которого начинается общение (это происходит практически в 100% случаях, а мы в СПАЙК принимаем по 4–8 таких звонков в день).

Почему?

Во-первых, цену можно сравнить. И самое главное — тут не надо разбираться, разжёвывать каждому разработчику все требования и нюансы, понимать, чем они отличаются (и отличаются ли) друг от друга. В отличие от мутных требований, которые, скорее всего, вы еще не можете четко сформулировать для себя сами (не знаю, чего хочу), цена — это конкретное число.

Во-вторых, цену можно отжать. После этого какое-то время чувствуешь себя героем. Ну и в принципе, раз ребята прогибаются — с ними приятно иметь дело 😉

В-третьих, названная цена снимает с вас ответственность за формулирование требований и переносит их на разработчика. Они обещают вам сделать проект за конкретные деньги.

2. Существенные критерии

Какие еще существенные критерии, кроме цены, у вас есть? Тут называют много: сроки, качество, компетенции… Вернее то, как, разработчики РАССКАЗАЛИ о своих сроках, качестве и компетенциях. Это называется «Зажигательность обещаний» 🙂

3. «Просто пришлите КП!»

Очень часто первоначальный сбор коммерческих предложений поручают тому, кого не жалко. (Замечу, что не всегда: в ответственных компаниях, которые понимают важность проекта, сразу выделяют толкового и ответственного человека и дают ему достаточно ресурсов и полномочий).

Тем не менее, ситуация, когда «собрать цены» поручают зеленому сотруднику две недели от роду, очень распространена. Такой сотрудник, как правило, не знает ни планового бюджета проекта, ни целей, ни технических деталей. Он не обладает достаточным опытом, авторитетом и компетенциями. Его мнение вряд ли будет учтено начальством при выборе подрядчика. Его личные перспективы на проекте — отдал КП и свалил в сторону.

Как вы думаете, будет ли такой человек париться из-за вашего проекта? Будет ли он досконально прорабатывать и продумывать с потенциальными подрядчиками оптимальную структуру и вдаваться в технические тонкости?

Скорее всего — нет. Скорее всего, как только студии начнут задавать ему много вопросов (а они начнут, если хотят подготовить почтенным людям почтенное коммерческое предложение), он переключит фокус на тех, которые таких вопросов не задает. И просто пришлет КП.

4. Выбор подрядчика

Итак, вот какие критерии выбора у нас набрались:

  • Цена: они должны хотеть мало денег;
  • Прогибаемость: они должны прогибаться;
  • Зажигательность обещаний: красиво поют (просто хор Турецкого!);
  • Не задают неудобных вопросов.
  • ПРИВЕТ ПОСЛУШНЫМ ИДИОТАМ!

    Коллеги, у меня вопрос: с чего вы взяли, что эти люди сделают вам проект? Если ответ «Ну, они же обещали» — читаем дальше 🙂

    5. Контракт — гарантия ВСЕГО!

    На самом деле — нет. Основных причин тому три:

    5.1. Поехали, потом заведешься

    Начинали ли вы ваш прошлый проект, не до конца понимая, что именно вы хотите получить на выходе? Скорее всего — да. Я сам так делаю. В общем-то, это нормально (именно поэтому так хорошо работает scrum), когда требования конкретизируются по ходу. Кому интересно, как это работает, — сходите потом по ссылке, почитайте!

    Однако цену-то мы хотим зафиксировать сразу. А требования — нет. Добавлять по ходу.

    Более того, в нашей культуре вполне себе нормой является отношение к подрядчикам «Мне плевать на их прибыль» и «Хочу результат за их счёт». По опыту работы с западными компаниями могу сказать, что в США и Европе это не так.

    Вопрос. Каким обманом вам ответит команда разработки, если поймет, что не сможет на вас заработать из-за постоянно растущих требований?

    Правильно. Плохим внутренним качеством. Качеством кода. Костылями.

    Особенно больно это аукнется на крупных проектах, когда вы попробуете их развивать и поддерживать. Все будет тормозить, глючить и ломаться. И никто не захочет брать такой проект на техническую поддержку за вменяемые деньги.

    5.2 Но мы же договорились!?

    Обычно со стороны и подрядчика, и заказчика контракт согласовывают первые лица компании. В общих чертах им все понятно.
    — Петрович — сделаешь?
    — Да!

    Дальше Петрович приходит к программистам, и там происходит примерно такой диалог:
    — Программисты, делайте!
    Программисты честно спрашивают:
    — Чо?
    — Ну вот ТЗ. Будет. В следующем месяце…

    Нормально. И потом, когда сайт готов:
    — Логисты, вот вам новый сайт! Следите теперь за заказами в админке. Вот доступы!
    [email protected]#%.

    Проблема в том, что договаривались одни люди, делать будут другие, а пользоваться — третьи. Буквально с первых секунд происходит разрыв ожиданий.

    5.3. Но мы же можем зафиксировать все требования!

    Ага, щас. Вот вам два примера:

    Машинки назывались «Инвалидка», или, по научному С-3Д («эс-три-дэ»). Устройство рядом — детище компании… Microsoft! Да, это «убийца» iPod — плеер Zune. По коричневому цвету видно, что продукт — полное говно рассчитан на молодежь.

    Что не так с обоими продуктами? У машины есть колеса, она ездит; плеер — играет, есть экран, листалка песен — колёсиком. Скорее всего, изделия ПОЛНОСТЬЮ соответствуют поставленным заданиям. Вроде как и функции все на месте, только пользоваться результатом не очень хочется.

    Этот ужас и кошмар обусловлен тем, что в техническом задании зачастую невозможно (или сложно) прописать нефункциональные требования. Даже если задаться целью получить максимально подробное описание проекта в ТЗ, это не удастся. Всегда будет повод двойной трактовки требований. И чем детальнее вы будете их расписывать, тем сложнее будет с ними работать. Но от двойных толкований вас это не избавит.

    Скорее всего, на проекте появятся какие-то переделки. И если вы прогнули разработчика в цене — готовьтесь, тут-то он вам и отомстит. Особенно если разработчик понял, что долгосрочные отношения с вами у него не получатся. Вы будете тратить многочисленные часы на препирательства, было ли это в ТЗ или нет («Ну, если не на самом контракте, то хоть на переделках-то я и заработаю»).

    Итак, реалии таковы, что контракт, который вы подписали и «договорились» — не гарантирует вам легкой жизни и успешного проекта. Увы.

    6. Мы УЖЕ опаздываем!

    Серьёзно. Как обычно стартуют проекты: приходит Большой Босс с паяльником, и говорит «Нам срочно нужен проект Х. И Мы УЖЕ опаздываем!». А паяльник такой большой, красный. И тут все начинают бегать-суетиться. Общая идея — если не сказать людям, что они уже опаздывают, если не загнать их в нереальные временные рамки — они расслабят булки и будут делать проект годами.

    Чем ответит разработчик на требования нереальных сроков?

    «Честный» ответит: «Не-е-е, это невозможно». И не получит контракт. А если вдруг получит, будет периодически раздражать заказчика нытьем «мы не успеваем», «мы опаздываем». Чем, собственно, будет очень нервировать заказчика, получит общественное презрение, порицание и дурную репутацию.

    «Опытный» ответит: «Сделаю». Заберет контракт. Потом по ходу работы будут бодрые рапорты: «Все по графику!», «Все по плану», а в последний день: «Извините, прилетели марсиане, увезли на Марс главного программиста, все сервера и исходный код. Нужно еще пару месяцев на доводку вашего проекта».

    Замечу, что «Опытный» получит по башке всего один раз, а «Честный» будет получать каждый день. Большой, красный паяльник у босса, желание показать конкурентоспособные сроки и возможность «потерпеть боль всего один раз» провоцируют разработчиков сразу говорить нереальные сроки. Ничего удивительного, что их часто срывают.

    7. Черные дыры

    В чем разница между адронным коллайдером и типовой компанией web-разработчиком? В том, что в коллайдере черную дыру только пытаются получить, а в компаниях разработки она реально есть!

    Как и чего там происходит — со стороны понять вообще невозможно. Бессистемность и непрозрачность рабочих процессов web-разработчиков — хорошо известный, но плохо излечимый феномен. Даже если процессы разработки хорошие, часто это непрозрачно для клиента. И это, конечно, способствует «хорошим» отношениям с заказчиком: появляется виноватый. В любой ситуации можно сказать: «Они там что-то намутили, поэтому все тормозит, глючит и работает не так».

    Что делать

    Собственно, я это все написал не для того, чтобы поковыряться в больной ранке у web-разработчиков и заказчиков.

    Во-первых, нужно понять, что современные web-проекты — это зачастую довольно сложно устроенные вещи. Мы уже давно не в песочнице. И заказать интернет-проект — это не тоже самое, что заказать двадцать кубов бетона (хотя, говорят, и там есть нюансы). Вариант «я им денег — они мне счастья» — не работает в принципе. Вариант «я им денег и ТЗ, они мне — счастья» — не работает тоже.

    На технически сложных web-проектах, которые глубоко завязаны на ваши бизнес-процессы (или могут их даже в корне изменить), необходимы:

  • Деньги (да, конечно).
  • Актуальные требования и ожидания (вместо один раз за коленке написанного ТЗ). Тут, кстати, хорошо поможет scrum с возможностью менять требования на ходу и интерактивные прототипы вместо толстых ТЗ, которые никто не читает.
  • Поддержку в поле власти. Проект должен получить добро на самом высшем уровне, а не быть инициативой мальчика-из-маркетинга вторую неделю на испытательном сроке. Чтобы разработчик имел потенциальную возможность получать нужную ему информацию от заинтересованных в проекте лиц в вашей компании.
  • Перспективу долгосрочных отношений (чтобы знал, что это проект ему поддерживать и развивать еще до-о-о-лго).
  • Время. Адекватное время на разработку системы. И адекватное время, которое руководитель проекта со стороны заказчика будет выделять на решение ключевых вопросов по проекту.
  • Достоверную и непротиворечивую информацию. До старта проекта важно учесть требования всех потенциально заинтересованных сторон: логистов, бухгалтерии, сэйлов, маркетинга и т.д.
  • Короче, всех, кого может коснуться сия напасть.
  • Что нужно требовать:

    Открытости. Разработчики должны объяснить, КАК именно они собираются добиться результатов. Не просто обещания, а четкий и понятный план, как именно требуемый результат появится в нужные сроки. Какие техники будут применяться на прототипировании, дизайне, планировании итераций, или планировании сроков всего проекта, разработке, ежедневном контроле, тестировании, отчетности или технической поддержке.

    И только в такой конфигурации на вашем проекте может наступить простое человеческое счастье 🙂

    Всем добра.
    4 июля 2014 г.

    Благодарности:
    Сергею Бережному за умные мысли 🙂

    Вся правда о разработке сложных интернет-проектов

    Валерия Жентерик (Максименко)

    Что скрывается под понятием «сложный интернет-проект»? Каковы его основные отличия от шаблонных сайтов? А самое главное, какое решение подойдет для определенного бизнеса и конкретного заказчика? Раскроем всю правду.

    Итак, начнем с определения. Под сложным интернет-проектом понимается прежде всего индивидуальная разработка сайта. Конечным продуктом в таком случае должен стать уникальный интернет-ресурс, не имеющий аналогов в сети.

    Если вы или ваша компания решили обзавестись сайтом, то в первую очередь нужно ответить на такие вопросы, как: «Зачем мне нужен сайт?», «Что я хочу от него получить?» и «Каким я хочу его видеть?». Не менее важно определиться с ресурсами — сколько времени вы готовы ждать и сколько денег вы готовы потратить.

    Компании-разработчики, опираясь исключительно на ваши потребности и пожелания, будут предлагать вам различные решения — как шаблонные сайты с определенной структурой и готовым дизайном, так и индивидуальную разработку.

    Так в чем же отличие шаблонов от сложных проектов?

    Зачастую стандартные подходы при разработке сайтов оказываются неэффективными. Индивидуальные решения, напротив, обеспечивают хороший результат и максимальную отдачу в будущем. Именно поэтому создание уникальных сайтов стоит дороже, чем покупка уже готового решения. А что касается времени, то на разработку сложного сайта его уйдет на порядок больше.
    Несмотря на это, профессионально изготовленный индивидуальный сайт способен стать эффективным инструментом для управления бизнесом в Интернете, привлечь клиентов, повысить статус компании и достаточно быстро окупить затраты.

    В основе индивидуальной разработки лежат четыре базовых принципа:

    1. учет пожеланий заказчика;
    2. эксклюзивный дизайн;
    3. уникальная структура;
    4. возможность реализации сложного функционала.

    Индивидуальная разработка дает свободу в реализации задуманных функций в работе сайта. Большим плюсом является то, что клиент в итоге получает то, что хочет, не жертвуя при этом какими-либо нужными функциями и возможностями в работе сайта, не соглашаясь на готовое решение. Процесс создания индивидуального сайта отличается высокой степенью детализации и проработки.

    Все начинается с идеи, или свобода творческого мышления

    Путь создания действительно уникальных проектов — это свобода творческого мышления. Индивидуальный подход к разработке не ограничивает полет творческой мысли, а наоборот — способствует его развитию.

    Что определяется в самом начале? В первую очередь — это общая концепция или основная мысль. Здесь важно разумно соотнести множество идей с возможностью их реализации. Необходимо четко оценивать существующие ресурсы и, опираясь на них, рассматривать разнообразные решения, предлагаемые разработчиком.

    Здесь на помощь заказчику приходит слаженная работа проектной команды. Работа проектной команды — это комплекс мероприятий, направленных на получение качественного продукта, полностью удовлетворяющего ожидание клиента и запросы конечных пользователей.

    Еще на этапе разработки концепции все участники команды должны прийти к единому мнению, выработав в дальнейшем четкую схему всех действий, направленных на желаемый результат. Участники проектной группы должны постоянно взаимодействовать, обмениваясь идеями и советами. Каждый специалист должен не просто выполнять операцию, но и согласовывать свои действия с остальными участниками.

    Каждый участник команды является квалифицированным специалистом в своей области, однако это не должно лишать его возможности видения всего проекта в целом и составляющих его этапов. Цель проекта должен понимать каждый. Например, при разработке дизайна важно понимать, каким образом его можно будет реализовать, при составлении схем страниц важно учитывать дизайн-концепцию.

    Впрочем, всю разработку сайта можно поделить на четкие этапы:

    1. Проектирование — это составление технической документации, определение функционала и отрисовка схем страниц. Данный этап дает возможность отразить предварительное видение будущего сайта, а также быстро внести корректировки и пожелания клиента касательно структуры сайта.
    2. Дизайн — графическая проработка внешнего вида сайта. При индивидуальной разработке дизайн является уникальным для каждого проекта — учитывается фирменный стиль компании, а так-же пожелания и рекомендации заказчика. При помощи дизайна необходимо сформировать первое впечатление о компании, повысить уровень доверия у потенциальных клиентов. Основная задача — привлечь внимание настолько, чтобы посетителю не захотелось уйти на сайт конкурентов.
    3. Программирование — это трудоемкий процесс создания сайта на основе CMS (Content Management System — система управления содержимым сайта). На данном этапе осуществляется настройка функциональных модулей системы и написание программного кода для реализации индивидуального сайта. Завершает процесс верстка — наложение графического изображения (дизайна) на программную часть сайта.
    4. Тестирование — проверка работоспособности функционала сайта и оперативное исправление ошибок в случае их обнаружения. На данном этапе важно оценить готовность сайта и проверить его на наличие ошибок.
    5. Наполнение — размещение на сайте актуального контента, ориентированного на интересы целевой аудитории. Наполнение осуществляется непосредственно перед запуском сайта.

    6. От того, насколько профессионально выполнена разработка индивидуального сайта, зависит эффективность его воздействия на аудиторию.

      Чтобы ресурс отвечал всем потребностям целевой аудитории, нужно знать, как она представлена в Интернете, какие предпочтения имеет, в чем ее специфика и как лучше вести с ней диалог.

      Значительную роль в этом процессе играет юзабилити (удобство использования) сайта, а также дизайн, который должен выгодно представлять компанию на фоне конкурентов. Важно, какое впечатление производит дизайн на посетителя. Знакомство с сайтом осуществляется при первом беглом просмотре страницы, на которое уходит 2–3 секунды. Именно в это время необходимо захватить внимание посетителей.

      Как известно, по статистике, если дизайн сайта не привлекает посетителя, то он незамедлительно покидает этот ресурс. Внешний вид сайта должен соответствовать вкусам и предпочтениям целевой аудитории. Понимание запросов и психологии пользователей — есть показатель профессионализма разработчиков.

      Еще одной приоритетной задачей при разработке сайтов является обеспечение комфортной работы владельца с собственным ресурсом. Разработчик должен предоставить заказчику инструкцию по наполнению сайта и обучить основным моментам для самостоятельного управления сайтом.

      Работа с клиентами или о чем еще следует сказать

      Важное место в процессе разработки занимает проект-менеджер. Он является связующим звеном между заказчиком и проектной командой. В задачи работы менеджера входит понимание клиента и знание технической стороны создания сайта. На нем лежит ответственность в принятии важных решений по ходу работы, а также контроль и согласование действий всех участников процесса разработки.

      Каждый клиент уникален по-своему. Понять клиента — основная задача менеджера. Менеджер должен уметь выслушать все вопросы клиента и суметь дать на них должный ответ. Поэтому здесь важна полная осведомленность по проекту, а также других процессов работы (документооборот, оплаты, сроки и стоимость работ).

      Решение проблем не должно быть конфликтным. Менеджер должен понимать клиента и стараться предлагать ему несколько вариантов решений. Нельзя доводить проблемы до спора, потому что это понижает доверие клиента и негативно сказывается на дальнейшем общении.

      Постпроектная работа или что нас ждет впереди

      С каждым днем происходит развитие информационных технологий, появляются различные устройства, с помощью которых можно выйти в сеть Интернет, совершенствуется программное обеспечение. При создании сайта необходимо не только следить за новинками, но и успешно применять их в разработке. Проекты должны отвечать современным требованиям.

      После завершения проекта очень важно следить за его дальнейшим развитием. Большой ошибкой является «забрасывание» сайта после размещения его в сети. Он, как живой организм, за которым необходимо ухаживать. Необходимо отслеживать пользовательскую активность, регулярно обновлять контент, убирать неактуальную информацию и развивать функционал. При разработке проекта необходимо предусмотреть, как в дальнейшем его можно будет совершенствовать.

      В заключение хотелось бы отметить следующее: интернет-сайт может стать эффективным инструментом для развития вашего бизнеса, будь то готовый шаблон или сложный проект. Степень эффективности зависит от того, насколько внимательно вы подойдете к его разработке.

      Проекты и Интернет-проекты

      Под проектом принято понимать определенную последовательность задач, направленную на достижение конкретных целей в течение заданного периода времени, с установленными требованиями к качеству результатов и возможными рамками расхода ресурсов. Соответственно, успешность реализации проекта целиком зависит от соблюдения этих трех основных условий:

      1. Качество/Функциональность
      2. Сроки
      3. Ресурсы
      4. В действительности же эти критерии достигаются далеко не всегда и не всеми. Так, по данным за сентябрь 1998 PM Network на основе анализа 23 000 проектов по разработке прикладного программного обеспечения, только 26 % из них были успешными, 28 % были провалены, а для завершения 46 % проектов необходимо было увеличить сроки и ресурсы либо снизить требования к функциональности, либо изменить все вместе. На российском рынке это соотношение несколько иное и представляется, на мой взгляд, таковым:

        10%-10%-80%. Успешных проектов, как и проваленных относительно немного, поскольку большая часть претерпевает видоизменения в процессе выполнения — российский заказчик, в отличие от западного, более склонен вложить еще немного денег, пролонгировать сроки и получить желаемый результат, чем не получить ничего.

        Интернет-проекты, на мой взгляд, отличаются от традиционных проектов по созданию ПО/информационных систем. Если традиционный проект — это четкий план, строгая организация, жестко заданные параметры (например, проекты Microsoft), то Интернет-проекты — это скорее импровизация, творчество и развитие. Их характеризует высокая скорость реализации, высокие темпы изменений и высокий уровень неопределенности.

        В Интернет-проектах, как правило, определена лишь главная цель, общее направление, но отдельные задачи уточняются по мере достижения частных результатов. Заказчики/инициаторы часто не имеют четкого видения/детализации проекта в начале его развития, и только в ходе реализации их идеи кристаллизуются и находят точное выражение. Кроме того, стремительное изменение интернет-среды приводит к необходимости постоянного внедрения новых технологий. Все это требует от разработчиков гибкости мышления, импровизации и умения адаптироваться в постоянно изменяемых условиях.

        Типы интернет-проектов

        Рассмотрим классификацию интернет-проектов на основе следующих признаков:

      5. Масштаб
      6. Условия выполнения
      7. Назначение
      8. По масштабу интернет-проекта можно выделить:

        Небольшие проекты:

        Затраты на разработку оцениваются в 300-1000 человеко-часов (ч/ч). Команда разработчиков состоит из 2-х-5-ти человек. Продолжительность проекта — 1 — 3 месяца.

        Средние проекты:

        затраты на разработку оцениваются в 1000-10000 ч/ч. Команда разработчиков обычно состоит из 5-12 человек. Продолжительность — 2-10 месяцев.

        Крупные проекты

        затраты на разработку оцениваются в 10000 — 30000 ч/ч. Команда разработчиков обычно от 10-ти человек. Продолжительность от 6 месяцев до 1,5 лет.

        Очень крупные проекты

        Затраты на разработку оцениваются свыше 30000 ч/ч.

        Конечно, это деление достаточно условное. Масштаб проекта также определяется и его значимостью и статусом в ранге себе подобных. Для интернет-проектов характерен показатель длительности — в основном интернет-проекты относятся к разряду небольших проектов. Впрочем, сейчас с притоком инвестиций в интернет, идет тенденция к увеличению числа средних проектов. Крупных проектов пока достаточно мало.

        Если называть конкретные примеры, то к небольшим проектам можно отнести — http://www.bmw.ru, http://www.sistel.ru, http://www.academy.ru. К средним — http://www.24×7.ru, http://www.i2i.ru,; К крупным проектам в Рунете необходимо отнести Яндекс и Рамблер. Ну а http://www.Amazon.com, несомненно, относится к разряду очень крупных проектов.

        Существует и другой принцип определения размера проекта — стоимость. Примерная шкала для Рунета такова:

      9. Небольшие проекты — до тыс.
      10. Средние проекты — от до 0 тыс.
      11. Крупные проекты — от 0 — до 00 тыс.
      12. Очень крупные проекты — свыше млн.
      13. Активная конкуренции и борьба за место под интернетовским «солнцем» обозначила тенденцию так называемого «крэш-проектизма», когда интернет-проекты растут, словно грибы. У подобных проектов ограничения по срокам и/или ресурсам превышают норму более чем на 50 % и, как правило, это коммерческие и имиджевые сайты. В качестве собственного примера приведу опять же http://www.24х7.ru. Вообще, «крэш-проектизм» — это отдельная тема для разговора. Хочется лишь заметить, что в «крэш» может превратиться любой проект при неправильном планировании и управлении.

        По бизнес-назначению я бы выделила: коммерческие, «полу-коммерческие» и корпоративно — имиджевые.

        Коммерческие проекты подразумевают, что сайт является основным источником дохода либо играет важную роль в бизнес-модели компании. Задача при запуске проекта — как можно раньше появиться в Рунете, раскрутиться и привлечь максимальное количество аудитории. При продвижении данных проектах много средств уходит на рекламу и маркетинг. В качестве примеров можно назвать: интернет-магазины, которые имеют только виртуальные прилавки без физического представительства (http://www.24×7.ru , http://www.torg.ru , http://www.ozon.ru ), аукционы, B2B-сайты.

        У «полу-коммерческих» проектов сайт не является основным источником дохода, но все же приносит реальные деньги. Это, например, интернет-магазины, имеющие реальные прилавки (например, магазин издательства «ЛОРИ»). Или некоторые магазины компьютерной техники и .т.п. Интернет-магазин в этом случае не является основным источником продаж, а больше исполняет имиджевую роль.

        К этой же категории можно отнести представительства в интернете тур-фирм (бронирование билетов, гостиниц, заказы путевок), сайты многих газет и журналов, предоставляющих пользователям платную информацию. К таким проектам, полагаю, относятся сайты, рассчитанные на достижение максимального числа посещений, — топ-листы, мэйл-сервера, новостные сайты, развлекательные сайты и т.д.- проекты, доход которых основан на размещении рекламы (в виде баннеров или еще чего-либо). Затраты на рекламу таких сайтов значительно ниже. Корпоративно-имиджевые сайты. Цель данных проектов — выгодно представить компанию в сети, разместив информацию о себе, полезную для клиентов или рекламирующую свою продукцию. Сайт в данном случае не является прямым источником дохода. Например, web-система «БиЛайна» (http://www.beeplus.ru, http://www.beelinegsm.ru, http://www.beeline.plus ) «.

        Какова длительность разработки проекта с нуля, чтобы он был конкурентно способен (по типам)

        Время разработки проекта зависит от сложности проекта, от набора требуемой функциональности, от новизны задач, от необходимости применения новых технологий и т.п.

        Нужно различать два понятия — время, которое требуется на запуск интернет-проекта и время, которое требуется на полную разработку интернет-проекта.. В отличие от коробочного ПО, для интернет-проектов характерен поэтапный выпуск, когда разработка проекта разбивается на несколько логических этапов. Во время запуска проект должен содержать набор минимальной функциональности, ниже которой его конкурентно-способность близка к нулю. Особенно это показательно для коммерческих проектов, где временной разрыв между запуском и окончанием может быть достаточно существенным.

        Минимальный срок для запуска несложного (например, имиджевого) проекта составляет около месяца, для проекта средней сложности (коммерческие и полу-) — от 1-3-х месяцев, для сложных проектов — от 3-6 — ти месяцев и выше.

        Нередко встречаешься с предубеждением, что чем больше человеческих ресурсов будет затрачено на разработку проекта, тем скорее его можно завершить. У нас в компании на это существует одна показательная поговорка: 9 беременных женщин ребенка за месяц не родят. У проекта есть свой срок развития, не зависящий прямо пропорционально от количества задействованных людей. А переизбыток ресурсов, так же как и недостаток, отрицательно влияет на ход проекта.

        Сколько проект может стоить (только разработка, разработка и сопровождение). Только оценки порядков.

        Стоимость проекта складывается из нескольких составляющих:

      14. Затрат на разработку
      15. Стоимости hardware
      16. Стоимости лицензионного ПО
      17. Стоимости маркетинговых и рекламных компаний
      18. Затраты на структуру поддержки и ведения проекта
      19. Стоимость разработки обычно оценивается методом подсчета затраченных человеко-часов * на определенную стоимость специалиста в час, установленную в компании для продажи проектов. Для Рунета эта цифра составляет примерно — в час. Стоимость крэш-проекта, как правило, превышает норму в два-три раза. Полагаю, что у каждой компании есть свой определенный минимум стоимости. Но возможны и исключения, в случае если проект окажет положительное влияние на имидж компании.

        Затраты на стоимость hardware & software зависят от типа проекта.

        Если за единицу отсчета взять стоимость разработки проекта (100 %), то для коммерческих проектов (для которых требуются высокопроизводительные сервера и технологии) стоимость оборудования составляет 10-15%, а стоимость необходимого ПО может доходить до 40 % и более от стоимости разработки при использовании коммерческого ПО — коммерческих серверов БД (например, Oracle, Informix), серверов приложений (WebSphere, WebLogic) и т.д. Для корпоративно-имиджевых проектов стоимость размещения сайта обычно не превышает 5-10 %, так как сайт данного типа, как правило, устанавливается на выделенном оборудовании фирмы-заказчика или провайдера и использует его ПО.

        Стоимость маркетинговых исследований и рекламных компаний может превышать стоимость разработки в несколько раз (на коммерческих проектах), а может составлять небольшой процент или быть равной нулю (для корпоративно-имиджевых).

        Оценки порядков стоимости проектов уже приведены выше.

        Что является определяющим при выборе платформы (знания команды, эффективность решения или вообще такие факторы, которые к самой процедуре разработки отношения не имеют)

        Выбор платформы для интернет-проекта зависит от нескольких параметров:

        1. Профильной технологии компании-разработчика

        Компания может профилироваться на базе одной или нескольких операционных систем (Unix и/или Windows). Также возможно использование одной или нескольких технологий разработки проектов, самыми распространенными из которых являются:

      20. Windows/ASP/MSSQL
      21. Unix/perl-PHP/MySQL- PostgreSQL- Informix
      22. Unix/Java-JSP/Oracle

2. Знаний ядра проектной команды (разработчиков + руководителя)

3. Предпочтения клиента

4. Эффективности решений

5. Трудоемкости технологии

Примерчики наиболее типовых успешных и неуспешных проектов (лучше из вашего опыта, но можно и чужие).

Понятие успешности достаточно относительное, о котором я уже упоминала выше. Если за критерий взять два параметра — функциональность и популярность ресурса в целевой аудитории, то успешными можно назвать http://www.ozon.ru, http://www.24×7.ru, http://www.molotok.ru. Успешность с точки зрения функциональности необходимо рассматривать прежде всего с позиций:

  • Соответствие разработанной системы функциональным требованиям;
  • Отказоустойчивость;
  • Оперативность реагирования системы на запрос пользователя;
  • Интуитивность интерфейса;
  • Логичность организации системы (прозрачность, гибкость архитектуры, масштабируемость)
  • Впрочем, качество разработки не всегда является обязательным условием популярности ресурса. Популярность, помимо «хорошо сделанной» работы обеспечивается рекламными кампаниями и брэндом. Понятие «неуспешности» также достаточно относительное. А примеры на Ваш взгляд неуспешных проектов Вы можете обнаружить в сети сами.

    Разбивка по времени стадий проектирования и внедрения и их взаимосвязь

    Из личного опыта разработки проектов, соотношение между этапами проектирования, разработки, тестирования и внедрения получаются примерно следующие:

  • Проектирование — 20-30 %
  • Разработка — 50 %
  • Тестирование — 10 %
  • Внедрение — 1-5 %
  • Стабилизация — 10-15 %
  • В интернет-проектах, вследствие стремления их быстрого запуска, наблюдается тенденция к занижению времени тестирования системы. Часть стабилизационного этапа системы приходится уже на время ее запуска и тестерами становятся реальные пользователи.

    Ваша оценка вознаграждения команды и ее доля в общей стоимости проекта

    Мотивация команды разработчиков является необходимым условием успешности проекта. Материальный стимул является не последним фактором, влияющим на производительность труда и отдачу от разработчиков.

    Фонд вознаграждений проектной команды составляет примерно 30 % от стоимости разработки проекта. Как правило, фонд состоит из 2-х частей — постоянных выплат в ходе проекта (заработная плата) и дополнительных выплат. Порядок дополнительных выплат обычно устанавливается в начале проекта и может варьироваться в зависимости от проекта. Примерами дополнительных выплат могут служить оплата в ходе проекта запланированного или обоснованного овертайма (по удвоенным ставкам), премии разработчикам по итогам проекта. Распространены непрямые вознаграждения в виде повышения зарплаты или роста по служебной лестнице и т.п.

    Существует ли аудит проектных решений, если — да, то в чем он заключается

    Аудит проектов необходим. Для этой цели в компаниях, занимающихся веб-билдингом, существуют позиции технического директора и арт-директора,( и + соответствующие советы), которые принимают участие как на стадии проектирования, так и на стадии разработки проекта. Они должны направлять компанию по нужному технологическому пути развития и все технологии, которые применяются на проектах, должны пройти через их руки и головы.

    Практикум «УПРАВЛЕНИЕ ИНТЕРНЕТ-ПРОЕКТОМ»

    ОСОБЕННОСТИ И ОСНОВНЫЕ ЭТАПЫ ИНТЕРНЕТ-ПРОЕКТОВ

    Особенности разработки бизнес-плана интернет-проекта. Анализ требований к сайту

    В соответствии со Сводом знаний по управлению проектами РМВоК, разработанным американским институтом PMI, «проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата» [1] .

    Интернет-проект — это проект, в состав которого входят задачи по разработке и развитию интернет-ресурсов или интернет-технологий, а также их использование и продвижение на электронном рынке в сети Интернет.

    В качестве примеров различных интернет-проектов можно привести проекты разработки и продвижения корпоративных сайтов и порталов, интернет-магазинов или электронных торговых площадок, социальных медиа (социальная сеть, блог-платформа, онлайновые СМИ и проч.), облачных сервисов (SaaS или PaaS), а также проекты по созданию различных технологий поиска требуемой информации в интернете. В соответствии с руководством РМВоК, каждый интернет-проект подразумевает управление интеграцией, содержанием, сроками, стоимостью, коммуникациями, человеческими ресурсами, качеством, рисками, заинтересованными сторонами проекта, закупками.

    В цифровом бизнесе важнейшее место занимают инвестиционные интернет-проекты. Они создаются с коммерческими целями и, как правило, окупают вложенные затраты и приносят прибыль заинтересованным сторонам. Примерами инвестиционных интернет-проектов могут служить проекты создания и развития интернет-магазинов и электронных торговых площадок, интернет-сервисы, монетизация которых основана на рекламной модели или модели подписки, платные облачные SaaS- и PaaS- сервисы.

    В начале реализации инвестиционных интернет-проектов, как правило, разрабатывается бизнес-план, который включает в себя следующие разделы [2] .

  • 1. Резюме.
  • 1.1. Суть проекта.
  • 1.2. Данные об эффективности проекта.
  • 1.3. Сведения о фирме.
  • 2. Описание участников проекта и отрасли.
  • 2.1. Краткая информация об отрасли. Имеющиеся БТЕРЕЬ- факторы (экономические, технологические, политические, экологические, правовые и социальные).
  • 2.2. Общие сведения об участниках проекта.
  • 2.3. История, финансово-экономические показатели деятельности предприятий-участников.
  • 2.4. Структурная схема менеджмента проекта.
  • 2.5. 8УОТ-анализ.
  • 3. Описание продуктов (услуг).
  • 3.1. Базовые характеристики и сокращенное описание.
  • 3.2. Новизна, новые виды или качественное изменение продуктов (услуг), имеющиеся аналоги.
  • 3.3. Условия логистики.
  • 3.4. Уникальное ценностное предложение, конкурентоспособность, позиционирование.
  • 3.5. Другое (особенности налогов, наличие льгот и проч.).
  • 4. Маркетинг и сбыт продуктов (услуг).
  • 4.1. Рынок сбыта продуктов (услуг), описание основных рыночных сегментов, оценка спроса.
  • 4.2. Конкурентный анализ, позиционирование проекта.
  • 4.3. Цена продуктов (услуг), ценовая политика, программы лояльности.
  • 4.4. Каналы сбыта продуктов (услуг).
  • 4.5. Стратегия продвижения на рынок.
  • 5. Производственный план.
  • 5.1. Обоснование необходимости научно-исследовательских и опытно-конструкторских работ (НИОКР) и ожидаемые результаты.
  • 5.2. Технологии, качество и сертификация.
  • 5.3. Производственные площади.
  • 5.4. Оборудование.
  • 5.5. Материалы, комплектующие.
  • 5.6. Кадровое обеспечение.
  • 5.7. Энергетическое и инженерное обеспечение, связь и транспорт.
  • 5.8. Вопросы экологии и безопасности.
  • 5.9. Операционный план.
  • 6. Организационный план.
  • 6.1. Команда управления.
  • 6.2. Правовое обеспечение.
  • 6.3. Партнеры.
  • 6.4. Поддержка и льготы.
  • 6.5. Организационная структура реализации проекта.
  • 6.6. Календарный план (график реализации проекта).
  • 6.7. Характеристика активов.
  • 7. Анализ рисков.
  • 7.1. Идентификация и оценка рисков (сущность риска, вероятность возникновения, влияние на ход проекта), включая макроэкономические, политические и отраслевые риски; финансовые, коммерческие, организационные и технические риски проекта; социальные и экологические риски.
  • 7.2. Мероприятия по минимизации наиболее значимых рисков.
  • 8. Финансовый план.
  • 8.1. Первичная расчетная информация.
  • 8.1.1. Окружение: курс рубля, инфляция, налоги.
  • 8.1.2. Денежное вознаграждение персонала.
  • 8.1.3. Прямые производственные издержки.
  • 8.1.4. Общие издержки.
  • 8.1.5. Объемы инвестиций.
  • 8.2. Результаты расчета.
  • 8.2.1. Отчет о прибылях и убытках.
  • 8.2.2. Кэш-фло — отчет о движении денежных средств.
  • 8.2.3. Балансовый отчет.
  • 8.3. Источники финансирования и выплат.
  • 8.3.1. Собственные средства акционеров.
  • 8.3.2. Заемный капитал (кредиты).
  • 8.3.3. Рефинансирование прибыли.
  • 8.3.4. Выплата дивидендов.
  • 9. Анализ проекта.
  • 9.1. Финансовые показатели.
  • 9.2. Расчет основных показателей эффективности инвестиций (срок окупаемости проекта, НРУ — чистый приведенный доход, PI — индекс прибыльности, IRR — внутренняя норма рентабельности и др.).
  • 9.3. Анализ чувствительности, рисков, сценарный анализ.
  • 9.4. Анализ доходов участников.
  • 9.4.1. Денежные потоки участников.
  • 9.4.2. Эффективность инвестиций, вложенных каждым участником.
  • Рассмотрим ключевые моменты, являющиеся типовыми при создании новых сайтов, инвестиционных интернет-проектов, при использовании наиболее распространенных конструкторов сайтов и продвижении уже созданных сайтов в интернете.

    1. Определение целей и задач интернет-проекта.

    Вначале необходимо определиться с целями и задачами, которые будет решать будущий сайт. Цели необходимо привязать к стратегии компании, и в частности к планам по маркетингу и продажам.

    2. Анализ требований к сайту.

    Веб-сайт является информационной системой, и требования можно разделить на две большие группы: функциональные и нефункциональные.

    Функциональные требования к сайту включают в себя требования к основным функциям и сервисам сайта. Примерами являются: наличие каталога и корзины товаров, калькулятора, онлайн-оплаты, личного кабинета клиента, программы лояльности с автоматическим расчетом скидок и бонусов, онлайнового консультанта или экспертной системы, позволяющей подобрать нужный товар, сервиса отслеживания статуса доставки товара, сервиса расширенного поиска и проч. Важными являются требования к контенту сайта, количеству и качеству представляемой информации.

    Нефункциональные требования к сайту включают в себя технические требования к платформе реализации, совместимость с различными браузерами, время отклика на запросы, наличие мобильной версии, требования к доменному имени и хостингу и проч.

    Важной группой нефункциональных требований являются требования к дизайну и удобству использования (usability).

    Рассмотрим требования к сайту более детально.

  • 2.1. Доменное имя сайта необходимо выбрать в начале проекта. В интернете доменные имена играют такую же роль, как имена людей в обычной жизни. Очевидным вариантом назначения доменного имени является использование основных продаваемых товара и услуги или названия компании. Использование в качестве доменных имен товаров или услуг в основном подходит для сайтов, предназначенных для широкой аудитории пользователей. В этом случае поиск нужного товара или услуги будет осуществляться из предметной области будущего сайта. Например, www.auto.ru — автомобильный портал. Существенными преимуществами обладает регистрация доменов в основных зонах; так, в России — это зоны «.ги», «.su» и «.рф». После выработки подхода к политике регистрации вашего домена следует не затягивать с реализацией этого процесса, поскольку желаемые доменные имена могут занять другие заявители. В зоне «.ги» уже зарегистрировано более 1,5 млн доменов, а в зоне «.сот» — порядка 80 млн. Рекомендуем использовать кириллические имена сайтов в зоне .рф.
  • 2.2. Информационная архитектура.
  • Планирование любого сайта начинается с анализа его контента (информационного наполнения). Под информационной архитектурой сайта подразумевают проектирование его структуры, дерева, а также моделирование поведения пользователей при работе с сайтом и определение элементов интерфейса с учетом удобства пользования.

    Любой сайт строится вокруг его содержания, т.е. материалов, которые планируется на нем разместить. Важно, чтобы на этапе создания плана проекта сайта уже имелось представление об информации, которая будет на нем размещена. Это позволит определить его иерархическую структуру (дерево). Размещение информационных материалов внутри соответствующего дерева представляет собой граф с ветвями в виде страниц с общими признаками. Так, на сайтах интернет-магазинов в каталогах группируются товары, относящиеся к одной группе. Например, группа товаров «холодильники» состоит из холодильников двухкамерных и трехкамерных, встроенных, с нижней, верхней морозильной камерой и т.д.

    Внешний вид сайта имеет большое значение и требует профессионального подхода к визуальной платформе, графическим элементам и верстке. Желательно проводить тестирование рабочих вариантов интерфейса сайта с помощью опросов и фокус-групп. Привлечение специалиста по удобству пользования призвано оценить и усовершенствовать работу дизайнера.

    2.4. Удобство использования (usability).

    Не всегда в штате даже дорогих веб-студий есть штатные эксперты по удобству пользования. Список компаний, декларирующих оценку usability как основной свой вид деятельности, весьма невелик. На сегодняшний день миллионы сайтов, имеющихся в Рунете, нуждаются в услугах специалистов по удобству пользования.

    В настоящее время лишь крупнейшие компании типа «Яндекс» целенаправленно ведут работу по улучшению своих сайтов в направлении удобства пользования.

    Большинство книг на эту тему выглядят как набор советов. Ряд наиболее часто встречающихся ошибок возможно исправить по этим известным книгам, но по-настоящему тонкую настройку интерфейса работы с сайтом можно осуществить, лишь проверяя его рабочий вариант на представителях целевой аудитории. Данные настройки весьма затратны для большинства выполняемых проектов. В этом случае, когда стремление разработчиков создать удобный сайт упирается в нехватку денежных средств у заказчика, остается лишь надеяться на квалификацию специалистов, выбранных для создания того или иного сайта.

    2.5. CMS и программная платформа.

    Сайт представляет собой совокупность информационного наполнения и программных решений, которые обеспечивают его работу. Провайдер хостинга, как правило, обеспечивает для создания сайта ряд системных программных средств. Например, это такие компоненты, как СУБД (например, MySQL), веб-сервер (например, Apache). А остальное программное обеспечение, необходимое для функционирования заказанного сайта, придется либо разрабатывать заново, либо приспосабливать под конкретные условия ранее разработанное.

    Применение CMS 0Content Management System — системы управления сайтом, его контентом) призвано упростить процесс создания сайта и уменьшить затраты на его поддержку.

    CMS-системы можно разделить на две категории — коммерческие и бесплатные. Коммерческие CMS-системы продаются как самостоятельный продукт, что достаточно затратно и требует адаптации и внедрения. Бесплатные CMS-системы, особенно open source, как правило, предлагаются в виде услуги (облачного сервиса) с результатом на выходе в виде работающего сайта.

    Простые сайты можно делать с помощью конструкторов сайтов, предлагающих выбор большого количества готовых шаблонов, а также хостинг. Наиболее популярными конструкторами являются Wix, Ukoz, Google.sites. Небольшой сайт можно сделать и разместить бесплатно; начиная с определенного объема контента требуется оплата. Более детальная информация о CMS и конструкторах сайтов содержится в гл. 4.

    Если планирование создания сайта прошло успешно, то в этом случае известно, какой тип сайта нужен заказчику и для какой аудитории пользователей он разрабатывается, что снимает некоторую неопределенность в его создании. После этого имеет смысл разработать ряд опросных анкет (check-list) с целью определения потребностей будущих пользователей создаваемого сайта. Мы можем воспользоваться такой анкетой и заранее решить, какие возможности сайта нам понадобятся на начальном этапе: наличие каталога и корзины товаров, калькулятора, онлайн-оплаты, личного кабинета клиента, программы лояльности с автоматическим расчетом скидок и бонусов, онлайнового консультанта или экспертной системы, позволяющей подобрать нужный товар, сервиса отслеживания статуса доставки товара, сервиса онлайновой примерки, 3D-визуализации и т.д.

    Интернет-проекты. Комплексные услуги по сопровождению интернет-бизнеса

    Если бизнес ведется в интернете, это не означает, что он находится вне рамок закона. Более того, государство все больше и больше включается в регулирование интернет-бизнеса. Взять хотя бы ужесточение требований в части обработки персональных данных или онлайн-касс. Плохо это или хорошо – спорный вопрос.

    Вместе с тем большинство уже существующих интернет-проектов напрямую не регулируются специальными нормативными актами. Например, нет законодательства о краудфандинге и краудинвестинге, до сих пор не приняты законы о телемедицине и маркетплейсах.

    Такая ситуация несколько осложняет юридическое сопровождение ит бизнеса по сравнению с сопровождением традиционных компаний. Ведь юристам приходится адаптировать нормы ГК к особенностям интернет-проектов, а также учитывать риски, выявленные судебной практикой.

    Чтобы интернет-проект мог прожить долгую и яркую жизнь, нужно определить для себя следующее:

    1. Наличие прямого правового регулирования.

    2. Наличие законодательных запретов или ограничений деятельности.

    Скажем, деятельность сервисов мобильного такси – таких как Яндекс.Такси, Gett – напрямую не регулируется законодательством. Они являются посредниками между таксистами и пассажирами, сами же деятельность по перевозке не осуществляют. Но, если посмотреть на законодательство о такси и текущую судебную практику с точки зрения того, кто оказывает юридические услуги для интернет-проектов, становится очевидно, что государство пристально следит за такими сервисами. В зависимости от того, какую договорную модель выбрал проект, его деятельность может быть запрещена. Есть даже множество примеров ограничения рекламы подобных сервисов.

    3. Выбор договорной модели.

    От этого зависят не только права и обязанности сервиса по отношению к пользователям, но и налоги, которые должен платить сервис. Взять, к примеру, некий маркетплейс. Работа с ним не просто юридическое сопровождение интернет магазина, здесь нужно разрабатывать более сложную договорную схему. Например, с поставщиками проект может выбрать форму договора поставки, тогда продажа товаров будет вестись от имени самого маркетплейса и за все недостатки будет отвечать он. Или же он может работать по агентскому договору – это позволит сократить налоговую нагрузку и перенести бремя ответственности за товар на поставщиков.

    4. Налоговые риски.

    Этот пункт напрямую связан с договорной моделью. Но налоговую нагрузку стоит рассчитывать отдельно, чтобы потом не было неприятных сюрпризов.

    5. Вопросы персональных данных.

    На сайте в обязательном порядке нужно разместить Политику обработки персональных данных и согласие на их обработку. Одновременно внутри компании необходимо разработать и внедрить целый пакет документов по работе с ПДн. Также следует соблюдать требования о локализации и разместить первичный сервер на территории РФ.

    Методические рекомендации по применению ГОСТ Р 7.0.97-2016 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов»

    Федеральное архивное агентство
    (Росархив)

    Федеральное бюджетное учреждение
    «Всероссийский научно-исследовательский институт
    документоведения и архивного дела»
    (ВНИИДАД)

    Методические рекомендации
    по применению ГОСТ Р 7.0.97-2016
    «Система стандартов по информации, библиотечному
    и издательскому делу. Организационно-распорядительная
    документация. Требования к оформлению документов»

    Методические рекомендации по применению ГОСТ Р 7.0.97-2016 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов» / Росархив, ВНИИДАД. М., 2018. 91 с.

    Методические рекомендации разъясняют положения стандарта ГОСТ Р 7.0.97-2016, содержат методику их практического использования органами государственной власти, органами местного самоуправления, организациями при реализации процессов документационного обеспечения управления, в том числе в работе по созданию электронных документов, а также при разработке и внедрении систем электронного документооборота.

    Методические рекомендации предназначены для применения органами государственной власти и государственными организациями, а также организациями различных организационно-правовых форм и форм собственности. Методические рекомендации могут использоваться также в процессе обучения студентов по соответствующим дисциплинам.

    Смотрите так же:  Гафарова защита прав потребителей

Оставьте комментарий