Управление проектами *

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

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

Изменения являются неотъемлемой частью современного рабочего мира и касаются всех отраслей. Так уж повелось, что в ИТ изменения явление довольно частое (гибкость и все такое): они могут быть инициированы событиями планетарного масштаба или, например, связанными с изменением в руководстве.

На управленца-новичка сваливается масса забот. И дело не только в ином уровне ответственности и новых, более значительных бизнес-целях. Главная сложность – люди в команде. 

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

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Если вы не понимаете бизнес своей компании, вы не сможете полностью реализовать свои технические навыки. Крутой технарь на позиции СТО, который знает нюансы TOGAF и отличия Raft от Paxos — это хорошо, но мало. Вы должны принимать решения не только исходя из технических деталей задачи, но и с учётом реалий бизнеса, его потребностей и направления развития.

Меня зовут Олег Федоткин, я СТО компании Циан. В этой статье расскажу, почему понимание бизнеса так важно для ИТ-менеджеров, тимлидов и архитекторов, и как оно влияет на принятие технических решений и развитие карьеры. Больше и чаще на подобные темы я пишу в свой ТГ-канал «Инженер и Менеджер».

Кому будет полезна статья:

Менеджерам в ИТ: тим-/юнит-лидам, руководителям направлений и СТО. Без понимания бизнеса у вас не получится построить карьеру — это аксиома.

Специалистам выше уровня senior: staff-/principal-инженерам и архитекторам для выработки полезных для компании технических решений.

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

Что с ними не так? Предлагаю разобраться в причинах и следствиях.

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

Продолжу рассказывать что нужно для проведения успешной трансформации

Как у всех появилась зацикленность на количественных показателях? Почему даже ошибочным цифрам верят больше, чем суждениям профессионалов?

Сегодня мы поговорим о таком интересном вопросе, как переход от Agile, к анти‑Agile. С течением времени команды часто сталкиваются с ситуациями, когда идеалы Agile начинают давать сбой, и приходит осознание, что работа по старым лекалам уже не приносит тех результатов, на которые мы рассчитывали.

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

Но давайте честно: Agile не идеален. На поздних стадиях разработки он может превращаться в настоящую головную боль. На этом этапе проект становится сложнее, требования начинают накладываться друг на друга, а команды, вместо того чтобы работать слаженно, часто начинают сталкиваться друг с другом. Сложно сосредоточиться на техническом долге, когда у тебя в голове только «первый спринт», «планирование» и «обсуждения».

Бывает такое, что на вашем проекте есть эксперт, от которого вам надо получить ОК на документацию, или чтобы он сделал важную работу, которая находится на критическом пути проекта. И, внезапно, этот эксперт делать вашу свою работу и давать вам ОК вообще не торопится. Что с ним делать?

Бывает такое, что на проекте произошла неприятность, требующая немедленного извещения вашего руководителя или Заказчика, а те не отвечают? А время идет и вы понимаете, что в бездействии обвинят вас, РП, ведь именно вы должны были всех оповестить. Что делать в этой ситуации?

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

Давайте разберёмся, для чего нужен WBS, что в нём должно быть, как он может выглядеть и какую пользу приносит.

Для наглядности я постепенно буду оформлять и заполнять WBS в Google Sheets и делиться скриншотами. В конце статьи вы найдёте ссылку на готовый шаблон для скачивания.

Какой бы сложной ни был проект, его декомпозиция на управляемые части поможет лучше понимать объём работы, правильно оценивать задачи и контролировать процесс. Главное — адаптировать структуру под свои задачи и не бояться углубляться в детали, когда это нужно.

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

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

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

Начало здесь https://habr.com/ru/articles/847700/

Численность и зрелость команд

Дефицит ресурсов

Влияние зрелости и структуры на успех

В условиях ускоряющейся цифровой трансформации компании стремятся применять гибкие подходы управления проектами, которые могут масштабироваться для крупных программ и портфелей проектов. Scaled Agile Framework (SAFe) является фреймворком, разработанным специально для масштабирования Agile на уровне всей организации. Однако, для эффективного внедрения SAFe, необходимо адаптировать процессы управления проектами, что подразумевает перестройку проектного офиса, внедрение инструментов, метрик и подходов, необходимых для работы с большими программами.

