IT-ментор: как стать успешным руководителем проекта в ИТ

Проджект — это человек на линии огня. С одной стороны команда, с другой — заказчик. И чаще всего именно он принимает на себя поток претензий и эмоций. 😤 Проблемные заказчики будут всегда Кто-то недоволен сроками, кто-то придирается к мелочам, кто-то просто слил плохое настроение. И такие ситуации происходят практически каждый день — иногда несколько раз за день. Хард-скиллы тут мало помогают. Методологии, диаграммы, планы — важно, но без умения общаться проект часто встанет. А если заказчик решит «отыграться» на команде — всё на проджекте. 💪 Что реально спасает 1. Не реагировать резко на негатив...

Каждый проджект сталкивается в работе с такой ситуацией. Срок близко, задач много, команда не успевает. Что делать? 1. Сначала понять причину Не спешите сразу «подгонять» команду. Нужно разобраться: • задач реально больше, чем можно сделать? • оценки были слишком оптимистичными? • есть блокеры снаружи (ждём дизайны, доступы, решения от клиента)? Без этого любые действия будут впустую. 2. Сказать честно Худшее решение — молчать до последнего. Лучше сразу сообщить заказчику о проблемах: • что не успеваем, • где именно проблема, • какие есть варианты. Это вызывает доверие и даёт время вместе найти решение...

Сейчас везде пишут: «Развивай софт-скиллы, без них никуда». Но если честно — далеко не все навыки нужны каждому. У каждой роли своя реальность. Софт-скиллы можно сравнить с любым хобби. Никто же не умеет и шить, и вязать, и вышивать, и рисовать. Да это и не нужно. Каждый выбирает то, что ближе, и становится в этом лучше. С софт-скиллами та же история: важно прокачивать именно то, что связано с вашей профессией. 🔑 База для всех Есть набор, без которого тяжело в любой сфере: ✔️ критическое мышление, ✔️ чёткая речь без «коверкания» слов, ✔️ умение ясно формулировать мысли. Это фундамент, на который ложится всё остальное...

Сейчас всё чаще вижу вакансии «системного аналитика, который и бизнес понимает, и постановку напишет, и без разработчика рядом справится». На словах — универсальный солдат, на деле — подмена понятий. Системный аналитик — это про анализ, логику и формулирование решений в понятной форме для команды. Он должен разложить бизнес-задачу, описать, что и зачем делаем, предложить варианты реализации, а не принимать технические решения «под капотом». Детали вроде того, какой объект метаданных создать или как именно хранить данные, зависят от архитектуры, регламентов разработки и особенностей платформы. И эти решения должны рождаться в коллаборации с разработчиком или техническим архитектором...

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