Вопросы зрителей всегда обогащают и расширяют любое выступление. Рады, что тема вызывает отклик и наши гости так активно участвуют 🔥

Разработка под ключ, но не с нуля 🧐 Как организовать?
Кейс
На одном проекте нам надо было реализовать единую систему управления для всех производственных процессов.
До этого заказчик пользовался двумя сервисами: во-первых, это было неудобно, во-вторых, функциональности не хватало. Так вот нашей задачей было объединить их преимущества и полностью покрыть бизнес-процессы. Документации на них не было.

Как организовывали процесс
1️⃣ В таком проекте важно работать в тесном контакте с командой заказчика, чтобы каждая заинтересованная сторона знала о необходимых изменениях, задачах и их актуальности. Поэтому ещё на этапе сбора требований мы определили и зафиксировали каналы и формат коммуникаций:
▪️ планировали встречи через google-календари примерно в одно и то же время, чтобы обеспечить максимальную посещаемость;
▪️ обговаривали повестку встречи заранее и прописывали тайминг встреч;
▪️ фиксировали достигнутые договорённости письменно и оповещали все заинтересованные стороны.
Всё это помогло нам выстроить эффективную коммуникацию с клиентом и наладить работу с ожиданиями.

2️⃣ После того как произвели приемку сервисов клиента, мы погрузились в продукт и стали анализировать логику и требуемый к переносу функционал. Составили ТЗ, в котором отразили реализацию 5 блоков бизнес-процессов, а также сформировали дорожную карту этапов разработки. Для того чтобы учесть все узкие места, мы провели QA-ревью документации и предоставили заказчику финальную версию.

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

Последний день рабочей недели – время подводить её итоги)

Провели мероприятие 🗣
70+ комментариев получили, на 20+ вопросов ответили, дополнительные материалы участникам отправили 🍾 Теперь наши участники знают о «Цене ошибки» больше 😉

Получили награды 🏆
Первые в рейтинге digirate среди digital-подрядчиков по выручке в 2022 году 🥇

Дали комментарии СМИ 📰
Коммерсант: Промышленникам добавят интеллекта
Эксперт: IT-сектору пообещали новые миллиарды на решение старых проблем

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

Как развивать soft skills
1. Для системного развития soft skills критически важно определить свои слабые стороны, например, с помощью комплексного метода оценки компетенций — ассессмента, и получить объективные результаты.
2. Важно принять эти результаты, упорядочить данные и выявить те навыки, которые нужно прокачать.
3. После этого необходимо составить план обучения на основе конференций, книг, тренингов по выбранной теме.
4. Окончив обучение, нужно рассказать коллегам о том, какие знания ты получил. Это помогает систематизировать полученную информацию и ещё раз пройти обучение внутренне.

Почему источник требований важен для команды
Кейс
Заказчик одного из проектов рассказал нашему ПМу, что 70% требований идёт со стороны их внутренней службы поддержки, так как конечный пользователь системы – крупный банк.
Конечно, это неудобный и несистемный способ мониторить запросы клиента. Наша команда моментально отреагировала на данный факт и внедрила автоматическое отслеживание ошибок, чтобы точнее понимать, с какими трудностями сталкиваются пользователи. Более того, ребята предложили устраивать предрелизные демонстрации конечному клиенту, чтобы формировать его ожидания от новых релизов.
Всё это привело к следующим результатам:
▪️ более глубокая аналитика, благодаря пониманию источников требований,
▪️ снижение нагрузки на саппорт,
▪️ долгосрочное сотрудничество с клиентом.

Что из этого следует
На первых этапах важно познакомить специалистов с представителями бизнеса и владельцем продукта, донести до заказчика важность контакта. Команда должна понимать источники требований, цели разработки IT-решения и портрет конечного пользователя. Впоследствии это поможет расставлять приоритеты, понимать, для чего разрабатывается та или иная фича, улучшать план тестирования и т.п.
Коммуникации должны быть направлены на снижение рисков, связанных с долгой передачей информации о новых требованиях, изменением сроков или отсутствием обратной связи.
Сотрудничество команды разработки и клиента помогает достичь общей цели.

Наши партнёры веб-интегратор Extyl уже пару лет ведут канал о digital-разработке: рассказывают, как выигрывать тендеры, управлять командой и считать бюджеты.

Делимся полезными постами:
🔹 Как выйти из операционки в бизнесе?
🔹 Синдром самозванца: почему возникает и как с ним бороться
🔹 Нанимать или взращивать? Откуда брать руководителей
🔹 Как выигрывать тендеры?
🔹 Способ мошенничества в тендерах

