Проекты как делают: Как делать проекты, не стреляя себе в ногу — Офтоп на vc.ru

Как делать проекты, не стреляя себе в ногу — Офтоп на vc.ru

Советы по управлению проектами от бывшего руководителя отдела разработки агентства Friends Moscow Петра Фомичёва.

10 703 просмотров

Про управление людьми очень хорошо сказал Егор Волков из компании Greensight: «Люди всегда всё портят. Они обещают и не делают. Или делают, но не так. Или так, но не то. Или то, но долго. Было бы здорово как-нибудь так построить бизнес, чтобы без людей».

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

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

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

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

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

Я обещаю, что не будет сложных инструментов — всё будет просто.

Энтропия? Я что, читаю vc.ru ради умных слов?

Энтропия — это то, что разрушает все наши замыслы. Чтобы попасть на тренировку к 10:00, мне надо встать хотя бы в 8:30. Я уверенно ложусь спать в 1 час ночи — без тени сомнений, что завтра в 10 тренер будет ругаться за то, что я опять пил на выходных и поэтому бью троечку слишком медленно. Всё спланировано, и Google Home готов разбудить меня вовремя. Угадайте, кто незаметно для себя во сне отключает будильник?

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

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

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

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

Тут мы приходим к двум важным пунктам:

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

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

Учимся рисовать

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

Если у вас нет шанса спастись и пойти кормить соек с лучшей девушкой в этом городе — с этой секунды для вас начинается проект.

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

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

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

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

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

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

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

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

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

Он превращался из миража в понятную структуру.

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

Делаем крутое ТЗ

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

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

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

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

Загадка: сколько реализовывался проект, на который было отведено 3 месяца?

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

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

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

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

Бесконечная презентация о том, как должен работать проект.

В финале я создаю формальное ТЗ в виде документа, который полностью копирует презентацию по смыслу. Его можно сделать приложением к договору.

Кусочек ТЗ для проекта с видеотрансляцией. Дальше его используют в качестве приложения к договору

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

Погоди. А где разработчики?

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

Я поклонник двух мыслей:

1. Менеджер проекта, если он руководит разработкой, должен уметь кодить. Он не должен уметь писать продакшн-код, но он должен находиться на уровне, когда сам может залезть в документацию к API, посмотреть методы и что-то уточнить. Менеджер должен не только понимать, как строится разработка и что значит писать код, но и осознавать, как мыслят программисты: это значительно улучшит коммуникацию с ними. Я полностью понимаю компании, когда они нанимают менеджеров проектов с техническим образованием. И не очень понимаю те организации, которые сажают в кресла проект-менеджера кого ни попадя.
2. Разработчиков нужно привлекать к обсуждению и планированию проекта как можно раньше. Не стоит думать, что разработчики дураки и ничего не понимают в бизнес-задачах — чем раньше они начнут помогать продумывать техническую сторону вопроса, тем больше времени будет сэкономлено на следующих шагах. Круто, если вы можете приглашать хотя бы одного программиста на сессии проектирования и советоваться с ним в процессе написания документации. Имея такую возможность, пользуйтесь ей постоянно. К сожалению, во многих компаниях это невозможно, поэтому смотри пункт первый — вы должны сами разбираться в технической области ровно настолько, сколько требуется для принятия взвешенных решений о функциональности.

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

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

Небольшой подытог этих страниц:

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

Ахиллесова пята всех проектов

Итак, вы сделали классную документацию и утвердили её со всеми. Настало время распланировать, что вы будете делать, чтобы достичь цели. После фиксирования цели попробуем уменьшить энтропию.

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

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

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

Что нам надо сделать:

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

Декомпозиция выглядит так:

Это метод «от общего к частному», где схема строится от глобальных элементов к самым маленьким. PMBoK описывает несколько случаев декомпозиции: по процессам и по элементам. Честно говоря, мне ни разу не приходилось расписывать процессы с помощью декомпозиции, а вот функциональность — постоянно.

