Владимир Завертайлов - Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

Здесь есть возможность читать онлайн «Владимир Завертайлов - Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий» — ознакомительный отрывок электронной книги совершенно бесплатно, а после прочтения отрывка купить полную версию. В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Москва, Год выпуска: 2022, ISBN: 2022, Жанр: management, management, management, management, Программы, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

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

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

Максимально полный путеводитель по профессии российского project-менеджера. В нем Владимир Завертайлов, основатель и руководитель scrum-студии «Сибирикс», которая входит в Топ-10 лучших веб-студий страны, рассказывает, как управлять собственным digital-производством и грамотно руководить проектом, заказывая digital-услуги на стороне. А еще – как расти в этой профессии, опираясь на знания о продуктовых техниках и понимая потребности бизнеса.
Из книги вы узнаете:
[ul]чем kanban отличается от scrum и при чем тут agile;
как управлять неуправляемым – дизайнерами;
что лучше: собственная команда или аутсорс и как быть с техподдержкой;
откуда берутся оценки времени и как понять, что исполнитель их завышает;
что такое декомпозиция, зачем она нужна на проекте;
как планировать экономику проекта, рассчитывать операционные затраты и анализировать P&L продукта.[/ul]

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

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

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

Но вот команда взрослеет, Scrum уже отлажен, все привыкли друг к другу и процессу, есть внутрикомандный scrum-мастер. В этом случае роль менеджера действительно уменьшается. И во что он трансформируется – вопрос на вырост. Может, в скрам-мастера. А может, в продуктового менеджера, или аналитика, или помощника Product Owner.

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

Можно ли совмещать в себе несколько ролей сразу? Быть и скрам-мастером и Product Owner? Технически – да, я такое видел в молодых командах. Но это антагонистические роли. В них специально зашит конфликт. Product Owner хочет больше и быстрее от команды, и менять все в любой момент. Scrum Master хочет, чтобы команда спокойно работала, и процесс не ломался. Сможете вы такое в своей голове удержать (быть и добрым, и злым), или начнет шизофрения развиваться? Хорошего-то мало. Я бы начал выращивать scrum-мастера внутри команды. Благо – это несложно, дня за три можно справиться.

3.11. Аналитика, дизайн, разработка – параллельно

Обычно нужно несколько спринтов, чтобы получился MVP (minimum viable product) – минимальный жизнеспособный продукт. MVP должен быть клевенький.

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

При параллельной разработке нагрузка на менеджмент и коммуникации растет чуть - фото 77

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

3.12. Документация

Agile-манифест (которому сто лет в обед) – набор правильных лозунгов, которые как-то надо адаптировать к практике:

Люди и взаимодействиеважнее процессов и инструментов.

Работающий продуктважнее исчерпывающей документации.

Сотрудничество с заказчикомважнее согласования условий контракта.

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

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

Agile-манифест разработки программного обеспечения. 2001 год.

В зрелом продукте документация нужна, Agile это не отрицает. В небольших web-проектах и приложениях – можно и без нее. Степень замороченности прямо пропорциональна объему проекта, педантизму заказчика и ресурсам. Правда, документация всегда немного отстает от реальности, и это окей.

Работая над SingularityApp , например, я беру какую-то крупную хотелку из бэклога и расписываю, как бы я хотел, чтобы она работала с точки зрения пользователя. Это просто схемки интерфейсов на iPad, скриншоты похожих реализаций и немного текста. Если нужно докрутить формальности – отдаю аналитикам (с проверкой, чтобы не исказили идею). Там уже могут появляться прототипы, описание граничных случаев, интеграционные протоколы и так далее, если мне нужна такая степень проработки и формализма. Такие штуки удобно хранить в Confluence или википедии проекта . Подойдет и Google Docs.

Уже эти постановки дербанятся на технические тикеты (sprint backlog), и по ним рисуются интерфейсы. Confluence позволяет отправлять задачи в бэклог прямо из текста документов (правда, довольно коряво, но все же). Мелкие хотелки из бэклога можно так детально не разжевывать.

Кодерская и техническая документация, в основном, лежит либо в самом коде (the code speaks), либо в вики проекта.

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

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

Документацию важно увязать с тест-планами, чтобы QA не плодил свои постановки и хотелки.

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

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

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

Представляем Вашему вниманию похожие книги на «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий»

Обсуждение, отзывы о книге «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x