Про процесс ДХП (документальный ход проекта)

Исторически в агентствах за документальным ходом проектов следят менеджеры. У нас тоже всегда было так. Однако проекты росли и усложнялись, а параллельно росла сложность документальных отношений с заказчиками, вследствие чего РП всё чаще начинали забивать на тщательный контроль документов и возникла острая необходимость в разделении труда.

Поэтому мы создали отдел администраторов проектов, которые ведут процесс ДХП. Они обеспечивают регулярный анализ клиентской документации и контроль соответствия фактического хода работ букве договора.

Администратор проекта закреплен за несколькими проектными офисами и ведёт до 10 активных клиентов. По итогу этой работы проектной команде и руководству раз в месяц уходят письма с документальным статусом проекта, выглядят они вот так:

Таким образом мы:

• контролируем все документальные риски и узнаем о них заблаговременно;

• снижаем риски непреднамеренного нарушения условий договора;

• получаем дополнительный источник информации о потенциальном срыве сроков проекта;

• разгружаем руководителей проектов;

• передаем весь документальный процесс специалистам с опытом в этой сфере и с фокусом на эту составляющую;

• контролируем и уменьшаем объем работы без подписанных документов.

Больше материалов об управлении IT-компанией — на странице нашего исполнительного директора Сергея Кожемякина в одной из соцсетей. Прежде чем перейти по ссылке, включите VPN.

Почему размер телефона имеет значение

На дизайне до безобразия редко вспоминают, что люди привыкли пользоваться разными смартфонами. Одни обожают лопаты до локтя, другие — миниатюрные аппараты, которые умещаются в ладони. А между тем, первые исследования о том, как люди держат в руках телефон и планшет, появились на Западе еще в 2010-х.

Вот недавний кейс из нашей практики. Заказчик сделал в мобильном приложении ленту с фотографиями. И всё бы хорошо, но было одно «но». Чтобы листать кадры, нельзя было просто свайпать. Вместо этого нужно было жать на кнопку в самом низу фото. Причем на маленьких девайсах блок с фото, заголовком и самой кнопкой не умещался на экране. Чтобы ее увидеть, нужно было скроллить вниз. И далеко не каждый это понимал.

Более того, если пользователь находил заветную кнопку и перелистывал фото, ему приходилось скроллить вверх, чтобы увидеть ее целиком. Чувствуете, как больно? При этом на большом IPhone Pro Max всё было в полном порядке — красиво и удобно.

Этот кейс напоминает нам, что у пользователей разный опыт, и это не всегда очевидно. А ведь есть еще куча более тонких нюансов:

💬 Что, если пользователь предпочитает планшет?

💬 А если он использует только левую руку, потому что в правой держит кофе?

💬 А вдруг это приложение для готовки, и с ним удобнее работать голосом?

Иногда детали просто невозможно узнать без исследования. А без этих деталей сделать удобный интерфейс — очень, очень сложная задача.

Больше постов о метриках и исследованиях — в нашем канале.

5 принципов именования и документирования аналитических событий

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

1. Единое место документации событий. Создайте единое место документации всех событий (будь то Notion, Confluence, Google-документ или система аналитики с встроенным трекинг-планом) и используйте только его как источник правды.

2. Единая нотация. Выберите одно соглашение о наименовании (нотацию) и придерживайтесь его. Вот наиболее используемые из них:

• all lowercase — page view;

• snake_case — page_view;

• camelCase — pageView;

• Proper Case — Page View;

• Sentence case — Page view.

3. Структура в названии событий. Обычно название события — это комбинация названия объекта, совершенного над ним действия и, при желании, категории события.

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

5. Единый справочник параметров. Определите список параметров всех событий и пользователей, максимально опишите их, укажите возможные значения параметров, их обязательность и тип. Переиспользуйте параметры в событиях.

Подробнее о каждом пункте мы рассказываем в отдельной статье.

Виды логирования в Swift

Логирование — важный инструмент в арсенале разработчика. Оно помогает систематизировать сообщения, дает возможности фильтрации и многое другое. У Apple несколько основных инструментов для логирования.

Print — базовая функция, выводящая текст в консоль Xcode. Она часто используется для дебаггинга и неплохо справляется, когда решать приходится простые проблемы. В релизном коде Print оставаться не должен.

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