Для digital-проектов я обычно делаю две декомпозиции: одна описывает элементы, вторая описывает функции и логику. Можно разбить на фронтенд и бэкенд — тоже удобно. Главное правило — мы всегда начинаем с самого глобального элемента, например с «Главной страницы», и дальше идём вниз по элементам, строя большое дерево, где они все связаны.

Декомпозиция какого-то старого проекта. Здесь от глобального элемента Landing page исходят следующие области: “Elements”, перечисляющая все элементы на страницы, “Content”, перечисляющая все элементы контента, и “Mechanics”, включающая в себя особые элементы логики. Я делаю декомпозицию в XMind, но это олдскул, и есть облачные решения.

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

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

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

Зачем это делать? Неочевидный плюс в том, что мы сами лучше начинаем понимать весь объём работ. Очевидный плюс — разделение на мелкие кусочки всего проекта помогает нам сделать хороший тайминг.

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

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

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

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

Упс, похоже, что-то идёт не так — таски горят красным! Да и ещё ни один не зафиксирован за исполнителем — совсем беда

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

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

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

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

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

Очень много do nothing — похоже, мы изрядно ленивы

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

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

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

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

На этом этапе у нас есть все составляющие хорошего плана:

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

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

Обо всём этом — во второй части, которую я напишу через неделю.

И если вдруг у вас есть желание предложить мне работу, то можно писать в Facebook или на почту: [email protected].

Три способа делать проекты #2 / Хабр

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

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

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

Есть несколько моделей:
1. Подготовленный захват территории.
2. Хороший уровень без звезд с неба.
3. Предпринимательский заход.

1. Подготовленный захват территории.

Когда есть инвестиции (или клиент готов платить), все сначала проектируется «сверху» до последнего болтика, делается так как нужно, потом запускается.
Плюсы:
— у заказчика есть иллюзия, что это конечный проект — одна смета, одна итерация на уровне создания проекта, вот сделали, запустили, работает. Хорошо в больших компаниях, когда эффективность не так важна, а важны прикрытые задние части менеджеров, которые несут ответственность за проект.
— есть возможность увязать довольно много смыслов в одну цельную систему. Скажем создавать сайт в отрыве от системы маркетинга — бред. Пока не выстроена система продаж, система привлечения, сайт (а он здесь лишь посредник) всегда будет ни о чем. Будет красивая брошюра в интернет, которая никому нафиг не нужна. Если выстраивать систему в целом, то можно спроектировать ее довольно внятно и связанно, тогда каждая ее часть будет усиливать другую и эффект может быть в разы больше, чем в других случаях.
— Все красиво. Все проекты и ТЗ имеют вменяемый и законченный вид, все целостно и логично.
Минусы:
— Такая работа обычно длительна и если компания работает на очень быстром рынке, то внешняя среда успевает измениться, пока проект проектируется и реализуется. В этом случае попадание по целям будет средним, невысоким.
— Большая сумма за весь проект, что подъемно не для всех заказчиков.
— Требует больших системных мозгов, хорошей команды. Не все могут проектировать большие связанные вещи, системы, тем более их реализовывать. На большой сцене плохая игра выглядит очень глупо.

2. Хороший уровень без звезд с неба.

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

Минусы
— Проект приобретает вид процесса. Постоянно возникают новые цели, на их пути лежат новые проблемы, которые требуют новых решений и постоянных усилий\денег\времени.
— Горизонт планирования меньше чем в первом случае, поэтому связанность системы не столь высока. Присутствует постоянное залатывания дыр.
— Требует высокого уровня менеджеров проекта, как со стороны разработчика, так и со стороны клиента, скорости и адекватности общения.
— Теряется много времени и сил на стыках информации между сторонами (клиент—разработчик—пользователь), на анализ, выводы, утверждения, вопросы и ответы.
— Постоянная оплата со стороны клиента за вроде бы как одно и то же — «Мы же платили уже за проектирование!? Мы же платили уже за дизайн?!».
— Если со стороны заказчика процесс не очень хорошо понимают, или хотят сэкономить на консалтинге, проектировании, разработке и внедрении (все хотят сэкономить? ), то будет очень много финансового гемороя.

