5 must have в создании качественного ПО: инструментарий, «инциденты», общение с клиентом и прочее

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

@rb_ru

Где «подстелить солому», чтобы получить конкурентоспособный прибыльный продукт? 🧐 Вместе с нашим директором по качеству Екатериной разбираем:

1. Сбор требований и ожиданий заказчика
2. Внимание к бюджету и дополнительным расходам
3. Правильный выбор инструментов
4. Чёткость и понятность процессов
5. Промежуточные результаты

Для каждого пункта рассказали:
➡️ С какими трудностями мы сталкивались
➡️ Полученные выводы (Что делать?)

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

Созвоны: что делать руководителю, чтобы они не становились «пожирателями времени»

1️⃣ Обозначать тему и цели
Так вы дадите шанс команде подготовиться к разговору – как минимум найти и открыть нужную задачу, чтобы она была перед глазами.
2️⃣ Ограничивать круг участников встречи
Конечно, хочется максимальной прозрачности, чтобы вся команда была в курсе всех событий на проекте. Но чем крупнее ваш проект, тем выше вероятность, что с таким подходом команда будет проводить весь свой рабочий день на созвонах. Собрались 50 человек и слушают дискуссию пяти в течение часа.
Нужно заранее определить, кто нужен на созвоне. Сообщая о митинге, тэгнуть необходимый состав или сделать рассылку на корпоративную почту. А для поддержания прозрачности процессов – отправить резюме созвона в общий чат.
3️⃣ Модерировать процесс
Если вы организатор созвона, ваша задача — следить за:
▪️ таймингом: начали вовремя, закончили тоже;
▪️ планом собрания: обсуждаем то, ради чего собрались, для других проблем и вопросов будет своя встреча.
4️⃣ Подводить резюме созвона
Итог встречи – обязательная составляющая: какие вопросы обсудили, какие решения были приняты, кто ответственный за их реализацию и в какие сроки. В зависимости от обсуждаемой темы, резюме может быть зафиксировано: в общем чате, в базе знаний, в рассылке на корпоративную почту.
5️⃣ Проводить встречи 1+1
Руководителю важно регулярно общаться со своей командой, причем не только в формате «узнать статус»: что сделал, что планируешь, есть ли сложности. Настроение в команде тоже имеет большое значение. Если кто-то из коллег раздражен, расстроен – это будет сказываться на работе.
Задача руководителя – обнаружить проблему и узнать, может ли он помочь. Проблема в сложной задаче? Или конфликт в команде? Подобные кейсы в зоне ответственности лида. Сложнее, когда это какая-то личная проблема. Но и тут руководителю важно проявить участие: показать человеку, что он здесь не ресурс или «винтик», а ценен и к его проблемам неравнодушны.

Как создать правильную атмосферу в команде
В нашем прошлом посте затронули тему настроения в команде. Тут главное соблюсти баланс: не быть просто другом для специалистов, но и не быть просто руководителем 🤔 А как всё это так придумать, чтобы не «скатиться» в ту или иную сторону – спросили у нашего ПМа Даниила 🦸‍♂️


Для команды ПМ, прежде всего, является неким коучем:
▪️ помогает развивать самоорганизацию и чувство ответственности;
▪️ контролирует процесс разработки с точки зрения бизнесовых метрик;
▪️ всеми возможными способами устраняет преграды и препятствия, чтобы специалисты могли вкладываться в работу на 100%.


