×Закрыть

Работа проджект-менеджера: как наладить идеальный рабочий процесс

У меня более 13 лет опыта в IT, восемь из них — в менеджменте. Работая в разных проектах и компаниях и в различных управленческих ролях — от Team lead до Senior PM и PM Competence Manager — накопила большой багаж практических знаний. Причем знания эти позволяют ответить на многие вопросы из серии «почему в реальных проектах часто приходится действовать в разрез с теорией».

Image source

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

Подводные камни

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

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

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

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

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

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

Чего хочет стейкхолдер?

Существуют различные подходы, позволяющие более детально разобраться в пожеланиях заказчика. Например, value proposition canvas или business model canvas. Только после того, как мы поняли, что в действительности беспокоит стейкхолдера проекта и что он может выиграть по его завершении, можно рассчитывать получить нужный ему продукт или сервис. Еще раз: если он просит у вас блокнот и ручку, получив их, возможно, останется таким же несчастным, как и до встречи с вами. Потому что вы не узнали, зачем они ему, и не предложили ему калькулятор, чтобы быстро совершить все нужные арифметические подсчеты.

Заказчики, которые просят двух программистов для работы — пример из реальной жизни. Правда, в итоге выясняется, что одному нужна команда для создания собственного сервиса, а другому — консультация по экспертизе, которой в его компании просто нет. В нашем случае, согласившись на сотрудничество в предложенном формате с самого начала, мы бы просто трудоустроили двоих разработчиков. Сейчас над этим проектом работает большая команда, при этом сам стейкхолдер счастлив — его идея получила развитие, которое необходимо заказчику. Оказались, что ему нужны не два программиста, а разработка продукта для рынка практически под ключ. Все работает благодаря переходу от парадигмы решений к изначальной парадигме проблем. Только после этого мы возвращаемся к решениям.

Продукты, сервисы, решения

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

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

«Вы меня не поняли», — стандартный ответ недовольного стейкхолдера. Неважно, что именно не сложилось, и как он сам объяснял задачу. Просто сейчас его сервис работает не так, как ему необходимо (причем понять разницу между тем, что хочет заказчик, и тем, что необходимо заказчику, — отдельная достаточно непростая задача).

Недавно на учебном модуле львовской бизнес-школы нам рассказывали, что отношение к процессам различается даже в разных городах Украины. И, например, Одесса — более продуктовый город — но в целом, когда берешь людей с рынка, лучше не рассчитывать, что каждый постарается вникнуть в реальные нужды заказчика. И если вы как проджект-менеджер уже научились дешифровывать его потребности, это еще не гарантирует положительного результата — вам предстоит поработать с командой. Ведь программисты часто уверены, что важнее технологии нет ничего, и только перейдя в роли, связанные с менеджментом, убеждаются, как часто все упирается в человеческое общение и отлаженность рабочих процессов.

Что мешает нам легко прийти к разработке solutions/services?

Для постсоветских стран один из пунктов — образовательная система. В средней школе нас продуктовому подходу никто не учит. Обычно там мы решаем абстрактные и при этом узкие задачи, не пытаясь рассчитать хотя бы площадь квартиры или расходы семьи на месяц. Никто не предлагает школьнику преобразовать полученные на уроке знания в какое-либо решение.

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

Следующим камнем преткновения становится недостаток информации. Обычно наибольшим объемом информации владеют менеджеры. Открытым остается вопрос, какую ее часть они готовы донести до остальных членов своей команды, как в целом ставятся задачи разработчикам или QA-инженерам. Если общая картина проекта не является общим достоянием — каждый будет копать свой маленький участок, не обращая внимания на соседей. Кроме того, отсутствие информации всегда дает повод сомневаться в качестве принятых решений и пользе собственной работы в целом.

Работая в больших командах, многие люди не знают о других составляющих продукта, частью которого они занимаются. Поэтому всех действительно необходимо собирать, объясняя общее направление, на забывая о классике аджайла, — груминг и планинг-сессиях. Если программисты знают, что через пару лет у нас планируется 200 тысяч пользователей против нынешних 200, архитектуру решений они будут строить по-другому. Именно так повышается качество решений на всех уровнях.

Все об этом знают, но иногда менеджеры просто забывают прийти к команде и пересказать полученную от заказчика информацию. И легко это звучит только на словах — я сама регулярно наступала на эти же грабли попросту из-за нехватки времени. Но если заказчик говорит, что ему необходимо интегрировать сервис распознавания речи, это может влиять на решения, которые принимают даже те программисты, которые работают над маленькими фичами, не имеющими к этому сервису прямого отношения. Менеджерам необходимо понимать: во время таких обсуждений многие будут сидеть с незаинтересованным видом (действительно, мы же не про код говорим ;), но информация все равно останется в голове у каждого.

