В этой статье я хочу поделиться своим опытом того, как я учился вести проекты, то есть контролировать риски, планировать ресурсы и все такое.

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

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

И так задача - научиться вести проекты.

Как реально этому научиться, какие варианты есть?

Вариант 1. Можно читать книжки, статьи на эту тему. Кому-то это поможет, но имхо это один из тех навыков, которые приобретаются не за счет изучения теории, а целиком из практики. Невозможно научиться кататься на велосипеде по книжке, сразу сев и поехав

Вариант 2. Пробовать, пробовать, набить шишки, и через N проектов вы станете хорошим продукт-менеджером, если вас не уволят или по пути вы не впадете в глубокое уныние ). Опять же так себе вариант - во-первых пока научитесь, угробите кучу проектов в ущерб своей карьере. А во-вторых это все равно что учиться водить машину с нуля без автошколы, 30 раз врезаясь в препятствие, пока поймете, что делает педаль тормоза, а что педаль газа.

Могу это подтвердить еще своим опытом создания нескольких стартапов.

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

Вариант 3. Наверное самый хороший вариант - зайти в команду, где хороший и опытный продукт менеджер. Встать рядом с ним и учиться у него.

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

Вариант 4. То, что предлагают разные тренинги и бизнес-курсы:

А давайте поиграем в бизнес-игру и по ходу столкнемся с реальными (на самом деле "условно-реальными") проблемами и научимся их решать.

Лучше, чем ничего. С нуля, думаю, поможет понять основные правила игры, но этого недостаточно чтобы стать хорошим менеджером. Условия слишком игровые, время очень ограничено, реальные риски вы не прочувствуете.

Более продвинутый подвид встречается на внутренних корпоративных курсах: давайте вы будете делать как бы реальный проект в течение 1-2 кварталов в группе.

Сам в таком не участвовал, но наблюдал со стороны.

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

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

Итак, вариант 5, мой.

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

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

Спорт брать не советую, т.к. это отдельная тема и очень сложная

Стартапы и другие сложные вещи тоже не нужно. Берите что-то самое простое. Простое в том плане, где понятен конечный результат и понятно какие действия нужно сделать чтобы его достичь (чтобы сварить картошку, нужно ее почистить и кинуть в кипящую воду).

Для себя я выбрал следующее - разровнять участок у себя на даче. Тут понятна цель и понятно, как ее достичь, не надо ничего выдумывать.

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

Собственно, в этом описание методики заканчивается, далее я опишу свой опыт и какие выводы для себя сделал.

Я планировал сделать свой проект (разровнять участок) за летний сезон по выходным. В итоге сделал за два с половиной сезона. Если точнее, то 80% я сделал за два сезона, еще 10% в 3-й сезон, оставшиеся 10% я решил не делать т.к. идеальное враг хорошего.

Что я понял из этого действительно полезнейшего для меня опыта:

1. Большинство рисков вы все равно не предвидите. К этому надо просто быть готовым

Например я никак не смог предвидеть следующее:

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

- бывают у нас периоды, что именно на выходные идут дожди и работать с землей невозможно

- мой поставщик земли, который годами всем возил землю вдруг сказал, что он теперь это делать не сможет, пришлось искать нового

- та земля, которую привез новый поставщик, плохо подходила для газонов (не плодородная), пришлось удобрять

- не говорю уже что были моменты, когда я болел, либо не мог выезжать на выходные на дачу по другим причинам

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

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

2. Роадмеп нужен. Но он должен быть живым и постоянно меняться. Многие руководители ждут, чтобы вы вот все спланировали на квартал-два и, если есть отклонения от роадмепа, значит вы плохо спланировали или плохо поработали.

Имхо концепция роадмепа должна быть другая.

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

Он должен быть живой и периодически пересматриваться (например, каждые две недели) и адаптироваться под выявленные риски.

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

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

Вместо этого лучше подготовьте для себя "козыри в рукаве", резервы, perk-и (называть можно как угодно). Т.е. то что вам поможет справиться с проблемами, когда они появятся.

Я выявил для себя их два основных типа:

boosting. Т.е. краткосрочное увеличение собственной производительности

В моем случае - можно взять отпуск на 2-3 дня и доровнять те участки, которые не успел.

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

Этим козырем очевидно нельзя пользоваться часто, иначе будет выгорание

припасти потенциал из дополнительных ресурсов.

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

Применительно к работе: заблаговременно договориться о помощи из других отделов (разработчики, аналитики, data scientist-ы). Либо перенести сотрудников временно с других задач на текущую.

Тут кстати я понял еще правило - не нужно при планировании квартала планировать так чтобы все были загружены на 100%. Понятно, что не каждое руководство это поймет. В этом случае можно показать, что планируемая загрузка 100%, но реально нужно оставлять резерв в 15-30%. К тому же всегда приходят непредвиденные задачи от руководства, adhoc-и.

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

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

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

Вот и все. Критикуйте на здоровье :) Повторюсь - может для кого-то это все очевидно, но, если даже одному человеку эта статья будет полезна, я буду рад.

Комментарии (8)


  1. lebedec
    00.00.0000 00:00
    +6

    Можно читать книжки, статьи на эту тему. Кому-то это поможет, но имхо это один из тех навыков, которые приобретаются не за счет изучения теории, а целиком из практики. Невозможно научиться кататься на велосипеде по книжке, сразу сев и поехав

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

    Например, давайте поговорим про управление рисками.

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

    То что вы хитро назвали "boosting", по книжкам называется перенос рисков. Отправляя разработчиков на внеурочку вы не только передаете им управление сработавшим риском, но и переносите ответственность за возможные дефекты. А эти дефекты обязательно будут учитывая внеплановость и стрессовость ситуации. Кроме того, предлагая неравнозначное вознаграждение в виде выходных вы еще и создаёте новый риск демотивации сотрудников.

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

    • дублирование, одна реализация разными командами

    • диверсификация, разная реализация одной фичи

    • предотвращение, отказ от фичи

    • эксплуатация, превращение риска в фичу

    • и т.д.

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

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

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

    Вы не поверите что пишут про интуицию в современных книгах. Спойлер. Это накопленные знания.


    1. BosonBeard
      00.00.0000 00:00

      Ну человек провел опыт, сделал вывод, это тоже путь обучения для данного автора, просто эффективность эта как у изобретения велосипеда в 21 веке


      1. MockBeard
        00.00.0000 00:00

        Статья про выравнивание участка через призму PMBOK была-бы намного интереснее.


    1. laatoo
      00.00.0000 00:00

      дублирование, одна реализация разными командами

      диверсификация, разная реализация одной фичи

      денег едва хватает на одну

      предотвращение, отказ от фичи

      отличный метод управления риском!

      эксплуатация, превращение риска в фичу

      не менее чудесный


  1. NewMan_by
    00.00.0000 00:00
    +2

    Проджект и Продукт все же разные виды менеджеров. Правильная теоретическая база это минимум. А ваш подход - это попытка прыгнуть с 1й ступеньки сразу на 6ю


  1. AcidoKiwi
    00.00.0000 00:00

    По логике статьи, любая мать погодок - сеньор проджект-менеджер в ИТ. Опыт ведения проектов должен быть хоть немного релевантен решаемым задачам. Я умею заставить копать землю, поэтому сейчас программисты у меня напишут чёткую софтинку)))


  1. Dmitrii_Bogdashkin
    00.00.0000 00:00

    через N проектов вы станете хорошим продукт-менеджером

    на этом месте кринжанул


    1. alexeysakhon
      00.00.0000 00:00

      А как бы вы сформулировали эту мысль?