Это наш топ, но внутри ещё много полезного – посмотрите 😉

Как Linkory поможет вашему бизнесу
Помните, мы писали про наш стартап в сфере маркетинга и продаж?) Рассказываем подробнее 😎👇

Все действия клиентов отслеживаются в режиме онлайн. Linkory покажет, что и когда смотрят ваши клиенты в реальном времени, а также пришлё уведомления о посещении страниц.

Благодаря аналитике сервиса вы сможете:
▪️ видеть действия клиентов, которым вы отправили ссылку;
▪️ увидеть, где в КП у клиента возникают сложности;
▪️ напомнить о себе сразу после прочтения предложения, пока вы ещё в голове клиента;
▪️ подготовиться к следующему созвону. Если пользователь долго был на слайде «цены», возможно, ваши услуги для него дороги. Объясните ценности вашей работы и почему она так стоит.

Всё это поможет сделать предложение лучше и увеличит ваши продажи. Помните, что аналитика это совместная работа отделов маркетинга и продаж. Подружите их между собой 🤝

Связаться с нами можно тут:
📍 https://s.simbirsoft.com/VjSB
📩 mail@linkory.io
📱 8(495)-179-38-33

Lean и Six Sigma в управлении проектами
– рассказывает Екатерина, наш PM

☝️ Эти методики – следующие по популярности после Agile. Открыты уже давно, правда изначально разрабатывались для совершенствования процессов на производстве. Теперь «дошли» до образования, IT и других сфер.
Рост интереса к адаптации методик Lean и Six Sigma в IT, на мой взгляд, можно связать с тем, что в непростых экономических условиях практически от каждого руководителя IT-проекта или целого IT-департамента бизнес требует сокращения затрат без потери качества.

Обзорно о методиках
В концепции Lean (бережливое производство и управление) главный критерий – ценность продукта для бизнеса и вовлечённость всей команды. Впервые внедрили в Toyota для устранения потерь и уменьшения затрат без ухудшения качества.
Six Sigma – метод управления и совершенствования производства через выявление и исключение причин дефектов в бизнес-процессах, а также концентрацию на требованиях потребителя. Здесь была первой Motorola.

Они хорошо подходят для больших компаний и проектов, где нужно максимально быстро проверить гипотезу или улучшить качество уже действующего продукта, например, когда он перешёл к вам на доработку после предыдущего подрядчика. Lean используют «РЖД», «Почта России», «Сбер»; а Six Sigma – «РОСТАР», «Инструм-Рэнд», «АВИСМА».
Как показывает практика нашей компании и мой личный опыт PM, методики Lean и Six Sigma помогают развивать системное мышление, решать нестандартные задачи и непрерывно улучшать процессы и продукты, удовлетворяя все запросы клиентов. В условиях быстро меняющихся реалий и требований рынка это очень актуально.

На этой неделе разберём каждую методику по отдельности, и я расскажу, для каких проектов и задач они подходят лучше. Завтра ждите пост о Lean, а в четверг – о Six Sigma.

Lean
В Lean-подходе фокус на непрерывное улучшение бизнес-процессов без радикальных изменений. Так мы не рушим существующую структуру и, соответственно, избегаем связанных с этим проблем.
🏚🏗🏰 Сломать всё и построить круто с нуля? – Нет.
🏚🏠🏡🏘 Шаг за шагом совершенствовать? – Да.

Принцип 5s:
▪️ sort – сортировка операций на значимые и ненужные,
▪️ set in order – упорядочивание предметов и процессов,
▪️ shine – поддержание порядка и чистоты,
▪️ standardise – внедрение норм и организация порядка для реализации правил,
▪️ sustain – совершенствование за счет мотивации и самодисциплины работников.

1. Устраняем потери. Анализируем процессы и выделяем всё то, от чего можно отказаться. Например, дополнительные, но ненужные пользователю фичи; несколько разрозненных каналов связи для передачи информации по проекту и др.
2. Повышаем качество. Встраиваем тестирование с начальных этапов разработки.
3. Создаём знания. База данных проекта поможет как команде, так и клиенту.
4. Откладываем «обязательства». Имея несколько вариантов, не стремитесь сразу принимать решение, а отсрочьте его на безопасный для проекта срок. Когда придёт время, будет больше доступной информации, поэтому будет легче сделать корректные выводы. Сравнение планируемых и фактических показателей поможет корректировать оперативные решения.
5. Организовываем быстрый выпуск. Частые релизы помогают отслеживать процесс реализации продукта и попадание в ожидания клиента.
6. Уважаем мнение людей. Универсальный принцип – важно прислушиваться к команде, поскольку они непосредственно участвуют в процессах.
7. Оптимизируем целое. Важно определить главную ценность и цель продукта и выстраивать разработку уже от них. Исправляем в первую очередь важные этапы, чтобы потом не переделывать несколько раз. Так минимизируются потери времени на неверную стратегию реализации.

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

