Media is too big
VIEW IN TELEGRAM
#полезное
7 сигналов, что сроки релиза могут сорваться
1) Техническое задание часто меняется, в спринт добавляются новые задачи.
2) QA подключается к задаче только после того, как она полностью разработана. Из-за этого серьезные проблемы выясняются достаточно поздно и команда вынуждена перерабатывать.
3) Тестовая документация не обновляется, когда вносятся изменения в техническое задание.
4) В новом функционале достаточно высокая плотность дефектов с самыми разными приоритетами.
5) Статусы выполнения задач обновляются несвоевременно, нарушены или полностью отсутствуют информационные потоки между QA, аналитиком, разработчиком и другими участниками команды.
6) Фактическое время выполнения задач сильно превышает планируемое.
7) Оценка вашего проекта не включает в себя риски: например, не заложено время на багофикс.
Если на проекте присутствуют два и более признаков, есть риск срыва дедлайна. Вовремя обнаружить и предотвратить серьезные проблемы в таком случае поможет аудит вашего приложения и процессов.
7 сигналов, что сроки релиза могут сорваться
1) Техническое задание часто меняется, в спринт добавляются новые задачи.
2) QA подключается к задаче только после того, как она полностью разработана. Из-за этого серьезные проблемы выясняются достаточно поздно и команда вынуждена перерабатывать.
3) Тестовая документация не обновляется, когда вносятся изменения в техническое задание.
4) В новом функционале достаточно высокая плотность дефектов с самыми разными приоритетами.
5) Статусы выполнения задач обновляются несвоевременно, нарушены или полностью отсутствуют информационные потоки между QA, аналитиком, разработчиком и другими участниками команды.
6) Фактическое время выполнения задач сильно превышает планируемое.
7) Оценка вашего проекта не включает в себя риски: например, не заложено время на багофикс.
Если на проекте присутствуют два и более признаков, есть риск срыва дедлайна. Вовремя обнаружить и предотвратить серьезные проблемы в таком случае поможет аудит вашего приложения и процессов.
👍8
#полезное
Как не оттолкнуть пользователя при знакомстве с приложением: авторизация
1. Позвольте работать в приложении без авторизации столько, сколько это возможно.
Здесь классическим примером будут интернет-магазины: вход в личный кабинет обычно необязателен для покупки, но требуется для начисления бонусов.
2. Гарантируйте сохранение данных, введённых пользователем до авторизации.
3. Сократите количество информации, необходимой для входа.
Чем больше данных нужно вводить, тем меньше вероятность того, что пользователь останется в приложении. Например, после регистрации или восстановления пароля не стоит просить повторно вводить данные для авторизации – сделайте её автоматической.
4. Используйте наиболее простые способы авторизации.
Например, биометрию или вход по номеру телефона с встроенной автоподстановкой кода. Подробнее о способах авторизации в мобильном приложении мы рассказывали здесь.
5. Сделайте понятной маску ввода.
Используйте подсказки под полями, объясняя, какие данные вы ожидаете получить. Для пользователя должно быть ясно, что вводить в качестве логина и в каком формате. Если была допущена ошибка, подсветите только те поля, которые требуют изменений.
6. Спланируйте перенос данных заранее.
Если вы планируете запустить новую версию мобильного приложения, изменив backend-часть, продумайте миграцию пользователей из старой базы данных, включая их данные для авторизации. В противном случае это грозит перегрузкой техподдержки, отрицательными отзывами и потерей клиентов. Лучше задержать релиз, но не допустить этой ошибки, так как вернуть доверие клиентов намного сложнее, чем изначально поддерживать его на высоком уровне.
Как не оттолкнуть пользователя при знакомстве с приложением: авторизация
1. Позвольте работать в приложении без авторизации столько, сколько это возможно.
Здесь классическим примером будут интернет-магазины: вход в личный кабинет обычно необязателен для покупки, но требуется для начисления бонусов.
2. Гарантируйте сохранение данных, введённых пользователем до авторизации.
3. Сократите количество информации, необходимой для входа.
Чем больше данных нужно вводить, тем меньше вероятность того, что пользователь останется в приложении. Например, после регистрации или восстановления пароля не стоит просить повторно вводить данные для авторизации – сделайте её автоматической.
4. Используйте наиболее простые способы авторизации.
Например, биометрию или вход по номеру телефона с встроенной автоподстановкой кода. Подробнее о способах авторизации в мобильном приложении мы рассказывали здесь.
5. Сделайте понятной маску ввода.
Используйте подсказки под полями, объясняя, какие данные вы ожидаете получить. Для пользователя должно быть ясно, что вводить в качестве логина и в каком формате. Если была допущена ошибка, подсветите только те поля, которые требуют изменений.
6. Спланируйте перенос данных заранее.
Если вы планируете запустить новую версию мобильного приложения, изменив backend-часть, продумайте миграцию пользователей из старой базы данных, включая их данные для авторизации. В противном случае это грозит перегрузкой техподдержки, отрицательными отзывами и потерей клиентов. Лучше задержать релиз, но не допустить этой ошибки, так как вернуть доверие клиентов намного сложнее, чем изначально поддерживать его на высоком уровне.
👍6
#посадилес #ESG #социальнаяответственность
Лес, меч Колесова, айтишники
11°, ливень, Подмосковье.
72 молодых волонтера собрались, чтобы высадить 10000 саженцев.
Волонтеры, клиенты и аккаунт-менеджеры #SimbirSoft посадили саженцы молодых сосен и елей на лесном участке, ранее пострадавшем от ветролома.
«Это было классно, – смеется аккаунт-менеджер Анна Шайдуллова. З часа до пункта назначения по неизвестной местности, инструктаж от лесника, что такое меч Колесова и как сажать сосны в условиях стоячей воды на делянке. И вот я в резиновых сапогах, дождевике с охапкой ароматных маленьких ёлочек вместе с нашими клиентами сажаю новые деревья...»
А вот что говорят наши клиенты:
– Чувствую, что желание сажать деревья только разожглось, и теперь не знаю, как его унять).
– Надо предложить нашим аналогичное мероприятие для участия вместе с СимбирСофт, поедем в Ульяновск.
– Наши довольны и хотят еще)).
Дальше – больше 💪🌲
Лес, меч Колесова, айтишники
11°, ливень, Подмосковье.
72 молодых волонтера собрались, чтобы высадить 10000 саженцев.
Волонтеры, клиенты и аккаунт-менеджеры #SimbirSoft посадили саженцы молодых сосен и елей на лесном участке, ранее пострадавшем от ветролома.
«Это было классно, – смеется аккаунт-менеджер Анна Шайдуллова. З часа до пункта назначения по неизвестной местности, инструктаж от лесника, что такое меч Колесова и как сажать сосны в условиях стоячей воды на делянке. И вот я в резиновых сапогах, дождевике с охапкой ароматных маленьких ёлочек вместе с нашими клиентами сажаю новые деревья...»
А вот что говорят наши клиенты:
– Чувствую, что желание сажать деревья только разожглось, и теперь не знаю, как его унять).
– Надо предложить нашим аналогичное мероприятие для участия вместе с СимбирСофт, поедем в Ульяновск.
– Наши довольны и хотят еще)).
Дальше – больше 💪🌲
🔥4❤3
Фото предоставлено организаторами проекта «Посади лес».
🥰11❤1
#подкасты
Мы тут немало рассказывали про разные аспекты frontend-разработки, но ещё не познакомили вас со специалистами, которые создают все эти удивительные вещи. Исправляемся!
🧑💻Сегодня Frontend-направление SimbirSoft объединяет 200+ скиловых разработчиков. За 6 лет они реализовали свыше 280 разнообразных проектов для банков, ритейла, фудтеха, здравоохранения, образования и других сфер. Ежедневно наши frontend-специалисты развивают 70+ IT-решений 🔥
В видео наши коллеги рассказывают, с чего начался их путь в IT, какие задачи они решают, чем их привлекает frontend-разработка и как им удается найти баланс между кодингом и управлением.
Приятного просмотра!
Мы тут немало рассказывали про разные аспекты frontend-разработки, но ещё не познакомили вас со специалистами, которые создают все эти удивительные вещи. Исправляемся!
🧑💻Сегодня Frontend-направление SimbirSoft объединяет 200+ скиловых разработчиков. За 6 лет они реализовали свыше 280 разнообразных проектов для банков, ритейла, фудтеха, здравоохранения, образования и других сфер. Ежедневно наши frontend-специалисты развивают 70+ IT-решений 🔥
В видео наши коллеги рассказывают, с чего начался их путь в IT, какие задачи они решают, чем их привлекает frontend-разработка и как им удается найти баланс между кодингом и управлением.
Приятного просмотра!
YouTube
Frontend в SimbirSoft: проекты, задачи, развитие, баланс
Frontend-направление SimbirSoft объединяет 200+ скиловых разработчиков. За 6 лет они реализовали свыше 280 разнообразных проектов для банков, ритейла, фудтеха, здравоохранения, образования и других сфер. Ежедневно #frontend-специалисты развивают 70+ IT-решений.…
👍5👏2
Какой метод управления проектом больше подходит в этой ситуации?
Anonymous Poll
65%
Классический
22%
Agile
14%
Scrum
👍2
Классический подход: преимущества и риски
Преимущества
🔹 Фиксация требований на старте и стабильность содержания проекта.
🔹 Предсказуемость процесса разработки. Качественная проработка требований и видения продукта на ранних стадиях проекта позволяет сэкономить время и силы на исправлении недочётов и решении проблем в дальнейшем.
Подводные камни/риски
🔹 Негибкое взаимодействие при возникновении новых условий и потребностей. К примеру, если нужно изменить цель, проект необходимо перезапустить и сформировать новый устав, определить требования и ограничения.
Классическое управление по PMI можно использовать, когда:
🔹 заинтересованные лица имеют чёткое видение результата – конечный продукт;
🔹 составлено подробное техническое задание на разработку;
🔹 есть жёсткие ограничения по сроку и бюджету проекта;
🔹 реализация проекта предполагается по формату договора fixed price.
Преимущества
🔹 Фиксация требований на старте и стабильность содержания проекта.
🔹 Предсказуемость процесса разработки. Качественная проработка требований и видения продукта на ранних стадиях проекта позволяет сэкономить время и силы на исправлении недочётов и решении проблем в дальнейшем.
Подводные камни/риски
🔹 Негибкое взаимодействие при возникновении новых условий и потребностей. К примеру, если нужно изменить цель, проект необходимо перезапустить и сформировать новый устав, определить требования и ограничения.
Классическое управление по PMI можно использовать, когда:
🔹 заинтересованные лица имеют чёткое видение результата – конечный продукт;
🔹 составлено подробное техническое задание на разработку;
🔹 есть жёсткие ограничения по сроку и бюджету проекта;
🔹 реализация проекта предполагается по формату договора fixed price.
👍1
Ответ на задачу
Если нужно создать ИТ-продукт, где фундаментальное содержание и цели проекта зафиксированы и неизменяемы, а также есть чёткие ограничения по сроку и бюджету, лучше выбирать классический подход. В этом случае Agile будет избыточным.
Если нужно создать ИТ-продукт, где фундаментальное содержание и цели проекта зафиксированы и неизменяемы, а также есть чёткие ограничения по сроку и бюджету, лучше выбирать классический подход. В этом случае Agile будет избыточным.
👍4
Гибкие методологии Agile
Преимущества
🔹 Быстрый жизненный цикл разработки.
🔹 Гибкость в принятии решений для улучшения итогового продукта.
🔹 Регулярное получение обратной связи от заинтересованных сторон открывает возможность вносить корректировки в реализацию проекта или в функциональность разрабатываемого продукта.
Подводные камни/риски
🔹 Отсутствие чёткого плана затрудняет управление ресурсами и планирование.
🔹 Все заинтересованные стороны должны работать в тесном сотрудничестве, чтобы каждый знал об изменениях, задачах и их актуальности.
🔹 Предъявляются более высокие требования к команде.
Гибкие методологии работают, когда:
🔹 детали проекта, требования и реализация фич всех запланированных модулей/подсистем ещё не до конца определены на старте. Нет чёткого понимания конечного результата, но есть общее представление о продукте;
🔹 проект нужно быстро корректировать и подстраивать под изменяющиеся требования.
Преимущества
🔹 Быстрый жизненный цикл разработки.
🔹 Гибкость в принятии решений для улучшения итогового продукта.
🔹 Регулярное получение обратной связи от заинтересованных сторон открывает возможность вносить корректировки в реализацию проекта или в функциональность разрабатываемого продукта.
Подводные камни/риски
🔹 Отсутствие чёткого плана затрудняет управление ресурсами и планирование.
🔹 Все заинтересованные стороны должны работать в тесном сотрудничестве, чтобы каждый знал об изменениях, задачах и их актуальности.
🔹 Предъявляются более высокие требования к команде.
Гибкие методологии работают, когда:
🔹 детали проекта, требования и реализация фич всех запланированных модулей/подсистем ещё не до конца определены на старте. Нет чёткого понимания конечного результата, но есть общее представление о продукте;
🔹 проект нужно быстро корректировать и подстраивать под изменяющиеся требования.
👍3
Задачка со звёздочкой
Условия: Высокая неопределённость требований и высокая техническая неопределённость
Пример проекта: создание приложения для мобильного устройства с блоком считывателя радиосигналов. Главная фича – распознавание размеров и других параметров объекта по фотографии, сделанной устройством.
Вопрос: Как бы вы поступили в этой ситуации?
Условия: Высокая неопределённость требований и высокая техническая неопределённость
Пример проекта: создание приложения для мобильного устройства с блоком считывателя радиосигналов. Главная фича – распознавание размеров и других параметров объекта по фотографии, сделанной устройством.
Вопрос: Как бы вы поступили в этой ситуации?
Как бы вы поступили в этой ситуации?
Anonymous Poll
18%
Выберу Agile-методологию
0%
Лучше отказаться от такого проекта – похоже, он бесперспективный
82%
Сначала попробую снизить неопределённость, окончательное решение приму потом
Пояснение к задаче
Вы правильно поняли, что отказываться от проекта с высокой неопределённостью сразу не стоит, так как по итогу упущенная выгода может быть весомой. К тому же в этом случае клиент, скорее всего, не придёт к вам и со следующими своими продуктами – сложная разработка не для вас.
Однако, в условиях «хаоса» Agile-методологии не подходят – они не позволят даже приблизительно оценить фронт работ и провести планирование. Значительное изменение сроков или количества специалистов на проекте может привести к недовольству клиента, также продукт может быть неосуществим.
Чтобы быть уверенным в возможности его реализации, команде необходимо уменьшить неопределённость. Например, использовать практику предпроектного исследования и реализовать прототип системы. Это помогает понять, достаточно ли команде технической экспертизы и инструментов для решения подобных задач.
Если возвращаться к описанному в задаче приложению со считывателем радиосигналов – это реальный пример из нашей практики. В ходе предпроектного исследования мы проверили гипотезу о возможности внедрения алгоритма machine learning в приложение и протестировали функционал считывания радиосигналов в полевых условиях. Команда убедилась, что задача имеет понятное техническое решение, тем самым снизила уровень технической неопределённости. Далее следовала стандартная схема работ.
Другой вариант – стартовать по концепции Lean Startup. Она позволяет с минимальными вложениями протестировать гипотезу: создать прототип, собрать обратную связь от пользователей, определить, интересен ли продукт целевой аудитории, и наметить план его развития.
Вы правильно поняли, что отказываться от проекта с высокой неопределённостью сразу не стоит, так как по итогу упущенная выгода может быть весомой. К тому же в этом случае клиент, скорее всего, не придёт к вам и со следующими своими продуктами – сложная разработка не для вас.
Однако, в условиях «хаоса» Agile-методологии не подходят – они не позволят даже приблизительно оценить фронт работ и провести планирование. Значительное изменение сроков или количества специалистов на проекте может привести к недовольству клиента, также продукт может быть неосуществим.
Чтобы быть уверенным в возможности его реализации, команде необходимо уменьшить неопределённость. Например, использовать практику предпроектного исследования и реализовать прототип системы. Это помогает понять, достаточно ли команде технической экспертизы и инструментов для решения подобных задач.
Если возвращаться к описанному в задаче приложению со считывателем радиосигналов – это реальный пример из нашей практики. В ходе предпроектного исследования мы проверили гипотезу о возможности внедрения алгоритма machine learning в приложение и протестировали функционал считывания радиосигналов в полевых условиях. Команда убедилась, что задача имеет понятное техническое решение, тем самым снизила уровень технической неопределённости. Далее следовала стандартная схема работ.
Другой вариант – стартовать по концепции Lean Startup. Она позволяет с минимальными вложениями протестировать гипотезу: создать прототип, собрать обратную связь от пользователей, определить, интересен ли продукт целевой аудитории, и наметить план его развития.
Telegram
DepthDev
Задачка со звёздочкой
Условия: Высокая неопределённость требований и высокая техническая неопределённость
Пример проекта: создание приложения для мобильного устройства с блоком считывателя радиосигналов. Главная фича – распознавание размеров и других параметров…
Условия: Высокая неопределённость требований и высокая техническая неопределённость
Пример проекта: создание приложения для мобильного устройства с блоком считывателя радиосигналов. Главная фича – распознавание размеров и других параметров…
👍3
Когда (пока) не нужно мобильное приложение?
Да-да, компания по разработке IT-продуктов пишет о том, когда стоит отложить эту самую разработку. Всё верно)
Мы за то, чтобы ваши продукты приносили вам пользу и прибыль, а не наоборот 💙
Прочитать новый пост можно, не выходя из Телеграма 😇
P.S. Как вам такой формат публикаций?
😉 Приветствую!
🤔 Обычные посты мне всё-таки милее
Да-да, компания по разработке IT-продуктов пишет о том, когда стоит отложить эту самую разработку. Всё верно)
Мы за то, чтобы ваши продукты приносили вам пользу и прибыль, а не наоборот 💙
Прочитать новый пост можно, не выходя из Телеграма 😇
P.S. Как вам такой формат публикаций?
😉 Приветствую!
🤔 Обычные посты мне всё-таки милее
Telegraph
Когда приложение не нужно: критерии
Сегодня в GooglePlay и AppStore уже около 6 миллионов мобильных приложений. Недавно Apple анонсировала чистку устаревших продуктов, AppFigures посчитал – под критерии может попасть около трети всего магазина. Google также периодически проводит мероприятия…
Как вы думаете, сколько давно не обновляемых или мало загружаемых приложений удалил AppStore за последние 6 лет?
Anonymous Quiz
16%
около 1–2 млн
19%
около 2–3 млн
9%
около 3–4 млн
56%
более 4 млн
#статьи
Изменения на рынке подтолкнули компании к усилению цифровизации: увеличился спрос на адаптацию готовых и разработку собственных продуктов.
Но бизнес всё ещё не до конца доверяет технологиям: «Разработка – это слишком дорого, а ещё долго и сложно», «Невозможно оценить эффективность IT-системы».
В статье для Executive рассказали о 5 популярных предубеждениях о финансовой стороне разработки (и о том, как происходит на самом деле). Материал будет полезен всем, кто задумывается о создании IT-продукта.
Изменения на рынке подтолкнули компании к усилению цифровизации: увеличился спрос на адаптацию готовых и разработку собственных продуктов.
Но бизнес всё ещё не до конца доверяет технологиям: «Разработка – это слишком дорого, а ещё долго и сложно», «Невозможно оценить эффективность IT-системы».
В статье для Executive рассказали о 5 популярных предубеждениях о финансовой стороне разработки (и о том, как происходит на самом деле). Материал будет полезен всем, кто задумывается о создании IT-продукта.
👍3❤1