Беседы об управлении проектами. Полная версия.

После получения результатов опроса «Какая методология используется в вашем проекте?», стало понятно, что опять ничего не понятно. Что такое «Agile собственного приготовления»? Почему треть команд работают «как получится» и «через %опу», и ситуация не меняется? Это только у нас вот так  или на Западе тоже?
Чтобы разобраться в истории, мы решили поговорить с нашими хорошо знакомыми  экспертами по управлению проектами Иваном Селиховкиным и Михаилом Рыжиковым..
Иван, Миша, привет! Как оцениваете результаты опроса 2017?
[М.Р.] Всем привет! Несерьезный опрос подтверждает серьезные тренды =) Радует, что более 50% используют гибкие и бережливые подходы в работе, и этот показатель имеет в целом положительную динамику. Настораживает, что 8% используют Waterfall. Расстраивает, что более 30% до сих пор работают «через %опу» или «как получится».
[И.С.] А я считаю, что то, что лидируют «как получится» и «…собственного приготовления» — это хорошо, правильно и разумно.
Многие менеджеры в России слишком серьезно относятся к «чистоте методологий». Внимательны и строги, как  к себе, так и окружающим. Многие считают, что работа по PMI — это когда у вас почти весь PMBoK используется. Или RUP — это когда все прям по книжке.
Большинство стандартов очень легко относятся к выборочному использованию. Кроме, кстати, SCRUM-guide, где в описании фреймворка прямо “русским по белому” на странице 21 сказано «Роли, артефакты, правила и события Скрама не подлежат  изменению. При внедрении отдельных элементов данного фреймворка, полученный  результат не может называться Скрамом» (ну, то есть «ничего менять нельзя, не меняйте ничего»). Как-то в нем это сочетается со сказанным в манифесте «Люди и взаимодействие важнее процессов и инструментов».
В методологиях есть основа, некая мысль, или, как сказал бы Миша Рыжиков “мякотка”. То, в чем основная идея, без чего работать не будет. Ну, например, в Kanban это визуализация процесса, уменьшение Work in progress, выявления бутылочных горлышек для ускорения Time to market. И вот можно еще пару тезисов добавить, и это будет основное. Все, что служит этой цели — соответствует «духу канбан» и именно это тебе, менеджеру, и поможет. Какие роли, какие инструменты — все вторично, «мякотка» — она главное.
В PMI «мякотка» — это условно-неизменный устав проекта и гибкие планы (обычно, иерархические), которые можно очень сильно менять, уточнять. И охапка инструментов, которые тебе, менеджеру даны, чтобы «впихнуть невпихуемое», чтобы у тебя расписание не перерастало те сроки, которые заказчику обещал, чтобы «содержание проекта» не расползалось бесконечно, но и пользователи и заказчик не чувствовали себя обманутыми. Используй что нравится, но главный принцип, он вот такой.
Даже знаменитая методология «через %опу» — это не мрак, тлен и уныние. Иногда, это пример слишком серьезного отношения к «чистоте методологий».

Мне случалось видеть (преимущественно, в гос.секторе) глубоко демотивированные команды, безнадежно пофигистичное отношение ко всем, невыполнимые планы, которые нельзя менять и от которых нельзя отказаться. Короче, я видел, что такое на самом деле «через %опу». И я не верю, что это массово.
А приспосабливать методологии под себя можно и нужно. В этом смысле «SCRUM собственного приготовления» — очень правильный вариант. Сама формулировка говорит «люди переживают, что у них SCRUM какой-то не такой», но это же правильно! Фреймворки, стандарты, методологии — не святые коровы. Их нужно допиливать. Главное, чтобы «мякотка» не страдала, и чтобы работало так, как вам нужно. 🙂
Знаете ли вы серьезные исследования проектного управления, и подтверждают ли они картину этого несерьезного опроса?
[М.Р.] Не готов ответить за проектное управление в целом, но касательно гибких и бережливых подходов к разработке ПО рекомендую взглянуть на два бесплатных международных ежегодных отчета: 11-th State of Agile Report 2016 и State of DevOps Report 2017. Это позволит лучше понять тренды в применении гибких и бережливых подходов по всему миру. Для затравки, приведу пару результатов этих исследований, ну а глубже уже сами почитаете по ссылке:
Распределение по использованию различных Agile-фреймворков, подходов на 2016 год.

