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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

ДНК проекта в IT
— рассказывает Светлана, PM

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

▪️ Одна из основ — проектная и техническая документация.

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

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

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

▪️ Вторая основа — итоговая цель проекта. И каждый участник процесса работы над IT-проектом должен четко ее понимать — от заказчика до исполнителя. Критерии SMART говорят следующее: цель должна быть конкретная, измеримая, достижимая, значимая и ограниченная во времени. Идеальным вариантом будет фиксация цели в цифровых показателях, например, в числах.

Цели у проектов могут быть самые разные: от проверки гипотезы до автоматизации процессов на производстве.

▪️ Даже если у вас уже есть документация и зафиксированы цели, то без третьей составляющей ничего не выйдет — это команда разработки.

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

В частности, тренд tone of voice тоже можно отнести к IT. Только рассматривать его как принцип общения в команде, которого придерживаются во всех каналах коммуникаций (мессенджерах, почте, звонках и т.д).

Итак, ДНК проекта:
▪️ документация,
▪️ цель,
▪️ команда.

Все это приведет проект к успешному завершению, а также поможет получить клиенту запланированную прибыль.

А что для вас ДНК IT-проекта?)

Авторам (всем нам) «Лучше потом зарегистрируюсь, чтобы сообщение в почте далеко не улетело» посвящается 🤗

«Пото́м» – уже сегодня! Регистрация тут

Встречаемся через 5 часов)

P.S. Эксперты круглого стола:
▪️ Андрей Евглевский, Директор по информационным технологиям сервиса «Подели»
▪️ Максим Гришутин, Руководитель отдела iOS-разработки в Ozon, владелец и автор канала Prefire iOS
▪️ Ринат Шамшутдинов, Руководитель направления мобильной разработки SimbirSoft
▪️ Дмитрий Григорьев, Владелец и автор канала Mobile_compose

Регистрация скоро закроется — мероприятие скоро начнётся)

#резюменедели
А нас и тут, и там показывают!

На телеканале «ПРОБИЗНЕС» вышло интервью с нашим CEO Алексеем Флоринским) Делимся видео и коротко рассказываем основные тезисы:
▪️ удалёнка и офисный коворкинг: как мы нашли для себя идеальный формат работы,
▪️ как изменились требования к специалистам на IT-рынке, где растёт спрос, а где появилась просадка,
▪️ искусственный интеллект (ИИ) — как он применяется в SimbirSoft, каких специалистов заменит на IT-рынке и какое будущее с ИИ нас ждёт.

Алексей в интервью рассказывает, что за последние 2 года заказчики стали требовать более сильных IT-специалистов. Вы заметили это на своих проектах?