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

Как критиковать, чтобы вдохновлять
— рассказывает Светлана, PM

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

Ни один Сидоров на самом деле не пострадал — это вымышленный персонаж, как и его импульсивный начальник. Диалог выше — это яркий и наглядный пример деструктивной критики.

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

Выбираем сервисы в зависимости от нужд проекта и целей PM ☝️

P.S. + означает, что инструмент предлагает данный функционал на конец декабря 2023 года)

23 года! 1575 сотрудников в компании! 1200 (даже больше) реализованных проектов! И просто много любви к IT!

Ва-ааа-у! С Днем рождения, SimbirSoft 💙

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

CEO Алексей Флоринский: "А начиналось все с маленького кабинета, 4 человек, увлеченных программированием, и банковского проекта из Японии. Вернуться вместе с нами в далекий 2001 год и посмотреть, как росла SimbirSoft можно на странице с нашей историей"💙

Есть же такой соблазн на собеседованиях – рассказать про весь свой специфичный инструментарий в багаже и ещё про то, что уже в школе были старостой и «менторили» пятиклашек)
Как всё-таки презентовать себя и свой опыт на встрече с клиентом? – в видео 😅


А вы сами встречали на собеседованиях разработчиков, которые «активно формошлёпничают, кнопочки красят и апишечки причёсывают»?)))

#резюменедели
Совпадение недели – попали в 5 рейтингов. Эмоция недели – гордииимся 😏💙

По версии TAdviser мы…
🥉 в тридцатке крупнейших поставщиков IT-услуг
🥈 в двадцатке крупнейших IT-поставщиков в российских банках
🥇 в десятке крупнейших игроков на рынке IT-аутсорсинга

hh.ru в одиннадцатый раз провёл исследование и составил рейтинг работодателей. И мы заняли в нём 21 место среди крупных компаний в сегменте «IT и интернет». И в Хабровском рейтинге у нас такие же результаты – 20 место ✌️

Наш директор по качеству Екатерина Ремизова выступила на конференции CNews и поделилась опытом контроля бизнес-процессов: зачем нужна система менеджмента качества, как команда из 4 человек проаудировала за полгода 480 проектов и что им помогает 🦸

Делимся кусочками выступления и ответа на один из вопросов. Ну и как же без фоточек)

Давайте поговорим! Открываем чат в комментариях 💁

Возьмём стандартный проект, в состав команды которого входят — проджект-менеджер (PM), тимлид, аналитик, разработчики и QA.

Насколько глубоко должен быть погружен проджект-менеджер в каждую задачу? Должен ли он проверять итоговый результат по каждой задаче или достаточно контроля исполнения по срокам?

Чтобы не сходить с ума от штиля – погружаемся в шторм мобильной разработки! Ух, и оседлаем эту волну 🌊

P.S. Без регистрации всё ещё никак) Но благо это быстро.

Что учесть при взаимодействии с клиентом: управляем зарядом батарейки
– рассказывает Андрей, PM

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

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

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

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

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

🪫 Как разряжается рациональная батарейка клиента
Тут всё просто – делать долго, дорого и/или некачественно. В процессе такого «поведения» не избежать нескольких резких рациональных и эмоциональных «разрядок».

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

#вопросыбизнеса
В каких случаях проводят аудит качества кода
– рассказывает Ринат, руководитель Mobile-направления

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

▪️ Для анализа качества продукта, если реализует его сторонний подрядчик. Аудит позволит убедиться в качестве реализованных решений.

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

▪️ Есть вопросы к работе текущей команды проекта: много багов, «вечный» рефакторинг и т.д. Аудит поможет понять, какие проблемы есть в приложении и расставить приоритеты для их исправления. Исследование причин ошибок – это отдельный аудит.

▪️ Для оценки готовности приложения к масштабированию и другим амбициозным планам по его развитию.

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

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

#резюменедели
Китайский Новый год, друзья! Окунаемся в сказочную атмосферу ✨

