Доброго всем времени суток. Настала очередь поговорить о проектировании проектов. По собственному опыту знаю, что иногда сложнее создать проект с нуля, чем привести в порядок то, что уже есть. Во многом это связано с тем, какое наследие Вы или Вам, оставляют после себя. В этой статье постараюсь рассказать на что стоит обратить особое внимание и предложить краткий план следования.
Понимание проекта
Прежде чем что-то планировать, вам необходимо понять какой проект нужно реализовать. Для себя я выделил несколько категорий проектов, таких как:
- Одноразовая поделка — это проект, нацеленный на создание какого-то графического концепта и его дальнейшей продажи инвесторам. Отличительными особенностями данного типа проектов являются:
- Невменяемая документация. Основная идея понятна, но в бизнес-кейсах творится полный хаос, а логических дыр не счесть.
- Сжатые сроки. До 3-х месяцев от написания документации до прототипа.
- Нет планов развития и не планируется дальнейшая поддержка.
- Маленькая команда. Обычно до 5 человек, включая дизайнеров.
- Отсутствие бизнес процессов. Всё взаимодействие сумбурное, основанное на межличностном общении, уточнении принципиальных моментов и/или придумывании на ходу.
- Роли размыты. Нет четкого разграничения полномочий и зон ответственности.
- Нет настоящих данных. Все данные сгенерированы для “красоты” и подогнаны для наилучшего отображения.
- Для ускорения разработки во всю используются внешние зависимости.
- Стартап — это проект, который настроен на реализацию конкретной идеи, с последующим развитием. Обычно, данные проекты развиваются по спиралевидной модели и, по этой причине, имеют почти такие же отличительные особенности, что и первый тип (одноразовая поделка):
- Чёткое разбиение на этапы. Минимально: сроки и перечень функционала, который необходимо в заданный период времени реализовать.
- Относительно вменяемая документация. Проведена аналитика, выставлены ориентиры по этапам сдачи, уточнения зачастую приходят во время спринта. Чаще всего используют waterfall, несмотря на то, что заявлен Agile.
- Средние сроки сдачи основного функционала. В среднем от 6 до 12 месяцев.
- На начальных этапах используют внешние зависимости, которые со временем меняются на собственную реализацию.
- Маленькая команда. Обычно до 7-10 человек.
- Есть разграничение ролей, но ответственность размыта.
- Проект может мутировать. На одном из этапов, возможно, изменится концепция или подход к реализации. Обычно это связано с требованиями инвесторов, изначально провальной идеи или ошибках в архитектуре.
- Условно живые данные. Происходит обкатка на фокус-группах или парсинг живых данных со сторонних ресурсов. Правда так бывает не всегда…
- Информационная система — это проект, реализующий идею с планами по интеграции в сторонние сервисы.
- Есть план развития.
- Четко написанная документация. Минимально: задокументировано описание API.
- Возможно, потребуется проводить интеграцию со сторонними сервисами, ставить “костыли” или перестраивать части системы.
- Есть промежуточные релизы, хот-фиксы.
- Команда средней величины. Обычно от 10 до 20-30 человек.
- Чёткое разделение зон ответственности.
- Требования безопасности: после проведения аналитики созданы кейсы, которые могут привести к краху системы.
- Уделяется время тестированию.
- Используется Agile.
- Почти всегда есть backlog.
- Используются только внешние зависимости, дорогие в реализации собственными силами. Практикуется наравне с проприетарными.
- Замкнутая система — это объемный проект, предназначенный для обслуживания конкретных потребностей Заказчика, с дальнейшей доработкой.
- Конкретный заказчик.
- Есть план развития.
- Проектная документация по разработке. В помощь пользователям написана отдельная документация по требованию Заказчика.
- Разграничение прав пользователей.
- Почти всегда есть backlog.
- Размер команды обычно больше средней. Как правило от 10 человек и до потери пульса.
- Используется Agile. Периодически прилетают дополнительные задачи, которые необходимо реализовать во что бы то ни стало.
- Неожиданные показательные выступления. По требованию вышестоящего руководства происходят показы, поэтому работоспособный тестовый контур никогда не будет лишним.
- Saas решение — это объемный проект с гибкой настройкой и дальнейшей кастомизацией под конкретного заказчика.
- Многомодульная система. Система разбита на несколько частей. Которые можно использования по отдельности, даже за рамками конкретного проекта.
- Чёткое планирование. Минимально: осуществляется оценка трудозатрат на реализацию фич. Закладывается время на модернизацию и рефакторинг.
- Объемная документация. Описано, как правило, почти всё, включая тест-кэйсы.
- Как правило, отсутствуют внешние зависимости и пишутся свои реализации частей системы. Даже если есть сторонние реализации.
- Несколько команд разработки. Каждый отвечает за свою часть разработки будь-то бэк или же фронт.
- Покрытие тестами всего и вся. Применяются авто-, юнит-, регресионое-, интеграционные тесты.
Все градации условны и чаще всего встречаются перетекающие типы. Хочу заметить, что все типы могут мутировать друг в друга, единственный нюанс — в стоимости модернизации. Например, проект изначально был “одноразовая поделка”, а потом эволюционировал в “замкнутая система”. Обычно, подобное приводит к полному или почти полному переписыванию системы или ее рефакторингу. Как вы понимаете, это экономически нецелесообразно. По этой же причине желательно понять какой именно проект вам необходимо создать с нуля, и попытаться определить его дальнейшую судьбу.
Для определения типа проекта, ниже я привел вопросы, получив ответ на которые вам станет понятно, чего от Вас хотят:
- Цель проекта?
- Полный перечень того что надо реализовать?
- Есть ли документация?
- Какие сроки? Желательно точные даты.
- Планируется внешнее взаимодействие со сторонними системами, или будет ли у проекта внешнее API
- Есть ли наработки?
- Размер команды?
- Кто за что отвечает? Кто ставит задачи, кто принимает, кто имеет права вето.
- Есть ли планы на развития и какие они?
- Кто заказчик?
- Есть ли бюджет на покупку готовых решений?
- По какой методологии планируют работать
- Есть ли аналоги?
Как вы видите, перечень не такой уж и большой. Правда, по какой-то неведомой причине, мало кто задаётся подобными вопросами до того, как начать что-либо делать. Вы спросите зачем мне понимать тип проекта?! Всегда надо делать так, чтобы проект жил вечность?! По большому счёту, вы правы, но есть нюансы, как в скабрезном анекдоте. Эти нюансы — ресурсы и сроки. Не стоит забывать, что мы трудимся на благо бизнеса и выполняем поставленные задачи. Когда вам известен тип проекта, вы можете без зазрения совести чем-то пожертвовать для достижения поставленных задач.
Выбор технологий
В выборе лучше придерживаться правила: технология не должна быть суперновой, но и устаревшей тоже. Если технология или фреймворк новые, это может обернуться такими проблемами как:
- Поиск квалифицированных кадров
- Перспективы развития: на ранних стадиях может умереть разработка или, наоборот, если технология старая, то баги придется лечить самим.
- Отсутствие готовых решений для новых, и отсутствие обновлений для старых.
Данный перечень проблем актуален не только относительно технологий, но и к сторонним зависимостям. Всё вышеперечисленное может похоронить проект на корню.
Перед тем как выбрать что-то конкретное, подумайте несколько раз. Составьте пресловутую таблицу преимуществ с коэффициентами важности для проекта.
Данный пример составлен для вымышленного проекта:
| Название функционала проекта. |
Коэффициент важности для проекта |
|---|---|
| Работа с формами |
3 |
| Роутинг |
1 |
| Простота написания анимации |
0,3 |
Как видно из таблицы, важными критериями отбора являются “работа с формами” и “роутинг”. Простота создания анимации для данного проекта не существенна. Далее модернизируем таблицу путем добавления новых столбцов-технологий. В нашем случае их будет два.
| Название функционала проекта. |
Коэффициент важности для проекта |
Технология 1 |
Технология 2 |
|---|---|---|---|
| Работа с формами |
3 |
+ |
± |
| Роутинг |
1 |
+ |
± |
| Простота написания анимации |
0,3 |
+ |
- |
Исходя из данных таблицы, мы понимаем, что у “Технология 2” работа с формами и роутинг хромают, а создание анимации подобно вызову Сатаны. В итоге, удельный вес данной технологии составляет 2. Вы спросите почему 2? Всё просто! Если вы ставите ±, то в данной технологии конкретный функционал реализуем, но с какими-то “костылями”, либо же более трудозатратный. В нашем сравнении выгоднее будет “Технология 1 “, с итогом 4,3. Думаю пояснения по образованию сумм излишни. Данная таблица работает не только с технологиями, но и со всем, что требует сравнения и выбора из списка. Главное — не забывать, что чем больше критериев напишите, тем проще вам будет сделать выбор.
Архитектура
В настоящее время есть возможность выбрать из многообразия различных сервисов, предоставляющих инструменты для проектирования архитектуры. Правда у любого из них есть недостатки, для кого-то критичные, а для кого-то нет. Так как я “oldfag”, то предпочитаю листочек и ручку или доску и маркер.
Для того чтобы понять за что хвататься в первую очередь, вам необходимо обрисовать основные части системы, а затем выбрать способ построения архитектуры. Как правило, на практике используют всего три:
Нисходящий — разработчики отталкиваются от больших узлов системы и идут к более мелким. Смысл архитектуры в том, что первоочередные компоненты — это крупные узлы, содержащие в себе более мелкие.
Восходящий — разработчики отталкиваются от мелких частей и идут к более крупным. Смысл архитектуры в том, что сначала создается много мелких компонентов, а уже из них собираются более крупные.
Монолит — архитектура неделимая на части, зачастую именуемая “legacy”. По факту это жесткая структура, изменение которой, требует решений без “костылей”. Это самый плохой вариант, но, как и всё в нашем мире, имеющий право на существование. Монолит применяют для реализации конкретного функционала и не планируют в дальнейшем его поддерживать. По сравнению с остальными, скорость такого подхода в разы быстрее. Ну просто потому, что можно на многое закрыть глаза.
Выбор вида архитектуры зависит от целей на проекте и скорости разработки. Обычно, первый способ используют, когда сроки не поджимают, а количество крупных модулей малочисленно. Его особенность заключается в том, что можно точно представить связь между конкретными модулями. Из минусов могу отметить долгое время разработки, связанное с последовательностью действий.
Второй способ предпочитают, когда требуется высокая скорость разработки и отсутствует понимание верхнеуровневой архитектуры. Особенностью является множество мелких компонентов, которые порой используются в разных крупных узлах. Стоит отметить, что почти всю разработку можно выполнять параллельно, без оглядки на остальные задачи. Минусами данного подхода будут компоненты, не отвечающие требованиям верхнеуровневой архитектуры и, соответственно, их придется переписывать или же создать возможность кастомизации.
Как показывает практика, все методики разработки сводятся к спиралевидному подходу, характеризующийся постепенным наращиванием функционала. Рассматривать его в рамках этой статьи не считаю целесообразным.
Планирование
Так называемая “Дорожная карта” поможет вам выполнить работу эффективнее. По сути это график, с условными сроками сдачи того или иного функционала. Даты могут переноситься, но, как показывает практика, при грамотном выполнении вышеизложенных пунктов, поправка составит до 30%. На практике это обычно 10-15%. Планирование позволит вам отслеживать прогресс проекта, видеть провисания, вносить коррективы в виде ресурсов или сдвига сроков, и т.д.
За что Вам потом скажут спасибо
Любой проект начинается с документации, и чем её больше, тем лучше! Так что не надо лениться — документируем ВСЁ. Да, это займет время, но впоследствии может спасти Вас от гнева руководства, если что-то пойдет не так, не по Вашей вине. Также не стоит забывать, что после Вас на проекте появятся люди, которым придётся разбираться в том, что вы создали. А без документов сделать это будет не просто.
Выводы
В данной статье описано, как следует действовать и на что обратить внимание при старте проекта. Данные этапы универсальны для фронта, бэка, тестирования или всего вместе. Я нарочно избегал конкретики по технологиям, для того чтобы не вводить в заблуждение.
Когда перед вами встаёт выбор какой использовать стек технологий, архитектуру и необходимо определить временные рамки для реализации проекта, вам может помочь таблица, приведённая ниже:
| Типа проекта / признаки |
Одноразовая поделка |
Стартап |
Информационные системы |
Замкнутые системы |
Saas решения |
Какие-то другие проекты |
|---|---|---|---|---|---|---|
| Кол-во людей до 5 |
X |
X |
X |
X |
||
| Кол-во людей от 7 до 10 |
||||||
| Кол-во людей от 10 до 30 |
X |
|||||
| Кол-во больше 30 |
X |
X |
||||
| Срок сдачи до 3х месяцев |
X |
X |
X |
X |
||
| Срок сдачи от 6 до 12 месяцев |
||||||
| Срок больше 12 месяцев |
X |
|||||
| Документация |
||||||
| Требования интегрирования с другими системами |
||||||
| Конкретный заказчик известен |
||||||
| Планируется дальнейшая поддержка |
||||||
| Планирование |
||||||
| Роли четко разграничены |
||||||
| Разрешено использовать внешние зависимости |
||||||
| Есть живые данные для тестирования и анализа |
||||||
| Требования по безопасности |
||||||
| Требуется тестирование |
||||||
| Требуется написание документации по продукту или инструкция |
||||||
| Требуются модульная реализация |
||||||
| Несколько команд разработки |
||||||
| Всего |
Как пользоваться таблицей, думаю все уже догадались, но на всякий случай — ровно также как и с предыдущей, только с небольшим дополнением в виде закрашенных ячеек. Имеется в виду, что значение не может быть использовано для данного проекта. Также прошу заметить что, таблица может быть неполной, добавьте строки, которые сочтёте необходимыми.