С чего начать проектирование
большой и сложной системы

Расскажу историю из далекого прошлого, когда писали в универе программки на Паскале, СИ, и каких-то неведомых ныне языках.

Зеленые бойцы придумывали кучу фич, с умным видом колбасили несколько экранов кода, радостно нажимали на кнопку «Компилировать» и… программа, конечно, не работала. Несчастные погружались в бесконечный процесс тестирования, который не всегда заканчивался успешно. Если программу таки удавалось запустить, то лучше было на нее не дышать и как можно быстрее сдать, пока ничего опять не сломалось (желательно не давая преподавателю нажимать на лишние кнопки).

Более опытные товарищи начинали с небольшого core-функционала и тестов. Выделяли логические куски в небольшие процедуры (да, раньше были процедуры), отлаживали их отдельно, собирали в библиотеки и строили логику основной программы уже на них. Получалось понятно, четко, прозрачно и быстро. Самое главное, что можно было добавлять фичи, менять поведение программы не опасаясь, что где-то что-то отвалится.

К чему это я? А к тому, что недавно мне задали вопрос – как продумать большую систему (веб-сервис) у которого должно быть много функционала, сложная навигация, куча контента… типа AirBnb или Pinterest. С чего начать и как все учесть чтобы ничего потом не переделывать. Так вот:

– Никак!

Вариант «один раз все придумать и потом ничего не переделывать» – не вариант. Для учебной задачки это еще приемлемо, но для боевого проекта – утопия.

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

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

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

Определяем самое главное (частое, важное, ценное) действие, которое пользователи должны делать и от чего они должны получать пользу. Фокусируемся на нем. Их может быть 2, ну максимум 3, если нашли больше – значит что-то можно отбросить. Например, для соцсетей это – потребление нового и нового контента, для банковского приложения – просмотр баланса и перевод между своими счетами, для музыкального приложения – запуск/остановка трека. Задача – сделать эту часть идеально, за остальное пользователи простят.

Выделяем основные понятия предметной области, которыми будем оперировать – объекты, без которых невозможно решить задачу. Например для соцсети это будет: пользователь, страница, пост, комментарий; для бухгалтерского приложения – документ, проводка… Важно не вдаваться в мелочи, сфокусироваться на крупных действительно ключевых объектах. Такие вещи, как количество лайков или уведомления – уже производные, о них не надо пока думать. Постройте в голове (а лучше на бумаге) высокоуровневую систему понятий и задача сразу станет проще.

Изучаем конкурентов и заимствуем удачные решения. В 99% случаев то, что вы пытаетесь сделать – кто-то уже сделал. Все это открыто и доступно, всем этим можно пользоваться. Если мучает совесть – не переживайте, вам ответят взаимностью :) Часто бывает так, что нужное решение можно подглядеть даже не у конкурентов, а в совершенно другой области. Делаете приложение по вызову такси – посмотрите на сервисы доставки еды или агрегаторы авиабилетов.

Обсуждаем, показываем, тестируем. Делаем как можно более ранние прототипы core-функционала и пытаемся их «продать» своей команде, ребятам из соседнего офиса, текущим и/или потенциальным клиентам… слушаем, внимаем, вносим изменения.

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

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

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