Эд Кевбрин
CEO в Eggs Community
И искусствоведы пишут ПО
Что продуктолог должен знать о разработке ПО помимо того, что всем делом заведует тимлид? Посмотрим под капот разработки на
примере eggsdigital.ru
примере eggsdigital.ru
Время чтения: 9 мин
Разработка как искусство
В стартап студии мы занимаемся запуском продуктов по своей методологии: 90% времени используем No-code и прочие относительно простые инструменты. Но допустим сейчас, что мы проверили MVP и решаем делать очередную платформу, что дальше? Дальше начинается разработка. И в этой статье мне интересно рассмотреть этот процесс с точки зрения продуктолога не-разработчика. Поэтому здесь не будет кода, а будут ответы на вопросы - какие инструменты полезно знать продуктологу, если он хочет чтобы его продукт был воплощен в жизнь так, как он себе представляет. Все рассуждения, конечно, взяты из практики, а именно я рассмотрю это один таск по сбору МАК адресов посетителей медицинских центров из платформы eggsdigital.ru.
По образованию я искусствовед, а не разработчик. В этом есть и плюсы и минусы. Самый главный плюс - это способность мыслить абстракциями (привет, абстрактное искусство!). Анализ разработки ПО сродни анализу произведений искусства - ты смотришь на всю картину, затем углубляешься
в детали, изучаешь их взаимосвязи, и, в конечном счете, все раскладываешь по полочкам. Для себя я даже накидал таблицу с 7 шагами, где каждому этапу анализа картины я могу привести аналогичный этап разработки ПО (таблица прокручивается):
По образованию я искусствовед, а не разработчик. В этом есть и плюсы и минусы. Самый главный плюс - это способность мыслить абстракциями (привет, абстрактное искусство!). Анализ разработки ПО сродни анализу произведений искусства - ты смотришь на всю картину, затем углубляешься
в детали, изучаешь их взаимосвязи, и, в конечном счете, все раскладываешь по полочкам. Для себя я даже накидал таблицу с 7 шагами, где каждому этапу анализа картины я могу привести аналогичный этап разработки ПО (таблица прокручивается):
Давайте шаг за шагом пройдем по всем пунктам разработки и разберем их на практике.
Должен ли все это знать продуктолог?
Не обязательно. Это обязательно должен знать тимлид. А продуктологу крайне полезно для своей "шкуры" понимать
его логику мышления
Не обязательно. Это обязательно должен знать тимлид. А продуктологу крайне полезно для своей "шкуры" понимать
его логику мышления
Определяем функции сервиса
Этот шаг продуктолог делает вместе с тимлидом.
NB!
Начнем со 2 шага таблицы (ибо если вы это читаете, то, как минимум
в голове, у вас уже есть "карта движения клиента", а также понимание
что ему нужно, соответственно шаг 1 можно пропустить). В качестве "подопытного кролика" возьмем сервис в eggsdigital.ru - составление портрета целевой аудитории для рекламодателя. Мы решили пойти по короткому пути и использовать для этого обезличенные MAC адреса посетителей клиник, собираемые Wi-Fi радарами. Механика следующая: роутер в радиусе 40-50 Db ловит эхо запросы встроенных в телефон роутеров, группирует их и передает на сервер. Сам скрипт мы опустим, рассмотрим работу облачного бэкенда. Вот так выглядит формализованный набор функций на DRAKON-диаграмме (смотрим сверху-вниз, в овалах начало и конец задачи, в квадратах названия функций, в ромбах условия ветвления, а в спич-бабблах мои пояснения):
в голове, у вас уже есть "карта движения клиента", а также понимание
что ему нужно, соответственно шаг 1 можно пропустить). В качестве "подопытного кролика" возьмем сервис в eggsdigital.ru - составление портрета целевой аудитории для рекламодателя. Мы решили пойти по короткому пути и использовать для этого обезличенные MAC адреса посетителей клиник, собираемые Wi-Fi радарами. Механика следующая: роутер в радиусе 40-50 Db ловит эхо запросы встроенных в телефон роутеров, группирует их и передает на сервер. Сам скрипт мы опустим, рассмотрим работу облачного бэкенда. Вот так выглядит формализованный набор функций на DRAKON-диаграмме (смотрим сверху-вниз, в овалах начало и конец задачи, в квадратах названия функций, в ромбах условия ветвления, а в спич-бабблах мои пояснения):
Это относительно простой сервис, тем не менее, он содержит 7 основных задач того, что должно делать ПО и 2 условия разветвления Да/Нет. Есть над чем поразмыслить уже тут. Пойдем дальше и разнесем "работу" ПО по времени.
Выстраиваем функции по времени
Этот шаг делает тимлид в одиночестве.
NB!
На шаге 3 мы выстраиваем функции последовательно друг за другом (именно так они выполняются вне зависимости от того, как происходит их развертывание). Тут смотрим слева-направо. Слева - клиенты, справа - укрупненные сущности бэкенда (ну вот, еще одно полезное слово - "сущность", фактически это просто объединение компонентов). В данном случае под клиентами понимаются Wi-Fi радары и партнерский сервис myTarget, который принимает от нас данные и помогает составить портрет целевой аудитории. Клиенты на диаграмме всегда слева, бэкенд - всегда справа, временная шкала сверху-вниз. Синий прямоугольник клиента - это его время взаимодействия с сервисом. Временные циклы есть также у каждой части бэкенда. Начало работы - верх прямоугольника, конец - низ. Стрелочка обычная - запрос. Функций, которые используют сущности, здесь уже 4. Смотрим UML диаграмму последовательностей:
Принципы наше все
Тут много сложных терминов - раздел можно пропустить.
NB!
Перед тем, как переходить к описанию шага 4, я хочу упомянуть про фундамент разработки ПО - принципы. Вся логика работы с функциями,
компонентами и сущностями (в нормальных условиях) должна подчиняться пяти принципам SOLID, которые расшифровываются следующим образом:
Первая буква S, сокращение от SRP (Single Responsibility Principle).
По-русски "Принцип единственной ответственности". Означает: что у
каждого компонента ПО должна быть только одна причина для изменений (например, компонент содержит функции для бухгалтеров и изменяется ТОЛЬКО по их требованиям).
Вторая буква О, сокращение от OCP (Open-Closed Principle).
По-русски "Принцип открытости/закрытости". Означает: что система должна быть настолько простой, чтобы можно было быстро добавить
новый код БЕЗ изменения старого.
Третья буква L, сокращение от LSP (Liskov Substitutional Principle).
По-русски "Принцип подстановки Барбары Лисков". Означает: что если вы делаете бэкенд на Python, не надо дописывать отдельные компоненты на Java - функции должны быть взаимозаменяемы.
Четвертая буква I, сокращение от ISP (interface Segregation Principle).
По-русски "Принцип разделения интерфейсов". Означает: необходимо создавать для каждого компонента свой интерфейс и не смешивать интерфейсы в одну кучу (на диаграмме ниже это db_interface.py).
Пятая буква D, сокращение от DIP (Dependency Inversion Principle).
По-русски "Принцип инверсии зависимости". Означает: что код с основными функциями бизнес-логики (main.py) не должен НИКОГДА содержать ссылок на код, реализующий менее важные функции.
Должен ли все что выше знать продуктолог? Не обязательно. Это обязательно должен знать тимлид. Но продуктологу было бы крайне полезно понимать его логику принятия решений, т.к. это значительно повлияет на скорость разработки, багфиксов и новых апдейтов в будущем. Чем меньше тимлид знает про SOLID - тем более недовольны будут
клиенты - эту зависимость точно знать полезно.
компонентами и сущностями (в нормальных условиях) должна подчиняться пяти принципам SOLID, которые расшифровываются следующим образом:
Первая буква S, сокращение от SRP (Single Responsibility Principle).
По-русски "Принцип единственной ответственности". Означает: что у
каждого компонента ПО должна быть только одна причина для изменений (например, компонент содержит функции для бухгалтеров и изменяется ТОЛЬКО по их требованиям).
Вторая буква О, сокращение от OCP (Open-Closed Principle).
По-русски "Принцип открытости/закрытости". Означает: что система должна быть настолько простой, чтобы можно было быстро добавить
новый код БЕЗ изменения старого.
Третья буква L, сокращение от LSP (Liskov Substitutional Principle).
По-русски "Принцип подстановки Барбары Лисков". Означает: что если вы делаете бэкенд на Python, не надо дописывать отдельные компоненты на Java - функции должны быть взаимозаменяемы.
Четвертая буква I, сокращение от ISP (interface Segregation Principle).
По-русски "Принцип разделения интерфейсов". Означает: необходимо создавать для каждого компонента свой интерфейс и не смешивать интерфейсы в одну кучу (на диаграмме ниже это db_interface.py).
Пятая буква D, сокращение от DIP (Dependency Inversion Principle).
По-русски "Принцип инверсии зависимости". Означает: что код с основными функциями бизнес-логики (main.py) не должен НИКОГДА содержать ссылок на код, реализующий менее важные функции.
Должен ли все что выше знать продуктолог? Не обязательно. Это обязательно должен знать тимлид. Но продуктологу было бы крайне полезно понимать его логику принятия решений, т.к. это значительно повлияет на скорость разработки, багфиксов и новых апдейтов в будущем. Чем меньше тимлид знает про SOLID - тем более недовольны будут
клиенты - эту зависимость точно знать полезно.
Наводим порядок
Этот шаг делает тимлид в одиночестве.
NB!
На этом шаге мы посмотрим как лучше развернуть наши функции на виртуальной машине в облаке. Каждая функция упаковывается в минимальную единицу для развертывания - компонент. Один компонент может содержать любое количество функций, главное чтобы они по своим компоновке не противоречили принципам SOLID. Компоненты выстраиваются в структуру, между ними появляются две связи:
- Поток управления - определяет порядок передачи управления в процессе исполнения кода от главных к второстепенным компонентам. Начало потока управления - место, откуда начинается взаимодействия пользователя с системой. Зачастую это пользовательский интерфейс (GUI) или любой другой файл (типа main в языках C).
- Поток наследования - определяет порядок наследования модулей в системе. Наследование в объектно-ориентированном программировании позволяет в одном компоненте использовать классы, функции, методы из другого модуля, просто "наследуя" их. Так, например, можно просто скачать сторонний модуль и наследовать оттуда функцию и самому ничего писать не придется. Красота.
Компонент - это минимальная единица развертывания ПО
Ниже диаграмма компонентов с функциями (один компонент - это один отдельный файл) и двумя стрелочками - потоком управления (черная стрелочка) и потоком наследования (стрелочка с белым треугольником):
В данном случае, черная стрелка, направленная от app.py в сторону db_interface.py означает, что первый компонент содержит в себе информацию о db_interface.py, а последний ничего не знает о первом.
Т.е. фактически, db_interface.py не зависит от app.py и может развертываться (и разрабатываться) независимо от него. Чтобы соблюсти принципы SOLID мы разбили компоненты на три блока, о которых говорили на шаге 1: базы данных (db_gateway.py), фронтенд (app.py) и бэкенд (query.py, main.py), а также добавили отдельный интерфейс для преодоление границ между блоком бэкенда и базой данных. Если внимательно посмотреть на диаграмму, то можно заметить, что самый нестабильный, зависимый и "грязный" компонент - это timer.py. Из него выходят три зависимые связи (т.е. он содержит ссылки на функции из трех компонентов), он же запускает поток выполнения всех функций (в данном случае выполняет задачу пользовательского интерфейса). Как я писал выше - пользовательский интерфейс - это всегда самый «грязный» компонент в разработке и должен изменяться так часто, как этого требует пользователь или кастдев, а значит от него вообще не должны зависеть другие компоненты и уже тем более те, которые могут повлиять на доходы компании.
Т.е. фактически, db_interface.py не зависит от app.py и может развертываться (и разрабатываться) независимо от него. Чтобы соблюсти принципы SOLID мы разбили компоненты на три блока, о которых говорили на шаге 1: базы данных (db_gateway.py), фронтенд (app.py) и бэкенд (query.py, main.py), а также добавили отдельный интерфейс для преодоление границ между блоком бэкенда и базой данных. Если внимательно посмотреть на диаграмму, то можно заметить, что самый нестабильный, зависимый и "грязный" компонент - это timer.py. Из него выходят три зависимые связи (т.е. он содержит ссылки на функции из трех компонентов), он же запускает поток выполнения всех функций (в данном случае выполняет задачу пользовательского интерфейса). Как я писал выше - пользовательский интерфейс - это всегда самый «грязный» компонент в разработке и должен изменяться так часто, как этого требует пользователь или кастдев, а значит от него вообще не должны зависеть другие компоненты и уже тем более те, которые могут повлиять на доходы компании.
Если до шага номер 7 продуктолог или тимлид сделали свою работу плохо, то никакая "гибкая" или "не гибкая"
разработка вам не поможет
разработка вам не поможет
Пару слов про Agile
Этот шаг продуктолог делает вместе с тимлидом.
NB!
Закончить можно было бы уже на предыдущем пункте - больше продуктологу ничего не надо знать про разработку (писать код все же будут разработчики). Но в завершении я бы хотел сказать пару слов про самое популярное слово на собеседовании продуктологов в нашу студию. Я, конечно, про магический Agile (это шаг 7 анализа картины - разработки в нашей таблице).
Окей, Google, как выглядит Agile на практике? Давайте представим такую картину. За столом собирается команда. В ней 6 человек. Пришел тим лид, пару очень опытных разработчиков (Senior) бэкенда, один начинающий (Junior) фронтендщик, тестировщик (QA engineer) и devops-администратор. Продуктолог расчехлил свой PowerPoint и начинает рассказывать о новом замечательном продукте. Говорит про клиента, его путь, а также о функциях, которые нужно сделать (о «кил фичах», естественно). Потом он спрашивает команду насколько сложна та или инфа функция в реализации. Участники переглядываются и опускают руки под стол и в нужный момент каждый показывает на пальцах число от 1 до 5. Среднее число на руках разработчиков - это средняя сложность разработки функции, или «истории» в терминах «гибкой» разработки. Все истории собираются в один дашборд, а дальше команда выбирает какую историю в каком порядке делать. В зависимости от скорости работы команды, раз в неделю или реже выбирается очередная «история» и реализуется. Постепенно становится понятна скорость работы команды по сделанным в GIT коммитах. Отсюда вытекает и конечная скорость разработки, которая влияет на бюджет проекта.
Вот и вся магия. Если до шага номер 7 продуктолог или тимлид сделали свою работу плохо, то никакая "гибкая" разработка вас не спасет.
Методология разработки ПО - это не панацея от всех проблем, а лишь способ облегчить создание кода, но и она должна базироваться на
прочном фундаменте - принципах и диаграммах.
Окей, Google, как выглядит Agile на практике? Давайте представим такую картину. За столом собирается команда. В ней 6 человек. Пришел тим лид, пару очень опытных разработчиков (Senior) бэкенда, один начинающий (Junior) фронтендщик, тестировщик (QA engineer) и devops-администратор. Продуктолог расчехлил свой PowerPoint и начинает рассказывать о новом замечательном продукте. Говорит про клиента, его путь, а также о функциях, которые нужно сделать (о «кил фичах», естественно). Потом он спрашивает команду насколько сложна та или инфа функция в реализации. Участники переглядываются и опускают руки под стол и в нужный момент каждый показывает на пальцах число от 1 до 5. Среднее число на руках разработчиков - это средняя сложность разработки функции, или «истории» в терминах «гибкой» разработки. Все истории собираются в один дашборд, а дальше команда выбирает какую историю в каком порядке делать. В зависимости от скорости работы команды, раз в неделю или реже выбирается очередная «история» и реализуется. Постепенно становится понятна скорость работы команды по сделанным в GIT коммитах. Отсюда вытекает и конечная скорость разработки, которая влияет на бюджет проекта.
Вот и вся магия. Если до шага номер 7 продуктолог или тимлид сделали свою работу плохо, то никакая "гибкая" разработка вас не спасет.
Методология разработки ПО - это не панацея от всех проблем, а лишь способ облегчить создание кода, но и она должна базироваться на
прочном фундаменте - принципах и диаграммах.
И все же - могут ли искусствоведы разобраться в создании ПО или это дело разработчиков-математиков? Я думаю - могут. Если вы тоже, как и я - гуманитарий, то это не повод отчаиваться. Это повод открыть книжку по Python или JS, сесть и внимательно почитать. А визуальное мышление гуманитария окажет вам значительную помощь в обучении.
Интересно сотрудничество? Есть вопросы? Контакты ниже
Удобно по электропочте
Удобно по электропочте