Руководство интернет проектом

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

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

По данным SuperJob.ru, средняя зарплата, которую предлагают руководителям интернет-проектов московские компании, составляет 65 000 руб. В Санкт-Петербурге такие специалисты могут рассчитывать на доход около 52 000 руб. в месяц. В Казани и Самаре руководители интернет-проектов зарабатывают в среднем 33 000 руб.

Руководство проектом во Всемирной сети работодатели готовы доверить специалистам, имеющим опыт работы администратором сайта, seo-оптимизатором, интернет-маркетологом либо менеджером интернет-проекта не менее 1 года. Соискатели должны иметь законченное или неполное высшее образование, демонстрировать знание основ интернет-маркетинга, интернет-рекламы, HTML и графических редакторов. Зарплатные предложения для руководителей интернет-проектов, делающих первые шаги на данном поприще, в столице составляют от 35 000 до 55 000 руб., в городе на Неве — от 30 000 до 47 000 руб.

На более высокий оклад вправе рассчитывать соискатели, имеющие опыт управления интернет-проектами более 2 лет. Работодатели заинтересованы в кандидатах, изучивших особенности, специфику и методы управления проектами во Всемирной паутине, основы бюджетирования и финансового планирования. Претендентам необходимо иметь сертификаты, подтверждающие прохождение курсов или тренингов по проект-менеджменту, а также владеть английским языком на уровне, достаточном для чтения технической литературы. Специалисты, соответствующие указанным требованиям, в Москве зарабатывают до 80 000 руб., в северной столице — до 70 000 руб., в Самаре — до 41 000 руб., в Казани — до 40 000 руб.

Максимальный доход руководителей интернет-проектов с опытом работы на данном посту не менее 3 лет в Москве составляет 120 000 руб., в Санкт-Петербурге — 100 000 руб., в Казани и Самаре — 60 000 руб. Работодателей также интересует наличие у кандидатов отличных переговорных навыков и опыта успешной реализации крупных интернет-проектов.

Согласно исследованию рынка труда, большинство соискателей должности руководителя интернет-проекта — представители сильного пола (74%). Молодежь в возрасте до 30 лет составляет 41% от общего числа кандидатов, специалисты в возрасте от 30 до 40 лет — 39%. 90% руководителей интернет-проектов имеют высшее образование, 31% свободно владеет английским языком.

Типичный функционал:

решение комплекса задач по созданию, поддержке, продвижению и развитию интернет-проекта:

разработка стратегии развития интернет-проекта;

разработка концепции и структуры сайта проекта;

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

подготовка контента для информационного и графического наполнения сайта;

оптимизация и поисковое продвижение сайта;

анализ статистики посещаемости сайта;

планирование, проведение и анализ результатов рекламных и маркетинговых кампаний;

внедрение новых сервисов и проектов;

планирование и контроль сроков исполнения и бюджета интернет-проекта;

координация действий команды специалистов.

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

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

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

Регион	Диапазон I	Диапазон II	Диапазон III
Москва	до 55 000	55 000 — 80 000	свыше 80 000
Санкт-Петербург	до 47 000	47 000 — 70 000	свыше 70 000
Волгоград	до 25 000	25 000 — 35 000	свыше 35 000
Екатеринбург	до 37 000	37 000 — 55 000	свыше 55 000
Казань	до 28 000	28 000 — 40 000	свыше 40 000
Нижний Новгород	до 28 000	28 000 — 45 000	свыше 45 000
Новосибирск	до 31 000	31 000 — 50 000	свыше 50 000
Омск	до 25 000	25 000 — 40 000	свыше 40 000
Ростов-на-Дону	до 28 000	28 000 — 42 000	свыше 42 000
Самара	до 28 000	28 000 — 41 000	свыше 41 000
Уфа	до 26 000	26 000 — 42 000	свыше 42 000
Челябинск	до 30 000	30 000 — 45 000	свыше 45 000

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

Зарплатный диапазон	Требования и пожелания к профессиональным навыкам
I	высшее / неполное высшее образование; уверенный пользователь ПК; базовые знания HTML, графических редакторов; знание основ интернет-маркетинга, интернет-рекламы; опыт участия в создании, развитии или поддержке интернет-проектов (опыт работы администратором сайта, seo-оптимизатором, интернет-маркетологом, менеджером интернет-проекта) от 1 года;
II	знание особенностей, специфики и методов управления интернет-проектами; навыки бюджетирования и финансового планирования; знание английского языка на уровне чтения технической документации; наличие сертификата о прохождении курсов или тренингов по управлению проектами; опыт составления технических заданий; опыт управления интернет-проектами от 2 лет;
III	отличные переговорные навыки; опыт успешной реализации крупных интернет-проектов; опыт работы руководителем интернет-проектов от 3 лет.

Статистические данные:

Возрастной диапазон наиболее востребованных рынком руководителей интернет-проекта 25-40 лет; руководители интернет-проекта в возрасте до 30 лет составляют 41% от общего числа соискателей; в возрасте от 30 до 40 лет — 39%, в возрасте от 40 до 50 лет — 19%, в возрасте свыше 50 лет — 1%;

74% соискателей на позицию «руководитель интернет-проекта» — мужчины;

65% руководителей интернет-проекта владеют английским языком на базовом уровне и на уровне, достаточном для чтения специализированной литературы; на разговорном и на свободном уровнях — 31%;

90% руководителей интернет-проекта имеют высшее образование, 9% — неполное высшее, 1% — среднее специальное;

70% руководителей интернет-проекта имеют водительские права категории «В».

Автор: Исследовательский центр портала Superjob.ru

