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

Восстановление системы после неудачной разработки — один из вариантов услуг, которые мы оказываем нашим клиентам. Каждый случай специалисты SimbirSoft внимательно анализируют, чтобы в своей работе исключить ошибки предыдущего подрядчика. Единого шаблона разработки продуктов нет. Все процессы формируются и настраиваются в зависимости от бизнес-цели конкретного клиента и потребностей конкретного проекта. Используя многолетний опыт в заказной разработке и требования международного стандарта ISO 9001:2015 мы сформировали чек-лист, который поможет избежать возможных инцидентов. 📌 Ведение подробной документации на проекте. Сюда относятся не только требования к продукту и техническое задание, но и тест-кейсы, API, описания кода. Это позволяет проверить систему на соответствие целям и облегчает процесс подключения новых специалистов к проекту. Инструменты также играют весомую роль в выстраивании процессов. 📌 Таск-трекер — это система для удобной постановки задач и отслеживания времени, затраченного на работу. Он помогает понять статус, текущее состояние разработки, найти описание каждого бага и проследить историю создания продукта от самого первого таска. Трекинг всех задач и затраченного на их реализацию времени помогает членам команды понимать состояние проекта и оценивать, не вышел ли он за какой-то критический порог. 📌 Workflow — это жизненный цикл задачи, правила смены её статусов — от момента ее постановки до полного исправления, проверки и закрытия. Благодаря этому команда находится в одном информационном поле и понимает текущее состояние реализации каждой фичи. Правильно построенный workflow позволяет избежать лишних коммуникаций, митингов и путаницы. 📌 Коммуникации — встречи и созвоны — помогают быстрее решить сложные вопросы и обсудить все детали. Не менее важно выстроить общение между командой и клиентом. Например, демонстрация выполненных работ после каждого спринта позволит погрузить заказчика в процесс разработки продукта и удовлетворить его ожидания. 📌 Метрики — это показатели разработки продукта, которые позволяют контролировать процесс его создания и проверять соответствие срокам, бюджету и требованиям качества. Они подбираются индивидуально под каждый проект. В числе базового набора: План-факт позволяет выявить отклонения от намеченного результата и вовремя скорректировать действия команды. Burndown показывает объем выполненных работ и количество нерешенных задач до завершения спринта/проекта. Процент возврата задач — данные по количеству тасков, отправленных по какой-либо причине на доработку. Эта метрика позволяет вовремя заметить сложности на проекте и быстро их решить. Процент Bug Fix — показывает отношение часов, затраченных на разработку, ко времени багофикса. Благодаря этим данным, мы сможем быстро обнаружить, что команда больше занимается устранением багов, чем созданием продукта, и исправить ситуацию до завершения спринта.

Для стабильной работы при пиковых нагрузках, предупреждения кризисов и учета рисков важно сохранять устойчивость IT-системы. Обеспечить ее стабильное функционирование поможет нагрузочное тестирование сайта или приложения. Мы задали о нем несколько вопросов нашим специалистам – спешим поделиться их ответами. 💬Когда нужно проводить нагрузочное тестирование? Наиболее правильный подход – включение нагрузочного тестирования в процесс разработки. Его следует проводить, как и регрессионное, каждый раз после внесения корректировок в продукт, поскольку исправления кода могут повлечь за собой изменения в части производительности. Отдельно следует упомянуть предсказуемые увеличения нагрузки на сервис во время рекламных акций или перед сезонными всплесками пользовательской активности, например, перед «Черной пятницей». Лучше заранее спрогнозировать такие случаи и протестировать нагрузку еще до выхода релиза в продакшн, чтобы избежать возможных проблем. 💬Стресс-тесты и нагрузочное тестирование – это одно и то же? Стресс-тесты – один из видов нагрузочного тестирования. Они позволяют получить представление о том, как продукт ведет себя в период пиковой нагрузки, а также оценить возможность восстановления системы после такого максимума или даже полного отказа. 💬Что тестировать: производительность или нагрузку? Чтобы понять, соответствует ли продукт обозначенным требованиям в различных сценариях, необходимо протестировать систему под нагрузкой. Далее идет сбор метрик системы (например, пропускной способности) и сервера (например, утилизации процессорного времени). На основе полученных данных можно сделать объективный вывод о производительности системы. 💬Сколько запросов выдержит система? Если нет требований к пропускной способности системы, то для ответа на этот вопрос необходимо подавать нарастающую нагрузку, увеличивая ее вплоть до отказа. Далее следует провести тест на подтверждение стабильной работы продукта, когда он нагружен на 80% от полученного максимума. Исходя из результатов такого тестирования, делается вывод о том, сколько запросов система способна выдержать, сохраняя при этом стабильность. Об этапах нагрузочного тестирования и его преимуществах при различных сценариях вы можете подробнее прочитать здесь: https://www.simbirsoft.com/blog/kogda-i-kak-my-provodim-nagruzochnoe-testirovanie/. 🧐А что еще вы хотели бы узнать о нагрузочном тестировании?

