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

Ставим задачу так, чтобы исполнитель понял 👍

Контрольные точки – проверяем, что на проекте всё хорошо Допустим, вы занимаетесь разработкой системы. Недавно перед командой поставили новые амбициозные задачи с жёсткими сроками. Работа кипит, однако вы замечаете, что уже третий спринт в релиз выходит гораздо меньше задач, чем вы запланировали. Если бы на проекте была внедрена метрика возврата задач, то вы смогли бы выявить и решить проблему на ранней стадии. Например: когда такой показатель больше 20%, то это сигнал, что пора разобраться – возможно, дополнительно обсудить ТЗ с участниками команды. Нужные метрики подбираются индивидуально под каждый проект и позволяют контролировать процесс создания продукта. Как правило, к базовому набору относят следующие: ▪️ План-факт. Позволяет выявить отклонения в данных в большую или меньшую сторону от намеченного результата и вовремя скорректировать действия команды. ▪️Burndown. Демонстрирует, какой объём работы уже выполнен и сколько задач осталось решить до завершения спринта/проекта. Помогает отслеживать темп работы и понимать, когда следует ускориться. ▪️Процент возврата задач — как часто таски приходят на доработку. Благодаря этой метрике, мы вовремя можем заметить сложности на проекте и быстро их пофиксить. ▪️Процент Bug Fix. Показывает отношение часов, затраченных на разработку ко времени багофикса. Благодаря этим данным, мы сможем быстро обнаружить, что команда больше занимается багами, чем созданием продукта. И исправить ситуацию до завершения спринта. Мы в SimbirSoft ежедневно проводим мониторинг около 15 показателей по проектам (сроки, качество, бюджет и т.д.). Таким образом мы видим все «движения» в организации и можем вовремя заметить отклонение.

#резюменедели Порадовались отзывам клиентов 🥰 +1 отзыв на Wadline от ЮMoney: «Высокие стандарты разработки Simbirsoft делают нашу совместную работу над проектами проще и эффективнее» 😎 Получили награды 🏆 В нашей копилке разные достижения – в этот раз заняли 1 место в турнире по лазертагу на UL CAMP) Рассказали о проекте 🔏 Сервис автоматизации финансовой аналитики для «МК Лизинг»

Бесконечные правки и новые требования перед релизом Контекст ☝️ Такое произошло с нашим менеджером по управлению проектами Екатериной. Под её руководством была команда, которая «под ключ» создавала для заказчика корпоративный портал. На старте с клиентом согласовали техническое задание и макеты, утвердили логику работы и roadmap, а после каждого спринта проводили демонстрацию разработанного. Внезапно в компании заказчика изменился ответственный за проект специалист с другим видением портала. И вот дата релиза уже не за горами, а в работу прилетели новые фичи. Что делать?.. 🤔 Екатерина провела с клиентом приоритизацию новых фич, а затем их оценку. Проверила, что из этого списка команда точно успеет сделать и взять в релиз, а по остальным задачам предложила несколько вариантов: 1) Выпустить MVP-версию, а после составить план по доработке портала и внести дополнительные фичи. 2) Увеличить команду, если важно взять в релиз все и успеть вовремя. 3) Сдвинуть дату релиза. Чтобы принять решение, нужно было донести до клиента: ▪️ плюсы и минусы каждого решения; ▪️ информацию о том, что каждую новую фичу необходимо не только разработать, но и протестировать, а также заложить на это ресурсы; ▪️ свериться с бюджетом проекта и определить, какие из этих шагов можно себе позволить уже сейчас, а какие позже. Совместно с клиентом мы решили придерживаться согласованного ранее плана, выпустить MVP-версию, утвердить новые фичи и их приоритет, а затем доработать портал.

#резюменедели ✔️ Опубликовали чек-лист: набор метрик, который поможет управлять проектом и обеспечивать его качество Он поможет узнать, насколько эффективна ваша команда сейчас, проверить уровень качества проекта и подскажет, как можно улучшить работу. Выступили с докладом на онлайн-конференции DIGITAL ЛЕТО от Roistat Наш sales-менеджер Павел рассказал про новые инструменты контент-аналитики в B2B — возможности и кейсы применения. Рассказали о проектах  🔏 Аудит инфраструктуры комплексного решения для ресторанного холдинга