Что делать, когда Кощей похитил Новый год, потому что не успел сдать проект? 🦹🏻‍♂️

Вместе с детьми наших IT-специалистов нашли рецепт, но у нас есть только его начало:
1. Пойти по SCRUM-дороге, у которой нет ни начала ни конца
2. Составить точный план сказочного мира на митинге с Гудвином, Львом и Страшилой
3. Очистить репу от багов…

А окончание похоже найдётся в их приключениях 🪄 Вжуууух, переносим вас в мир, нарисованный дизайнерами Изумрудного города. Магия начинается…

Неполное описание задачи в таск‑трекере? – Не надо так 😶
– рассказывает Екатерина, руководитель QA-направления

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

Что делать, если такое иногда происходит в команде
1. Напомните команде, чем это может грозить
▪️ Разработчикам и QA-специалистам потребуется больше времени, когда они будут брать фичу в работу. Сначала специалист пойдёт изучать требования в базе знаний, потом уточнять их у коллег, процесс затянется, при доработках снова придётся вспоминать, о чём вообще это всё было.
▪️ Больше вероятности, что задача, вернётся на доработку. Если у задачи отсутствует подробное описание с требованиями, то разработчик может не понять, чего именно от него ждут. Поэтому задача, скорее всего, вернётся на доработку, а того, кто её ставил, попросят уточнить техническое задание.

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

Специфика зарубежных проектов
На иностранных продуктах мы замечаем закономерности в подходах к работе. Решили поделиться ими в посте)

1. Отлаженный процесс онбординга
Каждый сотрудник получает план на первые месяцы работы: какие доступы настроить, в какие задачи погрузиться. Помимо этого, к новичку приставлен buddy – сотрудник из той же команды, который знакомит с коллегами, помогает погрузиться в продукт и предстоящие задачи.

2. Метод кнута и пряника недопустим, во всём приветствуется гибкость
Во время code review специалисты стараются не «тыкать»: «ты сделал неправильно»,, «ты не учел». Вместо этого используется подход с позиции «мы»: «у нас возникла проблема», «не хотим ли мы это поменять». Вместе с высокими требованиями к hard-скиллам здесь есть принятие того, что человек может ошибиться. Сложно представить ситуацию, при которой члена команды отчитали бы за промах публично.

3. На первом месте качество
Как и на любом IT-проекте, клиенту важно укладываться в дедлайны. Однако если команда по объективным причинам не успевает в срок, руководство не будет форсировать события, ведь в приоритете – качество продукта. Задачу вынесут в следующий релиз, чтобы пользователь не получил сырой продукт. Когда менеджер хочет как можно быстрее выложить фикс бага, он говорит об этом заранее, и команда укладывается в срок без необходимости работать сверхурочно.

4. К слову о переработках: их, как и само явление трудоголизма, компания не приветствует
Сотрудника, пришедшего на рабочий созвон в свой выходной, ненавязчиво отправят отдыхать. Здесь ценят не только работу, но и отдых, и чётко следуют идее work-life balance – лучшей защите от эмоционального выгорания.

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

6. Высокий уровень лояльности руководства опирается на не менее высокие требования, и в первую очередь – к soft-скиллам сотрудников
На проектах российских заказчиков мы привыкли к жёстким оценкам, в том числе сроков выполнения задачи. На иностранных более лояльны к срокам, но цена этого – автономность работы. Конечно, если специалист обратится за помощью, никто не откажет, но здесь ждут, что специалист разберётся в задаче сам, не отрывая от работы коллег..


Какие трудности приходится преодолевать чаще всего
▪️ Самое очевидное – языковой барьер. Работа в интернациональной команде предполагает свободное общение на иностранном языке: все общие созвоны и митапы проходят на английском, а специфика продукта обязывает также владеть и технической лексикой.

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

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

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

Несколько лет назад мы внедрили автоматизированную систему поддержки оценки.