Где подходит
Поскольку Lean заточен на скорость, методику целесообразно применять там, где нужно максимально быстро проверить гипотезу. Например, при создании MVP.

Six Sigma
В Six Sigma концепции фокус на качество и на удовлетворение клиентов. Чтобы достичь этого, нужно сокращать ошибки в организации и исполнении процессов.

Компоненты:
☺️ Удовлетворение потребителя. Определяем и учитываем все требования клиента.
☺️ 🔀 Выявление процессов, показателей и методов управления. На всю цепочку процессов смотрим через призму потребностей клиента, ориентируемся на неё и корректируем при необходимости.
☺️ 🔀 🤝 Командная работа. Чтобы улучшение отдельных процессов было более скоординированным, обеспечиваем прозрачность для всех участников. Отлаженная командная работа поможет добиться качества.

5 шагов DMAIC (define, measure, analyze, improve, control – определять, измерять, анализировать, улучшать, контролировать)
1. Определяем основные проблемы, формируем команду по улучшению процесса и прописываем зону ответственности.
2. Чтобы выяснить текущее положение проекта, проводим измерение процессов.
3. Анализируем полученные данные, устраняем причины и предлагаем методы по устранению причин.
4. Разрабатываем способы внедрения улучшений в процесс.
5. Заносим в документацию и контролируем улучшения после изменения процессов.

Где подходит
Six Sigma можно применять на проектах, где отлажена командная работа, так как внедрение концепции происходит за счёт управления отдельными задачами и процессами – они улучшаются независимо друг от друга. При этом нужен постоянный контроль, чтобы система не перестала функционировать, пока происходят изменения.

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

Получили награды 🏆
▪️ Заняли места в ТОП-10 и ТОП-20 рейтингов RAEX среди крупнейших IT-компаний
▪️ Попали в ТОП-100 крупнейших IT-разработчиков, по версии CNews

Поделились важным 💙
Это сейчас у нас большая команда из 1300+ человек с 6 офисами в разных городах России и филиалом в США. А начиналось всё с маленького кабинета, 4 увлечённых программированием человек и банковского проекта из Японии. Вернуться вместе с нами в 2001 год и посмотреть, как росла наша SimbirSoft теперь можно на странице с нашей историей 📝

Рассказали о проектах 🔏
▪️ Сервис рассрочки для маркетплейса
▪️ Оптимизация работы мобильного приложения для ритейла
▪️ Модернизация системы управления производственным предприятием в 1С: ERP

Отпраздновали юбилей сотрудничества 🎊
Уже 15 лет мы партнёры с Международной цифровой олимпиадой «Волга-IT»! В 2008 году подключились к олимпиаде – взрыв, буря, эмоции!☺️ А теперь ежегодно являемся одними из организаторов мероприятия и разрабатываем задание для дисциплины по Java и C#.

Зачем нужна служба качества в IT-компании
– рассказывает Екатерина Ремизова, наш директор по качеству

Служба качества (СК) помогает организовать все процессы в компании так, чтобы продукт был готов в срок с минимальными затратами, соответствовал задачам бизнеса и ожиданиям пользователей.
Чем занимается СК:
▪️ устанавливает и внедряет стандарты процессов разработки,
▪️ согласовывает критерии качества продуктов,
▪️ разрабатывает и внедряет метрики, по которым можно оценить качество работы всей компании,
▪️ отслеживает уровень удовлетворенности клиентов,
▪️ проводит аудиты работы на каждом уровне организации, в производственных и вспомогательных процессах, которые обеспечивают её работу.