Что в итоге мы изменили у себя в процессах 1. Ввели архитектурный надзор в каждом производственном направлении. Проводим ревью разрабатываемой архитектуры на контрольных точках проекта, которые определяют PM. 2. При тестировании используем только релевантные данные и строго это контролируем. Это помогает увидеть реальную картину и проработать корректные требования для продукта. 3. Проводим минимальное нагрузочное тестирование продукта, даже если клиент считает, что оно не нужно. И анализируем необходимость полноценных нагрузочных тестирований на каждом проекте, чтобы понять, сколько пользователей выдержит инфраструктура продукта и какие «узкие» места в ней есть. 4. Не делаем релизов в предвыходные и предпраздничные дни :) P.S. Когда я села писать историю об этом кейсе, у меня даже мысль возникла: «А как мы это упустили? У нас же есть контроль на уровне архитектуры и сбора требований». А потом поняла: да это же как раз после этого инцидента ввели :))) Разработка без ошибок – это в идеальном мире. Самое главное – делать выводы, учиться на ошибках и непрерывно улучшать процессы создания программных продуктов.

Как «неудавшийся» релиз привёл к изменению в процессах – рассказывает Екатерина Ремизова, наш директор по качеству Безмятежное начало Мы работали над классным проектом – приложением для online-тренировок. Под него собрали команду из аналитика, дизайнера, backend-, Android- и iOS-разработчиков, QA-специалиста и проектного менеджера. Первый релиз состоялся 20 октября. И только за первый месяц работы уже было 50+ тысяч скачиваний. «А всё, а всё! А надо было раньше…» – никто тогда не знал К Новому году мы с клиентом запланировали релиз дополнительных функций приложения и публикацию нового курса тренировок, рекламная кампания которого уже была в разгаре. Для самых быстрых предложили скидки, поэтому много пользователей уже были на низком старте. Всё подготовили, осталось дождаться окончания проверок от AppStore и Google Play. И вот 30 декабря проверки закончились, а на 31 декабря клиент запланировал релиз – ему хотелось побыстрее запустить его. Мы пошли у него на поводу... Запах мандаринов покинул чат Вечер 31 декабря, обновление выпущено в прод, команда расслабилась и ушла нарезать оливье и смотреть «Иронию судьбы». В 19:54 появилось первое предупреждение о высокой нагрузке на базу данных. А спустя ещё час некоторые видео перестали открываться или прогружались долгое время. Суммарные загруженные данные вышли за предел, который был заложен в приложении и учтён в аналитике. Вся команда была на телефонах, бросила дела и начала разбираться в ситуации. Backend-разработчик связался с DevOps и предложил донастроить кеширование на стороне СУБД.В 21:53 поняли, что дело плохо: на экранах пользователей появилась ошибка. В итоге за несколько часов до Нового года мы получили срыв запуска продукта. Как потушили пожар В 22:46 команда настроила кеширование и увеличила производительность сервера. Приложение начало работать. Но мы понимали, что это временно: принятые меры не решали проблему. Поэтому Новый год все члены команды встречали у компьютера, чтобы подключиться к работе в нужный момент. А с 1 января приступили к исправлению ситуации и подкорректировали код. До 5 января мониторили работу продукта: в процессе выскакивали проблемы с кешем Redis. После этого продукт работал без инцидентов, а мы смогли выдохнуть и начать работу над ошибками.

