Помозгоштурмим? Выгорание ключевого сотрудника

Экспериментируем с новым форматом, который так и называется – «Помозгоштурмим?») В нём мы будем предлагать «жизненную» ситуацию из рабочих будней и накидывать свои предложения, как её решить. Рубрика будет выходить в разных форматах – сегодня это диалог «каким он мог бы быть».
Зовём и вас делиться своим опытом: как удалось или не удалось разобраться с подобными кейсами, что помогает. Просто написать «жизааааа» тоже можно – админу будет приятно 😅

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

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

🧑‍💻 (разработчик) Я не успеваю, ничего не успеваю. Я постоянно уставшая, у меня не хватает времени, при этом постоянные переработки. Просто приходишь на работу – смотришь на комп и тупишь долго в начале.
🦸 (PM) Я правильно понимаю: ты приступаешь к работе, смотришь на всё, что нужно сделать по плану, и не знаешь, с чего начать? Голова идёт кругом – и желания нет стартовать?
🧑‍💻 У нас горят сроки, у нас куча задач, постоянные созвоны – с командой, с аналитиками… Я даже переключаться не успеваю. У меня каша в голове, апатия – хоть бросай всё и увольняйся(
Не знаю, что с этим делать, концов этому не видно. Это уже всё длится долгий период. Никто не может сказать, когда это всё кончится.
🦸 Смотри, а эти переживания связаны с проектными событиями или внешние факторы влияют?

Полный диалог с комментариями читайте в Телеграфе. Там мы разобрали такие причины выгорания разработчика:
▪️ он не успевает и не укладывается в оценку
▪️ приоритеты меняются
▪️ постоянные митинги отнимают время.

Эту рубрику мы создали, чтобы обмениваться опытом друг с другом:
▪️ Что ещё может беспокоить выгоревшего сотрудника?
▪️ Каково работать с выгоревшими людьми?
▪️ Какие практики можно посоветовать?
▪️ Как вы отслеживаете состояние ваших сотрудников?
… и любые другие ваши замечания, эмоции и идеи по этой теме)

#резюменедели
О продуктивности писать – продуктивными быть (админ канала)

ПЛАН_ФАКТ за неделю
Мероприятия
✅ Провести QA-митап в Пензе. Рассказали мы там и о том, как переходили на новую CMS 1С-Битрикс, и как подготовить данные для нагрузочного тестирования, и даже как проблемы на проекте преобразовать в точки роста 🚀
✅ Провести «QA-экстрим». Вебинар прошёл так продуктивно, получилось обсудить всякое: как сделать проект менее чувствительным к текучке кадров, как мотивировать сотрудников на неинтересные задачи… всего, конечно не перечислишь. В общем, ждём всех на следующем прямом эфире)

Комментарии
✅ Дать комментарий «Ъ»: Как российские производители выбирают между отечественными мобильными ОС

Кейсы
✅ Рассказать о наших проектах:
▪️ Решение для управления складом для металлургического предприятия
▪️ Развитие приложения для «Асконы»

Отдыхаем на выходных с классными воспоминаниями 🤩

Что делать, если клиент пришел с проектом перед Новым годом
– рассказывает Ринат Шамшутдинов, руководитель mobile

Контекст:
Дело было несколько лет назад. Под самый конец года к нам обратился клиент – 21 января он планировал показать MVP-версию мобильного приложения инвесторам. В конце декабря он понял, что предыдущий подрядчик, кажется, не успевает. И пришёл к нам с кодом для оценки – сможем сделать или нет.

Вёрстка была прекрасная,
Всё остальное было ужасное пустое.
(Если бы Сапгир был айтишником)

Я тогда был разработчиком. Вот проверяю полученный код, проверяю, проверяю и понимаю – интеграции никакой нет, бизнес-логика не заложена. У нас есть вёрстка :) Словно предыдущий подрядчик показывал клиенту «прогресс», на самом деле демонстрируя лишь вёрстку. Получается, экран как бы есть – кнопки нажимаются, но «под капотом» ничего не происходит 🥲

Ну что? Погнали!)