Определение целей

Важную роль играет определение целей всех заинтересованных лиц. Для этого стоит найти ответы на вопросы:

  • Зачем мы это делаем?
  • Куда все движется?
  • Каковы наши ожидания?
  • Чего ожидает заказчик?

Цели у вашей организации и организации заказчика могут быть разными — для аутсорсеров это валидно. Например, вы можете хотеть заработать, а заказчик — сделать продукт подешевле. А все, кто сталкивался с заказной разработкой внутренних продуктов компании, понимают, что бюджеты на внутренние системы всегда стараются сократить. При этом в любом случае мы все заинтересованы в хорошем продукте, поэтому нужно четко понимать, как цели каждого из нас коррелируют между собой. Замечательно, когда мы зарабатываем, просто помогая заработать заказчику. Еще лучше, если он хочет развивать какие-то новые технологии, и мы развиваемся вместе с ним — это «win-win situation». Но, к сожалению, она возникает не всегда.

Существует классический вопрос ожиданий. Есть ценность, которую мы представляем для заказчика, и если смотреть на проект именно с этой точки зрения, вся картина сразу приходит в движение. То есть, если заказчик понимает, что вы можете принести ему прибыль, он более лояльно отнесется к изменениям срока выполнения проекта. Если он понимает, что это выгодно для бизнеса, могут найтись и дополнительные ресурсы. Но стейкхолдер должен четко знать, что ты не стремишься просто заработать деньги для своей команды или компании, а вместе с ним развиваешь продукт — это гарантирует другой уровень отношений. И, соответственно, делает возможным обсуждение любых технических и финансовых моментов. Никто не отменяет ограничений расходов и времени, но разговор о них ведется уже с партнерских позиций.

Что при таком подходе не работают попытки манипуляции, вы заказчика просто потеряете — учтите, он все равно это почувствует. И ему это не понравится.

Виды мотивации

Все мы помним, что в менеджменте выделяют три уровня мотивации:

  • Motivation 1.0 Базовая мотивация, полностью зависящая от биологических процессов.
  • Motivation 2.0 Мотивация за счет награды или наказания: кнут и пряник, они же морковь и палка.
  • Motivation 3.0 Вид мотивации, который активно пропагандирует Дэниел Пинк в книге «Драйв. Что на самом деле нас мотивирует». Он считает, что наказания и поощрения работали в индустриальную эру, когда объем выполненной работы напрямую зависел от потраченного времени. Сейчас, если программист просидел на работе десять часов вместо восьми, это вовсе не значит, что он сделал больше и при этом на достаточном качественном уровне. И от того, что вы наказали программиста за ошибку, работать лучше он вряд ли будет, как показывает опыт. Новая теория мотивации говорит, что человеку важны автономия, возможность повышать мастерство и цель. Обратите внимание — ни о деньгах, ни об их эквиваленте тут нет ни слова.

Продемонстрировать цель как раз и позволяет рассказ о конечном продукте, который мы создаем вместе с заказчиком, о его планах, предполагаемом выходе продукта на рынок, о том, чего ждут пользователи, и насколько счастлив отдел маркетинга клиента. С отдельными категориями продуктов в этом отношении проще — они имеют очевидные цели. Например, если мы делаем дефибриллятор, то сразу понятно, кому и зачем он нужен. Но с бизнес-приложениями часто такой ясности нет. «Я сделал три формы. Зачем? Кому от этих трех форм стало легче жить?» — нормальная реакция программиста. Но когда мы показываем, что кому-то эти формы и правда облегчат жизнь, это меняет мотивацию человека. Он начинает действовать по-другому, принимает другие решения, люди в команде понимают, что пользователь — это совершенно определенная бабушка или банковский работник, а может быть, человек, которому срочно нужно забронировать номер в отеле. Получается, что объект приложения усилий персонализируется, и никто уже не делает просто кнопки или формы.

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

На DOU проводили опрос разработчиков, который показал, насколько людям важны реализация своих идей и ощущение причастности к чему-то новому. Причем значение этих факторов выше у тех, кто работает в стартапах, чем у занятых в классическом аутсорсинге. Это легко объяснить: в продукты и стартапы просто перекочевывают люди, которым в больших аутсорсинговых компаниях неуютно — там они слишком остро чувствуют себя только маленькими винтиками малопонятного механизма.

Посмотреть в глаза

Ответственность — как много в этом слове заключено для каждого PM. И насколько туманным остается его содержание для многих команд. Споры о ней могут утихать, но почти никогда не прекращаются полностью. Как только вам кажется, что наконец-то все поняли, насколько важна их часть работы, ждите неприятностей. Избежать их помогает связь с конечным пользователем. Если в вашем случае разработчик может посмотреть в глаза человеку, которому предстоит пользоваться продуктом, часть которого он сейчас пилит, он сам начнет фиксить баги. Поверьте, никому не хочется, чтобы из-за его ошибок пострадали живые люди, которых можно себе представить в подробностях.

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

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

