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

Опытный часто не думает. Он вспоминает. Это разные вещи Опыт — штука вообще полезная. Без него никуда. Но есть у него одна особенность, которую мы не всегда понимаем. Чем больше у человека опыта, тем хуже он видит то, что не вписывается в его картину мира. Знакомая картина: кто-то в команде предлагает новую идею. Молодой сотрудник, стажёр, вообще кто-то с периферии. И опытный руководитель — с уверенностью, достойной лучшего применения — объясняет, почему это не сработает. «Мы это уже пробовали», «так не делается», «поверь моему опыту». Дело тут не в злости и не в глупости. Просто за годы складывается набор готовых ответов. Мозг экономит энергию, достаёт решение из памяти, и вот — ответ готов. Быстро, уверенно, почти без усилий. Проблема в том, что эти ответы были верны для другой ситуации. А мир успел поменяться. Самое коварное, что опытный человек этого даже не замечает. Ему кажется, что он думает. А на самом деле он вспоминает. Разница колоссальная, но снаружи она почти не видна — и звучит одинаково уверенно. И вот что странно. Часто самые свежие решения приходят от тех, кто меньше всего «в теме». Не потому что они умнее. А потому что у них нет готовых ответов — им приходится думать заново. И иногда это единственный способ увидеть то, что опытный взгляд давно перестал замечать.

«Разбирайся сам» — фраза, выдающая за доверие Все ругают микроменеджеров. Типа, душат, контролируют, стоят над душой — понятно, плохо. Но есть и обратная крайность, о которой почему-то почти не говорят или не видят. Это руководитель, который «даёт полную свободу». Звучит ведь прекрасно, как мечта любого сотрудника. Только на деле всё выходит немножко не так. Свобода без поддержки — это не свобода, а просто бросание на произвол. Сотрудник приходит с вопросом, а ему: «разбирайся сам, ты же взрослый». Просит рамку решения — «прояви инициативу». Жалуется, что завяз в согласованиях, — «учись договариваться». И человек уходит разбираться сам. С тем же набором проблем, но уже без всякой поддержки. И вот что странно. Внешне это выглядит как доверие. Начальник спокойный, не лезет, «верит в команду». На самом же деле — он просто не делает свою работу. Потому что руководитель — это не только про то, чтобы не мешать. Это про то, чтобы убирать препятствия, давать направление, быть подстраховой, когда человек заходит в тупик. А не прятаться за красивым словом «самостоятельность». Самое смешное, что такие руководители часто искренне считают себя прогрессивными. Мол, не душим людей, как в старые времена, развиваем автономность. А команда тем временем тонет. Решения принимаются наугад, потому что спросить не у кого. Конфликты копятся, потому что их некому разрулить. Люди недовольны оттого, что тянут то, что тянуть не должны. И здесь парадокс. Между «душить контролем» и «бросать на произвол» есть огромная середина. Она называется «быть доступным». Не стоять над плечом, но и не исчезать. Дать рамку, а внутри неё — свободу. Подстраховать на развилке, а не решать за. Это сложнее, чем выбрать крайность. Зато и работает.

Дайджест «Школы менеджера организации» за 10–16 августа На прошлой неделе на канале говорили об управленческой информации, мотивации команды, анализе конкурентов, одиночестве руководителя и моделировании бизнес-процессов. 📌 Информация, которая делает бизнес умным (а не просто учётным) Почему данные не должны оставаться цифрами в отчётах: управленческая информация помогает замечать изменения, понимать причины происходящего и принимать решения на основе реальной картины, а не привычки. 🏃 Мотивация не работает, когда никто не понимает, куда бежать Корпоративные призывы к вовлечённости не заменяют ясные цели и устойчивые приоритеты. Команде сложно сохранять энергию, если направление меняется каждую неделю, а смысл работы остаётся неясным. 🔎 Как цифровые технологии помогают разбираться в рынке и конкурентах Какие цифровые инструменты позволяют отслеживать рынок, действия конкурентов и изменения в поведении клиентов — и почему даже самые подробные данные не отменяют экспертную оценку. 🎥 SADT: как моделировать сложные системы и бизнес-процессы Видео о методологии SADT: как с помощью функциональных моделей, блоков и связей описывать сложные системы, декомпозировать процессы и видеть логику их работы. 🧭 Одиночество руководителя: о чём не говорят на MBA Чем выше позиция руководителя, тем сложнее находить пространство для честного разговора о сомнениях и рисках. Материал о том, как управленческое одиночество влияет на решения, команду и самого лидера. Сохраняйте подборку и делитесь с коллегами, которым важны управление, развитие команд и работа с бизнес-процессами.

