Школа проектного специалиста

описание

Это сообщество практикующих IT-специластов. Здесь мы делимся опытом управления проектами и автоматизации бизнес-процессов, разбираем реальные кейсы, анонсируем обучения и проводим прямые эфиры. Сотрудничество: @ymin67

← к каналу @techitpm

2 988

подписчиков

Охват к подписчикам

11,5%

ERR

Реакции к просмотрам

0,86%

249 на 50 постов

Пересылки к просмотрам

2,58%

751

Постов в день

1,6

всего 112

Где отзываются чаще

доля реакций к просмотрам

6 авг.без подписи4,34%
26 июл.без подписи2,33%
13 авг.В большинстве компаний есть одна странная немая договорённость. Никто напрямую не говорит друг другу, как на самом деле идёт работа. Есть оценки — раз в месяц или по запросу, есть финансовые показатели, как правило запаздывающие. Еще есть туманные «всё в порядке», «потенциально растёшь», «продолжай в том же духе». А настоящей обратной связи — нет. И ведь это не потому, что люди не хотят знать. Хотят. Каждый менеджер где-то в глубине понимает, что у него есть слабые места. Каждый сотрудник хотел бы услышать честно — что улучшить, что поменять, в какую сторону расти. Но спросить напрямую — почему-то неловко. Как будто это нарушает негласный код. Ты же не хочешь выглядеть неуверенным, правда. Получается замкнутый круг. Руководитель не говорит — потому что «человек сам должен понять» или «не хочу обидеть». Подчинённый не спрашивает — потому что «вдруг подумают, что я не справляюсь». Все вежливы. Все заняты. Все делают вид, что как-то само рассосётся. Но ничто не рассасывается — просто копится. Самое коварное, что отсутствие обратной связи люди часто воспринимают как одобрение. Мол, раз не ругают, значит, всё хорошо. А на самом деле молчание ничего не значит. Иногда оно значит «пойдёт», иногда — «я ещё не решил», иногда — «мне некогда». И человек живёт в тумане интерпретаций, выдумывая себе оценки из ничего. И вот парадокс. Компании тратят огромные деньги на обучение, развитие, ассесменты, тренеров. А простого честного разговора раз в месяц — нет. Хотя он бесплатный. И часто даёт больше, чем любой курс. Потому что рост начинается не с новых знаний, а с понимания, где ты сейчас. А это можно узнать только у других. Если, конечно, попросить. И если тебе ответят.2,15%
5 авг.Как правильные метрики заставляют компанию работать неправильно Странная штука происходит с людьми, когда им ставят чёткую цель. Они начинают в неё попадать. Любой ценой. Даже если сама цель в итоге приносит компании вред. Вот, скажем, отдел поддержки. Поставили метрику — «время ответа клиенту». Отличная же цель, что плохого. И правда ничего, пока через полгода не выясняется, что сотрудники просто шлют отписки в первую же минуту. Формально — ответ дан, метрика закрыта. По сути — клиент в бешенстве. Или продажи. Завели план по звонкам. Менеджеры начинают звонить кому угодно и как угодно, лишь бы набить цифру. Качество разговора, нужен ли клиенту этот продукт вообще — мимо. Главное — отзвонить. Это же не со зла. Люди просто реагируют на то, чем их измеряют. Поставили одно — будут делать одно. Поставили другое — другое. А то, что не измеряется, тихо отмирает, потому что за него никто не отвечает. И вот парадокс. Чем умнее выглядит система метрик на бумаге, тем сильнее риск, что вся компания начнёт под неё подстраиваться. Не под реальность, а под табличку. Потому что табличка простая, а реальность сложная. И людям свойственно выбирать простое. Самое незаметное тут — что никто не задумывается, чего именно мы на самом деле хотим. Быстрого ответа или решённой проблемы? Звонка или продажи? Цифры или результата? Это разные вещи. И если их перепутать — метрика начнёт работать против тебя, очень старательно и очень послушно.2,01%
22 июл. 2025 г.Если вы ответили, что: – сталкиваетесь с хаосом, – действуете интуитивно, – хотите научиться управлять изменениями системно. То курс «Управление изменениями» — для вас. Преподаватель: Маргарита Карки, Senior Change Transformation Manager 🔣 Запись ➡️ тут #курс #управлениеизменениями #ADKAR #eprlab #проектныйменеджмент #softskills1,87%
10 авг.🌉 Когда разработчик становится архитектором (и почему это больно) Переход из разработки в архитектуру выглядит как повышение. Деньги, статус, уважение. На деле — один из самых тяжёлых переходов в карьере, потому что меняется почти всё. Не должность, а профессия. И многие не готовы к тому, насколько это больно. Давайте честно разберёмся, что происходит с человеком, который «стал архитектором», и почему этот путь нередко заканчивается выгоранием или возвратом обратно в код. Главный шок: ты больше не делаешь В разработке главное удовольствие — видеть результат. Написал, запустил, работает. Моментальная обратная связь, понятный результат, чувство «я сделал это». Архитектор так не работает. Архитектор не пишет код — он его проектирует, описывает, объясняет. Результат его работы появляется через месяцы, а иногда и годы. И чаще всего — в чужом исполнении, которое отличается от задуманного. Это первый и самый тяжёлый шок: ты больше не видишь свой результат сразу. Ты видишь его через призму чужих рук, чужого понимания, чужих ошибок. Многих это ломает. Человек скучает по коду, возвращается «помочь», начинает писать сам — и превращается либо в помеху, либо в «главного разработчика с приставкой архитектор». Ни то, ни другое — не архитектура. Второй шок: ответственность без власти Архитектор отвечает за систему в целом. Но не он нанимает людей, не он ставит сроки, не он решает, что войдёт в очередной выпуск. Он советует, рекомендует, предупреждает. А решения принимают другие. И если решение оказалось неверным — отвечать тоже ему, потому что «он же архитектор, должен был предусмотреть». Это классическая ловушка: ответственность есть, власти — ограниченно. Умение жить в этом напряжении — один из главных навыков архитектора. И он не врождённый. Третий шок: ты работаешь не с кодом, а с людьми В разработке люди — помеха, отвлекающая от кода. В архитектуре — наоборот. Главная работа архитектора — это не диаграммы и схемы. Это переговоры. С разработчиками, которые не понимают, зачем так. С руководителями, которые хотят «проще и быстрее». С заказчиками, которые не понимают, почему «просто кнопку» нельзя сделать без перестройки половины системы. Знаете, что самое тяжёлое? Доказывать очевидное. Архитектор видит риски, которые другие не видят. И объяснять эти риски людям, которые хотят «быстрее и проще», — отдельное искусство. Многие талантливые разработчики, став архитекторами, не справляются именно с этим — не с технической частью, а с человеческой. Четвёртый шок: цена ошибки возрастает на порядки Ошибка разработчика стоит часов или дней. Ошибка архитектора стоит месяцев или лет. Неверное решение на уровне архитектуры может проявиться через год, когда уже всё построено на этом решении, и «переделать» стоит как новый проект. Это тяжёлое давление. Архитектор живёт с постоянным ощущением: «а что, если я не прав?». И в отличие от разработчика, не может быстро проверить — результат проявится нескоро. Что помогает Признать, что переход — это не «продолжение разработки на новом уровне», а смена профессии. С другими навыками, другим складом ума, другим удовольствием от работы. Учиться переговорам, а не только технологиям. Архитектор, который не умеет объяснить и защитить своё решение — бесполезен. Даже если он технически гениален. Найти себе наставника. Человека, который прошёл этот путь и может поделиться опытом. Университетского курса «как стать архитектором» не существует. Реальный опыт — бесценен. И, главное, — не пытаться быть и разработчиком, и архитектором одновременно. Это разные роли. Выберите одну и выполняйте её полноценно. Вывод Архитектор — не «разработчик рангом выше». Это другая профессия. С другими радостями и другими болями. Переход тяжёлый, но если пройти его честно — он открывает уровень влияния, недоступный разработчику. Влияния на то, как система будет работать не сегодня, а через пять лет. Если вы в этом переходе — потерпите. Если думаете о нём — взвесьте. Это не повышение. Это смена пути. Ссылки и контакты Есть еще наш канал в MAX. #архитектура #карьера #разработка #софт_скиллы #практика1,57%
24 июл.🔥 РП, который не горит: как перестать быть пожарным Есть два типа руководителей проектов. Один утром открывает ноут и не знает, что его сегодня ждёт — какой факел вспыхнет, какой срыв подкрался, какой заказчик опять «всё передумал». Второй утром открывает ноут и примерно представляет, что будет — потому что сам это распланировал. Первого мы называем пожарным. Второго — хозяином проекта. Честно говоря, большинство из нас начинают как пожарные. Мне кажется, это даже в какой-то степени нарабатывается как доблесть. «Я спас проект», «мы вытянули релиз за выходные», «без меня всё бы рухнуло». Звучит героически, окружение кивает, руководство ценит. А потом ты оглядываешься и понимаешь: ты не управляешь проектом. Ты управляешь пожарами. И если убрать твои ночные подвиги — ничего не работает, потому что системы нет. Парадокс в том, что хороший РП — это скучный РП. У него редко что-то «горит», потому что он выстроил привычки, которые не доводят до пожара. Горящий срок — это не свойство профессии, это симптом. Сигнал, что где-то не сработало раннее обнаружение. Давайте про привычки. Не про Jira и не про диаграммы Ганта — это инструменты, они вторичны. Про то, как мыслить. Первая привычка — ловить отклонения рано. Не когда задача уже просрочена на неделю, а в первый день, когда она начала буксовать. Разница между «мы уже отстали» и «мы только начали отставать» — это разница между авралом и корректировкой. Для этого нужен регулярный, честный статус по задачам. Не «всё нормально, работаем», а «вот тут застряли, вот тут ждем, вот тут рискованно». Многие РП боятся поднимать тревогу заранее — кажется, что это признак слабости. Наоборот. Молчание до последнего — это слабость. Вторая — держать буфер. И в сроках, и в ресурсах, и в своих собственных силах. План, в котором каждый час расписан и нет ни одного свободного дня — это не план, это катастрофа с отложенным запуском. Что-то всегда идёт не так: кто-то заболел, заказчик не дал данные, интеграция не взлетела с первого раза. Если буфера нет — первый сбой превращается в пожар. Если есть — в рабочую ситуацию. Третья — отдельный тайм-бокс на «непредвиденное». Грустная правда: непредвиденное предвидеть нельзя по определению. Но можно зарезервировать под него время. Час в день на разбор полётов, ответы на срочное, штормовые вопросы команды. Если этот слот не заложен — «срочное» начинает съедать плановые задачи, и вот ты уже не РП, а диспетчер, который мечется от одного вызова к другому. Четвёртая — регулярные точки сверски, даже когда «всё хорошо». И особенно когда «всё хорошо». Команда часто молчит, когда всё нормально — и молчит до тех пор, пока что-то не сломается. Регулярный короткий статус, даже пустой по содержанию, держит связь. Ты узнаёшь о проблеме на этапе «что-то странно», а не «всё горит, помогите». И пятая, наверное, самая неудобная — уметь отказывать. Не каждый скоуп-крип растёт бесконечно. Не каждая просьба заказчика должна идти в текущий спринт. РП, который не умеет сказать «это пойдёт в следующий релиз, не сейчас» — это РП, у которого потом горят сроки. Отказывать — это не конфликтовать. Это защищать проект от перегрузки, которая всё равно вылезет боком. Знаете, что самое трудное во всём этом? Изменить собственную самооценку. Перестать ассоциировать себя с тем, кто «всегда спасает». Хороший РП часто выглядит так, будто у него мало работы. Потому что пожаров нет. А когда нет пожаров — кажется, что и толку от него мало. Это ловушка, в которую попадают и сами РП, и их руководители. Цените тех, у кого скучно. Скорее всего, именно они и делают так, чтобы всё работало. #менеджмент #РП #проектная_команда #практика #управление_проектами1,55%
8 июл. 2025 г.без подписи1,52%
11 авг.📖 Документация, которую реально читают Знаете, какой документ в проекте читают реже всего? Тот, который написали «потому что надо». Толстый, подробный, с красивым оглавлением — и мёртвый. Потому что его никто не открывает, кроме автора. И когда новенький приходит, он всё равно спрашивает у коллег, а не лезет в документацию. Почему так — давайте разберёмся. Потому что большинство документации пишется не для людей. Она пишется для проверяющего, для отчёта, для «ну обязаны же быть регламенты». И получается текст, который формально есть, а фактически — мёртв. Почему документация умирает Первая причина — пишет не тот, кто делает. Документацию часто поручают «специальному человеку», который не работает с системой напрямую. Он переписывает то, что ему объяснили, в красивую форму. Получается аккуратно — но оторвано от реальности. Через полгода документ не соответствует тому, как всё работает. Вторая — не обновляется. Написали в год внедрения. Потом система меняется, дорабатывается, перестраивается. Документация — нет. Через два года она бесполезна. Все это знают, но никто не обновляет, потому что «некогда» и «вроде и так работают». Третья — пишет для себя. Автор документирует то, что ему кажется важным. А читателю нужно другое: не «как устроено», а «как мне сделать мою работу». Разница огромная. Один пишет про архитектуру, другой ищет «как создать документ». Оба правы. Но второй не находит. Что делает документацию живой Живая документация — это не та, что написана идеально. Это та, которую открывают, когда надо что-то сделать, и находят ответ. Вот что отличает её от мёртвой. Пишет тот, кто делает. Не «документалист», а человек, который сам работает с системой. Он знает, какие вопросы возникают, какие шаги непонятны, где люди спотыкаются. Его текст — не литература, но он правильный. Потому что написан изнутри, а не снаружи. Обновляется по ходу. Не «раз в год большим обновлением», а по мере изменений. Изменился процесс — изменили документ. Добавили функцию — добавили описание. Документация — часть работы, а не отдельный проект. Структурирована под задачу, а не под систему. Не «раздел Справочники → подраздел Контрагенты → пункт Создание». А «Как завести нового контрагента: три шага». Люди ищут действия, а не архитектуру. Возвращайте им действия. Короткая и конкретная. Лучше пять строк, которые отвечают на вопрос, чем пять страниц, которые надо прочитать целиком, чтобы найти одну крупицу. Стереотип «хорошая документация — это толстая» в корне неверен. Хорошая документация — это та, которую можно прочитать за минуту. Практичные форматы, которые работают Не всё нужно описывать текстом. Иногда другой формат работает лучше. • Пошаговые инструкции. «Сделай это, потом это, проверь вот это». Короткие, с конкретными шагами. Идеально для рутинных операций. • Скринкасты. Три минуты видео, где показано, как сделать задачу, заменяют десять страниц текста. Особенно для новичков. • Чек-листы. Для процессов, где важно не забыть шаги. Не описание, а список «отметил — сделал». • FAQ. Сборник реальных вопросов, которые задавали люди, с ответами. Живой документ, который пополняется. Онбординг как тест документации Лучший способ проверить, работает ли ваша документация — посадить новичка и попросить сделать задачу, пользуясь только документами. Если он справился — документация живая. Если постоянно спрашивает — мёртвая. Это не проблема новичка. Это проблема документации. И это самый честный тест. Вывод Документация — не «обязательная часть проекта». Это инструмент, который либо помогает людям работать, либо валяется мёртвым грузом. Разница — не в объёме, а в подходе. Пишет тот, кто делает. Обновляется по ходу. Структурирована под действия, а не под систему. Короткая и конкретная. Мёртвая документация съедает время на написание и не возвращает ничего. Живая — экономит время на вопросы, обучение, ошибки. И становится тем, ради чего её и пишут: надёжным способом передачи знаний. #документация #проектная_команда #практика #РП #аналитика1,45%
14 авг.Что сегодня зависит от меня? Утро современного человека начинается не с восхода солнца. Оно начинается с чужих проблем. Телефон ещё толком не сфокусировался перед глазами, а там уже всё готово: кто-то прислал сообщение в 7:14, рабочий чат успел обсудить срочный вопрос, новости сообщили о новой причине тревожиться, а приложение заботливо напомнило о делах, которые вы вчера не сделали. Прошло минут пять. Вы ещё лежите в кровати, но мысленно уже присутствуете на совещании, спорите с незнакомым человеком и немного переживаете за мировую экономику. День ещё не начался, а внимание уже разобрали. И вот здесь неожиданно полезным оказывается человек, который жил почти две тысячи лет назад и не знал ни рабочих чатов, ни push-уведомлений. У Марка Аврелия тоже было кому испортить утро. Марк Аврелий был римским императором. Поэтому совет «просто не обращай внимания на неприятных людей» подходил ему примерно так же, как современному руководителю совет отключить корпоративную почту. Люди всё равно приходили. Со своими просьбами, интригами, претензиями, конфликтами и удивительной способностью создавать проблемы именно тогда, когда проблем уже достаточно. В «Размышлениях» Марк Аврелий заранее напоминает себе, что в течение дня встретит людей назойливых, неблагодарных, высокомерных, коварных, завистливых и неуживчивых. В каком-то смысле это очень древняя версия утреннего просмотра рабочего календаря. Только вместо того чтобы удивляться: «Ну почему они опять такие?», можно задать себе другой вопрос: «Что сегодня зависит от меня?» Вопрос подозрительно простой. Поэтому его легко принять за очередную красивую фразу для картинки с рассветом. Проблема только в том, что применять его гораздо труднее, чем опубликовать. Начальник сегодня не в настроении Допустим, утром руководитель недоволен вашей работой. Можно провести несколько часов, мысленно доказывая ему, что он неправ. Потом пересказать разговор коллеге. Потом ещё раз воспроизвести его вечером дома, уже с улучшенными репликами, которые почему-то не пришли в голову во время разговора. Есть только небольшая неприятность: настроение начальника всё это время остаётся его настроением. Вашими остаются ответ, аргументы и дальнейшие действия. Это не означает, что нужно соглашаться со всем подряд. Стоицизм вообще довольно странно превращать в искусство терпеливо кивать. Речь о другом. Можно спорить о решении, не пытаясь управлять чужой головой. А это две очень разные задачи. Особенно трудно не управлять интернетом Кто-то написал неприятный комментарий. Человек находится неизвестно где, возможно, уже забыл о своём комментарии и спокойно пьёт кофе. А вы продолжаете беседу. Сначала в голове. Потом открываете комментарий ещё раз. Потом придумываете особенно точный ответ. Потом решаете не отвечать. Через двадцать минут всё-таки отвечаете. Незнакомый человек потратил на вас полминуты. Вы выделили ему вечер. В этот момент вопрос «что зависит от меня?» становится почти бухгалтерским. Чужое мнение? Нет. Удалить из мира людей, которые думают неправильно? Пока соответствующий функционал не выпущен. Решить, сколько собственного внимания отдать чужому мнению? Вот это уже ближе. Планы обладают неприятным свойством не спрашивать нашего разрешения Самолёт задержался. Клиент перенёс встречу. Сотрудник заболел. Подрядчик обещал прислать документ вчера и теперь почему-то «уточняет у коллег». Особенно раздражает последняя категория событий. Ведь план был хороший. Иногда даже в Excel. А хороший план в Excel создаёт особое чувство: кажется, что реальность теперь юридически обязана ему соответствовать. Не обязана. Можно сколько угодно злиться на сорванную встречу, но вернуть её в календарь силой раздражения не получится. Зато остаётся следующий ход: перенести задачу, предупредить людей, изменить последовательность работ, пересчитать последствия. Не самая эффектная философия. Зато рабочая. Мы вообще любим контролировать то, что нам не принадлежит Чужие решения. Чужие эмоции. Репутацию. Погоду. Рынок. Реакцию клиента. Прошлое. Особенно прошлое. Это, пожалуй, один из самых странных объектов человеческого управления.1,42%
7 нояб.без подписи1,36%
23 июл.без подписи1,33%