3. Предпринимательский заход.

Когда ничего не важно кроме денег сейчас. Минимум расходов, делать только то, что приносит прибыль. Делается все на коленке, собирается минимально рабочая система, потом по ходу идет развитие. Минимум инвестиций, только практика, практика, и практика. Головой об стенку, и до победного конца, пока стена не рухнет.
Плюсы
— Минимум расходов
— Максимальная скорость внедрения
— Максимально быстрое реагирование на изменения внешней среды, обратную связь.
— Возможность проверить массу предположений (за счет скорости) и найти работающие варианты.
— Можно начать, сделать и запустить проект уже сегодня. Сегодня!
Минусы
— Требует некоторой предпринимательской хватки. Взять и сделать, без изучения вопроса, без анализа, без всего — просто сделать и испытать. Потом переделать, потом еще и еще, до победы. Так могут лишь немногие.
— Плохо работает на конкурентном рынке (на эмоциональном уровне), вообще не работает на уровне продуктов и услуг Люксового уровня (социальный уровень)
— Позволяет зайти в систему лишь с самого низа. Долгое время придется терпеть все минусы этого положения дел.
— Прибыли не будет вообще, или будет минимальная, на прожиточном уровне, до тех пор пока не закрепитесь, не пробьетесь, не заслужите, не примелькаетесь и так далее и тому подобное. Работа идет с целью роста, а не прибыли.
— При достаточной конкуренции на рынке, или низкой квалификации предпринимателя, скорость роста будет ниже чем скорость развития рынка, поэтому время будет идти, вы будете развиваться, а общая ситуация будет лишь усугубляться 🙁
— Нужен большой запас прочности, способность терпеть боль длительное время.
— Если рынок уже развит, то привлекать профессионалов в такое дело будет очень трудно.
— На развитом рынке с приличной конкуренцией, придется выдавать клиентам Мега-бонусы, чтобы убедить работать с вами.

Есть еще 4й вариант:

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

Как спланировать проект? — Выполните следующие действия, чтобы запустить проект.

Этап планирования является наиболее важным этапом проекта.

Большая часть вашего будущего успеха зависит от того, как вы начнете…

В этой статье я покажу вам, как планировать свой проект.

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

Вот что вам нужно сделать:

• Шаг 1:  Получить понимание предмета
• Шаг 2:  Определить цель проекта
• Шаг 3:  Составьте список задач и результатов
• Шаг 4:  Определить участников проекта
• Шаг 5:  Создайте план ресурсов
• Шаг 6:  Создайте расписание проекта
• Шаг 7:  Создайте бюджет проекта
• Шаг 8:  Проведите совещание по запуску проекта

Шаг 1: Получить представление о предмете

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

Когда я взялся за свой первый ИТ-проект, все было новым. Мне приходилось иметь дело с серверами, хранилищем, резервным копированием и прочим. Проблема была в том, что я ничего не знал об этих вещах. Итак, я подсел к каждому из своих специалистов и спросил: «Скажи мне, о чем все это?» Это было полезно, потому что я получил представление об их работе и понял, как должна планироваться система резервного копирования.

Подобно моему подходу, вы должны попытаться хорошо понять тему.

Как стать экспертом в новой области?

Читая статьи и общаясь с большим количеством людей:

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

Сосредоточьте свое исследование на этих пунктах:

• Каковы основные задачи в таком проекте?
• Как задачи связаны друг с другом? Что нужно сделать первым, вторым и так далее?
• Какие задачи самые сложные?

Мой вам совет: не бойтесь задавать вопросы

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

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

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

Я бы хотел, чтобы вы адаптировали следственный стиль детектива Коломбо. Если вы не слышали о Коломбо: он был детективом в популярном криминальном сериале.

Что особенного было в Коломбо?

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

В типичной ситуации он выходил из комнаты, оборачивался и задавал собеседнику неудобный вопрос: «Еще кое-что…».

