#4. Философии, Методологии и Фреймворки управления проектами
Один из первых парадоксов, с которым сталкивается начинающий проект менеджер – это попытка понять разницу между тем, что такое философия и что такое методология управления проектами.
Путаница возникает из-за того, что в свое время множество разных авторов написали сотни книг в которых каждый излагал свое мнение насчет того, что считается философией а что методологией. Если начинающий проект менеджер вдобавок к книгам прочтет пару статей по этой теме в Интернете – он запутается окончательно. В этот момент, наиболее вероятно, у него потеряется интерес к этому вопросу, он выберет «что-то одно» и закроет тему, так и до конца не разобравшись.
Вопрос терминологии становится еще забавнее, когда в офисах компаний, конференциях или на форумах эти же проект менеджеры начинают яро обсуждать что чем считать, всеми правдами и неправдами отстаивая то, почему «AAA» является философией, а «BBB» методологией.
Вопрос терминологии становится еще забавнее, когда в офисах компаний, конференциях или на форумах эти же проект менеджеры начинают яро обсуждать что чем считать, всеми правдами и неправдами отстаивая то, почему «AAA» является философией, а «BBB» методологией.
Эта статья для тех, кто хочет окончательно понять эти термины, и их различия. Сперва поймем, где находятся «философии» и «методологии» по отношению друг к другу, чтобы нам было проще ориентироваться.
Наука (Science)
Наука, это особый вид познавательной деятельности, направленный на выработку объективных, системно организованных и обоснованных знаний о мире. Говоря проще, если в мире появляется широкий интерес к некоему своду идей, которые не попадают под описание другими науками – этот свод может стать наукой. Новые науки появляются постепенно, по мере развития человечества.
Пример «свежей» науки: «Сеттлеретика» - наука, изучающая возможность «переноса» информации из нашего мозга на какой-то внешний носитель (например, нейрокомпьютер), с целью обеспечения «бессмертия» человека.
Менеджмент – это наука изучающая управление интеллектуальными и материальными ресурсами.
Философия (Philosophy)
Если наука – основана на фактах и аксиомах, то философия, являющаяся производной науки, имеет под собой идеологический, более абстрактный стержень. Философия подразумевает систему убеждений, которые приводят к изменению нашего отношения к чему-либо. Философия, в целом показывает, чем мы по-умолчанию руководствуемся принимая решения в кооперации с внешним миром.
Если вы верите в то, что люди предпочитающие кроссовки, классической обуви, более разговорчивы и им можно доверять – это один из элементов вашей философии, так как он в какой-то мере определяет ваше отношение к людям.
Философия в управлении проектами – это свод идеологических принципов, которые отвечают на вопрос «Что мы хотим учитывать при управлении проектом». Для каждого отдельно взятого проекта мы можем очертить свою философию, которая будет соотвествовать нашим целям, и целям проекта.
Методология (Methodology)
Если философия показывает нам, что мы хотим учитывать в управлении проектами, то методология дает нам набор принципов и практик, руководствуясь которыми мы получаем ответ на вопрос «Как управлять проектом». Методология может иметь множество разных принципов и практик, которые можно использовать частями, в зависимости от специфики решаемых задач.
Фреймворк (Framework)
Фреймворк – это по сути готовая, самодостаточная структура с заранее обозначенными правилами и практиками, придерживание которых по задумке должно привести к определенным результатам.
Фреймворк в контексте управления проектами, это проверенная, работающая схема действий, которая в чистом виде не подразумевает добавление других практик. Однако, мы можем "одолжить" нужные нам принципы и практики из уже существующих фреймворков, добавить пару своих правил, использовать все это на некоем проекте, и сказать что мы придумали фреймворк :-).
Философии, Методологии и Фремйворки в IT-проектах.
Наиболее подходящим, под описание философии в IT-проектах безусловно можно назвать крайне популярный в наше время Agile.
Философия Agile основывается на 4-х пунктах манифеста, согласованного и написанного 17 независимыми IT-экспертами в 2001м году (Далее copy-paste):
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
- “То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева."
Как видим, здесь нет ни слова о том, как управлять проектами и какие практики использовать, однако здесь совершенно четко обозначено что в первую очередь учитывать при управлении проектами.
И тем не менее, Agile все кому не лень гораздо чаще называют методологией, нежели философией, а причина в том, что создатели манифеста, на той же встрече в 2001м, помимо 4 ценностей, вывели также 12 принципов Agile (copy-paste):
Мы следуем таким принципам:
- Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Здесь мы можем углядеть больше конкретики, которая, для внимательного менеджера может стать ответом на вопрос «как управлять», тем самым, позволяя утверждать что Agile это методология.
Вот почему возникает путаница. Мы можем использовать ценности Agile манифеста, и принципы совершенно другой методологии, и в этом не будет ничего страшного, пока наши решения идут на благо проекта. Либо наоборот, мы можем использовать принципы Agile вместе с ценностями которые исповедует наша компания, что будет означать, что мы используем корпоративные ценности как нашу философию (вопрос «что учитывать») и принципы и инструменты Agile (вопрос «как управлять») как нашу методологию.
Таким образом, ценности которыми ты руководствуешься (вопрос «что учитывать») – суть, твоя философия. В свою очередь принципы, которые указывают на то как управлять проектом – это твоя методология.
Надеюсь мы более менее уловили разницу между философией и методологией.
Примеры наиболее популярных методологий для общего ознакомления (Можете пройти по картинкам быстро, исключительно для улучшения понимания общей картины. Детали писать не буду, при желании можете легко загуглить любой из непонятных терминов.):
Примеры наиболее популярных методологий для общего ознакомления (Можете пройти по картинкам быстро, исключительно для улучшения понимания общей картины. Детали писать не буду, при желании можете легко загуглить любой из непонятных терминов.):
Lean (Бережливое производство / Бережливая разработка, часто используется и интерпретируется как философия):
FDD (Feature Driven Development):
XP (eXtreme Programming):
Lean Startup:
И парочка сильно устаревших методологий (выкладываю сюда, так как сам когда-то давно потратил много времени собирая и фильтруя информацию по ним):
DSDM/Atern:
DSDM/Atern:
AgileUP (Agile Unified Process):
У вас может возникнуть вопрос "зачем читать об устаревших методологиях?"
Отвечаю.
Все методологии создавались группами очень умных и грамотных специалистов, за общение с каждым из которых я бы не пожалел ни времени ни денег. Если в какой-то момент своей деятельности они пришли к решению вывести ряд правил для оптимизации процессов их времени – значит этого достаточно, чтобы внимательно отнестись к материалу. Вреда никакого, а потенциальная польза пропорциональна нашим навыкам использования информации (читай - креативности).
Отвечаю.
Все методологии создавались группами очень умных и грамотных специалистов, за общение с каждым из которых я бы не пожалел ни времени ни денег. Если в какой-то момент своей деятельности они пришли к решению вывести ряд правил для оптимизации процессов их времени – значит этого достаточно, чтобы внимательно отнестись к материалу. Вреда никакого, а потенциальная польза пропорциональна нашим навыкам использования информации (читай - креативности).
Итак, полагаю уже понятно, что мы можем использовать как ценности методологий, сделав их нашей философией, так и практики, бесконечно варируя их так, как нам нужно.
Теперь мы бегло пройдемся по парочке наиболее популярных фреймворков и завершим статью лирическим отступлением.
Фреймворки
Как я уже сказал, фреймворк является самодостаточной системой с заранее выверенными инструкциями, придерживание которых, по задумке, должно привести к конкретным результатам. Фреймворки, в отличие от философий и методологий используются всеми. Причина их популярности в том, что ты можешь ничего не знать об управлении проектами, не понимать практически ничего что написано в этой статье и даже не слышать о философиях и методологиях, но при этом ты можешь просто взять фреймворк, собрать команду, нанять начинающего менеджера и сказать ему «Мы будем использовать «название фреймворка» и ждать успеха.
Фреймворки просто говорят тебе что, где, когда и как сделать, а в некоторых случаях еще и чего опасаться, на что обращать особое внимание и другое.
На первый взгляд может показаться, что фреймворка в таком случае достаточно для ведения бизнеса, но...да, так и есть.☺
Если отточить навыки использования фреймворка, этого достаточно чтобы иметь небольшую фирму которая будет заниматься аутсорсом и приносить некоторую прибыль, работая в основном на небольших проектах.
У читателя может появиться вопрос «Зачем тогда философии и методологии? Бери фреймворк, заучи его и покоряй мир!». Причин несколько:
- Проект менеджер никогда не сможет выйти за рамки небольших проектов не понимая того, что написано в этой статье. Работа только с одним фреймворком и одной системой затормозит его профессиональное, и, возможно, карьерное развитие;
- Высокое качество управленческих процессов недостижимо, если менеджер не понимает фундаментальных составляющих современной управленческой деятельности, а также управленческой истории, которая к этому развитию привела. В конце концов, менеджмент - это наука;
- Мир покоряют не фреймворки а идеологии, целиком основывающиеся на философии. В мировой истории 19 и 20го века есть много примеров.
Пример высокого качества: высокоорганизованная, самодостаточная команда не имеющая никаких конфликтов друг с другом, которая ставит ценность для заказчика и приоритеты заказчика выше собственных желаний и амбиций.
Если подобной синхронности и взаимопонимания еще можно достичь в узком кругу друзей в группе из 3-4 человек, то по мере увеличения размера проектов и, соответственно, команды, отсутствие идеологической составляющей (философии) и согласованных подходов к работе (методологии) приведет к постоянным конфликтам, нестыковкам и непониманию решений топ-менеджмента.
Даже если мы будем пытаться придумать что-то «на лету», это будет отнимать колоссальное кол-во времени и нервов, которые, быть может, мы бы могли потратить гораздо лучше, если бы с самого начала четко обозначили принципы и приоритеты.
Если нам не интересно качество, но мы хотим чтобы у нас была фирма, работники, куча мелких проектов и глубокомысленное выражение лица сидя в собственном кабинете – фреймворк нам достаточен. Более того, компаний, весь фундамент которых опирается только на фреймворки – больше половины (да да!) от общего числа компаний-аутсорсеров занимающихся разработкой ПО в мире.
Собственно, сами фреймворки:
Канбан (Kanban)
Канбан очень популярен среди современных компаний, и насчет него ведутся клановые войны, адептов которых дико возмущает, когда Канбан называют фреймворком, или методологией, потому-что в чистом виде, по своей первоначальной задумке, Канбан не является ни тем ни другим. Канбан нельзя считать фреймворком, потому-что для фреймворка он слишком неполноценен и абстрактен, однако методологией его также не назовешь, потому что в нем есть ряд четких правил,инструментов и инструкций, которые свойственны фреймворкам.
Первоначально Канбан был разработан как система планирования и управления потоком производства промышленных компаний в Японии во второй половине 20го века. Тогда его называли методом. В определенных кругах, дабы избежать спора, его так же называют и сейчас (шах и мат, война окончена).
В IT компаниях от канбан используют его ключевой инструмент – доску.
В классическом виде канбан-доска представляет из себя три колонки. Первая колонка называется “To Do” и в нее помещаются задачи, которые нужно сделать. Вторая колонка – “In progress” (или In Process, Doing и так далее) – в нее перетаскиваются задачи из колонки “To Do”, чтобы визуально было понятно какие из задач находятся в процессе. Последняя колонка называется ”Done” и в нее попадают задачи из "In Progress", после того как они были выполнены.
В классическом виде участники команды тянут задачи из листов по принципу FIFO (First In – First Out) – таким образом, задачи, находящиеся в самом верху листа “To Do” выполняются раньше, и этот лист часто используется заодно для приоритизации задач.
Пример на ворованной картинке:
Мои старые заметки с дополнительной информацией по Канбану:
Скрам (SCRUM)
Наиболее распространенный фреймворк (по состоянию на 2018й год его использовало 56% IT-компаний, с тенденцией на рост) О нем мы будем много говорить в отдельных статьях, поэтому деталей здесь писать не буду.
Гибрид - СКРАМБАН (SCRUMBAN)
Как несложно догадаться, это гибрид Скрама и Канбана. В основном от Канбан используется доска и принцип FIFO.
Гибрид - SCRUM/XP
Гибрид Скрама и XP. Из XP в основном используют TDD (Test-Driven Development), Code Refactoring, Continuous Assembly.
Если вам стала интересна популярность фремйворков и методологий, можете взглянуть на публичный отчет компании VersionOne.
Итог
Мы поговорили с вами о философиях и методологиях управления проектами и поняли их разницу. Мы поняли где находятся философии, методологии и фреймворки по отношению друг к другу и в чем смысл каждого из них.
Мы рассмотрели самые популярные элементы каждой категории и вообще нам стало очень хорошо. Мы молодцы.
Мы рассмотрели самые популярные элементы каждой категории и вообще нам стало очень хорошо. Мы молодцы.
В следующей статье мы узнаем какие циклы разработки ПО существуют, а также сфокусируемся на общих вещах для Agile команд, постепенно углубляясь в рабочий процесс.