Цитаты из книг автора «Алексей Минкевич»

Как и любая другая система, команда без управления стремится к хаосу. Независимо от рабочего подхода, должен быть человек, который будет упорядочивать работу команды. Цель управления — добиться такого состояния системы, при котором 100% приложенных командой усилий приближают проект к успешному завершению. С точки зрения PMI в управлении командой существуют следующие процессы. Планирование управления человеческими ресурсами. Процесс идентификации и документирования ролей в проекте, зон ответственности, требуемых навыков и отношений подотчетности, а также создания плана обеспечения проекта персоналом. На этом этапе менеджер определяется с ожиданиями относительно команды, решает, какие специалисты нужны на проекте, какого уровня и сколько. Набор команды проекта. Процесс подтверждения доступности необходимых специалистов в компании и набора команды для выполнения задач проекта. На этом шаге мы приступаем к собеседованиям и найму людей. Развитие команды проекта. Процесс обучения и повышения квалификации людей в команде, улучшения уровня взаимодействия между ними и общих условий работы для того, чтобы повысить общую эффективность выполнения проекта. Еще на этапе набора команды менеджеру следует определиться, каким образом он будет развивать людей и какие возможности для этого предусмотрены на проекте. Управление командой проекта. Процесс контроля эффективности работы команды, обеспечения обратной связи, решения проблем и управления изменениями, направленными на оптимизацию выполнения проекта. Менеджеру нужно определиться, как он будет управлять командой в ежедневном режиме. Например, какие процессы и инструменты будут использоваться в проекте, как будут приниматься решения и преодолеваться конфликты и т.д.

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

А как же плюсы? Конечно же, они есть. Во-первых, большой масштаб решаемых задач. Управляя командой, можно сделать гораздо больше, чем в одиночку. Нет большего удовольствия, чем запуск крупного проекта и осознание того, что вы сделали его вместе. Во-вторых, менеджер принимает решения и несет ответственность. К слову, любому руководителю платят именно за опыт и ответственность. Чем больше у него опыта, тем вернее решения, тем спокойнее и хладнокровнее он будет вести себя в сложных ситуациях, ведь он уже через них проходил. Тут еще могу добавить, что, с моей точки зрения, любому руководителю полезно заниматься адреналиновыми видами спорта. Так можно натренироваться адекватно реагировать на выбросы адреналина и в сложных ситуациях оставаться спокойным и рассудительным. В-третьих, помощь в росте и развитии людей. Каждый проект — это процесс обучения. Очень редко руководителю попадается команда, которая на 100% знает, что делать. Обычно члены команды учатся в ходе проекта, чтобы затем успешно его завершить. Для меня рост людей — это один из самых важных моментов. Очень приятно наблюдать за тем, как люди сначала учатся решать сложные, почти невыполнимые в начале проекта задачи, а затем легко справляются с ними. Какой путь выбрать — это сугубо индивидуальное решение. Если вы любите людей и общение, умеете быть лидером и работать в условиях стресса, то из вас может получиться хороший руководитель проектов. При этом нужно понимать, что хорошим разработчиком вы уже не будете, так как физически не сможете изучать все технологические новинки. Стать хорошим менеджером — это долгий путь, на освоение этой профессии уйдут годы. В моем случае трансформация «разработчик — руководитель проектов» заняла пять лет. Сначала я 90% времени тратил на написание кода, а оставшееся время — на управление. Через пять лет ситуация была обратной. Свою последнюю строчку кода я написал в январе 2011 г. В 2012 г. я уже стал руководителем портфеля проектов и управлял отделением из 55 человек. И передо мной уже стоял другой серьезный вызов — привести нашу команду к успеху, а не написать код. Алексей Минкевич

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

У хорошего технаря есть ряд существенных преимуществ перед руководителем проектов, который больше не пишет код, а тратит 100% своего времени на управление. Во-первых, всегда есть куда расти. Технологии идут вперед семимильными шагами: появляются новые стеки, новые языки программирования, развивается инфраструктура. Это все очень интересно, но, чтобы постоянно быть в курсе всех изменений, нужно много времени посвящать изучению нового. Во-вторых, если понадобится, разработчик может работать удаленно из любого уголка мира. Это здорово. В-третьих, работу в другой стране найти проще инженеру, чем руководителю проектов. Технологии ведь везде одинаковы, в отличие от культуры. Есть и минусы. Во-первых, можно надолго застрять на одном длинном проекте и остановиться в развитии. Во-вторых, есть риск потерять навыки общения и связь с окружающей реальностью. Это побочный эффект постоянной работы за компьютером.

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

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

Например, метрика показала: на проекте что-то пошло не так. А что делать дальше? Дальше нужно вносить изменения в процесс работы организации, чтобы повлиять на источник возникновения нежелательных отклонений и убрать его. Всегда лучше заранее, проактивно продумать, какие шаги предпринять в случае ошибки, чем действовать по факту. И вот тогда в компании начинают появляться соответствующие процессы и регламенты. Корректирующие действия описывают, что надо сделать в случае возникновения отклонения, на которое нам укажет метрика. А превентивные действия позволяют не допустить возникновение проблемы. Например, вы ведете проект по разработке новой платежной системы. Метрики демонстрируют, что количество дефектов существенно выросло в начале марта. Анализ основной причины показывает: все дело в том, что первого марта проект покинул архитектор Патрик, который решил организовать свой собственный стартап. Корректирующим действием будет постараться как можно быстрее найти толковую замену архитектору на рынке. А превентивным действием, чтобы избежать подобных проблем в будущем, будет назначить back up или заместителя для каждой ключевой позиции на проекте. Ведущий специалист обучает более юного коллегу таким образом, чтобы тот мог выполнять его обязанности во время отпуска или болезни. В случае ухода ключевого сотрудника его заместитель сможет достаточно быстро подхватить работу и не допустит провалов на проекте.

Метрики качества: Количество дефектов. Степень покрытия кода тестированием. Процент времени, когда система работала и была доступна.

Метрики продукта: увеличение дохода (Expansion revenue) — процент новой прибыли, которую бизнес получает от клиентов; индекс приверженности клиентов (Net Promoter Score, NPS) — опрос, который демонстрирует, насколько ваши клиенты готовы рекомендовать продукт своим друзьям; индекс удовлетворенности клиентов (Customer Satisfaction Score, CSAT) — опрос, который демонстрирует, насколько ваши клиенты удовлетворены продуктом; отток пользователей (Churn) — подсчет ушедших из компании клиентов и связанных с ними доходов, которые недополучила компания; ключевые показатели эффективности (Key Performance Indicators, KPI) — всевозможные показатели бизнеса, к которым нужно стремиться.