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

Грамотно выстроенные процессы имеют огромное влияние на качество конечного продукта. Они определяют, каким образом команда организует работу, выполняет задачи, тестирует и внедряет изменения. У многих компаний уже есть свой «рецепт счастья» по управлению IT-проектами. Мы не исключение. Давайте в общих чертах расскажем, как это сделано у нас. Всегда ведь интересно узнать, как другие подходят к процессам 🙃

Мы придерживаемся следующих базовых рекомендаций по управлению проектами:
🔹 Аналитика и архитектура
У нас в компании архитектор и аналитик подключаются к проекту еще до того, как принимается решение о старте проекта. Они помогают проработать верхнеуровневые бизнес-требования и сформировать архитектурную концепцию будущего продукта. Это позволяет четко определить содержание и провести качественное планирование сроков, ресурсов и стоимости проекта.

Также можно использовать архитектурный надзор. Цель — проверка соответствия кода заявленной архитектуре. Данный процесс также существенно влияет на качество разрабатываемого ПО.

🔹 Код-ревью и аудит
Основная цель код-ревью — выявление ошибок, дефектов и потенциальных проблем в коде на ранних стадиях разработки. Другие члены команды, анализируя код, могут найти ошибки, которые пропустил автор. Это позволяет найти нарушения и исправить проблемы еще до того, как код попадет в более продвинутые стадии разработки и станет основой для других функций или модулей.

В дополнение к код-ревью можно внедрить процесс аудита со стороны направлений в компании или от смежных команд. Это помогает поддерживать уровень качества на проектах вне зависимости от условий.

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

🔹 Служба качества и метрики
В SimbirSoft есть Служба качества (СК), которая контролирует исполнение процесса на каждом этапе жизненного цикла проекта. Она помогает организовать все процессы в компании так, чтобы продукт был готов в срок с минимальными затратами, соответствовал задачам бизнеса и ожиданиям пользователей.

СК подсвечивает проблемные точки, уязвимые места, дает рекомендации, а итоговые решения принимают владельцы бизнес-процессов, руководители подразделений или руководители проектов.

О лайфхаках расскажем позднее, если есть вопросы - пишите 😉

Помните проджект-менеджера Валеру? В этом посте мы рассказали про рекомендации, которые дала ему ментор Светлана, чтобы грамотно выстроить первое интервью с клиентом.

Теперь у него другая задача ↓

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

Начали внедрять выбранную библиотеку, однако в процессе адаптации к проекту возникли сложности и вылезли «подводные камни». Выяснилось, что она нуждается в интеграции с другими библиотеками и адаптации под уже написанный код. Кроме того, возник риск открыть «дыру» в безопасности данных. Это увеличивало бюджет проекта и требовало ускорения работ в некоторых областях.

Но Валера не был бы классным проджект-менеджером, если бы не предусмотрел риски 😎

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

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

Через неделю расскажем, как мы прорабатываем риски на проектах. А пока пройдите, пожалуйста, опрос ↓

Наладить процесс разработки IT-проекта не так легко, как кажется. Чаще всего на разработку продукта влияют:
◾Bus factor
◾Неполная команда на старте
◾Отсутствие коммуникаций между бизнесом и IT-командой
◾Часто меняющиеся требования к IT-продукту

Чтобы максимально избежать таких моментов, советуем тщательно подбирать команду разработки, продумывать «гибкость» проекта и настраивать коммуникацию с командой.

❗Но даже в этом случае остается риск внесения срочных корректировок в процессе разработки❗

Мы составили небольшую шпаргалку с рекомендациями, что делать в таком случае:

🔹Четко определить новые требования. Иначе команда потратит драгоценные часы на постоянные уточнения, а функциональность не будет отвечать конечной цели.

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

🔹Спланировать несколько промежуточных демо для оценки ключевых пользовательских сценариев и своевременной обратной связи.

🔹После внедрения задачи рассказать об успешности срочной разработки, удалось ли достичь бизнес-цели.

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

При разработке IT-продукта важным этапом является его оценка. Но как понять, что она верная?

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

Избежать ошибок в разработке IT-проекта можно, если следовать 4 критериям для оценки проекта на этапе аналитики:

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

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

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

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

Важно доводить до исполнителей честную и объективную информацию, а оценщику фиксировать в документе обстоятельства, на которые опирается оценка. Например: «описание интеграции с внутренней системой заказчика (документация на систему предоставляется заказчиком)». Естественно, от исполнителя тоже требуется максимальная честность и объективность оценки. Мы в компании всегда стараемся действовать именно таким образом 😊

🤔 На каком этапе зависла задача? Наш эксперт Роман рассказал, зачем нужно детализировать её статусы.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

❗Что делать?

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

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

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

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

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

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

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

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

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

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

Задача подрядчика — помочь клиенту оценить время на разработку, чтобы определить необходимые ресурсы. Для этого можно воспользоваться одним из методов — оценка по 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 как «шаги». Например, «Я как пользователь могу посмотреть штрафы, пришедшие от ГИБДД».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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