А без службы качества можно?
Если в компании нет чёткой системы обеспечения качества, могут возникнуть следующие проблемы:
🔹 Сложно воспроизводить процессы в компании. При старте очередного проекта всегда приходится выстраивать разработку с нуля. СК организует все процессы один раз, а потом немного их корректирует и адаптирует под новые условия. Например, у нас на каждом проекте внедряются таск-трекер и базовые метрики: план-факт, процент возврата задач, процент Bugfix.
🔹 Возрастает цена ошибки. Исправить недоработку, когда продукт уже готов, дороже, чем если выявить её при разработке. И дешевле, если сделать это на этапе формирования требований. СК помогает системно подойти к вопросу качества продукта и не допустить типовых ошибок на всех этапах.

Мы считаем, что СК нужна всем компаниям независимо от масштаба, ведь любому бизнесу необходимо контролировать процессы, предотвращать ошибки, а также вовремя выявлять и исправлять недоработки.
Завтра расскажем, как начать выстраивать работу службы качества, а в пятницу – историю, когда неудача на проекте привела к изменениям в процессах.

P.S. «85% проблем качества вызваны процессами производства и только 15% – исполнителями». Джозеф Джуран – архитектор качества, экономист, теоретик менеджмента, автор «Справочника по контролю качества».

С чего начать выстраивать работу службы качества
Мы в SimbirSoft начали выстраивать работу службы качества ещё в 2012 году. Тогда были, конечно, немного другие условия, требования и бизнес-процессы. Но нижеперечисленные действия — базовые, они актуальны и сейчас.
Шаг 1. Сформировать команду из штатных специалистов
Сотрудники службы качества должны быть погружены во внутренние процессы — знать обо всех тонкостях и целях компании. Можно нанять внешних специалистов, но основная часть команды должна быть из «своих».
Количество сотрудников в команде СК может быть разным — всё зависит от объёма задач.
Шаг 2. Определить обязанности и сферу деятельности, разработать и внедрить стандарты
Разработайте стандарты, на основе которых СК будет оценивать качество продукта и процессы компании. Опираться можно на собственный опыт — принять в качестве эталона лучшие процессы и практики, которые уже действуют в организации. И на базовые методологии: Agile, Waterfall, канбан, ISTQB — универсальную программу тестирования — и другие. Главное, не внедрять всё подряд, а выбирать то, что подойдёт вашей компании, исходя из её целей и компетенций.
За основу стандарта проведения внутренних аудитов можно взять ISO 19011 — «Руководящие указания по проведению аудита систем менеджмента». Адаптируйте его под вашу компанию. Например, мы используем этот стандарт для двух направлений.
• Основное. Поэтому оптимизировали этот стандарт таким образом, чтобы проводить параллельные аудиты быстрее. Упростили процесс интервью и сбор данных. А ещё автоматически рассчитываем метрики качества и прочее.
• Дополнительное — наём сотрудников. Здесь мы ничего не меняли, так как нам подошли стандартные процессы.
Когда команда СК знает, на что ориентироваться, — можно считать, что она готова к работе уже на 50%.
Шаг 3. Отслеживать работу компании с помощью службы качества
Проводить аудиты и оценивать результаты тоже можно по ISO 19011 — это один из самых логичных и понятных стандартов. Все результаты аудитов и инцидентов фиксируются. Из этой статистики можно выделить повторяющиеся ошибки. Далее СК анализирует ошибки, которые из раза в раз встречаются в разных проектах, выявляет их причины и предлагает решения.

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

Как «неудавшийся» релиз привёл к изменению в процессах
– рассказывает Екатерина Ремизова, наш директор по качеству

Безмятежное начало
Мы работали над классным проектом – приложением для online-тренировок. Под него собрали команду из аналитика, дизайнера, backend-, Android- и iOS-разработчиков, QA-специалиста и проектного менеджера. Первый релиз состоялся 20 октября. И только за первый месяц работы уже было 50+ тысяч скачиваний.

«А всё, а всё! А надо было раньше…» – никто тогда не знал
К Новому году мы с клиентом запланировали релиз дополнительных функций приложения и публикацию нового курса тренировок, рекламная кампания которого уже была в разгаре. Для самых быстрых предложили скидки, поэтому много пользователей уже были на низком старте. Всё подготовили, осталось дождаться окончания проверок от AppStore и Google Play. И вот 30 декабря проверки закончились, а на 31 декабря клиент запланировал релиз – ему хотелось побыстрее запустить его. Мы пошли у него на поводу...