С чего начать выстраивать работу службы качества Мы в SimbirSoft начали выстраивать работу службы качества ещё в 2012 году. Тогда были, конечно, немного другие условия, требования и бизнес-процессы. Но нижеперечисленные действия — базовые, они актуальны и сейчас. Шаг 1. Сформировать команду из штатных специалистов Сотрудники службы качества должны быть погружены во внутренние процессы — знать обо всех тонкостях и целях компании. Можно нанять внешних специалистов, но основная часть команды должна быть из «своих». Количество сотрудников в команде СК может быть разным — всё зависит от объёма задач. Шаг 2. Определить обязанности и сферу деятельности, разработать и внедрить стандарты Разработайте стандарты, на основе которых СК будет оценивать качество продукта и процессы компании. Опираться можно на собственный опыт — принять в качестве эталона лучшие процессы и практики, которые уже действуют в организации. И на базовые методологии: Agile, Waterfall, канбан, ISTQB — универсальную программу тестирования — и другие. Главное, не внедрять всё подряд, а выбирать то, что подойдёт вашей компании, исходя из её целей и компетенций. За основу стандарта проведения внутренних аудитов можно взять ISO 19011 — «Руководящие указания по проведению аудита систем менеджмента». Адаптируйте его под вашу компанию. Например, мы используем этот стандарт для двух направлений. • Основное. Поэтому оптимизировали этот стандарт таким образом, чтобы проводить параллельные аудиты быстрее. Упростили процесс интервью и сбор данных. А ещё автоматически рассчитываем метрики качества и прочее. • Дополнительное — наём сотрудников. Здесь мы ничего не меняли, так как нам подошли стандартные процессы. Когда команда СК знает, на что ориентироваться, — можно считать, что она готова к работе уже на 50%. Шаг 3. Отслеживать работу компании с помощью службы качества Проводить аудиты и оценивать результаты тоже можно по ISO 19011 — это один из самых логичных и понятных стандартов. Все результаты аудитов и инцидентов фиксируются. Из этой статистики можно выделить повторяющиеся ошибки. Далее СК анализирует ошибки, которые из раза в раз встречаются в разных проектах, выявляет их причины и предлагает решения. Сколько нужно времени На внедрение СК мы советуем закладывать около года — за такой срок получится сформировать команду, разработать документацию и организовать основные процессы. С технической стороны создать СК можно быстро, больше всего времени уходит на психологическую адаптацию. Сотрудникам нужно погрузиться в процессы обеспечения качества, перестроиться с разработки на аналитику. Другим отделам необходимо привыкнуть к критике от аудиторов и проникнуться доверием к ним, особенно если раньше в компании этого не было. Мы в SimbirSoft выстроили настолько доверительные отношения между командами, что после стольких лет работы коллеги стали сами приходить в службу качества с просьбой провести внеплановый аудит.

Зачем нужна служба качества в IT-компании – рассказывает Екатерина Ремизова, наш директор по качеству Служба качества (СК) помогает организовать все процессы в компании так, чтобы продукт был готов в срок с минимальными затратами, соответствовал задачам бизнеса и ожиданиям пользователей. Чем занимается СК: ▪️ устанавливает и внедряет стандарты процессов разработки, ▪️ согласовывает критерии качества продуктов, ▪️ разрабатывает и внедряет метрики, по которым можно оценить качество работы всей компании, ▪️ отслеживает уровень удовлетворенности клиентов, ▪️ проводит аудиты работы на каждом уровне организации, в производственных и вспомогательных процессах, которые обеспечивают её работу. А без службы качества можно? Если в компании нет чёткой системы обеспечения качества, могут возникнуть следующие проблемы: 🔹 Сложно воспроизводить процессы в компании. При старте очередного проекта всегда приходится выстраивать разработку с нуля. СК организует все процессы один раз, а потом немного их корректирует и адаптирует под новые условия. Например, у нас на каждом проекте внедряются таск-трекер и базовые метрики: план-факт, процент возврата задач, процент Bugfix. 🔹 Возрастает цена ошибки. Исправить недоработку, когда продукт уже готов, дороже, чем если выявить её при разработке. И дешевле, если сделать это на этапе формирования требований. СК помогает системно подойти к вопросу качества продукта и не допустить типовых ошибок на всех этапах. Мы считаем, что СК нужна всем компаниям независимо от масштаба, ведь любому бизнесу необходимо контролировать процессы, предотвращать ошибки, а также вовремя выявлять и исправлять недоработки. Завтра расскажем, как начать выстраивать работу службы качества, а в пятницу – историю, когда неудача на проекте привела к изменениям в процессах. P.S. «85% проблем качества вызваны процессами производства и только 15% – исполнителями». Джозеф Джуран – архитектор качества, экономист, теоретик менеджмента, автор «Справочника по контролю качества».