Показатели по частоте установок, скорости поставки (time-to-market) и скорости реакции на инциденты.
[И.С.] По опросам видно, что в России Agile популярнее других подходов. И это правда. Другая правда, кстати, в том, что Agile — слишком широкий термин, по сути, система ценностей). Как мне быть, например, если считаю, что «люди и их взаимодействие важнее процессов и инструментов», но при этом использую Prince 2? Я вот как бы что-то практикую, и есть ли в этом противоречие? 🙂
Насколько я знаю, никто в мире не может корректно сравнить востребованность SCRUM, PMI, MSF и прочих — не удается сформулировать критерии. Менеджмент вообще сильно закрыт от научных исследований (перекрыт всевозможными соглашениями о неразглашении (NDA) и прочими «коммерческими тайнами»). PMI, к примеру, проводит подробные и достоверные исследования на предмет того, кто проектами управляет, сколько в какой стране за это платят (Россия, Украина и Беларусь не учитываются), и от чего это зависит (например — Project Management Salary Survey, пример от 2015 года здесь: https://www.pmi.org/learning/careers/project-management-salary-survey). Но там опять же нет данных о сопоставлении подходов.
Если говорить о субъективных впечатлениях (кто и что использует) — как-то развлекался, изучая статистику поисковых запросов google.
Сравнивал за периоды 2004-2017 популярность по регионам двух запросов: PMI (именно тот PMI, который относится к управлению проектами, а не к индексу промышленного производства) и SCRUM.
Картинка была примерно такой: PMI [Институт управления проектами] (красный) vs. SCRUM (синий):

Мой друг Уехал в Австралию (навсегда). Он бизнес-аналитик. Помню, как спустя первые полгода мы плотно общались — говорил «все пропало, туту аналитики не нужны, у всех SCRUM» (и слово «SCRUM» произносил таким страшным голосом). В итоге, переквалифицировался в юзабилистов и счастлив (я до конца так и не понял, почему с его слов в австралийском SCRUM юзабилисты нужнее аналитиков) 🙂
При этом (вот теперь личный опыт), последние годы много общаюсь с западными (а не австралийскими) менеджерами. Возможно, это специфика моей тусовки, хотя она очень ИТ-шная, крайне разношерстная, и, думаю, вполне репрезентативная. Когда я говорю о SCRUM, коллеги из США и Европы меня не всегда понимают. Все знают слово Agile (он, скорее, как система ценностей — с ней все согласны, грубо говоря что-то вроде «за бумажками важно не потерять человека»). И далеко не все ИТ-менеджеры с ходу понимают, что такое SCRUM.
PMI понимают очень многие, но не все готовы обсуждать его детально (т.е. слово знают, но не каждый в нем ориентируется).
Так что похоже, да, за рубежом также популярно свое «как получится»  и «методологии собственного приготовления». И, как уже говорил, если в процессе приготовления удалось сохранить здравый смысл, не выплюнув «мякотку» — то это отлично, это вообще самый лучший подход какой может быть!
По вашим ощущениям, что изменилось в индустрии за последние два года?
[М.Р.] На крупных отраслевых конференция и в профессиональных сообществах уже все меньше и меньше обсуждаются практики, подходы и инструменты на «уровне команд», а все больше и больше обсуждаются подходы к масштабированию Agile на уровне крупных компаний с большим количеством команд разработки и мощным стыком с не IT-шным бизнесом. Сейчас набирают популярность такие фреймворки и подходы, как: Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), The Nexus Guide и прочие.
Можно с уверенностью сказать, что теперь Agile уверенно пытается проникнуть в российский Enterprise, т.е. крупные компании и государство всерьез задумались о необходимости меняться, менять подход к организации работы, дабы не проиграть в конкурентной борьбе небольшим и агрессивным компаниям. На данный момент волна, так называемой, «Agile-трансформации» захлестнула: банковский сектор, телеком, IT в медицине и гос.секторе. Все начинают создавать/наращивать/обновлять свои IT-лаборатории и бегают «с фонарями» по рынку труда, ищут просветленных Agile-коучей и Scrum-мастеров. =)
Еще одно из изменений, Agile ценности и принципы, а также практические наработки: фреймворки, подходы, инструменты, «вызревшие» в IT-индустрии, начинают адаптироваться и в других областях: бухгалтерия, маркетинг и т.д. Также появился новый тренд Business Agility. Буквально недавно меня пригласили рассказать об Agile и Lean на Петербургском Медицинском Форуме, целевая аудитория которого  —  руководители и врачи коммерческих клиник. Скажу честно  —  это был интересный опыт.
[И.С.] В мире за два года ничего драматически не поменялось. Там «стабильность» лет десять уже. Есть проектные подходы (PMI Prince 2, IPMA и другие). Есть продуктовые (SCRUM, например). И те, и другие, по большому счету были придуманы лет 50 назад (например, родоначальник термина «Водопад», Winston W. Royce в статье «Managing the Development of Large Software Systems» (1970) некоторые принципы Agile предвосхитил, например, итеративную разработку).
Время от времени кто-нибудь перепаковывает термины, и это не надолго становится «сенсацией». Возникают какие-то гибриды.
Отвлекаясь от проектного управления, в регулярном менеджменте то же. Вот, например, была книжка по спиральной динамике (но она трудно читалась). А потом Фредерик Лалу написал «Открывая организации будущего» — и она стала хитом. Люди отправились серьезно обсуждать, когда у руля встанут бирюзовые организации (без иерархии) и можно ли всерьез сделать это в нашей компании и как. Вот в последние 2 года это и до России докатилось, пообсуждали немного (Герман Греф не преминул поговорить). При том, что этой теме тоже больше полувека. Обожаю Генри Минцберга (рекомендую его «Структуру в кулаке» — «Structure In Five»), он очень здорово анализировал, каким компаниям подходит какая иерархия, и почему одни хороши в механистических структурах, а другие — в адхократиях, и как одно в другое превращается.
Говоря о России, продолжается то ли кризис, то ли стагнация. Это косвенно сказывается на проектном управлении.
Денег стало мало. Бизнес отреагировал. Фактически, менеджеру проектов, который хочет рулить чем-то сложным и интересным (я сужу в первую очередь по ИТ сфере, но не только по ней) приходится становиться перед выбором: либо компании работающие на западных заказчиков, либо государственные или очень близкие им структуры. Раньше было очень много вариантов «посередине». Какие-нибудь компании 100 — 150 человек, работающие на российский рынок и эпизодически на зарубежный. А сейчас довольно жесткое расслоение.
Менеджмент в этих крайних вариантах и раньше сильно отличался. Компании, работающие на западных заказчиков — они разные, но, например, в ИТ огромную долю (сильно больше 50%) занимают аутсорсеры. Компании, которые иногда еще называют полушутливо «Bodyshop». Они продают руки и головы инженеров + свои компетенции + некоторые гарантии качества западным заказчикам. В таких компаниях на первом месте всегда «Accounting» (работа с заказчиком). Это не пресловутое agile-овское “работа с конечным пользователем”, нет, это обхаживание того, кто платит. «Самого-главного-на-стороне-заказчика».
Управление там часто трансформируется так: на первом месте сейлз [с нашей стороны] и «топы-со-стороны-заказчика» с их стороны. Всевозможный софт-скилз, создание доверия. А на втором-третьем местах уже хороший продукт, результат, командная работа. В таких компаниях одинаково хорошо себя чувствуют и PMI (и другие классические), и Agile (и другие гибкие) подходы. Но они одинаково не на первом месте, но все же очень важен результат. Важно, чтобы то, что создается, заработало (жили как-то до проекта, а вот после проекта должно обязательно возникнуть что-то новое, за что мы платим).
Компании, «гос.» (органы власти, ФУПы, ГУПы, компании с гос. капиталом и работающие на гос.сектор) — там на первом месте GR (Government Relationship). Как человек чуть меньше половины карьеры, проведший именно в афилированных с государством компаниях (я занимался медицинским ИТ, а на заре своего становления — почти все масштабное медицинское ИТ было государственным) — хорошо знаю, как там появляются и заключаются контракты, как принимаются работы. Очень важна лояльность, субординация. Переработки «вне контракта» так же горячо приветствуются (и являются частью «лояльности»).