Исследовательский центр рекрутингового портала Superjob.ru (http://www.superjob.ru/) в феврале 2011 года изучил предложения работодателей и ожидания претендентов на позицию «Руководитель интернет-проекта» в 12 городах России.

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

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

Руководство проектом во Всемирной сети работодатели готовы доверить специалистам, имеющим опыт работы администратором сайта, seo-оптимизатором, интернет-маркетологом либо менеджером интернет-проекта не менее 1 года. Соискатели должны иметь законченное или неполное высшее образование, демонстрировать знание основ интернет-маркетинга, интернет-рекламы, HTML и графических редакторов. Зарплатные предложения для руководителей интернет-проектов, делающих первые шаги на данном поприще, в столице составляют от 35000 до 55000 руб., в городе на Неве – от 30000 до 47000 руб., в Казани и Самаре – 18000 до 25000 руб.

На более высокий оклад вправе рассчитывать соискатели, имеющие опыт управления интернет-проектами более 2 лет. Работодатели заинтересованы в кандидатах, изучивших особенности, специфику и методы управления проектами во Всемирной паутине, основы бюджетирования и финансового планирования. Претендентам необходимо иметь сертификаты, подтверждающие прохождение курсов или тренингов по проект-менеджменту, а также владеть английским языком на уровне, достаточном для чтения технической литературы. Специалисты, соответствующие указанным требованиям, в Москве зарабатывают до 80000 руб., в северной столице – до 70000 руб., в Самаре – до 41000 руб., в Казани – до 40000 руб.

Максимальный доход руководителей интернет-проектов с опытом работы на данном посту не менее 3 лет в Москве составляет 120000 руб., в Санкт-Петербурге – 10000 руб., в Казани и Самаре – 60000 руб. Работодателей также интересует наличие у кандидатов отличных переговорных навыков и опыта успешной реализации крупных интернет-проектов.

Согласно исследованию рынка труда, большинство соискателей должности руководителя интернет-проекта – представители сильного пола (74%). Молодежь в возрасте до 30 лет составляет 41% от общего числа кандидатов, специалисты в возрасте от 30 до 40 лет – 39%. 90% руководителей интернет-проектов имеют высшее образование, 31% свободно владеет английским языком.

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

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

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

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

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

Регион	Мин.	Нижний квартиль	Медиана	Верхний квартиль	Макс.	Мода	Среднее арифметическое
Москва	35 000	55 000	65 000	80 000	120 000	70 000	69 000
Санкт-Петербург	30 000	47 000	52 000	70 000	100 000	55 000	55 200
Волгоград	18 000	25 000	28 000	35 000	50 000	30 000	29 670
Екатеринбург	20 000	37 000	42 000	55 000	70 000	40 000	40 710
Казань	18 000	28 000	33 000	40 000	60 000	35 000	33 120
Нижний Новгород	18 000	28 000	35 000	45 000	60 000	35 000	34 740
Новосибирск	20 000	31 000	38 000	50 000	70 000	40 000	37 260
Омск	18 000	25 000	31 000	40 000	60 000	30 000	31 050
Ростов-на-Дону	20 000	28 000	33 000	42 000	65 000	35 000	35 189
Самара	18 000	28 000	33 000	41 000	60 000	35 000	35 194
Уфа	18 000	26 000	31 000	42 000	70 000	30 000	31 878
Челябинск	20 000	30 000	34 000	45 000	70 000	35 000	35 880

Пояснения к таблице »

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

Регион	Диапазон I	Диапазон II	Диапазон III
Москва	до 55 000	55 000 — 80 000	свыше 80 000
Санкт-Петербург	до 47 000	47 000 — 70 000	свыше 70 000
Волгоград	до 25 000	25 000 — 35 000	свыше 35 000
Екатеринбург	до 37 000	37 000 — 55 000	свыше 55 000
Казань	до 28 000	28 000 — 40 000	свыше 40 000
Нижний Новгород	до 28 000	28 000 — 45 000	свыше 45 000
Новосибирск	до 31 000	31 000 — 50 000	свыше 50 000
Омск	до 25 000	25 000 — 40 000	свыше 40 000
Ростов-на-Дону	до 28 000	28 000 — 42 000	свыше 42 000
Самара	до 28 000	28 000 — 41 000	свыше 41 000
Уфа	до 26 000	26 000 — 42 000	свыше 42 000
Челябинск	до 30 000	30 000 — 45 000	свыше 45 000

Пояснения к таблице »

№	Зарплатный диапазон	Требования и пожелания к профессиональным навыкам
1	I	— высшее / неполное высшее образование; — уверенный пользователь ПК; — базовые знания HTML, графических редакторов; — знание основ интернет-маркетинга, интернет-рекламы; — опыт участия в создании, развитии или поддержке интернет-проектов (опыт работы администратором сайта, seo-оптимизатором, интернет-маркетологом, менеджером интернет-проекта) от 1 года;
2	II	— знание особенностей, специфики и методов управления интернет-проектами; — навыки бюджетирования и финансового планирования; — знание английского языка на уровне чтения технической документации; — наличие сертификата о прохождении курсов или тренингов по управлению проектами; — опыт составления технических заданий; — опыт управления интернет-проектами от 2 лет;
3	III	— отличные переговорные навыки; — опыт успешной реализации крупных интернет-проектов; — опыт работы руководителем интернет-проектов от 3 лет.

Статистические данные:

• Возрастной диапазон наиболее востребованных рынком руководителей интернет-проекта 25-40 лет; руководители интернет-проекта в возрасте до 30 лет составляют 41% от общего числа соискателей; в возрасте от 30 до 40 лет – 39%, в возрасте от 40 до 50 лет – 19%, в возрасте свыше 50 лет – 1%;
• 74% соискателей на позицию «руководитель интернет-проекта» — мужчины;
• 65% руководителей интернет-проекта владеют английским языком на базовом уровне и на уровне, достаточном для чтения специализированной литературы; на разговорном и на свободном уровнях — 31%;
• 90% руководителей интернет-проекта имеют высшее образование, 9% — неполное высшее, 1% — среднее специальное;
• 70% руководителей интернет-проекта имеют водительские права категории «В».

Ознакомиться с зарплатным индексом Superjob в сегменте «Информационные технологии»

Посетить профессиональное сообщество «IT, телекоммуникации и связь» портала Superjob Заказать обзор заработных плат

Просмотреть резюме руководителей интернет-проекта на портале SuperjobПросмотреть вакансии руководителей интернет-проекта на портале Superjob

Понравилась статья? Поделитесь с друзьями

---

Другие статьи

---

Подписка на результаты новых исследований   Прайс-лист на аналитические исследования

© Перепечатка в любых СМИ, в том числе в Интернете, возможна при условии прямой активной ссылки на портал Superjob.ru.

100+ материалов для менеджера проектов с описаниями и ссылками: карта компетенций, курсы, книги, инструменты, Telegram-каналы, блоги и фильмы. Собрали материалы и рекомендации опытных экспертов в одной статье, чтобы всё было под рукой.

Карта компетенций

Начнем с начала: кто же такой менеджер проектов в digital-индустрии и как им стать. Поговорим о том, с чего начать и какие ресурсы помогут двигаться в нужном направлении.

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

Звучит здорово, и такой человек точно нужен всем. Какими же качествами он должен обладать?

Выполнить задачу по запуску проекта невозможно без умения договариваться, работать с командой, ставить сроки и следить за их соблюдением. Нужно уметь делать и демонстрировать прототипы, распределять ресурсы, решать конфликтные ситуации. То есть, самое важное для project-менеджера — soft skills: коммуникативные навыки, способность справляться со стрессом, умение работать с информацией, самоорганизованность, навык поиска нестандартных решений. Хорошую карту компетенций проджект-менеджера составила scrum-студия «Сибирикс».

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

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

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

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

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

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

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

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

По мнению «Сибирикс» важно понимать технологии: хостинги, подключение платежных систем, подключение систем доставки, сайты (адаптивные, композитные, мобильные), интеграция с SMS-шлюзами, принципы работы DNS, размещение кодов метрик/аналитики.

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

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

Хорошо иллюстрирует роль менеджера притча о двух работниках:

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

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

Где учиться менеджеру проектов

Первое — прочитать план обучения от IT-Agency. Там собрали необходимые материалы для старта, разделив их по темам: личная и общая система организации работы, решение задач, переговоры и работа с клиентом, текст, повышение конверсии, английский.

Годовые курсы:

Профессия «Project Manager в IT» от Skillfactory

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

«Факультет проджект-менеджмента» от GeekBrains

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

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

Курс «Руководитель digital-проектов» от Interra

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

Курсы покороче:

Профессия «Менеджер проектов» от Яндекс Практикума

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

Курс «Project Manager» от Нетологии

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

Курс «Руководитель digital-проектов» от Skillbox

Расскажут про все этапы работы над проектом — от планирования до запуска. Дипломный проект — запуск собственного сайта.

Курс «Проджект-менеджмент» от Laba

Объяснят все IT-термины, помогут начать общаться с командой разработчиков на одном языке.

Можно выбрать из 13 курсов и пройти обучение с преподавателями НИУ ВШЭ, получив по итогу удостоверение о повышении квалификации. Стоимость и время варьируются в зависимости от выбранного курса.

Мини-курсы по управлению проектами от Udemy

Курс «Руководитель проектов» от Русской Школы Управления

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

Набор полезных инструментов проджект-менеджера

Канбан-доска, на которой можно создавать карточки с задачами по темам (например, набор карточек «to do» и «in progress», или разделенные по принципу «разработка», «внедрение», «тестирование»).

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

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

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

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

Более простой, чем MSProject и бесплатный инструмент, который упрощает работу с проектами, позволяя показать заказчику сразу готовый план, и одобрить его, чтобы не координировать работу постоянно.

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

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

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

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

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

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

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

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

Один из первых онлайн-инструментов для записи дел и возможности разделить их между членами команды. Можно задавать задачам приоритет.

Что почитать будущему или начинающему проджект-менеджеру, чтобы понять, как же превратить идею в проект и соблюсти сроки

Книги для менеджера проекта

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

Скотт Беркун, бывший руководитель проектов в Microsoft, ответил в своей книге на животрепещущие вопросы начинающих проджектов: «как выстроить отношения в команде?», «как принять верное решение?», «что делать, если все идет не так?».

Джозеф Хигни, президент консалтинговой компании QMA International, на основании PMBOK составил руководство, помогающее узнать больше о работе проджект-менеджера.

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

Дэвид Андерсон — первый, кто использовал метод канбана в 2005 году. Учитывая свой опыт, он расскажет, что такое канбан, зачем он нужен, как внедрить, и чем это поможет бизнесу.

Книга, особенно полезная проджект-менеджеру в IT, потому что объясняет, насколько успех digital-проектов зависит от социального фактора, а не от знания софта.

Книга о склонности людей сбиваться в племена, и о том, как быть лидером такого племени. О первобытных рефлексах рассуждаю Дэйв Логан — доктор наук, старший преподаватель бизнес-школы при Университете Южной Калифорнии, сооснователь CultureSync, Джон Кинг — коуч, Хэли Фишер-Райт — доктор медицинских наук, педиатр.

OKR (Objectives and Key Results) — методика постановки целей и оценки результатов для команд. Авторы научат, как использовать OKR на практике, сформулировать цели и результаты, и оценить пользу от внедрения OKR.

Эмоциональный интеллект — способность понимать свои и чужие эмоции, стремления и намерения. Осознавать и применять эти знания важно ради успешного запуска проектов, и как это делать в своей книге описал Энтони Мерсино, обладатель сертификатом института PMI и специалист-практик по методам Agile, MBA.

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

Руководство по 4 основным методологиям Agile: Scrum, XP, Lean, Kanban. С помощью книги можно полностью изменить мышление людей, работающих над проектами, превратить их в команду, которая добивается результатов.

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

Способ выживать в безнадежных проектах для разработчиков программного обеспечения.

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

Подробный рассказ про методологию GTD (Getting Things Done). Техника как хорошо и эффективно работать, не теряя вовлечения в личную жизнь — как отделять главное от второстепенного, планировать и контролировать работу, не создавая хаос из мыслей.

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

Институт управления проектами Project Management Institute (PMI) публикует и регулярно обновляет PMBOK — свод знаний по управлению проектами. В самом институте используют этот документ как основной справочный материал. В шестом издании книга выпущена с дополнением о гибких средах проекта, с описанием, как эти подходы интегрировать в проект.

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

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

Джефф Сазерленд — один из разработчиков методологии Scrum, описывает в своей книге как Scrum помогает преодолевать классические проблемы в управлении проектами, и в более короткие сроки и с меньшими затратами создавать и выпускать продукты отличного качества.

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

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

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

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

Продолжение аудиокурса «Персональное управленческое искусство», который поможет продвинуться в управлении на порядок, без потери лет и совершения типовых ошибок.

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

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

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

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

Приложение к статье «Правила Ашманова», в котором собраны высказывания программистов, которые управленец не должен понимать буквально.

Дополнение к «Правилам Ашманова» и «Правилам Ашманова 2». Вредные советы для руководителей — если часто повторять написанные в словаре фразы, проблемы с проектом и персоналом возникнут неминуемо.

Книга про отношения с клиентом. Отношения всегда непросто, а уж между бизнесом и клиентом — создать, укрепить и сохранить еще сложнее. Нужно стараться во всем угождать, и одновременно уметь говорить «нет» и не прогибаться. Автор подробно расскажет о том, как это сделать, а иллюстрации помогут запомнить содержимое книги.

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

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

Проект по сути всегда оказание услуг. Автор книги — консультант и исследователь управления организациями, оказывающими профессиональные услуги, написал настольное руководство правильного внедрения методик управления.

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

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

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

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

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

Блоги для проджект-менеджера

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

Элизабет Харрин, создательница блога, поняла, что очень мало женщин пишут про проджект-менеджмент, и решила это исправить. Ее цель — помочь проджект-менеджерам, особенно женщинам, успешно запускать свои проекты.

Дмитрий Нижебецкий, менеджер IT-проектов с более чем 10-летним опытом, дает советы и рекомендации по управлению проектами, которые будут особенно полезны для начинающих проджект-менеджеров.

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

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

Каждую неделю в блоге nTask выкладывают полезную информацию об управлении проектами.

Статьи в блоге основаны на книге Джона Кэролла «Путь руководителя проекта», помогут изучить все, что нужно знать проджект-менеджеру.

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

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

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

Блог, в котором рассказывают, насколько управлять проектами легко в теории и тяжело на практике.

Джина — президент совета директоров Project Management Institute и в своем блоге она делится опытом со всеми проджект-менеджерами.

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

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

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

На какие каналы подписаться в телеграме

Канал о том, как эффективно управлять проектами и достигать желаемых результатов.

Управление IT проектами без мистики и занудства, ведет @Roman_Kovalevsky

Канал для аналитиков в IT.

Подборки ссылок, рецензии на книги и блог менеджера проектов Виталия Салахмира.

Анонсы новых выпусков, голосования и прочие инфоповоды.

Вакансии для проджектов и продактов, которых нет на стандартных агрегаторах.

Канал о кейсах в digital продуктах и проектах. Типовые ошибки, лучшие практики, методологии и люди, а также анонсы эфиров.

Новостной канал о событиях в области управления проектами в Санкт-Петербурге и не только.

Канал о семинарах, форумах, конференциях и других событиях в сфере управления проектами, портфелями, программами, продуктами и общем менеджменте.

Канал PM в корпоративном IT, родом из 1С. Обсуждает все самое интересное.

Федор пишет о производстве сложных проектов, управлении продуктами, профессиональном росте программистов.

Канал о тимлидстве, интересный проджект-менеджеру с точки зрения управления командой. Ведет Алексей Катаев. О чем пишет: процессы, инструменты, эксперименты, метрики, найм, продуктивность и тайм-менеджмент.

Марьяна Онысько, экс-продакт МИФа пишет о создании продуктов, управлении проектами и командой, чендже и ране.

Канал полезный для всех из сферы IT. Рассказывают про системную аналитику и управление проектами.

Канал Михаила Калашникова о разнообразии цифрового мира.

Какие фильмы смотреть, чтобы почувствовать себя вовлеченным и прокачать софт-скиллы

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

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

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

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

Сериал для тех, кому понравился «Карточный домик». Расскажет о противостоянии финансиста с Уолл-стрит Бобби Аксельрода и принципиального федерального прокурора Чака Родса.

История братьев Адольфа и Рудольфа Дасслеров, которые основали небольшую обувную фабрику. Их бизнес, как и любой, проживал взлеты и падения, и в итоге разделился на два конкурирующих бренда — Adidas и Puma.

Оскароносный рассказ о жизни Фостера Кейна, газетного магната, чья личность и жизнь была настолько яркой, что ему пророчили роль президента.

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

Фильм о том, как строилась личность Стива Джобса параллельно с Apple. Кроме истории головокружительного успеха, не упустили темные стороны личности Стива Джобса и неоднозначные решения, присущие каждому руководителю.

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

Как и где искать работу начинающему проджекту

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

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

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

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

Digital HR – тоже про вакансии в digital, которые заслужили доверие авторов канала.

Яндекс — вакансии каждую среду.

Примеры задач при найме

Зарплаты менеджеров проектов

Мы проанализировали рынок вакансий на Head Hunter, а также открытые исследования рынка заработных плат от аналитического агентства Tagline и рекрутингового агентства Real HR. Зарплаты менеджеров проектов зависят от уровня, специфики и ниш. Уровень зарплат варьируется от 50 до 350 тыс. руб.

Уровни зарплат в студиях и агентствах:

При работе на стороне клиента уровень зарплат может быть выше на 15-30%, но на таких проектах более медленный рост по скиллам.

О сертификации PMP для развития проджектов

PMP (Project Management Professional) — международный сертификат подтверждающий квалификацию проджект-менеджера. Сдавать экзамен для его получения могут те, у кого есть высшее образование и 3 годы опыта работы проджектом, или среднее образование и 5 лет профессионального опыта. Также нужно пройти 35 часов обучения проджект-менеджменту и предоставить бумаги об этом.

PMP редко является обязательным требованием работодателя при найме проджект-менеджера, но всегда — бонусом. По статистике зарплата для такого кандидата будет примерно на 40% выше, чем без сертификата. В международных вакансиях PMP — часто обязательное требование, или гарант того, что зарплата будет на 25% выше.

C 2020 года экзамен на PMP можно сдавать не выходя из дома. Подробнее об условиях можно прочитать здесь. Нужно зайти на портал, пройти тест системы (скорость работы интернета, и прочее), выбрать удобную дату и время для экзамена. За 30 минут до экзамена нужно зайти в личный кабинет, начать экзамен и подтвердить свою личность: сфотографироваться, сфотографировать удостоверение личности и снять свое рабочее место с 4 ракурсов. На столе не должно быть ничего лишнего и никаких шпаргалок, а все вкладки браузера, кроме окна экзамена, должны быть закрыты.

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

Чтобы потренироваться, можно проверить свои силы на тренажере — симуляторе PMP.

Вместо выводов

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

Невольно напрашивается вопрос: «Ради чего все это, множество требований при куче стресса за не самую большую ЗП и работу на дядю?»

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

Руководитель Интернет проектов, высокооплачиваемая профессия

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

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

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

к оглавлению ↑

Особенности работы руководителя (менеджера) Интернет проектов

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

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

• анализ и планирование;
• поиск сотрудников в проект;
• контроль всех сотрудников в проекте;
• продвижение проекта.

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

к оглавлению ↑

Что должен знать руководитель Интернет проекта

Какая бы у Вас специальность не была, везде нужно учиться и знать, как делать свою работу. Итак, вот что должен знать руководитель проектов:

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

Это лишь основные знания, которые используют на практике менеджеры Интернет проектов.

к оглавлению ↑

Как получить профессию руководителя Интернет проекта

Совсем не обязательно иметь высшее образование руководитель Интернет проектов. Этой профессии можно обучиться в Интернете. Примерно, за 4–6 месяцев. Данное обучение поможет Вам набраться опыта – это заказчики ценят больше всего в своей работе.

Получить эту профессию можно на специальных курсах. Например, есть онлайн-обучающая программа от ресурса Нетологии. Чтобы записаться на обучение, наберите в поиске браузера – «Нетология руководитель проекта». После этого переходите на главную страницу и жмёте кнопку «Записаться». Обучающая программа по такой специальности в Нетологии стоит дорого.  Основная цена — 70 000 (очная форма обучения) рублей базовый пакет. Заочная форма обучения через Интернет стоит дешевле.

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

к оглавлению ↑

Где найти работу менеджера (руководителя) Интернет проекта

После обучения на курсах Вы можете найти работу в Интернете и стать руководителем Интернет проекта. Самый выгодный вариант – это устроиться на удалённую работу. В этом случае Вам помогут: Интернет, и ресурс для поиска работы. Для примера, можно взять сервис – «ru.jobsora.com».

Если набрать в поиске браузера «Руководитель Интернет проекта и нажать кнопку «Найти», Вы можете заметить в результатах выдачи этот ресурс. Далее, переходим на него и видим свободные вакансии, размещенные на этом ресурсе (Скрин 1).

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

к оглавлению ↑

Управление проектами, сколько можно заработать по данной профессии

Какой в действительности заработок у руководителей Интернет проектов?  Средняя зарплата менеджера проекта в месяц 20 000 – 80 000 рублей. Такой доход возможен в основном у начинающих менеджеров, которые прошли недавно обучение и начали свою первую деятельность в Интернете.

У профессионалов с опытом работы 3–6 лет заработок в месяц будет выше. Например, в размере 400 000 рублей в месяц.

к оглавлению ↑

Заключение

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

С уважением, Иван Кунпан.

Просмотров: 498

Сущность интернет – проектов

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

Особенности управления интернет – проектами

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

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

«Управление интернет — проектами» 👇

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

Цель интернет – проекта

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

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

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

Вступление

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

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

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

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

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

Бизнес-руководителя на протяжении всего текста можно было бы называть просто руководителем проекта и это было бы всем понятно, но он всегда будет называться именно бизнес-руководителем. Это сделано для того, чтобы вы понимали простую истину: у технологически сложного ИТ-проекта всегда два руководителя, из них один ведущий (бизнес), другой ведомый (технический), но их два. Если технический руководитель забудет, что он тоже руководитель и тоже несёт определённую ответственность за успех проекта, то в условиях острого ограничения по времени это с большой долей вероятности приведёт к краху проекта.

Заметка получилась размером около 80 тыс. символов и потребует при быстром чтении около двух с половиной часов. Она будет интересна руководителям проектов, инвесторам и тем из разработчиков, кто интересуется стартапами и проектным подходом к разработке.

Об авторе

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

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

Есть опыт успешного выхода из проекта с проблемным окончанием финансирования.

К чему приводит нехватка времени

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

Трудности найма хороших разработчиков в начале проекта. Сроки давят. Рынок разработчиков небогат, особенно небогат желающими поработать с ненормируемым рабочим днём. Поэтому есть большое желание взять с рынка более-менее подходящих разработчиков и начать с ними разработку как можно раньше. Следует не поддаваться этому позыву. Лучше нанять качественных разработчиков, чем уложиться в сроки по найму — сорвав первый и второй отчётные периоды, руководство проекта получит значительно большую скорость разработки к завершению проекта. Ваша же цель проект, а не промежуточная отчётность.

Рост трудности найма с развитием проекта. Чем дольше разрабатывается проект, тем больше написано кода, тем более сложная логика реализована, тем новичку больше приходится разбираться в имеющемся коде. Кроме того, постоянное откладывание рефакторинга даже в условиях качественного CodeReview приводит к тому, что код местами становится трудно понятен. Это может приводить к тому, что уже через три месяца после начала написания кода новые нанимаемые программисты будут быстро уходить и текучка по новым разработчикам достигнет 100%. Опытный технический руководитель может справиться с этой трудностью заблаговременно, начинающий — нет.

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

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

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

Все всё понимали. Проект был запущен в срок с качеством кода сильно превышающим среднерыночный для крупных компаний.

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

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

Решению конфликтов сильно поможет понимание того, что конфликт в группе разработки обычно возникает из желания участников сделать работу лучше и быстрее. При этом решения для этого используются разные. Иногда с разными приоритетами на скорость или качество. Это производственные конфликты, не личностные. Такие конфликты лучше всего решать обучением сторон и совместным принятием решения, а не поиском правого или виноватого.

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

Бизнес-руководитель проекта

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

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

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

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

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

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

С кем не стоит связываться

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

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

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

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

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

Технический руководитель проекта

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

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

Возьмём, например, основные стеки технологий автора:

• Lotus Notes — Lotus Domino — Lotus Workflow — Lotus Domino.Doc ;
• Linux — Nginx — Apache / PHP_FPM — MySQL / PostgreSQL — PHP / Perl / C ;
• Linux — Node.JS — Tarantool / Redis — LuaJIT ;

Языки вне стеков: C++, Assembler, разнообразные диалекты Visual Basic, JavaScript, TypeScript, Go, Java, Formula и всякие Fortran и Pascal в юности.

Из операционных систем удалось разрабатывать во всех MS DOS начиная с 3.0, всех Windows начиная с 3.1, OS/2, CentOS, Ubuntu, Debian, openSUSE, AstraLinux и давно уже на FreeBSD.

Администрировать довелось в основном CentOS, Ubuntu, Debian, openSUSE и AstraLinux.

Из фреймворков: Symfony2, Symfony3, Kohana 3, Yii 2, React Native, SailsJS, ExpressJS, MFC, Bootstrap 3, OWL for C++ и др.

Из прочего инструментария пришлось разбираться и промышленно использовать ElasticSearch, MongoDB, Beanstalk, BerkeleyDB, инфраструктуру Docker, Composer, Capyfony, RabbitMQ, Memcached, Git, Jira, RedMine, PHPUnit, SphinxSearch, Axshare, WinAPI и разнообразные API для С типа Rational Rose, MySQL, Domino.Doc и другие.

Из IDE: NetBeans, PhpStorm, Visual Studio, блокнотик, редактор mc и vi.

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

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

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

Остаются руководительские, управленческие и организаторские. Так называемые софт-скилы. Софт-скилы желательно наращивать именно в указанном выше порядке. То есть сначала руководительские, затем управленческие, затем организаторские.

Навыки руководства позволяют распределить сферы деятельности между разработчиками, объяснить им что именно нужно делать и почему, а кроме того помогать им решать текущие вопросы, разруливать конфликты интересов и учить вместо того, чтобы критиковать. Так же они являются критичными при найме разработчиков — именно они позволяют понять кто пришёл на собеседование, что он на самом деле может и как он впишется в разработку сейчас и со временем.

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

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

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

Можно ли в небольшой группе разработки обойтись слабо развитыми навыками руководства и управления? Можно. Для этого достаточно организовать Scrum по Scrum Guide. Это в чистом виде фреймворк для руководства без руководства и управления без управления. В условиях острой нехватки времени обычно неприменим из-за психологических особенностей бизнес-руководителя проекта и спонсора.

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

Разработчики

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

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

Много ограничений? Много. И они серьёзнее, чем может подумать неискушённый человек.

Лучшим разработчиком для проекта с острой нехваткой времени является тот, кто знает, чего хочет, хочет вырасти в рамках своей специализации и способен доводить решения задач до конца. У него есть необходимые навыки, он жизненно-активен и принимает необходимость в разных ситуациях действовать по-разному. Так же он комфортен в общении для нанятых и еще не нанятых участников команды, при этом другие ещё не нанятые участники комфортны для него — иначе команда его отторгнет, что критично в таком типе проектов. Это минимальные требования, но и они радикально сужают круг приемлемых кандидатов.

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

Для каких-то проектов ради достижения высокого качества продукта требуются перфекционисты. Для других критично важны люди, умеющие пересилить в себе желание сделать идеально ради того, чтобы быстро сделать работающую первую версию. Для третьих требуются узкие специалисты и технический руководитель проекта выступает как интегратор их труда в единый продукт. Для четвёртых — разработчики с широким кругозором и кто-то из разработчиков, а может и технический руководитель, довёрстывает то, что не может сверстать верстальщик; исправляет в JavaScript-е то, что не может исправить frontend-разработчик; реализует в серверной части то, с чём не справляется backend-программист. Для пятых невозможно обойтись без активной коммуникации внутри группы разработки и это требование к умению общаться по делу и помогать друг другу будет перевешивать даже профессиональные навыки.

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

Вот такие ограничения на кандидатов.

Планирование

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

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

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

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

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

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

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

План работ в системе отслеживания задач типа Jira описываться не будет из-за обилия хороших статей на это тему. Автор заметки хочет отметить лишь важные моменты. У задач должна быть достаточно разветвлённая система статусов. Они могут быть не объединены в настроенный документооборот, но они должны быть описаны и утверждены. Только они помогут разбираться с текущими статусами задач не отвлекая разработчиков от работы. Вторым важным моментом является фиксация всех принятых решений в рамках задач в комментариях к ним. Все устные договорённости тоже должны быть зафиксированы. Это избавит от конфликтов что должно быть сделано, а о чём договорились не делать.

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

План работ в виде списка всех задач в таблице Excel описывает как список задач, так и кто делает каждую из них. Это примерно 300-500 задач, которые объединяются в блоки. Каждый блок обычно соответствует отдельной функции. Например, «реализация уведомления о событии» является блоком, а «создание дизайна писем-уведомлений», «вёрстка писем-уведомлений по дизайну», «встраивание вёрстки в код» и «реализация логики отправки уведомлений при возникновении события» — это отдельные задачи, которые выполняют разные люди. Эти люди указываются в виде исполнителей по каждой из задач. Для каждой задачи плана работ прописывается задача в Jira и номер её попадает в таблицу плана работ. Задачи в Jira объединены в рамках истории, соответствующей блоку. Кроме того, у каждой задачи есть плановый объём работ в часах, фактический объём работ, плановая дата завершения и фактическая дата завершения. У каждого функционального блока есть плановая дата завершения всего блока и фактическая дата завершения. В довершение у каждой задачи и у каждого блока есть свой статус. У задачи те же статусы, что и в Jira, а у блока лишь два статуса «пустое поле» и «Готово» — такой вариант статусов вполне позволяет отслеживать текущее состояние дел всем заинтересованным лицам.

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

Если разработчиков немного и выставлением задач-тестированием занимается технический руководитель проекта, то в список задач можно отдельными строками помещать лишь исполнение задач, а всё остальное относить на время технического руководителя проекта. В такой ситуации 60% времени будет учтено в строке по самой задаче, 5% времени по задаче «Тестирование» в конце списка всех задач данного этапа, 20% времени по задаче «Исправление ошибок» и 15% времени занимаемые постановкой задачи, интеграцией её в приложение и контролем исполнения задачи будут учитываться как постоянная управленческая работа технического руководителя проекта.

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

Объём работ измеряется в часах. Минимальная единица исполнения задачи — час. Если задача мелкая и вынесена в отдельный пункт лишь с целью контроля, то может быть полчаса. Мельче имеет смысл планировать только объём работ по простым ошибкам, но они в план работ не попадают. Минимальная единица объёма работ для прописывания задачи, тестирования и исправления по задаче — 1/4 часа. Данная деятельность выполняется в пакетном режиме (например, прописываются сразу 5 задач или тестируются сразу все задачи, выполненные за день, или правятся ошибки по всем задачам, протестированным до этого пачкой), поэтому сам пакет подзадач занимает час-полтора, а каждая отдельная подзадача выполняется относительно быстро. Следует лишь учесть, что на первые 10 задач каждого нового разработчика будет тратится непропорционально большое время на составление длинного списка огрехов, обнаруженных во время Code Review. Спустя какое-то время разработчики привыкают писать правильно и Code Review умещается в 10-15% времени отводимого на тестирование.

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

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

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

Учёт рабочего времени

Объём работ имеет подвох, который трудно объяснить неискушённому бизнес-руководителю проекта. Лучше всего механизм этого подвоха показать на простом примере. Технический руководитель посчитал, что 10 задач для разработчика серверной части потребуют 24 часа работы. Задачи были созданы в системе отслеживания задач, разработчик выполнил задачи и в ходе выполнения каждой задачи честно отмечал затраченное на каждую из них время. Суммарное время получилось 24 часа и совпало с проектным. Зарплату он получил за 30 часов. Последнюю задачу перевёл в статус «Выполнено» через четыре дня после начала работы над первой вместо трёх. Занимался он только этими задачами. Куда делись эти 30 — 24 = 6 часов?

Фишка в том, что разработчик не может работать 8 часов в день. Он ходит в туалет раза три-четыре за 8 часов. Отдыхает каждый час минут по пять и этот отдых — часть техники безопасности, без него работать невозможно. Чай себе делает раза четыре в день. В общем, программист на задачи тратит лишь 6-6.5 часов рабочего времени. В ситуации аврала доходит до 7 часов, но долго так продолжаться не может — организм не выдерживает постоянного сидения за компьютером и программирования. И вот эту разницу в полтора-два часа между оплачиваемым временем и временем фактической работы над задачами необходимо как-то учитывать.

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

Трудностью такого подхода является разъяснение бизнес-руководителю и заинтересованным лицам вот этой разницы. То есть почему они платят за 8 часов, а работа осуществляется 6 часов, почему 8-часовой рабочий день планируется как 6-ти часовой. Ещё хуже становится, когда в рамках корпоративной системы учёта рабочего времени требуется заполнять листы отработанного времени с расписыванием их по каждой задаче. Хуже может быть только обязательная интеграция системы отслеживания задач с выгрузкой сырых данных в корпоративную систему.

Ради избежания этого объяснения многие технические руководители проектов просто увеличивают плановое время по задачам на треть, а время фактического исполнения задачи меряется с учётом всех туалетов и передыхов, то есть в размере 8 часов за день. Данный подход приводит к серьёзному искажению отчётности и неадекватности при пересчёте плана на базе данных по времени выполнения типичных задач каждым из разработчиков.

Вход в проект

Следует избегать входить в проект разработки любого программного обеспечения в условиях острой нехватки времени. Данное утверждение вдвойне верно для технологически сложных проектов. Это знают все работающие в ИТ. Но некоторые всё равно идут на данный шаг. Кто-то потому что такие проекты хорошо оплачиваются. Кто-то потому что они бросают вызов разуму. Кто-то потому что других предложений о работе нет. А кто-то просто работает в ИТ и привык, что проекты с разумными сроками здесь так же редки, как тёплые июньские дни этим летом в Москве.

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

То есть все три важных вопроса — это про людей. Не про технологии. Не про методологии. Не про бюджет. Про людей. Программные продукты делают люди руками других людей и поэтому именно они являются следующим по важности риском после сжатых сроков.

Начало разработки

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

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

И так, у нас есть техническое задание в виде какого-то макета интерфейсов приложения в каком-нибудь Axure/Axshare или готовые дизайн-макеты в Photoshop, есть желающие побыстрее начать разработку бизнес-руководитель и спонсоры проекта и есть технический руководитель проекта, который должен организовать разработку максимально быстро. Что делать техническому руководителю?

Для начала следует прописать общую схему работы приложения. Нарисовать то, как данные текут от пользователя в базу и от базы к пользователю. Какие данные текут: чтения из базы, записи в базу, чтения с диска, записи на диск, преобразования изображений и т.д. В каком объёме эти данные текут.

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

После того, как прописаны потоки данных, становится ясно, что из хорошо знакомого инструментария можно использовать в проекте, а что нет. Так же становится ясно, где в архитектуре есть пробелы, которые придётся закрыть плохо знакомыми или вовсе незнакомыми инструментами.

Большим плюсом хорошо знакомого инструментария (база данных, языки, фреймворки, утилиты, кеши и т.д) является отсутствие необходимости тратить время на их изучение и, особенно, на устранение типичных ошибок и разрешение непонятных случаев. Его использование радикально ускоряет разработку. Особенно на начальном этапе, когда остро не хватает времени на изучение нового инструментария.

Из личной практики. Использования незнакомых инструментов стоит остерегаться, но не стоит бояться. Автор заметки однажды столкнулся с необходимостью разрабатывать интернет-приложение на полностью незнакомых инструментах. В ходе прописывания архитектуры и прояснения особенности возникающих нагрузок стало ясно, что из знакомого при разработке можно было использовать лишь Sphinx и Docker. Итогом было успешно построенное приложение и целая пачка новых изученных инструментов в виде Lua, NodeJS, Tarantool, React Native и др.

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

Нижним уровнем интерфейсов выступают репозитории. Репозитории отвечают только за отдачу запрашиваемых из внешних источников данных (база данных, поисковый движок, кеш) и передачу данных во внешние системы (базу данных, поисковый движок, приложения отправки почты и т.д.). Большим плюсом репозиториев является радикальное ослабление связи кода приложения и внешних систем. Решение о выборе поставщика услуг доставки SMS или итоговой базе данных может быть принято в последний момент.

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

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

Итогом было успешное встраивание в приложение Tarantool, он полностью оправдал ожидания.

Верхним уровнем выступает API. В случае с приложением типа клиент-сервер это традиционное REST API или Websocket API. В случае более традиционного сайта с MVC-архитектурой это промежуточный слой из одного класса между моделью предметной области и контроллером. Так же в случае традиционного сайта важно прописать правила именования ссылок, перечень самих ссылок и сопоставление им контроллеров.

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

Если техническому руководителю проекта повезло и удалось обосновать найм тестировщика, то он может оказать всем большую услугу. А именно, написать функциональные и интеграционные тесты на API. Так как API полностью покрывает бекендную часть функционала, то по этим тестам можно отслеживать фактический прогресс разработки бекенда интернет-приложения — это просто доля успешно отработанных тестов API. Так же данные тесты позволят узнать, какой из методов API и с какими параметрами перестал работать. Это становится критично важно через 5-6 месяцев быстрой разработки.

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

Автор заметки не стал писать про важность организации среды разработки, стандартов форматирования кода, правил именования веток Git-репозитория, CI, CD и т.д. Все это знают. И это, действительно, важно. Но гораздо важнее следовать этим важным практикам, чем просто знать об их важности.

Тестирование

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

Тестирование можно разделить на:

• простое ручное тестирование, при котором тестирующий приложение знает, что разрабатывалось и исправлялось и вручную тестирует изменения руководствуясь лишь своей логикой;
• ручное тестирование по списку кейсов или плану тестирования, а в пределе — по методике приёмо-сдаточных испытаний в рамках ГОСТ 34.603-92;
• автоматизированное модульное тестирование;
• автоматизированное функциональное тестирование;
• автоматизированное интеграционное тестирование;
• автоматизированное тестирование на базе спецификаций;
• и т. д. (в условиях острой нехватки времени до этого пункта проект не дойдёт никогда в силу особенностей бизнес-руководства).

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

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

И так, при определённой сноровке первые полгода можно обойтись без автоматических тестов без особых последствий. Ключом к этому являются хорошо продуманная архитектура с минимальной связностью различных частей приложения и постоянный Code Review: отслеживание нарушений в архитектуре, изживание неявных зависимостей и обучение программистов на примере их собственного кода как писать яснее, понятнее и правильнее.

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

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

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

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

В условиях острой нехватки времени никто и никогда не даст времени на написание модульных тестов даже понимая необходимость данных тестов. Бизнес-требования так устроены, что бизнес-руководитель проекта вынужден регулярно выдавать новый результат. Вариант «мы остановим разработку, потратим треть уже затраченного времени — месяца три — на написание модульных тестов и приложение опять станет устойчивым» не пройдёт. Автор заметки не сталкивался, чтобы такой вариант кто-то согласился реализовать. Автор заметки не слышал, чтобы кто-то смог его пробить. Автор заметки даже не читал о подобных чудесах в литературе.

Обычно используется подход с плавным покрытием кода тестами. Либо покрывается лишь новый функционал, а старый постепенно становится легаси; либо покрывается тот функционал, который затрагивается изменениями и правками ошибок; либо используется схема «тронул класс — покрой его тестами».

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

Что делать, если проблема назрела, а денег нет, то есть проект развивается по первому варианту? В такой ситуации следует покрывать тестами лишь наиболее проблемный код. Его можно выделить либо по местам локализации ранее найденных ошибок, либо по местам наиболее долгого исправления ошибок, либо изучая код на наличие в участках кода большого количества связей, зависимостей и сложной логики. Для этого необходимо с начала проекта вести лог ошибок (например, в виде билетов на исправление ошибок в Jira), замерять время исправления ошибок, опрашивать разработчиков на предмет того, какие участки кода им кажутся сложным и самому понимать код. Последнее требуется скорее для того, чтобы отбросить те предложения программистов, которые затрагивают улучшение и без того вполне годного кода (то есть не такого ужасного, как остальной).

И последнее. Замечено, что если все тесты выполняются менее 3-х секунд, то программистам не составляет труда их запускать. Особенно если их запуск выведен в браузер и делается простым обновлением страницы. Если тесты выполняются более 10 секунд, то программисты начинают лениться и отправлять на сервер код, в который в последний момент была внесена правка, а ждать прогона тестов не хотелось. Так же замечено, что регулярное наличие в основной ветке непройденных тестов сильно демотивирует разработчиков на запуск тестов.

Написание полного набора тестов занимает 30% всего времени разработки. Ручное тестирование, исправление, перетестирование и так пока не заработает занимают 40% всего времени. При этом автоматические тесты гарантируют некоторый заранее определимый уровень качества кода. Выбор за вами.

Инфраструктура

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

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

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

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

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

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

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

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

Документирование

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

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

Для этого достаточно выполнить следующее:

• код должен иметь стандарты кодирования для всех используемых языков;
• код должен прогоняться через инструмент проверки соблюдения стандартов кодирования;
• наименования схожих по функционалу объектов должны быть стандартизированы;
• разработчиков необходимо стимулировать писать длинные имена классов, длинные имена функций и длинные наименования переменных — современные IDE с их подсказками позволяют использовать такие имена без затраты дополнительного времени на набор букв, при этом говорящие за себя названия значительно ускоряют понимание кода и его написание;
• код должен проходить процедуру CodeReview и отправляться на доработку при малейшей неясности с разъяснением разработчику, к чему данная неясность может привести.

Так же желательно полностью задокументировать инфраструктуру.

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

Начало эксплуатации

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

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

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

Начало эксплуатации заканчивается после того, как продукт может существовать без разработчиков. То есть первым стабильным релизом, запуском MVP. С этого момента продукт переходит в стадию собственно эксплуатации.

Подготовка к началу эксплуатации

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

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

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

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

Все должны понимать, что перед релизом необходимо внимательное тестирование. И только после того, как технический руководитель уверен, что релизы проходят серьёзное тестирование, вот только тогда он может договариваться о регламенте исправления ошибок во внерабочее время. Регламент следует прописать так, чтобы участие технического руководителя по возможности ограничивалось SMS-ками о проблеме и её решении.

Описанный сложный социальный процесс тоже часть подготовки к началу эксплуатации.

Ещё одним важным моментом подготовки к началу эксплуатации является непредсказуемость нагрузки сразу после запуска. Если маркетинговый анализ промахнётся с потоком посетителей всего в два раза в обе стороны, то помните — перед вами либо мастер понимания рынка, либо чистое везение. Посему технический руководитель должен проработать схему запуска с минимальными техническими ресурсами так, чтобы за час можно было масштабировать нагрузку в десяток раз. Современные технологии позволяют это реализовать достаточно прозрачно. Это позволяют и технологии предыдущего витка развития, необлачные. В умелых руках это позволяли даже технологии 15-летней давности.

Технический руководитель проекта может использовать:

• облачные серверы с моментальной докупкой мощностей по мере надобности;
• снижение нагрузки за счёт отключения функционала (например, полнотекстового поиска, оставив лишь поиск по заголовкам);
• снижение нагрузки за счёт ограничения скорости регистрации с помощью инвайтов;
• вынос статических файлов в сеть доставки контента;
• включение микрокеширования страниц (кеширование на 1 секунду творит чудеса);
• кеширование первой страницы;
• упрощённый вариант первой страницы;
• ограничение посетителей по белым листам IP (например, только из интересующей страны).

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

Развитие продукта после начала эксплуатации

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

Все это знают. Никто так не делает. Чуть реже чем всегда на базе будки пытаются построить небоскрёб. Результат как бы заранее предсказуем, все это изначально понимали, но после возведения небоскрёба удивляются, почему опять вышло вкривь и вкось.

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

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

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

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

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

Выход из проекта

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

У продуманного технического руководителя проекта первой точкой принятия решения является момент входа в проект, второй — запуск MVP, а третьей — частичный выход из проекта основателей.

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

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

Если у проекта кончились деньги

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

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

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

Практика показала, что даже если есть возможность заплатить работникам сразу, а такое бывает, то технический руководитель проекта получит свои деньги спустя некоторое время. Часто в несколько этапов. Основной причиной этого являются размеры выплат. Зарплата технического руководителя проекта составляет от 25 до 40% фонда оплаты труда группы разработки и это весомая часть общей суммы долга.

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

Как часто люди не получают своих денег? Отпускные, оценочно, в трети случаев. Зарплату-полторы плюс отпускные — в одном из десяти. Автору заметки удавалось полюбовно договариваться всегда и получить все свои деньги в пяти из пяти стартапов, в одном из них с серьёзной задержкой. В свою очередь, в нескольких своих стартапах атору удалось расплатиться со всеми работниками на момент их увольнения, а инвесторам выплатить все занятые деньги спустя некоторое время.

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

И так, допустим, что техническому руководителю надоело ждать свои деньги и жить «завтраками» от спонсора. Что ему стоит предпринять?

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

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

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

Далее следует дождаться начала переговоров (инициатор — спонсор) и договориться о графике выплаты честно заработанных денег.

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

Вход в новый проект

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

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

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

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

Хорошо работает место получения образования. Очень хорошо работает фактический опыт, который помогает на собеседованиях показывать свои компетенции в интересующих бизнес-руководителя областях, а в реальной работе быстро решать возникающие трудности. Так же прекрасно помогают найти общий язык человеческие качества и способность понимать других. Вообще, умение излагать сложные технические темы простым языком собеседника весьма редкое качество российских технических руководителей проектов. Оно даёт значительное преимущество перед другими кандидатами. Для технарей это трудно дающийся навык, но его стоит постоянно развивать. Софт-скилам была посвящёна половина раздела «Что необходимо уметь».

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

Заключение

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

Согласно своду знаний по управлению проектами PMBOK, разработанному американским институтом PMI, «проект — это ограниченное по времени мероприятие по созданию уникального продукта, услуги или результата».

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

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

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

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

1. резюме.
   1.1 Суть проекта.
   1.2 Данные об эффективности проекта.
   1.3 Информация о компании.
   Описание участников проекта и отрасли.
   2.1 Краткая информация об отрасли. Имеющиеся факторы (экономические, технологические, политические, экологические, правовые и социальные).
   2.2 Общая информация об участниках проекта.
   2.3 История, финансовые и экономические показатели компаний-участников.
   2.4 Структурная схема управления проектом.
   2.5 Структура управления проектом. 8.
   3 Описание продукции (услуг).
   3.1 Основные характеристики и краткое описание.
   Новизна, новые виды или качественные изменения продукции (услуг), существующие аналоги. 3.3.
   Требования к логистике 3.3.
   3.4 Уникальное торговое предложение, конкурентоспособность, позиционирование.
   Прочее (особенности налогообложения, преференции и т.д.) 4.
2. маркетинг и реализация продукции (услуг)
   Рынок сбыта продукции (услуг), описание основных сегментов рынка, оценка спроса. 4.2.
   4.2 Конкурентный анализ, позиционирование проекта
   4.3 Ценообразование продукции (услуг), ценовая политика, программы лояльности. 4.4.
   4.4 Каналы сбыта продукции (услуг).
   4.5 Стратегия маркетингового продвижения.
3. план производства.
   5.1 Обоснование и ожидаемые результаты исследований и разработок (НИОКР).
   5.2 Технология, качество и сертификация.
   5.3 Производственное пространство.
   5.4 Оборудование.
   Материалы, компоненты. 5.5.6.
   5.6 Человеческие ресурсы.
   5.7 Энергетика, технологии, связь и транспорт. 5.8.
   5.8 Вопросы экологии и безопасности.
   5.9 Оперативный план. 6.
4. организационный план.
   6.1 Руководящий состав.
   6.2 Юридическая поддержка.
   6.3 Партнеры.
   6.4 Поддержка и преимущества.
   6.5 Организационная структура для реализации проекта. 6.6.
   6.6. временной график (план реализации проекта). 6.7.
   Характеристика активов. 7.
5. анализ рисков.
   7.1 Выявление и оценка рисков (тип риска, вероятность возникновения, влияние на проект), включая макроэкономические, политические и промышленные риски; финансовые, коммерческие, организационные и технические риски проекта; социальные и экологические риски.
   7.2 Меры по минимизации основных рисков.

Ключевые моменты

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

определите цели интернет-проекта.

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

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

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

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

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

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

Давайте подробнее рассмотрим требования к сайту.

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

Значительные преимущества имеет регистрация доменов в крупных зонах, то есть в России — это зона «.ги», «.су» и «.рф». После разработки концепции регистрации вашего домена не следует затягивать с осуществлением этого процесса, так как желаемые доменные имена могут быть заняты другими претендентами. В зоне «.gi» уже зарегистрировано более 1,5 миллионов доменов, в зоне «.sot» — около 80 миллионов. Мы рекомендуем использовать кириллические имена сайтов в зоне .рф.

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

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

Выбор подрядчика для разработки сайта

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

• Специализированная веб-студия;
• Рекламное агентство
• дизайнерское агентство
• компания по разработке программного обеспечения;
• виртуальное сообщество «свободных художников» {добровольное);
• неквалифицированный новичок, «студент»;
• рециркуляционные решения, аренда площадки, площадка как услуга.

Давайте рассмотрим каждую разновидность более подробно.

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

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

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

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

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

«Виртуальные компании»

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

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

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

Циркуляционные решения. В мире, в том числе и в России, тенденция «программное обеспечение как услуга» становится все более популярной. В частности, ряд известных компаний предлагают разработанный ими инструментарий, известный как «конструктор сайтов». Эта услуга обычно включает аренду CMS и хостинг. В этом случае клиенту предлагается «шаблонный» дизайн и набор программных модулей для расширения возможностей созданного сайта, по принципу «больше опций — дороже аренда».
Использование инструментария «Конструктор сайтов» дает конечному пользователю возможность оценить собственный сайт и освоить ряд специфических особенностей работы с ним. Поскольку это лишь «способ попробовать», то в дальнейшем предполагается разработка полноценного сайта или покупка CMS, на базе которой и будет осуществляться аренда.

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

Поддержка сайта

Техническая поддержка веб-сайта. Сайт в Интернете — это особый вид сервиса, который работает без перерыва все 7 дней в неделю и все 24 часа в сутки. Для поддержания такого режима бесперебойной работы необходима достаточно квалифицированная команда профессионалов, обеспечивающая техническую поддержку данного сайта. Услуги технической поддержки веб-сайта включают управление веб-сервером и установленным на нем программным обеспечением, мониторинг работы веб-сайта, обновление программного обеспечения, регулярное профилактическое обслуживание аппаратного и программного обеспечения. Хорошо организованный сайт поддержки предотвращает возникновение аварийных и критических ситуаций, которые приводят к сбоям в работе веб-сервера и в конечном итоге препятствуют взаимодействию с посетителями сайта.

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

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

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

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

Виртуальный выделенный хостинг

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

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

Выделенный сервер. В варианте «выделенный сервер» количество виртуальных серверов в точности равно количеству физических серверов, т.е. один физический сервер соответствует одному пользователю. Здесь в распоряжении компании находится весь физический сервер, поэтому нет потерь на программном уровне виртуализации, которые, по оценкам, составляют до 10% производительности. В этом случае вы просто покупаете свой собственный сервер и размещаете его в дата-центре провайдера вместе с быстрым телекоммуникационным оборудованием. Чуть менее распространена аренда физических серверов. Очевидными недостатками этого варианта являются более высокая стоимость такого решения по сравнению с DRM/ROB и низкая эффективность использования, поскольку многие автономные серверы используются лишь 15-20% времени. В то же время им требуется место в стойке для оборудования, услуги электропитания и охлаждения, а также постоянное управление и мониторинг.

Компьютерный кластер с балансировкой нагрузки — это группа физических серверов. Между этими серверами нагрузка обычно распределяется с помощью инструментария «балансировщика нагрузки». Есть случаи, когда инструментарий «балансировщика нагрузки» представлял собой аппаратное решение (например, решение корпорации C/jaso). Полученное гибридное решение обладает преимуществами двух предыдущих вариантов и идеально подходит для таких гигантов рунета, как Rambler или Яндекс. Не все интернет-проекты требуют таких ресурсов и такой сложной архитектуры с гигантским масштабом, мощным центром обработки данных и огромными затратами.

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

На странице курсовые работы по менеджменту вы найдете много готовых тем для курсовых по предмету «Менеджмент».

• Здесь темы рефератов по менеджменту

Читайте дополнительные лекции:

1. Оптимизация организационной структуры
2. Процесс и функции менеджмента
3. Японская культура управления
4. Генити Тагути, японский инженер и статистик
5. Выбор альтернативы в управленческом решении
6. Использование информации в основных функциях менеджмента
7. Системный подход в производственном менеджменте
8. Управление интернет — проектами
9. Интегрированные системы менеджмента
10. Методы выбора проекта

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

Разберём слона на слонят.

Детализация задачи

Как происходит детализация слона? Сам слон, то есть задача, — это epic, некая большая конечная цель: сайт, лендинг, что угодно. Epic мы разбиваем на stories — задачи поменьше: программирование, вёрстка, дизайн, контент сайта и так далее.

Дальше нужно детализировать процессы на задачи, каждая из которых будет занимать 4–6 часов. Такие задачи называются tasks. Не бойтесь детализировать и составлять большой список задач, это действительно поможет в работе.

Список tasks (синяя иконка) и stories (зелёная иконка) внутри одного epic (неполный список)

Пример. В программе постановки задач Jira мы создали epic под названием «Главная страница». А в ней подзадачи-stories: «прорисовать», «закодить», «написать текст», «подобрать иллюстрации». И в каждой такой задаче — несколько tasks. Это мелкие задачи, которые занимают (в идеале) не более 4 часов. Например, в story «Нарисовать дизайн сайта» у нас будет task «Нарисовать шапку» или «Нарисовать иконки».

Хороший task длится максимум 4 часа и его нельзя разбить на ещё более мелкие задачи. У любой задачи есть ответственные, то есть исполнители.

Если говорить о тексте для главной страницы сайта, то у нас будет такая лестница задач:

• epic — «Создать главную страницу»;
• story — «Написать тексты для главной»;
• а tasks будет очень много: «Заполнить бриф», «Написать тексты», «Защитить тексты перед клиентом», «Отредактировать тексты».

В Jira можно связать крупную задачу (story) с более мелкими (tasks)

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

Оценка задачи и ресурсов

У любой задачи есть оценка. Оценка означает предполагаемые временные затраты и количество необходимых людей. Оценка даёт картину затрат ресурсов по каждой задаче. Детализировать и оценивать ваших слонов вы можете в любой удобной программе, даже в таблицах Google.

Оценить более мелкую задачу проще, чем крупную. Одно дело — оценить задачу «Собрать ядро запросов». Это сложно. Другое дело — разбить её на ряд максимально односложных задач: «Собрать кластеры запросов», «Собрать по кластерам в нужном формате», «Свести данные в Excel» и так далее. Эти задачи гораздо проще оценить по времени. Выносите в отдельный task каждый шаг, и тогда оценить будет легче.

Оценка общего списка задач внутри эпика в Jira

Как оцениваем время задачи

При оценке задачи мы выставляем оценочное время (estimate). Это наш прогноз временных затрат. В процессе выполнения заполняется графа фактически затраченного времени (log). Исполнители отмечают потраченное время в Jira.

В Jira оценка задачи видна в блоке Time Tracking

Реализация: циклы

В сутках ограниченное количество рабочих часов. Для того мы и применяем детализацию, чтобы осознанно использовать временные циклы. Обычно в веб-разработке цикл занимает рабочую неделю. В начале недели на планёрке мы смотрим, какую часть слона мы «съели», и приступаем к новому циклу.

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

Зелёным цветом выделяется прогресс выполнения задачи

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

Если у вас нет большого потока задач, то следить за управлением проектом можно даже в Excel или Google Таблицах. Но сохраните методологию: разбивайте задачи на более мелкие, проставляйте статусы выполнения и указывайте ответственных.

Пример таблицы управление проектом в Google Sheets

Пошаговая инструкция и советы

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

Сроки задач

Для каждой задачи мы выставляем два дедлайна. Внутренний дедлайн называется redline («красная черта»). В этот срок работа должна быть сделана внутри компании, но ещё остаётся время на доработки перед показом клиенту. Deadline — крайний срок демонстрации результатов клиенту. Он несдвигаемый.

Используйте redline — это значительно снижает стресс и повышает качество итоговой работы

Контроль своих и чужих задач

Программы вроде Jira позволяют быстро находить свои и чужие задачи с помощью фильтров: по имени, срокам, проекту. По всем фильтрам можно делать «напоминалки»: вы будете получать письма про задачи с определёнными параметрами.

Примеры почтовых рассылок по событиям для контроля изменений в Jira

Как ставить задачи, которые так и хочется выполнять

Как придумывать удобные и полезные названия задач? Название хорошей задачи отвечает на вопрос «что делать». «Сверстать страницу о компании», «Написать текст для страницы о нас», «Показать клиенту анимацию кнопок X».

Правильное название задачи описывает не процесс, а результат: не «Подумать над ускорением сайта», а «Ускорить сайт до 90 баллов по Google PageSpeed». Результат выполнения задачи измерим и выражается либо в цифрах, либо в конкретных действиях.

	Не надо так	Надо так!
	Подумать над ускорением сайта	Ускорить сайт до 90 баллов по Google PageSpeed
	Протестировать вёрстку	Записать в файл с багами все проблемы вёрстки
	Посмотреть текст на сайт	Оставить комментарии в Google Документе к тексту от копирайтера

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

	Не надо так	Надо так!
	Сделать вёрстку о компании	alta-profil.ru: сверстать страницу «О компании»
	Реализовать вёрстку страницы услуги	alta-profil.ru: сверстать страницу «Услуги»
	Верстать главную	alta-profil.ru: сверстать страницу «Главная»

Описание задач

Задачи от epic до task нужно описывать максимально подробно. Пишите всё, что знаете о задаче. Иначе всё, что вы не скажете, гарантированно потеряется, забудется, не будет учтено или будет понято неверно. Расписывайте все мысли по задаче, но не в режиме потока сознания, а структурировано.

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

Идеальная задача та, к которой нет ни одного уточняющего комментария от исполнителя.

Задача определена, когда из неё полностью понятны исполнителю:

• сайт или объект, для которого нужно выполнить задачу;
• объём работ в часах и серии подзадач;
• трудозатраты на задачу (фиксированные или «от». Если «от», то когда надо остановиться?);
• сроки исполнения;
• исполнитель;
• описание задачи максимально понятное и подробное;
• все файлы, документы, картинки, таблицы приложены к задаче. Если это ссылка, то доступ исполнителю открыт.

Пример подробного описания задачи

Кейс: разбивка и детализация

Мы используем программу Jira и платное дополнение Jira Portfolio. Вы можете применить сам подход в любой программе или таблице.

Как вы видите на скриншоте ниже, мы сделали три вещи, лежащие в основе управления проектами.

1. Разрезали слона на кусочки: детализировали задачи.
2. Дали оценку задачам.
3. Назначили ответственных.

С помощью Jira Portfolio мы создали зависимости между задачами. Одна задача не начнётся, пока не закроется связанная с ней более ранняя. Это представлено визуально.

Пример заданной зависимости между задачами

Система считает по каждой задаче примерное время, когда исполнитель сможет приступить к задаче. Также система рассчитывает время окончания задачи. Если нам не нравится расчётное время, система покажет, как она распределила задачи исходя из уровня занятости специалистов. В нашем случае мы видим, что посадочную страницу мы сможем сдать только 3 января, хотя она нужна уже в ноябре!

Почему так происходит? Внутри отчёта по загрузке времени сотрудников видим, что ключевые специалисты по этому проекту уже заняты на возможные 40 часов в неделю.

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

Необходимо видеть общую картину проекта, чтобы с учётом зависимости задач перераспределить объём работ по спринтам и успеть в срок. Мы увеличиваем приоритет epic-задачи. Тогда остальные проекты автоматически (по мнению системы) станут менее важными.

Однако в реальности не всегда можно полагаться на мнение системы. Для этого и нужен менеджер проектов. Он может вручную сдвигать приоритет задач, чтобы в работу шли более важные задачи, а те, которые могут подождать, переместились на более поздний спринт. Именно поэтому человека пока ещё не может заменить обезьяна или робот ;–)

Резюмируем

Итак, управление проектами в веб-разработке базируется на трёх столпах.

1. Детализация задач. Наша цель — разделить слона на максимально краткие и простые задачи.
2. Оценка. Оценивайте каждую задачу по двум временным точкам: предположительное время выполнения и фактическое время выполнения. Дедлайна у нас также два: redline для внутренней сдачи и deadline — для сдачи клиенту.
3. Циклы. Назначайте исполнителей, расставляйте приоритеты, перетряхивайте приоритеты при необходимости. Опирайтесь на недельные циклы, которые закрывают планёрки.

Максимально точно и подробно описывайте задачи. Используйте программы для автоматизации и удобства или руками создавайте таблицы. Главное: соблюдайте принципы управления.

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.