Попробуем порассуждать над аспектами развертывания проектного офиса под SAFe, с акцентом на применение PMBOK - овского "Шестиугольника управления проектами", включая описание методологии, ролей, документов и инструментов. Приглашаю обсудить описание взаимосвязей между этими элементами и их применение для построения успешной структуры управления проектами в комментариях.

Аналитики прогнозируют рост объёмов рынка аутстаффинга ИТ-персонала на 18% до 265 млрд рублей в 2024 году по сравнению с прошлым годом. Для ИТ-компаний это замечательная новость — потенциально они смогут увеличить финансовые результаты на 20-25%.
А как быть клиентам, которые хотят получить от поставщика не обещания, а реальные результаты?
В этом материале оценим, как изменились требования клиентов к услуге, поговорим о продуктовом аутстаффинге в ИТ и о трендах в работе агентств на 2025–2027

Я написал статью, свои мысли по поводу AI Ecom Ассистента.

Зачем? Причины аж четыре:

1. В наше время LLM и крутых ребят, которые двигают эти технологии в массы, многие думают как это использоваться. Я тоже не смог не подумать про это и думал как такой проект можно запустить. Быстро понял, что сделать это хорошо доступно только когда у тебя есть доступ к большим ресурсам и мозгам.

2. Подумал, что не плохо было бы найти команду/компанию, у которой есть ресурсы и планы делать такого ассистента. Ну и лучшее, что может сделать продакт — это написать свои мысли как он это видит и как это должно работать.

3. Мне давно очень хотелось применить подход Amazon к написанию документов PRFAQ. Это я и постарался применить в написании этой статьи.

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

Привет, Хабр! Меня зовут Миша Шлыков, я менеджер проектов в диджитал-продакшене Далее . Уже два года мы вместе с «Национальными приоритетами» развиваем сайт наука.рф. За это время 30 миллионов человек поучаствовали в проектах Десятилетия науки, а делают его простые люди со всей России. В статье рассказываю о том, как проект добавил +100 к пониманию пользователей с низкой компьютерной грамотностью.

Привет, Хабр! На связи отдел внедрения BIM и отдел сопровождения и поддержки из ПИК.

ПИК — компания с большим опытом в информационном моделировании BIM. Мы решили рассказывать об этом в блоге – и начнём с вводной статьи про то, что такое BIM как технология и какую пользу она приносит девелоперам и специалистам.

Все мы сталкиваемся с проблемами и идем к своему руководителю (менеджеру / ведущему аналитику, если вы джун / куратору итд), чтобы получить решение наших проблем. Как обычно это происходит? Приходим, обрисовываем проблему, руководитель слушает и говорит, что нужно делать. Вы рады? Конечно, проблема решена.

Но в долгосрочной перспективе ничего хорошего такой подход не принесет:

Надо ли говорить на работе о том, что для сотрудника важно и как это делать, чтобы потом не было мучительно больно?

Статья навеяна вот этой статьей на Хабре: https://habr.com/ru/articles/846700/ (почему не надо оставлять честную обратную связь).

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

Руководителя винить здесь бесполезно: руководитель - не штатный психолог компании, он не папка (или не мамка) сотрудникам, который должен учить их жизни, лечить и помогать. Нет. Все, что надо руководителю – это выполнить цели компании, и чтобы команда не разбежалась после этого. Это все. Руководитель не отвечает за моральное и психологическое состояние сотрудников. Это ответственность самих сотрудников**

Но как правильно отвечать на давление? Как правильно и, как сейчас модно говорить, экологично отвечать, когда вы чувствуете, что вас используют, не предлагая ничего стоящего взамен?

Вот про это и предлагаю поговорить ниже.

Жил был на свете Парень. Программист, женат, 2-е детей, старший Сын учится в Новосибирске в университете.

 У Парня есть возможность взять ИТ-ипотеку под 6%. И они с Женой решили взять Сыну хорошую квартиру в Новосибирске: пусть делает с ней что хочет, но квартира сразу приобретается как высокорентабельный объект. 

Парень подошел к решению задачи как программист.

Когда строишь бизнес на новом рынке, один из ключевых вызовов - создать видение своего продукта, который найдет свой PMF (Product-Market Fit).

На своем опыте рассказываю о том, как определить проблему и создать для нее решение, которое действительно будет решать проблему пользователей.