Бесплатный фрагмент - Решебник начинающего руководителя проекта

Мы правда написали книгу?! \ Введение

Привет! Меня зовут Дмитрий, и я в информационных технологиях уже порядка 30 лет. За это время успел поработать во всех основных ролях — админ, разработчик, аналитик, руководитель проекта, директор различных направлений в ИТ.

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

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

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

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

Опытный читатель скажет: «Хитренькие какие, книга вон какая большая! А вдруг прочитаю и мне не понравится?» — и будет совершенно прав. Чтобы такого не случилось, мы сделали отдельную главу в самом конце, которая расскажет тебе сразу всю книгу — самое главное из того главного, что есть в книге. Можно прочитать только эту главу, а книгу-то и не читать. А можно прочитать и пользоваться главой как чек-листом и напоминалкой.

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

Поехали! (с) Гагарин

Что главное в проекте? \ Проект и результат

Именно так. Проект и его результат.

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

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

— Проект — это то, что должно заканчиваться конкретным уникальным результатом.

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

— Скорее всего, есть ограниченный ресурс не только времени, но и всего остального — людей, инструментов, станков и т. д.

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

Вот, собственно, от этого и будем с тобой плясать.

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

Шагнем чуть дальше и зададимся вопросом: а кому нужен результат?

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

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

— ты;

— люди;

— инструменты (сервера, рабочие окружения и т. д.);

— любые другие ресурсы (от бумаги в принтере и чата для общения с командой до знаний сторонних экспертов);

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

— результат;

— заказчик, которого этот результат должен удовлетворить.

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

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

Давай рассмотрим реальный студенческий кейс.

Группе студентов 1–2 курсов необходимо сделать учебный проект. В качестве проекта была выбрана автоматизация одного из подразделений университета.

Разложим сначала контекст:

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

— Команда. Студенты в количестве 4–6 человек с разной специализацией.

— Руководитель проекта. Ты.

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

— Время. Полгода календарных = один учебный год (с учетом старта проекта и его защиты).

— Результат:

— Умными словами: информационная система, которая автоматизирует бизнес-процессы для сотрудников подразделения.

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

Вроде все понятно. Так ведь?

На самом деле не до конца. Чтобы хорошо описать результат, надо для начала ответить на несколько простых вопросов «зачем». К примеру, таких:

— Зачем это заказчику? (Ответ: чтобы работалось удобнее, быстрее и все было в одном месте. Ок.)

— Зачем это команде? (Ответ: чтобы:

— сдать проект и получить оценку;

— научиться работать в команде;

— научиться новым технологиям;

— в идеале получить деньги за проект или грант на развитие.)

Звучит неплохо! Все?

И снова нет. Надо посмотреть на контекст еще шире и добавить:

— Зачем это университету?

— Вам повезло — вы автоматизируете кусочек внутренней «кухни». Университету как организации это нужно.

— Улучшение работы отдела университета, за счет этого улучшится репутация университета.

— Получить социальный эффект.

— Зачем это преподавателю?

— «Прогнать» вашу группу через проект и оценить результативность и возможность совместно работать.

Итого:

Вы станете востребованными и дорогостоящими кандидатами на рынке труда. Будете много зарабатывать.

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

Вот теперь результат выглядит полнее:

На выходе получаем информационную систему, которая:

1. автоматизирует основные сценарии конкретного подразделения университета;

2. работает по государственным стандартам (мы же помним, что университет — это государственная структура?);

3. система построена на востребованных рынком технологиях;

4. в ИС заложена возможность развития и масштабирования;

5. обеспечена эффективной мотивированной командой разработки и поддержки;

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

А каждый представитель проектной команды:

7. защитил проект и получил отличные оценки;

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

9. возможно, стал чуть богаче.

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

Осознав контекст результата, можно продумать риски и заранее их проработать и/или задать себе и ответственным лицам соответствующие вопросы. Например, такие:

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

— В каких юридических условиях вы находитесь как команда? Оформляли ли вы проект официально? Если да, то как?

— Что будет являться успешным проектом с точки зрения команды?

— Как решить конфликт «технологии университета vs технологии, востребованные рынком», если таковой возникнет?

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

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

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

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

— Мы очертили границы будущего результата. Поняли, что делаем в принципе, а чего не будем делать точно.

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

