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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

Немножко о себе - 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-у интуиция, которая лишает его иллюзий, что все можно предусмотреть и спланировать. Рекомендую такую практику всем.

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

Источник: https://habr.com/ru/post/721040/


Интересные статьи

Интересные статьи

В прошлой статье про атомную промышленность я отмечал E.ON как одного из операторов атомных станций и я решил разобраться, чем этот бизнес занимается, кроме атомной генерации. Какой углеродный след ос...
Когда я вижу, как кто-то учит кого-то языку программирования, то частенько замечаю тенденцию показывать новичкам примитивные примеры в виде ToDo list. Помимо того, что подобные примеры не учат ничем...
Однажды, в понедельник, мне пришла в голову мысль — "а покопаюсь ка я в новом ядре" (новым относительно, но об этом позже). Мысль не появилась на ровном месте, а предпосылками для нее стали: ...
Здравствуйте. Я уже давно не пишу на php, но то и дело натыкаюсь на интернет-магазины на системе управления сайтами Битрикс. И я вспоминаю о своих исследованиях. Битрикс не любят примерно так,...
Вчера в конгресс-центре «Альфандега» в Порту объявили, что Москва выбрана площадкой для проведения старейшего и самого престижного в мире студенческого чемпионата по спортивному программирова...