Консультации и тренинги по управлению проектами

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

В моем активе опыт длиной 20 лет и десятки успешных проектов разных масштабов (от трех человек до сотни), в разных областях бизнеса (консалтинг, банки, производство, ИТ) и в разных географических локациях (Россия, Украина, Европа).

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

Чтобы связаться со мной по вопросам консультаций или обучения управлению проектами, напишите на psilonsk@gmail.com.

Тут можно подписаться на мой телеграм-канал.
promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

Верхний пост: лучшие рубрики блога, FAQ для начинающих менеджеров проектов и многое другое

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

Об управлении рисками в проектах. Все, что вы не знали и боялись спросить о проектных рисках.
Collapse )

Великие менеджеры, великие проекты. Рассказы о том, как делаются проекты, изменившие мир (здесь вы вряд ли найдете историю про внедрение 1С на заводе).
Collapse )

«Непридуманные истории об управлении проектами» – рассказы из жизни менеджера проектов Леши Шрудкина и его коллег. Основано на реальных, хотя и не всегда приятных, событиях. Сериал без конца и края.
Collapse )

Список лучших постов – рекомендовано к неторопливому прочтению.
Collapse )

Задачки-водокачки – одна из самых интерактивных рубрик блога. Разбираем сложные управленческие ситуации, встречающиеся в абсолютно реальных проектах. Умные менеджеры ищут решение кейсов и учатся на своих и чужих ошибках.
Collapse )

Вы обалдеете, сколько классных постов по тегам "заметки на бегу", "упражнение для менеджеров" и "менеджмент в литературе".

А уж сколько рецензий на  бизнес-книги в моем блоге
вообще с ума сойти.

А еще тут можно подписаться на мой телеграм-канал.

🧩 О монетизации продукта



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

Это вызов: задается высокий уровень ожидаемого качества и пользы. Если пользы нет, то после начального периода люди просто удалят приложение.

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

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

Все остальные варианты меня либо дико раздражают, либо просто не работают.


Тут можно подписаться на мой телеграм-канал.

🗣 🦠 👥 Лжеэкономия на удаленке



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

И все думают, что нанять хорошего (!) разработчика в провинции можно быстро и недорого.
Это не так.

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

Да очень просто. Качественный фрилансер — это профи, который все умеет и не нуждается в няньке. Это онлайн-человек. Он прекрасно себя чувствует на внутреннем или на русскоязычном рынке, а если не поленился подтянуть английский, то и на международном. С чего ему стоить дешево? Может, вы выиграете процентов пятнадцать на квартирно-транспортных расходах. Или не выиграете, если его специализация востребована. На Senior Java dev-e не сэкономите точно. )

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

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


Тут можно подписаться на мой телеграм-канал.

‼️ Технарям о текстах



Если ты менеджер проекта или продукта, владелец продукта, аналитик, тестировщик или аккаунт-менеджер, ты пишешь тексты. Ты их пишешь, даже если ты программист. И если ты не умеешь писать тексты, ты хреновый специалист.

Дам несколько дельных советов. Годятся и для технических документов, и для писем клиентам или коллегам.

1. Не пиши текст с первого раздела. Начинай с самой важной мысли, с самой важной части. Даже если это последние пять строк документа. Введение напишешь потом, когда основная мысль будет отточена и завершена. Если начинать писать текст так, как его будут читать, то потратишь кучу времени на раздел «Общие положения» и ему подобные. А потом все равно придется переписывать.

2. Запомни: ты не стилист уровня Чехова или Довлатова. Ты не сможешь написать сразу так, чтобы читатель подпрыгивал от восхищения. Ни-ко-гда. Начни писать так, как ты думаешь: корявенько, не подбирая слов, путаясь в предложениях и мыслях. Если легче с матом – матерись. Вывали на бумагу всю страшненькую кучу своих мыслей. И только потом начинай искать верные формулировки и подходящие слова, разгребай ее, делай из кучи конфетку. Сразу написать хорошо не выйдет.

3. Запомни: чем короче, тем лучше. Для текста это точно справедливо. )) Не пиши длинных предложений. Если получилось длинное, разбей на несколько коротких.

4. Не пиши предложения в пассивном залоге. Для тех, кто не в курсе: это фразы типа «тестирование системы было проведено специалистами заказчика». Надо так: cпециалисты заказчика протестировали систему. Меньше пассивного залога – лучше текст.

5. Проверь документ перед отправкой. В нем не должно быть ошибок, опечаток, несогласованных частей предложения, лишних скобок и кавычек. Не уверен в своей грамотности – пользуйся автоматическими средствами проверки орфографии. Если в документе есть ошибки, то и к автору документа, и к его компании, и к его продукту отношение как к … гм… ну, ты понял. Я уж молчу про ошибки в интерфейсе продукта.

Тексты – это важно.

Тут можно подписаться на мой телеграм-канал.

🤷♀ Не забывать о ловушке аналогий



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

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

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

Бизнес-идеи поясняют отраслевыми аналогиями. «Это как Uber для животных». «Это как ворд, но онлайн». «Это как варкрафт, только в комосе».

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

Именно поэтому будущих математиков на первом курсе учат, что нельзя доказать утверждение, приведя пример. Примером можно только что-то опровергнуть.
Аналогия помогает объяснять, но не заменяет объяснение.

Аккуратнее с аналогиями.


Тут можно подписаться на мой телеграм-канал.

📝 Эскалационная азбука



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

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

Обычно передают административные, управленческие проблемы. Реже — технические.
Сотрудник другого подразделения профакапил срок, с менеджером не смогли договориться, вас сильно оскорбили, задача зависла, процессы ошибочны? Эскалируйте.

Чтобы эскалация работала, надо следовать нескольким простым правилам. Простым, но обязательным.

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

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

3. Эскалация — это инструмент управления. Это не способ пожаловаться на кого-то и вылить на него ведро говна. Это способ решить проблему, когда все другие инструменты не работают. Этику, уважение к коллегам и здравый смысл никто не отменял. Обычно проще договориться. У вас в компании проще сразу эскалировать? Сочувствую.

4. Эскалация — это инструмент управления. Ей пользуются дозированно и последовательно. Не надо сразу бежать жаловаться к начальнику начальника вашего оппонента. За один раз — один шаг. А то наживете себе лишних недругов из тех, кого пропустили в своем порыве поиска истины. Оно вам надо?

5. Эскалация — это инструмент управления. Работает он с фактами, а не с домыслами. Желательно — с письменными фактами. Тогда вам тоже станет понятно: есть документированная проблема или чьи-то действия всего лишь не соответствуют вашим ожиданиям. Или, может, вам кто-то персонально не нравится? Это не повод для эскалации.

6. Эскалация — это инструмент управления. Ее не надо бояться. Менеджер не выглядит слабым, если эскалирует проблему. Он выглядит слабым, когда проблема неожиданно для всех всплывает, а о ней никто не знал.

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

Тут можно подписаться на мой телеграм-канал.

📚🧑🏿💻📚 О дистанционном обучении новичков



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

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

Новичок неосознанно впитывает технологическую и управленческую культуру команды. И сам на нее влияет.

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

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

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

Ситхи тоже не просто так везде по два бродили — понимали, что без наставника никак. )

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

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


Тут можно подписаться на мой телеграм-канал.

🤲 Право на отказ



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

Попросить и дать право на отказ - существенно увеличить шансы на выполнение задачи.

Тут можно подписаться на мой телеграм-канал.

🔤 Протоколы, задачи и необоснованные ожидания



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

Но приходит уже 4 марта, а ничего не сделано. Уж полночь пробило, а Германа все нет. И 5 марта тоже ничего не передали. Но ведь в протоколе, который Герману тоже выслали, все написано! Как же так?

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

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

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

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

Неправильная цепочка: написал ответственного в протоколе встречи → ожидаю, что он читает протокол и все сделает → расстроился, что ничего не сделано в срок или сделано не то → получил люлей от клиента → наказал инженера.

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

Тут можно подписаться на мой телеграм-канал.