Колонки

Как вывести ИТ-продукт на рынок. Часть 3: Проверка на прочность (архитектура, компетенции, качество)

Колонки
Илья Фейгин
Илья Фейгин

основатель и технический директор WaveAccess

Дарья Мызникова

Представляем заключительную часть пошагового руководства, которое поможет разобраться, почему проекты по разработке проваливаются. Списки для самопроверки основаны на более чем 20-летнем опыте WaveAccess по созданию ИТ-проектов.

В первой части мы разбирались с MVP и инфраструктурой проекта. Во второй части — в интеграции ИТ-систем. А сейчас пришло время проверить проект на прочность.

Основатель и технический директор компании Илья Фейгин рассказывает об архитектуре программного обеспечения и тех вызовах, к которым она должна быть готова. Он объясняет, как определить уровень полезности членов проектной команды, и делится планом по контролю качества проекта — тестированию.

Как вывести ИТ-продукт на рынок. Часть 3: Проверка на прочность (архитектура, компетенции, качество)

Выбор архитектурного решения: компетенции архитектора 

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

Мы собрали список пунктов, которые помогут вам удостовериться, все ли необходимое с точки зрения архитектуры ПО предусмотрено, нет ли ошибок с выбором решений. 

Важно проверить:

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

Проверка компетенций: как оценить разработчиков

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

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

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

  • Каждый разработчик может рассказать, над каким участком проекта он работает. 
  • Разработчик знает, как протестировать разработанную им функциональность (и в рамках системы, и отдельно от всех ее частей). 
  • Разработчик понимает возможные технологические недостатки в коде тех модулей, с которыми ему пришлось работать. Узнайте, есть ли у него предложения по устранению этих недостатков.
  • Разработчик предусмотрел алгоритм действий в случае неудачного выполнения задачи. 
  • Разработчик хорошо знаком с технологиями, которые используются в той части системы, с которой он работает. 
  • Разработчик способен написать тест для проверки функциональности, над которой работает.
  • Разработчик может адаптировать код других разработчиков так, чтобы этот код можно было протестировать. 
  • Разработчик знает уровень нагрузки на часть системы, над которой работает, включая требуемую скорость обработки, объем данных, частоту запросов.  
  • Разработчик может провести профилирование своего кода и понимает, как его оптимизировать при необходимости.  
  • В особенности с разработчиками баз данных: они понимают не только, как писать запросы, но и как эти запросы будут выполняться, какие индексы будут использоваться и будут ли, как профилировать запросы и что нужно делать, если запросы работают медленно. 

Команда тестирования: проверка качества ПО

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

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

В этом чек-листе мы собрали пункты для проверки и основные идеи, которые важны для успешного тестирования продукта. Убедитесь, что: 

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

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


Фото на обложке: Shutterstock/Aksonsat Uanthoeng

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Как вывести ИТ-продукт на рынок, несмотря ни на что. Часть 2: Полезные связи
  2. 2 Эта методология поможет вам быстро и качественно разрабатывать IT-продукты. Как она работает?
  3. 3 8 вопросов, которые нужно себе задать перед разработкой приложения
RB в Telegram
Больше полезного контента в Telegram
Подписывайтесь!