Главный приоритет в гос. — всегда не «сделать новое», а «не сделать ошибку». Если ты упустил возможность — не страшно. Страшно, если ты рискнул и потерпел неудачу, и доказано, что это твоя вина. Все это накладывает отпечаток на характер проектов.
В госе они очень бюрократизированы, это вот то самое место, где «документы важнее реально работающего продукта» (и в большинстве случаев вы не переубедите ни одного чиновника, т.к. его карьера от бумаги зависит, а от работающего продукта — нет). Бывают нюансы, но сейчас не о том.
И вот, в последние 5 лет перед отечественным менеджером встал серьезный выбор. Стало ясно, что отечественному менеджеру (ну, по крайней мере, в ИТ) приходится выбирать, в чем прокачиваться. То ли в работе с западными заказчиками — тогда нужно учить язык, учить методологии, которые в ходу за рубежом, прокачивать софт-скилл и вообще привыкать к культурным различиям (общение русских между собой совсем не похоже на общение в Штатах или Великобритании-Германии-Франции). То ли погружаться в гос.сектор (тут уже пишутся килотонны новых российских стандартов управления, многие из которых основаны на западных же стандартах, но тюнингованных), глубоко изучать отраслевые законы, вообще разбираться в отрасли. Особенно важно разбираться в начальниках и их привычках — это важно: кто откуда пришел, чего хочет, нужно привыкать к запрещенному слову на «О» и так далее. Этих менеджеров очень легко различить. Достаточно пол-минуты поговорить с человеком — угадаешь, из какой он «вселенной».
Раньше выбор не стоял так остро. Можно было отработать в госе, потом сдвинуться немного «в серединку» и поработать в коммерции на российский рынок, потом сдвинуться еще и поработать на западных заказчиков. Я именно так и делал. Сейчас ситуация иная. Если ты проработал 5-7 лет в гос.секторе, перейти на конкурентный рынок сложнее (можно, но трудно) и с большой вероятностью — и по деньгам, и по предложениям работодателей рынок будет удерживать тебя там, где ты начал.
Так что менеджерам проектов приходится сейчас больше думать наперед чем мне двенадцать лет назад, когда я только начинал. 🙂
В заверешении — в двух словах про PMI. Для меня это самая крупная и самая авторитетная международная структура в управлении проектами. Они занимаются всем что связано с project management и около него (управление портфелями, программами и т.п.). Так вот, PMI взял курс на демонтаж многих направлений, которые посчитал, видимо, «не совсем внятными» или «не совсем здоровыми». Например, он перестал аккредитовывать собственных консультантов (стал сворачивать консалтинг под знаменем PMI), прекратил разработку руководств по проектным офисам и по оценке зрелости компаний. Вместо этого заявил что-то в духе «нужно идти к руководителю проектов, а не к его боссу» и «мы слишком долго смотрели не в ту сторону, руководители проектов — это основа нашей организации, мы работаем для них». И вот это очень адекватно.
По моему опыту, менеджер проекта в компании часто оказывается без поддержки. То есть приходит новый сотрудник и ему говорят — вот у нас положение об управлении проектами (читай), вот ИТ-системы (осваивай), и давай, рули. А как рулить? Проектное управление это много-много заботы о клиентах и пользователях результата, это срабатывающие риски, это умение строить планы там, где команда не может внятно сформулировать, что нужно сделать и сколько это займет времени и т.п. И вот тут и только тут рядовому менеджеру и нужна поддержка. Своя компания не всегда (а в России — практически никогда) не может ему помочь, поддержать, пояснить. PMI и другие — пытаются.
При этом понятно за что на рынке платят деньги — за консалтинг, за анализ, за «оценку зрелости», за написание тех самых «положений о проектных управлениях», согласно которым менеджер должен использовать определенные шаблоны, писать определенные отчеты и вообще вбивать все расписания в софт. А как ему повседневно «делать» сложные вещи и принимать сложные решение — за это не платят.
В итоге на рынке надулся такой здоровенный консалтинговый пузырь. На мировом рынке, но в России в последние два года его очень видно, особенно с подачи первых лиц, которые стали использовать термины «проектное управление» для обоснования кадровых перестановок. В итоге PMI- и Agle- консультанты бросились в гос.сектор, на уровне компаний. Стали их улучшать, развивать, консультировать.
В это время PMI просто сказал — ребята, на зацикливайтесь на проектных офисах. Мы о них больше писать не будем. Думайте о менеджерах, о портфелях. А мы больше поддерживать и продвигать консультантов не хотим. Это не то, что важно. В России этого никто не заметил, а на PMI leadership meetings — это постоянно обсуждается.
Ну вот это еще один тренд. Я думаю он очень знаковый.
Влияют ли на индустрию инициативы политиков и бизнесменов? В России президент объявил о том, что везде должны быть проектные офисы. Герман Греф везде рассказывает про пользу Agile.
[М.Р.] Да, влияют и достаточно сильно. Все их цитируют, следят за ними. Благодаря этому интерес к теме явно возрос и вышел за границы IT.
[И.С.] Интересный вопрос! Разделю его. «Влияют ли инициативы политиков на управление проектами?» История говорит: да. Крупные течения в проектном управлении были связаны с некоммерческими организациями, которые поддерживал «крупняк».
«Крупняк» — это либо гос. сектор (посмотрите как появился Prince2 — он встал на ноги, когда правительство Велкобритании сделало методологию обязательной для работы в сфере многих «гос. заказов»).
Либо это «военные / космос» — PMI встал на ноги благодаря NASA. А на одной из встреч PMI Global, основатель института пошутил с президентом Петербургского чаптера — спасибо, говорит, вам (СССР) за холодную войну, это подстегнуло развитие космических и военных программ США, а они подстегнули проектное управление в целом и PMI в частности. Как они там дальше перешучивались я рассказывать не стану, но факт — на проектное управление «госы» влияют.
Третий вариант это, например, RUP и MSF (методологии от IBM и Microsoft соответственно). Они уже к госам прямого отношения не имеют (хотя и те и другие исторически имеют крупные государственные контракты), но свое слово сказали.
Причина очень проста — когда-то потребовалось «придумать» проектное управление. Для этого нужно было привлечь лучшие мозги. Т.е. вот просто взять самых умных, самых опытных людей, отвлечь их от работы (частично или полностью), оплатить их труд, упустить потенциальную выгоду и получить на выходе методологию / стандарт, который, возможно окупится в будущем. Такое могли позволить себе только крупные игроки.
В итоге, проектное управление было придумано. Кто бы ни работал над стандартами (европейцы — IPMA, Prince2, американцы — PMI, MSF, RUP, японцы — P2M и другие) — все они создали очень похожие стандарты. Глубоко зная один, легко воспринимаешь любые другие. И последние лет 10-15 ничего существенно не меняется, новые подходы не изобретаются. Даже «современные» гибкие подходы были описаны давным давно, в том числе автором термина Waterfall (имею в виду статью Winston W. Royce «Managing the Development of Large Software Systems» (1970)). С тех пор происходит просто «перепаковка смыслов». То в одну обертку завернут, то в другую. То так главы разделят, то тут акценты расставят. Но люди знакомые со стандартами видят — десятилетия ничего не изобретается. Не нужно больше ничего изобретать. Все есть. Давайте уже осваивать.
И вот тут вторая половина вопроса: «Влияет ли в России инициатива политиков на проектное управление?». Здесь мне нужно высказаться очень аккуратно. Хорошо знаю людей, которые разрабатывают российские стандарты (ГОСТы), продвигают проджект менеджмент сейчас. Это хорошие специалисты и профессионалы. Они хорошие.
Здорово ли то, что они делают? Не всегда.
Во-первых, часто исходят из ложного посыла, что в России нужно «разработать свой подход к проектному управлению». По-моему это ошибка. История убедительно показывает — кто бы ни писал «национальный стандарт», получается один и тот же автомат Калашникова IPMA-PMI-Prince2-etc. Время изобретения стандартов прошло. Все что нужно было сказать — сказано, жизнь не меняется так сильно, чтобы потребовалось что-то писать с нуля. Огромное количество сил (нужных на проворот шестеренок бюрократической машины) тратится создание большого количества «нормативов».
Россия — не уникальная с точки зрения менеджмента страна (не настолько уникальная, чтобы не походить на одну из других 206 стран, где по данным 2016 года активно применяются PMI-стандарты или любые другие).
Мне довелось работать в компании, где один из топ-менеджеров был уверен в невероятной уникальности русских менеджеров и сотрудников, приводил в пример труд «Русская модель управления» Александра Прохорова и мечтал написать собственный стандарт на ее основе.
То что я сейчас наблюдаю в гос. секторе — здорово напоминает съезд «любителей писать свои стандарты». Смысл в этом примерно такой же, как разрабатывать специальную российскую читалку для школьных учебников (кто помнит — была такая инициатива), вместо того чтобы взять за основу имеющееся импортное «железо» и сфокусироваться на создании того, чего еще нет (самих учебников, адаптированных под планшет, на развитие навыков учителей для работы с ними и т.п.).
Т.е. в России поведение политиков влияет на проектное управление, но влияние это странное. Русские политики пытаются повторить то, что уже есть, только хуже (свой стандарт, свой экзамен, своя сертификация, свои требования к квалификации). Я не буду эту мысль дальше развивать (думаю, ясно почему это направление выглядит для идеологов привлекательнее). Вопросы повышения эффективности работы гос. сектора — немного в другой плоскости.
Про Германа Грефа. Герман Греф везде активно рассказывает про много что. Сейчас «один странный вещь скажу». Герман Греф мне напоминает… Илона Маска. Стойте, не стреляйте в меня! Дослушайте! 🙂
В том смысле, что он оседлал тот же тренд «продай людям мечту и они пойдут за тобой». Вот Маск «продает» инвесторам идеи, которые увлекали каждого мальчишку (полеты на Луну, электромобили, поезда в безвоздушной трубе и т.п.). Мне иногда кажется, что он прям повторяет все что было описано и нарисовано в одной моей детской книжке (я прям зачитывался и «замечтывался», представляя как взрослым буду летать на выходные на Марс). При этом Маск пока не создал ничего, что реально бы изменило мир (но продал идею, что рано или поздно изменит). Можно долго и религиозно спорить о реальных результатах (но факт в том, что его машины дороги, полеты редки и эксклюзивны, поезд по трубе пока не ездит и даже солнечные батареи все никак не перекроят экономику). А Маск, собрав деньги на одних ожиданях, тут же аноснирует следующую, еще более яркую идею. Он успешен, потому что ярок. Людям нужна надежда. Им никто ее не дает. И тут Маск, сознательно имитирующий «Iron Man» из фильма («миллиардер, гений, меценат» (c)). Других нет, и сразу хочется его слушать, ему верить. Как результат — экономически неэффективная  компания Тесла обогнала по капитализации проверенный поколениями Форд-моторс.
Греф не Маск. Но смысл тот же. Вот у нас куча скучных (и иногда безграмотных) политиков, банкиров. И тут Греф. Который с видом откровения, немного в режиме «капитан очевидность» начинает критиковать неэффективность той системы, которую сам отчасти строил. Его выступления устроены примерно так «я был в Кремниевой долине — я видел, как там работают по SCRUM / как функционирует Netflix / как изнутри устроен Amazon — мы отстали на 100 лет — нужно бежать вперед».
Как слышат это люди? «Греф нас поведет, он единственный кто видит неэффективность системы, он продвинутый, прогрессивный, он — надежда».
Если кто помнит, Герман Оскарович перебрал очень много тезисов про управление и остановился на самом эмоциональном. Вначале он говорил про проектное управление (все плохо, нужно применять проектное управление). Реакция была слабой. Затем заговорил про Agile — и сразу отклик. Потом пошел дальше и начал рассказывать про бирюзовые организации (про компании без иерархии). Снова слабо. И Герман Оскарович вернулся туда, где эмоциональная отдача сильнее. Это Agile и это понятно (не буду развивать, Agile очень медийная история, в нем очень много шоу — сравните поведение любого Agile-куча и любого PMI-IPMA-Prince2 тренера). Начинающим управленцам трудно вдохновиться проектным управлением, опытные же в речах Грефа по определению не слышат ничего нового. А Agile — у него такой имидж. Скажи Agile и сразу выглядишь молодым и продвинутым.  В этом смысле Греф напоминает мне Маска по-русски.
Что изменится в проектном управлении от того, что он его и Agile подход будет часто упоминать? А что, поезд Маска когда-нибудь домчит людей от побережья до побережья? Tesla за почти 15 лет существования подешевела до уровня автомобиля с бензиновым двигателем?
Думаю, ни Греф, ни Маск (специально ставлю рядом несравнимое) — мир не меняют. И даже свои компании они меняют гораздо в меньшей степени чем кажется. Но они символизируют надежду. Они вдохновляют.
Сбербанк (на мой взгляд) невозможно изменить. Но прямо сейчас кто-то слушает Грефа и думает, черт, я пожалуй тоже сделаю… И сделает. Кто-то изменит мир, Греф и Маск соберут денег и продвинут собственные карьеру и бизнес. В конечном счете проектное управление не останется «в накладе» и получит стимул, но не так как кажется, из речей Грефа.
Проекты, в которых вы участвовали (консультировали) — какое там распределение по методологиям?
[М.Р.] На протяжении последних двух лет я работаю в крупной IT-компании, в которой уже три года продолжается Agile-трансформация. Поначалу я пришел туда в роли Agile/Lean консультанта, а теперь уже год как тружусь руководителем лаборатории разработки.
В компании до сих пор еще кое где остались привычки «каскадной (waterfall)» модели разработки, но три-четыре года назад это был основной процесс разработки, вот несколько «зарисовок» из прошлого…
Сильный синдром «системный аналитик всему голова». В этой компании я познакомился с word’о-кодом, это когда очень трудолюбивые системные аналитики, месяцами пишут детальные спецификации в word’е, ласково называя их «постановки». Тщательно выбирают названия для таблиц и колонок в базе данных, подробно описывают текстом алгоритмы работы системы. В общем, делают все, чтобы «кодерам» (а иначе разработчиков в этой среде не назвать) оставалось только перенести этот word’о-код в исполняемый код на Java или процедуры PL/SQL. К сожалению эти системные-аналитики, теряясь в море технических деталей, забывают узнать у заказчика, а зачем все это нужно? Кто и как будет этим пользоваться? Как устроены бизнес-процессы прямых потребителей? Какие у них сейчас проблемы? И какие бизнес-цели хочется добиться автоматизацией…
Также часто встречался синдром «губительной task-ориентированности». Это когда у команды есть лидер, который считает своим долгом пропускать через себя все работы, собственноручно продумывать/проектировать для них решения, разбивать на маленькие технические задачи и «размазывать» эти задачи по своим узкоспециализированным однокомандникам, тщательно им разжевывая «как, что и где надо сделать». Ну и конечно же, при любых возникающих сложностях, однокомандники сразу бегут к их лидеру за решением. А лидер, упиваясь своей значимостью и востребованностью, выдает готовые решения направо и налево.
И вечерами тихо страдает от того, что мол его окружают безинициативные специалисты, не вовлеченные, плохо знающие свой продукт и не способные принять даже самые простые решения самостоятельно.
Еще мой любимый паттерн «команда узкоспециализированных бойцов». Представьте в команде семь человек и каждый из них занимается своим собственным «огородиком ». Например: один Java-разработчик занимается одним компонентом, другой Oracle-разработчик на PL/SQL другим, один C++ разработчик, который «пилит» свою часть, два тестировщика (один отвечает за тестирование правой части системы, а другой за тестирование левой). Ну и конечно же в команде есть системный аналитик «всему голова» и тимлид, обязанности которого пропускать через себя все работы, мелко нарезать и распределять технические задачи по своей любимой команде и следить чтобы «никто не ПРОСТАИВАЛ»! И каждый из них »вскапывает свой огородик» и ему глубоко безразличны огородики однокомандников…
В результате, даже самая плевая сквозная бизнес-задача обретают такую комплексность, что достаточно быстро наступает хаос…
Типовые «болезни», развивающиеся в результате подобной организации труда:

• никто в команде не представляет себе систему в целом, у каждого из них есть знания только под узким углом зрения;
• системы захлебываются от сложности, принятые ранее бизнес- и инженерные решения не пересматриваются, а наворачиваются как «снежный ком» друг на друга;
• в основном, в командах преобладают сотрудники с «потухшими глазами», не проявляющие инициативу, просто выполняют поставленные перед ними задачи и вовремя уходят домой;
• реальных пользователей никто и никогда из команды даже в глаза не видел (часто и системные-аналитики тоже =), все работают по «постановкам» и «прилетающим извне» задачам, им это никогда и не требовалось, в задачах же описано что надо сделать;
• за production часто отвечают специально-обученные люди, а команды разработки перекидывают свои разработанные «инкременты» им через «забор», для того чтобы они их развернули и поддерживали в production;
• вокруг царит атмосфера авралов, надвигающихся дедлайнов и сыпется нескончаемый шквал ошибок.

Ух как разошелся я в черных красках… 🙂 Может ли быть по-другому? Да, до этого энтерпрайз-ада я на протяжении шести лет участвовал в совершенно другой разработке. Когда небольшие кроссфункциональные, автономные команды full-stack специалистов, регулярно общаются с пользователями и узнавая их контекст, процессы, проблемы находят интересные и неожиданные решения. Быстро прототипируют их, получают качественную обратную связь. Всей командой проектируют систему часто рисуя архитектуру решений на доске, взвешивая плюсы и минусы и принимая лучшие из имеющихся решений, реализуют и поставляют готовую функциональность в production по несколько раз в неделю. В общем, идут от понимания бизнеса/потребителя, экспериментируют, рефакторят, обсуждают решения, одним словом создают продукты которыми гордятся, при создании которых развиваются и получают от этого удовольствие!
[И.С.] Распределение проектов по методологиям? Видимо, я скажу это много раз. Я не адепт, шовинист, не поборник чистоты подхода. Выше об этом говорил — так не бывает.
С точки зрения биологии (я врач по базовому образованию, и только потом уже программист и менеджер) — самые здоровое потомство у «непохожих» родителей. И наоборот. Близкородственные браки вредны.
Если в компании все проекты натягивать на одну очень жесткую методологию, некоторые из них вырастут болезненными и слабыми, как породистые котята. Как ни странно, главные сторонники единообразного подхода — обычно, топ-менеджеры.
Управлять проектами не их работа. Им не хочется разбираться в разнообразии, оно напрягает, создает ощущения бардака. Именно они часто формулируют запрос «разработайте нам методологию, подберите ИТ-инструмент, мы всех на них натянем».
В реальной работе должен быть кто-то, кто умеет выбрать. Смотрит на команду, на заказчика, на сложность продукта, на сроки и решает «давайте тут так рулить», «а тут этак».
Менеджеру проектов, чтобы научиться выбирать методологию, нужен большой опыт (причем опыт работы в разной среде — с разными людьми, нужно своими глазами увидеть где какие подходы буксуют, чтобы научится выбрать). Поэтому я обычно сразу закладываю возможность использования разных подходов.
Нахожу внутри компании человека или людей, которые в состоянии такой выбор делать. Обычно они находятся где-то выше обычных менеджеров (руководители программ или портфелей, если есть проектный офис — то вот в нем им самое место, по-хорошему это как раз «гнездо» для таких экспертов и менторов). И вместе с реальными менеджерами и тим-лидерами прорабатываю правила «как мы делаем проекты, если он в PMI-стиле, как если в Kanban- или SCRUM-стиле». И это никогда не «чистые методологии». Всегда гибрид.
Не породистые британские котята, а боевые, агрессивные, дворовые коты 🙂
Как команда воспринимала переход на новые рельсы? Кто был в оппозиции? Как вы преодолевали оппозицию?
[М.Р.] Разные есть кейсы. Все очень зависит от того, чувствует/видит ли команда проблемы и хочет ли меняться/улучшаться или нет…
Если видит, но не знает как, то тут начать эволюцию достаточно несложно, нужно не бояться экспериментировать и внедрить первые улучшения, например проделав следующее упражнение:

