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

Любому руководителю IT-проекта, владельцу бизнеса и IT-разработчику иногда нужна помощь, чтобы вовремя закончить IT-проект или повысить качество продукта. Проще всего для этого привлечь сторонних подрядчиков. В этом случае надо выбрать формат работы: аутстаф и аутсорс.

Напомним их различия. Если кратко: аутстаф — это подключение сторонних специалистов для IT-разработки, при котором управление проектом происходит полностью на стороне заказчика.

Аутсорс — это передача разработки продукта «под ключ» в стороннюю IT-компанию.

А какая модель разработки подойдет для роста вашего бизнеса? Узнайте в нашем тесте: https://mrqz.me/6577ffd8dc2a590025eef20c

Смотрите в карточках основную разницу в форматах.

Наш эксперт Константин рассказал про этапы UX-аудита, а теперь поделится, для чего он нужен и в каком формате закрепить результаты исследования. Смотрите видео 👀

Автоматическое тестирование — не роскошь, а проверенное средство, которое помогает снизить риски ошибок!

Есть примеры, когда ПО давало «сбой» как раз из-за недостатка в тестировании. Например, когда банк случайно пополнял счета клиентов на миллионы рублей!

Но шутки в сторону, если дело касается медицинской сферы: там от наличия ошибок в приложении будет зависеть здоровье человека. В таких случаях, помимо классической проверки качества IT-продукта (QA), помогает автоматизация тестирования (SDET). Это не только ускоряет разработку, но и снижает риск пропуска бага.

В лонгриде мы рассказали, везде ли нужны автотесты, как проходит тестирование, когда подключаются инженеры по разработке в тестировании (SDET-специалисты) и будет ли выгода бизнесу от автотестов.

Находим баланс в управлении IT-проектами — в нашем дайджесте💪

Ловите список полезных материалов, которые выпустили в первом месяце лета 👇

🔹Наш эксперт Марина рассказала, как подружить разработку и тестирование так, чтобы проект завершился вовремя, а рабочая атмосфера оставалась дружеской.

🔹Разбирались, как защитить базы данных от внешнего воздействия и восстановить их, если информационная безопасность дала сбой.

🔹Эксперт Екатерина объяснила, какие бывают ошибки при постановке задач в IT-проекте и как их избежать.

🔹Рассказали, как используем реестр рисков при разработке IT-проектов и какие при этом принимаем превентивные меры.

🔹Алёна, специалист по компьютерному зрению и ML, поделилась, как может бизнес выгодно использовать эти технологии.

🔹Видео от руководителя направления дизайна Константина про обязательные этапы UX-аудита.

Итак, продолжаем делиться нашим опытом 🙂

Выбор инструментов для управления проектами зависит от специфики проекта и особенностей команды. За всё время работы в SimbirSoft мы определили, в каких ситуациях они подойдут с большой вероятностью.

🔹Agile
Гибкий подход, который позволяет быстро реагировать на изменения и активно привлекать клиентов к процессу разработки. В рамках методологии выделим следующие инструменты:

▪️ Scrum фокусируется на коротких итерациях и регулярных встречах, что помогает командам быть организованными и продуктивными. Подходит для проектов с постоянными изменениями и активным взаимодействием с клиентами.
▪️ Kanban помогает визуализировать рабочий процесс и выявлять узкие места. Такой подход лучше использовать для проектов с четко определенными задачами и процессами.
▪️ Lean направлен на минимизацию потерь и максимизацию ценности для клиента. Оптимальный вариант для маленьких команд (1-2 разработчика) и стартапов. Позволяет сосредоточиться на самых важных задачах и быстро адаптироваться к изменениям.

Наши рекомендации:
— Для ИТ-команд до 50 человек хорошо подходят Scrum и Kanban, так как они помогают организовать работу и визуализировать задачи.
— Kanban и Lean лучше использовать для проектов с четко определенными задачами и процессами.

🔹EVM
Метод освоенного объема (EVM) — инструмент для точного контроля прогресса и эффективности проекта. С его помощью можно оперативно определить проблемы, которые влияют на график и бюджет проекта, и сразу же принимать меры по их устранению. Такой метод подходит для работы, например, над крупным корпоративным проектом.

🔹Отчёты
Помогают не только быстро выявлять отклонения, но и своевременно их устранять, предотвращая возможные проблемы в будущем. Мы создаём отчёты как для команды, так и для заказчика. Кроме того, регулярные встречи по работе над проектом позволяют учитывать все пожелания и замечания клиентов, оперативно вносить необходимые корректировки.

🔹Коммуникация
Ещё один важный аспект — улучшение общения в команде. Уровень доверия повышается, когда команда и все заинтересованные стороны знают о текущем состоянии проекта. Это особенно важно, когда каждый этап зависит от предыдущего.

Это базовые инструменты, которые проверены на разных проектах в нашей компании. Но помните, что выбор зависит от индивидуальных особенностей проекта и бизнес-цели заказчика.