Мы аккумулируем в общей базе опыт решения типовых задач, оценённый в часах (планируемых и фактических).
⬇️
Периодически корректируем оценки типовых задач на основе обновлённой информации.
⬇️
Используем наборы готовых решений, которые связывают различные этапы реализации системы. Так, типовая функция системы имеет оценку на различных этапах: от аналитики и проектирования до реализации и тестирования.
⬇️
Оценку проекта проводим в два этапа. На первом детально оцениваем аналитику, архитектуру и проектирование системы. Этап реализации, тестирования и внедрения оцениваем рамочно – для общего понимания сроков и бюджетов, которые могут корректироваться.
Второй этап оценки запускается после завершения этапа аналитики и проектирования, когда команда более детальное погрузилась в проект и у неё есть понимание сроков.

Мы видим такие плюсы подхода:
▪️ База данных нормо-часов – строится на основе реализации типовых задач на проектах – позволяет получить средневзвешенную оценку без привлечения экспертов. Это значительно сокращает время расчёта и экономит время специалистов.
▪️ На выходе получается детальная и развёрнутая спецификация, которая содержит все виды работ с описанием и указанием количества часов.

Этот инструмент помог рассчитать 1000+ проектов и продолжает хорошо показывать себя.

#резюменедели
Суббота у нас сегодня читательская)

В статье для it world рассказали, как технологии ИИ используются в процессах разработки. Вы знали, что разработка с применением ИИ-инструментов на разных стадиях жизненного цикла ПО к 2028 году может достигнуть 75%? 🤯

С ComNews поделились мыслями об импортозамещении:
▪️ Первая российская АБС мигрировала на импортонезависимые СУБД
▪️ Что мешает провести импортозамещение вовремя. Считаем, что заменить иностранное ПО полностью до 1 января 2025 года – это амбициозно. Чтобы сделать это, надо:
1. обеспечить достаточное количество качественного российского ПО
2. подготовить кадры для работы с ним
3. обучить конечных пользователей

В кейсе – как усилили команду Zetra на проекте микросервиса веб-приложения для экстренных служб 👩‍🚒 Среди вызовов – сложная архитектура, состоящая из 50 микросервисов, отсутствие детализации ТЗ и сжатые сроки)

SMART и делегирование в работе руководителя
– рассказывает Ирина, руководитель отдела QA

Когда растишь отдел, очень хочется работать с профессионалами, которым можешь доверять: поставить задачу – и быть уверенным, что она будет сделана. Чтобы было именно так – важно вкладываться в своих сотрудников с самого начала:
1. делегировать,
2. ставить задачи по SMART,
3. расставлять приоритеты между ними (и объяснять, почему именно так и не иначе).

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

→ Ставишь задачу, назначаешь ответственного, ограничиваешь во времени, обозначаешь точки контроля

И можно не называть это SMART’ом, но это будет он, пусть и в супер-лайтовом виде)

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

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

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

Мы это всё к чему? 👆 – В наших пользовательских руках всё больше смартфона. И по количеству, и по времени, между прочим.

И ещё недавно разработка приложений для этих самых смартфонов была стабильной и понятной. Но оказалось, не только жизнь общажная полна сюрпризов :)

Так давайте 29 февраля обсудим этот вопрос! А именно:
▪️ актуальную ситуацию на рынке разработки мобильных приложений
▪️ современные решения в создании мобильных сервисов и тренды в поведении пользователей
▪️ опыт и кейсы бизнеса по преодолению блокировок и ограничений
▪️ состав идеальной команды разработки мобильного приложения
▪️ инхаус, аутсорс или аутстафф в мобильных проектах: что выгоднее бизнесу и при каких условиях

– Чем же всё это окончится? – Будет апрель март.
– Будет март, вы уверены? – Да, я уверен.

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

Ну какова красота! Регистрация тут: https://s.simbirsoft.com/NKc6)

P.S. Админ собрал отсылки для всех возрастов, 😎 – если понял все три. А остальным солнышко придётся ставить, а то как же солнечные очки без солнца)