Что реально важно знать менеджеру проектов, чтобы войти в IT с нуля?
Менеджер проектов в IT — это человек, у которого нет формальной власти над командой, но есть ответственность за результат. Ты не можешь "приказать" разработчику или тестировщику, но при этом именно ты отвечаешь за дедлайны, качество и коммуникации. Что делать в такой ситуации новичку, который только пришёл в айтишку и пока не говорит на "местном диалекте"?
Введение
Зайти в IT как менеджеру проектов — звучит просто: ты же уже умеешь "ставить задачи", "контролировать сроки" и "общаться с людьми". Но вот первая встреча с командой: разработчик говорит, что "билд упал", тестировщик кидает в чат баг-репорт с тремя скриншотами и словами "не воспроизводится", а DevOps просит "поднять пайплайн". И ты сидишь с глазами а-ля "сделайте, пожалуйста, переводчик с айтишного на человеческий".
Я сам видел, как в IT заходили PM-ы из стройки, маркетинга и даже госслужбы. У одних получилось мягко встроиться, у других был культурный шок: команда не реагирует на "я начальник, а вы должны", Jira кажется новой вселенной, а Agile — каким-то секретным культом.
Давайте по-честному разберём, что реально нужно знать PM-у, чтобы без лишнего стресса войти в IT.
Теория: база для айтишного PM-а
- IT ≠ магия Код пишут люди, тестируют люди, всё ломается тоже людьми (или из-за того, что кнопка "Deploy" была нажата не туда). Нужно понимать хотя бы базово, как работает процесс разработки: от идеи до продакшна.
- Agile — это не просто слово для резюме Scrum, Kanban, спринты, ретро — это не магические заклинания. Это способ, которым команда реально работает каждый день. Не знаешь, что такое "Definition of Done" — значит, завтра поймёшь на своей шкуре, почему задача "готова" не значит "готова".
- Инструменты — это твой новый офис Забудь Excel и почту как единственный инструмент. Теперь твой рабочий стол — это Jira (где живут задачи), Confluence (где хоронят документацию), Slackозаменитель (где жизнь кипит 24/7). Если ты не умеешь в Jira, это как бухгалтер, который не видел 1С.
- Английский — без этого никуда Большая часть документации, коммьюнити и мемов (да, даже мемов) — на английском. Уровень "читать и переводить со словарём" уже спасает.
- Словарь айтишника Ты не должен знать, как писать SQL-запросы, но понимать слова "pull request", "merge", "CI/CD", "деплой" придётся. Иначе диалоги будут напоминать серию "Теории большого взрыва", где Шелдон общается со "среднестатистическим человеком".
Практика: что реально поможет на старте
- Учись слушать, а не командовать В IT никто не обязан тебе подчиняться напрямую. Твоя сила — в фасилитации: собрать митинг, задать правильный вопрос, убрать блокеры. Тут работает не "делай так, потому что я сказал", а "давай посмотрим вместе, что мешает задаче сдвинуться".
- Не бойся учебных проектов Запусти тестовую команду на пет-проекте, собери сайт другу или просто внедри Kanban-доску в своём отделе. Лучше один реальный кейс, чем три сертификата без опыта.
- Гугл и ЖПТ — твои лучшие друзья Половина жизни PM-а в IT — это "почему Jira не показывает спринт?" или "как работает merge в GitHub". Умение задавать правильные вопросы в Google или ChatGPT — уже суперскилл.
- Фасилитация митингов — это новый вид спорта Планирование легко превращается в двухчасовой спор о том, "почему кнопка зелёная, а не синяя". Твоя задача — удерживать рамку. Если умеешь завершить митинг вовремя, команда тебя будет любить.
- Документы = артефакты, а не романы Никто не будет читать 30 страниц текста. В IT ценят коротко и по делу: user story, acceptance criteria, пара скриншотов. Всё остальное — "TL;DR, не осилил".
Типичные ошибки новичков-PM в IT
- Писать ТЗ "как в строительстве" 50 страниц текста с оглавлением и подпунктами "1.3.2.4.7" — это сразу минус уважение от команды.
- Думать, что Jira = Excel Если воспринимать Jira как "табличку с тасками", то ты упускаешь её главную силу — прозрачность процессов и связность задач.
- Ставить нереальные сроки "срочно, к вечеру" В IT это не работает. Разработчик не может "дописать 200 строк кода быстрее", как грузчик не может "поднять холодильник в два раза быстрее".
- Фокусироваться только на контроле Микроменеджмент в IT убивает доверие. Твоя задача не "сидеть над душой", а создавать условия, чтобы команда могла работать.
- Игнорировать командные ритуалы Daily, ретро, демо — это не пустая трата времени. Это инструменты, которые держат команду в тонусе. Пропускаешь их — теряешь связь с реальностью.
Заключение
Чтобы войти в IT менеджеру проектов, не нужно быть разработчиком. Нужно:
- понимать процесс разработки,
- освоить Agile на практике,
- уверенно владеть инструментами (Jira, Confluence и т.д.),
- прокачать английский и словарный запас,
- научиться слушать команду и фасилитировать процессы.
IT-PM — это не "надзиратель", а "катализатор" работы команды. Если ты в этом разберёшься — IT тебя примет, и, возможно, даже полюбит.