Как создавать настроение в команде и наладить правильную рабочую, а главное – доверительную, обстановку:
🔹Каждый член команды важен и имеет право высказывать своё предположение, идею, аргумент или контраргумент. Особенно актуально при планировании или продумывании реализации той или иной фичи. В командах мы предлагаем договариваться и обсуждать всё «на берегу».
Бывают такие моменты, когда человек хочет высказать мнение или задать вопрос и переживает, что это мнение неверно. В таком случае я всегда говорю, что лучше уточнять сразу, чем действовать по наитию и сделать неправильно. Именно так каждый член команды понимает, что у него есть голос, его мнение ценно и он будет всегда услышан.
🔹«Быть 24/7 на связи» – и хорошо, и плохо одновременно
Конечно, ПМ сам выбирает путь и планирует загрузку. Я стараюсь придерживаться правила, что нужно проинформировать собеседника, что вы на связи. Если не можете ответить прямо здесь и сейчас, договоритесь о времени. Важно не забывать про риски выгорания, если обсуждение запланировано на нерабочее время.
🔹Разделять понятия «начальник» и «лидер»
Да, ПМ – связующее звено между заказчиком и командой разработки. Лично я разделяю понятия «начальник» и «лидер». Стараюсь выстраивать коммуникацию с командой так, чтобы меня слушали люди не из-за того, что являюсь руководителем, а потому что мои решения взвешены, измерены, логичны, последовательны и аргументированы. Когда человек видит, что собеседник идёт по плану, а его решения оправданы и работают, то он захочет идти с ним плечо к плечу и быть одной командой.
🔹 Обозначать чёткий ориентир для движения вперед
Опыт показывает, каким бы заводным, дружелюбным и софт-скилловым управленцем вы ни были, членам команды будет сложно чувствовать себя комфортно и быть уверенными в завтрашнем дне, если они:
▪️ не знают, что дальше делать,
▪️ не понимают, какой скоуп задач будет на следующей неделе, через неделю и к чему он должен их привести.
Поэтому задача руководителя проекта – дать им чёткое понимание промежуточных и конечных результатов.

​​Как мы SDK для системы платежей обновляли
— Ну что, готово?
— Нет.
— А когда будет?
— Через неделю.
— А можно как-то быстрее? И помнишь, мы еще другую функцию просили запилить, там уже есть какие-то сроки?

Вы Project-manager, к которому через день приходят из разных отделов и вопрошают: «Ну что, готово?».
Понять их можно – чем быстрее пользователи мобильного приложения получат обновления, тем вероятнее компания получит прибыль. Понять можно и команду разработки, потому что 50% задач срочные и важные, а по слову «вжух» релизы не выпускаются.
Как решить? Ускорить выход релизов, например, с помощью мобильного SDK, как сделал наш клиент.

SDK – это набор готовых решений, в котором может содержаться несколько API, фрагменты кода, библиотеки, документацию и другие инструменты. А еще SDK упрощает работу команды и в результате все счастливы:
• разработчик тратит гораздо меньше времени на создание кода;
• маркетинг быстрее получает новые функции и проверяет окупаемость новых гипотез;
• компания меньше тратит на разработку.
У нашего клиента SDK уже был, но ему потребовалось его обновить, в связи с запуском нового бизнес-направления.

Нам предстояло исправить несколько ключевых ошибок, которые влияют на проведение платежей, а также «научить» SDK настраивать вид приложения при подключении новых партнёров. Для этого нужно было разработать новый функционал, обновить цветовую палитру и добавить новые UI-элементы.
Как обычно, не всё так просто, как кажется на первый взгляд – в работе мы столкнулись с несколькими трудностями:
▪️ сильно связанный код текущего SDK, отсутствие единой архитектуры;
▪️ старый стек технологий, отсутствие автоматизации кода;
▪️ 90% кода было написано на Java, что замедляло темпы разработки нового функционала из-за специфики языка;
▪️ отсутствие единого подхода к вёрстке;
▪️ множественное дублирование кода (отсутствие корректной иерархии наследования классов).

О том, как мы всё решили и что в итоге получилось – рассказываем здесь 😏

😱 Потратили на 125 часов больше запланированного,
😱 в 2 раза превысили бюджет,
😱 провалили дедлайны,
😎 проанализировали и внедрили политику по качеству.

Оцените историю про то, как внутренний проект заставил нас пересмотреть подход ко всей работе и сформировать собственную политику по качеству:
▪️ рассказала Служба качества;
▪️ озвучил видеограф Ярослав;
▪️ отрисовала pr-специалист Женя.

4 минуты пользы и эстетического наслаждения 💙

Сможет ли ChatGPT заменить программистов: обзор от экспертов SimbirSoft

Несколько фактов о ChatGPT:
▪️ Обучен на данных из Интернета до 2021 года. Дальнейшие события он уже не учитывает.
▪️ Нет подключения к Интернету, поэтому все задачи он решает с помощью предустановленной базы.
▪️ Можно пользоваться бесплатно, но есть ограничения по количеству запросов в минуту и размеру сообщений. Легко решается с помощью перехода на платный тариф.
▪️ Есть API, который позволяет использовать сервис в приложениях.
▪️ Позиционирование сервиса — большая языковая модель, которая может выполнять функции ассистента.