Подробнее о методологиях управления проектами, а также как выбрать между классическим подходом и Agile читайте в статье.

А ещё у нас в блоге есть статья про роль руководителя в IT-проекте, где рассказываем, какими компетенциями он должен обладать и какие задачи решать.

Любая команда стремится сделать разработку IT-проекта успешной, но каждая делает это по-своему. И с течением времени она вырабатывает свои лайфхаки. Мы не исключение. Сегодня хотим поделиться своими секретами (методами и подходами), которые подходят для большинства проектов.

❗Помните, что выбор инструментов, подходов и методов зависит от индивидуальных особенностей проекта ❗

В управлении проектом не бывает незначительных этапов: они всё влияют на конечный результат. Но фокус и акцент — на:

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

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

Пример из практики:
В проекте по созданию новой e-commerce платформы аудит существующей системы показал проблемы с управлением клиентскими данными и низкую производительность сайта при высоких нагрузках. Мы предложили переход на более масштабируемую облачную инфраструктуру и внедрили современные инструменты аналитики данных, чтобы повысить персонализацию клиентского опыта.

Зачем акцентируем внимание на этих этапах
Понимание текущего состояния системы клиента помогает:
1. Избежать возможных проблем и конфликтов на этапе разработки.
2. Учитывать все особенности и ограничения существующей системы при разработке нового решения.
3. Точнее оценить объем работ и требуемые ресурсы.
4. Подготовить рекомендации по улучшению текущей системы, если это необходимо.

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

Шёл 2084 год. #SimbirSoft провела традиционную закрытую нетворк-встречу #SimbirVolga…

Когда-нибудь будет пост об этом. А сейчас делимся атмосферой второй (о самой первой - писали здесь) конференции SimbirVolga-2024 в Самаре. Два дня общения, обмена опытом и инсайтов про инновации в IT.

Для наших гостей — только самое лучшее ↓
💥Круглый стол «Выбор точки ИИ-зации» и доклады на практические темы
💥Лекция про вкусные напитки и их дегустация
💥Экскурсия в музей авиации и космонавтики
💥Кулинарный мастер-класс

Моменты конференции и волжские просторы — в нашем видео 👀

А сейчас расскажем, к чему этот опрос был ↓

Разработка ИТ-решений требует значительных ресурсов. Бизнесу (заказчикам) хочется знать точный прогноз, когда ИТ-система заработает и начнет приносить прибыль.

Задача подрядчика — помочь клиенту оценить время на разработку, чтобы определить необходимые ресурсы. Для этого можно воспользоваться одним из методов — оценка по UCP (use case points, оценка на основании вариантов использования).

Метод оценки проектов по UCP был предложен Густавом Карнером в 1993 году. Автор предложил оценивать затраты на разработку, учитывая вес параметров следующих групп в баллах:

◾ Функциональные параметры (UUCP*): кто и что может делать в информационной системе.
◾ Технические параметры (TCF*): сложность архитектуры, требования к безопасности, производительности, нагрузке и прочее.
◾Факторы окружения (ECF*): погружение команды разработки в предметную область, наличие опыта разработки аналогичных систем, уровень квалификации и прочее.

Работа по оценке методом UCP делится на два этапа:

🔹1. Unadjusted — проработка ролей в системе и Use Cases (вариантов использования).

На этом этапе необходимо составить списки:

▪️ UAW: количество действующих лиц в системе и их способ взаимодействия с ней (через UI, посредством API или доступ по FTP, например)
▪️ UUCW: количество и сложность Use Cases
Это самая ответственная часть — от того, насколько качественно вы их пропишете, будет зависеть итоговая оценка. Чтобы ничего не упустить, можно использовать UseCase-диаграмму.

🔹2. На следующем этапе необходимо расставить вес всех параметров в группах Unadjusted, технические факторы и факторы окружения.

Мы, например, применяем такие коэффициенты:

▪️ Простой Use Case (1-3 шага) — 5 баллов, сложный (7-11 шагов) — 15 баллов.
▪️ Взаимодействие с системой по API — 1 балл, с помощью UI — 3 балла.
▪️ Для технических факторов и факторов окружения мы используем баллы: 0-3-5.

Чем больше суммарный балл, тем сложнее система и выше итоговая оценка проекта.

При составлении списка Use Cases важно писать их от лица пользователей: неодушевленные участники информационного обмена участвуют в Use Cases как «шаги». Например, «Я как пользователь могу посмотреть штрафы, пришедшие от ГИБДД».

Также в этом методе присутствуют дополнительные множители — «вес факторов», которые мы использовали для адаптации этого метода оценки под наши реалии. Подробности об этом в статье 🙂

*расшифровка аббревиатур в статье

Всем добрый день!
Давайте узнаем правильные ответы ↑

По вопросу 1 — стартап (1) и разработка «с нуля» (3)
По вопросу 2 — разработка с «с нуля» (1) и оценка специфичных задач (3)