#резюменедели Получили награды 🏆 ▪️ Заняли места в ТОП-10 и ТОП-20 рейтингов RAEX среди крупнейших IT-компаний ▪️ Попали в ТОП-100 крупнейших IT-разработчиков, по версии CNews Поделились важным 💙 Это сейчас у нас большая команда из 1300+ человек с 6 офисами в разных городах России и филиалом в США. А начиналось всё с маленького кабинета, 4 увлечённых программированием человек и банковского проекта из Японии. Вернуться вместе с нами в 2001 год и посмотреть, как росла наша SimbirSoft теперь можно на странице с нашей историей 📝 Рассказали о проектах 🔏 ▪️ Сервис рассрочки для маркетплейса ▪️ Оптимизация работы мобильного приложения для ритейла ▪️ Модернизация системы управления производственным предприятием в 1С: ERP Отпраздновали юбилей сотрудничества 🎊 Уже 15 лет мы партнёры с Международной цифровой олимпиадой «Волга-IT»! В 2008 году подключились к олимпиаде – взрыв, буря, эмоции!☺️ А теперь ежегодно являемся одними из организаторов мероприятия и разрабатываем задание для дисциплины по Java и C#.

Six Sigma В Six Sigma концепции фокус на качество и на удовлетворение клиентов. Чтобы достичь этого, нужно сокращать ошибки в организации и исполнении процессов. Компоненты: ☺️ Удовлетворение потребителя. Определяем и учитываем все требования клиента. ☺️ 🔀 Выявление процессов, показателей и методов управления. На всю цепочку процессов смотрим через призму потребностей клиента, ориентируемся на неё и корректируем при необходимости. ☺️ 🔀 🤝 Командная работа. Чтобы улучшение отдельных процессов было более скоординированным, обеспечиваем прозрачность для всех участников. Отлаженная командная работа поможет добиться качества. 5 шагов DMAIC (define, measure, analyze, improve, control – определять, измерять, анализировать, улучшать, контролировать) 1. Определяем основные проблемы, формируем команду по улучшению процесса и прописываем зону ответственности. 2. Чтобы выяснить текущее положение проекта, проводим измерение процессов. 3. Анализируем полученные данные, устраняем причины и предлагаем методы по устранению причин. 4. Разрабатываем способы внедрения улучшений в процесс. 5. Заносим в документацию и контролируем улучшения после изменения процессов. Где подходит Six Sigma можно применять на проектах, где отлажена командная работа, так как внедрение концепции происходит за счёт управления отдельными задачами и процессами – они улучшаются независимо друг от друга. При этом нужен постоянный контроль, чтобы система не перестала функционировать, пока происходят изменения.

Lean В Lean-подходе фокус на непрерывное улучшение бизнес-процессов без радикальных изменений. Так мы не рушим существующую структуру и, соответственно, избегаем связанных с этим проблем. 🏚🏗🏰 Сломать всё и построить круто с нуля? – Нет. 🏚🏠🏡🏘 Шаг за шагом совершенствовать? – Да. Принцип 5s: ▪️ sort – сортировка операций на значимые и ненужные, ▪️ set in order – упорядочивание предметов и процессов, ▪️ shine – поддержание порядка и чистоты, ▪️ standardise – внедрение норм и организация порядка для реализации правил, ▪️ sustain – совершенствование за счет мотивации и самодисциплины работников. 1. Устраняем потери. Анализируем процессы и выделяем всё то, от чего можно отказаться. Например, дополнительные, но ненужные пользователю фичи; несколько разрозненных каналов связи для передачи информации по проекту и др. 2. Повышаем качество. Встраиваем тестирование с начальных этапов разработки. 3. Создаём знания. База данных проекта поможет как команде, так и клиенту. 4. Откладываем «обязательства». Имея несколько вариантов, не стремитесь сразу принимать решение, а отсрочьте его на безопасный для проекта срок. Когда придёт время, будет больше доступной информации, поэтому будет легче сделать корректные выводы. Сравнение планируемых и фактических показателей поможет корректировать оперативные решения. 5. Организовываем быстрый выпуск. Частые релизы помогают отслеживать процесс реализации продукта и попадание в ожидания клиента. 6. Уважаем мнение людей. Универсальный принцип – важно прислушиваться к команде, поскольку они непосредственно участвуют в процессах. 7. Оптимизируем целое. Важно определить главную ценность и цель продукта и выстраивать разработку уже от них. Исправляем в первую очередь важные этапы, чтобы потом не переделывать несколько раз. Так минимизируются потери времени на неверную стратегию реализации. Пример: как устранить потери в проектах Оптимизируем и сокращаем «бесполезные» митинги, документацию, огромные описания процессов до понятного и простого минимума. Когда мы отсекаем все ненужные процессы, упрощаем подходы, ставим на поток постоянное обучение новому и полезному, то автоматически повышаем качество продукта и запускаем его на бесперебойный конвейер релизов. Где подходит Поскольку Lean заточен на скорость, методику целесообразно применять там, где нужно максимально быстро проверить гипотезу. Например, при создании MVP.

