Как научиться вести проекты IT-шнику

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

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

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

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

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

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

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

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

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

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

• и т.д.

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

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

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

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

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

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

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

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