Экспертиза

Seniority — сложная тема, потому что ее не измерить количеством ромбиков на погонах. На мой взгляд, если человек отработал пять лет, но при этом отказывается говорить с заказчиком и командой, не может выступить в качестве ментора, срок его работы ничего не значит. Если он занимается исключительно выполнением своей узкой задачи, даже через пять лет остается на уровне мидл — обычным инженером. Отличие старшего инженера в том, что он берет на себя ответственность за других людей, может общаться с клиентом и что-то ему советовать.

В нашей стране, к сожалению, с этим есть ряд проблем. Когда мы говорим, что человек «синьорный», это часто означает только то, что у него есть определенные знания. Но seniority включает в себя еще и манеру поведения. То есть HR-часть, те самые софт скиллы.

Есть люди, которые не хотят брать на себя ответственность, прикрываясь образом жертвы: «Я бедный-несчастный, тестировщики на меня напали, а еще дизайнер приходил и все поменял — мне теперь опять нужно код переписывать». Ситуации бывают разными, но очень часто важным в такой истории оказывается вовсе не история про дизайнеров и QA, а сам посыл «я бедный-несчастный». И этот образ мыслей приходится менять — если в команде он не поощряется, люди прибегают к нему все реже. Хотя команде иногда приходится нелегко, поскольку при таком подходе нужно не просто здорово писать код, но и принимать решения в рамках всего продукта.

Мне приходилось заниматься такой трансформацией на уровне команды. Сейчас это происходит более точечно: я смотрю, какие люди ко мне приходят, и исходя из прошлого опыта, понимаю, с кем предстоит поработать персонально. Но в целом, если есть core-команда — бизнес-аналитики и техлиды, которые берут на себя работу с продуктом — остальные идут за ними гораздо легче.

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

Перегибы и перекосы

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

Другая ошибка — перекос в сторону собственной компании. Это позиция, при которой нас заботит только то, что написано в спецификации. Если вы подумали, что заказчик сам виноват в том, что недостаточно внимательно ее прочитал, — что-то идет не так.

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

Баланс, как всегда, искать сложно. Но искать его необходимо.

Потеря фокуса

Кто приносит прибыль вам и вашему заказчику: каждый отдельный человек или команда? Иногда мы увлекаемся тем, что работаем с каждым человеком индивидуально, позволяя команде выпадать из фокуса менеджера. Нормально, что когда мы перестраиваемся на команду, иногда приходится делать очень непопулярные изменения (менять людей в команде, вводить непопулярные процессы).

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

Сохранение прозрачности

Вернемся к ситуации, описанной в начале статьи. У вас все хорошо, технологии определены, и команда трудится, создавая новый продукт. Но тут появляется взволнованный заказчик. Это значит, что ему не хватает visibility, а это — пробел в коммуникации.

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

Проджект-менеджер должен говорить с заказчиком как можно чаще. Если ты даешь ему value и visibility, все остальные изменения: в людях, технологиях и сроках — перестают вызывать фрустрацию. Значит, вам не придется писать странные отчеты в ответ на вопросы, которые кажутся не вполне понятными. Если у заказчика есть чувство контроля, детали он доверит вам. Вы же не спрашиваете, каким именно шпателем вам ровняли стены, делая ремонт, если мастер вовремя отчитался, что «коридор закончили», и вам этот коридор нравится. Этот принцип работает с заказчиками в любых сферах.

Как со всем этим справляться?

Просто работать.

12 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо за интересную статью. И что-то мне кажется, что Вы могли бы написать еще одну после фразы

Как со всем этим справляться?

:-)

Статья просто бальзам на душу. Спасибо!
Вы упоминаете в статье о персональной работе с ответственностью подчиненных — было бы классно, если бы вы могли поделиться своим опытом в этом направлении.

Тема про отвественность сложная и неоднозначная, корнями уходит в психологию. За идею спасибо, я подумаю, как правильно приподнести этот вопрос и как правильно его раскрыть. Если что-то напишу, то кину сюда линк где посмотреть.

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

Спасибо за отзыв. Я переодически выступаю на конференциях, о чем сообщаю у себя на фб. Если будем на одной конференции — приходите, буду рада видеть :)

запустили проект и наладили процесс [...] Но тут в дверях появляется главный стейкхолдер

Так это давно известно, что в стейкхолдерах всегда все проблемы )

А по старой школе образования — моему потоку ректор в своё время сказал: «Единицы из вас пойдут работать по специальности, многие уйдут в секторы, где востребованы технари со своим мышлением. В институте вы не учитесь каким-то дисциплинам, вы учитесь находить и использовать информацию, контактировать, взаимодействовать.»

