Что-то на продуктивном в первые дни зимы
Есть же такой момент, что в холодное время года вся массовая культура отправляет нас лежать с горячим какао под пледиком (вспоминаем рекламы и фильмы). И так это соблазнительно, такова романтика!
А дела и боевой настрой?) Ну вот мы и решили сделать пост об одной из практик тайм-менеджмента. Чтобы легче всякие задачки решались :)

Напомним о наших пределах
▪️ 1 задача в 1 момент времени – концентрироваться
▪️ 3 аспекта проблемы мы можем удерживать в голове одновременно
▪️ 3 секунды мы можем думать над одной мыслью непрерывно :)

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

🔺 Переключение между контекстами в среднем для нас занимает около 15 минут

Ресурсы сильны ограничены и быстро заканчиваются – как их освободить
Как мы сказали, выкинуть всё из головы – выписываем на бумагу все(!) задачи, проекты, заботы и идеи, которые на вас висят.

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

А дальше
1. Анализируем список, перевариваем и принимаем решение, что уже неактуально для нас. Зачёркиваем и выкидываем из своей головы.
2. Все проекты и задачи, которые зависят от наступления чего-то выносим в отдельный список (начну бегать, когда снег растает; фича на апруве у бизнеса). Тоже забываем на них на время.
3. Выбираем из оставшегося важное и срочное и составляем план на день/неделю.

Коллеги, которые проделали впервые эту технику, делятся: время на выполнение задач сократилось примерно на треть. А у вас есть ритуалы/лайфхаки/приёмы, которые помогают вам сохранять силы и оставаться в тонусе?)
Мы как-то опрос проводили, и там 37% сказали, что постигли джедайские техники – откликнитесь!)👇

Админ канала решил, что просто букв недостаточно для того, чтобы напомнить вам о вебинаре «QA-экстрим»)

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

☝️ Обсудим сегодня в 14:00.

С вас – регистрация по ссылке

С нас:
▪️ ответы на вопросы в прямом эфире
▪️ разбор реальных кейсов
▪️ памятка с лучшими практиками по предотвращению инцидентов после вебинара

Письмо придет на указанную при регистрации почту 😁

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

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

Ситуация. 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 правил может привести к исправлению десятков, а порой и больше сотни файлов. В устоявшейся команде, которая уже привыкла работать без линтера (да, такие существуют) весьма не просто внедрить такие изменения. И часто дело не только в привычке, но и в горящих сроках. Запланировать внедрение и рефакторинг всё-таки надо – на менее активные периоды разработки.