Бывает так, что у вас в коллективе есть чувак, с которым неприятно работать. Или вы вышли на новое место, а там – Он. Или вы начали новый проект, вам дали Архитектора, а это – Он.

Он может ныть, может быть категоричен и послать нафиг, местами он вас троллит и, кажется, даже самоутверждается за ваш счёт. Короче – бесит. Сейчас таких стало модно называть токсами 🤢

 Я как-то работал с таким. Я называл его «критикующий архитектор»:

— Толя, я тебе там ТЗ выслал, ты поглядел?

— Ну открыл, да.

— Чего скажешь?

— Да чего говорить-то? Говно какое-то, стили не выровнены, оглавление едет. Я открыл и закрыл, нахрен такое смотреть? (в оригинале, разумеется было матом)

Эта статья – очередная из цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых менеджерских софтскиллах. Кому интересна эта тема, читайте другие мои статьи на Хабре и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Сегодня будет про неуспешные проекты

Про успешные проекты я уже писал вот тут (Что такое Успешный проект), а теперь пришло время поговорить про плохое: основные факапы в проектах, причины, их порождающие, и что можно сделать, чтобы неуспешных проектов у вас, как менеджера (или как менеджера менеджеров) было меньше.

Tldr: статья на статистике доказывает, что самое важное – софтскиллы у РП, а с этим на рынке ИТ проектов сейчас проблемы.

Статья состоит из 2 частей:

- статистика по мировому и (немного) российскому рынку;

- мои выводы из этой статистики.

Это - очередная статья, посвященная тому, чему менеджеров не учат на курсах - софтскиллам. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» , а также читайте другие статьи здесь, на Хабре

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

Давайте серьёзно: оценки и списания — это инструменты прогнозирования и анализа проблем. Если бы все ИТ-команду всегда укладывались в сроки, эти вопросы бы не возникали. Но реальность другая: менеджеры ругаются на разработчиков, разработчики — на "чайка-менеджеров", а в итоге, по опросу в моём канале, 50% компаний либо не учитывают затраты вовсе, либо делают это формально.

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

В статье ниже я собрал основные подходы, выделил их плюсы и минусы, а в конце, опираясь на свой опыт (25+ лет внедрения проектов и несколько лет развития собственного продукта для управления IT-командами), делаю вывод о наиболее эффективном подходе.

Эта статья — обобщение идей, обсуждавшихся в моём Telegram-канале "Морковка спереди, морковка сзади". Если вам интересно проектное управление в IT и все проблемы, с ним связанные - заходите и подписывайтесь, а также читайте другие мои статьи здесь, на Хабре.

Я на сайте увидел Её. Какая же Она была классная! Я почитал про нее поподробнее и понял – я ее хочу. Явно меня ждет там что-то интересное. Я почти влюбился. Я понял, что должен написать. Но это необычный случай, я искал ее слишком долго,  поэтому я готовился несколько дней. Я даже сходил в фотоателье и сделал приличные фотографии (говорят это работает, они обращают на это внимание). Я придумал полностью оригинальный текст для знакомства. Я отлаживал его еще день.

И через три дня после того, как я заметил Её, я написал!! На такое письмо было просто невозможно не ответить. Это было и признание в любви, и обещание верности, и много чего еще одновременно. Это был бронебойный снаряд, запущенный в ее сторону, в котором было столько страсти, столько энергии и желания, что он мог бы пробить самую твердую стену и растопить самое ледяное сердце...

Я нажал отправить...

А в ответ – прочитано. И все.

Я не мог в это поверить. Вдруг мое сообщение просто потерялось среди сотен таких же, желающих этой красоты, я же так старался? Но напоминать о себе, вроде, не принято, и я молчал.

А мне так никто и не ответил...

А еще через месяц пришла стандартная отбивка с сайта: "Вакансия, на которую вы откликались, перенесена в архив".  😭😭😭

Это еще одна статья, посвященная софтскилам и лайфхакам в управлении, о которых не рассказывают на курсах по менеджменту. На этот раз будет про отношения и работу и какие навыки пригодятся и там, и там. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» и читайте другие мои статьи здесь, на Хабре.

