Работа над проектом напоминает море: иногда все идёт гладко, а иногда начинается шторм. Особенно сложно тому, кто управляет кораблем разработкой проекта, сохранить лояльность заказчика (или партнёра).

Как же не потерять голову и сохранить хладнокровие? 🤔

Например, можно предотвратить конфликты, управляя «зарядом батарейки» партнёра. Рассказываем, что это такое ↓

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

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

🔹Если коммуникация между сторонами «размытая», то информация о ходе проекта поступает нерегулярно. Это приводит к тому, что эмоциональный «заряд» как минимум остается на стартовых 50%, либо снижается к концу проекта. И даже если задачи будут выполнены в срок, то заказчик вряд ли продолжит работу с этим подрядчиком.

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

Вот здесь мы рассмотрели один из кейсов с действиями руководителя проекта по выходу из конфликтной ситуации, а ещё добавили лайфхаки, как управлять ожиданиями заказчика: https://s.simbirsoft.com/RGgK

Всем привет!

⚡️Напоминаем, что сегодня в 14:00 (мск) проведем вебинар аналитиков «Анализировать нельзя разрабатывать. Лекарство от хаоса в разработке»

Вот ссылка, для тех, кто не успел зарегистрироваться → https://s.simbirsoft.com/CLYV

Вы узнаете от руководителя направления аналитики Константина и ведущего аналитика Марии, как снизить риски в процессе разработки IT-проекта. Кроме того, эксперты ответят на все острые вопросы, которые волнуют руководителей IT-проекта и IT-команд.

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

🔥 А ещё приготовили секретный бонус только для участников вебинара — 1 час консалтинга от наших аналитиков. Условия для получения озвучим на вебинаре.

Регистрируйтесь → https://s.simbirsoft.com/CLYV

Всем привет! Ловите дайджест с полезными материалами и новостями нашей компании за апрель 🙂
🔹SimbirSoft и Синара Лаб стали партнерами по внедрению коробочного решения «Цифровой рубль». Это технически сложный проект, для которого нужны опытные IT-разработчики, чтобы выстроить процессы согласно требованиям ЦБ.
🔹Посоветовали новому ПМу Валере, как сделать погружение в проект максимально эффективным, а общение с заказчиком продуктивным.
🔹Поделились, какие качества нужны ПМу для клиента, команды и проекта в целом.
🔹В этом видео эксперт Роман рассказал, по каким качествам можно определить будущего тимлида на проекте.
🔹Предложили вариант, как предотвратить конфликты, управляя «зарядом батарейки» партнёра. А также написали лайфхаки для управления ожиданиями заказчика.
🔹12-13 апреля SimbirSoft выступила Платиновым партнёром и партнёром секции 1С на IT-конференции «Стачка». Наши эксперты поделились опытом онбординга аналитиков, практикой использования новой технологии 1C:Элемент и рассказали о тестировании компьютерного зрения.
🔹Рассказали, как бизнесу избежать инцидентов на IT-проекте.

Как создать мобильное приложение?🤔

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

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

2. Тщательно продумать дизайн: интерфейс должен быть простым и удобным в использовании, а действие элементов экрана – интуитивно понятным каждому. Также Коле надо не забыть про качественное наполнение приложения: тренировки, консультации, счетчик калорий и т.д.

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

А также Коле важно помнить и о трудностях, с которыми можно столкнуться на пути к релизу, и заранее продумать эти вопросы.

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

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

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

Как выбрать подходящий именно Коле способ создания мобильного решения? Рассмотрим 5 основных вариантов:
— сборка на конструкторе;
— кастомная разработка на нативных языках или с помощью кроссплатформенных решений;
— PWA (Progressive Web App): адаптация существующего сайта под мобильное приложение;
— телеграм-боты;
— мини-аппы в социальных сетях.

Идеального варианта не существует – каждый из этих способов имеет свои преимущества и ограничения. Подробно о каждом, а также про этапы разработки мы написали здесь: https://s.simbirsoft.com/dNzG

#резюменедели

SimbirSoft – в списке лидеров ИТ для промышленности 🏆

Мы засветились в таких номинациях, как:
⚡ «Лидеры ИТ для промышленности России»
⚡ «Лидеры-поставщики ИТ-решений» — ERP, MES, HRM, EAM и др.
⚡ «Лучший поставщик ИТ-решений для отрасли» — металлургия, нефтегазовый комплекс, производство строительных материалов, энергетика

Сам рейтинг направлен на определение компаний, владеющих навыками решения специфических задач в сфере производства. Ключевым критерием ранжирования стала выручка ИТ-компаний от сотрудничества с предприятиями. Рейтинг проводится ежегодно с 2013 года. Организатор – деловой портал «Управление производством».

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

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

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

Подробности здесь → https://s.simbirsoft.com/ByWM

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

Грамотно выстроенные процессы имеют огромное влияние на качество конечного продукта. Они определяют, каким образом команда организует работу, выполняет задачи, тестирует и внедряет изменения. У многих компаний уже есть свой «рецепт счастья» по управлению 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-тестированию, не дожидаясь фронтенда. Это мешает раннему выявлению багов.

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

❗Что делать?

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

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

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