— Мы утвердили приоритеты и ограничения, а также образ будущего проекта (после наступления «нашего» результата).

Все это поможет нам в формулировке «правильного» результата и в расчете достижимого «Как сделать результат» (т. е. его плана).

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

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

Результат важнее процессов!

Исходя из этого выставляй приоритеты, разрешай споры и фокусируй работу.

Повторим в очередной раз главное, что надо запомнить из этой главы:

— Главное — результат.

— Результат должен быть получен в определенный срок.

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

— Обсуждение деталей проекта должно проходить в контексте планируемого финального результата.

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

За что отвечаю я? \ Роль менеджера проекта

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

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

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

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

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

— Аналитик, дизайнер, архитектор, проектировщик — довольно близкие по смыслу роли. Это специалисты, способные представить будущий продукт в виде модели: процессов, сценариев, дизайнов интерфейса, модулей, сервисов, объектов и компонент. Зачем? Да чтобы уменьшить вероятность ошибки в разработке. Чем шире и качественнее проведено предварительное моделирование, тем меньше вероятность, что разработчики «выбросят» уже написанный код из-за появившихся уточнений/требований.

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

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

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

— DEV, т. е. для разработки;

— QA для тестирования;

— UAT (user acceptance testing), предназначенный для приемки продукта.

— Менеджер. Это ты. И у тебя много дел. Давай попробуем обозначить основные твои обязанности и результаты:

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

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

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

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

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

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

Акцент твоей работы в роли менеджера будет меняться по ходу проекта:

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

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

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

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

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

Итак, краткие тезисы этой главы:

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

— Роль не равно человек. Береги ресурсы, если проекту не нужна/не ценна работа какой-то роли.

— Роль менеджера — в достижении общего результата.

— Акценты в твоей работе зависят от текущего состояния результата всего проекта.

Ну все понятно, а начинать-то с чего? \ Старт проекта

Как гласит один из законов Мерфи, «все, что хорошо начинается, кончается плохо. Все, что плохо начинается, кончается еще хуже».

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

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

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

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

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

— Функции продукта.

— Техника и инфраструктура.

— Процессы совместной работы.

— Этапы, контрольные точки и дедлайны.

— Источники информации для будущего сбора требований.

— Пользователи, роли и их ограничения.

— Риски.

— Прочее.

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

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

3. Границы проекта. Как только вы более или менее зафиксировали Видение, пришло время прописать Границы проекта. Это дополнительный раздел, где четко описано, что НЕ будет входить в систему и где заканчивается то, что уже описано. Чтобы не было недопонимания потом в стиле: «Я думал, раз вы делаете мостик, то и асфальтированную освещенную дорогу в 5 км к нему сделаете, а иначе как им пользоваться?» Это тоже должно входить в полный вариант Видения. Или следует четко прописать, что никаких подъездных путей и освещения в конечном результате не предусмотрено.

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

4. Требования. Теперь уже можно писать Техническое задание (оно же — Требования). Хотя бы верхнего уровня. Берете Видение + Границы, разбиваете на сценарии и бизнес-кейсы и начинаете прорабатывать каждый в отдельности. Как проработали, прикидывайте архитектурную, техническую, интеграционную, инфраструктурную и все остальные стороны. На этом этапе необходимо продумать и описать все, включая такие очевидные вещи, как, например, авторизация, восстановление пароля, управление пользователями, уведомления и т. д. Потом надо будет оценивать, как эти задачи влияют на трудозатраты и сроки реализации.

Глубина и структура ТЗ определяется тобой (ТЗ — это текстовая модель результата. Выше мы писали про роли аналитиков-проектировщиков и про то, что глубина их участия в разных проектах разная). Есть, конечно, различные стандарты, но лучше ориентироваться опять же на здравый смысл. ТЗ должно быть понятным, должно описывать, что и как надо сделать. Больше его расписывать, если нет специальных требований заказчика, смысла нет. Если только в качестве упражнения в стиле «А жахну-ка я ТЗ по ГОСТ 34.602—89», но это уже на любителя.