Я долго учился правильно писать это слово: приоритизация, но намного дольше я учился правильно приоритизировать.

Собственно, в самих приоритетах запутаться сложно даже начинающему менеджеру, их всего 4: Низкий, Средний, Высокий и Критический (бывает больше, но это, обычно, извращения). Но вот как их правильно выстроить, как потом отстоять перед заказчиками и какие подводные камни тут вас будут ждать, я расскажу кратко ниже.

Приоритизировать можно и нужно что угодно: собственный поток задач, задачки в беклоге, поток требований от Заказчика, поток багов от Куа, поток задач в разработку – короче, все.

Это очередная статья посвященная софтскилам и лайфхакам в управлении, о которых не рассказывают на курсах по менеджменту. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» и читайте другие статьи здесь, на Хабре.

Откуда взялись именно 4 приоритета?

Этот текст я посвящаю Руководителям-нытикам. Его также полезно почитать не только манагерам, он вообще посвящается любителям пострадать на тему несовершенства мира (с позиции совершенства собственного, разумеется).

Так вышло, что вас окружают дебилы.

Сотрудники не понимают, что от них нужно, хотя это должно быть очевидно даже без объяснений и напоминаний. Заказчик – конченный: не понимает очевидных вещей, ругается на ровном месте и вообще – вместо того, чтобы накинуть бюджета и не вставлять палки в колеса, как ему сказали, ходит и че-то там эскалирует про плохого менеджера на стороне исполнителя.
Ваш линейный руководитель, вместо того чтобы утешить и поддержать вас, тоже встает на сторону заказчика.
Руководство вашей компании тянет ее непойми куда, и создается ощущение, что ваша «компания, как курица без головы: бегает, машет лапами, разбрызгивая кровь, но бегать остается недолго» (реальная цитата одного недовольного, кстати).
Процессов нет и работать совершенно невозможно. Или процессы есть, но их много и они не те. Или они есть и те, но их никто не выполняет потому что см название статьи.

Короче: вы один в кольце дураков, и вас никто не понимает.

Бывало что-то подобное?

Тогда поздравляю, вы – ленивая и эгоистичная задница.

Это очередная статья посвященная софтскилам и лайфхакам в управлении, о которых не рассказывают на курсах по менеджменту. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» и читайте другие статьи здесь, на Хабре.

Сегодня предлагаю поговорить горячую тему: а возвращать сотрудников в офис или нет, а если возвращать, то кого и зачем?

Я работаю с удаленщиками еще с 2004 года. Тогда это называлось «распределенная команда», и распределена она была где-то между Мельбурном, Самарой, Тольятти, Москвой и Лондоном. И, хотя все честно ходили в офис по месту пребывания, уже тогда возникал вопрос: а нафига ходить в офис, если главное, чтобы скайп и аська (тогда еще эти слова были популярными) работали, и чтобы было электричество подключить ноут?

С тех пор с распределенными офисами я сталкивался почти на каждом рабочем месте. Картина, когда менеджер и аналитики в офисе, а разработчики фиг знает где, мне стала привычной задолго до ковида. При этом, вплоть до 2020го, весь крупняк по-прежнему требовал присутствия в офисе всей команды, неважно кто ты: разработчик, аналитики или менеджер. Топай в офис.

Потом случился ковид, который уравнял всех, работать из офиса стало запрещено. Удаленка стала обязательной, и большим компаниям пришлось хоть как-то отладить процессы удаленной работы: коммуникации, постановку задач и их контроль. Сделали это все в разной степени успешно. И, насколько я вижу, именно от успешности внедрения процессов выше во многом и зависит ответ: «а звать всех назад или нет?».

Если вас интересуют темы проектного управления, управления командами, и как эти знания структурировать и использовать – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади», а также читайте мои статьи тут, на Хабре (их уже больше 20ти и все на тему управления ИТ командами).

Сегодня будет про культуру ведения тикетов в трекере.

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