Запах мандаринов покинул чат
Вечер 31 декабря, обновление выпущено в прод, команда расслабилась и ушла нарезать оливье и смотреть «Иронию судьбы». В 19:54 появилось первое предупреждение о высокой нагрузке на базу данных. А спустя ещё час некоторые видео перестали открываться или прогружались долгое время. Суммарные загруженные данные вышли за предел, который был заложен в приложении и учтён в аналитике.
Вся команда была на телефонах, бросила дела и начала разбираться в ситуации. Backend-разработчик связался с DevOps и предложил донастроить кеширование на стороне СУБД.В 21:53 поняли, что дело плохо: на экранах пользователей появилась ошибка. В итоге за несколько часов до Нового года мы получили срыв запуска продукта.

Как потушили пожар
В 22:46 команда настроила кеширование и увеличила производительность сервера. Приложение начало работать. Но мы понимали, что это временно: принятые меры не решали проблему. Поэтому Новый год все члены команды встречали у компьютера, чтобы подключиться к работе в нужный момент. А с 1 января приступили к исправлению ситуации и подкорректировали код. До 5 января мониторили работу продукта: в процессе выскакивали проблемы с кешем Redis. После этого продукт работал без инцидентов, а мы смогли выдохнуть и начать работу над ошибками.

Что в итоге мы изменили у себя в процессах
1. Ввели архитектурный надзор в каждом производственном направлении. Проводим ревью разрабатываемой архитектуры на контрольных точках проекта, которые определяют PM.
2. При тестировании используем только релевантные данные и строго это контролируем. Это помогает увидеть реальную картину и проработать корректные требования для продукта.
3. Проводим минимальное нагрузочное тестирование продукта, даже если клиент считает, что оно не нужно. И анализируем необходимость полноценных нагрузочных тестирований на каждом проекте, чтобы понять, сколько пользователей выдержит инфраструктура продукта и какие «узкие» места в ней есть.
4. Не делаем релизов в предвыходные и предпраздничные дни :)

P.S. Когда я села писать историю об этом кейсе, у меня даже мысль возникла: «А как мы это упустили? У нас же есть контроль на уровне архитектуры и сбора требований». А потом поняла: да это же как раз после этого инцидента ввели :)))
Разработка без ошибок – это в идеальном мире. Самое главное – делать выводы, учиться на ошибках и непрерывно улучшать процессы создания программных продуктов.

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

Опубликовали чек-лист: набор метрик, который поможет управлять проектом и обеспечивать его качество ✔️
Он поможет узнать, насколько эффективна ваша команда сейчас, проверить уровень качества проекта и подскажет, как можно улучшить работу.

Выступили с докладом на онлайн-конференции DIGITAL ЛЕТО от Roistat 🗣
Наш sales-менеджер Павел рассказал про новые инструменты контент-аналитики в B2B — возможности и кейсы применения.

Рассказали о проектах  🔏
Аудит инфраструктуры комплексного решения для ресторанного холдинга

Бесконечные правки и новые требования перед релизом
Контекст
☝️ Такое произошло с нашим менеджером по управлению проектами Екатериной. Под её руководством была команда, которая «под ключ» создавала для заказчика корпоративный портал.
На старте с клиентом согласовали техническое задание и макеты, утвердили логику работы и roadmap, а после каждого спринта проводили демонстрацию разработанного. Внезапно в компании заказчика изменился ответственный за проект специалист с другим видением портала. И вот дата релиза уже не за горами, а в работу прилетели новые фичи.

Что делать?.. 🤔
Екатерина провела с клиентом приоритизацию новых фич, а затем их оценку. Проверила, что из этого списка команда точно успеет сделать и взять в релиз, а по остальным задачам предложила несколько вариантов:
1) Выпустить MVP-версию, а после составить план по доработке портала и внести дополнительные фичи.
2) Увеличить команду, если важно взять в релиз все и успеть вовремя.
3) Сдвинуть дату релиза.

Чтобы принять решение, нужно было донести до клиента:
▪️ плюсы и минусы каждого решения;
▪️ информацию о том, что каждую новую фичу необходимо не только разработать, но и протестировать, а также заложить на это ресурсы;
▪️ свериться с бюджетом проекта и определить, какие из этих шагов можно себе позволить уже сейчас, а какие позже.

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

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

Порадовались отзывам клиентов 🥰
+1 отзыв на Wadline от ЮMoney:
«Высокие стандарты разработки SimbirSoft делают нашу совместную работу над проектами проще и эффективнее» 😎

Получили награды 🏆
В нашей копилке разные достижения – в этот раз заняли 1 место в турнире по лазертагу на UL CAMP)

Рассказали о проекте 🔏
Сервис автоматизации финансовой аналитики для «МК Лизинг»