Six Sigma
В Six Sigma концепции фокус на качество и на удовлетворение клиентов. Чтобы достичь этого, нужно сокращать ошибки в организации и исполнении процессов.
Компоненты:
☺️ Удовлетворение потребителя. Определяем и учитываем все требования клиента.
☺️ 🔀 Выявление процессов, показателей и методов управления. На всю цепочку процессов смотрим через призму потребностей клиента, ориентируемся на неё и корректируем при необходимости.
☺️ 🔀 🤝 Командная работа. Чтобы улучшение отдельных процессов было более скоординированным, обеспечиваем прозрачность для всех участников. Отлаженная командная работа поможет добиться качества.
5 шагов DMAIC (define, measure, analyze, improve, control – определять, измерять, анализировать, улучшать, контролировать)
1. Определяем основные проблемы, формируем команду по улучшению процесса и прописываем зону ответственности.
2. Чтобы выяснить текущее положение проекта, проводим измерение процессов.
3. Анализируем полученные данные, устраняем причины и предлагаем методы по устранению причин.
4. Разрабатываем способы внедрения улучшений в процесс.
5. Заносим в документацию и контролируем улучшения после изменения процессов.
Где подходит
Six Sigma можно применять на проектах, где отлажена командная работа, так как внедрение концепции происходит за счёт управления отдельными задачами и процессами – они улучшаются независимо друг от друга. При этом нужен постоянный контроль, чтобы система не перестала функционировать, пока происходят изменения.
В Six Sigma концепции фокус на качество и на удовлетворение клиентов. Чтобы достичь этого, нужно сокращать ошибки в организации и исполнении процессов.
Компоненты:
☺️ Удовлетворение потребителя. Определяем и учитываем все требования клиента.
☺️ 🔀 Выявление процессов, показателей и методов управления. На всю цепочку процессов смотрим через призму потребностей клиента, ориентируемся на неё и корректируем при необходимости.
☺️ 🔀 🤝 Командная работа. Чтобы улучшение отдельных процессов было более скоординированным, обеспечиваем прозрачность для всех участников. Отлаженная командная работа поможет добиться качества.
5 шагов DMAIC (define, measure, analyze, improve, control – определять, измерять, анализировать, улучшать, контролировать)
1. Определяем основные проблемы, формируем команду по улучшению процесса и прописываем зону ответственности.
2. Чтобы выяснить текущее положение проекта, проводим измерение процессов.
3. Анализируем полученные данные, устраняем причины и предлагаем методы по устранению причин.
4. Разрабатываем способы внедрения улучшений в процесс.
5. Заносим в документацию и контролируем улучшения после изменения процессов.
Где подходит
Six Sigma можно применять на проектах, где отлажена командная работа, так как внедрение концепции происходит за счёт управления отдельными задачами и процессами – они улучшаются независимо друг от друга. При этом нужен постоянный контроль, чтобы система не перестала функционировать, пока происходят изменения.
👍4
#резюменедели
Получили награды 🏆
▪️ Заняли места в ТОП-10 и ТОП-20 рейтингов RAEX среди крупнейших IT-компаний
▪️ Попали в ТОП-100 крупнейших IT-разработчиков, по версии CNews
Поделились важным 💙
Это сейчас у нас большая команда из 1300+ человек с 6 офисами в разных городах России и филиалом в США. А начиналось всё с маленького кабинета, 4 увлечённых программированием человек и банковского проекта из Японии. Вернуться вместе с нами в 2001 год и посмотреть, как росла наша SimbirSoft теперь можно на странице с нашей историей 📝
Рассказали о проектах 🔏
▪️ Сервис рассрочки для маркетплейса
▪️ Оптимизация работы мобильного приложения для ритейла
▪️ Модернизация системы управления производственным предприятием в 1С: ERP
Отпраздновали юбилей сотрудничества 🎊
Уже 15 лет мы партнёры с Международной цифровой олимпиадой «Волга-IT»! В 2008 году подключились к олимпиаде – взрыв, буря, эмоции!☺️ А теперь ежегодно являемся одними из организаторов мероприятия и разрабатываем задание для дисциплины по Java и C#.
Получили награды 🏆
▪️ Заняли места в ТОП-10 и ТОП-20 рейтингов RAEX среди крупнейших IT-компаний
▪️ Попали в ТОП-100 крупнейших IT-разработчиков, по версии CNews
Поделились важным 💙
Это сейчас у нас большая команда из 1300+ человек с 6 офисами в разных городах России и филиалом в США. А начиналось всё с маленького кабинета, 4 увлечённых программированием человек и банковского проекта из Японии. Вернуться вместе с нами в 2001 год и посмотреть, как росла наша SimbirSoft теперь можно на странице с нашей историей 📝
Рассказали о проектах 🔏
▪️ Сервис рассрочки для маркетплейса
▪️ Оптимизация работы мобильного приложения для ритейла
▪️ Модернизация системы управления производственным предприятием в 1С: ERP
Отпраздновали юбилей сотрудничества 🎊
Уже 15 лет мы партнёры с Международной цифровой олимпиадой «Волга-IT»! В 2008 году подключились к олимпиаде – взрыв, буря, эмоции!☺️ А теперь ежегодно являемся одними из организаторов мероприятия и разрабатываем задание для дисциплины по Java и C#.
🔥4❤1
Зачем нужна служба качества в IT-компании
– рассказывает Екатерина Ремизова, наш директор по качеству
Служба качества (СК) помогает организовать все процессы в компании так, чтобы продукт был готов в срок с минимальными затратами, соответствовал задачам бизнеса и ожиданиям пользователей.
Чем занимается СК:
▪️ устанавливает и внедряет стандарты процессов разработки,
▪️ согласовывает критерии качества продуктов,
▪️ разрабатывает и внедряет метрики, по которым можно оценить качество работы всей компании,
▪️ отслеживает уровень удовлетворенности клиентов,
▪️ проводит аудиты работы на каждом уровне организации, в производственных и вспомогательных процессах, которые обеспечивают её работу.
А без службы качества можно?
Если в компании нет чёткой системы обеспечения качества, могут возникнуть следующие проблемы:
🔹 Сложно воспроизводить процессы в компании. При старте очередного проекта всегда приходится выстраивать разработку с нуля. СК организует все процессы один раз, а потом немного их корректирует и адаптирует под новые условия. Например, у нас на каждом проекте внедряются таск-трекер и базовые метрики: план-факт, процент возврата задач, процент Bugfix.
🔹 Возрастает цена ошибки. Исправить недоработку, когда продукт уже готов, дороже, чем если выявить её при разработке. И дешевле, если сделать это на этапе формирования требований. СК помогает системно подойти к вопросу качества продукта и не допустить типовых ошибок на всех этапах.
Мы считаем, что СК нужна всем компаниям независимо от масштаба, ведь любому бизнесу необходимо контролировать процессы, предотвращать ошибки, а также вовремя выявлять и исправлять недоработки.
Завтра расскажем, как начать выстраивать работу службы качества, а в пятницу – историю, когда неудача на проекте привела к изменениям в процессах.
P.S. «85% проблем качества вызваны процессами производства и только 15% – исполнителями». Джозеф Джуран – архитектор качества, экономист, теоретик менеджмента, автор «Справочника по контролю качества».
– рассказывает Екатерина Ремизова, наш директор по качеству
Служба качества (СК) помогает организовать все процессы в компании так, чтобы продукт был готов в срок с минимальными затратами, соответствовал задачам бизнеса и ожиданиям пользователей.
Чем занимается СК:
▪️ устанавливает и внедряет стандарты процессов разработки,
▪️ согласовывает критерии качества продуктов,
▪️ разрабатывает и внедряет метрики, по которым можно оценить качество работы всей компании,
▪️ отслеживает уровень удовлетворенности клиентов,
▪️ проводит аудиты работы на каждом уровне организации, в производственных и вспомогательных процессах, которые обеспечивают её работу.
А без службы качества можно?
Если в компании нет чёткой системы обеспечения качества, могут возникнуть следующие проблемы:
🔹 Сложно воспроизводить процессы в компании. При старте очередного проекта всегда приходится выстраивать разработку с нуля. СК организует все процессы один раз, а потом немного их корректирует и адаптирует под новые условия. Например, у нас на каждом проекте внедряются таск-трекер и базовые метрики: план-факт, процент возврата задач, процент Bugfix.
🔹 Возрастает цена ошибки. Исправить недоработку, когда продукт уже готов, дороже, чем если выявить её при разработке. И дешевле, если сделать это на этапе формирования требований. СК помогает системно подойти к вопросу качества продукта и не допустить типовых ошибок на всех этапах.
Мы считаем, что СК нужна всем компаниям независимо от масштаба, ведь любому бизнесу необходимо контролировать процессы, предотвращать ошибки, а также вовремя выявлять и исправлять недоработки.
Завтра расскажем, как начать выстраивать работу службы качества, а в пятницу – историю, когда неудача на проекте привела к изменениям в процессах.
👍4
С чего начать выстраивать работу службы качества
Мы в SimbirSoft начали выстраивать работу службы качества ещё в 2012 году. Тогда были, конечно, немного другие условия, требования и бизнес-процессы. Но нижеперечисленные действия — базовые, они актуальны и сейчас.
Шаг 1. Сформировать команду из штатных специалистов
Сотрудники службы качества должны быть погружены во внутренние процессы — знать обо всех тонкостях и целях компании. Можно нанять внешних специалистов, но основная часть команды должна быть из «своих».
Количество сотрудников в команде СК может быть разным — всё зависит от объёма задач.
Шаг 2. Определить обязанности и сферу деятельности, разработать и внедрить стандарты
Разработайте стандарты, на основе которых СК будет оценивать качество продукта и процессы компании. Опираться можно на собственный опыт — принять в качестве эталона лучшие процессы и практики, которые уже действуют в организации. И на базовые методологии: Agile, Waterfall, канбан, ISTQB — универсальную программу тестирования — и другие. Главное, не внедрять всё подряд, а выбирать то, что подойдёт вашей компании, исходя из её целей и компетенций.
За основу стандарта проведения внутренних аудитов можно взять ISO 19011 — «Руководящие указания по проведению аудита систем менеджмента». Адаптируйте его под вашу компанию. Например, мы используем этот стандарт для двух направлений.
• Основное. Поэтому оптимизировали этот стандарт таким образом, чтобы проводить параллельные аудиты быстрее. Упростили процесс интервью и сбор данных. А ещё автоматически рассчитываем метрики качества и прочее.
• Дополнительное — наём сотрудников. Здесь мы ничего не меняли, так как нам подошли стандартные процессы.
Когда команда СК знает, на что ориентироваться, — можно считать, что она готова к работе уже на 50%.
Шаг 3. Отслеживать работу компании с помощью службы качества
Проводить аудиты и оценивать результаты тоже можно по ISO 19011 — это один из самых логичных и понятных стандартов. Все результаты аудитов и инцидентов фиксируются. Из этой статистики можно выделить повторяющиеся ошибки. Далее СК анализирует ошибки, которые из раза в раз встречаются в разных проектах, выявляет их причины и предлагает решения.
Сколько нужно времени
На внедрение СК мы советуем закладывать около года — за такой срок получится сформировать команду, разработать документацию и организовать основные процессы. С технической стороны создать СК можно быстро, больше всего времени уходит на психологическую адаптацию. Сотрудникам нужно погрузиться в процессы обеспечения качества, перестроиться с разработки на аналитику.
Другим отделам необходимо привыкнуть к критике от аудиторов и проникнуться доверием к ним, особенно если раньше в компании этого не было. Мы в SimbirSoft выстроили настолько доверительные отношения между командами, что после стольких лет работы коллеги стали сами приходить в службу качества с просьбой провести внеплановый аудит.
Мы в SimbirSoft начали выстраивать работу службы качества ещё в 2012 году. Тогда были, конечно, немного другие условия, требования и бизнес-процессы. Но нижеперечисленные действия — базовые, они актуальны и сейчас.
Шаг 1. Сформировать команду из штатных специалистов
Сотрудники службы качества должны быть погружены во внутренние процессы — знать обо всех тонкостях и целях компании. Можно нанять внешних специалистов, но основная часть команды должна быть из «своих».
Количество сотрудников в команде СК может быть разным — всё зависит от объёма задач.
Шаг 2. Определить обязанности и сферу деятельности, разработать и внедрить стандарты
Разработайте стандарты, на основе которых СК будет оценивать качество продукта и процессы компании. Опираться можно на собственный опыт — принять в качестве эталона лучшие процессы и практики, которые уже действуют в организации. И на базовые методологии: Agile, Waterfall, канбан, ISTQB — универсальную программу тестирования — и другие. Главное, не внедрять всё подряд, а выбирать то, что подойдёт вашей компании, исходя из её целей и компетенций.
За основу стандарта проведения внутренних аудитов можно взять ISO 19011 — «Руководящие указания по проведению аудита систем менеджмента». Адаптируйте его под вашу компанию. Например, мы используем этот стандарт для двух направлений.
• Основное. Поэтому оптимизировали этот стандарт таким образом, чтобы проводить параллельные аудиты быстрее. Упростили процесс интервью и сбор данных. А ещё автоматически рассчитываем метрики качества и прочее.
• Дополнительное — наём сотрудников. Здесь мы ничего не меняли, так как нам подошли стандартные процессы.
Когда команда СК знает, на что ориентироваться, — можно считать, что она готова к работе уже на 50%.
Шаг 3. Отслеживать работу компании с помощью службы качества
Проводить аудиты и оценивать результаты тоже можно по ISO 19011 — это один из самых логичных и понятных стандартов. Все результаты аудитов и инцидентов фиксируются. Из этой статистики можно выделить повторяющиеся ошибки. Далее СК анализирует ошибки, которые из раза в раз встречаются в разных проектах, выявляет их причины и предлагает решения.
Сколько нужно времени
На внедрение СК мы советуем закладывать около года — за такой срок получится сформировать команду, разработать документацию и организовать основные процессы. С технической стороны создать СК можно быстро, больше всего времени уходит на психологическую адаптацию. Сотрудникам нужно погрузиться в процессы обеспечения качества, перестроиться с разработки на аналитику.
Другим отделам необходимо привыкнуть к критике от аудиторов и проникнуться доверием к ним, особенно если раньше в компании этого не было. Мы в SimbirSoft выстроили настолько доверительные отношения между командами, что после стольких лет работы коллеги стали сами приходить в службу качества с просьбой провести внеплановый аудит.
🔥3
Как «неудавшийся» релиз привёл к изменению в процессах
– рассказывает Екатерина Ремизова, наш директор по качеству
Безмятежное начало
Мы работали над классным проектом – приложением для online-тренировок. Под него собрали команду из аналитика, дизайнера, backend-, Android- и iOS-разработчиков, QA-специалиста и проектного менеджера. Первый релиз состоялся 20 октября. И только за первый месяц работы уже было 50+ тысяч скачиваний.
«А всё, а всё! А надо было раньше…» – никто тогда не знал
К Новому году мы с клиентом запланировали релиз дополнительных функций приложения и публикацию нового курса тренировок, рекламная кампания которого уже была в разгаре. Для самых быстрых предложили скидки, поэтому много пользователей уже были на низком старте. Всё подготовили, осталось дождаться окончания проверок от AppStore и Google Play. И вот 30 декабря проверки закончились, а на 31 декабря клиент запланировал релиз – ему хотелось побыстрее запустить его. Мы пошли у него на поводу...
Запах мандаринов покинул чат
Вечер 31 декабря, обновление выпущено в прод, команда расслабилась и ушла нарезать оливье и смотреть «Иронию судьбы». В 19:54 появилось первое предупреждение о высокой нагрузке на базу данных. А спустя ещё час некоторые видео перестали открываться или прогружались долгое время. Суммарные загруженные данные вышли за предел, который был заложен в приложении и учтён в аналитике.
Вся команда была на телефонах, бросила дела и начала разбираться в ситуации. Backend-разработчик связался с DevOps и предложил донастроить кеширование на стороне СУБД.В 21:53 поняли, что дело плохо: на экранах пользователей появилась ошибка. В итоге за несколько часов до Нового года мы получили срыв запуска продукта.
Как потушили пожар
В 22:46 команда настроила кеширование и увеличила производительность сервера. Приложение начало работать. Но мы понимали, что это временно: принятые меры не решали проблему. Поэтому Новый год все члены команды встречали у компьютера, чтобы подключиться к работе в нужный момент. А с 1 января приступили к исправлению ситуации и подкорректировали код. До 5 января мониторили работу продукта: в процессе выскакивали проблемы с кешем Redis. После этого продукт работал без инцидентов, а мы смогли выдохнуть и начать работу над ошибками.
– рассказывает Екатерина Ремизова, наш директор по качеству
Безмятежное начало
Мы работали над классным проектом – приложением для online-тренировок. Под него собрали команду из аналитика, дизайнера, backend-, Android- и iOS-разработчиков, QA-специалиста и проектного менеджера. Первый релиз состоялся 20 октября. И только за первый месяц работы уже было 50+ тысяч скачиваний.
«А всё, а всё! А надо было раньше…» – никто тогда не знал
К Новому году мы с клиентом запланировали релиз дополнительных функций приложения и публикацию нового курса тренировок, рекламная кампания которого уже была в разгаре. Для самых быстрых предложили скидки, поэтому много пользователей уже были на низком старте. Всё подготовили, осталось дождаться окончания проверок от AppStore и Google Play. И вот 30 декабря проверки закончились, а на 31 декабря клиент запланировал релиз – ему хотелось побыстрее запустить его. Мы пошли у него на поводу...
Запах мандаринов покинул чат
Вечер 31 декабря, обновление выпущено в прод, команда расслабилась и ушла нарезать оливье и смотреть «Иронию судьбы». В 19:54 появилось первое предупреждение о высокой нагрузке на базу данных. А спустя ещё час некоторые видео перестали открываться или прогружались долгое время. Суммарные загруженные данные вышли за предел, который был заложен в приложении и учтён в аналитике.
Вся команда была на телефонах, бросила дела и начала разбираться в ситуации. Backend-разработчик связался с DevOps и предложил донастроить кеширование на стороне СУБД.В 21:53 поняли, что дело плохо: на экранах пользователей появилась ошибка. В итоге за несколько часов до Нового года мы получили срыв запуска продукта.
Как потушили пожар
В 22:46 команда настроила кеширование и увеличила производительность сервера. Приложение начало работать. Но мы понимали, что это временно: принятые меры не решали проблему. Поэтому Новый год все члены команды встречали у компьютера, чтобы подключиться к работе в нужный момент. А с 1 января приступили к исправлению ситуации и подкорректировали код. До 5 января мониторили работу продукта: в процессе выскакивали проблемы с кешем Redis. После этого продукт работал без инцидентов, а мы смогли выдохнуть и начать работу над ошибками.
👏3❤1
Что в итоге мы изменили у себя в процессах
1. Ввели архитектурный надзор в каждом производственном направлении. Проводим ревью разрабатываемой архитектуры на контрольных точках проекта, которые определяют PM.
2. При тестировании используем только релевантные данные и строго это контролируем. Это помогает увидеть реальную картину и проработать корректные требования для продукта.
3. Проводим минимальное нагрузочное тестирование продукта, даже если клиент считает, что оно не нужно. И анализируем необходимость полноценных нагрузочных тестирований на каждом проекте, чтобы понять, сколько пользователей выдержит инфраструктура продукта и какие «узкие» места в ней есть.
4. Не делаем релизов в предвыходные и предпраздничные дни :)
P.S. Когда я села писать историю об этом кейсе, у меня даже мысль возникла: «А как мы это упустили? У нас же есть контроль на уровне архитектуры и сбора требований». А потом поняла: да это же как раз после этого инцидента ввели :)))
Разработка без ошибок – это в идеальном мире. Самое главное – делать выводы, учиться на ошибках и непрерывно улучшать процессы создания программных продуктов.
1. Ввели архитектурный надзор в каждом производственном направлении. Проводим ревью разрабатываемой архитектуры на контрольных точках проекта, которые определяют PM.
2. При тестировании используем только релевантные данные и строго это контролируем. Это помогает увидеть реальную картину и проработать корректные требования для продукта.
3. Проводим минимальное нагрузочное тестирование продукта, даже если клиент считает, что оно не нужно. И анализируем необходимость полноценных нагрузочных тестирований на каждом проекте, чтобы понять, сколько пользователей выдержит инфраструктура продукта и какие «узкие» места в ней есть.
4. Не делаем релизов в предвыходные и предпраздничные дни :)
P.S. Когда я села писать историю об этом кейсе, у меня даже мысль возникла: «А как мы это упустили? У нас же есть контроль на уровне архитектуры и сбора требований». А потом поняла: да это же как раз после этого инцидента ввели :)))
Разработка без ошибок – это в идеальном мире. Самое главное – делать выводы, учиться на ошибках и непрерывно улучшать процессы создания программных продуктов.
🔥4👏2
#резюменедели
Опубликовали чек-лист: набор метрик, который поможет управлять проектом и обеспечивать его качество ✔️
Он поможет узнать, насколько эффективна ваша команда сейчас, проверить уровень качества проекта и подскажет, как можно улучшить работу.
Выступили с докладом на онлайн-конференции DIGITAL ЛЕТО от Roistat 🗣
Наш sales-менеджер Павел рассказал про новые инструменты контент-аналитики в B2B — возможности и кейсы применения.
Рассказали о проектах 🔏
Аудит инфраструктуры комплексного решения для ресторанного холдинга
Опубликовали чек-лист: набор метрик, который поможет управлять проектом и обеспечивать его качество ✔️
Он поможет узнать, насколько эффективна ваша команда сейчас, проверить уровень качества проекта и подскажет, как можно улучшить работу.
Выступили с докладом на онлайн-конференции DIGITAL ЛЕТО от Roistat 🗣
Наш sales-менеджер Павел рассказал про новые инструменты контент-аналитики в B2B — возможности и кейсы применения.
Рассказали о проектах 🔏
Аудит инфраструктуры комплексного решения для ресторанного холдинга
👍6
Бесконечные правки и новые требования перед релизом
Контекст
☝️ Такое произошло с нашим менеджером по управлению проектами Екатериной. Под её руководством была команда, которая «под ключ» создавала для заказчика корпоративный портал.
На старте с клиентом согласовали техническое задание и макеты, утвердили логику работы и roadmap, а после каждого спринта проводили демонстрацию разработанного. Внезапно в компании заказчика изменился ответственный за проект специалист с другим видением портала. И вот дата релиза уже не за горами, а в работу прилетели новые фичи.
Что делать?.. 🤔
Екатерина провела с клиентом приоритизацию новых фич, а затем их оценку. Проверила, что из этого списка команда точно успеет сделать и взять в релиз, а по остальным задачам предложила несколько вариантов:
1) Выпустить MVP-версию, а после составить план по доработке портала и внести дополнительные фичи.
2) Увеличить команду, если важно взять в релиз все и успеть вовремя.
3) Сдвинуть дату релиза.
Чтобы принять решение, нужно было донести до клиента:
▪️ плюсы и минусы каждого решения;
▪️ информацию о том, что каждую новую фичу необходимо не только разработать, но и протестировать, а также заложить на это ресурсы;
▪️ свериться с бюджетом проекта и определить, какие из этих шагов можно себе позволить уже сейчас, а какие позже.
Совместно с клиентом мы решили придерживаться согласованного ранее плана, выпустить MVP-версию, утвердить новые фичи и их приоритет, а затем доработать портал.
Контекст
☝️ Такое произошло с нашим менеджером по управлению проектами Екатериной. Под её руководством была команда, которая «под ключ» создавала для заказчика корпоративный портал.
На старте с клиентом согласовали техническое задание и макеты, утвердили логику работы и roadmap, а после каждого спринта проводили демонстрацию разработанного. Внезапно в компании заказчика изменился ответственный за проект специалист с другим видением портала. И вот дата релиза уже не за горами, а в работу прилетели новые фичи.
Что делать?.. 🤔
Екатерина провела с клиентом приоритизацию новых фич, а затем их оценку. Проверила, что из этого списка команда точно успеет сделать и взять в релиз, а по остальным задачам предложила несколько вариантов:
1) Выпустить MVP-версию, а после составить план по доработке портала и внести дополнительные фичи.
2) Увеличить команду, если важно взять в релиз все и успеть вовремя.
3) Сдвинуть дату релиза.
Чтобы принять решение, нужно было донести до клиента:
▪️ плюсы и минусы каждого решения;
▪️ информацию о том, что каждую новую фичу необходимо не только разработать, но и протестировать, а также заложить на это ресурсы;
▪️ свериться с бюджетом проекта и определить, какие из этих шагов можно себе позволить уже сейчас, а какие позже.
Совместно с клиентом мы решили придерживаться согласованного ранее плана, выпустить MVP-версию, утвердить новые фичи и их приоритет, а затем доработать портал.
👍4🔥1👏1
#резюменедели
Порадовались отзывам клиентов 🥰
+1 отзыв на Wadline от ЮMoney:
«Высокие стандарты разработки SimbirSoft делают нашу совместную работу над проектами проще и эффективнее» 😎
Получили награды 🏆
В нашей копилке разные достижения – в этот раз заняли 1 место в турнире по лазертагу на UL CAMP)
Рассказали о проекте 🔏
Сервис автоматизации финансовой аналитики для «МК Лизинг»
Порадовались отзывам клиентов 🥰
+1 отзыв на Wadline от ЮMoney:
«Высокие стандарты разработки SimbirSoft делают нашу совместную работу над проектами проще и эффективнее» 😎
Получили награды 🏆
В нашей копилке разные достижения – в этот раз заняли 1 место в турнире по лазертагу на UL CAMP)
Рассказали о проекте 🔏
Сервис автоматизации финансовой аналитики для «МК Лизинг»
🔥4🎉2
Контрольные точки – проверяем, что на проекте всё хорошо
Допустим, вы занимаетесь разработкой системы. Недавно перед командой поставили новые амбициозные задачи с жёсткими сроками. Работа кипит, однако вы замечаете, что уже третий спринт в релиз выходит гораздо меньше задач, чем вы запланировали.
Если бы на проекте была внедрена метрика возврата задач, то вы смогли бы выявить и решить проблему на ранней стадии. Например: когда такой показатель больше 20%, то это сигнал, что пора разобраться – возможно, дополнительно обсудить ТЗ с участниками команды.
Нужные метрики подбираются индивидуально под каждый проект и позволяют контролировать процесс создания продукта. Как правило, к базовому набору относят следующие:
▪️ План-факт. Позволяет выявить отклонения в данных в большую или меньшую сторону от намеченного результата и вовремя скорректировать действия команды.
▪️Burndown. Демонстрирует, какой объём работы уже выполнен и сколько задач осталось решить до завершения спринта/проекта. Помогает отслеживать темп работы и понимать, когда следует ускориться.
▪️Процент возврата задач — как часто таски приходят на доработку. Благодаря этой метрике, мы вовремя можем заметить сложности на проекте и быстро их пофиксить.
▪️Процент Bug Fix. Показывает отношение часов, затраченных на разработку ко времени багофикса. Благодаря этим данным, мы сможем быстро обнаружить, что команда больше занимается багами, чем созданием продукта. И исправить ситуацию до завершения спринта.
Мы в SimbirSoft ежедневно проводим мониторинг около 15 показателей по проектам (сроки, качество, бюджет и т.д.). Таким образом мы видим все «движения» в организации и можем вовремя заметить отклонение.
Допустим, вы занимаетесь разработкой системы. Недавно перед командой поставили новые амбициозные задачи с жёсткими сроками. Работа кипит, однако вы замечаете, что уже третий спринт в релиз выходит гораздо меньше задач, чем вы запланировали.
Если бы на проекте была внедрена метрика возврата задач, то вы смогли бы выявить и решить проблему на ранней стадии. Например: когда такой показатель больше 20%, то это сигнал, что пора разобраться – возможно, дополнительно обсудить ТЗ с участниками команды.
Нужные метрики подбираются индивидуально под каждый проект и позволяют контролировать процесс создания продукта. Как правило, к базовому набору относят следующие:
▪️ План-факт. Позволяет выявить отклонения в данных в большую или меньшую сторону от намеченного результата и вовремя скорректировать действия команды.
▪️Burndown. Демонстрирует, какой объём работы уже выполнен и сколько задач осталось решить до завершения спринта/проекта. Помогает отслеживать темп работы и понимать, когда следует ускориться.
▪️Процент возврата задач — как часто таски приходят на доработку. Благодаря этой метрике, мы вовремя можем заметить сложности на проекте и быстро их пофиксить.
▪️Процент Bug Fix. Показывает отношение часов, затраченных на разработку ко времени багофикса. Благодаря этим данным, мы сможем быстро обнаружить, что команда больше занимается багами, чем созданием продукта. И исправить ситуацию до завершения спринта.
Мы в SimbirSoft ежедневно проводим мониторинг около 15 показателей по проектам (сроки, качество, бюджет и т.д.). Таким образом мы видим все «движения» в организации и можем вовремя заметить отклонение.
👍5
Media is too big
VIEW IN TELEGRAM
Ставим задачу так, чтобы исполнитель понял 👍
#резюменедели
Провели мероприятие и анонсировали новые 🗣
▪️ Провели A warm Backend Meetup в Краснодаре. Поговорили об особенностях искусственного интеллекта и разработки моделей, а также о DWH и Data Lake
▪️ 26 августа проведём Backend Meetup в Самаре, а 9 сентября в Казани
▪️ Стартуем 27 сентября SDET-практикум
Рассказали о проекте 🔏
MVP мобильного приложения для международного маркетплейса
Дали комментарии СМИ 📰
РБК: Microsoft перестанет продлевать подписки корпоративным клиентам из России
Провели мероприятие и анонсировали новые 🗣
▪️ Провели A warm Backend Meetup в Краснодаре. Поговорили об особенностях искусственного интеллекта и разработки моделей, а также о DWH и Data Lake
▪️ 26 августа проведём Backend Meetup в Самаре, а 9 сентября в Казани
▪️ Стартуем 27 сентября SDET-практикум
Рассказали о проекте 🔏
MVP мобильного приложения для международного маркетплейса
Дали комментарии СМИ 📰
РБК: Microsoft перестанет продлевать подписки корпоративным клиентам из России
👍2🤩1
Задачка для менеджеров
Команда вашего проекта состоит из backend- и frontend-разработчиков, аналитика, QA, дизайнера, тимлида (вас) и продакт-менеджера. При подготовке к релизу внезапно изменились требования и сдвинулись сроки – дата релиза стала гораздо ближе.
Клиент готов подписать приложение к договору, в котором будут отражены все изменения.
С комментариями вернёмся завтра 🤗
Команда вашего проекта состоит из backend- и frontend-разработчиков, аналитика, QA, дизайнера, тимлида (вас) и продакт-менеджера. При подготовке к релизу внезапно изменились требования и сдвинулись сроки – дата релиза стала гораздо ближе.
Клиент готов подписать приложение к договору, в котором будут отражены все изменения.
С комментариями вернёмся завтра 🤗
Мы к вам с ответами ✌️
Вариант А – в рамках договора и перед законом вы правы. Однако вряд ли клиент продолжит сотрудничество с подрядчиком, который не слышит его проблему. Кто знает, возможно, ситуация изменилась настолько, что продукт без правок и к другой дате клиенту больше не нужен.
Вариант B не про продуктивную команду, которая качественно выполняет свои задачи. У специалистов должен быть нормальный рабочий график и время на отдых. Выгорание никого не щадит — даже при дополнительной оплате.
Вариант С мы считаем самым оптимальным. Клиенту важно внести новые фичи до релиза и выпустить продукт раньше, а команда должна качественно всё реализовать – чтобы этого добиться, нам нужно больше ресурсов.
Вариант А – в рамках договора и перед законом вы правы. Однако вряд ли клиент продолжит сотрудничество с подрядчиком, который не слышит его проблему. Кто знает, возможно, ситуация изменилась настолько, что продукт без правок и к другой дате клиенту больше не нужен.
Вариант B не про продуктивную команду, которая качественно выполняет свои задачи. У специалистов должен быть нормальный рабочий график и время на отдых. Выгорание никого не щадит — даже при дополнительной оплате.
Вариант С мы считаем самым оптимальным. Клиенту важно внести новые фичи до релиза и выпустить продукт раньше, а команда должна качественно всё реализовать – чтобы этого добиться, нам нужно больше ресурсов.
👍7😱1
#резюменедели
🏆 Вошли в рейтинг крупнейших ИТ-поставщиков для ритейла
Поделились со СМИ 📰 своим мнением по разработке системы, позволяющей предиктивно анализировать потребности рынка труда. А еще обсудили перевод инфраструктуры с сервисов Microsoft.
Выпустили первую и вторую часть дневника разработки по проекту РОСТ (Карьера.онлайн) 🔏
Ну и на сладкое — рассказали, как гостили у @severstal 🥰
🏆 Вошли в рейтинг крупнейших ИТ-поставщиков для ритейла
Поделились со СМИ 📰 своим мнением по разработке системы, позволяющей предиктивно анализировать потребности рынка труда. А еще обсудили перевод инфраструктуры с сервисов Microsoft.
Выпустили первую и вторую часть дневника разработки по проекту РОСТ (Карьера.онлайн) 🔏
Ну и на сладкое — рассказали, как гостили у @severstal 🥰
🔥3🤔1
Наши дизайнеры подготовили карточки с правилами хорошей UX-редактуры, которые помогут иначе взглянуть на текст в интерфейсе и избежать ошибок при реализации продукта.
❤5👍1