Обычно этот вопрос раскрывал убийцу.

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

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

Шаг 2: Определите цель проекта

Цель проекта — это краткое изложение цели проекта: Чего должен достичь проект? Цель обеспечивает ясность и оказывает мотивационное воздействие на команду.

Лучший способ определить цель проекта — задать вопрос: «Какого положительного результата мы ожидаем от этого проекта?». Пригласите заказчика и спонсора проекта обсудить их ожидания. Затем попытайтесь составить короткое утверждение (1–3 предложения), в котором резюмируется цель.

Пример цели проекта:

«Цель проекта — внедрить систему Supersoft CRM в нашем отделе продаж и маркетинга, чтобы повысить удовлетворенность клиентов и сократить среднее время обработки заказов».

Это просто цель высокого уровня, которую вы могли бы поставить в презентации. Вы можете получить более конкретную информацию, определив материальные цели. Конкретной целью может быть повышение среднего рейтинга удовлетворенности клиентов с 4,8 до 5,0 в течение следующих 12 месяцев.

Узнайте больше о том, как определить цель проекта здесь.

Если вам необходимо создать экономическое обоснование, это шаг для этого.

Шаг 3. Составьте список задач и результатов

Быть ответственным за проект может быть невыносимо. Лучший способ преодолеть первоначальный паралич — разбить проект на небольшие части.

На этом шаге вы должны обратить внимание на две вещи:

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

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

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

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

Это помогает разбить задачи по фазам проекта:

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

Что я делаю в начале проекта: я планирую несколько встреч с теми людьми, которые, как мне кажется, имеют какое-то отношение к проекту. Даю обзор проекта и спрашиваю народ: Скажите, какие у вас основные задачи?   В каком порядке их нужно выполнять?

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

Помогут следующие материалы:

• слайды с кратким описанием проекта (отправлены не менее чем за 1 неделю до встречи)
• диаграммы процессов (что изменится?)
• организационные схемы

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

Ниже вы видите пример приглашения Outlook, которое я рассылал бы каждому, с кем хочу поговорить:

В конце этого шага вы должны были составить список действий и ответственных за каждый.

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

Шаг 4. Определите заинтересованные стороны

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

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

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

Заинтересованные стороны делятся на 3 категории:

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

Вот как можно узнать, кто эти люди:

Опросите как можно больше людей в вашей организации: «Эй, как вы думаете, кого мне следует привлечь?» . «Кто еще участвует в этом процессе?» , «Какие люди используют этот продукт?»

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

Я написал подробный пост о том, как определить заинтересованные стороны проекта. Проверьте это.

Шаг 5: Создайте план ресурсов

Сколько часов Джон, Линда и Пит должны работать над вашим проектом? Это то, что вы определяете в плане ресурсов. Он показывает ежемесячные усилия, которые члены команды и отделы должны вносить.

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

Вот простой пример плана ресурсов. Обычно я ставлю проценты, а затем умножаю сумму на количество рабочих дней в месяце (в среднем 20), чтобы получить количество рабочих дней. Например, 0,8 означает, что вы используете ресурс на 80 % в конкретном месяце. 0,8 х 20 = 16 дней.

Шаг 6: Создайте расписание проекта

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

Сначала загрузите мой шаблон плана проекта. Это простой шаблон Excel, который вы можете увидеть на изображении ниже. Затем возьмите выводы из вашего первоначального исследования и обсуждений с вашей командой и запишите основные задачи проекта в соответствующем порядке.

Вот как выглядит реальная временная шкала проекта:

Здесь вы можете скачать шаблон плана проекта Excel

 

Лично я всегда использовал Excel в своих проектах. Он очень прост в использовании, и любой может открыть его. Держитесь подальше от сложных инструментов управления проектами, включая MS Project, если только вы не управляете многомиллионным проектом со сложными зависимостями (здесь я расскажу о MS Project, посвященном тактическому менеджеру проектов).

Почему?

Ваш самый ценный ресурс как менеджера проекта — это ваше время.

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