Наверное, просто надо один раз написать и потом слать ссылку на текст. Для этого и напишу 😊

Это очередная статья, посвященная софтскилам и лайфхакам, о которых руководителям не рассказывают на курсах по менеджменту. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» и читайте другие мои статьи здесь, на Хабре.

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

Я тут замечаю, как высмеивают на многих досках и каналах Эйчаров, которые задают на интервью вопросы вида: «а кем вы хотите быть через 3-5 лет?».

Помню время, когда я и сам бесился от этого вопроса. Ну камон, откуда я знал, что мне захочется через целых 5 лет: пойти работать в SAP и улететь в Южно-Сахалинск, пойти работать по контракту за бугор или попасть в условный Газ-Тех-Ресурс-пром? А может, что-то другое? Вот что больше денег захочется наверняка – это я знал. Но говорить такое палевно было, очевидно, что ответ неверный.

Тогда какой ответ верный, что надо отвечать на этот вопрос? Что им там хотеть правильно?

С тех пор прошло много лет. Я получил дофига опыта, научился ставить цели на развитие больших отделов и даже компаний, выполнять KPI, стремиться к OKR и вообще узнал много новых и страшных слов, которые перестали меня пугать. И теперь уже я – тот, кто иногда на собеседованиях любит задавать Тот Самый Вопрос.

А еще чаще, в ходе сессий по менторингу, я начал спрашивать другой, но более важный на мой взгляд, вопрос: "А чего ты хочешь?". И вот про эти два вопроса и будет статья дальше.

Если вам интересны темы постановки целей, софтскиллов, менеджерства и Руководства проектами в частности – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» (если еще не подписались) где много подобных историй и подписывайтесь на Хабре.

Сегодня будет сказ о наболевшем для любого Руководителя проектов, да и вообще – для любого участника ИТ команды и их заказчиках – сказ об идеальной и прозрачной системе управления ИТ проектами. Чем пользуется большинство команд, какие боли при этом испытывают и как их решают. Существует ли серебряная пуля – решение, которое удовлетворит всех (спойлер - нет), кто в этом виноват, и что делать?

Почему эта статья? Я вижу, что в область, где я работаю с 2000 года приходит много новичков. При этом сами процессы управления в командах часто не выстроены и даже местами не осознаны (то есть болит, но участники не понимают, что болит и почему). Все пробуют новые подходы, но неизменно наступают на все те же самые грабли, на которые наступало большинство команд, которые я видел за 10-15-20 лет. Количество новичков растет, а качество управления падает. И вот уже возникает ощущение, что большинство ИТ команд выживает как умеет.

Как этому помочь, куда копать, как копать, и есть ли инструмент, который поможет? Я попробую ответить.

Тех, кому интересна тематика проектного управления и управления ИТ командами, я приглашаю на свой ТГ канал «Морковка спереди, морковка сзади», где я рассказываю лайфхаки для менеджеров, которые им не рассказывают на курсах РП, да и вообще делюсь опытом из своей практики.

Итак, статья состоит из четырех частей.

Менеджер должен тащить. Давать срок и попадать в него, как обещал. Если менеджер не тащит — это плохой менеджер. Это очевидно. А что, если менеджер тащит, но не туда? Или по ТЗ тащит туда, но заказчик недоволен? А если менеджер выгорает от того, что к нему каждый день прибегает заказчик с нереальными и плохо описанными задачами, а потом убегает и жалуется руководству, что менеджер отказывается оценивать работы в таком виде?

Эта статья будет про то, как можно помочь вашим заказчикам лучше формулировать требования, а не посылать их нафиг при виде некачественных постановок и быть (а не выглядеть) тем, кто тащит куда нужно и помогает, а не делает вид.

Это очередная статья из цикла статей и постов в моем ТГ канале о жизни менеджеров и необходимых им софтскиллах. Это то, чего обычно руководителям не рассказывают на курсах, но что вам понадобится с самого первого дня его работы. Если тема для вас интересная, подписывайтесь на мой ТГ «Морковка спереди, морковка сзади» и читайте другие мои статьи тут, на Хабре).