Дайджест «Школы проектного специалиста» за 10–16 августа На прошлой неделе говорили о том, как начинать проекты с понятной бизнес-целью, развивать систему после MVP, фиксировать границы работ и выстраивать коммуникацию между участниками ИТ-проекта. 🔍 «Сделайте нам нормально»: что не так с этой просьбой клиента Почему разговор о внедрении 1С или ERP стоит начинать не со списка доработок, а с ответа на вопрос: какой результат нужен бизнесу. Без общей цели у подразделений быстро появляются разные ожидания от одного проекта. 🚙 Жизнь после MVP: почему мы пересаживаемся с поезда на джип После запуска минимально жизнеспособного продукта появляются реальные данные, обратная связь и новые приоритеты. Автор объясняет, почему дальнейшее развитие ERP не всегда стоит вести по жёсткому ТЗ и как сохранить контроль над изменениями и бюджетом. 🚀 Набор на курс «Школа руководителя проекта» с обновлённой программой Анонс нового потока курса для тех, кто хочет выстроить целостную систему управления проектами: от запуска и работы с требованиями до рисков, команды, изменений и взаимодействия с заказчиком. 🗣 Научитесь договариваться в ИТ-проектах: интенсив по деловым коммуникациям Практический двухнедельный интенсив о том, как выявлять потребности, аргументировать решения, фиксировать договорённости и снижать потери времени из-за разночтений между заказчиком, аналитиком и разработчиком. 📐 Границы и ценность проекта Видео о том, как определить содержание проекта, зафиксировать ограничения, допущения и критерии приёмки, чтобы не допустить неконтролируемого расширения работ. 💬 Когда слова говорят одно, а поведение — другое: ловушки общения, которые разрушают отношения Видео о двойных посланиях — ситуациях, когда слова расходятся с интонацией, жестами или действиями. Внутри — способы замечать такие противоречия, задавать уточняющие вопросы и снижать риск конфликтов. Сохраняйте подборку и делитесь с коллегами, которым важны управление проектами, коммуникации и развитие ИТ-систем.

🔥 Делимся опытом впечатлениями! «Школа руководителя проектов» — один из флагманских курсов, за который мы регулярно получаем благодарность! А вы еще успеваете присоединиться к новой группе! Старт 24 августа — регистрируйтесь на сайте.

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

