Настольная книга тимлида разработки ПО

Проектирование функций (на базе бизнес-процессов)

Функциональные требования к продукту: являются частью описания бизнес-процессов или раскрывают подробности выполнения различных бизнес-процессов. Например, классический интернет-магазин автоматизирует бизнес-процесс коммуникации организации с покупателем, при этом:

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

— Корзина и оформление покупки — автоматизируют формирование и прием заказа от покупателей. Раньше заказы принимали по телефону или с помощью почтовых отправлений. Карточки заказов шли в бумажных каталогах на последних страницах, чтобы можно было отправить письмом несколько заказов.

— Контакты, О компании… — информирование покупателей об условиях сделки, продавце и т. д.

Процессы могут иметь разные формы при одной и той же цели.

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

Продукты могут автоматизировать деятельность клиентов или взаимоотношения с клиентами. При таком раскладе функции продукта проверяются бизнес-гипотезами. Эффективность бизнес-гипотез необходимо подтверждать увеличением вовлеченности, уровнем продаж и др. Другой случай — продукты, которые автоматизируют внутреннюю деятельность предприятий. Они как раз не нуждаются в доказательстве эффективности тех или иных своих функций. Их деятельность уже осуществляется в неавтоматизированном виде, что делает обратную связь от внедрения достаточно быстрой.

Тимлид, как любой другой разработчик, может и должен подсказывать владельцу продукта наиболее оптимальные пути развития. Также в его полномочия входит извлечение данных знаний из всей команды. Это позволит использовать полезные UI элементы и улучшить UX.

Описание функций

В главе «Качество постановки задач» рассматривались различные методы формализации задач. Выбор метода должен быть основан на необходимости более точной (качественной) реализации задач и ориентированы на описание функций продукта.

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

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

— Постоянно держите в фокусе основную цель продукта и основной бизнес-процесс зарабатывания денег.

— Определите охват продукта и его пользователей.

— Функции продукта должны отвечать потребностям пользователей, а также помогать им более эффективно и качественно выполнять свою роль в бизнес-процессе.

— Проектирование их должно обеспечивать удобство и простоту пользования без чтения документации.

— Система понятно и предсказуемо реагирует на действия пользователей.

— Приятное эстетическое ощущение от интерфейса продукта.

— Обработка ошибок системы, дающая понимание того, что произошло и не требующая от пользователей дополнительных действий.

Архитектура приложений

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

Архитектуру информационной системы можно представить в виде слоев:

— Технологический

— Инфраструктура

— Платформа

— Информационный

— Приложение

— Данные

— Бизнес

— Сервисы

— Процессы

— Компетенции

— Ценности

Архитектура — это набор принятых и реализованных решений в отношении элементов (каждого слоя) и их взаимодействия.

Этап первичного проектирования архитектуры часто сопровождается созданием документации — диаграмм и схем. Для этих целей используются UML диаграммы, эта нотация практически не имеет достойной альтернативы на текущий момент.

Проектирование приложения сводится к вопросам:

— Как систематизировать и логически разделить программный код (функциональный, по типу объектов, по слоям объектов, по фичам)

— Уровень отделения логических блоков (монолит, сервисная архитектура)

— Платформа (serverless, на одном сервере, на разных физических серверах, в контейнерах, на виртуальных машинах)

Выбор технологий

Основными критериями при выборе программного языка, фреймворка и инфраструктуры будут:

— Наличие компетенции в технологии

— Способность технологии решить поставленную задачу

— Эффективность решения данной задачи на заданной технологии (стоимость, скорость, расширяемость)

— Доступность компетентных ресурсов в организации в нужный момент времени

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

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

Архитектурный контроль

Принятые архитектурные решения необходимо реализовать в продукте. Контроль корректности реализации архитектуры продукта — одна из важнейших функций тимлида. Процесс контроля встраивается в процесс ревью кода. В рамках ревью проверяется: соответствие архитектурному видению внесенных изменений в коде, необходимость изменить архитектуру, оправданность этих действий.

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

Аудит архитектуры необходимо проводить в случае, если нет жесткого контроля всех вносимых изменений в продукт. Таким образом в продукте:

— могут появиться изменения, нарушающие его архитектурную целостность

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

Технический долг

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

Управление техническим долгом — это его постоянный поиск, подсчёт стоимости и постепенное устранение.

Что будет если не выплачивать технический долг?

— Будет расти время разработки и стоимость поддержки системы.

