Вредные советы о том, как добиться качества IT-продукта

Как команде IT-разработчиков уложиться в срок и бюджет – рассказываем в старом добром жанре вредных советов. В нашей подборке – 6 рискованных, однако распространенных ситуаций, которые выявляет и устраняет Служба качества SimbirSoft. Мы реализовали уже более 900 проектов для разных отраслей, как с нуля, так и подключаясь к командам заказчиков, и стремимся анализировать риски на ранних этапах работы. Делимся опытом, о котором мы ранее рассказали на нашей конференции «Технореволюция 2.0».

Внимание! Не пытайтесь повторить описанные кейсы – это опасно для здоровья вашего проекта!

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

Заказчику не понравился результат? Он – не эксперт и не знает, как должно быть правильно!

На практике:

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

На старте проекта нужно обратить внимание на детали, которые в дальнейшем могут отразиться на результате:

Старт проекта – это очень легко, взял ТЗ и делай! Вы уверены, что у вас в команде «сеньористые» сеньоры с кучей опыта! Команда профессионалов всегда сама во всем разберется, а если нет, то не судьба, найдем других заказчиков.

На практике:

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

Даже команда, состоящая из экспертов, нуждается в поддержке. Развитие проекта во многом зависит от того, насколько эффективно команде удастся поставить его на “рельсы” на старте.

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

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

Продуманная архитектура? Требования по нагрузке? Об этом подумаем потом. Нужно скорее делать!

На практике:

Если вы знаете, ЧТО должна делать система, уже на старте нужно определить, КАК она это будет делать. Неопределенность в этом вопросе зачастую приводит к тому, что исправлять продукт в дальнейшем мучительно больно.

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

О том, хорошо ли мы работаем, успеваем ли в сроки и в бюджет, мы узнаем в конце. Чего раньше времени переживать? Проект не нуждается в частом снятии метрик – это все бесполезная работа. Метрики ни на что не влияют. Главное, что в результате мы получим продукт, а уж как мы его разрабатывали – неважно.

На практике:

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

Так, для себя мы разработали дашборд «Здоровье проекта», который позволяет отслеживать общее состояние и значения целевых метрик: прогнозируемый и реальный план/факт, багофикс, эффективное время работы команды и т.д. Если метрика отклоняется от целевых показателей, то это позволяет нам оперативно среагировать и скорректировать ситуацию.

Мы собираем обратную связь от клиентов, которая тоже является метрикой. Проводим опросы среди специалистов, а также внутренний аудит проектов – Project Review. Например, анализируем причины, которые влияют на time-to-market: недочеты в планировании, несоответствие ожиданиям, наличие дефектов кода и прочее.

Эти инструменты в большей степени направлены на выявление проблем, которые мешают эффективной работе команды, и их устранение.

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

На практике:

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

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

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

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

На практике:

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

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

Как показывает практика, обмениваться опытом, содействовать специалистам в сертификации – один из действенных способов для наращивания экспертизы всей команды. Помимо профессиональных знаний, важны хобби и неформальное общение. Так, у нас уже более 40 клубов по интересам, большинство из которых так или иначе связаны с разработкой – «LevelUp», «Группа 51», «Инновационный центр», архитектурный комитет, клуб тимлидов, менторов и другие.

В этой статье мы перечислили вредные советы, которые могут привести к серьезным проблемам на проекте. В основу рекомендаций лег наш многолетний опыт работы с более чем 700 клиентами. В завершение мы решили обобщить наши рекомендации и сформулировали несколько полезных советов «Как не загубить проект»: