├── .piglet-meta.json ├── principles ├── project-cartoon.png ├── manifest.md ├── primary-analysis.md ├── legacy-diagram.svg ├── crosservice-development.md ├── task-definition-checklist.md ├── _assets │ └── puml-e65c8ca997e7.svg ├── tech-debt.md └── problem-formulation.md ├── process ├── incidents │ ├── attachments │ │ └── incident_lifecycle_diagram.excalidraw.png │ ├── incident_manager.md │ ├── lsr.md │ ├── postmortem.md │ └── definition.md ├── techlead │ ├── projects-complexity-overview.md │ ├── techlead-skillset.md │ ├── techlead.md │ └── techlead-workbook.md ├── design-review │ ├── definition.md │ ├── template.md │ └── hint.md ├── teamlead.md └── squad_health_check │ ├── squad_health_check_external.md │ └── shc_how_to_external.md ├── LICENSE ├── yfm-build-manifest.json ├── AUTHORS ├── README.md ├── CONTRIBUTING ├── toc.yaml ├── education └── books.md └── .mapping.json /.piglet-meta.json: -------------------------------------------------------------------------------- 1 | { 2 | "project":"verticals-tech-playbook", 3 | "repository":"arcadia" 4 | } -------------------------------------------------------------------------------- /principles/project-cartoon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/YandexClassifieds/playbook/HEAD/principles/project-cartoon.png -------------------------------------------------------------------------------- /process/incidents/attachments/incident_lifecycle_diagram.excalidraw.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/YandexClassifieds/playbook/HEAD/process/incidents/attachments/incident_lifecycle_diagram.excalidraw.png -------------------------------------------------------------------------------- /process/techlead/projects-complexity-overview.md: -------------------------------------------------------------------------------- 1 | # Что такое «проект»? 2 | 3 | В нескольких наших процессах (проектное техлидерство, дизайн-ревью, ...) фигурирует понятие «проект». Здесь определена минимальная граница того, что считается проектом. 4 | 5 | {% note info "Проект — это ..." %} 6 | 7 | Продуктовая или техническая задача, соответствующая одному из критериев: 8 | - Создание нового сервиса; 9 | - Интеграция двух и более поддоменов; 10 | - Вовлечение бо́льшей части профессий продуктовой команды; 11 | - Изменение ключевой функциональности business-critical сервиса; 12 | - Ожидаемая разработка более человеко-месяца. 13 | 14 | {% endnote %} 15 | 16 | Определение сложности проекта по относительно формальным критериям дает возможность оценить примерный срок реализации за счет наличия сроков реализации схожих по сложности проектов, а так же выбрать подходящего по уровню компетенций техлида. 17 | -------------------------------------------------------------------------------- /process/design-review/definition.md: -------------------------------------------------------------------------------- 1 | # Дизайн ревью 2 | 3 | 4 | ## Зачем 5 | Для того чтобы: 6 | * Расширить кругозор 7 | * Предотвратить разработку плохо спроектированных проектов 8 | * Предотвратить разработку дублирующих велосипедов 9 | * Оставить артефакт с описанием архитектуры проекта, чтобы в будущем хотя бы было описание какую проблему решали 10 | 11 | ## Когда требуется дизайн-ревью 12 | Когда есть соответствие определению проекта. 13 | 14 | {% note info "Проект — это ..." %} 15 | 16 | Продуктовая или техническая задача, соответствующая одному из критериев: 17 | - Создание нового сервиса; 18 | - Интеграция двух и более поддоменов; 19 | - Вовлечение бо́льшей части профессий продуктовой команды; 20 | - Изменение ключевой функциональности business-critical сервиса; 21 | - Ожидаемая разработка более человеко-месяца. 22 | 23 | {% endnote %} 24 | 25 | 26 | 27 | ## Как оформить дизайн-док 28 | 29 | 30 | * [Шаблон дизайн-документа](template.md) 31 | * [Подсказки и рекомендации](hint.md) 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2024 YANDEX LLC 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in 13 | all copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 21 | THE SOFTWARE. 22 | -------------------------------------------------------------------------------- /yfm-build-manifest.json: -------------------------------------------------------------------------------- 1 | {"redirects":{},"fileTrie":{"trie":{"index":{"file":{"ext":".md","toc":"t0"}},"process":{"children":{"design-review":{"children":{"definition":{"file":{"ext":".md","toc":"t0"}},"template":{"file":{"ext":".md","toc":"t0"}},"hint":{"file":{"ext":".md","toc":"t0"}}}},"incidents":{"children":{"definition":{"file":{"ext":".md","toc":"t0"}},"postmortem":{"file":{"ext":".md","toc":"t0"}},"lsr":{"file":{"ext":".md","toc":"t0"}},"incident_manager":{"file":{"ext":".md","toc":"t0"}}}},"teamlead":{"file":{"ext":".md","toc":"t0"}},"techlead":{"children":{"techlead":{"file":{"ext":".md","toc":"t0"}},"techlead-workbook":{"file":{"ext":".md","toc":"t0"}},"techlead-skillset":{"file":{"ext":".md","toc":"t0"}},"projects-complexity-overview":{"file":{"ext":".md","toc":"t0"}}}},"squad_health_check":{"children":{"squad_health_check_external":{"file":{"ext":".md","toc":"t0"}},"shc_how_to_external":{"file":{"ext":".md","toc":"t0"}}}}}},"principles":{"children":{"manifest":{"file":{"ext":".md","toc":"t0"}},"primary-analysis":{"file":{"ext":".md","toc":"t0"}},"problem-formulation":{"file":{"ext":".md","toc":"t0"}},"crosservice-development":{"file":{"ext":".md","toc":"t0"}},"task-definition-checklist":{"file":{"ext":".md","toc":"t0"}},"tech-debt":{"file":{"ext":".md","toc":"t0"}}}},"education":{"children":{"books":{"file":{"ext":".md","toc":"t0"}}}}},"tocMapping":{"t0":"toc.yaml"}},"yfmConfig":{}} -------------------------------------------------------------------------------- /AUTHORS: -------------------------------------------------------------------------------- 1 | The following authors have created the source code of "playbook" 2 | published and distributed by YANDEX LLC as the owner: 3 | 4 | Mikhail Chugunkov poslegm@yandex-team.ru 5 | Aleksei Androsov aandrosov@yandex-team.ru 6 | Igor Biryulin ibiryulin@yandex-team.ru 7 | Andrei Ovcharov a-a-ovcharov@yandex-team.ru 8 | Alexander Mityakov krustnic@yandex-team.ru 9 | Valeryi Varankin swapster@yandex-team.ru 10 | Roman Kosarev rs-pluss@yandex-team.ru 11 | Ilya Makarov caulfield@yandex-team.ru 12 | Alexander Konygin alexkonygin@yandex-team.ru 13 | Sergei Novikov sernovikov@yandex-team.ru 14 | Evgeniy Veretennikov vere10@yandex-team.ru 15 | Dmitry Andreev kemmko@yandex-team.ru 16 | Vadim Kokhtev vkokhtev@yandex-team.ru 17 | Maxim Sazonov maxim-sazonov@yandex-team.ru 18 | Nikolay Mukin mukin-nikolay@yandex-team.ru 19 | Roman Vishnevsky r-vishnevsky@yandex-team.ru 20 | Nikita Gorlin nagorlin@yandex-team.ru 21 | Mikhail Grigorev mi-a-grigorev@yandex-team.ru 22 | Dmitry Polienko polienkodv@yandex-team.ru 23 | Yury Kurzhumov kurzhumov@yandex-team.ru 24 | Egor Zonov ezzer@yandex-team.ru 25 | Filipp Vagner filippvagner@yandex-team.ru 26 | Georgy Besedin fresk@yandex-team.ru 27 | Maxim Balushkin maxbalushkin@yandex-team.ru 28 | Anton Bulychev abulychev@yandex-team.ru 29 | Leonid Fedotov fedleonid@yandex-team.ru 30 | Evgeniy Belov datichto@yandex-team.ru 31 | Lev Orekhov lorekhov@yandex-team.ru 32 | Svyatoslav Demidov svyatoslav@yandex-team.ru 33 | -------------------------------------------------------------------------------- /process/incidents/incident_manager.md: -------------------------------------------------------------------------------- 1 | # Заведующий инцидентами (Incident Manager) 2 | 3 | Заведующий инцидентами — это почётная роль, которую выполняют люди, обладающие широким знанием системы и команд. Задача таких людей — снижать ущерб от инцидентов для бизнеса и пользователей. Соответственно, их деятельность оценивается по тенденции инцидентов в зоне ответственности: снижается ли ущерб от них или растёт. 4 | 5 | 6 | 7 | ## Обязанности 8 | 9 | - Внедрение и адаптация фреймворка по управлению инцидентами; 10 | - Координация дежурных при авариях первого класса. Обычно самые «горячие» инциденты происходят на стыке нескольких команд и дежурным сложно локализовать настоящую причину аварии. В таком случае дежурный может обращаться к заведующему, чтобы тот посмотрел на ситуацию с высоты птичьего полёта и организовал работу дежурных; 11 | - Обучение сотрудников правилам поведения при инциденте. Куда смотреть, как регистрировать, где лежат подсказки, как писать пост-мортем, как проводить разбор. Заведующий выступает смесью ментора и консультанта, готовя людей к авариям на дежурствах. И чем лучше заведующий обучает, тем меньше стресса у дежурных в реальных условиях; 12 | - Контроль за тем, что каждый инцидент в должной мере проанализирован и разобран, причины устраняются, а не отложены в долгий ящик; 13 | - Помогает сотрудникам писать пост-мортемы и проводить разборы, пока они не научились делать это сами. 14 | - Оценивает финансовый ущерб. 15 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Разработка Яндекс.Вертикалей 2 | 3 | Добро пожаловать на домашнюю страницу разработчика Яндекс.Вертикалей! 4 | 5 | Здесь мы стараемся собрать всё, что может помочь в работе. Миссия этой документации — стать настольной книгой программиста, первоочередным местом, к которому разработчики будут обращаться в поиске ответов на рабочие вопросы. 6 | 7 | ## Содержание 8 | 9 | * Процессы и роли 10 | * Дизайн-ревью 11 | * [Регламент](process/design-review/definition.md) 12 | * [Шаблон дизайн-документа](process/design-review/template.md) 13 | * [Рекомендации](process/design-review/hint.md) 14 | * Управление инцидентами 15 | * [Регламент](process/incidents/definition.md) 16 | * [Post-Mortem](process/incidents/postmortem.md) 17 | * [Разбор](process/incidents/lsr.md) 18 | * [Заведующий инцидентами](process/incidents/incident_manager.md) 19 | * [Тимлид](process/teamlead.md) 20 | * Техлид проекта 21 | * [Кто это такой и зачем он нам](process/techlead/techlead.md) 22 | * [Настольная книга техлида](process/techlead/techlead-workbook.md) 23 | * [Знания и навыки техлида](process/techlead/techlead-skillset.md) 24 | * Описание сложности проектов 25 | * [Что такое «проект»?](process/techlead/projects-complexity-overview.md) 26 | * Squad health check external 27 | * [Squad health check](process/squad_health_check/squad_health_check_external.md) 28 | * [Как проводить](process/squad_health_check/shc_how_to_external.md) 29 | * Принципы разработки 30 | * [Общие Принципы](principles/manifest.md) 31 | * [Первичный анализ задач](principles/primary-analysis.md) 32 | * [Формулировка проблем (НЖЯ)](principles/problem-formulation.md) 33 | * [Принципы кросс-сервисной разработки](principles/crosservice-development.md) 34 | * [Ставим задачи правильно](principles/task-definition-checklist.md) 35 | * [Управление техдолгом](principles/tech-debt.md) 36 | * Саморазвитие 37 | * [Образовательные материалы](education/books.md) 38 | -------------------------------------------------------------------------------- /CONTRIBUTING: -------------------------------------------------------------------------------- 1 | # Notice to external contributors 2 | 3 | 4 | ## General info 5 | 6 | Hello! In order for us (YANDEX LLC) to accept patches and other contributions from you, you will have to adopt our Yandex Contributor License Agreement (the “**CLA**”). The current version of the CLA can be found here: 7 | 1) https://yandex.ru/legal/cla/?lang=en (in English) and 8 | 2) https://yandex.ru/legal/cla/?lang=ru (in Russian). 9 | 10 | By adopting the CLA, you state the following: 11 | 12 | * You obviously wish and are willingly licensing your contributions to us for our open source projects under the terms of the CLA, 13 | * You have read the terms and conditions of the CLA and agree with them in full, 14 | * You are legally able to provide and license your contributions as stated, 15 | * We may use your contributions for our open source projects and for any other our project too, 16 | * We rely on your assurances concerning the rights of third parties in relation to your contributions. 17 | 18 | If you agree with these principles, please read and adopt our CLA. By providing us your contributions, you hereby declare that you have already read and adopt our CLA, and we may freely merge your contributions with our corresponding open source project and use it in further in accordance with terms and conditions of the CLA. 19 | 20 | ## Provide contributions 21 | 22 | If you have already adopted terms and conditions of the CLA, you are able to provide your contributions. When you submit your pull request, please add the following information into it: 23 | 24 | ``` 25 | I hereby agree to the terms of the CLA available at: [link]. 26 | ``` 27 | 28 | Replace the bracketed text as follows: 29 | * [link] is the link to the current version of the CLA: https://yandex.ru/legal/cla/?lang=en (in English) or https://yandex.ru/legal/cla/?lang=ru (in Russian). 30 | 31 | It is enough to provide us such notification once. 32 | 33 | ## Other questions 34 | 35 | If you have any questions, please mail us at opensource-support@yandex-team.ru. 36 | -------------------------------------------------------------------------------- /process/teamlead.md: -------------------------------------------------------------------------------- 1 | # Руководитель группы разработки 2 | Заметка предназначается для тех, кто: 3 | 1. Подумывает стать тимлидом, но слабо представляет, что придётся делать; 4 | 2. Только стал тимлидом, но не понимает, в какую сторону работать; 5 | 3. Опытных тимлидов, взращивающих себе преемника. 6 | 7 | Эти направления сформулированы из самых важных метрик, на которые мы смотрим при оценке эффективности работы руководителя. Как именно достигать высокой эффективности по каждому направлению — творческая задача, зависящая от специфики конкретной команды. 8 | 9 | - **Результаты команды**. Команда даёт обоснованные оценки сроков выполнения проектов и попадает в них с надлежащим качеством. Руководитель непрерывно работает над повышением производительности команды и помогает определить оптимальное соотношение качество/скорость благодаря своему пониманию потребностей бизнеса. Руководитель контролирует, что деятельность команды неминуемо приводит к благоприятному для пользователей и бизнеса результату. 10 | - **Работа с людьми**. Команда хорошо замотивирована, процессы ориентированы на людей внутри команды. Руководитель помогает сотрудникам в их профессиональном развитии и раскрытии потенциала. Руководитель понимает текущее состояние сотрудников и их будущие планы. Руководитель ведёт индивидуальную работу с высокопотенциальными сотрудниками для ускорения их роста и с «отстающими» для устранения проблем с производительностью. 11 | - **Стратегия команды**. Руководитель понимает цели команды, запрос стейкхолдеров, бизнес-контекст и может сформулировать стратегию её развития на ближайший квартал. Понимает технические тренды в организации и планирует техническое развитие в зоне ответственности команды. Исходя из этих целей эффективно управляет ресурсами, непрерывно оценивает соответствие состава и состояния команды её целям. 12 | - **Коммуникация**. Руководитель управляет ожиданиями смежников. Смежникам понятны сроки и приоритеты проектов, при этом руководитель добивается такой же прозрачности и от самих смежников по влияющим на его команду вопросам. Руководитель может координировать кросс-командные проекты, распространяет удачные практики за пределы команды. 13 | 14 | ### Ссылки 15 | 16 | 17 | - [Teamlead Roadmap](https://tlroadmap.io/) 18 | -------------------------------------------------------------------------------- /toc.yaml: -------------------------------------------------------------------------------- 1 | title: Classifieds Tech Playbook 2 | items: 3 | - name: Домашняя страница 4 | href: index.md 5 | - name: Процессы и роли 6 | items: 7 | - name: Дизайн-ревью 8 | items: 9 | - name: Регламент 10 | href: process/design-review/definition.md 11 | - name: Шаблон дизайн-документа 12 | href: process/design-review/template.md 13 | - name: Рекомендации 14 | href: process/design-review/hint.md 15 | - name: Управление инцидентами 16 | items: 17 | - name: Регламент 18 | href: process/incidents/definition.md 19 | - name: Post-Mortem 20 | href: process/incidents/postmortem.md 21 | - name: Разбор 22 | href: process/incidents/lsr.md 23 | - name: Заведующий инцидентами 24 | href: process/incidents/incident_manager.md 25 | - name: Тимлид 26 | href: process/teamlead.md 27 | - name: Техлид проекта 28 | items: 29 | - name: Кто это такой и зачем он нам 30 | href: process/techlead/techlead.md 31 | - name: Настольная книга техлида 32 | href: process/techlead/techlead-workbook.md 33 | - name: Знания и навыки техлида 34 | href: process/techlead/techlead-skillset.md 35 | - name: Описание сложности проектов 36 | items: 37 | - name: Что такое «проект»? 38 | href: process/techlead/projects-complexity-overview.md 39 | - name: Squad health check external 40 | items: 41 | - name: Squad health check 42 | href: process/squad_health_check/squad_health_check_external.md 43 | - name: Как проводить 44 | href: process/squad_health_check/shc_how_to_external.md 45 | - name: Принципы разработки 46 | items: 47 | - name: Общие Принципы 48 | href: principles/manifest.md 49 | - name: Первичный анализ задач 50 | href: principles/primary-analysis.md 51 | - name: Формулировка проблем (НЖЯ) 52 | href: principles/problem-formulation.md 53 | - name: Принципы кросс-сервисной разработки 54 | href: principles/crosservice-development.md 55 | - name: Ставим задачи правильно 56 | href: principles/task-definition-checklist.md 57 | - name: Управление техдолгом 58 | href: principles/tech-debt.md 59 | - name: Саморазвитие 60 | items: 61 | - name: Образовательные материалы 62 | href: education/books.md 63 | path: toc.yaml 64 | -------------------------------------------------------------------------------- /process/incidents/lsr.md: -------------------------------------------------------------------------------- 1 | # Разбор инцидента (LSR) 2 | 3 | Целью разбора является получение списка задач, которые приведут к: 4 | 1. Устранению причины; 5 | 2. Повышению скорости реагирования; 6 | 3. Повышению скорости устранения; 7 | 4. Любые другие меры, снижающие вред для пользователей и бизнеса (blast radius). 8 | 9 | Разбор можно провести письменно, если причины инцидента и пути исправления понятны, или очно, если инцидент сложный или просто интересный :) Для инцидентов второго класса не рекомендуется злоупотреблять очными разборами, чтобы не утомлять команду. В идеале, если разбор проведёт сам дежурный, сразу же написав в тикет с инцидентом список задач для устранения причин. Так что Incident Manager организует разборы для команды до тех пор, пока команда не научится делать их самостоятельно. 10 | 11 | Золотые правила проведения разбора: 12 | 1. Не выяснять личные отношения, а сконцентрироваться на конструктивной работе. Ведущий должен оперативно пресекать попытки участников перейти на личности. Когда слышно «а я ж вам говорил …», «Петя, как обычно, не заметил …», «до сих пор вы не можете …» и тому подобное — надо прервать разговор и объяснить, что участники здесь собрались не для этого; 13 | 2. Разбор проводится только после того, как готов Post-Mortem. Считается, что все участники его прочитали, и не надо тратить время на рассказ о хронологии инцидента или влиянии на бизнес: максимум за минуту дать краткий пересказ, чтобы настроить участников; 14 | 3. Ведущий на протяжении всего разбора концентрируется сам и концентрирует остальных участников на цели мероприятия: формирование плана работ, который приведёт к **устранению причин, повышению скорости реагирования, повышению скорости устранения, любому другому снижению вреда для пользователей и бизнеса**. Не надо давать участникам разбора уходить в абстрактные или не относящиеся к делу рассуждения. Разбор — это целенаправленная работа, а не место для общения «обо всём». 15 | 4. Задачи, фиксирующиеся после разбора, должны быть конечные и реалистичные: никаких «улучшить ...», «повысить ...» и тому подобного. Если не получается сформулировать конкретную задачу, лучше так и написать в резюме разбора, а не пытаться добавить в план пункт просто чтобы он там был. 16 | 5. Если разбор инцидента не укладывается в полчаса, у вас или очень сложный инцидент или проблемы с фасилитацией. 17 | 6. Внимание акцентировать на проблемах бизнеса: «как 5хх повлияли на пользователей?». Надо не закрыть техническую дыру, а обеспечить стабильную работу сервиса для тех, кто его использует. 18 | 19 | После того, как разбор проведён, его резюме со списком задач надо оставить в комментарий к тикету с инцидентом. Тикеты с причинами лучше сделать подзадачами к инциденту. 20 | -------------------------------------------------------------------------------- /education/books.md: -------------------------------------------------------------------------------- 1 | # Обучающие материалы для разработчиков 2 | Те книги, которые могут быть релевантны для разработчиков в Вертикалях. Совсем узкоспециализированной литературы тут быть не должно. Эта библиотека — проверенные временем книги, которые с высокой вероятностью будут полезны и интересны большинству разработчиков. 3 | 4 | ## Бэкенд 5 | ### Чтение для всех и каждого 6 | - Martin Kleppman — Designing Data Intensive Applications 7 | - Building Secure and Reliable Systems 8 | - Практически весь [блог](https://martinfowler.com/) Мартина Фаулера 9 | 10 | ### Scala и функциональное программирование 11 | - Курс Олега Нижникова «[Введение в Scala](https://stepik.org/course/16243/info)» 12 | - [Scala with Cats](https://www.scalawithcats.com/) / [Zionomicon](https://www.zionomicon.com) / видео с канала [Zymposium](https://www.youtube.com/playlist?list=PLvdARMfvom9C8ss18he1P5vOcogawm5uC) 13 | - Paul Chiusano, Rúnar Bjarnason — Functional Programming in Scala 14 | - Гарольд Абельсон, Джеральд Джей Сассман — Структура и интерпретация компьютерных программ 15 | 16 | ## Стать тимлидом 17 | - Том ДеМарко — Deadline 18 | - Майкл Уоткинс — Первые 90 дней 19 | - Ryan Singer — Shape Up 20 | - Элияху Голдратт — Цель 21 | - Фредерик Брукс — Мифический человеко-месяц 22 | - Патрик Ленсиони — Пять пороков команды 23 | - Дэниел Пинк — Драйв: Что на самом деле нас мотивирует 24 | 25 | ## Роль техлида проекта 26 | Список поможет подготовиться к реализации больших проектов на лидирующей роли. [Что это за роль?](../process/techlead/techlead). Некоторые книги дублируются с секциями про бэкенд и тимлидерство, потому что начинающему техлиду они особо будут полезны. 27 | 28 | - [Наш гайд](../process/techlead/techlead-workbook.md) + [доклад](https://www.youtube.com/watch?v=y0IY4PK-fiQ) 29 | - Архитектура (для начала достаточно первых трёх пунктов) 30 | - Richards, Mark, and Neal Ford — Fundamentals of Software Architecture: An Engineering Approach 31 | - [Architecture view model](https://en.wikipedia.org/wiki/View_model) \+ [C4 Model](https://en.wikipedia.org/wiki/C4_model) \+ [4\+1](https://en.wikipedia.org/wiki/4%2B1_architectural_view_model). Да, прямо на википедии. 32 | - Khononov, Vlad — Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy 33 | - Bass, Len — Software Architecture in Practice 34 | - Ford, Neal — Software Architecture: The Hard Parts: Modern Trade-off Analyses for Distributed Architectures 35 | - System Design 36 | - Martin Kleppman — Designing Data Intensive Applications 37 | - Delivery (достаточно первого пункта, второй и третий уже для глубокого погружения) 38 | - [“Как доделывать дела и запускать проекты вовремя.” Кинжал.](https://kinzhal.media/domique/) 39 | - Элияху Голдратт — Цель 40 | - Ryan Singer — Shape Up 41 | -------------------------------------------------------------------------------- /process/design-review/template.md: -------------------------------------------------------------------------------- 1 | # %%Название проекта%% 2 | 3 | --- 4 | 5 | ### Решаемая задача 6 | 7 | %%Ссылка на тикет%% 8 | 9 | %%Краткое описание задачи%% 10 | 11 | --- 12 | 13 | ## Требования 14 | 15 | ### Функциональные требования 16 | 17 | %% Требования к реализуемому функционалу %% 18 | Обычно берутся из тикета 19 | 20 |
21 | Пример 22 | Нужно уметь сохранять подписки пользователя в новой централизованной системе 23 |
24 | 25 | ### Нефункциональные требования 26 | 27 | %% Что учесть из существующих/неочевидных моментов в реализации на основе функциональных требований %% 28 | 29 |
30 | Пример 31 | При переключении системы на исходное состояние должны учитываться изменения, внесенные в новую систему 32 |
33 | 34 | ## Дополнительные вводные 35 | 36 | %% Известные ограничения, известные планы на будущее, ... %% 37 | 38 | --- 39 | 40 | ## Сущности и термины 41 | 42 | %%Основные объекты системы, их свойства, термины из предметной области. Здесь 43 | не надо углубляться в детали абсолютно всех моделей. Но в проекте обязательно 44 | будут сущности, которые являются для него определяющими, без которых он не 45 | сможет существовать. Вот их значение и надо описать.%% 46 | 47 | 48 | ## Общая картина 49 | 50 | ### Текущее состояние системы (если есть) 51 | 52 | %%Краткое функциональное описание существующей системы и диаграмма компонент, C1-C2 по [C4Model](https://c4model.com/)%% 53 | 54 | 55 | #### Ресурсы 56 | 57 | - Нагрузка на сервис(ы) и хранилища в разбивке по профилю(чтение/запись) 58 | - Хранимые данные 59 | - Количество записей 60 | - Сколько занимает места 61 | 62 | ### Целевое состояние системы 63 | 64 | %%Краткое функциональное описание целевого состояния системы и диаграмма компонент, C1-C2 65 | по [C4Model](https://c4model.com/)%% 66 | 67 | 68 | #### Ресурсы (если меняются) 69 | 70 | - Нагрузка на сервис(ы) и хранилища в разбивке по профилю(чтение/запись) 71 | - Хранимые данные 72 | - Количество записей 73 | - Сколько занимает места 74 | 75 | ## Влияние на смежников 76 | 77 | - Какие сервисы смежников начнут использоваться 78 | - Нагрузка на сервис(ы) в разбивке по профилю(чтение/запись) 79 | - Хранимые данные 80 | - Количество записей 81 | - Сколько занимает места 82 | - Какие сервисы смежников перестанут использоваться 83 | 84 | ## Процессы 85 | 86 | %%Ключевые процессы системы. Желательно использовать диаграммы последовательности или состояний%% 87 | 88 | 89 | ## План реализации 90 | 91 | %% Эпики по стримам с учетом параллельности%% 92 | 93 | ## План тестирования 94 | 95 | %% Кто, что, когда и как должен протестировать %% 96 | 97 | ## План релиза 98 | 99 | %% Релизы сервисов/фичи/прочие ручные действия в формате чек-листа %% 100 | 101 | ## План отката 102 | 103 | %% Релизы сервисов/фичи/прочие ручные действия в формате чек-листа %% 104 | 105 | ## Проблемы и альтернативные решения 106 | 107 | %%Что может пойти не так? Какие трейдоффы принимаем? Как ещё можно было решить задачу? Почему выбрали именно текущий 108 | вариант?%% 109 | -------------------------------------------------------------------------------- /.mapping.json: -------------------------------------------------------------------------------- 1 | { 2 | ".":"classifieds/docs/tech/external", 3 | "AUTHORS":"classifieds/docs/tech/external/AUTHORS", 4 | "CONTRIBUTING":"classifieds/docs/tech/external/CONTRIBUTING", 5 | "LICENSE":"classifieds/docs/tech/external/LICENSE", 6 | "README.md":"classifieds/docs/tech/external/README.md", 7 | "education/books.md":"classifieds/docs/tech/external/education/books.md", 8 | "principles/_assets/puml-e65c8ca997e7.svg":"classifieds/docs/tech/external/principles/_assets/puml-e65c8ca997e7.svg", 9 | "principles/crosservice-development.md":"classifieds/docs/tech/external/principles/crosservice-development.md", 10 | "principles/legacy-diagram.svg":"classifieds/docs/tech/external/principles/legacy-diagram.svg", 11 | "principles/manifest.md":"classifieds/docs/tech/external/principles/manifest.md", 12 | "principles/primary-analysis.md":"classifieds/docs/tech/external/principles/primary-analysis.md", 13 | "principles/problem-formulation.md":"classifieds/docs/tech/external/principles/problem-formulation.md", 14 | "principles/project-cartoon.png":"classifieds/docs/tech/external/principles/project-cartoon.png", 15 | "principles/task-definition-checklist.md":"classifieds/docs/tech/external/principles/task-definition-checklist.md", 16 | "principles/tech-debt.md":"classifieds/docs/tech/external/principles/tech-debt.md", 17 | "process/design-review/definition.md":"classifieds/docs/tech/external/process/design-review/definition.md", 18 | "process/design-review/hint.md":"classifieds/docs/tech/external/process/design-review/hint.md", 19 | "process/design-review/template.md":"classifieds/docs/tech/external/process/design-review/template.md", 20 | "process/incidents/attachments/incident_lifecycle_diagram.excalidraw.png":"classifieds/docs/tech/external/process/incidents/attachments/incident_lifecycle_diagram.excalidraw.png", 21 | "process/incidents/definition.md":"classifieds/docs/tech/external/process/incidents/definition.md", 22 | "process/incidents/incident_manager.md":"classifieds/docs/tech/external/process/incidents/incident_manager.md", 23 | "process/incidents/lsr.md":"classifieds/docs/tech/external/process/incidents/lsr.md", 24 | "process/incidents/postmortem.md":"classifieds/docs/tech/external/process/incidents/postmortem.md", 25 | "process/squad_health_check/shc_how_to_external.md":"classifieds/docs/tech/external/process/squad_health_check/shc_how_to_external.md", 26 | "process/squad_health_check/squad_health_check_external.md":"classifieds/docs/tech/external/process/squad_health_check/squad_health_check_external.md", 27 | "process/teamlead.md":"classifieds/docs/tech/external/process/teamlead.md", 28 | "process/techlead/projects-complexity-overview.md":"classifieds/docs/tech/external/process/techlead/projects-complexity-overview.md", 29 | "process/techlead/techlead-skillset.md":"classifieds/docs/tech/external/process/techlead/techlead-skillset.md", 30 | "process/techlead/techlead-workbook.md":"classifieds/docs/tech/external/process/techlead/techlead-workbook.md", 31 | "process/techlead/techlead.md":"classifieds/docs/tech/external/process/techlead/techlead.md", 32 | "toc.yaml":"classifieds/docs/tech/external/toc.yaml", 33 | "yfm-build-manifest.json":"classifieds/docs/tech/external/yfm-build-manifest.json" 34 | } -------------------------------------------------------------------------------- /process/incidents/postmortem.md: -------------------------------------------------------------------------------- 1 | # Post-Mortem 2 | 3 | Post-Mortem — это исторический слепок инцидента. Важный документ, в котором участники аварии детально анализируют произошедшее и подробно описывают его контекст. Хороший post-mortem читается как захватывающий приключенческий рассказ с дежурным в главной роли. 4 | 5 | Важная часть разбора инцидента — это придерживаться **blameless** культуры. Факапы случаются — это **нормально**. 6 | При разборе инцидента ищут и чинят сломанные процессы. Непокрытые алёртами вещи, незамониторенные фичи, недостатки тестов, недостатки релиз-процесса или любого другого принятого в команде процесса. 7 | Переводить стрелки и искать виноватого — непродуктивно, порождает страх ошибок (а как тогда что-то делать вообще), 8 | а главное, не предотвращает повторение инцидента в будущем. Чините процессы, а не людей. 9 | 10 | ## Зачем писать 11 | - Чтобы учиться на чужих ошибках: распространение опыта внутри компании; 12 | - Чтобы проводить продуктивный разбор по инцидентам; 13 | - Чтобы лучше продумать план по устранению причин инцидента, используя детальное описание инцидента перед глазами; 14 | - Чтобы использовать как инструкцию к действию в случае повторения инцидента; 15 | - Чтобы видеть **системно повторяющиеся инциденты**. 16 | 17 | ## Когда писать 18 | Писать для любого инцидента точно не стоит. Есть три ситуации, когда надо написать постмортем: 19 | 1. Обязательно для инцидентов 20 | первого класса 21 | критичности; 22 | 2. Для любого инцидента по желанию ответственного; 23 | 3. Для инцидента второго класса критичности по указанию руководителя разработки. 24 | 25 | ## Хорошие практики 26 | - Представьте, что постмортем читает разработчик, только пришедший в компанию. Всё ли он поймёт? Чем глубже вы опишите причину инцидента и способы его устранения, тем лучше. 27 | - Задайте себе пять вопросов «почему?» 28 | - Писать постмортем таким образом, чтобы его можно было использовать как инструкцию для дежурного при повторении инцидента похожего. 29 | - Подсчитывать потери. 30 | - В план действий, сформулированном после разбора инцидента, стараться устранить *причину* инцидента, а не повысить удобство в работе с уже случившейся аварией. 31 | - Причём каждый пункт в плане действий должен быть конечной задачей, а не общими формулировками: «улучшить ...», «повысить ...». 32 | - Задачи при этом должны быть реалистичны. Если не знаете, что можно сделать, лучше так и написать, чем выдумывать воздушные замки. 33 | - И, естественно, должен сопровождаться ссылкой на тикет с ответственным за его выполнение. 34 | - ... но если устранить причину вообще никак не получается, надо стараться максимально снизить вред от повторных аварий. 35 | - Уделить особое внимание времени обнаружения. Отрефлексировать, почему не произошло мгновенное реагирование. 36 | - Перечислять в постмортеме компоненты системы, затронутые инцидентом. Это нужно для вычисления зависимостей без graceful degradation. 37 | - Если пишете о каких-то величинах, например, кеш-промахи, давайте конкретные значения и ссылки на графики, по которым вы их поняли! Это будет бесценная информация при повторении аварии. 38 | - Постмортемы должны распространяться настолько широко, насколько это возможно. Одна из целей постмортемов — обучение на чужих ошибках. 39 | - Крайне важно избегать агрессивный тон по отношению коллегам. 40 | - Держать себя в руках на разборе постмортема :) 41 | 42 | --- 43 | ### Ссылки 44 | [Google SRE Workbook — Postmortem Culture: Learning from Failure](https://sre.google/workbook/postmortem-culture/) 45 | [Pager Duty Post Mortem template](https://response.pagerduty.com/after/post_mortem_template/) 46 | -------------------------------------------------------------------------------- /process/squad_health_check/squad_health_check_external.md: -------------------------------------------------------------------------------- 1 | # Squad Health Check 2 | 3 | Squad Health Check — мероприятие, помогающее команде найти решение самой актуальной проблемы. 4 | 5 | Фактически, это альтернативный формат командной ретроспективы, на которой: 6 | - Команда оценивает состояние дел в разных аспектах своей деятельности 7 | - Выявляет наиболее проблемные направления 8 | - Собирает связанные с ними проблемы и препятствия (анализирует причины неидеального состояния) 9 | - Выбирает самые важные из них 10 | - Ищет способы их решения 11 | 12 | После встречи остаются артефакты: 13 | - **Результат оценки.** Его можно использовать в следующий раз для сравнения с предыдущими результатами. Это помогает оценить эффективность выбранных решений 14 | - **Приоритезированный список текущих проблем.** Решив самую важную, можно перейти к следующей 15 | - **План решения ключевой проблемы** 16 | 17 | При разработке методики проведения мы вдохновлялись примером из [Spotify](https://engineering.atspotify.com/2014/09/squad-health-check-model/). 18 | 19 | ## Зачем нужно 20 | 21 | Squad Health Check помогает команде систематически улучшать свою работу. 22 | Регулярные встречи позволяют сравнить текущее состояние с предыдущими результатами и оценить динамику изменений. 23 | 24 | Анализ данных по всем командам подразделения помогает выявить общие проблемы и разработать универсальные решения. 25 | 26 | ## Как проводить 27 | 28 | Мероприятие проводится в формате командной ретроспективы. Основное отличие — этап сбора данных: 29 | - Команда оценивает состояние дел по стандартным критериям, используя шкалу: **хорошо/средне/плохо** 30 | - Затем определяется тренд: **улучшается/не меняется/ухудшается** 31 | 32 | Дальнейшее обсуждение фокусируется на самых слабых местах. 33 | 34 | Для помощи командам доступны: 35 | - [шаблон в Miro](https://miro.com/app/board/uXjVJmLLLns=/?share_link_id=44122416350). (Введите: Health_Check_1) 36 | - [рекомендации по проведению](shc_how_to_external.md). 37 | 38 | **Анонимность.** Оценка может проводиться анонимно. Формат остальных этапов команда выбирает самостоятельно. 39 | Если участники не готовы к открытому обсуждению, рекомендуется сохранить анонимность для всех этапов. 40 | 41 | **Рекомендация:** первый раз проведите мероприятие полностью анонимно. 42 | 43 | **Длительность.** От 1 часа. Точное время зависит от размера команды, опыта фасилитатора и количества проблем. 44 | Для первого раза выделите 1.5–2 часа. 45 | 46 | **Регулярность.** Проводите на постоянной основе. Оптимальная периодичность: 47 | - Не реже 1 раза в год 48 | - Не чаще 1 раза в квартал 49 | - Рекомендуемый интервал — раз в полгода 50 | 51 | **Отличия при первом и последующих проведениях:** 52 | - Первый раз: изучение критериев и шкалы оценки, определение тренда по ощущениям команды 53 | - Последующие разы: добавление сравнения с предыдущими результатами 54 | 55 | ## Что оцениваем 56 | 57 | Стандартный список критериев, подходящий большинству команд. Критерии сгруппированы для удобства: 58 | 59 | **Задачи и цели** (понимание и влияние команды): 60 | - Понятность миссии и целей 61 | - Участие в принятии решений 62 | 63 | **Результат работы команды** (эффективность): 64 | - Качество 65 | - Скорость 66 | - Удовлетворённость заказчиков 67 | 68 | **Внутренние факторы результата:** 69 | - Командная работа 70 | - Процесс разработки 71 | - Экспертиза 72 | - Дежурство 73 | - Кодовая база 74 | 75 | **Внешние факторы результата:** 76 | - Инструменты 77 | - Взаимодействие со смежными командами 78 | 79 | **Личные аспекты:** 80 | - Удовольствие от работы 81 | - Обучение и развитие 82 | 83 | Подробное описание каждого критерия доступно в шаблоне Miro. 84 | 85 | ## Что почитать 86 | 87 | - [Spotify. Squad Health Check model – visualizing what to improve](https://engineering.atspotify.com/2014/09/squad-health-check-model/) 88 | - [Fun Retrospectives](https://www.funretrospectives.com) — много разных идей по проведению ретро 89 | - [Retromat](https://retromat.org/ru) — еще идеи для ретро 90 | 91 | -------------------------------------------------------------------------------- /process/design-review/hint.md: -------------------------------------------------------------------------------- 1 | # Рекомендации как писать дизайн-документы 2 | 3 | ## Вопросы на подумать 4 | 5 | Подсказка для начала работы над дизайн-документом. Пункты из списка — это начальные точки для размышлений. Список не претендует на полноту и универсальность, а помогает приступить к самостоятельному анализу системы. 6 | 7 | - Логика 8 | - Какие бизнес-процессы **самые** важные в задаче? 9 | - Действительно ли техническое решение соответствует требованиям? 10 | - Данные 11 | - Модель 12 | - Схема хранения 13 | - Нагрузка 14 | - Есть ли SLA? 15 | - Необходимая задержка / пропускная способность системы 16 | - Ожидаемая rt/nonrt нагрузка 17 | - Объём хранимых данных, их прирост 18 | - Интеграции 19 | - Сервисы, от которых зависит система 20 | - Нагрузка на внешние сервисы 21 | - API 22 | - Кто будет пользователями API? (Фронтенд, мобильные приложения, внутренние сервисы, ...) 23 | - Устраивает ли API пользователей? 24 | - Масштабирование 25 | - Как сервис растет с ростом нагрузки или размера хранимых данных? 26 | - Какие ручные действия необходимо совершить для осуществления дальнейшего роста? 27 | - Отказоустойчивость 28 | - Везде ли предусмотрена транзакционность, где она нужна? 29 | - Возможно ли ситуации, когда система *потеряет данные*? 30 | - Являются ли операции идемпотентными? 31 | - Как сервис себя ведет при отключении дата центра, базы-данных и других зависимых сервисов 32 | - Как ведет себя система при единичной ошибке обработки запроса/сообщения 33 | - Информационная безопасность 34 | - С какими чувствительными данными будет работать система? 35 | - Где могут произойти утечки? 36 | - Data Governance 37 | - Аналитические поставки данных 38 | - Почему выбрано именно это решение, а не альтернативы? 39 | - Какие альтернативы в принципе рассматривались при выборе решения? 40 | - Что будет с системой дальше? 41 | - Риски и недостатки выбранного решения 42 | - При каких обстоятельствах оно даст сбой? 43 | - Какой предел масштабирования у системы? 44 | - Насколько система будет сложна в разработке и поддержке? 45 | - Ожидания 46 | - Какой срок запуска проекта? 47 | - Какие конкретно ожидания у заказчика к плановой дате запуска? 48 | - Как уложить реализацию проекта в адекватный срок? 49 | - Что *не* входит в данное решение? 50 | - Команды 51 | - Какие смежные команды участвуют в проекте? Что им нужно сделать? 52 | - Точки проекта, на которых команды-участники взаимодействуют друг с другом 53 | - Все ли смежники обладают необходимой информацией о проекте? 54 | - В каких моментах проект будет зависеть от чего-то, что лежит вне зоны ответственности команды? 55 | - Какую подготовительную работу надо провести, чтобы интеграция была гладкой? 56 | - Наблюдаемость 57 | - Как понять, что всё работает как надо? 58 | - Нужны ли бизнес-метрики? 59 | - Какие технические метрики и алерты, кроме стандартных, нужны? 60 | 61 | ## Описание альтернатив 62 | 63 | Когда ревьюверы будут читать дизайн-документ, самым частым вопросом, который они будут себе задавать, будет «Почему сделали X, а не Y». Часто авторы дизайн-документа рассматривали Y, но отказались от него по каким-то причинам. Об этом стоит написать прямо в документе. В итоге и у ревьювера сразу будет понимание почему не сделали Y, и на будущее останется артефакт, который на этот вопрос ответит следующему поколению (или нам самим через пол года). 64 | 65 | Это относится не ко всему решению целиком, а к отдельным частям, которые можно было сделать иначе. Очевидно, что расписать альтернативы каждого принятого решения невозможно. Но если по какому то пункту альтернативы рассматривались или, тем более, обсуждались — то это лучше отразить в дизайн-документе. 66 | 67 | ## Как рисовать диаграммы 68 | 69 | 70 | Известные способы рисовать иллюстрации: 71 | 72 | 1. [mermaid.js](https://mermaid.js.org) или PlantUML — для тех, кто предпочитает описывать диаграму на универсальном языке разметки. 73 | 2. [draw.io](https://draw.io) — классика. Позволяет рисовать достаточно сложные диаграмы; 74 | 3. [Excalidraw](https://excalidraw.com/) — простой редактор для простых схем. Примечателен тем, что имитирует рисование «от руки». 75 | -------------------------------------------------------------------------------- /process/techlead/techlead-skillset.md: -------------------------------------------------------------------------------- 1 | # Знания и навыки техлида 2 | 3 | Тут собран минимальный набор знаний и навыков для успешного техлидерства. Каждое направление сопровождено списком литературы. Да, литературы недостаточно, но это хотя бы что-то. Нумерация литературы сквозная. 4 | 5 | ### Архитектура 6 | 7 | *Чтобы понять, что делать-то собственно* 8 | 9 | 1. Richards, Mark, and Neal Ford. Fundamentals of Software Architecture: An Engineering Approach. 10 | 2. Bass, Len, et al. Software Architecture in Practice. 11 | 3. Ford, Neal, et al. Software Architecture: The Hard Parts: Modern Trade-off Analyses for Distributed Architectures. 12 | 4. [Architecture view model](https://en.wikipedia.org/wiki/View_model) \+ [C4 Model](https://en.wikipedia.org/wiki/C4_model) \+ [4\+1](https://en.wikipedia.org/wiki/4%2B1_architectural_view_model). Да, прямо на википедии. 13 | 5. Khononov, Vlad. Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. 14 | 15 | Для начала достаточно \[1\], \[4\] и \[5\]. 16 | 17 | ### System Design 18 | 19 | *Чтобы собрать систему как конструктор из технологий и паттернов* 20 | 21 | 6. Kleppmann, Martin. Designing Data-Intensive Applications: The Big Ideas behind Reliable, Scalable, and Maintainable Systems. 22 | 23 | Для начала можно даже не до конца читать :) 24 | 25 | ### Risk analysis 26 | 27 | *Чтобы не строить отказоустойчивую систему там, где достаточно скрипта на баше, и не писать скрипт на баше там, где нужна отказоустойчивая система.* 28 | 29 | 7. Lanzafame, Robert. [Risk and Reliability Analysis for MUDE](https://tudelft-citg.github.io/MUDE/intro.html). Delft University of Technology, the Netherlands. 30 | 8. [Failure mode and effects analysis](https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis). Да, прямо на википедии. 31 | 32 | Для \[7\] достаточно беглого чтения по диагонали. Как альтернативу можно посмотреть короткую [лекцию](https://www.youtube.com/watch?v=agDuSD-7ivo). 33 | 34 | ### System Thinking / Systems Theory 35 | 36 | *Общая интуиция для понятия системы. Не обязательный, но желательный пункт.* 37 | 38 | 9. Левенчук, Анатолий. Системное мышление. 39 | 40 | ### Delivery 41 | 42 | *Чтобы система заработала в проде, а не на бумаге* 43 | 44 | Ищите в интернете по ключевым словам: декомпозиция, оценка сроков, управление ожиданиями, азы проектной организации. 45 | 46 | 10. [“Как доделывать дела и запускать проекты вовремя.” Кинжал.](https://kinzhal.media/domique/) 47 | 11. Голдратт, Элияху. Цель. Процесс Непрерывного Улучшения. 48 | 12. Singer, Ryan. Shape Up: Stop Running in Circles and Ship Work That Matters. Basecamp, 2019. 49 | 50 | \[10\] — 15 минут чтения, осилит каждый. \[11\] и \[12\] — уже продвинутый уровень. Вместо них можно посмотреть [доклад](https://www.youtube.com/watch?v=GIk0A2DiQbA) и ещё какие-нибудь видосики на тему. 51 | 52 | ### Communications 53 | 54 | *Чтобы эффективно взаимодействовать с другими участниками проекта* 55 | 56 | Целостную литературу найти сложно. Есть список софт-скиллов для самостоятельной проработки: 57 | 58 | 1. Самоорганизация. Способность принимать и исполнять правильные решения без внешнего контроля. При этом распространять свои решения на окружающих. 59 | 1. Организаторские навыки. Умение организовать коллег хотя бы на небольшой задаче. В отсутствии лидерских качеств — эффективные действия в роли ведомого. 60 | 2. Бизнес-ориентированность 61 | 1. Умение сделать свою задачу именно так, как это нужно бизнесу на самом деле 62 | 2. Базовое понимание экономики предприятия 63 | 3. Умение проводить анализ предметной области 64 | 4. Умение принимать решения на основе синтеза своих твёрдых навыков с пониманием бизнеса 65 | 5. Умения отделять зёрна от плевел: действительно важные для бизнеса проекты и требования от не важных 66 | 3. Взаимодействие со смежниками 67 | 1. Умение разговаривать с продактом и другими нетехническими людьми так, чтобы им было понятно. При этом понимать то, что говорят они. 68 | 2. Налаживание взаимодействия со смежными командами. 69 | 3. Управление конфликтами 70 | 1. Создание конструктивных конфликтов 71 | 2. Эффективное поведение во время конфликта 72 | 4. Организация своего труда, личная эффективность 73 | 5. Грамотная устная и письменная речь 74 | 75 | ### Доклады 76 | 77 | *… от наших сотрудников. Максимально близкая нам информация.* 78 | 79 | 13. [Доклад](https://www.youtube.com/watch?v=y0IY4PK-fiQ) на TechLead Conf о роли техлида проекта; 80 | 81 | 14. [Доклад](https://www.youtube.com/watch?v=wX7OXL9K1mU) об успешных практиках для техлида проекта на Delivery Meetup от нашего разработчика; 82 | 83 | 84 | ### Реальный опыт 85 | 86 | *Уникальная информация о наших собственных проектах* 87 | 88 | ...чтобы увидеть этот раздел, приходите к нам работать :) 89 | -------------------------------------------------------------------------------- /principles/manifest.md: -------------------------------------------------------------------------------- 1 | # Общие принципы разработки в Вертикалях 2 | 3 | Описанные здесь принципы сформулированы на основе реальной работы в Вертикалях. Очевидно, что в организации достаточно часто происходят и действия вразрез им, но это исключения, а не правило. Помимо наших принципов мы разделяем ценности Вертикалей и всего Яндекса. 4 | 5 | ## Бизнес-ориентированность 6 | Вертикали — это продуктовая компания, и в ней жизненно важна синергия разработки и бизнеса. Поэтому важное качество наших разработчиков — это бизнес-ориентированность, то есть фокус на ценности, которая создаётся в результате работы. У нас разработчики общаются с продактами напрямую. Они имеют как непосредственный доступ к информации о продукте, так и задачу осмыслить потребности бизнеса перед тем как перейти к написанию кода. 7 | 8 | ## Осознанное отношение к рискам 9 | Разработка и продукт находятся в непрерывном [диалоге](primary-analysis.md) о реализации новых идей. Иногда наиболее выгодное для продукта решение — это временный «костыль» в разработке, который противоречит естественному желанию разработчиков держать систему в стройном и красивом состоянии. В таких случаях практикуется осознанное взвешивание рисков от некрасивого решения и совместный поиск оптимального баланса между продуктовым эффектом сейчас и развитием системы в будущем. Мы отвергаем карго-культ «идеального кода» и в то же время готовы понятным языком объяснить продукту, почему иногда экономия на разработке обернётся значительно большими убытками. 10 | 11 | Чем бы мы не занимались, везде наилучшим поведением является такой же осознанный подход к трейд-оффам. Например, с [техническим долгом](tech-debt.md) мы боремся не ради технического фетишизма, а для решения конкретных взвешенных проблем, оказывающих негативное влияние на бизнес. 12 | 13 | ## Горизонтальные связи 14 | Мы самостоятельно [взаимодействуем](crosservice-development.md) со смежниками из других команд, а не пытаемся решить все вопросы через менеджера. Мы не стесняемся конструктивно дискутировать о решениях коллег или выставлять на общее обсуждение свои идеи, потому что коллективная работа над задачей часто бывает продуктивнее индивидуальной. По этой же причине мы избегаем ситуаций, в которых человек продолжительное время разрабатывает сервис в полном одиночестве, не показывая никому свой код: мы сторонники командной работы. 15 | 16 | ## Ответственность 17 | Разработчик в Вертикалях не просто пишет код. Он отвечает за весь жизненный цикл своего продукта. Участвует в продуктовой проработке, обсуждает техническое решение, пишет код, выводит сервис в прод, поддерживает его работоспособность для пользователей. 18 | 19 | Профессионального роста у нас добиваются люди, которые не боятся выходить за границы своей зоны [ответственности](../process/techlead/techlead.md) и расширять свою область влияния. И правда, иногда можно нанести огромную пользу компании подметив недостаток в выбранном продуктовом решении, или поправив неоптимальный процесс, или оказав помощь коллегам. При этом важно именно собственное стремление, а не ожидание директивы сверху. 20 | 21 | Само собой, не все люди хотят постоянно выходить за границы своей зоны ответственности. Мы ценим также и результативную работу в рамках своих обязанностей. 22 | 23 | ## Человечность 24 | Люди — это самое ценное, что есть в нашей команде. Мы относимся к коллегам как к людям, а не шестерёнкам в рабочем механизме. Мы поддерживаем среду, в которой разработчики могут не только комфортно работать, но и раскрывать свой потенциал. И, конечно же, коммуникации всегда должны сопровождаться уважением к коллегам. 25 | 26 | Этот же принцип отражен и в нашем подходе к [руководству](../process/teamlead.md). Профессиональный рост и мотивация сотрудников, создание для них комфортной рабочей атмосферы — это одни из самых важных задач руководителя. 27 | 28 | При возникновении проблем мы считаем правильной моделью поведения концентрацию на системном решении, а не обвинения отдельных личностей. 29 | 30 | ## DevOps 31 | Для нас DevOps — это не новое название должности сисадмина, а культура и методология совместной работы разработки и эксплуатации. Поэтому мы уделяем большое внимание качеству автоматизации наших типовых процессов, а разработчики сами отвечают за работоспособность своих сервисов в проде. Деплой, наблюдаемость, алертинг, [реагирование на инциденты](../process/incidents/definition.md) — всё это продумывают и реализуют сами разработчики, пользуясь готовым инструментарием. 32 | 33 | Мы стремимся к инфраструктуре как продукту, поэтому непрерывно развиваем свою Platform as a Service. Мы щепетильно относимся к отказоустойчивости: наши системы должны быть готовы к сбоям. Значительные изменения обязательно проходят [design review](../process/design-review/definition.md). Мы уверенно следуем пути continuous delivery, поэтому стремимся минимизировать время выкладки сервисов, следим за green trunk и изоляцией компонент, а релиз может сделать любой участник команды. 34 | -------------------------------------------------------------------------------- /process/techlead/techlead.md: -------------------------------------------------------------------------------- 1 | ## Предпосылки, или зачем все это 2 | 3 | За последние несколько лет в Авто.ру было несколько "больших" продуктовых запусков. 4 | 5 | Мы вместе с продуктом проанализировали, как шли процессы разработки, запуска, эксплуатации и пришли к выводу, что на каждом таком проекте необходим тех. лид, который ведет весь проект целиком. 6 | 7 | Особенности этих проектов 8 | - Это продуктовые задачи 9 | - У проекта есть project-менеджер. Обычно он же заказчик, но бывает и по другому 10 | - нет единой кросс-функциональной команды 11 | - участвовало больше 4 команд и еще больше сервисов 12 | 13 | Что пошло не так и какие проблемы решаем: 14 | - каждая команда что то сделала, но все вместе плохо стыкуется 15 | - получилось сложное и трудно поддерживаемое решение 16 | - никто не знает, как это все вместе работает 17 | - упустили часть требований 18 | - продукт принес в одну из команд решение, которое сделали без понимания, как это будет работать все вместе. На этапе интеграции пришлось переделывать 19 | - не учли нагрузку на некоторые части системы. Сломалось на этапе запуска 20 | - после запуска что то сломалось, и не понятно, куда нести проблему. Все команды ждут, что разбираться будет кто то другой 21 | - не подумали про план запуска. Как выкатить все части и легко включить/выключить новый функционал 22 | - забыли про аналитику. Какие данные и откуда надо поставлять 23 | - забыли про запуск через AB 24 | 25 | Практику с выделенным тех. лидом уже начали применять и регулярно стакиваемся с вопросами: "А что же он должен делать?", "Границы ответственности с project-менеджером", ... 26 | 27 | Хочется немного формализовать ожидания от тех. лида и ответить на все эти вопросы. 28 | 29 | ## В каких проектах он должен быть 30 | На тех, которые соответствуют определению проекта. 31 | 32 | {% note info "Проект — это ..." %} 33 | 34 | Продуктовая или техническая задача, соответствующая одному из критериев: 35 | - Создание нового сервиса; 36 | - Интеграция двух и более поддоменов; 37 | - Вовлечение бо́льшей части профессий продуктовой команды; 38 | - Изменение ключевой функциональности business-critical сервиса; 39 | - Ожидаемая разработка более человеко-месяца.Продвинутый инструментарий сбора информации используется не только руководителем, но и остальной командой 40 | 41 | {% endnote %} 42 | 43 | P.S. Это пересекается с идеей дизайн-ревью. Если оно вам нужно, скорей всего вам нужен тех. лид. И да, он обязательно принесет туда диз. док. 44 | 45 | ## Откуда он появляется в проекте 46 | 47 | Скорее всего — это кто-то из команд, участвующих в реализации проекта. Вероятнее всего — вызвавшийся сам. 48 | В крайнем случае, если никто не хочет, привлекать руководителей служб. 49 | 50 | ## Что от него ждем 51 | - полностью берет на себя ответственность за техническую реализацию проекта 52 | - глубокое погружение в доменную область 53 | - понимание всего проекта в целом. От того, что видит пользователь, до аналитики и поддержки 54 | - "Helicopter view" технической части проекта. Т.е. без погружения в детали конкретных сервисов 55 | - будет единой точкой входа для заказчика 56 | - фасилитацию внутренней коммуникации между разными командами разработки 57 | - фасилитацию совместных решений между ними 58 | 59 | ## Границы между project-менеджером, заказчиком и тех. лидом 60 | 61 | **Важно!** Они работают вместе, для получения результата. Границы приведены примерно и могут меняться, в зависимости от ситуации. 62 | 63 | ### За что отвечает тех. лид 64 | - **проработку** функциональных требований **заказчика**. Фактически тут он играет роль системного аналитика 65 | - формирование нефункциональных требований (нагрузки, надежность, ...) 66 | - общую архитектуру решения (крупноблочно. Детали по каждому блоку прорабатывает конкретная команда) 67 | - написание и защиту диз. дока 68 | - взаимодействие между командами по техническим вопросам 69 | - тестирование 70 | - запуск 71 | - опытную эксплуатацию 72 | - перевод проекта на поддержку. Т.е. по итогу должно стать понятно, с какими вопросами и в какие чаты приходить. 73 | 74 | ### За что не отвечает тех. лид 75 | - **придумывание** функциональных требований (use-case, макеты, ...) 76 | - фиксирование результатов обсуждений с заказчиком 77 | - календарный план работ ("колбаски", ганты, и т.д.) 78 | - проектные синки 79 | - организацию и планирование разработки в командах исполнителях 80 | 81 | ## Зачем становиться тех. лидом проекта 82 | Что вы получите, если успешно затащите проект в роли фичалида: 83 | - Респект и уважуху от всех участников проекта 84 | - Расширение кругозора. Выходите из домика своей зоны ответственности и видите, как все устроено у смежников 85 | - Больше узнаете про продукт 86 | - Быстрый рост кучи навыков 87 | - Горизонтальные связи со смежниками 88 | 89 | ## Полезные ссылки 90 | - [Настольная книга тех. лида](techlead-workbook.md) 91 | - Наш доклад про тех. лидов на TechleadConf 2023. [Youtube](https://youtu.be/y0IY4PK-fiQ), [VK](https://vk.com/video-160451396_456240682) 92 | - [Наш доклад про путь техлида на проекте на Delivery Meetup 2024](https://www.youtube.com/watch?v=wX7OXL9K1mU) 93 | - [Еще на тему от коллег из MindBox](https://habr.com/ru/companies/mindbox/articles/741448/) 94 | -------------------------------------------------------------------------------- /principles/primary-analysis.md: -------------------------------------------------------------------------------- 1 | # Первичный анализ задач 2 | 3 | К разработке часто приходят с вопросом “помогите, как сделать вот такую задачу?” 4 | 5 | В этом кейсе заказчик быстро хочет получить план "на салфетке": реально ли вообще сделать задачу, и насколько она сложна. 6 | 7 | Знание технической стороны от разработчика + знание продукта от заказчика = новые решения сложных проблем бизнеса, более быстрые и качественные. 8 | 9 | Эти решения развивают продукт быстрее. Заказчики в такие моменты в восторге от разработки. А разработчики проявляют себя как настоящие 10x-инженеры. 10 | 11 | ## Как разработчик спасает заказчика 12 | 13 | Самое главное — осмыслить задачу на стыке технологий и продукта, подойти к бизнес-требованиям творчески: 14 | - Понять, что надо бизнесу на самом деле. 15 | - Подумать, есть ли альтернативные способы решения задачи, кроме разработки того, «что написано». 16 | - Подумать, можно ли отсечь часть требований, радикально упростив задачу. 17 | - Кристаллизовать оптимальный способ технической реализации из бизнес-идеи. 18 | 19 | Всё это делается верхнеуровнево и быстро, без погружения в детали, "на салфетке". 20 | 21 | ### Tips and tricks 22 | 23 | - Стоит тесно работать с заказчиком и чётко понимать, какую исходную проблему он хочет решить, и зачем. Так найдутся более простые решения проблем. А порой станет понятно, что надо решать вообще другую проблему. → См. [Формулировка проблем (НЖЯ)](problem-formulation.md) 24 | - Порой видно только дорогое решение (например, cтоит месяц разработки). Тогда можно представить, что у нас гораздо меньше времени (например, неделя). И придумать подходящее решение. 25 | - Есть и другие способы стимулировать творческое мышление. Например, если простое решение мешает придумать особенность работы одного из сервисов — представить, что этой особенности нет. 26 | - Если нужен контекст, который есть у коллеги — стоит его получить. 27 | - Бывает полезен брейншторм не просто одного разработчика с заказчиком, а нескольких разработчиков из одной или разных команд с заказчиком. 28 | 29 | ## Что не ожидается от помогающего разработчика 30 | 31 | - Реакция в течение минут, как в дежурстве. Хороший SLA на реакцию зависит от команды. 32 | Если непонятно, как выбрать SLA - в качестве ориентира можно взять три рабочих дня, а дальше твикать по необходимости. Т.е. можно в спокойном темпе сделать это фоном или между своими задачами. Обычно не нужно всё бросать и заниматься новым запросом на разбор. 33 | - Обнаружение абсолютно всех вариантов, блокеров и деталей задачи. 34 | Нужен верхнеуровневый первичный разбор, что-то не учесть на этом этапе — это ок. 35 | - Точнейшая оценка задачи. Достаточно прикидки на уровне "дни/недели/месяцы". 36 | - Ответ, когда возьмём задачу в работу. С этим лучше отправить заказчика к ответственному за планирование. 37 | - Полная разработка задачи сразу. Достаточно прикинуть верхнеуровневое решение. 38 | 39 | ## Зачем всё это разработчикам и командам 40 | 41 | Во многих компаниях и командах вышеописанной деятельностью занимается только тимлид/техлид. Зачем же делать это не только тимлиду/техлиду, но и другим разработчикам? 42 | 43 | - Повышается синергия между разработчиком и продуктом. 44 | Продукт становится тем, на что разработчик напрямую влияет, а не чем-то абстрактным и далёким. 45 | - Разбирать такие вопросы — сложная и очень развивающая активность для разработчиков. 46 | - Контекст сервисов лучше размазывается по команде, повышается bus factor. 47 | - Избавляемся от вечных дежурств по доработкам в фичах. 48 | Например, когда за проект отвечал конкретный разработчик, часто и все вопросы по дальнейшим доработкам проекта прилетают тоже в него. А можно периодически выделять другого разработчика, который разберётся в доработке. 49 | - Повышается вовлечённость команд в будущие задачи: когда разработчик проводил первичный анализ задачи, он лучше понимает её контекст. 50 | После чего, например, может помогать продукту топить за задачу на планировании. 51 | - Убирается бутылочное горлышко в виде тимлида/техлида: избегаем его перегрузки. 52 | 53 | ## Ограничения салфеточного анализа 54 | 55 | - Разработчику нужен helicopter view сервисов команды и её окружения. Без этого помогать будет трудно. 56 | Например, разработчик/команда слишком мало знает о той области, в которой надо решить задачу, и не может быстро получить этот контекст. Тогда стоит просто сказать об этом и поискать коллег в теме. Если таких коллег нет — что ж, похоже, в этой задаче салфеточный анализ неприменим, и нужно дорогое полноценное погружение. 57 | - Бывают настолько сложные задачи, что они никак не решаются салфеточным анализом. Если мы попробовали найти решение быстро и не удалось — не беда. Мы узнали, что даже составить верхнеуровневый план решения — сложная задача сама по себе, это уже ценно. А ещё мы запустили в головах процесс обдумывания, который фоном может внезапно принести решение через недельку-другую :) 58 | 59 | ## Как не надо делать 60 | 61 | 1. Отмахнуться от вопроса со словами "у нас огромный беклог, идите ждите месяц, пока мы сможем на это посмотреть". 62 | _Почему это плохо:_ проблема долго не решается, хотя возможно, что на самом деле можно легко найти очень простое решение. Причём порой даже в команде, в которой ресурсы как раз есть. 63 | 2. На такие вопросы всегда отвечать только тимлиду/техлиду. 64 | _Почему это плохо:_ ограничивается простор для развития разработчиков, ухудшается принятие решений из-за генерации идей только одним человеком. 65 | 3. Уйти прорабатывать или даже сразу программировать решение, не поговорив с заказчиком. 66 | _Почему это плохо:_ 67 | ![What the customer really wanted?](project-cartoon.png) 68 | -------------------------------------------------------------------------------- /principles/legacy-diagram.svg: -------------------------------------------------------------------------------- 1 | Легаси 🤮Как оно относитсяк бизнес-стратегии компаниина текущий момент?Действительно тормозитбизнес-процессы, приносит убытки,не соответствует стратегии компанииНе противоречит бизнесу,но вызывает неудовлетворённостьу команды разработкиПриводим системук состоянию,соответствующемупотребностям бизнесаУстраняемраздражениекоманды -------------------------------------------------------------------------------- /principles/crosservice-development.md: -------------------------------------------------------------------------------- 1 | 2 | ## Abstract 3 | 4 | Вертикали обладают сложной и гетерогенной инфраструктурой, разные части которой находятся во владении разных команд. Зачастую для решения задачи требуется внести правки в более чем один сервис, в том числе и в те, которыми владеют другие команды. 5 | 6 | ## Цель 7 | 8 | Упростить внесение изменений и повысить качество принимаемых технических решений. 9 | 10 | ## Правила внесения изменений в чужую кодовую базу 11 | 12 | ### Перед внесением изменений 13 | 14 | Почитай документацию, ознакомься с coding standards, дойди до владельца со своей задачей и обсуди варианты решения, **получи одобрение от владельца**. Если изменений много - возможно стоит использовать 15 | Процедуру design review. 16 | 17 | ### Feel free to contribute 18 | 19 | Можно вносить правки в любой сервис. Но при этом: 20 | - правки должны соответствовать code style, coding standarts и архитектурным принципам, принятым в команде - владельце кода; '* 21 | - перед тем, как отдать правки на ревью владельцу, дай их посмотреть своим коллегам; 22 | - нельзя вливать правки без согласия владельца; 23 | - оставь код лучше, чем он был до твоего прихода; 24 | - как контрибьютор не забывай, что межкомандное ревью может занять дольше, чем обычно; 25 | 26 | '* - а что если нет coding style, coding standarts? Смотри "Я - владелец". 27 | 28 | ### Тесты 29 | 30 | Тесты важны. У нас green trunk и trunk based development, и тесты - это один из механизмов, который позволяет рассчитывать на то, что сделанные правки не сломали функциональность сервиса. Но не только. Тесты - это еще и часть документации проекта. А потому: 31 | - написал новый код - обложи его тестами; 32 | - внес правки и сломал тесты? - почини; 33 | - внес правки, а тесты не упали? Возможно они написаны криво или их недостаточно. Удостоверься, что для твоих правок тесты проходят корректно; 34 | - нашел ненужные тесты - удали; 35 | 36 | ### Эксплуатация 37 | 38 | Не забывай что решение задачи это не только написание кода, но и эксплуатация. Подумай о метриках, логах, мониторингах, трассировке. Не усложняй жизнь тех, кто будет поддерживать сервис в production окружении. 39 | 40 | ### Кто сломал - тот и чинит 41 | 42 | Ни что в мире не может гарантировать то, что написанный код корректен (окей, может быть кроме TLA+). И потому внесенные правки могут сломать тесты, метрики, и даже production. 43 | Чинить в таком случае должен автор правок. 44 | *Важно!* если результатом правок стал инцидент - его устраняет команда, ответственная за эксплуатацию сломанного сервиса. Она не делегирует починку автору ломающих правок. Но дальше можно завести баг и передать его автору, чтобы он его исправил. 45 | 46 | 47 | ## Что должен обеспечить владелец кода 48 | 49 | ### Code review: 50 | 51 | Code review очень важная часть процесса разработки. Оно преследует две основные цели: поддержание качества технических решений на должном уровне и обмен информацией. Но, зачастую, добавляет не мало сложностей в процесс разработки. Чтобы сделать этот процесс не таким болезненным и более прозрачным - нужно иметь сформулированные политики code review: 52 | 53 | - как назначаем ревьюеров; 54 | - каков SLA на просмотр PR (базовая рекомендация - смотрим не позже чем на следующий день); 55 | - принципы проведения PR; 56 | 57 | Если говорить про принципы, то базовые принципы, от которых стоит отстраиваться такие: 58 | 59 | - мы даем развернутые объяснения к оставленным замечаниям: почему, что будет если не исправить, как сделать правильно. Такой подход здорово экономит время как ревьюера, так и автора кода сокращая количество пинг-понгов; 60 | - мы не отсматриваем то, что можно проверить автоматически; 61 | - если дискуссия принимает идеологический характер, то надо мёржить PR и продолжать холивар уже после решённой задачи; 62 | - отталкиваться от соглашений. Если в организации существует правило, как надо писать код в определённых ситуациях, на код-ревью надо отталкиваться от этого правила. Если же правила нет, то валидным считается любой стиль кодирования в разумных пределах, а после решения задачи можно обсудить формулирования общего правила; 63 | 64 | 65 | ### Инструментарий для поддержания качества кодовой базы: 66 | 67 | 68 | #### Code style 69 | 70 | Code style необходим, без него неизбежны бесконечные споры об именовании переменных, отступах и комментариях. 71 | Нет ни малейшего смысла проверять code style в PR. Это рутинная деятелельность и она должна быть автоматизирована. 72 | Потому необходимо, чтобы у каждого проекта был определен code style и он должен проверяться линтерами, которые легко запустить локально, и которые автоматически запускаются на PR. Вообще - все что может проверяться автоматически - должно проверяться автоматически. 73 | Если есть возможность - неплохо использовать автоформаттер. 74 | 75 | #### Coding standards 76 | 77 | **Зачем нужны?** 78 | - проще интегрировать людей в команды; 79 | - легче поддерживать качество кода; 80 | - экономия времени на code review; 81 | - код проще, разработка быстрее; 82 | 83 | **Что в них может быть:** 84 | - структура проекта (папочки/пакеты, где пишем бизнес логику); 85 | - как мы пишем функции / классы 86 | - как мы пишем тесты 87 | 88 | 89 | #### Тестирование 90 | 91 | Тестирование - это очень важно. Тесты это надежность, это скорость обратной связи, это документация проекта. Они должны быть: 92 | - простыми для написания; тесты должно быть легко писать - иначе их писать не будут; 93 | - простыми для выполнения; тесты должно быть легко запустить; 94 | - простыми в поддержке; если тест ломается - должно быть понятно почему и как его быстро починить; 95 | - надежными; если твой код сломали, ты должен это узнать; 96 | - понятными; владельцы кода должны понимать - что тестируют те или иные тесты и зачем; 97 | - [optional] покрытие кода; правки кода не должны приводить к снижению покрытия; 98 | -------------------------------------------------------------------------------- /process/incidents/definition.md: -------------------------------------------------------------------------------- 1 | # Управление инцидентами 2 | 3 | Инцидент — это __внеплановое прерывание или снижение качества работы сервиса__. Соответственно, управление инцидентами — комплекс мероприятий, __возвращающих сервис в нормальное для пользователей состояние как можно быстрее__. В этом разделе описан фреймворк, который поможет не изобретать свой велосипед для работы с инцидентами. 4 | 5 | 6 | ## Цели 7 | Основная цель процесса — это снижение вреда от инцидентов для пользователей и бизнеса. Всё остальное — это производные от данной цели, адаптированные под специфику Яндекс.Вертикалей. Фреймворк нужен только чтобы упростить достижение основной цели, поэтому не стоит превращать отдельные его составляющие в карго-культ. В конечном счёте важнее стабильная работа сервиса у пользователей, а не аккуратность оформления резюме по разборам инцидентов. 8 | 9 | 1. *Мета-цель*: Система должна быть простой и создавать минимум накладных расходов на разработчиков; 10 | 2. Дежурный разработчик и сотрудник службы поддержки могут быстро и однозначно определить критичность инцидента; 11 | 3. Постоянное повышение скорости реагирования и устранения аварии; 12 | 1. Инциденты обнаруживаются собственными алертами, а не по жалобам от пользователей или коллег; 13 | 2. Во время инцидента участники группы реагирования действуют скоординировано, понимают свою роль; 14 | 4. Информация об инцидентах открыта на всю организацию и регулярно распространяется как минимум внутри разработки; 15 | 5. Системный разбор инцидентов и контроль за устранением причины. Инциденты не теряются и не зависают в воздухе; 16 | 6. Открытая и понятная документация о процессе реагирования и дальнейшей обработке инцидента. 17 | 18 | ## Фреймворк 19 | ### Жизненный цикл инцидента 20 | Фреймворк делит жизненный цикл инцидента на этапы. Ключевая идея в том, что каждый инцидент должен последовательно дойти до этапа устранения причин и, как следствие, _не повториться_. Каждый этап сопровождается инструкциями и подсказками, позволяющим участникам работы над инцидентом сконцентрироваться на сути происходящего. 21 | 22 | ![Жизненный цикл](./attachments/incident_lifecycle_diagram.excalidraw.png) 23 | 24 | - Обнаружение 25 | - Классификация 26 | - Устранение 27 | - Диагностика (возможно, с привлечением [Incident Manager](incident_manager.md)) 28 | - Восстановление штатной работы 29 | - Распространение информации 30 | - Предотвращение 31 | - [Анализ](postmortem.md) 32 | - [Разбор](lsr.md) 33 | - Устранение причины (контроль со стороны Incident Manager) 34 | 35 | Теперь посмотрим, как это будет выглядеть вживую: 36 | - Происходит обнаружение инцидента: дежурный видит его в канале с алертами своей команды, либо ему приносит обращение саппорт или смежник. 37 | - Анализ рисков выполняется дежурным при помощи 38 | памятки дежурного и классификации инцидентов. 39 | - Дежурный фиксирует краткий 40 | Incident Report. 41 | Он содержит минимальную информацию, по которой можно оценить критичность инцидента и собрать статистику по ключевым метрикам. 42 | - Дежурный приступает к устранению аварии. В этот момент к нему может подключаться [Incident Manager](incident_manager.md). Он помогает с локализацией инцидента и координацией дежурных. 43 | - После восстановления штатной работы дежурный пишет [Post-Mortem](postmortem.md) для инцидентов первого класса критичности, либо для иных, о которых попросил Incident Manager. IM и тимлид напоминают дежурному о написании post-mortem, если он забыл :). 44 | - IM, дежурные, участвовавшие в устранении и тимлид ответственной команды проводят [разбор](lsr.md) инцидента. После разбора в post-mortem фиксируются действия по предотвращению подобных инцидентов. При необходимости разбор проводится очно. 45 | - IM следит за тем, что действия по предотвращению выполняются. 46 | 47 | ### Метрики 48 | Важная составляющая работы с инцидентами — это статистика. Её сбор и анализ нужен для отслеживания здоровья организации и обеспечения позитивной тенденции по авариям для пользователей. 49 | 50 | - Распределение инцидентов по способу обнаружения (алерт в ответственной команде / алерт в смежной команде / жалоба от сотрудников компании / жалоба от пользователей); 51 | - Время до обнаружения; 52 | - Время до устранения; 53 | - Количество пострадавших пользователей и финансовый ущерб; 54 | - Доля инцидентов **без устранённых причин**. 55 | 56 | 57 | ### Процедуры 58 | - Вводятся классы критичности инцидентов, по ним классифицируются потенциальные инциденты в продуктах при помощи служб поддержки и продаж. 59 | - **Первый**. Высший уровень критичности, нарушение ключевых бизнес-процессов. Надо чинить любой ценой вне зависимости от обстоятельств. 60 | - **Второй**. Незначительное нарушение ключевых бизнес-процессов или нарушение второстепенных процессов. Устранять в рабочее время, отложив остальные дела; 61 | - **Третий**. Незначительные проблемы. Всё остальное. Устранять в штатном режиме. 62 | - Вводится роль Incident Manager, которую получают руководители разработки и другие опытные люди, обладающие широкими знаниями системы. 63 | Носители этой роли отвечает за минимизацию ущерба от инцидентов в своих подсистемах. В минимизацию ущерба входит как предотвращение аварий, так и помощь в их устранении. 64 | - По инцидентам вводятся метрики, которые отслеживаются командой IM: 65 | - Классификация инцидентов оформляется максимально наглядным и понятным программистам способом, минимизирует сомнения. Помимо неё описывается и поддерживается в актуальном состоянии памятка дежурного. 66 | - Обязательным этапом онбординга становится обучение дежурству. Как программа-минимум — знакомство с памяткой и специфичными для команды вещами. Как максимум — тренинг по реагированию на инцидент. 67 | - Для регистрации инцидентов, прохода по этапам жизненного цикла, написания пост-мортемов создаются формы, боты и шаблоны, позволяющие заполнить их с минимумом когнитивной нагрузки, но сохранить при этом бесценную статистику. 68 | 69 | 70 | 71 | --- 72 | ### Ссылки 73 | - [Building Secure and Reliable Systems](https://static.googleusercontent.com/media/sre.google/en//static/pdf/building_secure_and_reliable_systems.pdf) (Глава 16) 74 | - [High Severity Incident Management Program](https://www.gremlin.com/community/tutorials/how-to-establish-a-high-severity-incident-management-program/) 75 | - [ITIL](https://wiki.en.it-processmaps.com/index.php/Incident_Management) 76 | - [Наш доклад об управлении инцидентами на CodeFest 2024](https://www.youtube.com/watch?v=aNb1G4qOiNE) 77 | -------------------------------------------------------------------------------- /principles/task-definition-checklist.md: -------------------------------------------------------------------------------- 1 | # Ставим задачи правильно 2 | 3 | Когда говоришь заказчикам, что задача поставлена плохо, они сначала обижаются, а потом задают справедливый вопрос: "А как надо?". 4 | 5 | Этот документ — попытка найти ответ. 6 | 7 | ## В чем проблема с постановкой задач 8 | Разработчики работают гораздо лучше, когда получают хорошо проработанные, понятно описанные задачи. Им не нужно догадываться, что имел в виду автор, уточнять требования, или переделывать, когда сделано не то, что было нужно. 9 | 10 | Заказчики часто пренебрегают проработкой задач — у них, помимо вашей, ещё десяток других задач, куча встреч, и, вообще: "Вроде хорошо написал, что не понятно то?". 11 | 12 | К чему это приводит: 13 | - принесли решение, а не проблему. "Сделайте ручку для ...". В итоге оказывается, что эта ручка вообще не помогает в решении проблемы, или ее надо серьезно дорабатывать 14 | - проблема описана в очень общем виде. Разработка начинает выяснять нюансы. Это происходит на встречах, в чатах, в личке, ... . Зачастую, результаты не фиксируются. Потом долго гадаем, почему сделали именно так и что именно хотели изначально 15 | - на старте не подумали, как будем запускать. Например, нужно будет сравнить старый вариант и новый. Для чего нужны A/B тесты. В итоге реализация оказалась сильно дороже, чем предполагалось изначально 16 | - не описали на что влияют изменения и как они должны повлиять на "смежную" функциональность. Выкатили решение, которое ломает имеющуюся функциональность в других разделах 17 | - не прописали, как будем выкатывать с учетом старых версий мобильных приложений. Про них просто забыли и сломали 18 | 19 | ## Как можно полечить 20 | Решений может быть много. Сейчас предлагаю следующее: 21 | - приходить с проблемой, а не с решением. Вполне возможно, что решение будет другим. _Если есть идеи про решение, их конечно же тоже стоит принести. Но обязательно вместе с проблемой_ 22 | - иметь единый источник фиксации продуктовых требований. 23 | - фиксировать все договоренности в том самом источнике сразу, как они были достигнуты. Делать это силами заказчика и валидировать записанное через того, с кем договаривались 24 | - проверять постановку задачи глядя на чек-лист. Даже если вам не нужны выгрузки для аналитиков, лучше написать это в явном виде, чтобы потом не тратить время на выяснения, почему их не сделали. 25 | 26 | ## Признаки хорошего описания задачи 27 | 28 | ### Зачем это делать 29 | Какую выгоду получит бизнес от выполнения этой задачи. В идеале — метрики, которые изменятся. 30 | 31 | **Плохо:** Сделать VIP пакет с длительностью 14 дней. 32 | 33 | **Хорошо:** Услуга VIP очень эффективная и очень дорогая, к тому же имеет большой срок действия — 60 дней. Есть гипотеза, что сделав его дешевле, но на 14 дней, сможем продать больше услуг и заработать больше денег. 34 | 35 | ### Содержит проблему, а не решение 36 | 37 | **Плохо:** Сделать в public-api ручку для получения цены отчетов для дилеров с учетом промокодов. 38 | 39 | **Хорошо:** У дилера есть промокоды на бесплатное получение отчетов. Однако при покупке отчета он видит только цену покупки и не знает, сколько у него есть промокодов, и будет ли получение отчета бесплатным. 40 | 41 | В хорошем варианте, разработчик скорей всего догадается, что нужна не цена с учетом промокодов, которая просто будет равна 0, а цена и доступное количество промокодов. Иначе будет сделана никому не нужная ручка. 42 | 43 | → См. также [Формулировка проблем (НЖЯ)](problem-formulation.md) — инструмент для проверки, что вы действительно сформулировали проблему, а не решение. 44 | 45 | ### Definition of Done 46 | Понятный и измеримый критерий, по которому мы поймем, что получили то, что хотел заказчик. 47 | 48 | **Плохо:** Тормозит ручка цен на платные услуги для объявления. 49 | 50 | **Хорошо:** Ручка цен на платные услуги для объявления: 95 перцентиль времени ответа - 900 мс. Должно быть не более 500 мс. 51 | 52 | В плохом варианте разработчик может ускорить недостаточно, или наоборот закопаться в оптимизацию, пытаясь сделать 100 мс на 99 перцентиле. 53 | 54 | ### Описан результат, а не процесс 55 | **Плохо:** Сделать скрипт, выдающий промокоды заданому списку пользователей. Запустить скрипт на приложенном списке. 56 | 57 | **Хорошо:** Для привлечения перекупов, хотим выдать некоторым из них промокоды со скидкой 50% на размещение объявлений. Список перекупов, которым надо выдать скидку, собрали аналитики и приложили к тикету. 58 | 59 | Во втором варианте, разработчик скорей всего подумает не только о скрипте, но и том, что хорошо бы сделать рассылку пользователям, получившим промокод. 60 | 61 | ### Содержит все необходимые материалы 62 | Задача должна содержать весь контекст, нужный для её выполнения. Необязательно писать все прямо в задаче. Достаточно ссылок на документацию, диз. доки и прочие полезные места. 63 | Представьте, что программист возьмёт вашу задачу, когда вы будете в отпуске. Вы же не хотите быть на связи круглосуточно и вкидывать контекст. 64 | 65 | ### Указана методика тестирования 66 | Если нет плана тестирования, разработчик скорей всего проверит только основной успешный сценарий. При наличии плана и сценариев, разработчик может написать автоматические тесты (unit, интеграционные, ...), или пройтись по ним вручную. 67 | 68 | ## Чек-лист 69 | Заказчикам стоит его использовать перед тем, как отнести задачу в разработку. А разработчикам, при анализе задачи. 70 | 71 | Конечно, соответствовать всем пунктам сложно, и вряд ли, если вы забудете один или два, то задача не будет выполнена. Но чем больше галочек вы поставите в списке ниже, тем продуктивней и приятнее будет работа. 72 | 73 | Основная часть: 74 | - описание проблемы 75 | - какое видим решение 76 | - макеты UI (не дизайн. Можно хоть карандашом накидать) 77 | - сценарии использования. Если это что-то новое, то все возможные. Если надо править имеющееся, то, все, которые должны измениться. Важно, чтобы сценарии были описаны для всех ролей. Например: пользователь, поддержка, аналитик, продакт, ... 78 | - новый функционал будет доступен всегда всем и везде, или есть варианты 79 | - как будем проверять успешность запуска. Зачастую, это какая-то аналитика, а для нее нужны данные 80 | 81 | Так же будет полезным подумать про: 82 | - необходимость поставки данных для аналитики, дашбордов и т.д. 83 | - дополнительные нюансы и ограничения (например связанные с мобильными приложениями) 84 | - как будем запускать. Все сразу, по частям, ... . Возможно, нужны А/В эксперименты, или настройки доступности по регионам 85 | - MVP. Если есть желание выпустить часть функционала раньше. Стоит про это написать 86 | - дальнейшее развитие. Этого может не быть, но если уже знаем, будет полезно сразу заложить такую возможность при проектировании 87 | 88 | -------------------------------------------------------------------------------- /process/squad_health_check/shc_how_to_external.md: -------------------------------------------------------------------------------- 1 | # Как проводить Squad Health Check 2 | 3 | Приведенный набор рекомендаций подходит большинству команд, и мы советуем всем его использовать. 4 | Но при необходимости вы можете адаптировать формат под себя. Постарайтесь не пропустить самое важное. 5 | 6 | **Важное:** 7 | - На встрече необходимо найти решение минимум одной ключевой проблемы 8 | - Сохранить артефакт с оценками состояния команды 9 | 10 | ## Подготовка 11 | 12 | **Необходимые материалы:** 13 | - Доска в Miro с [шаблоном "Squad Health Check"](https://miro.com/app/board/uXjVJmLLLns=/?share_link_id=44122416350). (Введите: Health_Check_1) 14 | 15 | **Распределение ролей:** 16 | - **Фасилитатор:** человек, который ведет встречу. Лучше, если это не тимлид команды (особенно в первый раз) 17 | - **Тимлид:** участвует в оценке наравне со всеми, может помогать фасилитатору 18 | 19 | ### Подготовка к встрече 20 | 21 | 1. **Создайте доску в Miro:** 22 | - Создайте новую доску и скопируйте на неё [шаблон](https://miro.com/app/board/uXjVJmLLLns=/?share_link_id=44122416350). (Введите: Health_Check_1) 23 | - Проводящий должен быть владельцем доски для доступа к расширенным инструментам 24 | 25 | 2. **Настройте шаблон:** 26 | - Выберите вариант разминки (или удалите этот этап) 27 | - Отрегулируйте количество фишек для голосования по числу участников команды 28 | - Если используете не анонимный вариант оценки, добавьте нужное количество столбцов с именами участников 29 | 30 | 3. **Подготовьте команду:** 31 | - При первом проведении расскажите команде про цель встречи и что будете делать в процессе 32 | - Проверьте, что все участники имеют доступ к доске в Miro 33 | - Если команда не использовала Miro раньше, проведите краткий ликбез (как создавать стикеры, голосовать, управлять масштабом) 34 | 35 | 4. **Организация встречи:** 36 | - Открывайте фреймы последовательно (слева направо), скрывая пройденные этапы 37 | - Это помогает держать фокус на текущей активности 38 | 39 | ## Структура встречи 40 | 41 | Встреча состоит из нескольких этапов: 42 | 43 | ### Разогрев (необязательно, 5-10 минут) 44 | 45 | **Цели:** 46 | - Переключиться с рабочих задач на встречу 47 | - Освоить базовые функции Miro 48 | - Настроиться на анализ процессов в команде 49 | - Создать неформальную атмосферу 50 | 51 | **Вариант 1. «Какой я супергерой»** 52 | 53 | Помогает участникам порефлексировать на тему — какую роль они выполняют в команде, кем они видят себя на работе. 54 | А вторая часть дает инсайты о том, как их воспринимает команда. 55 | 56 | Эту активность лучше не проводить больше одного раза. Повторить можно только после изменений в составе команды. 57 | 58 | **Вариант 2. «Безопасность и доверие»** 59 | 60 | Если не знаете точно, как дела с доверием в команде, обязательно проведите эту разминку. 61 | 62 | **Важно!** Проводить нужно анонимно. 63 | 64 | Если опрос покажет, что проблема есть, нельзя проводить не анонимную оценку. Получите очень недостоверные результаты. 65 | 66 | --- 67 | 68 | ### Часть 1. Оценка (15-20 минут) 69 | 70 | Оценка проводится по типовому набору критериев, подходящих большинству команд. 71 | Для каждого критерия в шаблоне приведено описание того, что такое «хорошо» и что такое «плохо». 72 | 73 | Для каждого критерия нужно оценить: 74 | - **Текущее состояние** по шкале от 1 до 3, где: 75 | - 1 = плохо (красный) 76 | - 2 = средне (желтый) 77 | - 3 = хорошо (зеленый) 78 | 79 | **Формат оценки** 80 | 81 | Вы можете выбрать анонимный или открытый формат: 82 | 83 | #### Анонимный вариант (рекомендуется) 84 | 85 | В таблице есть колонки со светофором, и для каждой строки набор фишек — по одной на каждого участника. Нужно поставить фишку в правильную колонку. 86 | 87 | **Плюсы:** 88 | - Проще высказать свое мнение, нет необходимости потом его пояснять 89 | - Более честные результаты 90 | 91 | **Минусы:** 92 | - Могут поставить плохую оценку, а потом не рассказать, почему она такая 93 | - Если в команде есть "ворчуны" или саботажники, они заметно повлияют на итоговую оценку 94 | 95 | **Важно:** если у вас платная версия Miro, используйте анонимное голосование её штатными средствами. 96 | 97 | #### Открытый вариант 98 | 99 | У каждого участника своя колонка, в которой нужно раскрасить стикер в соответствующий цвет (зеленый/желтый/красный). 100 | 101 | **Плюсы:** 102 | - Можно явно спросить у автора, почему он поставил именно такую оценку 103 | - Видно, как отличаются мнения новичков и опытных членов команды 104 | 105 | **Минусы:** 106 | - Очень сложно получить честный результат (только если в команде очень высокий уровень доверия и безопасности) 107 | - Есть риск перейти на личности при обсуждении проблем 108 | 109 | #### Подсчет результата 110 | 111 | Независимо от способа оценки, результат нужно усреднить, чтобы получить итоговую оценку по каждому критерию. Рекомендуется просто брать среднее арифметическое. 112 | 113 | --- 114 | 115 | ### Часть 2. Тренды (5-10 минут) 116 | 117 | **При первом проведении:** 118 | Текущий тренд определяется только по ощущениям команды. 119 | Проводим голосование и выбираем итоговый тренд, усреднив результат. 120 | 121 | **При последующих проведениях:** 122 | Сначала оцениваем критерии, потом смотрим на результаты прошлого раза и выставляем тренд в соответствии с предыдущими оценками. 123 | 124 | Результат копируем в таблицу с оценкой. В ней есть колонка для тренда. 125 | 126 | Если получился очень большой разброс оценок, стоит провести обсуждение и прийти к общему решению. 127 | 128 | --- 129 | 130 | ### Часть 3. Сбор проблем (15-20 минут) 131 | 132 | #### Шаг 1. Формулировка проблем 133 | 134 | Смотрим на те критерии, где есть красное, желтое или отрицательный тренд. Из них выбираем самые проблемные. 135 | 136 | **Важно!** Не надо пытаться охватить сразу все проблемные места. Выберите 1-2, точно не больше трех. 137 | 138 | Просим всех описать проблемы или чего не хватает, чтобы поставить оценку выше. Подробности см. в шаблоне. 139 | 140 | После этой части у вас будет список проблем для обсуждения, и вся команда будет понимать, о чем речь. 141 | 142 | **Важно!** На этой стадии не обсуждаем, только накидываем и поясняем, что имели в виду. 143 | 144 | **P.S.** Если у вас все зеленое — супер! Но всегда можно еще лучше, так что это не повод сворачивать обсуждения. 145 | 146 | #### Шаг 2. Выбор приоритетов (5 минут) 147 | 148 | Все решить наверно не получится, так что выбираем самое важное для команды. 149 | 150 | Классический способ выбора — голосование точками. В шаблоне каждому дано по 3 голоса, но вы можете изменить это количество. 151 | 152 | **Рекомендация:** 3 голоса на человека. Если тем очень много, то взять квадратный корень от их количества и округлить в большую сторону. 153 | 154 | **Важно!** Если у вас платная версия Miro, проводите голосование анонимно её штатными средствами. 155 | 156 | --- 157 | 158 | ### Часть 4. Обсуждение и решение (20-30 минут) 159 | 160 | #### Обсуждаем 161 | 162 | Выбираем проблему с максимальным количеством голосов, обсуждаем и придумываем решение. Потом переходим к следующей. 163 | 164 | **Рекомендации:** 165 | - Говорить по очереди и не перебивать 166 | - Ограничивать время на каждого участника 167 | - Фиксировать прозвучавшие тезисы в таблице (план действий → обсуждение) 168 | - Не обязательно обсудить все темы. К ним можно вернуться на отдельной встрече 169 | 170 | **Важно!** Не гонитесь за количеством. Лучше обсудить только одну тему и придумать конкретное решение, чем просто поговорить про всё и разойтись. 171 | 172 | #### Формируем список действий 173 | 174 | Список действий лучше формировать в виде: 175 | - **Кто делает** (ответственный) 176 | - **Что делает и какой результат ожидаем** 177 | - **Когда** (срок выполнения) 178 | 179 | **Рекомендации:** 180 | - Не надо записывать во все действия ответственным тимлида. Ищите добровольцев или назначайте из наиболее компетентных в данной области 181 | - Подумайте и запишите, какой результат будет у действия 182 | 183 | **Пример плохого действия:** 184 | "Обсудить со смежниками проблему" → результатом будет "я обсудил", что не улучшит ситуацию в команде. 185 | 186 | **Пример хорошего действия:** 187 | "Провести воркшоп по CI/CD до 15.10 (ответственный: Петров). Результат: гайд по настройке пайплайнов и договоренность о формате взаимодействия". 188 | 189 | --- 190 | 191 | ### Завершение (5 минут) 192 | 193 | Встреча должна быть понятной и полезной для команды. 194 | За 5 минут до конца встречи соберите фидбек с команды и обсудите впечатления от встречи. 195 | 196 | Собранный фидбек стоит учесть при следующем проведении. 197 | 198 | --- 199 | 200 | ## Альтернативный формат: только оценка 201 | 202 | Если для встречи мало времени или хотите провести только оценку, можно на этом и закончить. А все дальнейшие действия по выкапыванию проблем и придумыванию улучшений провести на отдельных встречах. 203 | 204 | Тогда просто проговорите это и договоритесь о следующих шагах. 205 | 206 | --- 207 | 208 | ## Общие рекомендации 209 | 210 | ### Для фасилитатора 211 | 212 | - Лучше иметь отдельного фасилитатора. Сложно самому вести и участвовать. Особенно если это первый раз 213 | - Следите за таймингом. Не забывайте ставить таймер. Особенно в обсуждениях 214 | - Озвучьте в начале цель встречи и ожидаемый результат: 215 | - Визуализировать, как обстоят дела в команде на ваш взгляд 216 | - Оценить текущее состояние 217 | - Обсудить оценки и почему они такие (собрать проблемы) 218 | - Придумать action plan для решения 1-2 проблем 219 | 220 | ### Техническая подготовка 221 | 222 | - До встречи попросите всех зайти на доску. Могут быть проблемы с доступом 223 | - Если раньше не использовали Miro, проведите отдельный ликбез по базовым операциям, которые потребуются в процессе (сделать стикер, управление масштабом, вставить картинку и т.д.) 224 | - Используйте приватный режим в Miro. Особенно там, где есть проблемы с доверием 225 | 226 | ### О процессе оценки 227 | 228 | - Оцениваем именно личные впечатления. Не как команда думает, а как думает каждый участник 229 | - Непонятные формулировки обсуждаются сразу во время оценки 230 | 231 | ### Для тимлида 232 | 233 | - Перед тем как оценивать с командой, оцените сами на отдельной доске. Потом сравните. Можно словить несколько инсайтов 234 | - Отслеживайте прогресс выполнения принятых решений на следующих ретроспективах 235 | 236 | ### Тайминг 237 | 238 | - Используйте таймер для каждого этапа и визуализируйте его для участников 239 | - Оптимальное время встречи — 1-1.5 часа 240 | - Для первого раза выделите 1.5-2 часа 241 | 242 | --- 243 | 244 | ## Сохранение результатов 245 | 246 | После проведения обязательно сохраните результаты оценки и тренды в общедоступном месте. Можно просто в виде скриншота или экспортировать данные из Miro. 247 | 248 | Эти результаты понадобятся при следующем проведении для сравнения динамики. 249 | 250 | --- 251 | 252 | ## Дополнительные материалы 253 | 254 | - [Статья Spotify о Squad Health Check](https://engineering.atspotify.com/2014/09/squad-health-check-model/) 255 | - [Fun Retrospectives](https://www.funretrospectives.com) — много разных идей по проведению ретро 256 | - [Retromat](https://retromat.org/ru) — еще идеи для ретро 257 | 258 | -------------------------------------------------------------------------------- /principles/_assets/puml-e65c8ca997e7.svg: -------------------------------------------------------------------------------- 1 | 🌳 КОРЕНЬСервисы падают(5 инцидентов за полгода)КлиентынедовольныБизнес теряетденьгиСмежники приходятс вопросами(3 раз/неделю)Дежурный тратитвремя(12 часов/неделю)Люди боятсядежуритьНет временина техдолгЧеловек в стрессехуже работаетПроизводительностьстрадаетОбщий дух командыстрадаетТехдолг растётСервисы становятсяещё хуже⟲ Порочныйкруг -------------------------------------------------------------------------------- /principles/tech-debt.md: -------------------------------------------------------------------------------- 1 | # Управление техническим долгом 2 | 3 | Набор принципов для управления техническим долгом в синергии с бизнесом, а не вопреки нему. 4 | 5 | Принципы работают только с соблюдением основного кредо: «**лучше не сделать новый техдолг, чем исправить старый**». Из него выводятся решения, повышающие продуктивность и удовлетворённость команды без многомесячных рефакторингов. Например, предпочтение небольших сервисов большим, «фиксация убытков» в отношении старых систем, тщательное дизайн-ревью новых решений. Так или иначе, снизить скорость прирастания легаси всегда лучше, чем остановить бизнес в тщетной попытке избавиться от него вовсе. 6 | 7 | ## Испытание легаси о бизнес-необходимость 8 | Это упражнение стоит делать при каждом подходе к легаси, чтобы избежать борьбы с ветряными мельницами. 9 | 10 | Легаси 🤮Как оно относитсяк бизнес-стратегии компаниина текущий момент?Действительно тормозитбизнес-процессы, приносит убытки,не соответствует стратегии компанииНе противоречит бизнесу,но вызывает неудовлетворённостьу команды разработкиПриводим системук состоянию,соответствующемупотребностям бизнесаУстраняемраздражениекоманды 11 | 12 | Разработке действительно хочется сделать как лучше. И с нашей точки зрения кажется, что все системы в плохом состоянии вредны одинаково. Но тут и кроется ловушка: на самом деле система может очень плохо работать, но при этом полностью соответствовать ожиданиям бизнеса от неё. Чтобы не тратить нервные клетки и время на ненужную работу, надо испытывать каждое желание исправить техдолг о бизнес-необходимость. Вполне возможно, что проблема на самом деле кроется в раздражённости команды от необходимости взаимодействовать с легаси. В таком случае надо исправлять именно его, а не пытаться системно вылечить болезнь там, где достаточно спрятать симптомы от разработчиков: писать новую логику в новых микросервисах, сделать админку или гайдлайн со скриптами для рутинных операций, погрумить проблемы внутри команды или любым другим способом добиться повышения комфорта программистов. 13 | 14 | Принятию подобных решений помогает выражение технических работ в деньгах и ресурсах. Если приблизительно оценить стоимость переписывания большой системы, может выясниться, что оно никогда не окупится. В таком случае правильнее будет вложиться в способы снижения неудобств для разработчиков. Если же переписывание окупается, то об этом стоит поговорить с бизнесом. 15 | 16 | ## Непрерывность работы 17 | Если техдолг решено устранить, то на это в любом случае потребуется выделение ресурсов команды. Хорошо, если это будет просто некоторое количество FTE, которые снизят пропускную способность команды на ограниченное время. Даже в этом случае к такому проекту должно быть ответственное отношение, чтобы он не превратился в долгострой. Плохо, если помимо этого работа над техдолгом блокирует наращивание новых возможностей ПО на продолжительное время. **Основная интеллектуальная работа руководителя на старте проекта должна протекать в ключе минимизации блокирующего влияния на бизнес**. 18 | 19 | ## Мыслить проектами, а не кодом 20 | Если при работе с техдолгом оперировать сложно написанными кусками кода и задачами на их рефакторинг, можно очень быстро утонуть. Рефакторинг кода эффективнее встраивать в культуру разработки, чтобы он происходил непрерывно при ежедневной работе программиста. Для управления техническим долгом с точки зрения *руководителя* атомарной единицей является не код, а архитектурная проблема. 21 | 22 | Особняком стоят непрерывные процессы обеспечения качества, которые выражаются в метриках. Например, количество инцидентов, время реагирования и ущерб от них, количество обращений в саппорт. К таким метрикам тоже можно сводить совокупности технических проблем, чтобы обсуждать допустимые пороги с бизнесом и держать их под контролем. 23 | 24 | ## Руководитель знает свой техдолг 25 | Руководитель должен чётко представлять себе ландшафт легаси в своей зоне ответственности. Для этого надо вести карту технических проектов, классифицировать их по важности и срочности, указывать задачи на устранение. Можно собирать регулярные синки по техдолгу, актуализировать карту, планировать следующие итерации работы. 26 | 27 | Для такой карты подходит Трекер, Вики или любое другое общедоступное место. Главное, чтобы в любой момент времени можно было понять состояние проблемных технологий в команде. 28 | 29 | ## У задачи есть заказчик 30 | Технические задачи конкурируют с продуктовыми. При этом у продуктовых задач всегда есть профессиональный заказчик, работа и компетенция которого — довести задачу до результата. Разработке тоже нужно использовать методы проектного управления в отношении своих задач, чтобы не выглядеть проигрышно на фоне продукта. Приносить не жалобы и плохо проработанные идеи, а полноценные задачи с обоснованием и *заказчиком*. Заказчик технической задачи выполняет функции и: собирает и валидирует требования, следит за проектной работой, синхронизирует команды, питчит проект. При таком подходе технические задачи перестанут выглядеть блекло на фоне продуктовых. Но это необходимое, а не достаточное условие. 31 | 32 | ## Бизнес-обоснование 33 | Каждая техническая задача должна иметь синергию со стратегией компании. Если между бизнесом и техдолгом нельзя установить соответствие, то такой проект делать не надо, поскольку он является скорее ложным перфекционизмом, чем реальной необходимостью. 34 | 35 | Идеальная ситуация — это **настолько мощное бизнес-обоснование, что заказчиком исправления техдолга становится кто-то из бизнеса**. В таком случае снимается половина головной боли с разработки. Обычно такое достигается, когда техдолг совпадает с проблемной частью бизнес-процессов. 36 | 37 | Помимо этого стоит понимать, что с точки зрения бизнеса технические проекты — это **вложения в инфраструктуру**. Соответственно правильный подход к техдолгу — это поиск ответа на вопрос «сколько ресурсов мы готовы аллоцировать под укрепление инфраструктуры в этой части компании?». На этот вопрос не могут ответить отдельно ни руководитель разработки, ни продакт — поэтому им надо работать вместе. 38 | 39 | ## Коммуникации 40 | Без налаженных коммуникаций между бизнесом и разработкой продуктивная работа над техническими задачами невозможна. Поэтому нужен **непрерывный** диалог между главами продукта и разработки. Естественно, он полезен не только для техдолга, но здесь он нам интересен, потому что без него бизнес никогда не получит реального понимания того, в каком состоянии находится разработка. Если продукт понимает, какие технические преграды стоят на пути, а разработка понимает, во что бизнес будет вкладываться, цели технического развития встанут в соответствие стратегии компании. 41 | 42 | ## Квотирование 43 | Одним из способов работы с техническим долгом является квотирование некоторого процента FTE или ёмкости команды на технические нужды. Это рабочий способ, но к нему стоит относиться с осторожностью: квотирование упрощает распределение ресурсов, но снижает гибкость команды. Если важно уметь максимально быстро реагировать на новые продуктовые возможности, оно может стать помехой. С другой стороны, квоты полезны при необходимости непрерывно работать над каким-то направлением, например, устранять причины инцидентов. То есть принятие решении о квоте должно быть обдуманным и соблюдать интересы бизнеса. 44 | -------------------------------------------------------------------------------- /process/techlead/techlead-workbook.md: -------------------------------------------------------------------------------- 1 | # В помощь техлидам 2 | 3 | 4 | Этот документ поможет начинающим техлидам разобраться, что же нужно делать работая над большим проектом. А для опытных может служить напоминалкой/подсказкой. 5 | И даст несколько советов по инструментам, которые могут пригодиться в процессе. 6 | 7 | В основном речь пойдет про продуктовые проекты, но большую часть можно использовать и на других проектах. 8 | 9 | Проекты бывают разными. У них может быть совсем другой набор стадий и роли могут распределяться по-разному. Это нормально. Так что рассматривайте данный документ скорей как набор рекомендаций, а не обязаловку. 10 | 11 | 12 | ## Роли техлида 13 | Исторически сложилось так, что над проектами работают продакты и разработка. У нас нет специально обученных аналитиков (ни бизнес, ни системных) и project менеджеров. 14 | Так что на разных стадиях проекта, участники выступают в разных ролях. 15 | 16 | Продакты: 17 | - заказчик 18 | - product owner 19 | - бизнес аналитик 20 | - project менеджер 21 | 22 | Разработка (техлид): 23 | - системный аналитик 24 | - архитектор 25 | - технический менеджер 26 | 27 | Важно помнить, что техлид и продакт не антагонисты. Они вместе делают общее дело и оба заинтересованны в успехе. 28 | 29 | ## Этапы работы над проектом 30 | Теперь рассмотрим, в какой роли выступает техлид на разных этапах проекта. 31 | 32 | ### Погружение в доменную область 33 | На этом этапе техлид выступает в роли системного аналитика. 34 | 35 | **Цель** этого этапа — разобраться в доменной области, которую затрагивает проект. 36 | 37 | **Результатом** должно быть понимание того, как сейчас работает продукт: 38 | - какие пользователи, как и зачем с ним взаимодействуют 39 | - общее понимание технической реализации. Какие сервисы участвуют и какие команды за них отвечают 40 | 41 | Если это уже описано — прекрасно. Но зачастую бывает так, что документации нет, или она недостаточна. Тогда приходиться разбираться. 42 | 43 | Бесценным источником знаний тут выступает продакт. Так как именно он лучше всех знает свой продукт. 44 | Так же очень полезным может оказаться привлечение тестировщиков. 45 | 46 | **Зачем все это нужно** — чтобы понять, что именно мы будем дорабатывать и не забыть про какие-то части продукта при внесении изменений. 47 | 48 | #### Сценарии использования. Какие есть виды пользователей и как они взаимодействуют с продуктом 49 | Ожидаем, что эту часть делает продакт, а техлид активно помогает. 50 | 51 | Важно рассмотреть не только основной сценарий использования, но и все остальные. Как с функционалом взаимодействуют: поддержка, аналитики, модерация и другие пользователи. 52 | На примере услуг продвижения для объявлений, основные сценарии выглядят примерно так: 53 | - продавец видит в карточке объявления цену услуги и может ее купить 54 | - продавец покупает и платит деньги 55 | - продавец видит, что услуга подключилась к объявлению 56 | - покупатель видит в листинге эффект от покупки услуги продвижения 57 | И есть еще много дополнительных, которые тоже нужно учесть: 58 | - продавец видит цену услуги и количество баллов плюса, которые получит за ее покупку 59 | - продавец видит купленную услугу в истории покупок 60 | - продавец получает чек о покупке на почту 61 | - продавец может включить автоматическое продление услуги 62 | - сопровождение видит историю покупок и может сделать возврат 63 | - аналитик видит покупку услуги в логе покупок 64 | - продакт видит покупки услуг на дашборде 65 | - ... 66 | 67 | Для описания сценариев можно использовать user-story, или описать их в произвольном формате. Главное, чтобы было понятно, кто, что и где делает. 68 | 69 | #### Как реализованы сценарии под капотом 70 | Это ответственность техлида. 71 | 72 | По каждому сценарию нужна верхнеуровневая схема, какие сервисы участвуют в процессе и какие команды разработки за них отвечают. 73 | Особых требований к описанию нет. Достаточно, чтобы они были понятны читателю. 74 | 75 | Рекомендации: 76 | - не делать огромных схем, на которых представлены сразу все сценарии. Это очень сложно читать. Лучше на каждый сценарий сделать отдельную схему 77 | - не стоит уходить в детали. Достаточно общего представления 78 | - респект и уважуха, если используете [С4-model](https://c4model.com)! Уровень 2 - это как раз то, что нужно на данном этапе. 79 | 80 | #### Артефакты 81 | После завершения у вас должны быть описаны: 82 | - роли пользователей 83 | - сценарии использования продукта для каждой роли 84 | - верхнеуровневые схемы реализации сценариев 85 | - список команд разработки, которые отвечают за нужные сервисы 86 | 87 | Результаты складываем в диздок. 88 | 89 | 90 | ### Анализ требований 91 | Техлид — системный аналитик и немного архитектор. 92 | 93 | Вместе с продактом, техлид выясняет, что же должно получиться в итоге. 94 | 95 | **Цель** — понять что должно получиться в итоге. Какие сценарии и как изменяться. Какие сценарии добавяться. 96 | 97 | **Результат** — максимально качественное описание задачи в продуктовом тикете. 98 | 99 | Очень важно, чтобы после этого этапа получилось именно [качественное описание задачи](../../principles/task-definition-checklist.md). 100 | 101 | Кроме функциональных требований и изменениях в пользовательских сценариях, рекомендуется подумать про: 102 | - новый функционал будет доступен всегда всем и везде, или есть варианты 103 | - дополнительные нюансы и ограничения (например связанные с app-ами) 104 | - как проверить, что сделано именно то, что хотели 105 | - как будем проверять успешность запуска. Зачастую, это какая-то аналитика, а для нее нужны данные 106 | - как будем запускать. Все сразу, по частям, ... . Возможно, нужны А/В эксперименты, или настройки доступности по регионам 107 | - MVP. Если есть желание выпустить часть функционала раньше. Стоит про это написать 108 | - дальнейшее развитие. Этого может не быть, но если уже знаем, будет полезно сразу заложить такую возможность при проектировании 109 | 110 | Даже если по этим пунктам ничего делать не требуется, лучше это зафиксироать. Новому читателю сразу будет понятно, что об этом подумали и осознанно решили не делать. 111 | 112 | После обсуждений и проработки, исходные требования скорей всего изменяться. Итог должен быть обязательно зафиксирован в продуктовом тикете. 113 | 114 | Примерно на этом этапе уже можно накидать список тест-кейсов, который отвечает на вопрос — как мы поймем, что сделали то, что нужно. Это совместное творчество продакта и техлида. Результат надо зафиксировать в продуктовом тикете и провалидировать с помощью тестировщиков. 115 | 116 | После проработки функциональных требований, техлиду стоит подумать про нефункицональные: нагрузки, масштабируемость и т.д. Результаты зафиксировать в диздоке. 117 | 118 | 119 | 120 | ### Проектирование 121 | Техлид выступает как архитектор и технический менеджер. 122 | 123 | **Цель** — получить техническое описание решения задачи. 124 | 125 | **Результат** — диздок, в котором расписано, как будет работать новый функционал. И пройденное [дизайн-ревью](../design-review/definition.md). 126 | 127 | Примерная последовательность действий: 128 | - техлид с помощью команд, ответственных за сервисы, придумывает общее решение и описывает его в диздоке. Описание примерно на уровне 2 из C4-model. Возможно шире, если того требвет ситуация 129 | - команды участники дописывают в диздок детали по их задачам, если это нужно. Уже на уровне 3 с добавлением sequence-диаграмм и другой полезной информации 130 | - техлид проходит дизайн-ревью. 131 | 132 | В зависимости от проекта, дизайн-ревью можно пройти как без детализации реализации от команд, так и вместе с ней. Для очень больших проектов, имеет смысл разделить диздок на несколько: общий и от каждого сервиса. 133 | 134 | На этом этапе техлид будет организовывать и фасилитировать встречи с командами. Главная рекомендация — проводить [хорошие и полезные](https://kinzhal.media/meetings-boss/) встречи. Не забывать про: 135 | - цель встречи 136 | - какой результат хотим получить 137 | - правильный состав участников 138 | - фасилитация в процессе 139 | - фиксация результатов 140 | 141 | Если не уверены в своих силах, совершенно не стыдно позвать на помощь продакта, или любого другого, кто может помочь. 142 | 143 | ### План разработки 144 | Техлид — технический менеджер и архитектор. 145 | 146 | **Цель** — составить план разработки. 147 | 148 | **Результат** — план разработки. В каком виде он нужен - решает продакт. 149 | 150 | Обычно на проектах продакт играет роль project менеджера. 151 | Он составляет план проекта, ставит задачи разработчикам, и следит за выполнением. 152 | 153 | Но без помощи техлида, составить план проекта не выйдет. И тут техлид активно помогает продакту. Что и где нужно сделать, в каком порядке, сколько это стоит, ... . Обычно, техлид рисует план разработки в виде верхнеуровневых задач. На нем видно: 154 | - задача 155 | - примерная сложность 156 | - какая команда выполняет 157 | - последовательность задач, если они зависят друг от друга 158 | А дальше за дело берется продакт и идет планировать розработку, и натягивать план на календарь. 159 | 160 | При этом техлид является единой точкой входа для продакта по техническим вопросам. 161 | Пример вопроса: хотим ускорить разработку и делать параллельно фронт и бэк. Что именно нужно для этого сделать - ответственность техлида. Т.е. он договориться с командами и расскажет продакту, как это повлияет на план разработки. 162 | 163 | ### Разработка 164 | Техлид — технический менеджер и архитектор. 165 | 166 | **Цель** — разработать новый функционал. 167 | 168 | **Результат** — все готово к общему тестированию и план запуска. 169 | 170 | Что делает техлид: 171 | - решает технические проблемы 172 | - выступает смазкой для команд при взаимодействии. Помогает договариваться 173 | - следит за тем, чтобы получалось то, что задумывалось 174 | - если ломается календарный план разработки, техлид помогает найти решение 175 | - пишет план запуска 176 | 177 | В конце этого этапа обязательно должен появиться **план запуска**. Что в него может входить: 178 | - какие компоненты должны быть готовы 179 | - последовательность выкатки на прод, если это важно 180 | - настройки (palma, бункер, ...) 181 | - миграции БД 182 | - фичи/рубильники/эксперименты. Где, какие, в каком порядке и кто переключает 183 | - кто и за что отвечает в процессе 184 | - как будем откатывать, если что-то пойдет не так 185 | - ... 186 | Желательно делать его в виде чек-листа или раскрашиваемой схемы, чтобы можно было отслеживать выполнение. 187 | 188 | 189 | ### Тестирование 190 | Техлид — технический менеджер и системный аналитик. 191 | 192 | **Цель** — убедиться, что новый функционал работает так, как задумано. 193 | 194 | **Результат** — план тестирования и отчет по его прохождению. 195 | 196 | По идее, на этапе анализа требований должен был появиться примерный план тестирования. 197 | В начале этого этапа план нужно составить с достаточным уровнем детализации. Его пишут тестировщики совместно с продактом. 198 | 199 | Техлид помогает с составлением и проверкой плана. Показывает план командам разработки и совместо с ними дополняет. 200 | 201 | Формат плана может быть совершенно разными. Все зависит от проекта и участников. 202 | Но точно можно сказать, что без него будет очень сложно провести качественное тестирование. Обязательно про что-то забудут, не подумают, ... . 203 | 204 | Хорошая идея - в процессе тестирования делать все в соответствии с планом запуска. 205 | 206 | ### Запуск 207 | Техлид — технический менеджер. 208 | 209 | **Цель** — запустить новый функционал в эксплуатацию. И при этом ничего не сломать. 210 | 211 | **Результат** — всеобщее счастье. 212 | 213 | Тут особо порекомендовать нечего. Следуйте плану запуска. 214 | 215 | Главная ответственность техлида - быстро решать любые возникающие проблемы. Обычно у проекта есть общий чат. Туда будут сыпаться вопросы и ошибки. Нужно на них оперативно реагировать и организовывать их решение. 216 | 217 | Т.е. когда поддержка пишет про странное поведение UI, техлид не ждет, пока отзовутся разработчики фронта, а смотрит, кто может помочь, призывает их в чат и помогает разобраться. 218 | 219 | ### Опытная эксплуатация 220 | **Цель** — "правильно" работающий функционал и быстрое решение возникающих проблем. 221 | 222 | **Результат** — все работает и есть примерное понимание, кто и как решает возникающие проблемы. 223 | 224 | Как бы мы не старались, все равно есть шанс, что на проде что-то пойдет не так. И не обязательно, это случиться в первые дни. 225 | Так что первое время, все пристально приглядывают за проектом. Как долго это продолжается, зависит от проекта. Но обычно, не дольше нескольких недель. 226 | 227 | Все это время ведется много коммуникаций в проектом чате, и возникающие проблемы прилетают в него. Как и на этапе запуска, техлид принимает активное решение в их решении. Попутно составляя некий аналог FAQ и таблицу роутинга проблем/вопросов на соответствующие команды. 228 | 229 | ### Перевод на поддержку 230 | Техлид — технический менеджер. 231 | 232 | **Цель** — завершить проект. 233 | 234 | **Результат** — Все взаимодействия идут штатными путями через соответствующие дежурные чаты. Участники проекта идут заниматься другими делами. 235 | 236 | Как это сделать — зависит от проекта. Наверняка поможет FAQ по возникшим проблемам и список к кому идти с какими вопросами. Их можно передать в сопровождение и продукт. 237 | 238 | Конечно же, техлида будут привлекать к проблемам в дальнейшем. Но активность будет исходить не от него. 239 | 240 | Идеальный результат этой стадии, если после нее техлид станет не доступен и от этого ничего не пострадает. 241 | 242 | ### Последующие доработки и улучшения 243 | Редко когда мы делаем проекты, которые больше никогда не дорабатываются. 244 | Если техлид и продакт следовали рекомендациям, оставляли нужные артефакты и подумали заранее о дальнейшем развитии, дорабатывать функционал будет легко и приятно. И это сможет сделать любой другой техлид и продакт. 245 | 246 | Давайте все к этому стремиться. Нам же потом с этим жить. 247 | 248 | ### Ретроспектива по проекту 249 | Очень рекомендуется провести серию ретроспектив по проекту, после его завершения: 250 | - общую в команде проекта (продакт, техлид, техлиды из команд участников) 251 | - внутри команд 252 | 253 | **Цель** — продолжать делать то, что было хорошо. А то, что было не очень, в следующий раз сделать лучше. 254 | 255 | **Результат** — список действий по улучшению. С конкретными задачами, сроками и ответственными. 256 | 257 | Завершением проекта можно считать завершение этапа опытной эксплуатации. 258 | 259 | Про ретроспективу написана не одна книжка, так что просто дам пару советов: 260 | - выделите на нее достаточно времени. 1 — 1:30 это минимум. Зависит от размера и длительности проекта 261 | - решите, кто ее будет проводить. Ему стоит подготовиться и в процессе быть фасилитатором 262 | - не зовите "лишних" людей. На ретро проекта стоит позвать только тех, кто активно участвовал во всем проекте: продакт, техлид проекта, техлиды разработки и тестирования. Где-то на старте у вас появилась проектная группа. Вот и ее и надо позвать. Не надо звать всех исполнителей. Участники должны быть максимально в курсе происходившего. На ретро внутри команд, зовем только команду и дополнительно приносим туда итоги ретро по проекту, которые касаются ее части работы 263 | - не надо искать виноватого и обвинять смежников во всех смертных грехах 264 | - обязательно поговорите о том, что пошло хорошо и скажите друг другу спасибо 265 | - дайте возможность высказаться всем участникам 266 | - шаги по улучшению лучше оформлять по [SMART](https://practicum.yandex.ru/blog/celi-i-zadachi-po-smart/). Должно быть понятно: что надо сделать, когда и кто ответственный. 267 | 268 | ## Артефакты после проекта 269 | Еще раз про артефакты, которые останутся после проекта: 270 | - "хорошая" постановка задачи в продуктовом тикете (требования, сценарии, как сейчас/как должно стать ...) 271 | - диздок, или несколько диздоков. В docs 272 | - план тестирования. Ссылка на него в продуктовом тикете 273 | - план запуска. Ссылка на него в продуктовом тикете 274 | - FAQ для поддержки. wiki? 275 | 276 | ## Общие рекомендации 277 | - фиксировать все результаты обсуждений. Самостоятельно или с помощью продактов 278 | - если рассматривали альтернативные варианты решений, их тоже зафиксировать. Сильно поможет другим при чтении 279 | - продумать и описать риски, и как с ними работать 280 | - делегировать и привлекать помощь. Никто не ждет, что техлид сделает все самостоятельно 281 | 282 |
283 | 284 | ## Полезные ссылки 285 | - [Кто такой системный аналитик](https://practicum.yandex.ru/blog/kto-takoy-sistemnyi-analitik/) 286 | - [Немного про user story для самых маленьких](https://habr.com/ru/post/577420/) 287 | - [Модель С4](https://c4model.com) 288 | - [Хорошая встреча](https://kinzhal.media/meetings-boss/ ) 289 | -------------------------------------------------------------------------------- /principles/problem-formulation.md: -------------------------------------------------------------------------------- 1 | # НЖЯ: Формулируем проблемы правильно 2 | 3 | > "Правильно сформулированная проблема — половина решения" — Чарльз Кеттеринг 4 | 5 | Часто мы вместо решения проблем боремся с симптомами. Или тратим недели на то, что в итоге не приближает к цели. Причина — в неправильной формулировке проблемы. 6 | 7 | **НеЖелательное Явление (НЖЯ)** — это инструмент из Теории ограничений Голдратта, который помогает формулировать проблемы так, чтобы их решение действительно приближало к цели. 8 | 9 | ## Зачем это нужно 10 | 11 | ### Связь с нашими практиками 12 | 13 | НЖЯ усиливает практики, которые мы уже используем: 14 | 15 | **[Первичный анализ](primary-analysis.md):** 16 | > "Стоит тесно работать с заказчиком и чётко понимать, какую исходную проблему он хочет решить, и зачем. А порой станет понятно, что надо решать вообще другую проблему." 17 | 18 | НЖЯ — это конкретный инструмент, который помогает понять **исходную** проблему заказчика, а не спутать её с предложенным решением. 19 | 20 | **[Постановка задач](task-definition-checklist.md):** 21 | В чек-листе есть требование: "**Содержит проблему, а не решение**". НЖЯ помогает проверить, действительно ли вы описали проблему, а не замаскировали готовое решение. 22 | 23 | **[Общие принципы — Человечность](manifest.md):** 24 | Наш принцип — концентрация на системном решении, а не обвинения людей. НЖЯ помогает формулировать проблемы системно: не "дежурный некомпетентен", а "произошло N инцидентов за период X". 25 | 26 | ### Три главные выгоды 27 | 28 | 1. **Экономия ресурсов** — не тратим время на решение не той проблемы 29 | 2. **Приоритизация** — видим, какие проблемы критичны, а какие нет 30 | 3. **Фокус на корневых причинах** — решаем одну корневую проблему вместо десяти симптомов 31 | 32 | ## Суть подхода 33 | 34 | ### Главный вопрос НЖЯ 35 | 36 | > "Если бы [этой проблемы] не было, с какой **важной** проблемой мы бы не столкнулись?" 37 | 38 | Этот вопрос заставляет копать глубже и находить настоящую проблему. 39 | 40 | ### Правила формулировки (краткая версия) 41 | 42 | Эффективная формулировка проблемы: 43 | 44 | 1. **Регулярно повторяется** (не единичный инцидент) 45 | 2. **Мы можем на это повлиять** (не "дождь идёт") 46 | 3. **Объективна и измерима** (не "плохо", а "N раз за период X") 47 | 4. **Не является причиной** (сначала фиксируем проблему, потом ищем причины) 48 | 5. **Не содержит решение** ("нет документации" → это решение, а не проблема) 49 | 6. **Не обвиняет людей** (проблема в системе/процессе) 50 | 7. **Очевидно негативна** (не требует пояснений "И чё?") 51 | 52 | [→ Подробнее о правилах НЖЯ](https://unconstrained.tilda.ws/tdocs/kogda-problema--ne-problema-nzhya--instrument-teorii-ogranichenii-ssy2mkjxjzymmmd) 53 | 54 | ## Пример из нашей практики 55 | 56 | ### Исходная ситуация 57 | 58 | **Боль:** "Дежурный долго ищет ответы на вопросы" 59 | **Очевидное решение:** "Написать регламент и документацию для дежурного" 60 | 61 | Проверяем по правилам НЖЯ: 62 | - ❌ Субъективно ("долго") 63 | - ❌ Завуалированное решение (подразумевает "написать доку") 64 | - ❌ Обвинение (дежурный недостаточно компетентен) 65 | 66 | **Вывод:** Это не проблема, это симптом. 67 | 68 | ### Применили главный вопрос 69 | 70 | > "Если бы дежурный **НЕ** долго искал ответы, с какой важной проблемой мы бы не столкнулись?" 71 | 72 | **Первый ответ:** "Дежурный смог бы заниматься техдолгом" 73 | 74 | Ага! Значит проблема в техдолге? Копаем дальше: 75 | - Техдолг есть? Да, есть. 76 | - Растёт? Да, растёт и не разгребается. 77 | - Что приоритетно в техдолге? Документация. 78 | 79 | **Стоп.** Круг замкнулся: дежурный ищет ответы → нет времени на техдолг → в техдолге нужна документация → дежурный ищет ответы... 80 | 81 | Значит, нужно копать ещё глубже: 82 | - Почему он вообще долго ищет? 83 | - Что именно ищет? 84 | - Долго, это сколько? 85 | - Откуда приходят вопросы? 86 | 87 | Посчитали: 88 | - 2 часа в неделю уходит на ответы, на типовые вопросы 89 | - 1 день в квартал на сложные вопросы 90 | - **Итого: 1-2 недели в год = 2-4% времени** 91 | 92 | ### Сформулировали НЖЯ про вопросы 93 | 94 | **НЖЯ:** "На разбор вопросов от смежников уходит в среднем 2 часа в неделю + 1 день в квартал на сложные вопросы (≈ 1-2 недели в год)" 95 | 96 | Проверка по правилам НЖЯ: 97 | - ✅ Регулярно: да, постоянно 98 | - ✅ Можем повлиять: да, наши процессы 99 | - ✅ Объективно: конкретные цифры, измеримо 100 | - ✅ Не причина: это факт, а не объяснение 101 | - ✅ Не решение: не говорит "надо сделать X" 102 | - ✅ Не обвинение: проблема в системе 103 | - ❌ **Очевидно негативно:** возникает вопрос "И чё?" 104 | 105 | ### Первое осознание: "И чё?" 106 | 107 | > "1-2 недели в год — это действительно серьёзная проблема?" 108 | 109 | **Инсайт:** То, что казалось критичным, оказалось малозначимым (2-4% времени). 110 | 111 | Правильная формулировка показала реальный масштаб. 112 | 113 | ### Копнули глубже 114 | 115 | > "А почему вообще приходят вопросы?" 116 | 117 | Обнаружили: 118 | - 3 критичных обращения в неделю 119 | - **5 инцидентов за последние полгода** 120 | - Часть инцидентов приводила к **недоступности клиентских сервисов** (~30 минут) 121 | 122 | ### Нашли корневую проблему 123 | 124 | **Корневое НЖЯ:** "За последние 6 месяцев произошло 5 инцидентов с недоступностью сервисов наших клиентов длительностью около 30 минут каждый" 125 | 126 | Проверка по правилам: 127 | - ✅ Регулярно: 5 раз за полгода ≈ 1 раз в месяц 128 | - ✅ Можем повлиять: наши сервисы 129 | - ✅ Объективно: конкретные цифры, измеримо 130 | - ✅ Не причина: это факт, а не объяснение 131 | - ✅ Не решение: не говорит "надо сделать X" 132 | - ✅ Не обвинение: проблема в системе 133 | - ✅ Очевидно негативно: недоступность клиентов — плохо 134 | 135 | ### Собрали все проблемы в одну карту 136 | 137 | В процессе обсуждения мы выписали множество проблем: 138 | 139 | - Смежники приходят с вопросами (3 раз/неделю) 140 | - Дежурный тратит время (12 часов/неделю) 141 | - Люди боятся дежурить 142 | - Человек в стрессе хуже работает 143 | - Производительность страдает 144 | - Общий дух команды страдает 145 | - Нет времени на техдолг 146 | - Техдолг растёт 147 | - Сервисы падают (5 инцидентов за полгода) 148 | - Клиенты недовольны 149 | - Бизнес теряет деньги на инцидентах 150 | 151 | **Все эти проблемы свелись к 2 НЖЯ:** 152 | 153 | 1. 🟡 **НЖЯ #1:** "На вопросы уходит 1-2 недели в год" — отпало по правилу "И чё?" 154 | 2. 🔴 **НЖЯ #2:** "5 инцидентов за полгода → недоступность клиентов" — КОРНЕВАЯ ПРОБЛЕМА 155 | 156 | **Ключевой инсайт:** Если решить корневое НЖЯ #2 (стабилизировать сервисы), все остальные проблемы исчезнут или значительно уменьшатся сами собой. 157 | 158 | ### Причинно-следственная карта 159 | 160 | {% diagram %} 161 | 162 | 🌳 КОРЕНЬСервисы падают(5 инцидентов за полгода)КлиентынедовольныБизнес теряетденьгиСмежники приходятс вопросами(3 раз/неделю)Дежурный тратитвремя(12 часов/неделю)Люди боятсядежуритьНет временина техдолгЧеловек в стрессехуже работаетПроизводительностьстрадаетОбщий дух командыстрадаетТехдолг растётСервисы становятсяещё хуже⟲ Порочныйкруг 163 | 164 | {% enddiagram %} 165 | 166 | **Если срубить дерево у корня, все ветки исчезнут сами.** 167 | 168 | ### Что изменилось 169 | 170 | | Аспект | До НЖЯ | После НЖЯ | 171 | |--------|--------|-----------| 172 | | **Формулировка** | "Дежурный долго ищет ответы" | "5 инцидентов за полгода → недоступность клиентов" | 173 | | **Решение** | Написать документацию | Стабилизировать сервисы | 174 | | **Где проблема** | В человеке | В системе | 175 | | **Приоритет** | Казалось серьёзным | Вопросы = 2-4% времени (не критично)
Инциденты = критично | 176 | | **Ресурсы** | 1-2 недели на доку впустую | Фокус на стабильность | 177 | 178 | ### Ключевые инсайты 179 | 180 | **Инсайт #1: Корневая проблема** 181 | > Если стабилизировать сервисы, все остальные проблемы (вопросы, дежурство, техдолг) исчезнут или значительно уменьшатся. 182 | 183 | **Инсайт #2: "Проблема" оказалась не проблемой** 184 | > "1-2 недели в год на вопросы" = 2-4% времени. Правильная формулировка показала, что это не критично. 185 | 186 | **Инсайт #3: Экономия ресурсов** 187 | > Не потратили 1-2 недели на документацию, которая не решила бы корневую проблему. 188 | 189 | ## Связь с другими практиками 190 | 191 | ### Post-Mortem 192 | При разборе инцидентов мы ["чиним процессы, а не людей"](../process/incidents/postmortem.md). НЖЯ усиливает этот подход: правило #6 — "НЖЯ не содержит обвинение". 193 | 194 | ### Управление техническим долгом 195 | При [управлении техдолгом](tech-debt.md) мы "испытываем легаси о бизнес-необходимость". НЖЯ помогает понять масштаб: это критично или просто раздражение команды? 196 | 197 | ### Управление инцидентами 198 | В метриках [инцидентов](../process/incidents/definition.md) мы отслеживаем "долю инцидентов без устранённых причин". НЖЯ помогает правильно сформулировать корневые причины. 199 | 200 | ## Как начать применять 201 | 202 | ### На следующей встрече 203 | 204 | Когда кто-то предложит решение проблемы, задайте вопрос: 205 | 206 | > "А какую именно проблему мы решаем? Можете сформулировать её без упоминания решения?" 207 | 208 | ### Проверьте формулировку 209 | 210 | Задайте один вопрос: 211 | 212 | > "Если бы этой проблемы не было, с какой **важной** проблемой мы бы не столкнулись?" 213 | 214 | Если ответ не "ни с какой", копайте глубже. 215 | 216 | ## Материалы для изучения 217 | 218 | ### Основные ресурсы 219 | - [Статья: Когда проблема — не проблема. НЖЯ — инструмент Теории ограничений](https://unconstrained.tilda.ws/tdocs/kogda-problema--ne-problema-nzhya--instrument-teorii-ogranichenii-ssy2mkjxjzymmmd) 220 | - [Доклад](https://youtu.be/3pklvegzF9A) Александры Брызгаловой на TeamLead Conf 2024 221 | 222 | ### Книги 223 | - "Основы ТОС" — Одед Коуэн, Елена Федурко. 224 | - "TOC Handbook" — Джеймс Ф. Кокс, Джон Шлайер 225 | 226 | --- 227 | 228 | ## Коротко 229 | 230 | 1. **НЖЯ помогает** формулировать проблемы так, чтобы их решение приближало к цели 231 | 2. **Главный вопрос:** "Если бы этой проблемы не было, с какой важной проблемой мы бы не столкнулись?" 232 | 3. **Связано** с первичным анализом, постановкой задач, принципом человечности 233 | 4. **Начните с малого:** задайте один вопрос на следующей встрече 234 | 5. **Формулировка определяет решение:** неправильная проблема → потраченные ресурсы 235 | 236 | > Лучше решить одну корневую проблему, чем десять симптомов. 237 | 238 | --------------------------------------------------------------------------------