И с тем, что ChatGPT отличный ассистент, мы полностью согласны. Что он умеет:
☑️ Писать код на разных языках программирования.
☑️ Переводить тексты и алгоритмы с одного языка на другой.
☑️ Добавлять в код unit-тесты.
☑️ Осуществлять автодокументирование кода.
☑️ Проводить code review и исправлять код.
☑️ Оптимизировать алгоритмы и запросы. Сразу оговорка, что это у него не всегда хорошо получается.
☑️ Отвечать на вопросы, в том числе и сложные технические.
☑️ Писать текст и перефразировать его, сочинять стихи и песни. Это не относится к программированию, но может быть хорошим подспорьем для студентов.

С простыми задачами сервис справляется, но если нужно что-то более сложное, то вы столкнетесь с ограничениями:
🔻 Самое основное и критичное, на наш взгляд — иногда ChatGPT пишет правдоподобно звучащие, логически выстроенные, но неправильные или бессмысленные ответы. Это случается, когда нейросеть не находит информацию под запрос.
🔻 Официально недоступен в РФ.
🔻 Есть проблемы с построением текстов на русском языке. Нам говорили, что с английским языком он справляется лучше, но этот момент мы сами не проверяли.
🔻 Не задает уточняющие вопросы, а «угадывает», что имел в виду пользователь.

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

Так что выдыхаем, если программистов и заменит искусственный интеллект, то случится это нескоро 😉

– Что можно сложить из цифр 0,1 и 2?
– Целую историю в 22 года!

22.02.2001 родилась наша компания. А сегодня, в свои 22, мы связываем между собой 50+ городов и 1300+ сотрудников – получаем из этого более тысячи проектов для наших клиентов! В минутном видео мы, конечно, не уместили всё, что хотели, но получилось уместить главное – тепло, с которым мы продолжаем строить нашу компанию и двигаться вперёд. С днём рождения нас, SimbirSoft! 💙

Проектный треугольник: чем полезен и как управлять
Делится знаниями наш PM Дмитрий 😎

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

Чем полезен –
наглядно показывает связь ограничений – если сломать треугольник, качество просочится наружу. Так, нужно всегда помнить, что при изменении одной стороны нужно также изменить одну из оставшихся. Невозможно при сокращении бюджета сделать за первоначальное время планируемое содержание – чем-то придётся пожертвовать. И наоборот.
🖇Один из таких примеров
Разработка мобильного помощника для крупного холдинга. На старте составили проектный треугольник и закрепили все ограничения. В процессе работы заказчик регулярно добавлял новые идеи по дополнительным полезным функциям.
Неопытный проектный менеджер смело брал задачи в работу. Он надеялся, что задачи окажутся небольшими и не повлияют на срок сдачи проекта.
Позже команда поняла, что для реализации всей функциональности — начальной и дополнительной — потребуется больше времени, чем запланировано на старте. Из-за увеличения стороны «Содержание» треугольник разошёлся.
✅ Чтобы не попасть в такую ситуацию, нужно контролировать изменения. Для этого можно использовать реестр изменений — это мастхэв в работе менеджера проектов».

Как управлять
▶️ Фиксировать ограничения после анализа. Проанализировав все требования и пожелания заказчика, нужно составить подробное ТЗ. В нём важно учитывать всё, что может повлиять на проектный треугольник. На этом этапе можно провести предпроектное исследование и проверить гипотезы.
Когда объём работ будет известен, уже возможно зафиксировать ограничения.
▶️ Донести ограничения до заказчика и ЛПР. Лучше это сделать прямо на старте – предупредить, что все дополнительные факторы возможны за счёт пропорционального увеличения всех сторон. Тогда, если это произойдёт, будет легче обсуждать возможные сценарии в сложившихся обстоятельствах.
▶️ Следить за ходом проекта. Дорожная карта поможет вовремя предупредить увеличение одно из стороны.Также для контроля можно использовать burndown chart — диаграмму сгорания задач для гибких методологий. Благодаря ей легче отслеживать движение проекта и делать прогнозы по времени выполнения оставшихся задач.

А узнать больше подробностей и о том, как проектный треугольник работает в Agile и Scrum, можно в статье Дмитрия на Skillbox 📰