Через полторы недели, 21 февраля в 14.00 (по мск), SimbirSoft проводит бесплатный вебинар, на котором вместе с экспертами компании обсудим следующие вопросы: 🔼 Как не наступить на старые грабли при смене подрядчика и правильно передать проект новой команде разработки? 🔼 Какие ошибки можно допустить при проработке проекта и к чему они могут привести? 🔼Почему до начала разработки важно продумать все нефункциональные требования к ИТ-продукту и к каким последствиям может привести их несоблюдение? Ссылка на вебинар придет вам в день мероприятия на электронную почту, указанную при регистрации https://s.simbirsoft.com/2Kd4 До встречи в эфире! Будем вас ждать)

Потребность в ИТ-архитекторах продолжает расти, особенно с переходом бизнеса в онлайн. Ведь одна из главных их задач - сделать ИТ-решение гибким и долговечным, а также снизить затраты на разработку за счет подбора грамотных решений, инструментов и шаблонов на этапе подготовки концепции проекта. 🔥 Руководитель архитектурного комитета Антон Мартынов рассказал изданию РБК, что входит в обязанности таких специалистов, чем они могут быть полезны бизнесу, а также о том, как получить эту востребованную профессию и добиться в ней успеха. Подробнее https://s.simbirsoft.com/JPhz А как часто вы прибегаете к услугам ИТ-архитекторов? #SimbirSoft #IT