— Усложняется анализ кода, требуется много времени, чтобы разобраться в нём.

— Тяжелее вносить изменения — системы с техническим долгом отличаются хрупкостью.

— В какой-то момент станет невозможной дальнейшая поддержка системы.

— Её придётся выводить из использования или переписывать с нуля.

Почему копится технический долг?

— Программист делает ошибки при разработке проекта, которые не отлавливаются на code review или статическом анализе;

— Когда ситуация вынуждает писать код быстро и некачественно, к нему в будущем не возвращаются для рефакторинга;

— Объем технического долга не известен руководству;

— В команде не выделяется время на периодическое исправление технического долга;

— Разработчики игнорируют мелкие дефекты качества и не пытаются их исправить на месте по правилу бойскаута.

Как выявить технический долг?

— Контроль качества внешним аудитом

— Code Review

— Автоматизация оценки качества кода

Поддерживаемость и отказоустойчивость

Документация — инструмент улучшения поддерживаемости продукта за счет сохранения знаний о продукте, его строении и процессе разработки. Правильно организованная передача знаний позволит уменьшить риски при низком bus факторе. Стоимость создания и поддержки документации достаточно высокая, поэтому начинать работать с ней нужно с ответа на вопросы:

— Кто потребитель документации?

— Какой информации будет достаточно (наиболее важная)?

— Какой вид документа будет максимально удобным для потребителя?

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

Распределение ответственности за код ведет к снижению поддерживаемости кода. Для больших продуктов вам придется искать компромисс между разделением области кода среди разработчиков и фокусировкой их деятельности в отдельной области.

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

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

Хорошей практикой является измерение уровня сложности кода и «запаха» кода статическими анализаторами.

Отказоустойчивость решения достигается за счет:

— Проверки выпускаемых версий (unit тестами, приемочными и интеграционными тестами, пентестами и статическим анализом кода на безопасность)

— Построение отказоустойчивой схемы инфраструктуры

— Уменьшение человеческого фактора в процессе публикации релизов

Обеспечение высокой доступности также включает:

— Резервное копирование

— План восстановления (максимально автоматизированный)

— Дублирование компонентов, масштабируемую архитектуру и кэширование

— Защита от вторжений (brute force, XSS, ransomware, SQL injection, DDoS и др.)

— Дотирование

— Метрики и алерты

Производительность

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

На основании прогнозов бизнеса планируются задачи по обеспечению производительности. Повышение производительности достигается за счет применения теории ограничений. Тестирование таких задач должно подтверждаться успешным нагрузочным тестом. При этом хорошим тоном считается способность системы выдержать х2-х5 нагрузки от плановых значений.

Необходимо встроить процесс обеспечения производительности в процесс разработки таким образом, чтобы изменения не приводили к деградации производительности продукта. Для этого на ревью оценивается производительность тех или иных алгоритмов, а тестировщик проверяет новую пропускную способность измененного участка.

Есть ситуации, когда построить план по нагрузке физически невозможно, при этом нагрузка может скакать в диапазоне х10. В этих ситуациях бизнесу придется прибегнуть к дополнительным расходам, чтобы обеспечить доступность системы с использованием serverless архитектуры.

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

Безопасность

Основные принципы проектирования и реализации безопасных систем:

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

— Целостность — свойство сохранения правильности и полноты активов.

— Доступность — свойство информации быть доступной и готовой к использованию по запросу авторизованного субъекта, имеющего на это право.

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

Требования безопасности необходимо выявить до начала работы над продуктом.

Основные шаги выстраивания безопасности:

— Сбор и выявление всех требований к безопасности (фактически реализации шагов ниже)

— Требования к технологиям передачи, обработки и хранения информации

— Выявление видов информации

— Выявление ролей пользователей (для приложения и инфраструктуры)

— Определение прав для каждой роли (операции чтения, удаления, обработки и изменения каждого типа информации)

— Определение способа идентификации пользователя (в том числе в момент перебора паролей и DDoS-атак)

— Правила согласования выдачи доступов и процесс выдачи доступов

— Политика паролей

— Регламенты информационной безопасности (профилактика, инциденты безопасности)

— Журналирование важных для безопасности событий

— Управление рисками безопасности (оценка угроз)

— Использование средств активной защиты от атак

Более того, требования могут быть наложены на сам процесс разработки: внесение изменений в код продукта, публикация новой версии продукта, использование последних версий библиотек и поддерживающих приложений.

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