скачать книгу бесплатно
Решебник начинающего руководителя проекта
Татьяна Белькова
Дмитрий Бельков
Андрей Макаров
Возможно, ты начинаешь руководить проектом. И тебе нужна понятная практика, а не теория. В книге собраны ответы на 26 реальных вопросов – с чего начать проект, как писать письма заказчику, можно ли менять озвученные решения и многие другие.Одна глава – ответ на один вопрос. Просто, понятно, с конкретными советами и примерами. Можешь смотреть оглавление и шагать сразу на нужную страницу. Но лучше прочитать последовательно. Так картинка у тебя в голове будет стройнее и полнее. Удачи!
Решебник начинающего руководителя проекта
Дмитрий Бельков
Татьяна Белькова
Андрей Макаров
Иллюстратор Татьяна Шестак
Иллюстратор Алиса Макарова
Редактор Анна Столярова
Корректор Ирина Игнатьева
© Дмитрий Бельков, 2024
© Татьяна Белькова, 2024
© Андрей Макаров, 2024
© Татьяна Шестак, иллюстрации, 2024
© Алиса Макарова, иллюстрации, 2024
ISBN 978-5-0062-2097-3
Создано в интеллектуальной издательской системе Ridero
Мы правда написали книгу?! \ Введение
Привет! Меня зовут Дмитрий, и я в информационных технологиях уже порядка 30 лет. За это время успел поработать во всех основных ролях – админ, разработчик, аналитик, руководитель проекта, директор различных направлений в ИТ.
Дело было так. Звонит мне дочь Таня, тогда студентка первого курса университета, и говорит, что стала руководителем студенческого проекта. Она начинает задавать вопросы по этой теме, а у меня самого дел море. Я ей говорю, мол, ты вопрос напиши, я подумаю, сформулирую и напишу ответ. Она задавала вопросы, я отвечал. А потом уточнял, как идет, что идет, а что не идет. В конце учебного года мы посмотрели на нашу переписку и осознали: а ведь это неплохой материал для начинающих руководителей проекта!
Потом подключился коллега Андрей Макаров, руководитель проектного офиса одной из лучших ИТ-компаний по разработке ИТ-продуктов для федеральных компаний. Уж он-то практик из практиков. И как давай давать советы и писать главы – загляденье!
Собственно, так и родилась эта книга с практическими советами от бывалых практиков для начинающих практиков. Заумной теории тут мало, зато много понятных ответов на непонятные вопросы.
Скрытых персонажей в книге 2 – собирательный образ Практика проектного управления и Студентка. Практик уже сделал в своей жизни не один десяток проектов и даже воспитал нескольких руководителей проекта. А Студентке надо сделать первый в своей жизни серьезный проект в роли руководителя проекта, у нее море вопросов. В этой книге она ставит вопросы и получает ответы.
Опытный читатель скажет: «Хитренькие какие, книга вон какая большая! А вдруг прочитаю и мне не понравится?» – и будет совершенно прав. Чтобы такого не случилось, мы сделали отдельную главу в самом конце, которая расскажет тебе сразу всю книгу – самое главное из того главного, что есть в книге. Можно прочитать только эту главу, а книгу-то и не читать. А можно прочитать и пользоваться главой как чек-листом и напоминалкой.
В общем, тут все для твоего удобства, дорогой читатель, а вернее, дорогая читательница – понятные наименования глав, простой язык, и нет заумной теории. Чистая выверенная практика.
Поехали! (с) Гагарин
Что главное в проекте? \ Проект и результат
Именно так. Проект и его результат.
Можно открыть «Википедию» или любую книжку по проектному управлению, и ты везде найдешь собственное красивое и глубокое определение того, что такое проект.
Мы не будем давать своих определений, а попробуем заглянуть в суть.
– Проект – это то, что должно заканчиваться конкретным уникальным результатом.
– Этот результат должен быть получен в определенные сроки. Т. е. время на реализацию ограничено.
– Скорее всего, есть ограниченный ресурс не только времени, но и всего остального – людей, инструментов, станков и т. д.
Проект не может просто случиться сам по себе и выдать результат. А уж тем более «правильный» результат. Значит, его надо «сделать» и этим «сделать» надо управлять – делать то, что надо, как надо и когда надо. Т. е. управлять с учетом ограниченных ресурсов.
Вот, собственно, от этого и будем с тобой плясать.
Тебе надо сделать так, чтобы вы с командой с помощью доступных инструментов и ресурсов за ограниченное время смогли получить определенный уникальный результат.
Шагнем чуть дальше и зададимся вопросом: а кому нужен результат?
И тут появляется он, один из главных действующих лиц проекта – Заказчик. Это может быть как человек внутри команды, так и извне.
Вот это и держи в голове, чтобы не упустить основные зоны влияния на проект:
– ты;
– люди;
– инструменты (сервера, рабочие окружения и т. д.);
– любые другие ресурсы (от бумаги в принтере и чата для общения с командой до знаний сторонних экспертов);
– время (доступное тебе для получения промежуточных и конечного результата);
– результат;
– заказчик, которого этот результат должен удовлетворить.
Теперь давай вернемся к заголовку, а именно «Проект и результат». Это то, чем должен заканчиваться любой успешный проект, – фиксацией результата.
Именно осознание и ожидание результата будет основной движущей силой в проекте. Двигать и побуждать будем людей. А значит, каждый участник проекта должен получить свой кусочек результата или рассматривать общий полученный результат как общий, которым он тоже может пользоваться.
Давай рассмотрим реальный студенческий кейс.
Группе студентов 1—2 курсов необходимо сделать учебный проект. В качестве проекта была выбрана автоматизация одного из подразделений университета.
Разложим сначала контекст:
– Заказчик. Глава подразделения университета, процессы которого хочется автоматизировать.
– Команда. Студенты в количестве 4—6 человек с разной специализацией.
– Руководитель проекта. Ты.
– Проект. Создание информационной системы, а значит, для начала достаточно домашних или университетских компьютеров с минимальными требованиями.
– Время. Полгода календарных = один учебный год (с учетом старта проекта и его защиты).
– Результат:
– Умными словами: информационная система, которая автоматизирует бизнес-процессы для сотрудников подразделения.
– По сути: внутренняя веб-система или кусочек внутреннего портала, который поддерживает основные сценарии работы конкретного отдела. Все в одном месте, все красиво и удобно.
Вроде все понятно. Так ведь?
На самом деле не до конца. Чтобы хорошо описать результат, надо для начала ответить на несколько простых вопросов «зачем». К примеру, таких:
– Зачем это заказчику? (Ответ: чтобы работалось удобнее, быстрее и все было в одном месте. Ок.)
– Зачем это команде? (Ответ: чтобы:
– сдать проект и получить оценку;
– научиться работать в команде;
– научиться новым технологиям;
– в идеале получить деньги за проект или грант на развитие.)
Звучит неплохо! Все?
И снова нет. Надо посмотреть на контекст еще шире и добавить:
– Зачем это университету?
– Вам повезло – вы автоматизируете кусочек внутренней «кухни». Университету как организации это нужно.
– Улучшение работы отдела университета, за счет этого улучшится репутация университета.
– Получить социальный эффект.
– Зачем это преподавателю?
– «Прогнать» вашу группу через проект и оценить результативность и возможность совместно работать.
Итого:
Вы станете востребованными и дорогостоящими кандидатами на рынке труда. Будете много зарабатывать.
А значит, конкретно ваш университет сможет привлекать лучших абитуриентов и преподавателей, улучшать программы, брать больше денег за обучение и развиваться еще быстрее и качественнее конкурентов.
Вот теперь результат выглядит полнее:
На выходе получаем информационную систему, которая:
1. автоматизирует основные сценарии конкретного подразделения университета;
2. работает по государственным стандартам (мы же помним, что университет – это государственная структура?);
3. система построена на востребованных рынком технологиях;
4. в ИС заложена возможность развития и масштабирования;
5. обеспечена эффективной мотивированной командой разработки и поддержки;
6. готова стать ядром еще более масштабной команды или взяться за другой проект.
А каждый представитель проектной команды:
7. защитил проект и получил отличные оценки;
8. изучил востребованные на рынке труда умения и технологии, а значит, наработал строчки в резюме;
9. возможно, стал чуть богаче.
Университет может про это написать кейс, снять ролик, включить в отчеты для чиновников, привлечь спецов проектной команды на день открытых дверей для того, чтобы они поделились с абитуриентами успехом. И многое другое в части маркетинга.
Осознав контекст результата, можно продумать риски и заранее их проработать и/или задать себе и ответственным лицам соответствующие вопросы. Например, такие:
– Какие требования к информационным системам выдвигает университет (по технологиям, размещению и защите персональных данных, владению интеллектуальной собственностью и т. д.)?
– В каких юридических условиях вы находитесь как команда? Оформляли ли вы проект официально? Если да, то как?
– Что будет являться успешным проектом с точки зрения команды?
– Как решить конфликт «технологии университета vs технологии, востребованные рынком», если таковой возникнет?
Задав эти вопросы на старте, ты сможешь прояснить важные моменты и принять решения на ранних стадиях проекта или вообще ДО его старта. Может оказаться, что видение контекста результата у команды, заказчика и университета настолько разное, что успех маловероятен.
Конечно, такое редко случается. Обычно все договариваются, просто корректируют образ результата. Но выравнивание контекста на старте приводит к правильным ожиданиям всех участников проекта. Вот ты уже имеешь опыт управления ожиданиями, а это одна из функций менеджера.