5. Технологии. Пока вы описывали Требования, как система должна работать, что включать, что не включать и т. д., дальше надо договориться о технологиях создания. Вы оба (заказчик и команда) уверены, что понимаете, как надо. Только в понимании проектной команды и заказчика могут присутствовать разные технологии. Если два этих списка технологий более или менее сошлись — прекрасно. Если нет, надо договариваться. Делать все на старых технологиях — не вариант, но и совсем все новое, скорее всего, тоже не получится протащить. Тут нужен разумный компромисс — то, что без особых проблем «встанет» у заказчика, и то, на чем можно вести разработку на современном уровне.

6. Установочная встреча (она же kick-off meeting). Это неформальная встреча с участием заказчика, руководителя проекта и команды. Ее можно провести раньше официального старта работ или чуть позже. У нее нет протокола или обязательных составных частей. Это, скорее, ознакомительная и вдохновляющая встреча. Команда видит заказчика, заказчик видит команду и может услышать каждого. Заказчик обычно рассказывает о своей бизнес-задаче, цели проекта, уже плюс-минус согласованном с менеджером Видении, границах проекта и подходах. PM (Project Manager — ты) может рассказать про подходы к реализации, о технологиях и команде. Именно в этот момент проясняются ваши ожидания друг от друга, в этот же момент возникают вопросы и предложения, которые могут сфокусировать конечный продукт или прояснить новые риски. На встрече заказчик «вливается» в команду, появляются общие цели и ожидания. И это хорошо.

7. Minimal Viable Product (он же MVP). Выделите с командой и заказчиком основные этапы и MVP, т. е. минимальный кусок системы, который покажет основной процесс или его часть. Потом это будете развивать. Вам результат нужен как можно раньше, чтобы проверить вашу идею и видение конечного результата. Есть миллион причин, почему проект может не взлететь. И половину этих проблем тебе придется решить в виде задач как раз при создании MVP.

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

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

8. Оценка трудозатрат. Теперь MVP надо оценить. В виде задач верхнего уровня, которые вы постепенно детализируете до конкретных понятных атомарных (малых) задач. Желательно, чтобы оценка каждой задачи не превышала 1–3 дня работы. Вы получаете структурированный план работ и Трудозатраты.

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

10. Дорожная карта. Детальные оценки на MVP и экспертные (на остальные этапы) лягут в основу верхнеуровневой Дорожной карты. Нарисуйте линейку и на нее нанесите результаты, когда и что будет. Или под ней укажите, когда начнутся и закончатся этапы. Масштаб линейки и цена ее деления зависит от величины проекта. Обычно таймлайн — от недели до квартала. При проектах больше 2 лет их разбивают на отдельные проекты и объединяют их в связанную программу. Но пока это вам не грозит. Так что берите и верстайте Дорожную карту.

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

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

Кто все эти люди и как с ними работать? \ Команда

У тебя появилась твоя команда. И это прекрасно.

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

Проектная команда отличается от простой группы специалистов наличием следующих вещей:

— общих целей;

— общих соблюдаемых правил;

— специализации (или выполняемых ролей);

— активного взаимодействия внутри.

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

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

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

2. Человек командный. Представитель команды. Это специалист с компетенциями, на которые ты рассчитываешь. Этого человека рассматривают с точки зрения так называемых hard & soft skills. Т. е. что он знает, умеет и вообще насколько готов работать в команде.

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

Обращай внимание на это качество, оценивая успехи команды и отдельных ее представителей. Бывают люди со слабыми soft & hard навыками, которые за счет усидчивости и упорства выдают результат даже бо́льший, чем «звезды». Возможно, при этом они делают ошибки, но они не высовываются и не рекламируют себя. Анализ фактических результатов показывает, что они молодцы. Опирайся на результативных людей.

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

a. Хороший человек. ТОЛЬКО «хороший человек». Это может быть друг/подруга, отличный добрый человек широкой эрудиции и искрометного юмора и вообще душа компании. Но бывает, что посмотришь на него с точки зрения результата, а там пустота. А если ты отбросишь эмоции, то обнаружишь, что проектные созвоны превращаются в веселые посиделки.

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

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

«Хорошие» люди (в том смысле, в каком они описаны выше) постоянно тормозят проект, т. к. на них тратятся управленческие и временные ресурсы. Токсичные люди кратно повышают риски — ты понадеешься на них, и в ответственный момент они тебя подставят так или иначе. Могут сами потеряться, могут выбить полкоманды своим общением или что-то еще. Обычно лучше сделать чуть позже, но гарантированно и управляемо, а не уповать на то, что пронесет.