Что сегодня зависит от меня? Утро современного человека начинается не с восхода солнца. Оно начинается с чужих проблем. Телефон ещё толком не сфокусировался перед глазами, а там уже всё готово: кто-то прислал сообщение в 7:14, рабочий чат успел обсудить срочный вопрос, новости сообщили о новой причине тревожиться, а приложение заботливо напомнило о делах, которые вы вчера не сделали. Прошло минут пять. Вы ещё лежите в кровати, но мысленно уже присутствуете на совещании, спорите с незнакомым человеком и немного переживаете за мировую экономику. День ещё не начался, а внимание уже разобрали. И вот здесь неожиданно полезным оказывается человек, который жил почти две тысячи лет назад и не знал ни рабочих чатов, ни push-уведомлений. У Марка Аврелия тоже было кому испортить утро. Марк Аврелий был римским императором. Поэтому совет «просто не обращай внимания на неприятных людей» подходил ему примерно так же, как современному руководителю совет отключить корпоративную почту. Люди всё равно приходили. Со своими просьбами, интригами, претензиями, конфликтами и удивительной способностью создавать проблемы именно тогда, когда проблем уже достаточно. В «Размышлениях» Марк Аврелий заранее напоминает себе, что в течение дня встретит людей назойливых, неблагодарных, высокомерных, коварных, завистливых и неуживчивых. В каком-то смысле это очень древняя версия утреннего просмотра рабочего календаря. Только вместо того чтобы удивляться: «Ну почему они опять такие?», можно задать себе другой вопрос: «Что сегодня зависит от меня?» Вопрос подозрительно простой. Поэтому его легко принять за очередную красивую фразу для картинки с рассветом. Проблема только в том, что применять его гораздо труднее, чем опубликовать. Начальник сегодня не в настроении Допустим, утром руководитель недоволен вашей работой. Можно провести несколько часов, мысленно доказывая ему, что он неправ. Потом пересказать разговор коллеге. Потом ещё раз воспроизвести его вечером дома, уже с улучшенными репликами, которые почему-то не пришли в голову во время разговора. Есть только небольшая неприятность: настроение начальника всё это время остаётся его настроением. Вашими остаются ответ, аргументы и дальнейшие действия. Это не означает, что нужно соглашаться со всем подряд. Стоицизм вообще довольно странно превращать в искусство терпеливо кивать. Речь о другом. Можно спорить о решении, не пытаясь управлять чужой головой. А это две очень разные задачи. Особенно трудно не управлять интернетом Кто-то написал неприятный комментарий. Человек находится неизвестно где, возможно, уже забыл о своём комментарии и спокойно пьёт кофе. А вы продолжаете беседу. Сначала в голове. Потом открываете комментарий ещё раз. Потом придумываете особенно точный ответ. Потом решаете не отвечать. Через двадцать минут всё-таки отвечаете. Незнакомый человек потратил на вас полминуты. Вы выделили ему вечер. В этот момент вопрос «что зависит от меня?» становится почти бухгалтерским. Чужое мнение? Нет. Удалить из мира людей, которые думают неправильно? Пока соответствующий функционал не выпущен. Решить, сколько собственного внимания отдать чужому мнению? Вот это уже ближе. Планы обладают неприятным свойством не спрашивать нашего разрешения Самолёт задержался. Клиент перенёс встречу. Сотрудник заболел. Подрядчик обещал прислать документ вчера и теперь почему-то «уточняет у коллег». Особенно раздражает последняя категория событий. Ведь план был хороший. Иногда даже в Excel. А хороший план в Excel создаёт особое чувство: кажется, что реальность теперь юридически обязана ему соответствовать. Не обязана. Можно сколько угодно злиться на сорванную встречу, но вернуть её в календарь силой раздражения не получится. Зато остаётся следующий ход: перенести задачу, предупредить людей, изменить последовательность работ, пересчитать последствия. Не самая эффектная философия. Зато рабочая. Мы вообще любим контролировать то, что нам не принадлежит Чужие решения. Чужие эмоции. Репутацию. Погоду. Рынок. Реакцию клиента. Прошлое. Особенно прошлое. Это, пожалуй, один из самых странных объектов человеческого управления.

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

⛔️ Проекты буксуют из-за коммуникации. Согласитесь, эти бесконечные уточнения в переписке, размытые технические задания, необоснованные уступки съедают не только время, но и экономическую эффективность работы. Мы запускаем интенсив «Деловые коммуникации для ИТ-специалиста» — практико-ориентированный курс, где за 2 недели и 4 живые встречи вы получите конкретные инструменты: → Техники активного слушания для выявления истинных потребностей заказчика → Презентации ИТ-продуктов на языке выгод по методике BOMBER-B → Переговоры по модели Томаса-Килмана → Автоматизация деловой переписки через ИИ-ассистентов с готовой библиотекой промптов ✅ Результат: паспорт компетенций, чек-листы, шаблоны и сокращение времени на рутину до 5–10 часов в неделю. 🧑‍💻 Для аналитиков, разработчиков, менеджеров по продажам, КАМов и администраторов проектов. 👉 Все подробности и заявка: на сайте #IT #softskills #деловыекоммуникации #обучение