Lean и Six Sigma в управлении проектами – рассказывает Екатерина, наш PM ☝️ Эти методики – следующие по популярности после Agile. Открыты уже давно, правда изначально разрабатывались для совершенствования процессов на производстве. Теперь «дошли» до образования, IT и других сфер. Рост интереса к адаптации методик Lean и Six Sigma в IT, на мой взгляд, можно связать с тем, что в непростых экономических условиях практически от каждого руководителя IT-проекта или целого IT-департамента бизнес требует сокращения затрат без потери качества. Обзорно о методиках В концепции Lean (бережливое производство и управление) главный критерий – ценность продукта для бизнеса и вовлечённость всей команды. Впервые внедрили в Toyota для устранения потерь и уменьшения затрат без ухудшения качества. Six Sigma – метод управления и совершенствования производства через выявление и исключение причин дефектов в бизнес-процессах, а также концентрацию на требованиях потребителя. Здесь была первой Motorola. Они хорошо подходят для больших компаний и проектов, где нужно максимально быстро проверить гипотезу или улучшить качество уже действующего продукта, например, когда он перешёл к вам на доработку после предыдущего подрядчика. Lean используют «РЖД», «Почта России», «Сбер»; а Six Sigma – «РОСТАР», «Инструм-Рэнд», «АВИСМА». Как показывает практика нашей компании и мой личный опыт PM, методики Lean и Six Sigma помогают развивать системное мышление, решать нестандартные задачи и непрерывно улучшать процессы и продукты, удовлетворяя все запросы клиентов. В условиях быстро меняющихся реалий и требований рынка это очень актуально. На этой неделе разберём каждую методику по отдельности, и я расскажу, для каких проектов и задач они подходят лучше. Завтра ждите пост о Lean, а в четверг – о Six Sigma.

Как Linkory поможет вашему бизнесу Помните, мы писали про наш стартап в сфере маркетинга и продаж?) Рассказываем подробнее 😎👇 Все действия клиентов отслеживаются в режиме онлайн. Linkory покажет, что и когда смотрят ваши клиенты в реальном времени, а также пришлё уведомления о посещении страниц. Благодаря аналитике сервиса вы сможете: ▪️ видеть действия клиентов, которым вы отправили ссылку; ▪️ увидеть, где в КП у клиента возникают сложности; ▪️ напомнить о себе сразу после прочтения предложения, пока вы ещё в голове клиента; ▪️ подготовиться к следующему созвону. Если пользователь долго был на слайде «цены», возможно, ваши услуги для него дороги. Объясните ценности вашей работы и почему она так стоит. Всё это поможет сделать предложение лучше и увеличит ваши продажи. Помните, что аналитика это совместная работа отделов маркетинга и продаж. Подружите их между собой 🤝 Связаться с нами можно тут: 📍 https://s.simbirsoft.com/VjSB 📩 mail@linkory.io 📱 8(495)-179-38-33

#резюменедели Поучаствовали в мероприятии 🗣 30 июня выступали на конференции ПРО.TECH в Краснодаре. Руководитель отдела QA SimbirSoft Екатерина рассказывала про применение ИИ в бизнесе: как машинное обучение помогает решать трудоемкие задачи. Дали комментарии СМИ 📰 Коммерсантъ: Минпромторг планирует финансировать проекты в области внедрения технологий искусственного интеллекта (ИИ) в промышленности, учредив АНО, которая займется их отбором. Рассказали о проектах 🔏 ▪️ Миграция баз данных: как за 4 месяца переехать с Oracle на PostgreSQL (на примере компании из государственного сектора). ▪️Как использовать машинное обучение (Machine Learning) для роста бизнеса — поделились, какие проекты мы уже реализовали, и что вы можете применить для своего бизнеса в новом видео

Наши партнёры веб-интегратор Extyl уже пару лет ведут канал о digital-разработке: рассказывают, как выигрывать тендеры, управлять командой и считать бюджеты. Делимся полезными постами: 🔹 Как выйти из операционки в бизнесе? 🔹 Синдром самозванца: почему возникает и как с ним бороться 🔹 Нанимать или взращивать? Откуда брать руководителей 🔹 Как выигрывать тендеры? 🔹 Способ мошенничества в тендерах Это наш топ, но внутри ещё много полезного – посмотрите 😉