У стейхолдеров главный ресурс на проект, поэтому я бы не называла их проблемой ;)

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

Вы смотрите на ситуацию слишком узко и однобоко! :)
Представим — Вы хотите купить автомобиль, новый, не б/у, не с «витрины», который не использовался для тест-драйвов, но начитавшись, что понравившееся авто часто угоняют решили поставить себе противоугонный комплекс. Вам говорят — авто ждать 1 месяц в Вашем цвете и комплектации, цена 30 тысяч, противоугонный комплекс выбранный Вами с установкой ещё 2 тысячи и 2 дня ... Продолжаем? ... В итоге — 2 месяца ждать авто, комплектация приехала без панорамного люка и литых дисков, допустим диски-то пол беды, поменять можно, но вот панорамный люк уже не врежешь, в альтернативу вместо белого перламутра предлагают цвет детской неожиданности, но в нужной комплектации и «немного с витрины», без компенсаций, противоугонных комплексов «ой, простите, Вы внесли предоплату, но таких уже нет», нужно под заказ ждать месяц, давайте-ка мы Вам другой впарим или застрахуем чтоб спали спокойно на месяц за 200 баксов за Ваш счет? :) Вернуть предоплату? Нет, это мы не можем. С точки зрения менеджера автосалона Вы «да задолбал, мудило, всё ему не нравиться, мозги парит каждый день, подумаешь месяц, подумаешь цвет, подумаешь люк» ... Вы довольны? Да сказка, что вообще может не нравиться! Если уж говорить о заказчике, то он платит деньги. На эти деньги зачастую и работает компании-аутсорсеры скопом, раздавая зарплаты. Разумеется то, что клиент всегда прав это мягко говоря чушь, но то, что он проблема и вообще источник проблем это ещё большая чушь, даже ахинея! Если посчитать хорошенько, то думаю в 90% случаев не умение договориться клиента с «продавцом» это будет проблема продавца.
Стейкхолдеры — к слову это все заинтересованные лица, а не кто-то конкретный. Причем главный стейкхолдер это может быть даже не заказчик, а наоборот компания-исполнитель допустим, для которого портфолио-проект для такой «крупной рыбы» это вообще возможность выйти на новый уровень заказчиков и сумм. Или на новый рынок. А может этот проект вообще для всех маленькая галочка, а для команды или PM это веха вообще в карьере по каким-либо причинам.
В итоге — даже не близко ...

Да в общем-то это был сарказм ) Конечно проблема шире )

Стаття коротка, а тема дуже широка і складна. Очевидно що тут багато спрощень, а багато відступів в тексті взагалі не про проекти. Людям які тільки починають свій шлях у проектному менеджменті я би радив не шукати «спрощень», а все таки глибоко розібратися в темі. Ось наприклад тема мотивації — теорій багато (тут тільки деякі — uk.wikipedia.org/wiki/Мотивація) і всі вони можуть бути використані і принести результат за певних обставин. Але мотивація в людей різна, більше того вона ще й міняється в часі — тому не все так просто.
Або наприклад визначення цілей проекту. Це дуже проста і хороша ситуація, коли вам потрібно розмовляти тільки з одією людиною на стороні замовника. А коли там багато учасників які впливають на проект, і часто їх інтереси просто не співпадають — тут вже без хорошої підготовки (в тому числі знання різних методів) і попереднього досвіду буде дуже важко.
По темі підводних каменів — всі вони починають з’являтися в результаті поганої перед-проектної підготовки, недостатнього планування, самонадіності і недисциплінованості ПМа. Часто це відбувається під гаслами Agile методологій — начебто «будемо уточнювати плани і специфікації по ходу». Тільки у випадку проекту це частіше не працює, ніж дає хороші результати. Тому Agile це гарно, але для проектів потрібен саме проектний менеджмент.
Що ж робити — ну я би сказав читати стандарти (www.pmi.org/...​ndards/foundational/pmbok), глибоко розібратися в кожній темі окремо, і не забувати про дисципліну. Тоді все буде виходити.

Так, ви праві, тема значно ширша за статтю. Ціллю статті було донести єдину думку, щодо того, як дивитись на те, що хоче замовник. Нажаль, назва теми трохи вийшла недвала, що могло призвести до думки, що я говорю про таку широку тему, як пошук срібної кулі.
Я повністю погоджуюсь щодо того, що Agile не відміняє проектний менеджмен, і коли менеджер говорить, що в нього agile, тому не треба заглиблюватись в проектний менеджент по PMBok або іншій методології — це багато говорить про цю людину як спеціаліста, але, нажаль, на ринку праці зараз досить багато саме таких недо-менеджерів.

Подписаться на комментарии