Итак, при каких условиях на такой проект можно соглашаться
1. Заказчик принимает риск. В таких условиях непонятно, сколько точно по времени займёт доработка. Вёрстка-то она статичная, а вот прикрутить динамические компоненты, логику при подключении к серверу – это совсем другое дело. То есть мы сказали, что мы согласны попробовать и постараемся успеть. НО подготовили заказчика к тому, что может возникнуть форс-мажор. Он доверился нам.
1.2. Заказчик не требует оценку по фиксе.

2. У вас есть PM и достаточно специалистов, которые готовы вписаться в такую авантюру. На тот момент PM’а с нами не оказалось, но в лодке было:
▪️ трое разботчиков: накидали архитектуру (решили делать с нуля, так было проще), поделили между собой бизнес-фичи, оттолкнулись от основных сценариев для презентации 21 января;
▪️ руководитель mobile: поддерживал нас в процессе и сделал интеграцию с AWS для загрузки файлов;
▪️ заказчик: докручивал backend на Битриксе.

Мы, разработчики, восприняли всё это как челлендж, который интересно выполнить. С 3 января мы работали full-time 5/2. Через две недели готова была версия для тестирования. Если команда не готова к такому, откажитесь от проекта.

3. Уровень разработчиков позволяет им работать по Scrum. Даже если они не задумываются об этом. Мы каждый день обновляли статусы фич, следили за диаграммой Ганта, чтобы точно успеть протестировать и исправить баги. Нам дали задачу – сделать мобильное приложение. Мы пошли и сделали – составили список задач, спланировали их выполнение и распределили. В общем, чистый Scrum) Взяли ответственность на себя и самоорганизовались)

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

5. С самого начала с заказчиком – контакт. Невозможно одолеть такой проект, если вы не будете единым механизмом. Тут мы разговаривали на одном языке, нам не нужно было объяснять приоритет фич для MVP, почему мы начали с нуля и т.д. Это сохраняло силы и время.

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

Считаем, коллеги!

#резюменедели
Новые победы на Tagline Awards🔥

Два наших проекта получили заслуженные награды на конкурсе Tagline Awards✌️

🥇 Золото – за лучший аутстаф-проект: Подели
🥈 Напомню, что и в рейтинге Tagline-2023 мы занимаем второе место среди лучших аутстаф-разработчиков
🥉 Бронза – за лучшее импортозамещающее IT-решение: Linkory

А вот ещё полезности от нас:
Как быстро заключить договор по T&M: 5 инструментов

2 недели до Нового года — не сбавляем обороты 🫶

#вопросыбизнеса

Какие языки программирования и технологии будут актуальны в 2024 году
– рассказывает Антон, архитектор

Коротко, за 3,5 минуты – с мини-аналитикой запросов от клиентов 🤗

Как работать со сроками на больших проектах? 🤝

5 софтскилов, актуальных для IT-специалиста в 2024 году
– рассказывает Екатерина, руководитель frontend-отдела

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

У кого как ещё настроена система прокачки софтскилов?)

#резюменедели
Порадовались отзыву клиента ☺️

«Если ребята из SimbirSoft, то в принципе интервью можно не проводить»
IconSoft

По заказу наших партнёров — компании IconSoft — предоставили своих специалистов для доработки масштабной информационной системы.

✔️Наше сотрудничество — это не только абсолютное погружение специалистов в проекты, обмен экспертизой и качественный результат, но и самое положительное впечатление о совместной работе.

Судя по отзыву технического директора IconSoft Александра Чемоданова, это взаимно💙

Разработчик не попадает в дедлайны – о чём это может говорить
– рассказывает Павел, руководитель frontend-отдела

Представим ситуацию. Разработчик говорит, что на решение задачи ему понадобится две недели.
А дальше события могут развиваться по-разному, самые критичные варианты выглядят примерно так:
1. Через две недели тимлид пришёл к сотруднику в надежде увидеть результат – оказалось, для решения нужно ещё две недели.
2. Задача выполнена в срок, но после тестирования выявлено большое количество багов. На их устранение нужна минимум неделя.
3. Задача выполнена, но на ревью выяснилось: код не соответствует принятому стайлгайду, UI и компоненты написаны с нуля, хотя их можно было взять из UI-кита. Приведение кода к желаемому виду также займёт одну, а то и две недели.

*
Я больше 10 лет в коммерческой разработке и последние 3 года выполняю роль тимлида на проектах, а также руковожу отделом ~50 разработчиков, которые задействованы на разных продуктах по масштабу и сложности. И могу сказать, что некорректное планирование задачи на самом деле распространено. На какие моменты обратить внимание руководителю, если он столкнулся с подобным?

Возможные причины
🔹 Отсутствие промежуточного контроля. Если слепо верить в корректность оценки сотрудника, можно заметить проблему слишком поздно – когда уже нет возможности скорректировать действия. А «подвести» может и достаточно опытный разработчик: например, он давно не уходил в отпуск – его продуктивность снизилась, а он продолжает оценивать «как раньше».
🔹 Несоответствие уровня решаемых задач и компетенций сотрудника. Здесь всё просто: чем выше уровень задач относительно уровня навыков разработчика, тем выше неопределённость в результате (по времени и качеству).
🔹 Нарушенные коммуникации. Например, сотруднику сообщили, что готовый компонент таблицы уже есть на проекте. Он лежит в репозитории, и его просто нужно взять.
🥁🥁🥁
Репозиториев 12 :) Тимлид в отпуске и не отвечает уже третий день. Другие участники не могут сказать, где лежит этот компонент, а сроки горят. В итоге он пилит свой велосипед, списывает на него 8 часов. На ревью через неделю ему говорят: всё удалить и использовать наше, «ведь мы же говорили взять имеющийся». Это мало того что удорожает разработку, но также в высшей степени демотивирует сотрудника.
Здесь ещё играет роль отсутствие поддержки со стороны команды и плохое погружение сотрудника.

В четверг напомню список must-have практик, которые помогают избегать подобных кейсов 👆

Включаем разумный контроль
– рассказывает Павел, руководитель frontend-отдела

В предыдущем посте я поделился одной из частых проблем на проектах – непопадание разработчика в дедлайны. Этот и другие негативные кейсы можно избежать, если отследить в самом зачатке и отработать. Основной инструмент здесь – контроль. Моя цель сегодня – ещё раз подсветить его важность и дать must-have практики: от созвонов до процессных моментов.
Это не ноу-хау, но иногда надо возвращаться к базе и проводить экспресс-скрининг. А то бывает уходишь в дебри, работаешь со сложными инструментами, а за ними забываешь о простом и сердитом)

1. Ежедневный статус голосом. Здесь отслеживаем, чем человек занимался в течение дня, и определяем есть ли у него проблемы. Если команда большая или поджимают сроки, статус можно собирать текстом. А возникшие вопросы – обсуждать точечно. Важно (!): один раз в неделю обязательно нужен созвон для обсуждения вопросов голосом.

2. Ежедневные коммиты.
Даже если задача выходит за рамки одного дня и не завершена, необходимо чтобы сотрудник коммитил свою работу за день. В таком случае мы:
▪️ понимаем, что сотрудник пишет код, который соответствует кодстайлу, и движется в правильном направлении;
▪️ снижаем вероятность, что в задаче на 20 часов активная работа начинается в последние 8;
▪️ в случае если разработчик заболел, (/недоступен для связи/ уволился/ у него вышел из строя компьютер/ компьютер украли…) максимальная потеря кода будет не более 8 часов.

3. Декомпозиция задач
Лучше, чтобы подзадача не занимала более 6 часов. Бывают редкие ситуации, когда задачу разбивать мельче чем на 10–15 часов избыточно – тут в игру вступают ежедневные коммиты.

4. Распределение задач
У тимлидов существует подход – давать сотруднику максимально разноплановые задачи, чтобы любой мог заменить любого. Я и сам его приверженец: люблю, чтобы задачи у разработчиков были посильные, но и в то же время достаточно сложные и интересные для них. Так сотрудник постоянно развивается и сохраняет высокий уровень мотивации и лояльности проекту и компании.
К сожалению, в реальной разработке абсолютизировать этот подход не получается. Часто у нас есть на выполнение задачи 8 часов, и мы не можем позволить себе дать её джуну, который будет сидеть с ней в 2–3 раза дольше.
Чем слабее сотрудник, тем более мелкие задачи ему нужно давать: лучше ~ 2–4 часа. Это же правило действует для сотрудников на этапе погружения, чтобы:
▪️ быстрее определить реальный уровень сотрудника,
▪️ быстро заметить, если сотрудник не справляется,
▪️ снизить уровень стресса сотрудника на входе.

5. Актуальная и понятная документация по производственным процессам
В каком состоянии документация на проекте? – Если не описан Flow, то первым делом внимания требуют:
▪️ правила описания задачи при её создании,
▪️ правило перехода задачи из одного статуса в другой, кто становится ответственным для каждого статуса;
▪️ git-flow проекта: правило создания, именования, мёрджа и удаления веток + правило описания коммитов.
На написание инструкции нужно не более четырёх часов + ознакомительный созвон. Чтобы зафиксированные правила выполнялись, первые три недели потребуется пристальное внимание, а когда все привыкнут, усилий нужно гораздо меньше.
Наличие этого документа на 3–5 страницы экономит часы времени на погружении и минимизирует вопросы в процессе работы.

6. Линтер и форматировщик кода*
Пункт со звёздочкой, потому что не всегда получается внедрить линтер. Когда кодовая база уже большая, добавление 3–5 правил может привести к исправлению десятков, а порой и больше сотни файлов. В устоявшейся команде, которая уже привыкла работать без линтера (да, такие существуют) весьма не просто внедрить такие изменения. И часто дело не только в привычке, но и в горящих сроках. Запланировать внедрение и рефакторинг всё-таки надо – на менее активные периоды разработки.

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

А какие ещё простые полезные практики есть в вашем must-have арсенале?)

#вопросыбизнеса
Пожелания бизнесу! 🎅🏼

В 2023 вы точно сделали многое – можно выдыхать, беззаботно улыбаться и по-детски наслаждаться волшебством Нового года 🎄

Мы желаем вам провести праздники в творческой паузе, чтобы порадоваться своим результатам и накопить энергию на важное в 2024!

И традиционно: шлём вам с этим постом миллион сердец! Спасибо, что вы с нами – мы это очень ценим 💙

Поставили цели, а что дальше
– рассказывает Дарья, Skill Master

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

Несколько полезных советов, которые помогают мне:
1. Вести журнал своих прорывов. Помните ли вы, когда достигали чего-то? Обычно наш мозг лучше хранит мысли о незаконченном и несделанном) А вы храните журнал ваших успехов: фиксация результатов помогает увидеть прогресс и не остановиться. Когда у меня что-то не получается, я открываю журнал и вспоминаю: как я шла к своим целям, с какими трудностями сталкивалась и какой итог получила.

2. Создавать подходящую окружающую обстановку. Неважно, работаете вы в офисе или дома – делайте пространство «своим». К примеру, у меня на столе всегда стоит спатифиллум (цветок такой), он помогает мне настраиваться на творческий лад. А админ канала уже месяца два работает под диджей-сеты Cercle – достаточно просто включить, и это уже мгновенно переносит на рабочую волну.
Периодически можно менять обстановку – это приносит оттенки свежести и больше соответствует вашему состоянию «в моменте».

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

4. Принимать неуспех. Это естественная составляющая развития. Когда я получила права, через неделю я ещё не могла парковаться задом. На нужной мне парковке были мои знакомые, которых я могла попросить о помощи, но мне было стыдно. Я уехала парковаться в другом месте иииии… опоздала на встречу. А можно было бы обратиться к ребятам, а на выходных ещё раз попрактиковаться, когда никуда не надо спешить)
В каждом промахе заложен опыт. Важно осмыслить его, сделать выводы, не опустить руки и продолжить делать то, что нужно. Шаг за шагом, день за днём оттачивая своё мастерство. Ну и полезно уметь относиться к каким-то ситуациям и к себе с юмором, без излишней драматизации 😉

Утренние часы на 40% состоят из привычек. Привычка чистить зубы у нас выработана с самого детства. Тогда что мешает во взрослой жизни добавить в свой режим ещё одну новую привычку?
Когда-то я хотела читать книгу каждый день, но вечно не хватало времени 🙃 Я решила создать привычку: каждое утро после завтрака уделяла 30 минут книге. Через какое-то время день без чтения стал уже неполноценным – я смогла читать в любое удобное для меня время с удовольствием.
Сравню снова с зубами: представим, мы ночуем на природе, зубную щётку забыли, так что утром не смогли почистить зубы. Мы же сделаем это, как только у нас появится возможность! У меня теперь то же самое с книгой. Мне необязательно читать утром – это привычка, которой в течение дня я уже 100% найду время. Так минимальные стартовые действия за долгие годы и собираются в огромные изменения)