Качество

Что такое качественный софт?

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

В большинстве случаев исполнители заинтересованы в том, чтобы создать качественный продукт и всеми силами стараются сделать это. В то же время оказывается, что по статистике только 30% разработанных систем удовлетворяют заказчика. Фактически, это означает, что большая часть средств, затраченных на разработку оказывается либо выброшена на ветер, либо потрачена недостаточно эффективно. Почему так происходит? Этот вопрос и вопрос, «что есть качество» — по сути один и тот же вопрос.

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

Означает ли качество — удобство использования? То, что называется модным словом «юзабилити»? Безусловно.

Может быть качество — это скорость отклика? Разумеется. Ничто так не раздражает, как работа с вечно тормозящей системой, особенно когда начальство требует немедленного результата, а рабочий день уже заканчивается.

Отсутствие ошибок? Несомненно. Никому не понравится, когда система делает не то, что от нее ожидаешь. А можно ли доверять ей финансовые операции, если она постоянно «глючит»? Мы бы не стали.

Безопасность? Конечно! Кому понравится, если хакер сунет свой нос вашу личную информацию или, например, в финансовые отчеты вашей организации.

Качественная система — это живая система. В ней реализованы идеи, которые отражают жизненные реалии. Она живет и развивается вместе с окружающим миром. Что, если сегодня система устраивает, а завтра — либо что-нибудь изменилось в окружающем мире, в вашем бизнесе, либо изменились ваши представления об этом мире. Хочется изменить систему в соответствии с этими изменениями? Сложно это сделать или нет? Сколько времени это займет? Все это — тоже вопросы качества.

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

Как достичь качества?

Как строить красивые удобные для жизни дома? Как строить качественные системы?

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

Знания и опыт

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

Коммуникация с вами

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

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

Итеративность

Мы (пока) не пишем системы управления полетами. В остальных системах можно использовать итеративный подход. После первой версии, после того, как с системой удается «поиграть», ваше представление о том, что вам нужно, изменится. Это происходит всегда, поверьте нашему опыту. Не исключено — изменится радикально. Мы стараемся разбить проект таким образом, чтобы в первую версию вошли только абсолютно необходимые характеристики, или «фичи», только ключевые сценарии, обрезать все лишнее. Если это — ваш первый проект, согласиться с таким подходом вам будет нелегко. Инстинктивно вам захочется включить все, по максимуму. Однако чем больше первая версия, тем больше придется менять в дальнейшем, тем больше средств выброшено на ветер. Чем компактнее первая версия, тем быстрее можно добиться осязаемого результата, тем выше качество.

Test Driven Development

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