ЧАТ. Технологии 1С проектов

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

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

Экспертное мышление — это не талант, а набор рабочих привычек В McKinsey и других консалтинговых компаниях людей учат не просто «много анализировать», а быстро превращать сложность в понятное решение. Структурировать проблему. Начинать с вывода. Отвечать за результат. Искать главное по принципу 80/20. Постоянно задавать себе вопрос «И что из этого следует?». И проверять гипотезы вместо того, чтобы собирать данные «на всякий случай». Собрал в инфографике 6 привычек экспертного мышления в подходе McKinsey. Интересно, что большинство из них полезны далеко за пределами консалтинга — особенно руководителям, аналитикам и тем, кому приходится принимать решения в условиях нехватки времени и информации.

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

📌 Дайджест «Школы проектного специалиста» За прошлую неделю — о профессиональном мышлении, адаптации компаний, работе с клиентскими ожиданиями и причинах конфликтов в командах. 🔹Экспертное мышление — это не талант, а набор рабочих привычек Шесть привычек из консалтингового подхода McKinsey: структурировать проблему, начинать с вывода, выделять главное по принципу 80/20 и проверять гипотезы. 🔹Парк юрского периода — компания, которая выросла на старых процессах, рискует вымереть О том, почему отлаженные процессы и привычная иерархия могут стать слабостью, если организация не успевает адаптироваться к изменениям вокруг. 🔹«Клиент всегда прав» — красивая фраза, которая ломает и команду, и продукт Почему профессиональная забота о клиенте иногда означает вовремя сказать «нет» требованию, которое вредит продукту, срокам или качеству. 🔹Конфликт без крика: как цели и роли незаметно сталкивают людей Конфликты в проекте часто возникают не из-за личных качеств, а из-за разных целей, неясных полномочий и отсутствия договорённостей о принятии решений. #управлениепроектами #проектныйменеджмент #экспертноемышление #команда #клиентскийсервис #управление

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

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

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

Сотрудница пять лет не была в отпуске — у нее накопилось 135 дней отдыха. Используйте отпуск вовремя! Ведь если компания спокойно работает без человека несколько месяцев, невольно возникает вопрос: насколько сотрудник действительно незаменим?

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

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

Классная «плоскостная» демонстрация работы гравитации.

Иногда это все, что нужно для полного счастья.

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

Доброе утро, друзья!

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

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

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