ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Чек-лист (часть курса "Технологии для продакта") помогает быстро и примерно оценить технические аспекты создания системы:
- сделай копию и заполни для своего кейса: по каждому критерию поставь оценку от 0 до 3 и обоснуй почему
- итоговая оценка - всего лишь среднее по категориям приведенное к числу от 0 до 1, она не так важна
- внизу сформулируй итоговый комментарий и выдели особенности проекта - это как раз важно, так как позволит тебе вести качественную дискуссию о времени разработки с тех. лидом
- после заполнения шаблона для нескольких кейсов (как в курсе), у тебя выработается понимание "простых" и "сложных" кейсов
2
ГруппаКритерийПочемуПример оценкиКомментарий по критерию для моего проектаОценка по моему проекту
(от 0 до 3)
3
Оценка бизнес-
логики		Изученность доменаДля изученных продуктов есть много открытых знаний. Для новых доменов придется разбираться во всем самому.0: очень хорошо изучен (одностраничники)
1: хорошо изучен (e-commerce)
2: cредне изучен (стриминг)
3: слабо изучен (распознавание видео)		3
4
Количество логических операций и бизнес-процессовБольше логики означает больше кода, медленный time-to-market, больше maintenance, больше потенциальных ошибок и т. д.0: очередной одностраничный сайтик
1: районный сервис аренды велосипедов (инвентарь, бронирование)
2: сервис продажи авиабилетов (+ оплата, обновление цен)
3: система управления аэропортом		1
5
Количество поддерживаемых классов продуктовКаждый новый класс продуктов имеет потенциал дублировать бизнес-процессы.0: нет продуктов
1: доставка только пиццы только на машине
2: доставка пиццы, ювелирки на машине
3: доставка пиццы, ювелирки и пианино на велике/машине/самолете		1
6
Оценка архитектурыЧисло backend-сервисов и frontend-овКоличество сервисов/элементов фронта является хорошим прокси для сложности системы, поскольку им придется взаимодействовать друг с другом.0: нет бэка вообще
1: 1-5 сервисов без систем хранения, только сайт
2: 5+ сервисов, системы хранения и несколько интеграций, сайт/iOS
3: 30+ сервисов, сложные системы хранения, много интеграций, сайт/iOS/Android/Huawei		1
7
Состояние архитектуры
(tech debt)		Если фундамент сломан, то будет трудно на нем надстраивать.0: ничего нет, или все гибко и расширяемо
1: повозиться придется, но в целом все расширяемо
2: у нас уже монолит и новые изменения внедрить сложно
3: нужно все перестраивать и мигрировать		0
8
Требования к будущему архитектурыЧем большие планы на будущее, тем более тщательным надо подойти к архитектуре.0: Проверка гипотезы, и так сойдет
1: Никаких больших планов, но сделаем хорошо на всякий случай
2: В будушем будем расширяться вертикально (трафик)
3: В будущем будем расширяться как вертикально, так и горизонтально (команды, продукты)		1
9
Оценка технологийИнновационность выбранных командой технологийМенее известные (но, возможно, хайповые) технические решения приносят больше сюрпризов в будущем.0: известные технологии (языки программирования, frontend/backend, фреймворки, платформы)
1: некоторые технологии новые
2: многие технологии еще не обкатаны
3: все выбранные технологии новые для индустрии		0
10
Опыт команды в выбранных технологияхОпыт команды разработчиков в конкретных технологиях сильно влияет на скорость и качество деливери.0: команда опытных профессионалов
1: большинство профессионалы или в большинстве технологий есть опыт
2: большинство новички или во многих технологиях нет опыта
3: команда джунов или учить большинство технологий заново		3
11
Насколько уже автоматизирована инфраструктураКод должен «жить» где -то, и это «где -то» кто-то должен поддерживать. Если это твоя команда, то вычитай 20% от скорости разработки.0: есть специальные инфра-команды, которые заведуют всех техникой
1: команд нет, но все в настроенном облаке
2: свои сервера и инфраструктурой занимается команда
3: надо разбираться с нуля с серверами/облаком или уже куча костылей, ручной работы		1
12
Оценка клиентской стороныКоличество клиентовКоличество клиентов является хорошим прокси сложности системы из-за повседневного maintenance и новых требований.0: 1-10 B2C
1: 1-2 B2B или 100+ B2C
2: 3-10 B2B или 10000+ B2C
3: 10-100+ B2B и/или 100000+ B2C		2
13
Требовательность клиентов/ строгость SLOsЧем более высокие SLO, тем больше усилий надо инвестировать в производительность/устойчивость системы.0: Низкие SLO: сервис обработки аналитики с сайта (потеряли и ладно)
1: Средние SLO: сервис показа бонусов (не показали - не смертельно)
2: Высокие SLO: сервис покупки билетов (не купил - потеря прибыли)
3: Очень высокие SLO: сервис автопилота самолета (не сработал - упал)		1
14
Объем трафикаСуществует разница между запуском системы под нагрузкой 10 запросов в день и 100000 запросов в секунду.0: 1-2 запроса в минуту/час
1: 10-100 запроса в минуту/час
2: 100-1000 запросов в секунду
3: 1000+ запросов в секунду		2
15
Оценка зависимостейЧисло зависимостейКоличество зависимостей является хорошим прокси сложности системы из -за поддержания интеграций и сценариев, которые могут пойти не так.0: Автономный: одностраничный сайт фотографа
1: С 1-2 зависимостями: фотосток, интегрированный с одним API платежки
2: С 3-10: фотосток, интегрированный с платежкой, печатью/доставки альбома, распознаванием объектов
3: С 10+: большой магазин, интегрированный с тем же, плюс картами, fraud check, и тд.		3
16
Критичность зависимостейЗависимости, как правило, являются внешними компаниями, вне контроля команды. Но они при этом влияют на производительность продукта.0: зависимости вообще не влияют на конечный продукт (виджет погоды на сайте)
1: зависимости нужны для продукта (гео-сервис на сайте аренды машины)
2: зависимости критичны для critical path (с сервисом платежей для покупки билета)
3: зависимости критичны и опираются от людей (саппорт)		1
17
Сложность интеграции с зависимостямиСколько времени тратится на интеграцию новых и обслуживание существующих зависимостей.0: их нет вообще или что-то очень простое (вставить виджет рекламы на сайт)
1: хорошая документация, test-environment, поддержка, обещанные SLOs
2: средняя документация, как-то помогают с тестами и саппортом
3: нет доков, тестирование только в продакшне, нет зафиксированных SLOs		1
18
Оценка безопасности/legalКритичность защиты данныхХорошая защита данных требует разработки систем доступа, шифрования, резервных хранилищ и так далее.0: Низкая: сервис погодных данных, все открыто
1: Средняя: сервис гео-карт, данные о том, где я был
2: Высокая: мессенджер Telegram, данные переписок
3: Очень высокая: сервис автопилота Tesla		0
19
Fraud appetite
(интерес мошенников)		Высокие риски мошенничества для продукта требуют разработки detection algorithm, алтернативных воронок, внутренних проверок и тд.0: Никакой: сервис погоды, нечего красть
1: Низкий: Маленький магазин: можно украсть аккаунт, но толку от этого немного
2: Средний: сервис билетов в кино, можно продать, но низкий ценник
3: Высокий: сервис миль авиакомпаний, можно анонимно продать за хорошие деньги		0
20
Требования legalВысокие юридические ограничения увеличивают сложность системы и количество обязательных интеграций.0: Никакие (сервис погоды)
1: Non-sensitive область (магазин книг)
2: Есть сложные моменты (например, customer privacy)
3: Высокие: регулирумая область (финансы, медицина)		1
21
22
ИтогИтоговый комментарий/особенностиПример: "Средний по сложности сервис в слабо изученно домене, командой новичков, большим числом зависимостей и высоким трафиком.0.4Финальная оценка - всего лишь индикатор сложности от 0 (если все пункты оценки были 0) до 1 (если все пункты были 3). Главное в упражнении не эта цифра, а комментарии по каждому пункту, которые станут основой стратегии / PRD.
23
24