Привет, Хабр! Я - Михаил Персианов (Данила Мастер), я разработчик 1С в ИТ-холдинге Т1.
Сегодня мы с Оппонентом обсудим вечную тему. Конечно же, в контексте 1С, и с неожиданным выводом. Для тех, кто вдруг не в курсе, поясню:
/
Многие специалисты в ИТ и управлении знакомы с состоянием, когда в конце рабочего дня список задач выполнен, но вместо ожидаемого удовлетворения возникает ощущение пустоты или фоновой тревоги. Это не субъективное переживание, а закономерный результат работы нейробиологических и когнитивных механизмов, которые часто игнорируются в построении рабочих процессов. Именно анализ этих механизмов позволяет понять, почему продуктивная активность не всегда приводит к психологическому ощущению завершенности.
Дофаминовая система: мотивация без награды
В основе нашего стремления к выполнению задач лежит дофаминовая система мозга. Ключевой нюанс ее работы заключается в том, что дофамин - это в большей степени нейромедиатор мотивации и предвкушения, а не удовлетворения. Его уровень повышается в процессе движения к цели, а не при ее достижении. В условиях современной рабочей среды этот механизм дает сбой:
Меня зовут Станислав Решетнев, я руковожу отделом разработки в компании Sape по направлению Link Building (инструменты для продвижения в поисковых системах). В моем ведении находятся команды продуктовой разработки и команда внутренней Платформы. Чтобы лучше понимать эффективность сотрудников и видеть проблемные места, я создал инфополе с метриками продуктивности команд.
В этой статье хочется передать тем руководителям и командам, которые растут и оцифровывают свои достижения, наши наработки. Построить подобное инфополе можно достаточно быстро и легко с помощью стандартных инструментов — Asana и Jira.
Пару лет назад я написал свою первую статью на Хабр. Если перечитать её сейчас, она хорошо заряжает энергией, но во многом говорит про ментальное становление и правильные вопросы к руководству. Эту статью я хочу посвятить следующему этапу. Менее мотивационному, но более сознательному. Тому, с чем сталкиваются и молодые, и опытные специалисты, когда рынок начинает меняться быстрее, чем привычные карьерные модели.
Под адаптацией я понимаю не смену технологий или профессии, а способность оставаться востребованным. Это уже не про стать лучше, а про стать предсказуемым и понятным рынку.
Я — Антон Марунько, руководитель в продуктовых компаниях уже более шести лет, помогаю строить и обучать команды в сфере IT.
Команда работает больше, процессов добавили, людей наняли. А результат тот же. Или хуже. Почему улучшения не работают? Рассказал, как перестать улучшать всё подряд и начать делать команду быстрее:
• Почему масштабирование команды не даёт результата (и что делать вместо этого);
• Когда стоит делегировать задачи, а когда нет;
• Как найти одно узкое место, которое тормозит всю систему.
В статье — разбор реальных кейсов от IT-команд до распределенных продуктовых групп, с примерами правильных и ошибочных решений.
Недавно наткнулся на статью о том, почему хорошие разработчики пишут плохой код в больших компаниях. Автор объяснял это высокой текучкой, тем, что большинство изменений вносят новички, а ветераны перегружены и не успевают передавать экспертизу. Меня эта статья зацепила, потому что я видел и другую картину в своей практике. Решил поделиться опытом: как в сравнительно небольшой ИТ-компании можно писать хороший код, когда собственник ратует за его качество.
Однажды фраза из к/ф "Человек с бульвара Капуцинов" навела меня на размышления о моем пути в ИТ-профессии. В отличие от Билли, мне повезло: я не просто встретил хороших людей, а прочитал умные книги, которые эти люди написали. Когда я вспоминаю годы, когда только становился программистом, отчётливо вижу те издания, которые заложили мой будущий фундамент. Это были не просто инструкции, а встречи с людьми, которые изменили мой взгляд на программирование и управление. Удивительно, насколько сильно несколько толковых книг могут повлиять на судьбу человека!
Refactoring Мартина Фаулера научил меня профессиональному отношению к коду и привычке доводить детали до совершенства. Не писать идеально с первого раза невозможно. Но постоянно улучшать, рефакторить, делать код чище и понятнее. Это не про перфекционизм, а про уважение к тем, кто будет читать этот код завтра. Фаулер однажды сказал: "I am not a good engineer, I am an engineer with good habits". Эта фраза стала для меня ключевой. Я понял, что хороший код это не про талант, а про привычки. Про то, что ты делаешь каждый день, даже когда никто не смотрит.
Маркировка охватывает всё больше товарных категорий, и если для одних участников рынка она уже стала рутиной, то у других она вызывает много вопросов и стресса. Сегодня на повестке — масла и автозапчасти.
В то время как моторные масла уже перешли в «обязаловку», автозапчасти пока ещё находятся на стадии эксперимента до февраля 2026. Постепенный ввод новых категорий даёт бизнесу шанс: разобраться с учетом, актуализировать данные, донастроить систему учёта под новые требования и сделать всё это до начала обязательного этапа — спокойно, без спешки, с возможностью совершать ошибки, за которые не придётся платить.
Особенно ценно это для компаний, работающих на устаревающих системах вроде «1С:Управление торговлей 10.3» и «1С:Альфа-Авто 5», где каждое новое требование регулятора превращается в технический вызов. Основываясь на собственном реальном опыте, историях и опыте наших ведущих партнёров-интеграторов, рассказываем, как пройти путь от ручного учёта «по бумажке» к автоматизированному контуру, совместимому с Честным ЗНАКом, без разрушения привычных бизнес-процессов.
Экономия масштаба была фундаментом глобализации последних ста лет. LLM меняют это уравнение: один человек с AI-инструментами может делать работу команды. Что это значит для аутсорсинговых экономик, мегаполисов и структуры рынка труда?
Сегодня разберем феномен, который вызывает споры в профессиональных чатах: почему представители поколения Z так резко реагируют на определенные фразы руководителей и как это связано с их лингвистической чувствительностью, а вовсе не с ленью.
Существует множество торговых компаний, которые, не смотря на их разнообразие, имею общее - осуществляют работу с закупками и продажей товаров и формируют при этом определенные материальные и сопровождающие их информационные потоки. Как эти потоки образуются, что при этом происходит и какие механизмы управления при этом используются будет рассмотрено в этой статье.
Лучший способ похоронить базу знаний — это спустить её сверху, обязать всех искать там информацию и бросить в таком состоянии. БЗ только тогда чего-то стоит, когда она вовремя пополняется и актуализируется, когда в ней на конкретный вопрос находится конкретный ответ, когда за информацией не надо бегать по куче ссылок, выискивая крупицы смысла. Когда база знаний не утрачивает своей пользы при росте числа пользователей — как авторов, так и читателей. Только тогда принятие решений на основе знаний будет точным, онбординг новичков будет проходить без задержек, а саппорт будет укладываться в SLA.
Качественное и своевременное внедрение корпоративных информационных систем как российского (1С, Галактика, Парус), так и западного производства (ранее преимущественно SAP, Oracle и Microsoft) требует досконального знания методологии имплементации, что накладывается свой отпечаток на жизненный цикл программного обеспечения. Несмотря на наличие гибких методов внедрения, жизненный цикл программных продуктов, по существу, остается единым: начиная с задумки и заканчивая выведением из эксплуатации. Внедрение корпоративных программных систем, представляющих собой имплементирование программного решения в масштабах предприятия или холдинга, имеет схожий жизненный цикл. Однако, если внимательнее к нему присмотреться, выходит, что процесс внедрения является не единственным, а фактически завершающим шагом. Не верите, тогда давайте разберемся в этом вопросе в рамках текущей статьи.
Приведем шаги классического жизненного цикла программного обеспечения [1]:
Развивать платформенные продукты не просто. С бизнес-продуктами всё более менее понятно: развивать надо то, что приносит деньги. Тут главный вопрос, как узнать, что именно приносит деньги. Это тоже очень не просто, и на эту тему написано десятки статей и даже учебников.
В этой же статье хочу поговорить о том, какие сложности стоят именно перед платформенными продуктами. Если хотите узнать подробности — эта статья для вас.
В марте в Москве пройдет INFOSTART TEAM EVENT 2026, и организаторы уже подтвердили и одобрили доклады потока «ИТ-анализ, управление требованиями, проектирование систем». Это тот самый трек, который обычно интересует не “ради вдохновения”, а ради ответа на практические вопросы: как формулировать требования так, чтобы они выполнялись в реальных условиях, как проектировать сложные взаимодействия между системами и как ускорять изменения без потери управляемости и качества.
Если коротко, в 1С-проектах стало заметно больше “взрослой” сложности. И это не абстрактная “цифровая трансформация”, а конкретика:
После того как я начал делиться своим опытом построения стартапа ($1.35 млн инвестиций, 300к юзеров, экзит) в статьях на Хабре — получил большое количество сообщений с просьбой продолжать. Мы уже обсудили базовые уроки, планирование в условиях неопределенности и тему управленческого долга.
Сегодня я хочу копнуть еще глубже и поговорить о первопричине всех проблем и успехов – о психологии. О том, как наши внутренние установки помогают и мешают управлять командой, создавать продукт, продавать его – и сохранять себя на этом пути.
Как всегда, для придания веса своим словам я призову на помощь Бена Хоровица (легендарный CEO с экзитом на $1млрд+, сооснователь фонда Andreessen Horowitz) для обсуждения психологии руководителя. А влияние психологии на продажи и маркетинг мы разберем с привлечением опыта Ноя Кагана, основателя AppSumo — в нашем стартапе мы на этой площадке сделали продаж на сотни тысяч долларов благодаря их маркетинговым тактикам.
Как успеть сделать огромную не профильную работу и выжить. Срочные задачи, размытые требования, меняющиеся вводные и большое количество людей, принимающих решения – это нормальное состояние для IT, продуктовой разработки и любых сложных систем. Поэтому в этой статье не будет рассуждений в духе «надо было всё предусмотреть заранее». Здесь про мой опыт и про то как мы преодолели этот рубеж и где оступились.
Вы можете быть сильным специалистом и все равно создавать сложности для коллег. Разбор восьми самых частых сценариев из жизни IT-команд.
Когда ИТ-активов становится слишком много, Excel перестаёт справляться
Десятки складов, международные поставки, перемещение между юрлицами — а учёт по-прежнему живёт в таблицах. Знакомо?
Мы прошли через это сами и за 9 месяцев внедрили ITAM-систему, которая превратила хаос с ИТ-активами в понятный и управляемый процесс.
Внутри — реальный опыт международной компании:
→ почему Excel опасен для бизнеса на масштабе
→ как выбирали ITAM-систему: 7 обязательных требований
→ внедрение за 9 месяцев: этапы, сложности и подготовка
→ первые измеримые результаты уже через 3 месяца
→ что дальше: интеграция с финансами, закупками и валютами
Если вы устали тратить дни на отчёты и хотите видеть каждый ИТ-актив в реальном времени — этот кейс для вас.
Приложения для заметок — это цифровой блокнот, где можно быстро записывать идеи, списки дел, конспекты и рабочие договорённости, чтобы ничего не терялось и легко находилось через поиск. Такой онлайн блокнот удобен, когда нужно одно приложение для заметок на телефон и ПК: записали мысль на ходу — продолжили на компьютере.
В статье я собрала приложения для заметок под разные сценарии — личные дела, работа, учёба и ведение «второго мозга».
Ситуация: открываете базу знаний и понимаете — что-то с ней не так, и каждый раз кто-то приходит с одними и теми же вопросами. Вы — тимлид/техлид/knowledge-менеджер, который знает ответы на все вопросы. Но времени на работу не остаётся как раз из-за разрешения всяких мелочей. Знакомо?
Привет, Хабр! Меня зовут Анастасия Граф. Я руковожу отделом разработки технической документации в Maxim Technology — компания делает Ride Tech сервис для такси Maxim. Мы первыми в России запустили цифровую платформу. Этот материал готовился по мотивам доклада для TeamLead Conf.
В предыдущей части статьи об организации Базы знаний мы сформулировали универсальные требования к ней и разобрались, с чего начать в принципе на примере процессов в Maxim Technology. Сегодня выясним, зачем нужно ревью любой документации и как оно поможет повысить уровень знаний в командах.