1. Собраться единомышленниками из команды, желающими изменить ситуацию в работе у белой доски с маркерами;
2. Провести «молчаливый брейншторминг», т.е. каждый в течении трех минут молча выписывает на стикеры ответ на вопрос «что мешает нашей команде быть High-Performance Team»?
3. Дальше, эти стикеры зачитываются, выклеиваются на доску, кластеризуются и в результате получаем единый список «помех».
4. Дальше приоритезируем список, задавая вопрос по каждому элементу списка: «чем мы за это платим?» (стараемся выразить ответ в каких либо единицах, например: 5 дней на регресс/стабилизацию, т.е. из нашего 2-х недельного спринта остается только 5 дней на разработку…). Важно чтобы в итоге наверху списка были самые крупные «помехи», а внизу самые мелкие.
5. После этого, прогоняем эту помеху по шаблону A3 — Problem Solving Report. С этой техникой можно познакомиться тут.
6. Внедрить, посмотреть на результат и продолжить улучшаться дальше!

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

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

Ну а если команда не видит проблем и считает что «у них все хорошо», а все их прямые потребители наоборот, дают о них только отрицательную обратную связь. То тут в ход идут сила убеждения через факты, а также продается идеальный процесс и на нем показываются «ништяки». Также очень важно организовать прямой поток этой обратной связи прямо в команду.
Например, в одной команде очень помогло, отправить членов команды в «эпицентр», прямо к их прямым потребителям (в командировку), понаблюдать за их работой в системе. Как раз была выпущена новая версия и надо было помочь с ее внедрением и обучением. Некоторые из членов команды аж «прозрели» от услышанного и увиденного. 🙂
Еще был другой кейс, для еще одной команды были введены ограничения «сверху», а именно, ввели регулярную демонстрацию промежуточных результатов. Каждые две недели команда должна была демонстрировать представителю заказчика и всем приглашенным свой реальный прогресс (т.е. реализованные кейсы прямо в продукте). Тут тоже начались интересные процессы осознания.
[И.С.] Команда — это сложившаяся система. Она всегда сопротивляется изменениям (никто не любит менять привычки). При этом в любой команде есть проблемы.
Есть «законы природы», которые эти проблемы порождают. Ну вот на уровне здравого смысла: заказчик и директор всегда хочет знать, когда проект закончится и сколько будет стоить. Это естественное желание любого человека. Каждый из нас, тратя время и деньги, хотел бы знать, сколько всего потребуется.
В любом проекте предсказывать сроки и стоимость трудно (иначе это не называлось бы проектом, но это отдельный разговор, не буду сейчас уходить в сторону). Заказчик и директор приходят с таким запросом к менеджеру, требуют ответа (и при этом ожидают, что все будет сделано хорошо). Менеджер — к команде. А та откуда возьмет ответы?
Вот тут возникают разные варианты. Вариант «через %опу» предполагает, что каждый по-своему как-то отморозился и вопрос снялся или решился сам собой. Вариант «как получится» означает, что были высказаны экспертные оценки разной степени безобразности. Методологии, стандарты, фреймворки означают, что менеджер в них заглянул и попробовал с их помощью найти ответ. Даже SCRUM «делает это» (в своем стиле).
Так вот, внедрение проектного управления (конкретной методологии) — оно всегда не ради красоты, а ради решения самых насущных проблем.
Обычно действую так. Пытаюсь понять какие проблемы самые большие (90% так или иначе связаны планированием сроков, денег, решением сложных инженерных задач, недостатком людей и их квалификации, проблемами с коммуникацией с заказчиком).
Затем я прихожу к команде (как менеджер) и говорю, например: «Ребята, как будем сроки планировать? Мне по вашим задачам нужно понимание чего и когда ждать.» Ребята эту проблему решать не хотят и пытаются применить ко мне «через %опу» или «как получится». С «через %опу » я не соглашаюсь, а «как получится» — принимаю. Потом оценки не рализуются (промахиваемся).
Я повторяю процесс несколько раз. И мы несколько раз промахиваемся мимо оценок. Потом я снова прихожу и задаю уже другой вопрос: «Ребята, как мы добьемся того, чтобы перестать так грубо ошибаться с оценками?».
«Чего?» — говорят ребята, — «Да у нас работа такая. И вообще это не наша проблема. Мы тебе скажем, как мы думаем, а жу ты менеджер — сам выкручивайся».
Говорю: «Нет, ребята, вы не поняли. Либо мы все вместе конструктивно с вашей помощью обсудим как добьемся повышения качества оценок, либо я сам придумаю методологию которая мне удобна и вы все будете по ней жить».
И дальше, если команде есть что сказать (она зрелая, у инженеров реальный опыт) мы обсуждаем и отбираем инструменты, которые будут удобнее и полезнее всего конкретным людям (я всегда приветствую гибриды и готов к любой адекватной методологии, подходу — не важно на что он будет похож: SCRUM, PMI, Kanban). Либо идей у команды нет (могут даже с облегчением сказать «вот-вот подумай, удиви нас») — и тогда идеи всегда есть у меня. Тут еще одно важно. Чтобы лучше планировать сроки, нужно проработать очень много чего (тщательнее собирать требования, обнаруживать заинтересованных лиц, корректно перепроверять свои гипотезы о сроках и вообще адекватно анализировать предыдущие попытки планировать, вести базу знаний и т.п.).
С неудовлетворенностью клиента, с проблемами на стороне заказчика как быть? Методологически. То есть, либо предложите мне свое решение (поддержу все простое и рабочее), либо пошли по пути методологий и вообще чужого опыта (моего, в том числе).
Команда может быть недовольна методологией или инструментом, но спорить с таким подходом невозможно. Проблема есть? Как решим — варианты есть? Даже если у вас нет, то у меня есть, погнали!
Это одна из составляющих менеджерской работы. Тут важный момент, конечно, отвественность. Сделаем так, и если будем регулярно придерживаться вот таких практик (я прослежу), то должен быть вот такой эффект (если я прав), под мою ответственность.
Т.е. ориентированность на решение реальных управленческих проблем и личная отвественность — так любые методологии внедряются. И, кстати, совсем не так большинсво консультантов работает, оттого их не люблю (шутка).
Если ты работаешь членом команды (не менеджером проекта), можешь ли ты вообще повлиять на методологию проекта? Есть ли секреты внедрения изменений “снизу”?
[М.Р.] Безусловно, повлиять можешь. Все начинается с индивидуальной эффективности, вовлеченности, установки на качество, любознательности и смелости.
Это ваша «внутренняя кухня», и она должна быть в порядке, прежде чем начать наводить порядок «во вне ее»!
Например, часто слышу, что: «нам менеджеры не выделяют времени на написание автотестов, при написании кода»… А почему вы вообще решили, что для этого нужно отдельно выделенное время??? Что его надо просить у менеджеров??? Это ваш инструмент проектирования и защиты от будущих ошибок, так встройте эту работу в процесс работы над задачей, превратите это в привычку, наподобии «мытья рук перед едой».
[И.С.] Пооему опыту, снизу внедрять сложно. Команда — сложившаяся система, она (с точки зрения законов физики) находится в равновесии. Менять — значит выводить из равновесия. А это, по тем же законам физики, требует энергии.
Вариантов два: либо официальная власть (т.е. ты руководитель команды или иное влиятельное лицо), либо ты обладаешь неисчерпаемой энергией.
В качестве примера — история.
Я работал в коммерческой компании, занимавшейся ИТ и консалтингом. Компания быстро выросла и переживала «детские болезни роста» (методологий не было, кадровая политика невнятная, сотрудники по уровню опыта, подходам и мотивации были очень разные, менеджмент складывался очень стихийно).
У меня уже был опыт проектного управления и очень раздражало, что у нас все как-то не так, вернее, вообще никак. Каждый отдел живет по-своему, департамент — это зоопарк, а компания, в целом, производит впечатление большого шумного ребенка, который хватается за разные игрушки, а потом устает, громко плачет, и все друг другом недовольны. Хотелось что-то менять, но полномочий не было. Более того, все топы, крупные управленцы смотрели друг на друга немного нервно, каждый боялся что другой «потянет одеяло», начнет подминать остальных под свое руководство. Даже поднимать вопрос о методология было сложно (его поднимали пару раз, даже собрали какой-то «комитет», где у каждого было свое мнение и не кончилось ничем).
Я работал над портфелем консалтинговых проектов (во многих из них ИТ-составляющей не было или она была не велика). На тот момент я был простым руководителем проектов (а руководителя портфеля не было, так получилось что все эти проекты вел я).
В таких проектах основой артефакт в результате работы — документ. Вернее много документов. Их генерируют в огромном количестве консультанты. Важны и скорость и качество, т.к. Документы стоили заказчику очень дорого. Основной специалист — это консультант (бизнес-аналитик).
Повезло — в компанию пришли несколько очень сильных аналитиков из питерского интегратора. Крутые ребята, со сложившимися и отточенными подходами к работе. Удалось заполучить их на свои проекты, мы быстро нашли общий язык. Они тоже быстро осмотрелись в компании и прищурившись в пол-голоса стали задавать вопросы («а почему такой бардак?», «почему все так стихийно»).
Я тут же заявил: «ребята, давайте сделаем правильно». У меня к тому момент почти не было опыта работы в консалтинге, а у них — в проектном управлении. Короче, мы нашли друг друга. Сделали из моих проектов «полигон». Я сказал — предлагайте любые практики, я их поддержку. Если провалимся — ответственность на мне. Но хочется попробовать делать тут проекты разумно.
За пару недель составили план действий. Не буду расписывать все. Мы не могли менять сложившиеся правила игры и сфокусировались на том, что в нашей власти. Уровнем ниже.
Мы ввели стандарты «как писать документы». Ввели кучу практик, которые мне вообще не приходили в голову (взаимная вычитка документов, кучу контр-интуитивных практик работы с шаблонами). Мы не могли выбить себе co-location (своместное расположение) и вместо этого завели сайт (попросили разрешения у руководства, за вечер сами оплатили хостинг, накатили форум phpbb3, структурировали его и ввели правило — все документы по проекту выкладывать там; получились одновременно и виртуальный co-location, и база знаний, и в некотором примитивном смысле даже получилась система отслеживания хода проекта). Финальным аккордом — оформили все наши (уже запущенные) работающие практики отдельным документом. Своего рода «правила» для менеджеров проектов и членов команд. Получился ненавязчивый, не бюрократичный, очень позитивный документ. И все, продолжили работать.
Очень быстро произошло несколько вещей. Во-первых о наших документах поползла слава по всей компании. На консалтинговые проекты все захотели использовать именно моих аналитиков (я торговался как черт, вернее как наркоторговец — давал аналитика на пресейл или на какую-нибудь встречу с заказчиком, чтобы у другого менеджера произошло «привыкание», а потом упирался и отказывался надолго отпускать с проекта — менеджер страдал, ругался, но выхода у него не было (сам аналитик был на моей стороне). Наши отчеты об обследованиях и концепции признавались лучшими в компании.
Более того, быстро обнаружилось, что их удобно использовать для внутренних целей (шаблоны, «рыбы» и примеры документов расползлись по компании и безо всяких усилий с нашей стороны стали стандартом де-факто). Их использовали все, включая генерального директора.
К нам стали ходить экскурсии. Доступ к нашему сайту «co-location» попросили 60% сотрудников других отделов (мы пускали их туда, куда можно, где не было приватной проектной информации).
Как-то само-собой устоялось что «вот у нас там — у нас да, работа на проектах поставлена». Нам не пришлось для этого ничего ломать, никого просить, мы шли с самого низа, со структурирования рабочего процесса, и степень нашей свободы постепенно ширилась. Нам доверяли все больше. Как-то само собой получилось, что корпоративные правила мы можем не соблюдать или соблюдать частично, если сумеем внятно аргументировать.
А через полгода, по-моему, снова возник вопрос «а не структурировать ли нам нормально проектное управление во всей компании». Не обошлось и без «давайте проектный офис построим». И вот тут уже в число реформаторов вошли мы с коллегами-аналитиками и еще три директора, включая генерального.
Там уже были и консалтинговые проекты, и ИТ-шные. И наше мнение было ведущим (нам как-то все отдали пальму первенства и перестали переживать на счет «перетягивания одеяла»). Всем хотелось нормальной проектной работы. Большинство ждало, что наши проектные документы можно будет взять за основу (может как-то чутка переделать). Так и вышло. Переделать пришлось не чутка и степень ответственности была совсем другая, но мы реально перестроили управление в компании, не имея изначально к тому никаких предпосылок.
Вот именно ту нашу исходную ситуацию большинство коллег (я знаю) назвали бы безнадежной. Было такое классическое «тут никому ничего не надо», «лучше не высовываться», «все через %опу» и «я уже пробовал менять». А стало — карт-бланш на изменения.
На самом деле, почти в любой компании есть степень свободы, с которой можно начинать. Одни компании (гос. сектор, крупные корпоративные структуры) — более ригидны, другие (средний бизнес) — менее. Но степень свободы есть всегда. Вопрос только в том, сколько энергии и мотивации есть у вас, и готовы ли вы действовать под свою ответственность (в том числе перерабатывать, засиживаться допоздна и в выходные), чтобы все поменять. И сразу многое становится возможным.
И еще очень важно. Хоть в чем-то быть очень хорошим специалистом. Я был средним менеджером (но довольно отважным), а коллеги — очень-хорошими аналитиками. Это была достаточная смесь (да, у нас еще было дофига энергии).
Компания должна чувствовать что вы в чем-то ну просто супер-хороши. Тогда будет вас слушать. Желающих посоветовать просто хоть что-то поменять везде полно. Никого просто так слушать не будут. Докажите. Проявитесь. Завоюйте и настаивайте.
Почему доля проектов, которые управляются способом “Как получится” и “Через %опу” не меняется со временем — ваше мнение?
[М.Р.] Потому что не так много вокруг настоящих лидеров, смелых людей, готовых на эксперименты и стремящихся «помимо того, чтобы просто делать свою работу, еще и непрерывно улучшать ее».
[И.С.] Повторюсь, считаю что «как получится» и «через %опу» — это собирательное название людей, которые либо «забили управлять», либо слишком серьезно относятся к чистоте методологий. Либо никак не могут придумать, откуда набрать энергию для изменения сложившейся системы (смотри выше). И тех и других и третьих довольно много, потому и доля таких проектов растет.
Проекты меняются, заказчики приходят и уходят, у всех свои требования. Что нужно знать хорошему менеджеру проекта, чтобы быть готовым к новому проекту?
[М.Р.] Лучше бы менеджеру проекта иметь свою сильную, сработавшуюся, кроссфункциональную команду единомышленников, которая будет накапливать экспертизу в той области, где они работают.
[И.С.] Отдельные инструменты управления проектами могут показаться сложными. Но все же проектное управление — не rocket science.
Основа любого бизнеса — «эффективность» и «»конкурентоспособность». Заказчик хочет этого. Ваш босс хочет, чтобы производимые вами услуги и продукты были такими.
Какой бы методологии вы не придерживались, какие бы инструменты и техники не применяли — проверяйте, возрастают ли в конечном счете эффективность вашей работы и конкурентоспособность того, что в итоге предлагается рынку.  Научитесь это понимать. Не всегда понятно, помогла ли очередная пробковая доска, бэклог или диаграмма Ганта делать лучшие продукты или нет. Это знание само по себе на голову не сваливается — его нужно научиться добывать. Мерить свою работу, сравнивать эффект до и после. Это самое главное.
Тот, кто оценивает эффективность инструментов и подходов — рано или поздно выявит самые полезные практики и научится подбирать их под ситуацию. А значит, станет очень хорошим менеджером.
Именно это самое главное для руководителя. А не изучать методологии (или как можно больше методологий). Умение оценивать техники и практический опыт. Таких менеджеров очень мало, в этом «клубе»” постоянно требуются готовые члены.
Не являясь поклонником конкретных методологий, со временем свел это в своей голове к термину «менеджмент здравого смысла» (по английски можно было бы сказать «reasonable management»).
Держите в голове «здравый смысл» (звучит коряво, но именно это и пытаюсь сказать) — это основной вклад в будущий успех.
Что можете порекомендовать тем, кто сейчас видит, что его проект управляется и делается не так, как надо?
[М.Р.] Начать менять ситуацию. Выявить парочку небольших проблем и решить их, вовлекая в решение сокомандников. А потом вообще поставить этот процесс ушучшений на поток. Благо, сейчас можно сформировать вижн «идеального процесса», прочтя множество книг и поняв куда вы хотите прийти. А также получить внушительную долю мотивации пообщавшись в сообществах с людьми решавшими подобные проблемы, поучаствовав на конференциях.
[И.С.] Вообще, если вы знаете «как надо» — значит, вы очень крутой специалист.
Не просто «нам нужно вести backlog», а как именно его вести, если у вас команда разнородная, задачи быстро меняются, аналитики и разработчики идут в разном ритме, а завершить проект нужно в определенный срок. Просто заявления типа «так не делается, давайте всех разгоним, заказчика научим и устроем нормальный SCRUM или SCRUM-ban» никому не интересны. Интересно, умеете ли вы работать с тем, что есть, в реальных ограничениях.
Как говорится «все любят писать стратегии». Все любят начинать с чистого листа. Вспомните программирование: что вы любите больше — начинать программу с нуля, мечтать о рефакторинге, чтобы переделать все нормально и без костылей, или копаться в чужом коде, которые пять лет писали другие люди, и который ни в коем случае нельзя поломать, т.к. на непрерывной работе приложения держится чей-то бизнес? А какие разработчики больше в цене на рынке, под какие задачи больше спрос?
Менеджмент ничем не отличается: у собственника свои ограничения, проблемы, интересы, отделы, команды, департаменты связаны с сложный узел, и далеко не всем интересно разбираться в «лучших практиках проектного управления». Вы должны уметь делать это за них.
Вот именно это я называю «знать как надо». И таких менеджеров — крутыми.
Становитесь крутыми и проблем у вас не будет. Рынок труда будет гоняться за вами в любой кризис.  Будете нарасхват, независимо от экономической ситуации.
Коллеги, будьте крутыми — отличное пожелание! Иван, Миша, спасибо за разговор! Всегда будем рады видеть вас в нашем блоге, и точно придем через год, чтобы узнать, изменилась ли ситуация с проектами!