Как только вы становитесь Руководителем проектов, да и не только проектов – вообще любым руководителем - список ваших дел начинает расти. Вам больше не ставят задачи в любимой джире по одной, где оценил - сделал. Не. Задачи начинают лететь в вольном формате и неограниченном количестве.

Вы договорились по пяти задачам на сроки готовности? – вам прилетело еще 5, более срочных. Потом еще пара. И еще одна, напоследок, от Генерального. А сделать надо все, от вас ждут.

Это очередная статья посвященная софтскилам и лайфхакам, о которых руководителям не рассказывают на курсах по менеджменту. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» и читайте другие статьи здесь, на Хабре.

Классическое желание новичка – это сделать все, что дали. «Я же хороший, я же должен показать, что меня не зря сделали менеджером, я должен все успеть». Ничего, что для этого надо задержаться до 9ти, разок можно 😊

Самое важное, что характеризует любого менеджера — это то, как он выдерживает собственные обещания. Не то, как он их дает, а то, как выдерживает.

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

Чем он управляет: одной задачей, целым проектом или портфелем проектов на миллиард — пофигу. Слово дал — иди делай, на тебя рассчитывают. Слово дать не можешь? Пойди еще подумай и дай, тебя набрали не для нытья, а для решения проблем.

Это статья про базовый софтскилл который касается и менеджеров и исполнителей: про умение нести отвественность. Если вам интересна тема софтскиллов, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади».

...и должен ли РП уметь писать ТЗ?

Этому холивару, по-моему, ровно столько же лет, сколько лет проектному управлению в IT.

Границы управления проектами просты: инициация - планирование – исполнение – завершение. Это знает даже джун. Сделай устав, план, делай статусы каждую неделю, а потом проведи финальный показ функционала – и твой проект ждет успех. Все так, правда?

Неправда, так не получается. Оказывается, надо провести нормальный сбор требований на базе качественной постановки задачи, сделать качественное ТЗ, затем сделать детальные спецификации, которые потом разложить в to do на разработку и так далее, и так далее.

Для этого есть соответствующие люди. Должны быть. Но они есть не всегда. Или они есть, но они не обладают достаточной квалификацией. И вот тут начинается «серая зона» ответственности РП, где его может выручить умение в «бизнес-аналитику».  Ну или где РП может гордо сказать, что задач по аналитике нет в его должностной инструкции и пусть все идут нафиг, он не нанимался. Как делать лучше?

Это очередная статья о том, чего не рассказывают на курсах РП: о навыках, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Пришло время для самого важного вопроса, встающего перед каждым Руководителем проектов, решающим сменить работу: «Куда мне лучше пойти работать?».

Выбор большой: продукт или ИТ услуги? ИТ услуги в роли Заказчика внутри большой компании или в интеграторе/консультанте в роли Исполнителя? Большая компания, где большая зарплата, соцпакет, стабильность и спортзал или маленький стартап, где хаос, ничего нет, но через пару лет обещают золотые горы?

Эта статья - продолжение предыдущей «Какие бывают Руководители проектов в разных компаниях», где разобрали чем отличается РП в продукте, внутреннем ИТ и внешнем ИТ.
В этой разберем чем отличаются большие компании от маленьких, и так уж ли важно идти в Большую компанию с Модным названием? Ну и, наконец, получим ответ на вопрос: "А куда пойти?"

Это очередная (но важная) статья для Руководителей проектов о том, «как делать хорошо», когда что такое «хорошо» вам никто не объясняет. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Для начала, что делает человек, когда ему приходит мысль сменить работу:

Куда можно пойти поработать, если вы – Руководитель проектов? Есть много сладких названий: Яндекс, Тинькоф, Сбер, Авито, ВК. Есть еще Газ-Нефть-Полиметал-Тех-сырье компании, есть просто ИТ подразделения не ИТ компаний типа Магнита или Технониколь. Есть еще системные интеграторы Т1, IBS, Softline и так далее. Есть ли среди всей этой карусели отличия, и что вы получите, работая в каждой, кроме того что сможете сказать «Я работал в /Name/?

