Привет! Я – Ольга Красильникова. У меня за плечами 18 лет работы в сфере управления и развития персонала в компаниях Евросеть, М.Видео, Yota, МТС, Coca-Cola, Heineken. Сейчас работаю менеджером по обучению в Bercut. А еще я карьерный психолог, коуч (более 800 часов коучинговой практики). Верю, что любая работа может стать ресурсом для человека.

За последний год я провела больше 400 карьерных консультаций и коуч-сессий (как внутри компании, так и в частной практике), и вот фразы, которые я слышала почти в каждой сессии:

• «ненавижу свою работу»;
• «как же меня бесят мои коллеги»;
• «мой руководитель – идиот»;
• «мне все это надоело, это никому не нужно»;
• «сил нет больше терпеть».

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

В своей публикации расскажу, как люди сами создают себе ад на работе и как сами могут себе помочь. Дам три полезных инструмента, позволяющие управлять замкнутыми кругами, в которые многие из нас время от времени попадают. А в конце –бонус.

Без толковой API-документации сложно делать открытый продукт и ждать, что его будут развивать пользователи. Часто владельцы сервисов занимаются документацией по остаточному принципу. В итоге разработчику достаётся запутанная инструкция, а интеграция усложняется или просто становится невозможной.

Мы осознали эту проблему до разработки открытого API и заранее спланировали, как сделать документацию понятной. Сегодня расскажу подробно про портал документации Alfa API. Как с ним быстро разобраться в технической реализации, а главное — улучшить впечатления от работы со сложным продуктом — узнаете в статье.

Хабр, привет!

Меня расстраивает несправедливость в мире IT: для новичков-разработчиков есть куча пошаговых инструкций, о там, как разработать API или мобильное приложение. Хочу немного уровнять баланс вселенной, поэтому я написал небольшой гайд для аналитиков для составления документации.

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

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

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

В этой статье я расскажу о генераторе документации Sphinx, с помощью которого можно автоматически создавать документацию для модулей Python. Кроме того, я буду использовать шаблон проекта Cookiecutter Data Science в Visual Studio Code (VS Code), поскольку он легко интегрируется в Sphinx и имеет стандартизированную структуру директорий. Официальное пособие по использованию Sphinx — отличный ресурс для пользователей, которые хотят углубиться в детали. А моя статья — это краткое руководство по началу работы с этим инструментом.

Привет! Меня зовут Савр, я работаю инженером технической поддержки Arenadata. В прошлом году нам, как и многим другим компаниям, использовавшим зарубежное ПО, пришлось переходить на российские аналоги. В частности, с болью в сердце мы отказались от Jira Service Management (далее SM) — нашей системы управления обращениями заказчиков и основного инструмента службы поддержки. Мы были вынуждены перейти на российскую разработку SimpleOne.

Поскольку наша команда привыкла к предыдущей функциональности, после миграции мы сделали ряд доработок нового сервиса. В этой статье я расскажу о некоторых из них: почему мы решили это исправить и как именно реализовали. Сразу оговорюсь, что мы не претендуем на статус великих специалистов или консультантов по SimpleOne, а лишь хотим поделиться своим опытом и идеями с теми, кто тоже рассматривает этот инструмент как альтернативу существующему решению.

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

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

В этой статье мы поделимся своим опытом создания документации «с нуля» на примере Arenadata.

Всем привет! Меня зовут Семен. Я Java-разработчик и руководитель группы Java-разработки в Центре Big Data компании MTS Digital. В этом посте я хочу поговорить о Release Notes. Что это такое, почему не стоит писать их вручную и какие есть способы автоматизации. Покажу и реальный пример того, как организована  работа с Release Notes в нашем проекте.

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

Вы бы стали читать рецепт из 10 страниц, чтобы приготовить салат? Что-то я сомневаюсь. Схожая ситуация бывает в документации, когда она пишется без шаблона по принципу "чем больше, тем лучше".

Если ваши  документы не читают, не понимают, или вы не знаете с чего начать описывать интеграцию,  то эта статья для вас.

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

Делимся ссылками на примеры API разных стилей, которое можно подёргать в режиме онлайн прямо на сайтах. Также к большинству ссылок есть документация.

В последние полгода появилась четкая тенденция: крупные корпорации загоняют сотрудников обратно в офис. Они обязуют 60% рабочего времени проводить в офисе, что примерно равно трем дням в неделю.

Приводятся разные доводы: кто-то говорит, что в офисе лучше строится доверие, другие считают, что сотрудники в продуктивнее работают вне дома. Давайте разбираться!

Сам работаю программистом в Амазоне уже больше двух лет. Начинал в команде в Ванкувере, Канада. Мне не понравилось и я переехал в Испанию, поменяв команду.

«Можно сделать быстро, но плохо, а можно — медленно, но хорошо. Через некоторое время все забудут, что было быстро, но будут помнить, что было плохо. И наоборот.»
Сергей Королёв, конструктор

В 2023 году SQL (Structured Query Language) остается одним из самых популярных языков программирования, используемых в области баз данных и аналитики данных. Изучение SQL может быть полезным как для тех, кто только начинает свой путь в IT, так и для опытных профессионалов, которые хотят расширить свои знания и навыки. В этой статье мы рассмотрим несколько советов и ресурсов, которые помогут вам изучать SQL в 2023 году, и оставаться в курсе последних тенденций и изменений в этой области.

Согласно данным сайта Indeed.com, в 2023 году требования к кандидатам в вакансиях, связанных с базами данных и анализом данных, включают знание SQL в качестве обязательного навыка. Некоторые из таких популярных вакансий включают в себя SQL Developer, Data Analyst, Database Administrator, Business Intelligence Analyst и другие. Согласно данным сайта Glassdoor, зарплата специалистов, владеющих навыками работы с SQL, может составлять от $50 000 до $100 000 в год в зависимости от региона и уровня опыта. В связи с этим, изучение SQL может быть полезным для тех, кто хочет улучшить свои шансы на рынке труда и получать высокую заработную плату в IT-сфере.

Docs as Сode — подход к работе с текстами, подразумевающий написание текста как кода:

• в простом текстовом редакторе или IDE;
• с использованием системы контроля версий;
• с CI / CD / Code Review.

В настоящее время Docs as Code широко применяется при работе с технической документацией, давая техническим писателям и проектным командам массу удобств и преимуществ.

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

В этой статье я расскажу о таком эксперименте (забегая вперед, удачном). Моей дочери 11 лет, она пишет сказки, стихи и рассказы. Чтобы поддержать ее увлечение, я помог ей создать литературный сайт, используя подход Docs as Code. Она успешно освоила основы Markdown и Git. Сейчас она самостоятельно публикует новые произведения и обновляет новости на своем сайте https://lib-beliakova.github.io/.

Всем привет.

Меня зовут Саша, я технический писатель в CSI, но занимаюсь и проектами в нашей команде разработки. Считайте, что сегодня вы зашли ко мне на работу, плюхнулись в пуфики, взяли кофе — и я просто так рассказываю вам про наш портальчик. Всю публичную техническую документацию по ИТ-продуктам компании мы ведем на портале поддержки, который развернут в инстансе Atlassian Confluence Cloud. Расскажу, как мы к этому пришли, как работали над структурой и принципами подготовки материалов, какой от этого профит.

Картинка тут не случайно. Буквально вчера знакомый художник прислал мне такой портрет меня — и я подумал, что она тут в тему: думаю, многим знакома ситуация, когда в одной голове или ресурсе сосредоточены все знания. Это про меня. Но сейчас я с вами с удовольствием поделюсь!

Сегодня хочу поговорить о том, как проводить one-to-one встречи. 

Сначала о том, зачем они вообще нужны. One-to-one встречи – это один из инструментов развития команды. На этих встречах вы постепенно, планомерное выстраиваете отношения с сотрудником. Прозрачные, ясные отношения, в которых становится возможным сотруднику развиваться. В итоге эти встречи работают на адаптацию сотрудников, на их мотивацию и удержание. 

На встрече важно обсудить не только задачи. Вот примерная схема проведения one-to-one встречи.

 1. О сотруднике. С этого стоит начать. Спросите, как у него дела, что у него в жизни происходит.  

 2. Задачи. Какие сейчас у него задачи, какие у них сроки, какие есть проблемы. 

 3. Мотивация. Важный пункт, не игнорируйте его, пожалуйста. Необходимо прояснять мотивацию сотрудника на каждой встрече. Спросите, как ему его задачи, что нравится, что нет. 

 4. Компания. Тут вы возвращаете сотрудника к тому, что он часть компании, что он приверженец определённой группы. Поделитесь с ним новостями компании и спросите, как это ему, поделитесь информацией про команду и тоже спросите, как это ему. Таким образом вы закрепляете за человеком его вовлечённость. 

 5. Работа с тимлидом. Самый неудобный вопрос) Можно задавать в лоб: «Как тебе работается со мной?» или окольными путями: «Что бы ты хотел в нашем взаимодействии улучшить, как тебе one-to-one, что бы ты хотел вынести на one-to-one», и т.д.

 6. Кризисы. Если в команде возник конфликт, пертурбация (например, когда из-за вируса все стали работать из дома), не старайтесь делать вид, что ничего не изменилось. Разъясните сотруднику происходящее, спросите, как он чувствует себя внутри всего этого. Вы таким образом можете снизить его тревогу. Сейчас достаточно много вызовов мира, которые заставляют сотрудников поступать по разному. И для нас важно понимать, не останется ли завтра проект без важного сотрудника, по его личным причинам.

На одном из потоков курса «PSYvIT для управленцев» меня спросили, надо ли на каждой встрече говорить про компанию. Разве может отношение к компании меняться раз в неделю? Нет, не обязательно каждый раз, но раз в 2-3 недели спросите. Вопросы могут меняться: держите в фокусе компанию, а спросите про продукт, про новый релиз. Компания – это вообще про окружение сотрудника, про команду. Опять же, многое зависит от того, что в вашей компании происходит сейчас. Кроме вопросов, рассказывайте об успехах и изменениях, которые происходят. Очень важно, чтобы новости компании сотрудники узнавали от вас, а не из новостной ленты социальных сетей.