[1/3] The Art of Project Management (Искусство управления IT-проектами) (Рубрика Management)

Это одна из первых книг по управлению проектами, которую я прочитал еще в начале своей карьеры. Книгу написал Скотт Беркун в 2005 году, а в 2007 году она была переведена на русский язык издательством Питер. В это время я заканчивал университет и у нас был отдельный предмет "Управление проектами", который нам рассказывали ребята из СОВНЕТ (это российская часть международной ассоциации IPMA). В общем, ребята были достаточно формальны и мне хотелось изучить что-то более технологичное без налета госпроектов - так я набрел на эту книгу и не пожалел. Скотт написал книгу по итогам своих 10 лет работы в Microsoft, которую он начинал с инженерной должности, а потом перешел на позицию руководителя программ. В этой должности он работал над Microsoft Office, Visual Basic и предшественниками Internet Explorer 6.0 (богомерзкой хрени из прошлого).

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

• Part 0. Preface
• Part 1. Plans
• Part 2. Skills
• Part 3. Management

Part 0. Preface 1) A brief history of project management (and why you should care) - здесь Скотт рассказывает, что управление проектами было с нами давно, но раньше его так не называли

Part 1. Plans 2) The truth about schedules Панирование и календарные сроки направлены на закрытие трех целей

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

3) How to figure out what to do На проект стоит взглянуть с трех точек зрения: бизнесмена, инженера и потребителя

• Бизнес - как мы заработаем на этом проекте (PnL)
• Инженер - как мы сможем спроектировать и реализовать запланированное
• Потребитель - что именно требуется потребителю, а точнее какой набор возможностей должен быть в нашем продукте Чтобы проект удался требуется сбалансировать эти три взгляда, а дальше зафиксировать их в виде отдельных документов - тут автор приводит достаточно тяжеловесные примеры артефактов, что были популярные тогда (market requirement document, work brakedown structure)

4) Writing the good vision Здесь Скотт рассказывает про создание хорошей концепции, которая должна быть простой, целенаправленной, вдохновляющей способной консолидировать и которую при этом можно запомнить:) Скотт считает, что у хорошей концепции только один автор. Желательно сделать краткую и емкую концепцию, а не объемную и размытую.

5) Where ideas come from Здесь автор рассказывает про разрыв между проблемами и решениями. Здесь автор говорит про креативность и вспоминает про дивергентное и конвергентное мышление. Он выдает тезисы, которыые отвечают на вопрос в названии главы

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

6) What to do with ideas once you have them Генерация идей - это круто, но главное не увлечься. Изначально новые идеи стоит группировать в похожие и проверять их на прототипах. По мере движения к заврешению проекта остается все меньше пространства для экспериментов и внесения изменений, поэтому приходящие идеи можно запоминать до следующего проектка:)

Продолжение в следующих постах

#Management #Agile #Project #Leadership #SelfDevelopment #Software #Processes