Dump — еще одна функция для распечатки сообщений в консоль. При работе с объектами и массивами объектов Dump показывает себя лучше, чем Print и DebugPrint. Мы получаем более наглядный результат, можем повлиять на то, в каком виде представлена информация, избавиться от лишнего «шума» в консоли.

OSLog — наш главный инструмент для ведения логов. Для этой функции мы передаем тип, название файла и название функции. Кастомизировать это можно как угодно.

Logger — более свежая альтернатива, доступная с iOS 14. Logger от OSLog отличается в деталях. Это разные уровни логирования и возможности настройки логов. С помощью расширений можно создать несколько логгеров, отвечающих за логирование разного функционала.

Подробнее о каждом инструменте — в нашем блоге.

Как оценить, нравится ли сотрудникам работать в компании

Чтобы понимать, какое настроение царит у нас в коллективе, мы раз в полгода проводим два опроса среди всех сотрудников: ESI и eNPS.

1. Индекс удовлетворенности ESI (Employee Satisfaction Index).

Опрос состоит из серии однотипных вопросов, где нужно оценить разные аспекты работы от 0 до 5 (например: уровень ЗП, интересность задач, соцпакет и т. д.).

По итогу формируется сводный показатель в виде среднего арифметического.

2. Индекс лояльности eNPS (Employee Net Promoter Score).

Тут задаем всего один вопрос — вероятность, что ты будешь рекомендовать AGIMA как место работы.

По итогу мы выявляем количество сторонников, нейтралов и критиков.

Процент сторонников минус процент критиков — это и есть показатель, на который мы ориентируемся.

Улучшение этих показателей — основной KPI нашего HR-директора, и весь HR-отдел работает над тем, чтобы сотрудникам больше нравилось работать. Мы хотим, чтобы наши спецы становились евангелистами, которые помогают транслировать наши преимущества вовне и тем самым укреплять HR-бренд.

Больше материалов об управлении IT-компанией — в блоге нашего исполнительного директора Сергея Кожемякина. Чтобы почитать, включите VPN.

Главный принцип работы с правками от заказчика

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

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

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

Поскольку согласовать работу, как правило, сложнее, чем ее сделать, мы внутри компании решили отказаться от слова «правка». Вместо него стараемся использовать слово «замечание». Оно отражает суть происходящего: мы не правим готовый продукт, а продолжаем над ним работу с учетом замечаний заказчика.

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

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

Как поведение пользователей может подсказать, какие фичи нужны

Недавно дизайн-команда Airbnb поделилась интересным кейсом. Они заметили, что на этапе, когда пользователь бронирует жилье, хозяева квартир повторяют одни и те же действия: отправляют гостям кучу фотографий. В общей сложности — более 1,5 миллиона каждую неделю.

На снимках подсказки, которые помогают добраться до точки: фото дома, схема подъезда или местоположение ключа и т. д. Заодно прикрепляют геометки и краткие текстовые уточнения. У всех сообщений общие черты: инструкции зачастую на нескольких языках, а также арендодатель почти всегда переживает, что у гостя не будет интернета и что тот заблудится.

Это навело команду Airbnb на хорошую мысль:

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

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

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

9 типов программистов в 2024

Часть 2

(Часть 1 тут)

Интроверт

Клише-программист с минимальными социальными навыками, который всё свободное время работает или играет. В 90-е таких часто обзывали ботанами, но теперь, благодаря интернету, у них много денег и девушек.

Codefluencer

Его естественная среда обитания — не VsCode и не GitHub, а социальные сети, чаще всего Twitter. Только что узнав, как вывести "Hello World" в HTML, он постоянно публикует мемы и новости IT. Скорее всего, его зарплата выше твоей просто потому, что он умеет продавать себя.

Программист с ИИ

Искусственный интеллект изменил подходы к работе в нашей сфере. Никто не знает это лучше, чем программист с ИИ. Он пользуется новейшие инструменты — GitHub Copilot, ChatGPT, Gemini и т. д. — и выполняет работу в пять раз быстрее. Но не качественнее.

Мегаразработчик

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

Древний кодер

Последний из своего рода. Этот тип программиста старше интернета, у него длинные седые волосы и белая борода, как у Гэндальфа Серого. Он пишет код только на C или Assembly, его любимая среда разработки — VIM, а глубина его знаний превосходит человеческие.

>>Лайк Cаше и его посту, если узнали коллегу :)

9 типов программистов в 2024

Часть 1

Full-stack разработчик

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

ТехноБро

Архетип, породивший тысячи мемов. Они щеголяют дорогими гаджетами и всякими ноу-хау типа Apple Vision Pro, у них столы с электроприводом и механические клавиатуры. Они первыми используют самые новые и модные технологии на рынке и имеют завышенное ЧСВ. Но часто у них на самом деле страсть к технологиям.

Технохейтер

Это тип программиста, который знает, насколько ненадежными и опасными могут быть новые технологии, и боится, что ИИ когда-нибудь отнимет у него работу. Он в основном использует Linux и тратит много времени на создание ПО, о котором обычный разработчик никогда не слышал. Их сложно найти в интернете, потому что они заботятся о своей безопасности и тщательно скрывают свой цифровой след. Часто используют пять VPN одновременно и обладают удивительными навыками в хакерстве.

DevOps

Это программист-загадка, поскольку никто точно не знает, чем он занимается. Но он есть в каждой команде и, скорее всего, это твой начальник. Такие ребята процветают в хаосе. Они могут устранять сбои серверов с молниеносной скоростью и автоматизировать рабочие процессы одним скриптом. Возможно, поэтому они всегда такие самодовольные.

Продолжение в следующем посте.

3 нескучных приложения для бега

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

Relive

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

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

«Бег» от VK

Сервис «Бег» от VK синхронизируется с данными о тренировках с мобильных гаджетов и публикует их в приложении «ВКонтакте».

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

Zombies, Run!

Это игра для Android и iOS, где вы должны буквально убегать от зомби, чтобы выжить в мире постапокалипсиса.

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

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

P. S. А полезные для бега гаджеты мы рассматриваем в отдельной статье — сохраняйте :)

SQL vs NoSQL: как выбрать архитектуру БД для мобильного приложения

SQL (Structured Query Language) — это язык запросов, которые мы используем для работы с реляционными базами данных. У таких БД жесткая структура в виде таблиц. Вся информация там хранится в столбцах и строках. Структурированность — одно из главных преимуществ SQL баз данных.

NoSQL — нереляционные БД, у них нет жесткой структуры. Скажем, у нас есть класс — пользователи. У каждого из них есть ID, имя, фамилия и проч. Эти данные помещаются в отдельный файл (а не в таблицу), и взаимодействие происходит только с этим файлом. Вы уже не можете забрать какое-то одно поле и работаете только с этим классом.

Чтобы выбрать между SQL и NoSQL, нужно исходить из задач бизнеса.

• Если вы делаете маленькое приложение на узкую аудиторию или MVP, можно смело выбирать NoSQL. Такие базы быстрые, с ними проще работать, они легко масштабируются. А если проект растет как на дрожжах — NoSQL можно быстро переписать на SQL.

• Если вы делаете средний по объему проект, лучше SQL. Хотя, если очень хочется, можно и NoSQL. Но тут есть особенности: выбирайте NoSQL, только если у вас есть налаженные ивенты, налаженная имплементация баз данных и опыт работы с NoSQL.

• Если вы делаете энтерпрайз, лучше выбрать SQL. Представим, что в каком-то крупном маркетплейсе 10 тысяч человек оплатили покупки, но не получили товары, потому что транзакция данных прошла некорректно. Цена ошибки тут слишком высока — поэтому SQL.

Больше подробностей — в нашем блоге.

Docker Hub ушел из России. Чем это грозит?

Сегодня Docker Hub перестал работать для российских пользователей. Вместо репозитория открывается сообщение о блокировке IP-адресов в нескольких регионах мира, в том числе в Крыму. Однако сайт недоступен для всех россиян. Head of DevOps в AGIMA Дамир Грачев объясняет, почему это стало головной болью для большинства IT-компаний.

— Стресс сегодня пережили многие, потому что тема микросервисной архитектуры стала модной в последние годы и Docker Hub был популярен. Из-за его отключения, по сути, упала инфраструктура многих проектов, остановился процесс выпуска релизов. Ломается сборка докеров, пайплайны и т. д. Могут даже ломаться кластеры Kubernetes, если в них ссылка на Docker Hub без зеркала.

Эта ситуация приводит к производственным сбоям. Все отвлекаются на решение этой проблемы. А если говорить глобально, то у каких-то компаний могут возникнуть проблемы с безопасностью. Сегодня мы увидели кучу странных зеркал на Docker Hub, которым сложно доверять. При их использовании произойти может что угодно — вплоть до повторении истории со СДЭКом.

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

Stable-версия Flutter стала поддерживать WASM

WebAssembly (WASM) — это новый способ запуска приложений в браузере. Это не замена JS, а возможность запускать код, написанный на других языках (C++, Rust или C#) вместе с JS. WASM оптимизирует размер и время загрузки и позволяет выполнять его на аппаратном уровне.

Компании, которые имеют дело с графикой (Unity, Figma), используют WASM для повышения скорости работы. Это обеспечивает более плавную работу с интерфейсом за счет снижения зависимости от JS.

Скомпилированное в WASM приложение может улучшить производительность в 2 раза по скорости рендеринга кадров. На видео выше сайт Wonderous, который мигрировал с чистого JS на WASM.

Что это значит для Flutter?

А то, что движок Dart компилируется в WASM и обеспечивает более высокую производительность. Это открывает новые перспективы для веб-приложений на Flutter. Можно контролировать каждый пиксель интерфейса на уровне Flutter и наслаждаться производительностью WASM.

Ограничения

- Safari пока не поддерживает WasmGC. Браузеры на iOS, например Chrome, используют WebKit, который пока тоже не поддерживает WasmGC.

- Ни flutter run, ни DevTools не поддерживают WASM в Flutter 3.22. Однако эта функция уже реализована и должна быть доступна в следующем стабильном релизе.

- Пока во Flutter работали над поддержкой WASM, пришлось заменить библиотеки dart:html и package:js. Либы, использующие эти библиотеки, должны мигрировать.

>> Телеграм-канал Саша расскажет // о мобильной разработке и ИТ

Плюсы и минусы GetX и BLoC

1. Простота в использовании.
   
   У GetX более низкий порог входа, он проще в освоении, чем BLoC. Он предоставляет простой и понятный API для управления состоянием, маршрутизации и управления зависимостями.

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

3. Тестирование.
   
   В BLoC есть мощные средства для тестирования потоков событий и состояний, например bloc_test.

4. Возможности.
   
   GetX предоставляет широкий спектр возможностей для маршрутизации и управления состоянием и зависимостями.

Что же выбрать?

Зависит от конкретных требований проекта и ваших предпочтений. Если приложение небольшое и простое, то GetX может быть более подходящим решением. Он предоставляет понятный API для работы, с ним можно писать меньше кода, что существенно экономит время.

Однако если у вас большое приложение, то лучше выбрать BLoC. С ним вы получите более гибкий и модульный подход к управлению состоянием, а это помогает при масштабировании сложных приложений. Плюс BLoC обеспечит четкую декларативность и читаемость кода.

Это часть статьи Flutter-разработчика Айдара Мавлетбаева — полную версию с кодом ищите тут.

Стили лидерства: как их использовать в работе

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

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

Подходит для кризисных ситуаций.

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

Подходит для задач, связанных с отказоустойчивостью систем. 

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

Подходит для творческих задач.

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

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

Узнать больше о самих стилях и о том, как их комбинировать, можно в отдельной статье.

Рекомендации врача: как минимизировать риски от сидячего образа жизни

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

Чтобы поддерживать физическое состояние в норме, врачи рекомендуют раз в час выполнять 5-минутную разминку.

1. На всё тело. Достаточно вспомнить разминку с уроков физкультуры и сделать что-то подобное: пройтись, сделайте наклоны, повороты головы и корпуса, повисеть на турнике.

2. На запястье. Что можно делать: сгибать запястье одной руки при помощи другой, делать круговые движения кистями, сжимать и разжимать ладони, разводить пальцы в стороны, вращать сцепленными в замок руками.

3. На икры. Добавьте к разминке стояние на носочках, так вы защититесь от варикоза. Просто встаньте на носки и снова опуститесь на стопу несколько раз. Подъемы можно разнообразить: подниматься на носки, стоя в приседе или в наклоне.

4. На глаза. Медленно поморгайте 10–15 раз, зажмурьтесь, посмотрите в окно на предметы на разном расстоянии, «порисуйте» глазами круги, стрелки или простые картины, посмотрите стереокартинки.

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

Три совета продакт-менеджерам

1. Полезные инструменты, которые должны быть под рукой.

Продуктовые дашборды удобно строить в Tableau, а технические метрики отслеживать в Grafana. Еще могут пригодиться Amplitude для аналитики, Miro для майндмеппинга и Kaiten для управления работой продуктовой команды.

Ну и Excel/SQL — без них никуда.

2. Топ ошибок при разработке продуктовой стратегии.

1. Не продумать форс-мажор и план Б.
2. Строить стратегию, оторванную от практики, т. е. без метрик успеха, Roadmap и декомпозиции на проекты.
3. Планировать отдельно от разработки.
4. Считать только оптимистичный/обычный прогноз.
5. Закладывать риски менее 20%.

3. Как не поддаться панике, если стратегия не работает.

Работа продакта связана с высокой неопределенностью. Какие-то предпосылки срабатывают не так, как мы думали, рынок меняется, клиенты меняют решения.

Нужно понять, почему что-то не работает и найти уязвимости: проанализировать метрики, пообщаться с пользователями, провести аудит реализации. И тогда у вас появится план действий. Вам придется либо скорректировать стратегию, либо «потушить пожары», либо просто где-то поднажать, чтобы всё исправить.

Чтобы ошибаться было не так больно, к стратегии стоит относиться, как к гибкому инструменту. Любая стратегия строится на гипотезах, которые могут не подтвердиться. Сокращайте время на подготовку стратегии, делайте MVP и быстрее приступайте к ее реализации и тестам.

Это пересказ интервью с продактами из «Зоозавра», VK, World Class и AGIMA. Полная версия тут.

Резюме разработчика: на что обратить внимание

1. Одно резюме — одна позиция.

Иногда кандидаты хотят отразить в резюме все свои навыки. Поэтому в заголовках пытаются уместить всё: PHP-разработчик, Python-разработчик, QA-инженер и т. д. Но это только путает. Чем ближе заголовок резюме к названию вакансии, тем лучше.

2. Опыт интереснее всего.

В резюме можно рассказать про хобби и амбиции. Но главный блок — опыт. Перечислите основные проекты: как долго длились, какая у вас была роль. Если проект под NDA, опишите его в общих чертах. Но главное — укажите стек и задачи, которые выполняли. Всё остальное — на втором плане.

3. Важничать — плохо.

В резюме можно описать свои условия: «Ищу работу в машинном обучении, в других сферах не ищу» или «Интереснее удаленка, офис не рассматриваю». Но составлять целые списки требований — плохая идея. Это испортит впечатление от резюме.

4. Резюме должно быть читаемым.

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

5. Постоянство — плюс.

В резюме рекрутер увидит, как часто вы меняли работу. Зачастую большие компании ищут людей всерьез и надолго. Поэтому, если вы меняете места каждые полгода, вам могут не ответить. Чтобы обезопасить себя, укажите, почему увольнялись. Это снимет часть вопросов.

А еще всегда можно воспользоваться методом бутерброда. Удачи в поисках!

Готовьте кроссовки — RUNIT 2024 уже скоро!

RUNIT — самый большой ежегодный фестиваль спорта и IT в России. Он пройдет 7 июля в Москве в парке «Коломенское».

Кто будет?

В этом году на забеге соберутся рекордные 4000 участников — это разработчики, тестировщики, дизайнеры, менеджеры и все причастные к Digital-индустрии. А поддержать бегунов придут еще как минимум 2000 — их родные, друзья и коллеги.

Что будет?

Для бегунов: несколько дистанций от 3 до 25 километров, личный и командный зачет, эстафета и детский марафон. Каждый участник забега получит стартовый пакет с фирменной футболкой и чипированный номер. Ну и, конечно, медаль на финише!

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

Где и когда?

Открытие фестиваля 7 июля в 8:00. На целый день займем территорию музея-заповедника «Коломенское» в Москве. Это огромная зеленая зона с прекрасными видами на Москву-реку.

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

Билеты еще можно приобрести на официальном сайте. А самые свежие новости фестиваля — в телеграм-канале.

Ждем вас на старте!

Как развивать эмпатию

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

1. Анализировать конфликты.

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

2. Следить за своими эмоциями.

Чтобы лучше понимать другого, нужно хорошо понимать себя. Обращайте внимание на свои чувства: что вас разозлило, а что порадовало. У многих людей в одних и тех же ситуациях похожие эмоции.

3. Активно слушать.

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

4. Получать обратную связь.

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

5. Читать книги.

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

Как развивать эмоциональный интеллект и почему это важно для тимлидов, читайте в отдельном посте.