📱 8,1 миллиарда приложений установили в App Store в третьем квартале 2021 года (https://s.simbirsoft.com/2JXR). Разместить ПО на этом маркетплейсе можно только после тщательного ревью от Apple. Компания модерирует каждую сборку, чтобы выявить различные проблемы и не допустить появления некачественных продуктов в их сторе. ✔️ Мы уже 13 лет занимаемся мобильной разработкой, поэтому всегда в курсе актуальных изменений гайдов и знаем, что нужно учесть, чтобы успешно пройти проверку от AppStore. На картинках кратко и просто рассказываем о самых распространенных причинах отказа в публикации приложения в маркетплейсе. А какие пункты гайдов Apple вы бы добавили к нашей подборке? #mobile_SimbirSoft #IT

👆Оценка трудозатрат – важный и ответственный этап при разработке ИТ-продукта. Она позволяет построить путь к достижению конечной цели заказчика – готовому решению – и требует внимательного подхода от ИТ-компании и клиента. За более чем 20 лет разработки ИТ-систем разной сложности мы накопили большой опыт предварительной оценки проектов. В среднем за год специалисты нашей компании анализируют по 400 идей клиентов, даже при отсутствии подробного технического задания или иной документации. Руководитель департамента бизнес-решений Анна Шведова рассказывает, как выстроенные в нашей компании процессы позволяют проводить предварительную оценку ИТ-проекта быстро, точно и прозрачно. Подробнее здесь: https://s.simbirsoft.com/KcN3. В завершении вы найдете чек-лист, который поможет вам подготовиться к брифингу с подрядчиком 🔥

🔺6. Не давайте обратной связи Участники команды должны понимать вас на интуитивном уровне. А если этого не происходит, дело в сотруднике – меняйте, пока не найдете нужного. ✅ Вы же работаете не с роботами! Обратная связь важна каждому члену команды. Она может поднять уровень мотивации и подсветить точки роста. Всегда приятно услышать от более опытных коллег о своих достижениях и обсудить с ними, каким образом можно справляться с задачами еще лучше. 🔺7. Не проводите ретроспективы Зачем тратить дополнительное время? На проекте и так много митингов и коммуникаций. ✅ Ходят слухи, что ретроспектива помогает команде развиваться! Во время обсуждения участники совместно, учитывая мнение каждого, выявляют точки роста, пути развития и распределяют задачи по выполнению того или иного улучшения – зарождается командная ответственность. Так можно и до кайдзен дойти! Надеемся, вам помогли наши вредные советы!

В мире вредных советов Workflow препятствует успеху проекта, а делегирование ответственности ни к чему хорошему не приводит. И, между прочим, только TeamLead или Project Manager должны знать всю информацию о ходе проекта, а остальным в команде это не нужно… Рассказываем, что делать, чтобы все полетело в тартарары 🙃 🔺1. Не выстраивайте workflow Разработчики сами разберутся, как нужно работать, а в статусе ваших тасков появится еще одна характеристика: «хаос». На выяснение деталей участники команды потратят дополнительное время, которое могли бы потратить на выполнение задач на проекте. ✅Благодаря workflow команда работает более эффективно, так как все специалисты находятся в одном информационном поле и понимают текущее состояние реализации каждой фичи. С его помощью просто и быстро обнаруживается, на каком этапе «застрял» процесс, а также сокращаются временные лаги между блоками работы. 🔺2. Не проводите планирование спринтов с командой Участникам команды совершенно не нужно понимать цель и сроки очередной итерации. Пусть каждый реализует задачи на свое усмотрение. Вы же хотите, чтобы конечный результат вас удивил. ✅Привлекая команду к планированию спринтов, вы выстраиваете единую картину реализации проекта, учитываете все детали. Возможно, кто-то из сотрудников уже работал с выбранной технологией, знает о нюансах и скрытых сложностях, которыми поделится со всеми. Так он может предостеречь от неверного плана и подскажет, как упростить задачи. Отсутствие плана, вероятнее всего, приведет к несоразмерной занятости команды или неправильной расстановке приоритетов и подтолкнет проект к срыву дедлайна. 🔺3. Перенагружайте команду Выгорать нельзя отдыхать. Поставьте запятую после первого слова – и в течение проекта вас будут сопровождать безынициативность и непродуктивность. ✅ Когда специалисты могут выполнить свои задачи в срок, при этом не выходя за рамки 8-часового рабочего дня, у них остается достаточно свободного времени для отдыха и восстановления. Такой баланс даст им возможность не просто быть исполнителями, но творчески подходить к вопросам, например, предлагать идеи по реализации задач. 🔺4. Не назначайте ответственных и не делегируйте Зачем руководителю развивать сотрудников, формировать их ответственность и создавать себе подушку безопасности, когда можно все взвалить на себя. После десятого выгорания его организм точно выработает иммунитет (спойлер: нет). Концентрирование обязанностей на одном человеке приведет к тому, что снизится вовлеченность всех участников, и они не будут ощущать свою значимость. Если TeamLead временно не сможет выполнять свои функции, например, из-за болезни или командировки, никто не заменит его. В итоге возрастет риск приостановки проекта. ✅Делегирование позволяет расширять компетенцию команды и формировать ответственность каждого участника за результаты, а руководителю – сохранять продуктивность и work-life balance. 🔺5. Сконцентрируйте весь набор знаний в голове одного или двух разработчиков Чем шире кругозор специалистов, тем больше вероятность того, что от них можно получить ценный совет по улучшению работы. А настоящему руководителю подсказки не нужны. Когда на проекте всего несколько хранителей знаний, опасное значение принимает bus factor («фактор автобуса»). Так называют количество членов вашей команды, при постоянном отсутствии которых работа попадет в кризисное положение ☹️ Чем показатель выше, тем лучше: от 3-5 и более, в зависимости от команды. Если все знания сосредоточены на одном специалисте, он равен единице. В таком случае к катастрофе может привести любой больничный этого сотрудника или его незапланированный отпуск. ✅Нужно заранее подумать о том, как обеспечить циркуляцию знаний внутри команды, назначить ответственных, распределить сложные задачи между разными разработчиками. Разбор затруднительных моментов проекта лучше проводить вместе со всеми участников. Тогда «супермены» команды смогут в доступной форме задокументировать информацию о реализованных ими решениях и подсказать лучший выход в тех или иных условиях.

🌇 Почему дизайн интерфейса — не просто красивые картинки? Качественный дизайн интерфейсов отличает продуманная логика, архитектура, четкая геометрия и удобный для пользователя способ решения задач. По словам Стива Джобса, дизайн — это не только то, как выглядит продукт и на что он похож, но и то, как он работает. Поэтому если мы хотим создать IT-сервис для бизнеса, необходимо думать не столько о красоте, сколько о его пользе для потребителя. ✔️ В нашем портфолио свыше 50 разработанных дизайн-систем. На основе имеющегося опыта мы выделили несколько основных условий, которые важны для создания хорошего интерфейса. На этапе предварительного исследования важно проанализировать рынок (выявить конкурентов, изучить механики и пр.), обозначить структурные проблемы и пути решения, сформировать цели и задачи, которые будут стоять перед продуктом. Это позволит понять: ▪️ кто наши пользователи и какие проблемы они решат с помощью продукта; ▪️ с какими вопросами они столкнутся в процессе эксплуатации IT-системы; ▪️ как мы можем улучшить опыт использования продукта; ▪️ какая стратегия развития увеличит прибыль. В результате исследования получаем: ▪️ информационную архитектуру продукта; ▪️ карту пользовательского пути; ▪️ характеристику групп потребителей; ▪️ описание болей и их решение; ▪️ первые прототипы продукта. Дальнейшие шаги: ▪️тестирование на группах пользователей; ▪️ внесение корректировок в решения; ▪️ создание полноценного черно-белого прототипа; ▪️ разработка минимально жизнеспособной версии продукта (MVP). После этого можно перейти к визуализации решения: подбору цвета, созданию иллюстраций, оформлению страниц, иконок и пр. Что такой подход к дизайну дает бизнесу? По данным исследования McKinsey (https://s.simbirsoft.com/vNBM), правильно спроектированный дизайн помогает бизнесу увеличить окупаемость инвестиций и опережать конкурентов. В результате: ▪️ пользователи не уходят к конкурентам, столкнувшись с перегруженным дизайном; ▪️ снижается риск неудачного запуска, так как продукт интуитивно понятен; ▪️ возникает минимум проблем для разработчиков, что экономит время; ▪️ сокращаются затраты на поддержку и развитие продукта. #design_simbirsoft #IT

Более 20 лет мы занимаемся разработкой, изучаем и применяем сотни новых технологий, чтобы наши программные решения соответствовали современным тенденциям и удовлетворяли потребности пользователей. Сегодня мы поделимся опытом реализации веб-приложения с помощью Blazor. 📌Blazor — это новый UI-фреймворк от компании Microsoft, который позволяет создавать интерактивный веб-интерфейс. Благодаря этому инструменту приложения могут работать как на стороне сервера, так и на стороне клиента. ➡️В 2020 году для медицинского учреждения мы разрабатывали систему для хранения карточек и работы с записями во время приема доктора. В качестве наиболее оптимального варианта платформы для UI-части мы выбрали приложение Blazor WebAssembly. С помощью него нам удалось: 🔹Использовать единую кодовую базу для WebApi и Blazor. В результате получилось принимать модели, которые отправляет наш API, и с помощью новых данных достаточно быстро переписывать сервисы. 🔹Написать код полностью на C#. Это повысило производительность системы, а также обеспечило лучшую совместимость – единый язык позволил обмениваться кодом и библиотеками между клиентской и серверной частями. В результате мы увеличили скорость разработки, поскольку в Blazor уже есть достаточно много обновлений и расширений от комьюнити, и начали применять этот инструмент на других проектах. Больше информации о нашей работе: https://www.simbirsoft.com/portfolio/technologies/c-net/

🔥 Договор ИТ-аутсорсинга имеет свои особенности, которые нужно учитывать при его заключении и заказчику, и исполнителю. Опираясь на опыт реализации ИТ-проектов для более 700 компаний, эксперты SimbirSoft рассказывают, на что нужно обратить внимание при подготовке этого документа и какие пункты в нем должны быть отражены. В статье https://s.simbirsoft.com/XMKj также найдете примеры формулировок конкретных пунктов. ☝️ От качества проработки договора ИТ-аутсорсинга будет зависеть, насколько точно он отразит все условия и обязательства сторон, давая тем самым клиенту уверенность в результатах сотрудничества. Были ли в вашей практике какие-то интересные случаи? Интересно узнать про ваш опыт.

Поздравляем с наступающим Новым годом! 🎅 Создавая IT-продукты вместе с нашими партнерами, мы стремимся достичь идеала во всем. А каждое идеальное решение основано на тысячах часов опыта. Из них вырастает виртуозность и мастерство. Этим разработка похожа на искусство, когда отдельные части становятся цельным произведением. В нашем видео делимся с вами небольшой новогодней фантазией🎄 Спасибо, что вы с нами!

Поздравляем с наступающим Новым годом! 🎅 Создавая IT-продукты вместе с нашими партнерами, мы стремимся достичь идеала во всем. А каждое идеальное решение основано на тысячах часов опыта. Из них вырастает виртуозность и мастерство. Этим разработка похожа на искусство, когда отдельные части становятся цельным произведением. В нашем видео делимся с вами небольшой новогодней фантазией🎄 Спасибо, что вы с нами!