190 проектов каждый день: как не потерять качество при разработке ПО

Всем привет! На связи Сергей Гордеев, руководитель проектного офиса ИТ-компании SimbirSoft. За 20+ лет разработки софта мы выросли из команды в четыре человека до компании с полутора тысячами специалистов в штате. В нашем портфолио уже более 1200 реализованных проектов. Мы создаем и кастомизируем информационные системы для решения бизнес-задач клиентов из разных отраслей, в том числе делаем высоконагруженные системы с использованием Machine Learning и Data Science. Компания стабильно развивается во многом потому, что мы быстро адаптируемся под меняющиеся рыночные условия, у нас сильный менеджмент и выстроенные процессы.

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

Итак, что же нам помогает обеспечивать качественную работу над несколькими сотнями проектов, расскажу далее.

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

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

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

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

Быть в контакте. Мы часто взаимодействуем с клиентом, обсуждаем видение и детали, чтобы в конечном итоге достигнуть нужного результата, и всегда остаемся на связи.

Фиксировать ответственность. На старте проекта составляем матрицу ответственности — фиксируем задачи и ожидания заказчика, распределяем роли и обязанности. Если в процессе что-то идет не так — проводим ретроспективу, даем всем участникам высказаться и вносим корректировки по результатам обратной связи.

Фиксировать точки контроля. Заранее согласовываем с заказчиком план созвонов, на которых демонстрируем промежуточные результаты по проекту.

Быть предсказуемыми. Все процессы на проекте прозрачны для клиента — он знает, что сейчас происходит и сколько времени будет длиться каждый этап. Это координирует руководитель проекта.

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

Также у нас есть база знаний по технологиям. У SimbirSoft, естественно, есть свои наработки — удачные технические решения, которые мы стараемся переиспользовать, если такая возможность есть. Это позволяет снизить трудозатраты на реализацию проекта, а значит, и сэкономить деньги клиента. Условно: специалист мог бы потратить неделю на продумывание архитектуры, а вместо этого использует наработки и делает всё за день.

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

Чтобы максимально попасть в ожидания заказчика, мы:

• Соблюдаем процесс разработки и постоянно его совершенствуем. Четкое следование стандартам и практикам, выработанным за 22 года проектной деятельности, позволяет добиваться предсказуемых результатов;
• Уделяем большое внимание аналитике. Чем лучше она проработана, тем ниже неопределенность, меньше багов и несоответствий между конечным решением и видением клиента;
• Обеспечиваем качество. На обеспечение качества наших проектов работает целый комплекс процессов компании: заранее определенный workflow, выстроенные процессы тестирования и т. п.

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

На этапе аналитики крайне важно понять реальные бизнес-цели заказчика, снизить функциональную и техническую неопределенность на проекте. Чтобы провести этот значимый этап качественно, мы привлекаем всех необходимых специалистов: аналитика, руководителя проекта, тимлида и QA-лида. После согласования артефактов (технического задания, прототипов, архитектурной концепции и прочего) со стороны заказчика команда приступает к этапу разработки.

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

Как бы качественно и хорошо мы ни делали с самого начала — ошибки неизбежны. Бывают ситуации, когда у заказчика есть определенные ожидания, но где-то происходят разночтения. Во время работы могут открыться неожиданные детали, которых мы не учитывали ранее, но они влияют на ход и результаты проекта.

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

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

При таком подходе и двести проектов одновременно — не предел!

Если у вас есть свои правила, как вести много проектов одновременно, — поделитесь в комментариях!