Почему источник требований важен для команды Кейс Заказчик одного из проектов рассказал нашему ПМу, что 70% требований идёт со стороны их внутренней службы поддержки, так как конечный пользователь системы – крупный банк. Конечно, это неудобный и несистемный способ мониторить запросы клиента. Наша команда моментально отреагировала на данный факт и внедрила автоматическое отслеживание ошибок, чтобы точнее понимать, с какими трудностями сталкиваются пользователи. Более того, ребята предложили устраивать предрелизные демонстрации конечному клиенту, чтобы формировать его ожидания от новых релизов. Всё это привело к следующим результатам: ▪️ более глубокая аналитика, благодаря пониманию источников требований, ▪️ снижение нагрузки на саппорт, ▪️ долгосрочное сотрудничество с клиентом. Что из этого следует На первых этапах важно познакомить специалистов с представителями бизнеса и владельцем продукта, донести до заказчика важность контакта. Команда должна понимать источники требований, цели разработки IT-решения и портрет конечного пользователя. Впоследствии это поможет расставлять приоритеты, понимать, для чего разрабатывается та или иная фича, улучшать план тестирования и т.п. Коммуникации должны быть направлены на снижение рисков, связанных с долгой передачей информации о новых требованиях, изменением сроков или отсутствием обратной связи. Сотрудничество команды разработки и клиента помогает достичь общей цели.

Как развивать soft skills 1. Для системного развития soft skills критически важно определить свои слабые стороны, например, с помощью комплексного метода оценки компетенций — ассессмента, и получить объективные результаты. 2. Важно принять эти результаты, упорядочить данные и выявить те навыки, которые нужно прокачать. 3. После этого необходимо составить план обучения на основе конференций, книг, тренингов по выбранной теме. 4. Окончив обучение, нужно рассказать коллегам о том, какие знания ты получил. Это помогает систематизировать полученную информацию и ещё раз пройти обучение внутренне.

Последний день недели – время подводить её итоги) Провели мероприятие 🗣 70+ комментариев получили, на 20+ вопросов ответили, дополнительные материалы участникам отправили 🍾 Теперь наши участники знают о «Цене ошибки» больше 😉 Получили награды 🏆 Первые в рейтинге digirate среди digital-подрядчиков по выручке в 2022 году 🥇 Дали комментарии СМИ 📰 Коммерсант: Промышленникам добавят интеллекта Эксперт: IT-сектору пообещали новые миллиарды на решение старых проблем #резюменедели

Разработка под ключ, но не с нуля 🧐 Как организовать? Кейс На одном проекте нам надо было реализовать единую систему управления для всех производственных процессов. До этого заказчик пользовался двумя сервисами: во-первых, это было неудобно, во-вторых, функциональности не хватало. Так вот нашей задачей было объединить их преимущества и полностью покрыть бизнес-процессы. Документации на них не было. Как организовывали процесс 1️⃣ В таком проекте важно работать в тесном контакте с командой заказчика, чтобы каждая заинтересованная сторона знала о необходимых изменениях, задачах и их актуальности. Поэтому ещё на этапе сбора требований мы определили и зафиксировали каналы и формат коммуникаций: ▪️ планировали встречи через google-календари примерно в одно и то же время, чтобы обеспечить максимальную посещаемость; ▪️ обговаривали повестку встречи заранее и прописывали тайминг встреч; ▪️ фиксировали достигнутые договорённости письменно и оповещали все заинтересованные стороны. Всё это помогло нам выстроить эффективную коммуникацию с клиентом и наладить работу с ожиданиями. 2️⃣ После того как произвели приемку сервисов клиента, мы погрузились в продукт и стали анализировать логику и требуемый к переносу функционал. Составили ТЗ, в котором отразили реализацию 5 блоков бизнес-процессов, а также сформировали дорожную карту этапов разработки. Для того чтобы учесть все узкие места, мы провели QA-ревью документации и предоставили заказчику финальную версию. 3️⃣ В основе команды на этапе разработки остались погруженные в проект специалисты (аналитик, QA, архитектор). Кроме того, была проработана архитектура предложенных решений: описаны технологии, требования модулей, интерфейсы взаимодействия. Это обеспечило ускоренное погружение разработчиков.