🚀 Старт уже через 2 недели! Новый поток авторского курса «Школа руководителя проекта» с обновленной программой! Что вас ждёт: 🔹 2,5 месяца интенсивной практики по стандартам PMBOK 🔹 Разбор реальных IT-проектов, а не абстрактных теорий 🔹 Инструменты, которые можно внедрить с первого занятия 🔹 Обратная связь от преподавателей-практиков Этот курс для вас, если вы: ▫️ хотите систематизировать опыт в проектном управлении ▫️ чувствуете, что проекты «едут» не так, как планировалось ▫️ готовы выйти на новый уровень — от исполнителя до руководителя Места ограничены. Подробности и регистрация на сайте.

Запись вебинара про корректировки закупок и продаж до ввода остатков: -Значение корректных начальных данных для последующей работы ERP-системы и последствия некорректного начального баланса; -Алгоритм корректировок закупок до начала ведения учета в 1С:ERP; -Шаги по проведению корректировок продаж до начала учета в 1С:ERP; -Инструменты для проверки устранения расхождений и ошибок. Смотрим: https://vkvideo.ru/video-63402641_456240376 #1C #ERP #1CERP

📖 Документация, которую реально читают Знаете, какой документ в проекте читают реже всего? Тот, который написали «потому что надо». Толстый, подробный, с красивым оглавлением — и мёртвый. Потому что его никто не открывает, кроме автора. И когда новенький приходит, он всё равно спрашивает у коллег, а не лезет в документацию. Почему так — давайте разберёмся. Потому что большинство документации пишется не для людей. Она пишется для проверяющего, для отчёта, для «ну обязаны же быть регламенты». И получается текст, который формально есть, а фактически — мёртв. Почему документация умирает Первая причина — пишет не тот, кто делает. Документацию часто поручают «специальному человеку», который не работает с системой напрямую. Он переписывает то, что ему объяснили, в красивую форму. Получается аккуратно — но оторвано от реальности. Через полгода документ не соответствует тому, как всё работает. Вторая — не обновляется. Написали в год внедрения. Потом система меняется, дорабатывается, перестраивается. Документация — нет. Через два года она бесполезна. Все это знают, но никто не обновляет, потому что «некогда» и «вроде и так работают». Третья — пишет для себя. Автор документирует то, что ему кажется важным. А читателю нужно другое: не «как устроено», а «как мне сделать мою работу». Разница огромная. Один пишет про архитектуру, другой ищет «как создать документ». Оба правы. Но второй не находит. Что делает документацию живой Живая документация — это не та, что написана идеально. Это та, которую открывают, когда надо что-то сделать, и находят ответ. Вот что отличает её от мёртвой. Пишет тот, кто делает. Не «документалист», а человек, который сам работает с системой. Он знает, какие вопросы возникают, какие шаги непонятны, где люди спотыкаются. Его текст — не литература, но он правильный. Потому что написан изнутри, а не снаружи. Обновляется по ходу. Не «раз в год большим обновлением», а по мере изменений. Изменился процесс — изменили документ. Добавили функцию — добавили описание. Документация — часть работы, а не отдельный проект. Структурирована под задачу, а не под систему. Не «раздел Справочники → подраздел Контрагенты → пункт Создание». А «Как завести нового контрагента: три шага». Люди ищут действия, а не архитектуру. Возвращайте им действия. Короткая и конкретная. Лучше пять строк, которые отвечают на вопрос, чем пять страниц, которые надо прочитать целиком, чтобы найти одну крупицу. Стереотип «хорошая документация — это толстая» в корне неверен. Хорошая документация — это та, которую можно прочитать за минуту. Практичные форматы, которые работают Не всё нужно описывать текстом. Иногда другой формат работает лучше. • Пошаговые инструкции. «Сделай это, потом это, проверь вот это». Короткие, с конкретными шагами. Идеально для рутинных операций. • Скринкасты. Три минуты видео, где показано, как сделать задачу, заменяют десять страниц текста. Особенно для новичков. • Чек-листы. Для процессов, где важно не забыть шаги. Не описание, а список «отметил — сделал». • FAQ. Сборник реальных вопросов, которые задавали люди, с ответами. Живой документ, который пополняется. Онбординг как тест документации Лучший способ проверить, работает ли ваша документация — посадить новичка и попросить сделать задачу, пользуясь только документами. Если он справился — документация живая. Если постоянно спрашивает — мёртвая. Это не проблема новичка. Это проблема документации. И это самый честный тест. Вывод Документация — не «обязательная часть проекта». Это инструмент, который либо помогает людям работать, либо валяется мёртвым грузом. Разница — не в объёме, а в подходе. Пишет тот, кто делает. Обновляется по ходу. Структурирована под действия, а не под систему. Короткая и конкретная. Мёртвая документация съедает время на написание и не возвращает ничего. Живая — экономит время на вопросы, обучение, ошибки. И становится тем, ради чего её и пишут: надёжным способом передачи знаний. #документация #проектная_команда #практика #РП #аналитика

