Подход

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

Есть Идея!

Хорошие проекты начинаются с хороших идей. Однако этого не достаточно, чтобы начать разработку. Почему недостаточно? Предположим, вы хотите построить дом и приходите в строительную компанию. Если задача сформулирована в виде идеи: «Постройте мне дом», результат, скорее всего, будет неудовлетворительным. Построенный дом может не подойти по размеру (слишком маленький для большой семьи) или каким-то другим функциональным признакам, наконец, он просто может не нравиться (вы хотели такой, как у соседа, а получили непонятно что).

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

Разработчики ПО являются такими же строителями — сфера деятельности иная, но проблемы те же самые. Согласно статистике, наиболее распространенной причиной неудавшихся проектов является неудовлетворенность заказчика конечным результатом, расхождение между тем, что хотели, и тем, что получили. В нашем случае в роли архитектора выступает аналитик, который по результатам нескольких встреч или телефонных разговоров может составить концепцию вашей будущей системы. Мы называем этот документ Vision. Он содержит только то, что нужно на данном этапе: основную задачу системы (главные сценарии), описание предметной области, приблизительные рамки проекта.

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

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

Есть Чертеж!

Хорошее техническое задание вполне можно сравнить с детальным чертежом здания. Имея чертежи, строители не задумываются о форме здания, размерах или используемых материалах. Им не нужно думать о том, выдержит ли конструкция, что будет со зданием через 10 лет, продуманы ли в нем системы пожаротушения и вентиляции. Все эти вопросы решаются архитекторами, конструкторами и инженерами на этапе проектирования и передаются конечным исполнителям в форме четких инструкций.

Некоторые клиенты приходят к нам, имея готовое техническое задание (мы еще называем этот документ требования). Это может быть, например, ТЗ, сделанное на заказ, или результат работы собственных аналитиков.

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

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

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

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

Есть Система!

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

Другое дело, когда система начинает эксплуатироваться в боевом режиме. Если речь, например, идет об успешном публичном проекте, то это означает следующее:

— Постоянный прирост числа посетителей

— Бесперебойная работа в режиме 24х7х365

— Увеличение нагрузки на серверное оборудование и каналы передачи данных

— Постоянное увеличение объема данных пользователей

— Необходимость защиты данных пользователей от потери в результате поломки оборудования или действий хакеров

— Постоянное развитие системы, добавление новых функций и улучшение существующих

— Мониторинг состояния системы и оборудования, с целью предупреждения потенциальных сбоев и проблем

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

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

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