Когда проект небольшой, а релизы выходят редко, тестирование чаще всего строится интуитивно. Что-то проверили, что-то упустили — в худшем случае исправили по факту. Такой подход может работать годами, пока система не начинает расти.

Этот материал вырос из нашего доклада на Infostart Tech Event в прошлом году. Здесь я подробно разберу, как мы перестраивали процесс тестирования релизов в крупном проекте 1С:ЗУП: с чего начали, какие проблемы выявили, почему не стали автоматизировать всё подряд и к какому результату в итоге пришли.

Меня зовут Анна, я руковожу образовательными программами в ИТ.

В этой статье хочу рассказать, как мы использовали игровые механики, чтобы сделать карьерное развитие в ИТ более понятным, наглядным и прикладным.

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

Выбираем архитектуру по кайдзен: на что обратить внимание

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

Предлагаю разобрать на примере подход выбора архитектуры для продукта!

В парусном спорте и работе в IT-команде больше общего, чем кажется: здесь тоже есть роли, ответственность, а успех зависит от слаженности команды, оперативного принятия решений и способности адаптироваться к изменениям. Делимся 5 менеджерскими подходами, которые отточили во время хождения под парусом.

Привет, Хабр! Меня зовут Денис, я руковожу технической поддержкой в одной из крупнейших компаний России. Более 16 лет я работаю в IT, а последние годы занимаюсь управлением поддержки и автоматизацией процессов.

Хочу поделиться нашим опытом перехода на новый ИТ-стек, построенный на полностью российских решениях (Astra Linux, R7 Office, TrueConf и другие), и преодоления всех сложностей. Возможно, кого-то из вас это оградит от пары седых волос и сэкономит сотни часов работы поддержки.

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

Всем привет! Меня зовут Андрей и наша команда занимается поддержкой и сопровождением системы управления нормативно-справочной информацией на платформе «1С:Предприятие». Одна из самых сложных и интересных задач технического характера для нас за последние годы — это обновление Библиотеки стандартных подсистем 1С в составе нетиповой конфигурации. В статье расскажем, как мы эту задачу решали, и поделимся опытом.

Привет! Меня зовут Петр, я начал свой путь 1С разработчика в 2021 году, и за почти 5 лет стажа успел поработать в самых разных компаниях: с крупным бизнесом, корпорациями и даже государственными структурами. Все большие проекты, на которые меня выводили, были похожи друг на друга. Большая команда, 3–4 контура, автотестирование и т.д. всегда масштабно! Но к моему удивлению даже на таких больших проектах зачастую халатно относились к защите данных! Но были проекты, на которых данные клиента были защищены на очень достойном уровне.

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

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

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

Статья будет полезна руководителям ИТ-отделов, специалистам по информационным технологиям и владельцам компаний, которые хотят поддерживать качество информационной среды и эффективно развивать своё дело.

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

Привет! Меня зовут Влад и занимаюсь Python backend-разработкой. Довольно долго я работал над большим продуктом, который объединял несколько команд разработки. В нем было много микросервисов, базовые фичи кочевали из одного в другой, и часто разработчики делали одни и те же инфраструктурные компоненты по-разному. А когда переходили с одного микросервиса на другой, им приходилось долго осмыслять кодовую базу нового решения.

Код полнился ошибками, а разработчики тратили время на их отладку и исправление. Так мы вживую воплотили печальную статистику: разработчики ПО в среднем тратят на написание кода лишь [52 минуты в день](https://www.software.com/reports/code-time-report), остальное — исправление ошибок и другие сопутствующие задачи.

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

Привет! Меня зовут Артем, я технический лидер в крупной it компании РФ. Расскажу как использовал nexus framework для масштабирования команд разработки.