Смена отдыха — тоже работа Лениться теперь тоже предлагают правильно. Звучит немного тревожно. Потому что современный человек уже почти всё делает правильно: работает по приоритетам, ест по калориям, спит по приложению, ходит по шагомеру. Осталось составить регламент ничегонеделания, назначить ответственного и вечером проверить результат. Но отдых почему-то не наступает. Свободная минута сегодня редко остаётся свободной. Рука сама тянется к телефону: новости, сообщения, короткие видео, ещё одно короткое видео, потом совсем последнее. Тело вроде лежит на диване, а голова продолжает перерабатывать чужие мысли, лица, споры и срочные сенсации. Получается не отдых, а вторая смена. Только без зарплаты. Клинический психолог Юлия Денисова-Мельникова напоминает простую вещь: мозг и нервная система не могут постоянно работать в режиме продуктивности. Иногда полезно просто лежать, бесцельно гулять или смотреть в окно. Причём без задачи «сейчас надо хорошо восстановиться» — иначе отдых превращается в очередной пункт плана. Источник И вот здесь начинается самое сложное. Ничего не делать многим уже почти физически неудобно. Возникает чувство, будто время пропадает, пока где-то другие развиваются, успевают, читают полезное и наверняка уже выучили новый язык. Хотя, возможно, пропадает оно как раз тогда, когда даже пауза забита информационным шумом. Настоящая лень — это не слабость и не отказ от дел. Скорее короткий момент, когда от человека вообще ничего не требуется. Даже стать лучшей версией себя. Редкая, между прочим, роскошь.

Дайджест «Школы менеджера организации» за 3–9 августа На неделе говорили о сложных управленческих темах: как быть честным и не переходить границы, почему KPI иногда искажает реальность, зачем руководителю делегировать и откуда у топ-менеджеров берутся сомнения в себе. 💬 Где проходит граница между радикальной честностью и грубостью — читать 📊 Почему сотрудники начинают работать на цифры, а не на результат — читать 🎯 Почему привычка «сделаю сам» мешает руководителю развивать команду — читать 📈 Чем отличаются цель, KPI, показатель и метрика — читать 🎭 Почему синдром самозванца особенно часто проявляется у руководителей — читать Читайте, сохраняйте и делитесь с коллегами, которым интересны управление командами, развитие руководителей и эффективная организация работы.