Из каких этапов обязательно состоит UX-аудит? Расскажет руководитель направления аналитики и дизайна Константин

Мы привыкли использовать ИИ в обычных жизненных ситуациях: разблокировка экрана смартфона по лицу или отпечатку пальца, автоматический пропуск машины на парковку, разговоры с Алисой или Siri). Но возможности технологий этим не ограничиваются.

Привет! На связи Алёна, специалист по ИИ, и в статье я расскажу, что такое компьютерное зрение, чем оно отличается от ML и как бизнес может применять эту технологию.

Какие ошибки возникают при постановке задач в IT-проектах
— рассказывает Екатерина, руководитель QA-направления

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

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

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

🔹 Нарушение принципа раннего тестирования.
Например, QA-специалист может не увидеть, что бэкенд-разработчик уже завершил свою часть работы и можно приступать к API-тестированию, не дожидаясь фронтенда. Это мешает раннему выявлению багов.

🔹 Отсутствие важных деталей для реализации необходимой функциональности.
Такие «общие» задачи превращаются в копию описания требований из базы знаний. Идеальная задача — максимально конкретная и заведённая для конкретного специалиста. Она чётко описывает, что он должен сделать и как, прикреплены ссылки на требования, макеты и другая информация, которая может потребоваться в работе.

❗Что делать?

✔️Создавать эпики и подзадачи. Общая задача — это эпик. В нём создаются подзадачи для каждой команды с конкретным описанием и учётом особенностей работы над ними.

✔️Следить за статусом всех подзадач в таск-трекере и следовать принципу раннего тестирования: каждую подзадачу можно и нужно тестировать по готовности, не дожидаясь остальных. Когда все подзадачи готовы и протестированы, эпик переводится в статус «Готово к тестированию» и тестируется полностью.

Такие шаги помогут справиться с теми недостатками, которые несет постановка одной задачи для нескольких команд. Если у вас есть варианты, как ещё можно уменьшить риск негативных последствий, пишите в комментариях 🙂

Всем привет!
Смотрим итог голосования:
вариант 1 — 12%
вариант 2 — 77%
вариант 3 — 11%

Всё верно 🙂 Ближе к истине именно вариант 2 — «Заранее продумать реестр рисков и выстроить процесс разработки с учётом особенностей проекта».

Намного удобнее заранее продумать риски и понять, как с ними справиться, чем надеяться на мозговой штурм и просто перераспределять задачи 👍

Расскажем, как мы работаем с рисками на проекте → статья

Как защитить базы данных от внешнего вторжения? 🤔

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

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

❗Мы подготовили список мер, которые помогут восстановить данные, если информационная безопасность дала сбой:


1. Создайте резервные копии (РК) данных по расписанию. Этот процесс важно сделать систематическим и довести до автоматизма.
2. Придерживайтесь правила «3-2-1», которое гласит, что для обеспечения надежного хранения данных нужно:
— Иметь ТРИ резервные копии ↓
— которые должны быть сохранены в ДВУХ различных физических форматах хранения ↓
— причем ОДНА из копий, должна быть передана на внеофисное хранение.
3. Зашифруйте РК. Доступ к данным должен быть ограничен, чтобы их не украли. А если это произошло, то прочитать зашифрованные данные будет сложно.
4. Периодически проверяйте целостность и объем данных в РК, чтобы иметь возможность полностью восстановить базу.

В статье мы рассказали о том, как могут взломать ваши внутренние системы и как этого избежать: https://s.simbirsoft.com/q3Jx

Как подружить разработку и тестирование — и почему это выгодно всем. Рассказывает руководитель отдела QA #SimbirSoft Марина.

Шутки про разработчиков и тестировщиков знакомы многим в IT. В них обычно специалисты соперничают между собой, что не всегда положительно сказывается на проекте. При этом главная цель — выпуск качественного продукта в запланированные сроки — может остаться «за бортом».

Марина делится историями своего взаимодействия с разработчиками, а также рассказывает, как разлад в команде может повлиять на итоговый результат и как это сказывается на бизнесе. Читайте в лонгриде.

Всем привет! Ловите дайджест с полезными материалами и новостями за май 🙂
🔹Разбираемся с продакт-менеджером Колей, что важно сделать для успешной разработки мобильного приложения.
🔹Рассказываем, в каких позициях засветилась SimbirSoft в списке лидеров ИТ для промышленности.
🔹Рекомендуем обратить внимание на отдельные этапы в разработке, которые влияют на качество ПО.
🔹 Описываем, как проджект-менеджер Валера справился с возникшими рисками на проекте, и спрашиваем, как другие предотвращают их.
🔹Предлагаем шпаргалку с рекомендациями, что делать в случае внесения срочных корректировок в процессе разработки.
🔹Делимся, каким критериям должна соответствовать оценка проекта на этапе аналитики, чтобы быть корректной.
🔹Наш эксперт Роман объясняет, как понять, на каком этапе зависла задача и что с этим делать.