Помимо плана проекта, обычно необходимо предоставить еще пару документов: смету расходов и план ресурсов.

Шаг 7: Создайте бюджет проекта

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

Ваша смета расходов (бюджет проекта) должна давать приблизительную стоимость по категориям затрат.

Категории затрат, которые входят в бюджет проекта:

• затраты на оплату труда
• стоимость материала
• плата за услуги
• амортизация
• стоимость проезда

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

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

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

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

 

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

Шаг 8: Проведите совещание по запуску проекта

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

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

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

Шаг 9. Не забывайте об организационных моментах

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

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

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

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

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

Подумайте обо всех ресурсах и инструментах, которые могут вам понадобиться в ходе вашего проекта, и убедитесь, что у вас есть доступ к ним, когда это необходимо!

Бонус: подготовьтесь к неудаче

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

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

Занесите все в таблицу Excel.

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

Для примера:

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

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

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

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

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

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

• Во время нашего проекта в Индии самым большим риском было несоблюдение индийского налогового законодательства. Индийские налоговые правила ужасно сложны! Мы легко могли что-то упустить или неправильно понять. Последствия были бы разрушительными. Вы не можете использовать ИТ-систему, которая выдает неверные налоговые декларации! Вот почему мы ОЧЕНЬ рано начали погружаться в налоговое законодательство и составлять обзор налоговых правил и соответствующих сценариев.
• Работа в разных часовых поясах
  Когда вы работаете с распределенными командами, у вас очень мало времени на телефонные звонки и т. д. На выполнение задач, которые можно выполнить за несколько часов, уходят дни или даже недели, потому что вам приходится полагаться на электронную почту коммуникация. Чтобы ограничить негативное влияние этого, мы назначили местного менеджера проекта, который координировал ресурсы в другом месте.
• Узкие места в ресурсах из-за параллельных проектов
  Обычно вам приходится «бороться», чтобы получить необходимые ресурсы, потому что ваши люди также поддерживают другие проекты. Если людям приходится тратить дополнительное время на другой проект, они могут не уложиться в сроки вашего проекта. Это распространенная проблема в крупных компаниях. Что мы делали, так это постоянно следили за ходом «конкурирующих» проектов. Чем раньше мы знали, что у другого проекта возникли проблемы, тем быстрее мы могли реагировать на узкие места в ресурсах.

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

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

— Адриан

Похожие посты, которые вам также могут понравиться

Адриан Ноймайер

Привет! Я Адриан, бывший старший менеджер ИТ-проектов и основатель Tactical Project Manager. Я создал сайт, чтобы помочь вам стать отличным руководителем проекта и успешно управлять интенсивными проектами!

Смотрите сообщения автора

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

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

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

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

Что такое процесс управления проектом?

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

1. Концепция проекта и его инициация

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

На этом этапе разрабатывается устав вашего проекта. Устав проекта — это документ, в котором вы определяете общий объем проекта, цели и управление командой.

Ознакомьтесь со статьей, чтобы узнать больше об уставе проекта: Как написать эффективный устав проекта?

Совет профессионала: Вы сталкиваетесь с проблемами при настройке вех для своих задач и проектов? Не беспокойтесь! Вы можете сделать это в несколько кликов с помощью nTask | Программное обеспечение для управления работой. Пришло время расставить все точки над I и скрестить Т до совершенства!

2. Определение проекта и планирование

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

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

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

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

3. Выполнение и сдача проекта

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

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

4. Мониторинг и контроль выполнения проекта

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

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

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

5. Закрытие и оценка проекта

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

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

10 эффективных советов по управлению проектом

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

1. Определить объем проекта

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

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

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

2. Знайте свой график

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

3. Оценка доступных ресурсов

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

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

4. Создайте план проекта

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

5. Общение с командой

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

6. Делегирование работы в соответствии с доступными ресурсами

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

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

7. Документируйте все!

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

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

8. Мониторинг хода проекта

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

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

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

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

Попробуйте nTask бесплатно и сделайте свои проекты лучшим инструментом.

10. Последующие действия и оценка

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