🌉 Когда разработчик становится архитектором (и почему это больно) Переход из разработки в архитектуру выглядит как повышение. Деньги, статус, уважение. На деле — один из самых тяжёлых переходов в карьере, потому что меняется почти всё. Не должность, а профессия. И многие не готовы к тому, насколько это больно. Давайте честно разберёмся, что происходит с человеком, который «стал архитектором», и почему этот путь нередко заканчивается выгоранием или возвратом обратно в код. Главный шок: ты больше не делаешь В разработке главное удовольствие — видеть результат. Написал, запустил, работает. Моментальная обратная связь, понятный результат, чувство «я сделал это». Архитектор так не работает. Архитектор не пишет код — он его проектирует, описывает, объясняет. Результат его работы появляется через месяцы, а иногда и годы. И чаще всего — в чужом исполнении, которое отличается от задуманного. Это первый и самый тяжёлый шок: ты больше не видишь свой результат сразу. Ты видишь его через призму чужих рук, чужого понимания, чужих ошибок. Многих это ломает. Человек скучает по коду, возвращается «помочь», начинает писать сам — и превращается либо в помеху, либо в «главного разработчика с приставкой архитектор». Ни то, ни другое — не архитектура. Второй шок: ответственность без власти Архитектор отвечает за систему в целом. Но не он нанимает людей, не он ставит сроки, не он решает, что войдёт в очередной выпуск. Он советует, рекомендует, предупреждает. А решения принимают другие. И если решение оказалось неверным — отвечать тоже ему, потому что «он же архитектор, должен был предусмотреть». Это классическая ловушка: ответственность есть, власти — ограниченно. Умение жить в этом напряжении — один из главных навыков архитектора. И он не врождённый. Третий шок: ты работаешь не с кодом, а с людьми В разработке люди — помеха, отвлекающая от кода. В архитектуре — наоборот. Главная работа архитектора — это не диаграммы и схемы. Это переговоры. С разработчиками, которые не понимают, зачем так. С руководителями, которые хотят «проще и быстрее». С заказчиками, которые не понимают, почему «просто кнопку» нельзя сделать без перестройки половины системы. Знаете, что самое тяжёлое? Доказывать очевидное. Архитектор видит риски, которые другие не видят. И объяснять эти риски людям, которые хотят «быстрее и проще», — отдельное искусство. Многие талантливые разработчики, став архитекторами, не справляются именно с этим — не с технической частью, а с человеческой. Четвёртый шок: цена ошибки возрастает на порядки Ошибка разработчика стоит часов или дней. Ошибка архитектора стоит месяцев или лет. Неверное решение на уровне архитектуры может проявиться через год, когда уже всё построено на этом решении, и «переделать» стоит как новый проект. Это тяжёлое давление. Архитектор живёт с постоянным ощущением: «а что, если я не прав?». И в отличие от разработчика, не может быстро проверить — результат проявится нескоро. Что помогает Признать, что переход — это не «продолжение разработки на новом уровне», а смена профессии. С другими навыками, другим складом ума, другим удовольствием от работы. Учиться переговорам, а не только технологиям. Архитектор, который не умеет объяснить и защитить своё решение — бесполезен. Даже если он технически гениален. Найти себе наставника. Человека, который прошёл этот путь и может поделиться опытом. Университетского курса «как стать архитектором» не существует. Реальный опыт — бесценен. И, главное, — не пытаться быть и разработчиком, и архитектором одновременно. Это разные роли. Выберите одну и выполняйте её полноценно. Вывод Архитектор — не «разработчик рангом выше». Это другая профессия. С другими радостями и другими болями. Переход тяжёлый, но если пройти его честно — он открывает уровень влияния, недоступный разработчику. Влияния на то, как система будет работать не сегодня, а через пять лет. Если вы в этом переходе — потерпите. Если думаете о нём — взвесьте. Это не повышение. Это смена пути. Ссылки и контакты Есть еще наш канал в MAX.   #архитектура #карьера #разработка #софт_скиллы #практика

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ «ШКОЛЫ ПРОЕКТНОГО СПЕЦИАЛИСТА» За прошедшую неделю, 3–9 августа, вышли материалы о границах проекта, баге в пятницу, управленческой перегрузке, адаптации новичков, метриках и развитии senior‑специалистов. 🚧 Как договориться, что НЕ входит в проект Сроки часто срываются не из-за слабой команды, а из-за незаметного расширения состава работ: к первоначальному запросу постепенно добавляют новые задачи, но дедлайн остаётся прежним. Статья о том, как заранее фиксировать границы проекта и обсуждать изменения с заказчиком без конфликта. 🐛 Стадии принятия бага, который всплыл в пятницу вечером Ироничный текст о знакомом сценарии: критическая ошибка появляется в конце рабочей недели, а команда проходит путь от отрицания до кофе, коммита и долгожданного подтверждения от заказчика. 🎙 SADT и IDEF0: как устроена строгая логика процессов Выпуск о методологии функционального моделирования: как через блоки и дуги декомпозировать сложную систему, описывать входы, управление, механизмы и результаты процесса. 📵 Самая незаметная ошибка — быть всегда на связи Постоянные сообщения, звонки и согласования создают ощущение занятости, но вытесняют работу над действительно важными решениями. Автор объясняет, как доступность руководителя приучает команду передавать ему всё больше вопросов. 🌱 Новички в крупном проекте: как не убить проект и не сломать людей «Бросить в воду» — плохая стратегия для сложных проектов, где цена ошибки высока. Материал о том, почему новичкам нужны понятные задачи, контекст, регулярная обратная связь и безопасный способ задавать вопросы. 📊 Как правильные метрики заставляют компанию работать неправильно Люди начинают оптимизировать то, чем их измеряют: поддержка шлёт отписки ради скорости ответа, продажи делают звонки ради плана, а качество уходит на второй план. Текст — о риске подменить бизнес-результат красивыми цифрами. 🧱 Карьерный тупик senior: ты всё умеешь, но некуда расти После уровня senior технический рост становится менее очевидным: редкие позиции архитектора, тимлида или техдиректора подходят не всем. Статья разбирает, почему это не обязательно выгорание и какие траектории развития остаются у опытного специалиста.