Эта статья посвящена тому, чем работа Руководителя проектов буде отличаться в разных компаниях. Прочитав ее, вы сможете для себя понять, куда лучше пойти, чтобы получить тот опыт, который вы хотите получить, а куда лучше не ходить.

Это очередная статья о том, чего не рассказывают на курсах РП: о навыках, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Статья не претендует на 100% знание истины (опыт у каждого свой), но основана на личном опыте автора, который поработал во многих компаниях, прошел больше сотни собеседований сам и прособеседовал не менее нескольких сотен Руководителей проектов из разных компаний.

Руководитель проекта должен любить людей. И любить с людьми общаться. Потому что к только вы становитесь Руководителем проектов, вам нужно начинать говорить с кучей народа: с командой – это минимум несколько человек, с заказчиками – это тоже часто несколько человек. Еще есть линейный руководитель, руководители команды, руководители заказчиков, релиз менеджеры, инженеры поддержки, внешние эксперты - короче, если вы не любите разговаривать с людьми, если долгое общение вас сильно утомляет, лучше всерьез подумать о какой-то другой работе.

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

Действительно ли надо всегда звонить, а не писать письмо? Какие еще есть варианты?

Как правильно и экологично проводить встречи?

Как не превращать встречи в ППР?

Обо всем этом коротко ниже.

Это очередная статья о том, чего не рассказывают на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Каждый РП рано или поздно меняет работу. Вы уходите со старого места, где вы уже хорошо ориентируетесь, и приходите в неизвестность:

- неизвестный проект с неизвестными рисками;

- непонятный руководитель (при первом знакомстве он душка, но какой будет в реале?);

- непонятные коллеги;

- непонятный заказчик.

Причем, как правило, проект, который вам отдают, уже несется на всех парах: команда пашет, заказчик чего-то хочет, у нового руководителя какие-то ожидания. И хорошо, если все так просто. А часто случается, что проект уже летит в бездну, бюджет израсходован, заказчик всех ненавидит, а руководство ждет от вас сдачи на следующей неделе (да, такие случаи тоже бывали 😊).

Это очередная статья о том, чего не рассказывают на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Выглядит так, что РП, выходящий на новую работу, как пассажир, который пытается запрыгнуть в поезд на ходу, чтобы потом добраться до головы состава и начать им управлять. И чем быстрее летит поезд – тем сложнее в него запрыгнуть. Ну и на все про все у вас примерно 2 недели. 4 от силы, если место ванильное, и поезд еще не разогнался.

Как не свернуть шею и не попасть под колеса на этом славном пути – по пунктам ниже

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

Когда у вас проблемы на проекте, вам хочется прийти к руководителю, выговориться, пожаловаться, чтобы похвалили и сказали, что надо делать. И лучше, чтобы не по телефону, а лично. Если у вас такое было или есть (у меня было, знаю, о чем пишу), знайте: это нормальная человеческая реакция – в сложный момент хочется поддержки, выговориться, обняться и порыдать - но это непрофессиональная реакция. Вы не на сеансе у психолога, вы на работе. Здесь не платят за "послушать, обнять и принять".

Вам придется научиться формулировать вашу проблему определенным образом, чтобы получать результат. Как это делать - под катом.

Это очередная статья о том, чего не расскажут на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Для начинающих Руководителей проектов часто становится новостью, что у них не только новая звонкая должность (руководитель!), зарплата и премия, но и неприятная обязанность отвечать вообще за все неприятности на вверенном проекте.

Эта статья – очередная из цикла статей о том, чего не говорят на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории - читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

То есть я теперь отвечаю не только за себя, но и за тех, кто, вроде бы, сам за себя отвечать должен:

• сотрудник обещал сделать, и не сделал – крайний РП;

• заказчик не сформулировал нормально требования, а теперь не хочет принимать работы – виноват РП;

• руководитель ругается, что работы не сделаны в срок, хотя именно он месяц не согласовывал начало работ – виноват РП;