Есть хорошая поговорка на эту тему: «Лучше с умным потерять, чем с дураком найти». Время показывает, что не зря ее мудрые люди придумали.

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

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

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

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

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

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

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

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

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

Резюмируем:

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

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

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

— Мотиваторы у всех разные — от денег и признания до новых навыков и причастности к великому результату. Ты должна эти мотиваторы знать.

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

Как оценить работу и составить план? \ Оценки, сроки и ресурсы

« — Есть ли у вас план, мистер Фикс?

— Есть ли у меня план? Да у меня целых три плана!»

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

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

Поэтому с точки зрения задачи есть два вида времени:

— Трудозатраты. Т. е. за сколько человеко-часов (человеко-дней и т. д.) можно выполнить ту или иную задачу.

— Срок реализации задачи. Это уже календарные или рабочие часы или дни.

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

1. Когда исполнитель сможет приступить к задаче?

2. Может ли таких исполнителей быть несколько? Это конкретные лица или любые члены команды (подходящие для задачи, разумеется)?

3. Выполнены ли все предварительные работы и задачи?

4. Есть ли элемент риска в задаче (риск ее внезапной остановки или увеличения трудозатрат)?

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

У вас в команде есть человек, который может выделять по 8 часов в неделю (примерно по часу в основные рабочие дни после учебы и по 3 часа в выходные). Это доступный ресурс. Если он один, то срок рассчитывается просто:

Срок реализации = 20 / 8 = 2.5 недели.

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

Они вдвоем смогут сделать эту задачу за 20 / (8*2) + Х трудозатрат, т. е. где-то недели за полторы или даже две, а не за 1.25. Где X будет нелинейно увеличиваться с добавлением каждого нового исполнителя задачи.

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

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

Вернемся к понятиям трудозатрат, ресурсов и сроков.

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

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

Давайте разделим в голове:

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

Например:

— анализ и составление требований (40 человеко-часов);

— разработка ПО (320 человеко-часов);

— тестирование (40 человеко-часов);

— развертывание и обучение (80 человеко-часов).

2. Дорожная карта — это планируемые бизнес-результаты и сроки.

Например:

— техническое задание — 10.04.24;

— дизайн ключевых экранов — 01.05.24;

— версия на DEV-окружение с полным функционалом и доступная для тестирования — 01.07.24;

— решение развернуто в промышленную эксплуатацию — 01.08.24.

3. Одно в другое переводится расчетами через доступные в проекте ресурсы с учетом рабочего графика и рабочего календаря. Т. е. тут надо предусмотреть праздники, отпуска и заложить время на риски (к примеру, на болезни в межсезонье).

Пара слов про понятие доступности ресурса.

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

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

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

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

Резюмируем:

— Различай трудозатраты (объем) и сроки (время достижение результата).

— Срок — величина, рассчитанная на основе трудозатрат, ресурсов и календаря работы.

— Учитывай все, а не только доступные ресурсы. Сюда могут входить деньги, инструменты, инфраструктура, площади и т. д.

— Добавление нового человека в проект замедляет работу на первых этапах.

— Изучи методы и инструменты календарного планирования. Например, MS Project и диаграммы Ганта. Это полезно.

А мне за это заплатят? \ Финансы и схемы работы

В начале любого проекта бывает сложно найти ответ на два вопроса:

— Просить денег или не просить, а если просить, то сколько? (с) Команда

— Платить или не платить, а если платить, то сколько? (с) Заказчик

Рано или поздно перед менеджером встает вопрос: «Вот мы собираемся работать, а нам за это заплатят? И если да, то сколько?» Давай разберемся, какие бывают схемы оплаты/монетизации работы и как они связаны с результатом.

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

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

Чтобы понять, как вы будете работать, необходимо понять, кто будет платить вам деньги или инвестировать в проект.

Тут все просто:

— деньги платит инвестор, или вы сами можете выступить инвесторами;

— деньги платит заказчик.

В этих подходах есть фундаментальная разница.

В сфере IT можно выделить базовые схемы работы: