SimbirSoft: управление разработкой

Что можно сделать, если рабочее время утекает как песок – рассказывает Дарья, Skill Master Бывает, что мы не замечаем, как втягиваемся в обсуждения с коллегами в офисе или как листаем ленту. А вечером становится непонятно, почему мы целый день работали, а успели малую часть запланированного. Ведь отвлекались только чуть-чуть 🤷‍♀️ Полезно периодически «фотографировать» свой рабочий день – создать таблицу продуктивности, которая наглядно показывает наши пробелы и даёт возможность проанализировать, что можно изменить и как перераспределить внимание. Например, что планирование задач в спринт занимает меньше времени с утра, чем во второй половине дня. С помощью таблицы также проще анализировать, насколько задачи, которым вы уделяете больше всего времени, соответствуют вашим целям. В таблице должно быть 3 столбца (или повторяющихся строк – кому как удобнее): ▪️ Задача. Чем вы конкретно занимались. ▪️ Категория. В зависимости от цели составления таблицы категории могут быть разными: например, «личное» и «рабочее», если хотите честно подсчитать, сколько часов тратите на рабочие задачи; «коммуникация», «менторство», «менеджмент» и «статьи», если хотите видеть, как распределён фокус внимания и др. ▪️ Минуты (часы). Здесь остаётся фиксировать, сколько времени ушло на выполнение того или иного дела. Когда у нас перед глазами есть чёткая информация, нам гораздо легче понять, куда мы тратим время и что мешает двигаться вперёд. Есть среди нас коллеги, кто пробовал этот метод? Поделитесь опытом.

#резюменедели В рабочем ритме движемся успешно ✌️ Решили боевой настрой на завтра не откладывать и вошли в рейтинги TAdviser: ▪️ ТОП-50 крупнейших IT-поставщиков в топливно-энергетическом комплексе 🏭 ▪️ ТОП-20 крупнейших поставщиков BPM-систем 🖥 ▪️ ТОП-20 крупнейших IT-поставщиков в российских банках 🏦 Ну и ещё про успешный кейс в ресторанной отрасли расскажем 🤗 Наш заказчик – крупный ресторанный холдинг с 40+ заведениями по России и популярным сервисом доставки. Вот мы для него мигрировали инфраструктуру приложения в облако. Теперь управлять приложением просто, стабильно и безопасно 🙌 И, конечно, греемся воспоминаниями с крутых корпоративов!)

Выбираем опорные слова на презентации продукта – рассказывает Екатерина, PM Помните, на уроке английского в школе были слова, которые помогали определить время: usually – Present Simple, now – Present Continious. Похожий принцип я использую, когда демонстрирую клиенту итоговую работу или промежуточный результат. Я определяю, кто передо мной: аудиал, визуал, кинестетик или дигитал. Если верить статистике, то в России по 35% кинестетиков и визуалов, 25% дигиталов и всего 5% аудиалов. А дальше я строю презентацию с опорой слова-мотиваторы, соответствующие типу личности. ▪️ Визуал: здесь все понятно, как вы можете увидеть, давайте посмотрим, стоит обратить внимание, представьте, что это выглядело бы вот так, я вижу о чем, вы говорите. ▪️ Аудиал: послушайте, это звучит привлекательно, это о много говорит; как вы могли слышать, было интересно услышать его мнение. ▪️ Кинестетик: данные вызывают оптимизм, в итоге получается, с радостью могу сообщить, весомый, крепкий, прочный, надежный. ▪️ Дигитал: логично, как вам известно, я полагаю, при внимательном изучении, знаю, понимаю, рассмотрим эту деталь, очевидно, что. А у вас есть подобные лайфхаки, которые помогают донести информацию до клиента?)

​​Какие вопросы к владельцу продукта помогают снизить неопределённость – рассказывает Екатерина, PM Когда руководители проектов получают от клиента краткое описание будущей системы, настаёт время выяснить детали. Для этого у меня есть любимая техника. На мой взгляд, она максимально устраняет неопределённость – там затронуты самые основные вопросы, которые помогут клиенту и команде в будущей разработке. Рисуем квадрат и распределяем уточняющие вопросы по четырем блокам: ▪️ Пространство: где? ▪️ Время: когда? ▪️ Ресурсы: что, как, сколько? ▪️ Отношения: кто? Под постом прикрепила пример для типового приложения (вопросов будет больше, если решение специфичное. Я выделила для себя маркеры успешной первой встречи: ▪️ заданы заранее заготовленные и возникшие в ходе беседы вопросы по всем четырём пунктам, ▪️ получены ответы на половину и более заданных вопросов, ▪️ заказчик задавал встречные вопросы.

Работа с ожиданиями заказчика: лайфхаки В своей работе многие компании уже давно сделали ставку на сервис и стараются предугадывать потребности и желания клиентов. В новой статье мы решили собрать лайфхаки и рекомендации про управление ожиданиями, основанные на личном опыте наших коллег. В посте кратко описываем основные моменты. ✒ Как предотвращать конфликты: управляем «зарядом батарейки» партнёра Важный и простой на первый взгляд инструмент, про который никогда не стоит забывать во время управления проектом — коммуникации. Если в начале сотрудничества проговорить с заказчиком все его ожидания, а также ясно и открыто обсудить, что и как из этого можно реализовать, то в большинстве случаев это избавит вас от дальнейших недоразумений. Конечно, клиент представляет интересы целой компании, но он такой же обычный человек со своими проблемами и страхами, целями и желаниями. В статье мы на примерах рассмотрели, как работать с эмоциональной и рациональной реакциями, а также, как сгладить ситуацию, если «что-то пошло не так»: https://s.simbirsoft.com/bXHt ✒ Как управлять ожиданиями: лайфхаки и работающие способы Есть несколько работающих способов, применяя которые, руководитель проекта вместе с командой может «вытащить» проект из негатива или хаоса. В статье мы описали их полностью, здесь обозначим кратко: 1) Создайте общий документ с требованиями. 2) Постоянно общайтесь с заказчиком. 3) Делите проект на более короткие спринты и циклы разработки. 4) Создайте процесс управления изменениями. Мы надеемся, применение этих инструментов на ваших проектах поможет улучшить управление ожиданиями заказчика и минимизировать возможные негативные последствия недопониманий. Если у вас есть дополнения или свои рекомендации, будем рады их увидеть в комментариях.

#вопросыбизнеса Зачем участвовать в конференциях Ещё в ноябре наш ML-специалист Денис выступал на Seymartec Digital 2023 и рассказывал, как повысить вероятность успеха ML-проекта на старте. На самом форуме было много общения, интересных вопросов и докладов от коллег — особенная айтишная атмосфера) Делимся с вами интервью нашего специалиста для Seymartec ☝️

#резюменедели Вдохновляемся природой 🔊

Поставили цели, а что дальше – рассказывает Дарья, Skill Master Я адепт дисциплины, а не мотивации. Так что советую забыть о поиске вдохновения и начать выстраивать рутину: привычки будут поддерживать вас независимо от того, вдохновлены вы или нет) Несколько полезных советов, которые помогают мне: 1. Вести журнал своих прорывов. Помните ли вы, когда достигали чего-то? Обычно наш мозг лучше хранит мысли о незаконченном и несделанном) А вы храните журнал ваших успехов: фиксация результатов помогает увидеть прогресс и не остановиться. Когда у меня что-то не получается, я открываю журнал и вспоминаю: как я шла к своим целям, с какими трудностями сталкивалась и какой итог получила. 2. Создавать подходящую окружающую обстановку. Неважно, работаете вы в офисе или дома – делайте пространство «своим». К примеру, у меня на столе всегда стоит спатифиллум (цветок такой), он помогает мне настраиваться на творческий лад. А админ канала уже месяца два работает под диджей-сеты Cercle – достаточно просто включить, и это уже мгновенно переносит на рабочую волну. Периодически можно менять обстановку – это приносит оттенки свежести и больше соответствует вашему состоянию «в моменте». 3. Находить единомышленников. Идти с кем-то к цели интереснее и легче. Тут история и о взаимной поддержке, и о возможности обсуждения вопросов, и об обмене полезными находками. 4. Принимать неуспех. Это естественная составляющая развития. Когда я получила права, через неделю я ещё не могла парковаться задом. На нужной мне парковке были мои знакомые, которых я могла попросить о помощи, но мне было стыдно. Я уехала парковаться в другом месте иииии… опоздала на встречу. А можно было бы обратиться к ребятам, а на выходных ещё раз попрактиковаться, когда никуда не надо спешить) В каждом промахе заложен опыт. Важно осмыслить его, сделать выводы, не опустить руки и продолжить делать то, что нужно. Шаг за шагом, день за днём оттачивая своё мастерство. Ну и полезно уметь относиться к каким-то ситуациям и к себе с юмором, без излишней драматизации 😉 Утренние часы на 40% состоят из привычек. Привычка чистить зубы у нас выработана с самого детства. Тогда что мешает во взрослой жизни добавить в свой режим ещё одну новую привычку? Когда-то я хотела читать книгу каждый день, но вечно не хватало времени 🙃 Я решила создать привычку: каждое утро после завтрака уделяла 30 минут книге. Через какое-то время день без чтения стал уже неполноценным – я смогла читать в любое удобное для меня время с удовольствием. Сравню снова с зубами: представим, мы ночуем на природе, зубную щётку забыли, так что утром не смогли почистить зубы. Мы же сделаем это, как только у нас появится возможность! У меня теперь то же самое с книгой. Мне необязательно читать утром – это привычка, которой в течение дня я уже 100% найду время. Так минимальные стартовые действия за долгие годы и собираются в огромные изменения)

#вопросыбизнеса Пожелания бизнесу! 🎅🏼 В 2023 вы точно сделали многое – можно выдыхать, беззаботно улыбаться и по-детски наслаждаться волшебством Нового года 🎄 Мы желаем вам провести праздники в творческой паузе, чтобы порадоваться своим результатам и накопить энергию на важное в 2024! И традиционно: шлём вам с этим постом миллион сердец! Спасибо, что вы с нами – мы это очень ценим 💙

#резюменедели Подводим итоги года 🎆 В этом году прирастали новыми наградами, проектами, людьми, мероприятиями, экспертизой. Ух, столько всего было! Вспоминаем и радуемся 🤩 Спасибо команде: ▪️ тем, кто разрабатывает и тестирует, ▪️ тем, кто пишет, ▪️ тем, кто организовывает корпоративные мероприятия, ▪️ тем, кто считает ресурсы, ▪️ тем, кто прокачивает разработчиков, ▪️ тем, кто общается с клиентами, ▪️ всем и каждому. SimbirSoft – это большая команда тружеников. Все и всё для того, чтобы делать проекты ещё круче 💙

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

Разработчик не попадает в дедлайны – о чём это может говорить – рассказывает Павел, руководитель frontend-отдела Представим ситуацию. Разработчик говорит, что на решение задачи ему понадобится две недели. Тимлид уходит в отпуск… А дальше события могут развиваться по-разному, самые критичные варианты выглядят примерно так: 1. Через две недели тимлид вернулся из отпуска и пришёл к сотруднику в надежде увидеть результат – оказалось, для решения нужно ещё две недели. 2. Задача выполнена в срок, но после тестирования выявлено большое количество багов. На их устранение нужна минимум неделя. 3. Задача выполнена, но на ревью выяснилось: код не соответствует принятому стайлгайду, UI и компоненты написаны с нуля, хотя их можно было взять из UI-кита. Приведение кода к желаемому виду также займёт одну, а то и две недели. ***** Я больше 10 лет в коммерческой разработке и последние 3 года выполняю роль тимлида на проектах, а также руковожу отделом ~50 разработчиков, которые задействованы на разных продуктах по масштабу и сложности. И могу сказать, что некорректное планирование задачи на самом деле распространено. На какие моменты обратить внимание руководителю, если он столкнулся с подобным? Возможные причины 🔹 Отсутствие промежуточного контроля. Если слепо верить в корректность оценки сотрудника, можно заметить проблему слишком поздно – когда уже нет возможности скорректировать действия. А «подвести» может и достаточно опытный разработчик: например, он давно не уходил в отпуск – его продуктивность снизилась, а он продолжает оценивать «как раньше». 🔹 Несоответствие уровня решаемых задач и компетенций сотрудника. Здесь всё просто: чем выше уровень задач относительно уровня навыков разработчика, тем выше неопределённость в результате (по времени и качеству). 🔹 Нарушенные коммуникации. Например, сотруднику сообщили, что готовый компонент таблицы уже есть на проекте. Он лежит в репозитории, и его просто нужно взять. 🥁🥁🥁 Репозиториев 12 :) Тимлид в отпуске и не отвечает уже третий день. Другие участники не могут сказать, где лежит этот компонент, а сроки горят. В итоге он пилит свой велосипед, списывает на него 8 часов. На ревью через неделю ему говорят: всё удалить и использовать наше, «ведь мы же говорили взять имеющийся». Это мало того что удорожает разработку, но также в высшей степени демотивирует сотрудника. Здесь ещё играет роль отсутствие поддержки со стороны команды и плохое погружение сотрудника. В четверг напомню список must-have практик, которые помогают избегать подобных кейсов 👆

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

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

По заказу наших партнеров компании IconSoft предоставили своих специалистов для доработки масштабной информационной системы. ✔️Наше сотрудничество — это не только абсолютное погружение специалистов в проекты, обмен экспертизой и качественный результат, но и самое положительное впечатление о совместной работе. Судя по отзыву технического директора IconSoft Александра Чемоданова, это взаимно💙

5 софтскилов, актуальных для IT-специалиста в 2024 году – рассказывает Екатерина, руководитель frontend-отдела Погружая сотрудников и общаясь с клиентами, мы замечаем, какие навыки наиболее востребованы и влияют на эффективность разработки. Делимся наблюдениями по софтскилам и рассказываем о практических шагах по их развитию в нашей компании. У кого как ещё настроена система прокачки софтскилов?)

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

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

#резюменедели Новые победы на Tagline Awards🔥 Два наших проекта получили заслуженные награды на конкурсе Tagline Awards✌️ 🥇 Золото – за лучший аутстаф-проект: Подели 🥈 Напомню, что и в рейтинге Tagline-2023 мы занимаем второе место среди лучших аутстаф-разработчиков 🥉 Бронза – за лучшее импортозамещающее IT-решение: Linkory А вот ещё полезности от нас: Как быстро заключить договор по T&M: 5 инструментов 2 недели до Нового года — не сбавляем обороты 🫶

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

Что делать, если клиент пришел с проектом перед Новым годом – рассказывает Ринат Шамшутдинов, руководитель 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. Презентация прошла хорошо. После мы в спокойном темпе доработали проект и успешно его завершили🤘