🎬 Один проект — два фильма: заказчик и подрядчик Пятница, вечер. Самое время посмеяться над тем, что объединяет нас всех. Один и тот же проект глазами двух сторон — два совершенно разных киносюжета. На совещании Заказчик: «У нас простые процессы, внедрим за пару месяцев». Подрядчик: «У них там ад, но на совещании улыбаемся». В договоре Заказчик: читает одно. Подрядчик: написал другое. Оба: уверены, что договорились. На старте Заказчик: «Ну, начали! Когда первые результаты?». Подрядчик: «Мы ещё не получили доступы. И данные. И НСИ. Хотя бы НСИ». На середине Заказчик: «А можно ещё вот это добавить? Совсем чуть-чуть». Подрядчик: «Опять. Снова. Как всегда». За неделю до сдачи Заказчик: «Кажется, нам нужно пересмотреть подход». Подрядчик: «Мы это предсказывали на старте. В протоколе. На странице три». На сдаче Заказчик: «Ну, в целом похоже на то, что мы хотели». Подрядчик: «Это ровно то, что в спецификации. Которую вы согласовывали. Полгода». Через год Заказчик: «Хорошо, что всё-таки сделали. Хотя было сложно». Подрядчик: «Хорошо, что всё-таки сделали. Хотя было сложно». Знаете, что смешного? На финальной строчке они наконец согласны. Все хотят одного — чтобы проект закончился и заработал. Просто путь к этому каждый видит по-своему. Хорошей пятницы и удачных проектов. Чтобы кино было со счастливым концом. 🍿

SADT появилась ещё в конце 1960-х как способ разложить сложную систему на понятные действия. Без магии: берётся большая функция, например «управлять производством», и раскладывается на более мелкие — закупать, планировать, выпускать, контролировать. Позже подход лёг в основу IDEF0, который до сих пор используют при описании бизнес-процессов, проектировании информационных систем, автоматизации производства и внедрении ERP. Особенно полезно там, где все говорят о процессе разными словами и уже немного запутались. Сильная сторона SADT — она заставляет не просто рисовать квадратики. У каждого действия есть вход, результат, правила управления и ресурсы. Сразу видно: что приходит в процесс, что из него выходит и почему он вообще работает. Но есть и минус. Хорошая SADT-модель требует времени и дисциплины. Если увлечься детализацией, можно нарисовать такую иерархию, в которой потеряется даже автор. Поэтому это не универсальная замена всем схемам, а инструмент для ситуаций, когда сложность действительно надо разложить по полкам.

Разбираем ключевые различия между целью, параметром, метрикой, показателем и KPI. В статье показано, как путаница в терминах приводит к ошибочным решениям, суррогатным «ключевым» показателям и странной системе премирования. И как навести порядок в управленческом языке, связать KPI с критически важными результатами и перестать измерять всё подряд только потому, что это легко выгружается в Excel? Читать полностью: Цель, KPI или метрика: почему менеджеры называют одним словом разные вещи.