/
Author: Литвинчук А.В.
Tags: языки программирования компьютерные технологии
ISBN: 978-5-9775-2147-5
Year: 2026
Text
^bhv^
Разработка
программного
обеспечения
Практическое руководство
для новичков в IT-команде
Структура российского IT-рынка
1 Первые шаги в IT-индустрии
Роли и карьерные пути в команде
Онбординг и адаптация в российском IT
Процессы коммерческой разработки
Командное взаимодействие и рабочие встречи
Инструменты искусственного интеллекта
Профессиональное развитие и оценка результатов
Александр Литвинчук
Александр Литвинчук
Разработка
программного
обеспечения
Практическое руководство
для новичков в 1Г-команде
Санкт-Петербург
« БХВ- Петербург»
2026
УДК 004.438
ББК 32.973.26-018 1
Л64
Литвинчук А. В.
JI64 Разработка программного обеспечения. Практическое руководство для
новичков в 1Т-команде. — СПб.: БХВ-Петербург, 2026. — 304 с.: ил.
ISBN 978-5-9775-2147-5
Книга поможет начинающим специалишам сделать первые main в 1Т-индустрии
и уверенно закрепиться в коммерческой разработке. Фокус — на междисциплинар-
ном взаимодействии и системном понимании процессов, что позво.'ыет преодолеть
разрыв между теоретической базой в узкой области и реальной практикой в команде.
В книге разбираются структура российского IT-рынка, специфика различных типов
компаний и современные методологии разработки Детально описаны командные
процессы — от формирования требований до эксплуатации продукта — и определе-
но место каждого участника в этом цикле. Особое внимание уделено практическому
освоению инструментов искусственного интеллекта: их использованию не только
для автоматизации рутины, но и как помощников в решении профессиональных за-
дач. Значительная часть книги посвящена долгосрочному развитию и методикам по-
строения плана карьерного роста для быстрого продвижения.
Для начинающих 1Т-специалистов
УДК 004.438
БЬК 32.973.26-018.1
Группа подготовки издания:
Руководитель проекта
Зав. редакцией
Редактор
Компьютерная верстка
Корректор
Дизайн обложки
Евгений Рыбаков
Людмила Гауль
Григорий Добин
Натальи Смирновой
Людмила Минина
Зои Канторович
Подписано в печать 22.04.26.
Формат 70x1001/16. Печать офсетная Усл печ л. 24.51
Тира* 100С экз. Заказ Ns 17628
"БХВ-Петербург* 191036, Санкт-Петербург Гончарная ул., 20
Отпечатано с готового ори т нал-маке га
ООО'Принт-М" 142300 М.О., г Чехов, ул Полиграфистов д 1
ISBN 978-5-9775-2147-5
© Литвинч) к А. В., 2026
© Оформление. ООО БХВ-Петербур1", 2026
Оглавление
Предисловие.................................................................. 13
Взгляд на разработку ПО .........................................................13
Российский рынок IT для новичка: почему начинать стоит здесь.....................13
Для кого эта книга?............................................................ 14
Как работать с книгой?.................................................... 14
ЧАСТЬ I. Стлрт В Г Г-КОМ АНДЕ....................................................15
Глава 1. IT-индустрия в России: рынок, компании, перспективы.....................16
1.1. Особенности российского 1Т-рынка......................................... 16
1.1.1. Структура компании................................................ 16
Технич еские гиганты......................................................16
Средние и мелкие 1Т-компании....................................... 17
Старта пы........................................................... 18
1.1.2. Основные сегменты IT в России..........................................18
Корпоративные решения......................................................18
Финансовые технологии......................................................19
Телекоммуникации. . ..................... . .........20
Электронная коммерция......................................................20
Игровая индустрия..........................................................21
Образовательные технологии............................................... 21
Медицинские технологии................................................... 21
Государственный сектор................................................ 22
1.1.3. Куда направиться начинающему специалисту?............................. 22
Импорте замещение........................................................ 22
Что это значит лично для вас. начинающего специалиста?................... 23
География..... ...................... . ..........................23
Культура...................................................................25
1.2. Типы компаний: аутсорс и аутстафф, продукт, стартап.........................26
1.2.1. Аутсорс....................................................... 26
Как это выглядит на практике?.........................................27
1.2.2. Аутстафф....................................................... 27
Итог: аутсорс vs аутстафф ....................................... ,28
1.2.3. Продуктовые компании............................................... 28
1.2.4. Стартап......................................................... 29
1.3. Как зарабатывают IT-компании: модели монетизации ПО и особенности работы
в России............................................ ..... ............................................ 30
1.3.1. Аутсорс и аутстафф............................................... 31
1.3.2, Разовый платеж................................................ 31
1.3.3. Подписка................................................... 33
Ограничения по количеству пользователей....................................33
Отраничения по объему использования..................................... 33
1.3.4. Оплата по факту использования...... ... _ ___________34
1.3.5 Фримиум..................................................... 35
1.3.6. Особенности российского рынка и российского менталитета............36
1.4. Карьерные пуз и для разных ролей................................... 37
1.4.1 Роли и обязанности что важно понимать в России________________________ 37
1.4.2. Технический путь.................................................. 37
1.4.3. Негехяический путь........................................... 38
1.4.4. Смена специализации и новые возможности ______________________ .... 38
1.4.5. Что влияет на карьерный рост в России?...................... 38
Тип компании...................................................... 38
Личная активность.................................................. 39
О законах карьеры: принципы Питера, Дилберта и Пула................. 39
Практические выводы для новичка....................................... 40
Глава 2. Роли в команде................................................•.....41
2.1. Продуктовые роли: менеджер, аналитик, дизайнер......................... 41
2 2. Технические роли-разработчик, тестировщик, DevOps .... . . .............45
2.3. Вспомогательные роли; технический писатель, поддержка ................ 49
Глава 3. Первые дни в команде................................................51
3.1. Как пройти онбординг и не потеряться?............................. .......... 51
3.1.1 Поймищ контекст, а не бросайтесь в задачи..................... 51
Почему это важно?................................................ 52
3.1.2. Задавайте вопросы....................................... ....52
Что спрашивать в первую очередь?...................................... 52
Как правильно спрашивать?........................................... 53
Особенности коммуникации в России................................ 53
3.1.3. Получение доступов............................................ ...53
("оставьте список основных систем в первые несколько дней............. 54
Запрашивай ie доступы целенаправленно . ..... .. ...54
Настройте окружение по чек-листу.................................. 54
Напоминайте вежливо, но настойчиво ................... .....55
3.1.4. Изучение процессов команды....................................... 55
Создание и оценка задач...... 55
Код-ревью............................................................ 56
Релизы ............................................................. .56
Стендапы.............................................................. 56
Ретроспективы.................................................... 56
Не спешите «улучшать»................................................ 56
3.1.5 Возьмите первую реальную задачу ........................... .... 57
Как получить первую задачу, если вам ее не дают?...................58
3.2. Ключевые люди к кому обращаться с вопросами9......................... 58
3.2.1. Непосредственный руководитель......................................58
3.2.2 Технический наставник .......................................... 59
3.2 3. Бадди (Buddy)............................................ 59
3.2.4. Специалисты по направлениям.. ................... . ..............59
3.2.5. Особенности российских команд................................. 60
Обращение с вопросами......................................... . 60
3.3, Корпоративная культура и негласные правила.............................. 61
Российская специфика: культура держится на тюдях. а не на процессах . 62
3.3.1. Как новичку читать негласные правила'.’.............................. 62
Наблюдайте за коммуникацией: иерархия реальная или декларативная?..........62
Присмотритесь к неформальному общению, где проходит граница работы?.......63
Разберитесь с процессами; скорость или качество?......................... 63
3.3.2. Чек-лист; чего лучше не делать, даже если никто не предупреждал ...... 63
3 4 План онбординга: что узнать и сделать в первые дни...........................64
3.4.1. Первые 30 дней: цель— сохранить базу и понять контекст............... 65
3.4.2. 31- 60 дней: цель — - стать предсказуемым исполнителем.............. 66
3.4.3 61-90 дней: цель — стать полноценным членом команды ..................66
3.4.4. Завершение испытательного срока: как пройти финальную встречу?.........67
Руководителя высшего звена нс нужно бояться............................... 68
Что делать, если встречи нет?............................................. 68
ЧАСТЬ И. Основы ПРОЦЕССОВ разработки.............................................71
Глава 4. Жизненный цикл ПО: от идеи до запуска...................................72
4.1. Этапы создания про1раммного продукта..................................... 72
4.1.1. Рождение программного продукта....................................... 72
С чего всё начинается?............................................. 73
Исследование рынка.................................................... 73
Формирование видения продукта............................................ 74
Стратегия и карта продукта............................................... 75
Проектирование решения................................................. 75
Оценка и запуск в разработку............................................ 76
4.1.2. Развитие программною продукта............................. ......... 76
Почему нельзя просто «сделать и забыть»?.................................. 77
Ключевые процессы этапа развития........................................ 77
Жизненный цикл разработки: основные этапы................................ 78
Когда развитие замедляется................................................ 80
4.1.3. Смерть программного продукта...................................... 81
Почему в принципе продукты умирают?....................................... 81
Как умирает продукт на самом деле? ....... ........................... 82
Российская специфика ............... ................ ... . .............. 83
4.2. Роль каждого участника на разных этапах............................... ... .84
4.2.1. Идея и рождение продукта.............. ....................... ..84
4.2.2. Проектирование решения.............................................. 85
4.2.3. Оценка и запуск в разработку.......................................... 86
4.2.4. Разработка, тестирование и выпуск версии........................ ... 86
4.2.5. Развитие и поддержка продукта..........................................87
4.2.6 Завершение жизненного цикла............................................ 87
4.2.7. Вывод.......................................................... 88
4.3. Основные принципы разработки ____________ __________________________ ______88
4.3.1. KISS......................................................... 88
4.3.2. YAGNI.............................................................. 90
4.3.3. DRY ...................................................................90
4.3.4. Fail Fast............................................................. 92
Глава 5. Безопасность в разработке программного обеспечения...................94
5.1 Базовые принципы безопасности при разработке..............................95
5.1.1. Логи.................................... .............. . ......95
5.1.2. Пароли, секреты и чувствительные данные.............................96
5.1.3. ^Велосипеды» и безопаа гость................................... 96
5.2. Доступы, роли и принцип минимальных привилегий.......................... 97
5 .2.1. Аутентификация и авторизация................................. 97
5 .2-2. Принцип минимальных привилегий ,............................... 98
5 2.3. Безопасность в распределенных системах.............................98
5.3. Аудит и тестирование безопасности...................................... 99
5.4. Законодательные требования и российская практика..................... 100
Глава 6. Гибкие методологии для новичков.....................................102
6.1. Суть Agile............................................... ...____102
6.2. Scrum: спринты, бэклоги, роли.......................................... 104
6.2.1. Основа: три столпа Scrum........... ... ....................... 104
6.2.2. Ключевые роли................................................... 105
6.2.3. Основные артефакты............................................ 105
6.2.4. Регулярные события................................. . . 106
6.2.5 Резюме для новичка в России................-.................... 107
6,3. Kanban- визуализация workflow, ограничения WIP. ...................... 108
6.3.1. Базовые принципы Kanban......................................... 108
6.3.2. Типы задач в Kanban................................................ .. 109
6.3.3. Важные нюансы.............................................. 110
6.3.4. Аналогия кухня ресторана с ограниченными мощностями................. 110
6.3.5. Метрики Kanban ....................................................Ill
6 3.6. Kanban в российских реалиях: плюсы и подводные камни... .........111
6.3.7. Что нужно знать новичку в российской КапЬап-команде?................112
6.4. Резюме: Kanban или Scrum — когда что выбрать?...........................113
6 5. Ваш первый спринт: практическое руководство для новичка..................113
6.5.1 Чек-лист первого дня: что нужно выяснить о процессе?.................114
6.5.2 Типичные ошибки новичка и как их избежать...........................114
Ошибка 1. Молчать на стендапе....................................... 114
Ошибка 2. Брать задачу и уходить в тишину на несколько дней............114
Ошибка 3. Бояться сказать, что не успеваете.............................114
6.5.3 . Как понять, что процесс сломан?...................................115
6.5.4 Ваши действия.......................................................115
6.6. Разговорник новичка: фразы для разных событий._._________________________ 116
На планировании спринта.............................. ..................116
На стендапе ...........................................................116
Когда задача заблокирована.............................................116
На ретроспективе........................................................116
Глава 7. Управление задачами и приоритизация ................................117
7.1. Системы управления задачами, требованиями, проектами и продуктами.. ....117
7.1.1. Почему важно понимать контекст?...................... ... . ..118
Причины.............................................................. ... 118
Главный вывод....................................................... 119
7.1.2 Системы управления задачами.........................................119
Что нужно знать новичку?......................................... 119
Российская специфика.......................................... 120
7.1.3. Системы управления требованиями (СУТ)........................... 120
Преимущества СУТ.......................................... 120
Российская реальность.............................................. 120
Что делать, если СУТ нет?....................................... 120
7.1.4. ALM-системы — единые платформы для всего жизненного цикла........ 121
Российская специфика......................................... 121
7.1.5. Другие системы управления в IT.............. . ...................121
7.2. Методы приоритизации задач. .......................................... 122
7.2.1 . Важнее не срок, а место в очереди................................122
7.2 2. Две большие разницы: продуктовые и проектные задачи...............122
Продуктовые задачи (развитие основного продукта).................... 122
Проектные задачи (платные доработки для конкретных клиентов)..........123
Российская специфика.............................................. 123
7.2.3 . Практические методики приоритизации..............................123
Ценное гь/Затраты (Value/Effort)......................................123
MoSCoW.......................................................... 124
RICE............................................................... 125
Метрика Полярной звезды............................................ 126
7 2.4. Главное правило приоритизации.............................. 127
7.3. Как правильно оценивать трудозатраты, сроки выполнения и ценность
для бизнеса?................................................................127
7.3.1. Относительные оценки: почему они работают лучше?..................127
Story Points (еторипоинты).......................................... 128
Покер планирования (Planning Poker)................................. 128
Оценки в футболках (T-Shirt Sizes)................................... 128
Часы «идеальные» и «реальные»: аналогия с аэропортом..................128
Метод критической цепи: умный подход к запасам-- --------------- ------128
7.3.2. От относительных оценок к реальным срокам ... .................130
7.3.3. Как перевести Story Points в сроки0............................ 130
7.3.4. Как определить ценность для бизнеса?............................ 131
Метрика Доход/Экономия................................................131
Стоимость задержки....................................................131
Модель Кано. ..........................................................132
Оценка возможностей...................................................132
Удовлетворенность клиентов.......................................... 132
7.4. Основы OKR/KP1. как задачи связаны с целями компании?................ 133
7.4 1. Два вида целей: KPI и OKR....................................... 133
КР1 ........................................................... .133
OKR................................................................. 134
7.4.2 . Российская специфика KPI и OKR............... . ... .. ...... 135
7.4.3 Кому подходят KPI, а кому — OKR?.................................. 136
7.4.4 . Работают ли цели?................................................136
7.4.5 Российская специфика постановки целей..............................136
7 4.6 Чьи цели стоит изучить в первую очередь?.........................137
ТАЛ. Когда KPI важнее здравого смысла?...................................137
7.4.8 . Что еще полезно знать о целях других?....................... . 138
7.4.9 . Что делать, если цели нужны вам?............ ............... .... 139
7.4.10 . Что делать, если в компании нет ясных целей?....................139
7 4.11. Составление целей — это отдельная работа.... .................139
7.4.12 Примеры из практики для разных ролей............................. 140
7.4 13. Ошибки, которые часто допускают................................ 140
ЧАСТЬ III. Командное взаимодействие.........................................141
Глава 8. Эффективная коммуникация...........................................142
8 1. Принципы конструктивного общения . ..............................142
8.2. Методы эффективной коммуникации. ..................................... 145
8 2.1. Регулярные встречи команды........................................145
8.2.2. Встречи один на один..............................................146
8.2.3. Форматы эффективного обсуждения вопросов и проблем_____ 146
E-mail.......................................................... 147
Чаты............................................................. 147
Аудиозвонки.......................................................... 147
Видеовстреча................................................... 148
Очная встреча.........................................................148
Очная встреча у доски ........................................... 149
Внутренняя документация............... ... .....................150
8.3 Язык команды: как понимать технические термины?.............. . 151
Откуда вообше берутся такие странные слова?.......................... 151
8.4. Особенности взаимодействия в российских командах ..................... 152
8.4.1. Типы компаний............................................ .152
8.4.2. Стиль общения ...................................................153
8.4 3. Правила и процессы...................................... 154
8.4.4 Взаимодействие между командами.................................... 154
8.4.5. Особенности работы с заказчиками и руководством...................155
Глава 9. Командные ритуалы и встречи........................................156
9.1. Ежедневные стендапы: что говорить и как слушать?.......................156
9.2. Уточнение бэклога продукта......................................... 157
9.2.1. Как разбирать объемные и нетиповые задачи?....................... 159
9.2.2. Критерии успеха и отраничения................................. 160
9.3. Планирование итерации (спринта)........................................161
9.4. Демонстрация: обзор спринта.......................................... 162
9.5 Ретроспектива: даем и получаем обратную связь...........................163
Глава 10. Режим работы команды..............................................165
10.1. «Спокойная разработка» и «Аварийный режим» ...........................165
10.1.1. Работа команды в аварийном режиме ............................. 166
10.1.2, Действия новичка в режиме «пожара»...............................166
10 13. Если вы активный участник команды, которая занимается аварией...167
10.1.4. Почему вообще возникает аварийный режим работы? ............ 168
10.2. Эскалация проблем: когда и к кому обращаться0.... .. . ... ... .......169
10.2.1. Нет доступа к системе (почта, трекер и т. п.)....................169
10.2.2. Непонятные или противоречивые требования в задаче................170
10.2.3. Отсутствие обратной связи от смежного отдела.....................170
10.3. Сложные переговоры с заказчиками и стейкхолдерами.................... .171
10.3.1. Желание заказчика получить решение в нереалистичные сроки..........171
10.3.2. Непонимание сложности или стоимости задачи.......................... 172
10.3.3. Изменение требований к задаче.................................... 173
10,3 4. Базовые принципы любых переговоров................................174
ЧАСТЬ IV. Участие специалистов нетехнических ролей в разработке
I1POI РАММНЫХ ПРОДУКТОВ.......................................................175
Глава 11. Работа с требованиями...............................................176
11.1. Методы сбора требований от пользователей............................ 176
11.1.1. CustDev............................................................176
Как проводится CustDev?................................. . . .177
Российские реалии.......................................................177
11.1.2 Jobs to Be Done (JTBD)............................................. 178
Как проводится JTBD?............................................ 179
11.1.3. Работа с существующими продуктами..................................179
11.2. Виды требований ..................................................... 180
11.2.1. Требования по содержанию....................................... 180
11.2.2. Требования по источнику............................................181
11.2.3. Требования по уровню иерархии.... ...... ..................... 181
11.3, Создание пользовательских историй и сценариев . . 182
11.3.1 Формат требований...................................................182
Критерии приемки и ограничения....................................... 183
Сценарии использования.............................................. 184
Изменение и дополнение сценариев использования........................ 186
11.3.2 . Макеты...................................................... 187
11.4. Участие в приемке готовых функций...................................... 189
11.4.1. Подготовка к приемке.............................................. 189
Чек-лист для заказчика ........................................... 189
Чек-лист для технических специалистов ..................................189
11.4.2. Приемка работы................................................... 190
11.4.3. Принятие решения...................................................191
11.4.4. Некоторые особенности приемки в России.............................191
Неуказанные требования..................................................191
Несоответствие ожиданий.................................................191
Отклонение от темы.............................. ..._____ ........... 192
11.4.5. В итоге............................................................192
Глава 12. Нюансы участия нетехнических специалистов в разработке ПО...........193
12 1. От требования к задаче что видит разработчик?...........................193
12.2. Проблема неполных требований_____________ ________... . ....... 194
12.3. Что непрограммистам важно знать про стек технологий и фреймворк?........195
12.4. Окончание срока поддержки ..............................................196
12.5. Работа с кодом и системами контроля версий..............................197
12.6. Ревью кода, сборка и развертывание.................................... 199
12.6.1. Ревью кода .................................................. 199
12.6.2. Сборка.............................................................200
12.6.3 Развертывание..................................................... 201
12.7 Технический долг и управление legacy-кодом..............................201
12. 7.1. Legacy-код.................................................... 201
12.7 2. Технический долг.................................................202
Типы технического долга................................................203
Что делать с техническим долгом?.......................................204
Что делать, если времени на возврат технического долга не дают?........205
12.8. Версионирование, прямая и обратная совместимость.......................205
12.8.1. Семантическое версионирование.....................................206
12.8.2. Прямая и обратная совместимость...... .......................... 206
12.8 3. Связь версионное™ и совместимости.............................. 208
Глава 13. Нюансы участия нетехнических специалистов в тестировании ПО........209
13.1. Виды тестирования......................................................209
13.2. Ручное тестирование: проверяем как пользователь........................211
13.2.1. Общий подход к ручному тестированию...............................212
13.2.2. Что делать, если задачу нельзя проверить в тестовой среде?........213
13.3. Формирование тесг-кейсов, чек-листов и работа с ними...................214
13.3.1. Тест-кейсы........................................................214
13.3.2. Чек-листы... .. ............................................ 216
13.3.3. Системы управления тестированием............................. 217
13.4. Автотеоьг мифы и реальность............................................217
13.5. Участие в приемочном тестировании .................................. 219
13. 5.1. Фиксация замечаний............................................. 220
13.5 2. Типичные риски и проблемы................................. 221
Глава 14. Качество и документация.......................................... 222
14 1. Что такое качество ПО с точки зрения разных ролей?.....................223
14.1.1 . Качество глазами пользователя продукта.......................... 223
14.1.2 . Качество глазами заказчика...... . .............................224
14.1.3 . Качество глазами разработчика.............................. 226
14 1.4. Качество глазами тестировщика ........................... 227
14.1.5 . Качество глазами менеджера проекта........................... 227
14.2. Участие в создании документации........................................228
14.2.1. Пользовательская документация.....................................228
14.2.2. Техническая документация ....................................... 229
14.2.3. Проектная документация......................................... 230
14.2.4. Процессная документация...........................................231
14.3. Работа с обратной связью от пользователей........................... 232
14.3.1. Сбор обратной связи............................................ 233
Служба поддержки.......................................................233
Магазины приложений................................................. 233
Каналы, чаты, соцсети и форумы...................................... 233
Формы обратной связи................. . ................... .......... 234
Прямое интервью и тесты использования............................. 234
14.3.2. Обработка обратной свя >и_________________________________________234
Работа с негативной обратной связью..... ..................... ....235
Особенности обратной связи при работе с бизнес-заказчиками............ 236
ЧАСТЬ V. Инструменты IT-команды и профессиональное развитие
сотрудников.............................................................. 239
Глава 15. Базовые инструменты..............................................240
15.1. Инструменты совместной работы....................................... .240
15.1.1. Таек-трекеры................................................... 241
15.1.2. Базы знаний ............................................ 241
15.1.3. Системы коммуникации.......................................... 242
15.1.4 Системы управления кодом и системы автоматизации.................242
15.1.5. Другие инструменты командной коммуникации ... ... ..............243
15.1.6. Интеграция инструмента..........................................243
15.2. Основы работы с метриками и аналитикой...............................243
15.2.1. Зачем в принципе нужны метрики?.............................. 244
15.2.2. Недостатки при использовании метрик........................ ... .244
15.2.3. Входные и выходные метрики......................................245
15.2.4. Особенности работы в России.................................... 246
15.2.5. Аналитика метрик............................................... 246
Глава 16. ИИ в работе 1Г-команды.............................................. 248
16.1 Базовые инструменты ИИ для автоматизации рутины..................... 248
16.1.1 Варианты использования ИИ любым сотрудником компании............ 248
Работа с текстом...... .. .............. . . ...................... 249
Тестирование.............................................. 249
Поиск решений...... . .. ........................................... 249
Специфические задачи............................................... 250
16.1.2. ИИ для разработчиков................................... .. . .250
Модели............................................................... 250
Инструменты......... ................................................ 251
Вычисления...................................................... 251
Дополнительные технологии.............................................. 252
16.1.3. Промпгы............................................... ......... .252
Ключевые элементы хороших промпз ов............................... 253
16 2. Использование ИИ для анализа данных и исследований...................253
16.2.1. Работа с данными и аналитика................................. 253
16.2 2. Задачи анализа данных для ИИ....................................254
16.2.3. Особенности и ограничения при работе с аналитикой...............254
16 3. Этические аспекты и ограничения ИИ...................................255
16.3.1. Где ИИ неприменим...............................................256
16.3.2. Правила работы с ИИ............................................ 257
16.3.3. Вывод..................................................... 257
Глава 17. Профессиональное развитие в команде............................ 258
17.1. Постановка целей и развитие навыков............................ 258
17.2. Как строить планы развития?..................................... 260
17.3. Поиск ментора и наставничество... ... .................. ...........261
17.3.1. Наставник................................................. 262
17.3.2. Ментор....................................................... 262
Как правильно обратиться к потенциальному ментору?.................. 263
Выстраивание отношений с ментором.................................. 263
17 4. Участие в комьюнити и кошверезпиях..................... .. . ... . 264
17.4.1. Основные пели участия в комьюнити и конференциях ... ....... 264
17.4.2. План участия.................................................. 265
17.4 3. Ошибки новичка.... ........................................ 266
Глава 18. Как в IT-командах устроены оценка и обратная связь?.............267
18.1. Циклы оценки: Performance Review и встречи один на один.......... 268
18 1.1. Оценка эффективности.................................... 268
18 .1.2. Встречи один на один..................................... 270
18.2. Ведение журнала достижений дтя регулярной оценки....................271
18.3. Подготовка и прохождение Performance Review.........................273
18.4. Как воспринимать обратную связь?....................................275
18.4.1. Неформальная обратная связь................................. 276
18.4.2. Ошибки новичков........................................... 276
18.4.3, Что делать с результатами оценки?............................. 277
18 5. Составление индивидуального плана развития________________ ____ ____278
18.5.1. Основные принципы, лежащие в основе ИПР........................278
18.5.2. Структура ИПР..................................................278
18.5.3. Шаги по составлению ИПР...................................... 279
18.6. Российская специфика опенки сотрудников .......................... 280
18.6.1. Основные особенности российской специфики................. 280
18.6.2. Неформальные критерии оценки................................... . 281
18.6.3. Практические советы лля роста................................. 281
Заключение................................................................283
Приложения................................................................285
Приложение 1. Глоссарий современных терминов разработки...................286
Ш 1. Продуктовые термины........................................ .. .286
П1.2. Термины, используемые в работе с людьми и командами................ 290
П1.3. Технические термины ............................................. 291
Приложение 2. Справочные материалы........................................295
П2.1, Ключевые вопросы для формирования Product Vision.. ................ 295
П2.2. Полная карга этапов жизненного цикла разработки.....................296
П2.3. Манифест и принципы Agile.................................... 296
П2.3.1 Agile-манифест разработки программного обеспечения . ......... 296
Основополагающие принципы Agile-манифеста.......................... 297
П2.4. Классификация нефункциональных требований...........................298
П2.5. INVEST-модель для пользовательской истории........................ 300
Предметный указатель......................................................301
Предисловие
Взгляд на разработку ПО
Разработка программного обеспечения — одна из самых динамичных отраслей.
Сегодня можно найти множество курсов, которые обещают вам быстро войти в
круг разработчиков, тестировщиков, аналитиков или других IT-специалистов. Од-
нако на практике одного знания языка программирования, технологии или кон-
кретного инструмента всегда оказывается недостаточно.
Я встречал сотрудников, которые хорошо разбирались в определенной технолопги
или были экспертами в используемом инструменте, но не понимали полной карти-
ны того, как разрабатывается продукт. Они путались в элементарных вещах, и это
ие давало им вырасти. Чтобы стать настоящим профессионалом, нужно не просто
знать инструменты или языки программирования, но и понимать, как работает сис-
тема под названием «разработка программного обеспечения» в целом.
Фреймворки, языки и методологии приходят и уходят. Но существуют базовые
принципы, общий подход и российские особенности. Они работают независимо
от того, создаете ли вы мобильное приложение для миллионов или сложную
enterpri se-систему.
Российский рынок IT для новичка:
почему начинать стоит здесь
П-индустрия часто воспринимается как та, у которой нет границ. Многим кажется,
что благодаря Интернету специалист из любой точки мира может участвовать в
международных проектах, не обращая внимания на государственные границы. Это
действительно так, но лишь отчасти.
В реальной жизни 1Т-специалисты всегда оформлены в конкретных компаниях, ко-
торые зарегистрированы в конкретных странах и обязаны соблюдать законы этих
стран. Также важны и потребности бизнеса: если в компании есть правила, обязы-
вающие сотрудника находиться в офисе, то границы становятся очень даже замет-
ными. Кроме того, для многих компаний важен сам по себе факт гражданства или
вида на жительство. Ну и в целом многие компании интересуются территориаль-
ным расположением сотрудника (в самых разных целях, например, в целях безо-
пасности). Это я уже не говорю о различных юридических ограничениях и пробле-
мах, которые необходимо преодолеть компаниям, чтобы взять сотрудника из дру-
гой страны на работу.
Я не утверждаю, что это невозможно. Некоторые ГГ-специалисты работают в ино-
странных компаниях, которые не имеют офисов в России. Однако многие ограни-
чения. действующие сейчас в отношении тех, кто работает из России, приводят к
тому, что найти именно удаленную работу за 1раницей становится сложнее. И как
следствие, приходится переезжать в те самые страны. 'Го есть на деле 1Т-ограсль
перестает быть такой уж безграничной, как это воспринимается
Таким образом, реально работать в зарубежных компаниях могут настоящие профес-
сионалы, опытные специалисты, которые обладают нужными знаниями и являются
востребованными за границей. Если же говорить о начинающих 1Т-специалистах, то
вряд ли мировой JT-рынок встретит вас с распростертыми объятиями
Поэтому остается искать работу в России. Кстати, в России также достаточно суро-
вые правила для работы из-за границы, и многие российские IT-компании уже тре-
буют от своих сотрудников иметь возможность приезжать в офис или как минимум
находиться на территории самой России. И речь не только про иностранцев, но и
про граждан России.
Для кого эта книга?
Эта книга в первую очередь предназначена для новичков, которые только начали
работать в IT или планируют это сделать. В книге много внимания уделяется осо-
бенностям разработки программного обеспечения в России В большинстве глав
даются советы новичку, описаны реалии работы в России и приведены примеры и
аналогии из жизни, помогающие лучше понять материал.
Книга также будет полезна тем, кто хочет выйти за рамки своей специальности и
глубже понять, как ведется разработка ПО целиком. Кроме того, книга окажет
помощь менеджерам, которые слабо знакомы с техническими терминами и нс до
конца разбираются в технологиях или процессах, используемых в компании, но хо-
тят лучше понимать команды, с которыми работают.
Если вы уже работаете в IT — как разработчик, тестировщик, аналитик или менед-
жер — и имеете практический опыт, эта книга напомнит вам про ваши ошибки, ос-
вежит знания и, надеюсь, поможет вам:
♦ систематизировать знания и увидеть, как все части соединяются в единое целое;
♦ найти точки роста для карьерного развития и углубления экспертизы;
♦ создавать продукты, которые действительно решают проблемы пользователей.
Как работать с книгой?
Книгу можно читать с любой главы. Главы, тематика которых вам хорошо знакома,
вы можете пропускать. В конце книги приведены приложения: одно посвящено
терминам, имеющим хождение в российской разработке, по которым не дано пояс-
нение в тексте, второе приложение— небольшой справочник по материалам, не
являющимся практическими советами, но полезным в плане обшего развития.
- ЧАСТЬ I -
Старт в 1Т-команде
Из первой часта книги вы узнаете об особенностях российского IT-рынка: о том,
какие в России существуют типы компаний, как они зарабатывают и зачем об этом
знать новичку. Здесь также будет рассказано о возможных карьерных путях и об
основных ролях в IT-командах. Материал завершающей главы этой част и поможет
вам понять, как вести себя в первые дни работы и к чему надо быть готовым.
- Глава 1 -
IT-индустрия в России: рынок,
компании, перспективы
1.1. Особенности российского IT-рынка
1.1.1. Структура компании
Прежде чем говорить о технологиях, языках программирования и карьерных тре-
ках, полезно разобраться в более базовой вещи — в том, какие вообще компании
существуют на российском ТТ-рынке. Это не формальность. От типа компании на-
прямую зависят задачи, стиль работы, темп, требования к специалистам и то, чему
вы научитесь в первые годы. Классификация достаточно простая.
♦ технические гиганты;
♦ средние и мелкие ГГ-компании;
♦ стартапы.
Количество первых (техгигантов) меньше всего, но это устойчивые и большие ком-
пании В них хотят попасть многие IT-специалисты, но они не идеальны. У более
мелких компаний есть свои преимущества, и, возможно, они также вам подойдут.
Рассмотрим более подробно каждый тип.
Технические гиганты
Это компании, названия которых знают даже люди, далекие от IT: Сбер. Яндекс,
VK, Ozon, МТС, Ростелеком, Тинькофф и им подобные. Попасть туда хотят мно-
гие — и не без причин. Это стабильность, масштаб и ресурсы.
Но здесь важно понимать один принципиальный момент: не все они являются IT-
компаниями в чистом виде, Например. Яндекс или VK действительно зарабатыва-
ют на технологиях как на основном продукте. А вот банки, телеком или ритейл —
это прежде всего бизнес, где IT играет обслуживающую роль. Основные деньги там
приносит не код, а кредиты, тарифы, логистика или торговля.
Из этого вытекает специфика работы:
♦ Во-первых, разработка в технических гигантах почти всегда ориентирована на
их внутренние потребности. Главный заказчик — сама компания. Именно под
нее создаются системы, платформы и сервисы.
♦ Во-вторых, процессы в таких организациях обычно очень инерционные. То есть
решения нужно согласовывать, и этот процесс может быть достаточно длитель-
ным. А еще часто свои шаги приходится согласовывать с тем, кто не разбирается
в разработке ПО, но при этом является важным заказчиком, игнорировать мне-
ние которого нельзя. Такой подход требует терпения, а также таланта объяснять
сложные вещи простым языком.
♦ В-третьих, требования здесь жесткие. Гибкие методологии используются выбо-
рочно. Часто встречаются классические каскадные подходы с заранее утвер-
жденными техническими заданиями, сроками и ответственными Иногда это
гибрид, но полной свободы ждать не стоит.
♦ Отдельного упоминания заслуживает технологический стек. В крупных компа-
ниях почти всегда выбирают надежные и проверенные решения. Эксперименты
допускаются, но только там, где они не ставят под угрозу основной бизнес. Это
нормальная логика enterprise-разработки, и характерна она не только для России.
♦ Наконец, существует заметная граница между IT и «бизнесом». Разработчику
здесь важно уметь говорить на двух языках (техническом и управленческом) и
быть готовым к тому, что отношение со стороны не-IT может быть далеко не
всегда партнерским.
Средние и мелкие 1Т-компании
Этот сегмент в России имеет свою специфику, которая заметно отличается от ана-
логичного бизнеса в США или Европе.
Прежде всего — фокус на внутренний рынок. Если западные продукты часто сразу
проектируются с расчетом на международные продажи, то российские компании в
большинстве случаев ориентируются на внутреннего пользователя. Иногда — на
страны СНГ, где схожий контекст и язык, но глобальный рынок чаще остается за
скобками
Модель роста здесь тоже другая. Венчурные инвестиции в России развиты значи-
тельно слабее, поэтому типичная история — это не «стартап —> инвестиционный
раунд (привлечение венчурных инвестиций) экспансия», а постепенное масшта-
бирование за счет собственной прибыли или частных инвесторов. Такие компании,
которые прошли стадию стартапа, нашли свою нишу и перешли на стадию масшта-
бирования, часто называют скейлапами (scale-up). Выход на международные рынки
для российских скейлапов сложен даже в благоприятные периоды, а в последние
годы стат почти недостижимым.
Следует сказать и о поддержке государства. Так, в частности, речь про налоговые
послабления, сниженные страховые взносы. Эти и другие меры позволяют IT-
компаниям развиваться.
Но главное преимущество этого сегмента— не в льготах. Оно в адаптивности.
Многие мелкие и средние российские IT-компании привыкли работать в условиях
нестабильности. Постоянные изменения в законах и иных требованиях, которые
обязательны к исполнению, воспринимаются не как проблема, а как очередная за-
дача, которую просто надо решить.
Стартапы
Вокруг стартапов всегда много романтики, но в российском контексте она быстро
разбивается о практику.
Если на Западе стартап нередко задумывается как будущий глобальный игрок, то в
России подход куда более приземленный. Здесь редко пытаются «изменить мир», а
решают куда более прагматичные и конкретные, но зато понятные проблемы: логи-
стические, операционные, образовательные, управленческие.
Многие проекты изначально ориентированы на быстрый, но понятный результат.
Стартап создается не ради миллиардной оценки, а ради работающего продукта и
дохода. Истории про «гараж, венчурные миллионы и единорога» существуют, но
остаются исключением.
Стартапы часто ограничены в финансировании (собственные средства, гранты,
иногда государственные), и, как следствие, от них ждут быстрой отдачи. Если ги-
потеза не подтверждается, проект могут закрыть и закроют без малейших колеба-
ний — просто не будет бюджета.
При этом ключевое преимущество стартапов — гибкость — никуда не исчезает.
Небольшие команды, работающие в стартапах, при необходимости быстро адапти-
руются, отказываясь от неудачных идей.
1.1.2. Основные сегменты IT в России
Теперь стоит поговорить о том, какие сегменты распространены в российском IT.
Под сегментами я понимаю отрасли со своей спецификой. Начинающему специа-
листу полезно в них ориентироват ься — это помогает осознанно выбрать направ-
ление для развития. Рассмотрим основные сегменты.
Корпоративные решения
Когда говорят про корпоративную разработку (еШе/ртс-разработку). то имеют в
виду программное обеспечение, которое используется внутри компаний. То есть
обычным людям (не сотрудникам компаний) оно не нужно. Вряд ли кому-то дома
понадобится программа, позволяющая управлять отношениями с клиентами. Такое
ПО — для закрытия своих внутренних потребностей — компании приобретают у
других компаний, именно поэтому для него часто используют термин b2h (business
to business). Почти всё, что свя гано с внутренними процессами бизнеса (расчет зар
плат, бухгалтерия, управление складом, закупки, производство, отчетность), отно-
сится именно сюда.
Важно понимать один характерный момент: корпоративное ПО пишется не для то-
то, чтобы пользователю было удобно, а для того, чтобы бизнес-процесс компании
работал без сбоев. Пользователями таких систем являются сотрудники компании, и
часто у них просто нет альтернативы, они не могут купить другую бухгалтерскую
программу, программу' для закупок или производства Поэтому главный критерий
качества — нс красота интерфейса и не современные технологии, а стабильность и
корректность в работе и соответствие законам. Также часто важна поддержка, бы-
страя реакция разработчика ПО.
В enterprise-разработке редко (почти никогда) гонятся за самыми новыми фрейм-
ворками Любое изменение здесь стоит дорою и почти всегда воспринимается не-
гативно, даже если было сделано из благих соображений. Причины такого негатива
в том, что нужно заново обучать пользователей, переписывать инструкции, согла-
совывать с безопасностью и аудитом. Поэтому новые технологии и вообще ново-
введения воспринимаются осторожно. Если вы ждете быстрых релизов и постоян-
ных экспериментов -— это не лучший выбор.
Зато здесь много сложной логики, долгосрочные проекты и понятный карьерный
рост. Новичкам полезно сразу привыкать к чтению документации и разбору бизнес-
процессов. Часто именно понимание предметной области ценится выше, чем зна-
ние еще одно! о языка программирования.
Финансовые технологии
Финтех (FinTech, Financial Technology) — это всё, что связано с деньгами и финан-
совыми операциями. В российских реалиях это в первую очередь банки, платежные
системы, сервисы переводов, кредиты, вклады, инвестиционные продукты. Работа
здесь достаточно разнообразная. Тут разрабатывают мобильные банки, системы
обработки платежей, внутренние платформы для расчетов и отчетности.
Работа в финтехе сильно отличается от многих других сфер. Здесь нет права на
«примерно» или «потом поправим». Ошибка в коде может привести не просто к
багу, а к финансовым потерям, штрафам или проблемам с регуляторами. В России
финансовая сфера жестко контролируется государством, и это напрямую влияет на
разработку; нужно понимать, не нарушает ли доработка какое-то из требований
регулятора.
Большая часть требований приходит не от продуктовой команды, а извне — из за-
конов, инструкций, нормативных документов Нужно уметь работать по правилам
и не пытаться их обойти — родительский бизнес это не оценит. Такой подход мо-
жет казаться скучным, но зато формирует очень сильную инженерную базу и при-
вычку к аккуратной работе.
Финтех хорошо подойдет тем, кому комфортны четкие требования, высокая от-
ветственность и формализованные процессы. Если у вас есть интерес к финансам
или профильное образование — это будет большим плюсом, но не обязательным
условием.
Телекоммуникации
Телеком (Telecom) — одна из самых технически сложных отраслей в IT. В России
она хорошо развита, и за ней стоит огромная инфраструктура. Тут не такое боль-
шое разнообразие, как в финтехе или enterprise, поскольку нро1раммное обеспече-
ние разрабатывается для операторов связи и провайдеров (системы управления се-
тями, биллинг, учет трафика, контроль качества связи}, а не всегда для конечных
клиентов.
Зато тут есть другие интересные вещи. Например, работа с большими объемами
данных и высокими нагрузками — это то, чего хотят многие разработчики. Зачас-
тую процессы идут в реальном времени, и система должна работать без сбоев Если
что-то ломается, это сразу чувствуют тысячи или миллионы пользователей.
Креме технической сложности, здесь много требований по безопасности и регули-
рованию: их, конечно, меньше, чем в том же финтехе, но без этого никуда. Некото-
рые функции могут быть обязательны на уровне законодательства. Поэтому разра-
ботка часто идет медленно и с большим количеством согласований.
Это направление подойдет тем, кому интересны сложные технические задачи: сети,
распределенные системы и «внутреннее устройство» больших платформ. Новичкам
стоит быть готовыми к тому, что входной порог здесь выше, чем, например, в веб-
разработ ке. но опыт, полученный в телекоме, очень ценится
Электронная коммерция
Электронная коммерция (E-commerce) — это интернет-магазины, маркетплейсы и
всё, что с ними связано: оплата, доставка, логистика, каталога товаров, акции и
распродажи. В России это один из самых быстро меняющихся сегментов.
Весьма важно здесь то, что разработка напрямую влияет на деньга. Если сайт не
выдержат нагрузку в день распродажи, то компания теряет выручку и прибыль. Ес-
ли интерфейс неудобный, то пользователи просто уходят к конкурентам. Поэтому
много внимания уделяется производительности, отказоустойчивости и пользова-
тельскому опыту (User Experience, UX). Отдельные вызовы появляются в послед-
нее время в связи с тем, что Интернет работает не везде стабильно, и нужно искать
варианты выхода из ситуации.
В e-commerce обычно высокий темп работы. Фичи выкатываются часто, решения
принимаются быстро, приоритеты могут меняться. Это может быть утомительно,
но позволяет быстро увидеть результат своей работы и попробовать увидеть фичу
самому. К тому же такой подход позволяет применить лучшие практики деплоя,
что обычно вызывает живой интерес.
Это направление хорошо подходит новичкам, которые хотят набраться практиче-
ского опыта и не боятся динамичной среды. Полезно сразу учиться понимать, как
технические решения отражаются на бизнесе, а не смотреть на код в отрыве оз ре-
зультата.
*
Игровая индустрия
Геймдев (GameDev, Game Development) — это разработка игр для мобильных уст-
ройств, компьютеров и консолей. Здесь сочетается программирование, работа с
графикой, фишкой, звуком и логикой игрового процесса.
Важно сразу снять иллюзии: работа в игровой индустрии — это не «играть в игры».
Это жесткие сроки, требования к производительности и постоянные компромиссы
Проекты могут закрываться, если игра не показывает нужных показателей, и к это-
му нужно быть готовым.
С другой стороны, геймдев даст уникальный опыт и требует нестандартного мыш-
ления. Здесь важно понимать поведение пользователя, механику взаимодействия и
то, как небольшие изменения влияют на игровой процесс.
Это направление подойдет тем, кто готов совмещать техническую работу с пони-
манием продукта и принимать нестабильность как часть профессии. Ну и надо быть
готовым к тому, что игра не зайдет.
Образовательные технологии
Эдтех (EdTech, Education Technology) — это платформы для онлайн-обучения, сис-
темы управления учебным процессом, курсы, тренажеры, электронные дневники. В
последние годы этот сегмент в России активно развивается.
Основная сложность здесь не столько в технологиях, сколько в понимании поль-
зователей. Аудитория может быть очень разной: школьники, студенты, взрослые
люди без технического бэкграунда. Поэтому важно делать простые и понятные
решения.
Часто в этом сегменте приходится работать с видео, интерактивными заданиями,
аналитикой прогресса обучения При этом требования к надежности ниже, чем в
финте хе или медицине, но ожидания по удобству — выше.
Это направление подойдет гем, кому важно ощущать социальную пользу от своей
работы. Для новичков это хороший вариант, чтобы научиться делать продукты
«для людей», а не только для бизнеса.
Медицинские технологии
Медтех (MedTech, Medical Technology) — это программное обеспечение для поли-
клиник, больниц, лабораторий и медицинского оборудования. Электронные меди-
цинские карты, запись на прием, телемедицина, ПО для диагностических уст-
ройств — всё это относится к области медтеха.
Здесь особенно важно качество. Ошибка в системе может повлиять на решения
врача и здоровье пациента. Поэтому разработка идет по строгим стандартам, с
большим количеством проверок, тестов и документации.
Процессы в медицине часто консервативны, и внедрение новых решений занимает
много времени. Это нужно учитывать и не ждать быстрых результатов.
Такое направление подходит тем, кто готов работать в условиях повышенной от-
ветственности и хочет, чтобы его работа имела реальное влияние на жизнь людей.
Государственный сектор
ПО для государственного сектора— это разработка информационных систем для
органов власти и государственных организаций. Порталы госуслуг, межведомствен-
ные системы, реестры, внутренние платформы — всё это требует 1Т-специалистов.
Здесь много специфики: законы, регламенты, стандарты, требования по использо-
ванию российского программного обеспечения. Разработка редко бывает быстрой,
зато проекты крупные и рассчитаны на миллионы пользователей.
Работа в госсекторе требует терпения и умения работать с документацией. Зато она
дает опыт участия в масштабных национальных проектах и понимание того, как
устроены государственные процессы изнутри.
1.1.3. Куда направиться начинающему специалисту?
В начале карьеры особенно важно выбрать среду, где вы получите не только пер-
вую строчку в резюме, но и реальный опыт. Первый выбор часто задает направле-
ние на годы вперед, и сменить его потом бывает непросто.
Да. на старте нередко хочется просто «попасть в 1Т». Но если есть возможность
выбирать, лучше ориентироваться на собственные интересы и долгосрочные цели.
Специалист, который понимает, зачем он делает продукт и для кого он работает в
российском контексте, почти всегда оказывается более ценным — и для команды, и
для бизнеса.
Импортозамещение
Для тех. кто только начинает свою карьеру в JT, термин «импортозамещение» бу-
дет всплывать постоянно. Честно говоря, я бы советовал нс относиться к нему как к
чему-то абстрактно-политическому. На деле в IT это означает довольно простую
вешь: переход на российский софт. Многим не очевидно, но этот тренд создает для
новичков не проблемы, а возможности.
Ситуация на рынке поменялась радикально Все, от крупных игроков до небольших
компаний, вынуждены были пересмотреть свои стеки технологий. Где-то это бо-
лезненно, да. Но факт в том, что сейчас появляются российские аналоги почти все-
му. что раньше было исключительно зарубежным.
Раньше, когда говорили про отечественное ПО, в голову приходила в основном
«1С» (со своим особенным языком, который не все любят). Сейчас же — смотрите
сами: есть российские ОС, СУБД, CRM, ERP-системы, облака, платежки, продукты
для безопасности и даже свои ИИ-модели, которые понимают контекст на русском.
И это не просто «для галочки» — госсектор, банки и крупный бизнес уже вовсю
внедряют такое За ними подтягиваются и средние компании Так что если вы толь-
ко входите в профессию — есть шанс оказаться у истоков новых, востребованных
технологий.
Что эго значит лично для вас,
начинающего специалиста?
Для новичка нынешняя ситуация в IT скорее открывает возможности, чем создает
проблемы. Пока опытные разработчики тратят время на переучивание и адаптацию
с привычных зарубежных инструментов, у вас есть шанс начать карьеру сразу на
новых российских решениях, без необходимости перестраиваться и ломать старые
привычки.
Российская экосистема развивается очень быстро. Многие продукты, пусть они мо-
лоды. активно догоняют зарубежные аналоги. При этом у них нет «наследия старо-
го софта» — устаревшей архитектуры или накопленнш о технического долга, кото-
рый замедляет работу и усложняет поддержку. На практике это значит, что вы на-
чинаете с чистого листа: архитектура современная, производительность выше,
инструменты удобнее в использовании
Еще один плюс — возможность участвовать в уникальных проектах. Развивая эти
техноло! ии, вы реально становитесь частью построения новой технологической
экосистемы страны. Такие возможности появляются не у каждого поколения IT-
специалистов. поэтому опыт, который вы получите, будет цениться особенно сильно.
Спрос на специалистов, умеющих работать с отечественными продуктами, станет
расти. Пока использование зарубежных решений ограничено санкциями и другими
факторами, компании ищут людей, способных быстро включиться в работу с ло-
кальными инструментами.
Совет новичку
Не зацикливайтесь на изучении одного конкретного продукта. Сосредоточьтесь на
фундаментальных принципах' как работают базы данных, операционные системы,
компьютерные сети. Российские анало!и построены на тех же основах, что и зарубеж-
ные продукты Чем лучше вы понимаете базовые концепции, тем проще будет адап-
тироваться к любому инструменту. В конечном счете, ваша гибкое,ь и прочные знания
станут главным преимуществом в быстро меняющихся условиях.
География
В России основные центры IT — это, как правило, крупные города. Традиционно
лидерами являются Москва, Санкт-Петербург, Казань, Новосибирск и Екатерин-
бург. Если вы планируете строить карьеру в IT, стоит понимать, где сосредоточены
основные возможности.
♦ Москва и Московская область— безусловный лидер рынка. Здесь находятся
штаб-квартиры большинства российских IT-компаний, крупнейшие банки с
серьезными разработками и офисы международных корпораций. При поиске ра-
боты логично рассматривать Москву и область как единый рынок: многие тех-
нопарки и бизнес-иентры, где размешаются компании, расположены именно в
Подмосковье Хороший пример — «Сколково», где базируются стартапы и
крупные IT-компании одновременно.
Для новичка это значит следующее- если вы готовы к переезду или к ежеднев-
ным поездкам, Москва и область дают наибольший выбор вакансий, проектов и
возможностей для развития. При этом стоит учитывать конкуренцию — здесь
много специалистов, и важно заранее продумывать свои навыки и портфолио.
♦ Санкт-Петербург— второй по значимости центр. Здесь очень сильная и разно-
образная среда: от собственных успешных продуктовых команд (часто в сфере
В2В-решений, финтеха и игр) до крупных исследовательских и разработческих
центров (R&D, Research and Development) международных корпораций.
♦ Казань и Иннополис. Иннополис — это специально созданный российский ана-
лог Кремниевой долины, город, расположенный возле Казани (Татарстан). В Ка-
зани также большое количество IT-компаний, сильны позиции в телекоммуни-
кациях, госсекторе и промышленной сфере.
♦ Новосибирск, Екатеринбург. Это крупнейшие академические и промышленные
центры за Уралом В них сильны компании, которые занимаются научно-
исследовательскими работами (R&D), разработкой ПО для промышленности и
аутсорсом.
♦ Другие развивающиеся центры. Нижний Новгород, Красноярск, Томск, Ростов-
на-Дону. Имеют сильные технические вузы и достаточное количество IT-
компаний.
Многие мечтают работать из дома или любой удобной точки. Удаленная работа —
это визитная карточка IT-рынка. Во многих компаниях прижился гибридный фор-
мат, когда часть времени ты проводишь в офисе, а часть — за его пределами.
Однако здесь есть свои нюансы. Многое зависит от политики конкретной компа-
нии. Так, многие разрешают удаленку или гибридный график, но только с террито-
рии России. Если вы планируете работать из другой страны, лучше сразу уточнить,
какой именно формат удаленной работы предполагается
У каждой компании свои причины на такие ограничения. Банковский сектор, на-
пример, ссылается на требования информационной безопасности. Крупные техни-
ческие гиганты обычно склонны ограничивать географию сильнее, чем средние и
мелкие компании. Последним часто просто не хватает ресурсов, чтобы контроли-
ровать, откуда работает каждый сотрудник.
Совет новичку
Начинающему специалисту я не советую сразу стремиться к полностью удаленной
работе Если есть выбор, лучше отдать предпочтение гибридному режиму или даже
работе из осриса Почему? Благодаря присутствию в осрисе вы сможете быстрее по-
знакомиться с «нужными» людьми, оперативно получать помощь и набираться опыта,
участвовать в неформальных обсуждениях (часто именно они приносят неожиданна
много пользы).
По личным наблюдениям, новички, которые чаще бывают в офисе, растут быстрее.
Руководство часто считает таких сотрудников более вовлеченными и тффекгивными.
Кроме того, для некоторых ролей, даже если заявлен удаленный формат, иногда
может потребоваться приехать в офис для решения срочных вопросов
Пример из жизни
Моему другу, который проживал в тот момент в Санкт-Петербурге, как-то пришло при-
мерно такое сообщение от HR: «Сразу хотели бы уточнить момент по формату
работы. Данная позиция предусматривает дистанционный формат с гибридом по
необходимости. Могут возникнуть ситуации, когда необходимо день в день прие-
хать в офис, также присутствие в офисе в течение нескольких дней подряд. Офис
находится в Москве...»
Хотя удаленная работа для IT — это норма, для быстрого старта и роста я рекомен-
дую искать не полностью удаленные варианты. Сначала лучше набраться опыта в
команде, а уж потом, с багажом знаний, можно пробовать переходить на полную
удаленку, если в этом есть необходимость.
Культура
Работа в российском 1Т зависит не только от технологий и структуры компаний, но
и от особой деловой культуры — смеси советского наследия, практичности, а также
новых реалий; кризисов, импортозамещения и стремления к независимости от за-
рубежных технологий.
Российская 1Т-культура— это сочетание двух традиций.
♦ Советское инженерное наследие, для которого характерны:
• жесткие сроки и готовность работать в любое время, чтобы успеть;
• ориентация на то, чтобы программа, которую создают, в первую очередь ра-
ботала, и работала надежно, а не то, чтобы она следовала стандартам и требо-
ваниям;
• уважение к авторитету опытных программистов.
♦ Западный стартап-стиль, который принес:
• гибкие методологии (Agile, Scrum);
• открытость к экспериментам;
• стремление к масштабированию и быстрому росту.
На практике это приводит к следующему.
♦ Гибкие методологии часто превращаются в гибридные подходы, где важно бы-
стро показать работающий результат, а не следовать процессу. Главный прин-
цип «делать быстро и надежно» часто важнее, чем «делать по стандартам».
♦ Приоритет бизнес-требований над техническим совершенством продукт дол-
жен решать проблему здесь и сейчас. При этом менеджеры активно разбираются
в коде и могут прочитать логи и даже понять причину проблемы. А технические
лиды могут вести переговоры с заказчиком.
♦ Готовность к изменениям — требования могут меняться в процессе работы, и
команда должна быстро адаптироваться
♦ Важность неформальных связей — личные отношения в коллективе часто игра-
ют не меньшую роль, чем компетенции.
Сейчас российская IT-культура переживает важный переход. Если раньше i лавным
вопросом было «как адаптироваться и продолжить работу в новых условиях», то
сегодня компании всё чаше думают о том, как создавать решения, которые оста-
нутся востребованными и через годы.
Также происходит изменение с простого импортозамешения на реальные иннова-
ции, то есть российские компании хотят поставлять свои решения за границу: в
страны СНГ, Азию и Африку.
Совет новичку
Гибкость — ключевой навык для всех в том числе для новичков. Требования меняют-
ся. инструменты блокируют, технологии перестают работать. Умение алаптироваться
важнее, чем знание очередной технологии Цените техническую экспертизу, но учи-
тесь работать в команде Будьте готовы к жестким срокам, но не забывайте о качест-
ве. Учитесь доносить свою точку зрения, уважая существующую иерархию.
Теперь, когда общее представление об IT-рынке в России есть, давайте разберемся
с тем, как именно зарабатывают IT-компании и как это повлияет на вашу работу.
Для вашей карьеры ключевое значение будет иметь не только размер компании, но
и принцип ее работы.
1.2. Типы компаний: аутсорс и аутстафф,
продукт, стартап
Существует три основных типа IT-компаний: первый тип — аутсорс и аутстафф (их
также иногда обобщенно называют «галерами»), второй тип — продуктовая разра-
ботка, третий тип — стартап. Нужно четко понимать особенности работы в каждой.
1.2.1. Аутсорс
Происходит от английского «outsourcing». Буквально переводится как «использо-
вание внешнего источника».
Аутсорс-компания — это компания-исполнитель, которая разрабатывает про-
траммное обеспечение для других бизнесов (заказчиков). Вы работаете над проек-
том клиента, а не над продуктом своей компании Результат — сданный проект для
заказчика. Будут ли в нем новые доработки — вопрос, который зависит от заказчика.
Аналогия из жизни
Представьте, что вы — повар в компании, которая готовит на заказ (кейтеринг). Кли-
ент (гость) приходит в вашу компанию и говорит’ «Мне нужен фуршет на 100 человек
пс такому-то меню». Ваша компания подключает вас и еще нескольких ваших коллег
на педготэзку блюда по предоставленному гостем рецепту. Завтра у вас будет новый
клиент с другим меню
Как эю выглядит на практике?
Вы — часть команды, которую «арендовали» для решения конкретной задачи. За-
казчик формулирует требования, а ваша компания разрабатывает это решение. Са-
мо собой, и заказчики, и проекты могут быть разными. Иногда это один постоян-
ный заказчик, а иногда несколько. Крупные компании могут создавать отдельные
организации, и они будут делать продукт только для одного заказчика — это норма.
♦ Плюсы для новичка.
• Разнообразие технологий и задач, но зависит от того, что за заказчик.
• Отлаженный опбординг.
• Стабильность
♦ Минусы.
• Нет возможности повлиять на продукт и предложить лучшее решение
• Риск застрять на неинтересном проекте.
1.2.2. Аутстафф
Не следует путать аутсорс и аутстафф (outstaff). Аутстафф означает, что компа-
ния-заказчик временно «арендует» вас у вашей IT-компании, чтобы вы работали
внутри его команды (команды заказчика, а не вашей!) над проектами заказчика.
Аналогия из жизни
Представьте, что вы — повар в компании, которая занимается аутстаффом Заказчик
приходит н вашу компанию и говорит: «Мне нужен на 6 месяцев повар-универсал для
работы в ресторан азиатской кухни». Ваша компания передает вас в ресторан заказ-
чика. и вы работаете в ресторане на условиях компании.
Ваш работодатель продает рабочее время и экспертизу специалиста Например, за-
казчик говорит: «Нам нужен на полгода один middle-разработчик со знанием Java».
В отличие от аутсорса, процессом управляет компания-зака зчик Ее менеджеры
ставят вам задачи, проводят ежедневные стендапы, код смотрят разработчики за-
казчика и интегрируют вас в свои процессы
Ваша компания несет ответственность за вашу зарплату', налоги и юридические
формальности. А за результат работы от вечаете вы перед заказчиком.
♦ Плюсы для новичка.
• Погружение в культуру и процессы реальной компании Вы работаете внутри
команды заказчика, которая уже имеет отлаженные процессы.
• Прямое обучение у опытной команды. Вы будете работать с командой заказ-
чика. Это бесценный опыт.
• Узкая специализация и глубокое погружение. В отличие от аутсорса, где про-
екты могут меняться, в аутстаффе вы обычно долго работаете над одним про-
дуктом.
• Возможность получить предложение в компании-заказчика. Для некоторых
компаний аугстафф — способ «присмотреться» к специалисту перед тем, как
предложить ему оффер.
♦ Минусы.
• Сложность адаптации. Вы оказываетесь «чужим среди своих». Команда, если
в ней нет других аутстафф-специатистов, не будет видеть смысла в обучении.
• Ограниченность поддержки. Ваша родная аутсгафф-компания может быть
далека от задач заказчика (так обычно и бывает). Сотрудники компании-
заказчика не будут вам помогать или будут делать это без желания, т. к. они
знают, что вы здесь временно.
• Риск «вечного времен шика». Новичок в аутстаффе рискует надолго застрять
в роли «временного сотрудника» без перехода в команду1 на постоянных ус-
ловиях. Как следствие — эт о отсутствие карьерных перспектив.
Совет новичку
Аугстафф — возможность прыгнуть выше своей головы, но это требуег высокой са-
мостоятельности и быстрой обучаемости. Если вам нужна поддержка и постепенное
развитие — лучше начать с классического эутсорса или продуктовой компании Если
ваша работа не устроит заказчика, то никто не будет церемониться, и вас попросят
заменить другим специалистом.
Итог: аутсорс vs аугстафф
Начинающему специалисту чаще всего проще стартовать в аутсорсе, где есть своя
внутренняя поддержка, онбординг и помощь коллег. Аугстафф требует большей
самостоятельности и умения быстро наладить работу в уже сработавшем коллекти-
ве, что может быть сложным на старте карьеры.
1.2.3. Продуктовые компании
Продуктовые компании развивают собственный IT-продукт. Вы работаете над про-
дуктом, который принадлежит вашей компании.
Аналогия из жизни
Представьте, что вы — повар в ресторане. Вы готовите блюда по постоянному меню,
а не на заказ Вы работаете над улучшением одних и тех же блюд, чтобы гости воз-
вращались к вам снова и снова Вы видите, как ваша работа напрямую влияет на по-
пулярность заведения.
Вы — часть команды, которая реализует какой-то продукт. Это может быть об-
лачное решение или программа, устанавливаемая на мобильный телефон. Важно,
что это продукт, который создаете именно ваша команда и вы. Команда сама ре-
шает, что и как улучшать в продукте, основываясь на данных и потребностях
пользователей.
Вы видит е долгосрочный результат своей работы.
♦ Плюсы для новичка.
• Глубокое погружение в ту предметную область, с которой работаете,
• Чувс гео причастности вы видите результат своей работы.
• Фокус на качестве — компания играет вдолгую, ошибки никому не нужны.
♦ Минусы.
• Меньшее разнообразие технологий. Если есть какой-го стек, го вы будете ра-
ботать именно на нем.
• Риск остаться специалистом в одной области. Если вы хорошо работаете, то
вы можете работать так до бесконечности, пока продукт развивается.
Совет новичку
Если вам предложили работать над продуктом, которым вы сами пользуетесь или ко-
торый вам искренне интересен — смело соглашайтесь Вам повезло вы не просто бу-
дете выполнять задачи, а сможете влиять на то, что действительно цените. Это ред-
кий шанс совместить работу с личной увлеченностью, когда даже рутинные задачи
будут наполнены смыслом.
1.2.4. Стартап
Это молодая компания, которая ищет работающую бизнес-модель или новое риско-
ванное направление внутри крупной компании. Главная цель стартапа - быстро
проверить гипотезу и «выстрелить» на рынке.
Стартапы бывают двух видов:
♦ независимые — классические молодые компании,
♦ внутрикорпоративные— отдельные специально созданные команды внутри
других компаний (не обязательно крупных, но устойчивых), которые работают
по стартап-методологиям, но с поддержкой «большого брата»
Аналогия из жизни (отдельная компания)
Вас позвали работать в новый фудтрак. Денег на опытных профессионалов нет, по-
этому вы— и повар, и кассир, и маркетолог Вы постоянно экспериментируете с ре-
цептами, а владелец тратит все силы на поиск инвесторов. Работаете за троих, но ес-
ли повезет — получите бесце нный опыт и карьерный рост
Аналогия из жизни (отдельная команда устойчивой компании)
Вы — пекарь, которою наняли в новый экспериментальный проект крупной сети рес-
торанов Сеть решила протестировать формат мини-кондитерских, и вас взяли в экс-
перимент. У вас есть поддержка бренда и ресурсы компании, но работаете вь в ав-
ральном режиме, как стартап: сами придумываете рецепты, украшаете торты, стоите у
плиты и даже помогаете думать над названием. Проект могут закрыть через полгода,
если он не окупится, но если «выстрелит», то вы станете ключевым специалистом в
быстрорастущем направлении
На практике в стартапах роли часто смешаны, а обязанности определяются по обста-
новке. Высокая скорость, постоянные эксперименты и готовность к резким измене-
ниям. Минимум бюрократии, но максимум личной ответственности за результат.
♦ Плюсы для новичка.
• Богатый опыт. За год вы получите опыт, который в крупной компании растя-
нулся бы на три.
• Реальное влияние. Ваши идеи и действия напрямую влияют на продукт и ус-
пех компании
• Возможность быстрого карьерного роста. Если стартап выстрелит, то есть все
шансы, что вас это коснется, и вы займете топовую должность в новой ком-
пании.
♦ Минусы.
• Ответственность. Приходится сразу брать на себя сложные задачи и нести за
них ответственность. Для новичка это сложно.
• Высокий риск. Большинство стартапов закрываются в первые несколько лет.
• Нестабильность. Могут быть переработки, стресс из-за смены приоритетов и
неопределенности.
• Выгорание. Высокие нагрузки и постоянное напряжение могут быстро исто-
щить сипы.
• Низкое качество. Сил и средств делать качественные решения в стартапе нет,
поэтому если всё удастся, то позже вы будете разгребать эти проблемы.
Совет новичку
Если вас зовут в стартап — обязательно уточните, независимый он или знутрикорпо-
рагивный. В независимом зы получите максимум свободы и ответственности, но будь-
те готовы к нестабильности Вчутрикорпопативный стартап — это лучшие условия Вы
будете эаботать в режиме с экспериментами, но, возможна не с авралом Зарплата
и ресурсы у вас будут как в большой компании. Идеально для первого знакомства
с IT -культурой без экстремальных рисков Но будьте готовы к тому, что если стартап
внутри компании стрельнет, то место руководителя займет ставленник сверху.
1.3. Как зарабатывают IT-компании:
модели монетизации ПО и особенности работы в России
Существует несколько вариантов того, как можно заработать на продукте. Но пре-
жде чем перейти к рассказу о том, какие бывают варианты монетизации, опишу',
зачем вообще в этом разбираться, тем более новичку.
Основные причины знать, как компания зарабатывает:
♦ Понимание приоритетов в работе. Одни модели заработка предполагают фокус
на качестве продукта, а другие — на соблюдении жестких сроков и ТЗ.
♦ Возможность быть ближе к бизнесу и разговаривать с ним на одном языке. Если
вы понимаете, как компания зарабатывает деньги, вы становитесь более ценным
сотрудником для представителей бизнеса, которые далеки от IT, а значит, и для
всей компании в целом. Вас будут больше ценить.
♦ Понимание монетизации помогает выбрать ту компанию, где вам будет ком-
фортно и интересно развиваться. Кому-то нужны стабильность и спокойствие, а
кому-то — технические вызовы.
♦ Важно понимание российской специфики. Предлагать внедрять новые модели
монетизации нужно аккуратно, часто заказчики к ним не всегда готовы. Как
следствие, можно будет адекватно реагировать на требования рынка и строить
продукт, за который будут платить, а не откажутся.
1.3.1. Аутсорс и аутстафф
Аутстафф и аутсорс — это, конечно, не модели продажи продукта, а модели зара-
ботка денет вашей компании Но я не могу про них не рассказать, пегому что выбор
такой компании значительно влияет на ответственность сотрудника.
При аутсорс-разработке компания зарабатывает на реализации готового проекта (то
есть на результате работы), а при аутстаффе — на предоставлении рабочего време-
ни конкретных специалистов (то есть на самом процессе работы).
♦ При аутсорсе.
Если команда закрыла проект быстро, то компания получает высокую прибыль. Ес-
ли проект затянулся, то компания теряет деньги, т. к. обычно фиксируется цена за
весь объем работ по проекту. Как следствие, качество может страдать, зато бывают
частые смены проектов. Часто (но не всегда) работает схема «сделал и забыл». Для
новичка также важно понимать, что работа осущесгвляется внутри своей команды,
задачи ставит ваш тимлид, вы меньше общаетесь с заказчиком напрямую.
♦ При аутстаффе.
Компания зарабатывает на разнице между зарплатой программиста и ставкой,
которую платит клиент за час его работы. Например, компания платит вам 1000
рублей в час. а «сдает в аренду» за 3000 рублей. Разница в 2000 рублей идет на
налоги, больничные, отпуска, офис, зарплату менеджерам и прибыль компании.
Для компаний, которые предоставляют аутстафф, — это более предсказуемый
бизнес, т. к риски за результат проекта несет заказчик Пока сотрудник нахо-
дится на проекте, компания получает доход. Для новичка тут важно понимать,
чго вы юридически числитесь в одной компании, но работаете в процессах и ко-
манде заказчика. Это отличный способ посмотреть, как устроены другие компании.
1.3.2. Разовый платеж
Самый давний вариант решений — это модель разовой покупки, когда можно од-
нократно купить лицензию на продукт и пользоваться продуктом сколь угодно долго.
Примеры продуктов
Microsoft Windows, Microsoft Office, Adobe Photoshop, AutoCad — это список продуктов,
за которые можно было заплатить один раз и пользоваться ими бесконечно долго.
Важн отметить, что бесплатные обновления в этой модели почти всегда касались
только обновлений безопасности и исправления ошибок (минорные версии, service
packs). Получение новых функций и мажорных версий (например, переход с Office
2010 на Office 2013) чаще всего требовало новой покупки.
Следует сказать что с развитием облачных сервисов (то есть тех, с которыми мож-
но работать удаленно через Интернет) такая модель становится всё менее популяр-
ной. Причины две:
♦ постоянные расходы вендора (разработчика).
Вычислительные ресурсы, которые нужны для работы продукта, поддержки и
развития, — это постоянные статьи расходов. Разовый платеж не покрывает их в
долгосрочной перспективе;
♦ слабая предсказуемость доходов.
Для компании-разработчика разовые платежи не создают стабильный, предска-
зуемый денежный поток. Сложнее планировать бюджеты, содержать штат со-
трудников и параллельно развивать продукт.
Теоретически возможен вариант, когда продукт работает на инфраструктуре клиен-
та (on premise), но на практике чаще подобные решения являются либо desktop-
приложениями (программы, которые устанавливаются на компьютер и работают
непосредственно на нем, используя ресурсы компьютера), либо решениями с от-
крытым исходным кодом (open source).
Не следует думать, что модель с разовым платежом умерла. Существует достаточ-
ное количество продуктов, которые можно купить навечно.
Пример из жизни
Современные сервисы видеоигр (например, Steam), фильмов (Кинопоиск. Окно Иви)
позволяют купить конкретный контент (например, игру или фильм), и она будет у вас
«навечно» (пока существует сам сервис).
Существуют также «антиподписочиые» продукты (Affinity Photo или DaVinci Resolve),
которые говорят о своем конкурентном преимуществе, но в России они пока являются
редкостью.
Совет новичку
Если вы пришли в компанию с такой моделью, как «разовый платеж», одним из пер-
вых вопросов задайте: «По какой схеме мы выпускаем обновления? Что получают
текущие пользователи бесплатно, а за что им придется платить снова?» Разбе-
ритесь. чего от вас ждут работодатели и заказчики
Доля компаний с доходом только от разовых платежей постепенно уменьшается.
Многие новые доработки, которые выходят в продукте, уже приобретаются за пла-
ту Таким образом, при создании новых задач вы можете отделять бесплатный ба-
зовый минимум (например, законодательные изменения), который получат все, и
дополнительные платные опции (например, по подписке можно получить фичи,
снижающие затраты заказчика).
1.3.3. Подписка
Оплата по подписке предполагает периодические выплаты за определенный интер-
вал времени, но с учетом определенных ограничений.
Ограничения по количеству пользователей
Два основных варианта. Первый — оплата за каждого пользователя каждый поль-
зователь оплачивается отдельно Второй — оплата пользователей по вилкам, когда,
например, установлены вилки по тарифам: start — до 10 пользователей, start plus —
до 20 пользователей, business — до 50 пользователей и гак далее.
Существуют различные модификации: оплата только активных пользователей
(плата за тех, кто пользовался), разные тарифы для разных ролей (обычные пользо-
ватели и гости).
Ограничения по объему использования
Под объемом в таком случае предполагается определенная функциональность —
например, количество обращений к API, время работы вычислительных ресурсов,
количество отправляемых сообщений, количество обработанных видео, фото, аудио,
объем хранимых данных. Го есть это привязка к той функциональности, которую
предоставляет сервис.
Вот один из вариантов тарификации — может предоставляться определенный ли-
мит количества операций- например, не более 10 тыс. запросов к API в месяц, не
более 1000 обработанных видео. При превышении установленного лимита оплата
осуществляется за каждую
Примеры из жизни
• Оплата за каждого пользователя: Microsoft 365, Google Workspace — классический
вариант подписки, когда стоимость подписки умножается на количество пользова-
телей.
• Оплата по вилкам. Zoom Тариф «Рго» — до 1 организатора встречи, «Business» —
до 10, «Enterprise» — от 50 и более
• Сервисы рассылок в мессенджерах (ManyChai, SendPulse). Тарифы строго привя-
заны к количеству подписчиков/контакгов (например, до 500, до 1500, до 10 000).
Совет новичку
На то, продлит ли клиент подписку или нет, влияет качество и сравнение с конкурен-
тами. Даже если вы технический специалист, то должны сразу думать о том, как удер-
жать клиента, сохранив его подписку Каждая задача, которую вы делаете, должна и
конечном итоге помогать клиентам видеть ценность сервиса и продлевать подписку.
Ваша главная цель— не просто «сделать фичу», а сделать так. чтобы она была не
хуже, чем у конкурентов а еще лучше, чтобы была только у вас. Поэтому всегда зада-
вайте себе и команде два вопроса: «Как эго повлияет на текущих пользователей?» и
«Как это позволит привлечь новых?».
1.3.4. Оплата по факту использования
Некоторые SaaS-сервисы (Software as a Service, «программное обеспечение как ус-
луга») в силу своей специфики не могут работать по подписке с авансовой систе-
мой оплаты Поэтому используется альтернативный вариант — оплата за использо-
ванные ресурсы (pay as you go, PAYG). Такая схема наиболее популярна в серви-
сах, у которых нагрузка может быть непостоянна. Многие облачные сервисы,
предоставляющие вычислительные мощности, работают именно по такой схеме
Вот примеры решений, которые часто используют модель оплаты по факту исполь-
зования:
♦ переменные ресурсы в облачных сервисах — оплата обычно по времени работы
определенного ресурса;
♦ работа с функциями как сервис (FaaS, Function as a Service) — оплата по количе-
ству ресурсов, потребленных функцией;
♦ количество отправленных сообщений или писем;
♦ количество совершенных транзакций;
♦ количество показанных рекламных сообщений;
♦ количество обращений к API (Application Programming Interface, прикладной
программный интерфейс): API поиска. API географических карт
Могут быть установлены разные тарифы по вилкам: чем больше потребление, тем
дешевле выходит один запрос. Например, до 1000 запросов каждый оплачивается
по одной цене, от 1 000 до 2000 — оплата по более низкой.
Примеры из жизни
• Количество обращений к API. OpenAI (ChatGPT API). Google Maps API, Amazon AWS
API Gateway. Иногда доступен лимит (в день, в месяц), остальное — за доплату.
• Время оаботы вычислительных ресурсов. Amazon ЕС2. Google Ooud Compute
Engine, Microsoft Azure Virtual Machines. Оплата за каждую единицу времени (се-
кунду), когда ресурсы используются.
• Объем хранимых данных Google Drive, Яндекс Диск, Mail. Бесплатно предоставля-
ется ограниченный объем (несколько Гбайт), за дополнительный объем нужно до-
плачивать.
Совет новичку
Вам нужно думать об оптимизации запросов То есть каждый лишний запрос (секунда,
гигабайт) будет прямыми расходами клиента. Ваша задача — написать не просто ра-
ботающий код. а написать максимально эффективный работающий код Всё неопти-
мальное будет стоить денег либо клиенту (что ухудшит его опыт), либо вашей компа-
нии (съедая маржу). Это особенно актуально в российских реалиях, где цена на об-
лачные ресурсы может быть высокой Всегда задавайтесь вопросом: «Можно ли
решить эту же задачу более оптимально сохранив качество?»
1.3.5. Фримиум
Еще одной достаточно интересной моделью монетизации (особенно для компаний)
является фримиум-модель (freemium). Ее суть сводится к тому, чтобы показать воз-
можности продукта или мотивировать начать им пользоваться, но добавить опре-
деленные ограничения, которые бы «мешали». Затем уже предложить купить ре-
шение без указанных ограничений.
Могут быть следующие варианты ограничений:
♦ Количество сотрудников, которые могут пользоваться совместным проектом.
Некоторые компании-вендоры позволяют небольшим компаниям-разработчикам
бесплатно пользоваться своим SaaS-продуктом с расчетом на го, что переходить
на другую платформу7 никто не будет. Многие системы работы с кодом построе-
ны по этому принципу — стартапы не несут затрат, но пользуются такими ре-
шениями.
♦ Ограничения в функциональности продукта.
При этом доступны не все его возможности. Кроме того, здесь часто ограничи-
вают работу интеграции, расширенной аналитики. Что и как именно ограничи-
вать. решает сам вендор.
♦ Ограничения на количество функциональности.
То есть пользоваться можно всем (или почти всем), но очень охраниченнос ко-
личество раз. Далее — можно перейти на модель с оплатой, например, за факти-
ческое потребление.
♦ Ограничение на объем данных.
Возможный вариант, который вынуждает пользователя постоянно думать о том,
как сэкономить место.
♦ Ограничение на скорость обработки
Для сервисов, в которых скорость обработки достаточно велика (например,
видео), вводятся отраничения на то, сколько времени будут обрабатываться
данные.
♦ Ограничение на уровень поддержки,
Например, для бесплатной версии доступны только публичные материалы, а для
платной — прямые каналы связи.
Существуют и другие ограничения — опять же. все зависит от продукта и страте-
гии продвижения.
Примеры из жизни
• Spotify: Бесплатная версия есть, но с рекламой, ограниченным количеством про-
пусков треков и без возможности скачивания музыки Платный план убирает все
эти ограничения.
• VK музыка Возможность слушать музыку на мобильном приложении только с
включенным экраном.
Совет новичку
Нужно все время балансировать на грани бесплатные функции должны быть полез-
ны, но неудобны, вызывать легкое недовольство, но не отторжение Вы должны четко
понимать, какие именно ограничения (лимиты пользователей, функциональность, ско-
рость) заставляют пользователя задуматься об оплате, но не мешают новичку протес-
тировать продукт и захотеть его купить Каждая задача должна оцениваться с двух
сторон: «Как это улучшит опыт для пользователей, которые не платят?» и «Усилит ли
эго ценность платного тарифа, чтобы они перешли?» Также важно следить за кон-
версией: сколько бесплатных перешли в платные Нужно помнить, что успех измеря-
ется не количеством бесплатных пользователей, а тем, сколько из них вы сможете
превратить в тех, кто плэтит
1.3.6. Особенности российского рынка
и российского менталитета
В России пользователи и компании (особенно в В2В) привыкли к долгим согласо-
ваниям и задержкам платежей. Это означает, что в финансовую модель сразу нуж-
но закладывать длинный никл продаж и выстраивать процессы напоминаний о том,
что скоро предстоит платеж. Более того, надо заложить и механизмы продления на
короткий срок лицензии. В обязательном порядке следует сразу закладывать меха-
низмы ограничений при истечении периода подписки. Помните, что любой бизнес
не будет платить, если у вас не будут работать граничения. Если клиент сможет
легко их обойти, то он обойдет.
При этом готовность платить за софт у нас в среднем ниже, чем на Запале Ожида-
ние «халявы» и возможность получить решение без оплаты — это то, с чем прихо-
дится сталкиваться каждый день. Модель Freemium может хорошо работать для
привлечения, но конвертация в пользователей, которые платят, часто низкая.
Пример из жизни
У нас был крупный клиент, который требовал сделать интеграцию нашего продукта с
его уникальной системой. Он активно настаивал на том, что это не просто его хотелка,
а стратегически важное улучшение для всего нашего продукта, и грозил уйти к конку-
рентам, если мы не сделаем это бесплатно «в рамках продуктового развития».
Мы проанализировали ситуацию и увидели, что система у него действительно уни-
кальная, но кроме него она никому не нужна Однако клиент продолжал доказывать,
что «это же так ценно для продукта»
В итоге мы не поддались и предложили сделать интеграцию как платный кастомный
проект Клиент ворчал, но согласился платить,— потому что реальная ценность на-
шего продукта для него оказалась выше, чем затраты на эту доработку
И в этом вся Россия: каждый клиент считает, что его узкоспециальная потребность
является нормой для всего рынка, и пытается получить кастомную разработку за
счет вендора. Важно уметь отличать такие ситуации от действительно полезных
улучшений.
1.4. Карьерные пути для разных ролей
Вы уже знаете, что компании бывают разными Но не менее важен выбор вашей
роли в команде. Карьера в IT редко когда строится по строгому плану. Чаше это
набор возможностей (иногда возникающих в самые неожиданные моменты), в ко-
торых можно двигаться в разные стороны, пробовать новые роли и менять специа-
.тизацию по мере опыта.
1.4.1. Роли и обязанности:
что важно понимать в России
Особенно важно понимать, что в российских компаниях название должности не
веет да совпадает' с реальными обязанностями. Поэтому, прежде чем соглашаться
на вакансию, стоит тщательно разобраться, чем именно придется заниматься на
практике.
Например, владелец продукта в одной компании может ограничиваться сбором тре-
бований и аналитикой, а в другой — фактически принимать ключевые решения по
продукту. Тимлид где-то больше руководит командой, а где-то продолжает активно
писать код. Аналитик в разных организациях может заниматься исследованием дан-
ных, составлением технических заданий или напрямую общаться с таказчиками.
Совет новичку
Не полагайтесь только на название должности. Читайте описание вакансии внима-
тельно и обязательно уточняйте на собеседовании, какие задачи вам предстоит ре-
шать и за что будете отвечать. Это поможет избежать недопониманий и выбрать ра-
боту, которая реально соответствует вашим ожиданиям.
1.4.2. Технический путь
Это путь углубления в технологии. Условная последовательность выглядит так:
♦ junior (1-2 года)— выполнение задач под руководством наставника или само-
стоятельное решение простых задач,
♦ middle (2-4 года) — самостоятельное решение большинства задач в проекте;
♦ senior (4+ лет) — решение задач любой сложности.
Сроки носят очень примерный характер. В России скорость роста сильно зависит
от компании: в стартапах можно стать senior за 3 года, а в крупных корпорациях
этот путь может занять больше времени. Кроме того, многое зависит и от руково-
дителя, и от плана развития
Но опыт не всегда переводится в следующий грейд. Можно остаться middle и через
10 лет. Senior— это тот, кто помогает достигать цели бизнеса, а не просто решает
одну задачу за другой. Но стать senior, не имея достаточного опыта, нельзя, требу-
ется время для того, чтобы стать хорошим техническим специалистом.
Совет новичку
Не пытайтесь сразу прыгнуть с уровня junior до senior: коллеги будут считать вас во|-
скочкой, а руководители — непрофессионалом Так можно закончить карьеру в компа-
нии раньше, чем хотелось.
1.4.3. Нетехнический путь
Это путь углубления в бизнес-процессы, коммуникацию и управление-
♦ аналитик: от сбора требований к управлению продуктом, а в перспективе — к
роли владельца продукта;
♦ менеджер проектов: от контроля сроков к стратегии развития;
♦ дизайнер; от создания интерфейсов к проектированию пользовательского опыта
1.4.4. Смена специализации и новые возможности
В российской 1Т-среде смена ролей — достаточно распространенная практика На-
пример
♦ тестировщик-автоматизатор может стать разработчиком, если применяется тот
же стек;
♦ тестировщик-ручник может стать аналитиком;
♦ разработчики реже меняют профессию кардинально, но их технический бэкгра-
унд становится огромным преимуществом при переходе в другие роли;
♦ технический специалист может стать тестировщиком.
Такой путь требует дополнительною обучения, но часто приводит к успеху, по-
скольку совмещает техническое понимание с новыми компетенциями. Кроме того,
много зависит от раскрывшихся талантов.
Совет новичку
Если вы устали от своей текущей роли, то поставьте себе четкую, но достижимую
цель — стать конкретным специалисгом. Чем четче вы сформулируете свое желание,
тем быстрее достигнете цели. Само собой, цель должна быть достижима.
1.4.5. Что влияет на карьерный рост в России?
Тип компании
♦ В больших компаниях рост может достаточно легко проходить внутри специа-
лизации (пусть от junior до senior), т. к. обычно предусмотрена регулярная оцен-
ка и понятный путь развития. Большим компаниям часто есть что предложить в
соседней команде.
♦ Средние компании предлагают стабильность, но рост может быть достаточно
медленным, особенно на новые и интересные позиции, т к. количество ролей в
команде ограничено. Зато часто возможна смена специализации. Самое главное —
об этом явно говорить.
♦ Стартапы дают больше возможностей для быстрого развития, но тут грейд мо-
жет быть очень условным. А специализация — меняться не потому, что хочется
развития, а потому что «надо».
Личная активность
Скажу достаточно очевидные вещи, но именно они позволяют строить карьеру.
♦ Нужно регулярно обучаться. Технологиям, практикам, подходам. Не делайте
акцент только на технику, сейчас очень важны нетехнические навыки. Даже для
разработчика.
♦ Важно участие в разных проектах и задачах. Если предлагают что-то новое, то
пробуйте.
♦ Постарайтесь выстраивать профессиональные отношения не только со специа-
листами своей области, но и с другими. Специалисты, которые понимают, как их
работа влияет на бизнес-результат, ценятся выше.
♦ Как я уже говорил: ставьте четкие цели на пути своего развития.
О законах карьеры: принципы Питера, Дилберта и Путта
При построении карьеры полезно знать несколько наблюдаемых закономерностей.
Это знание поможет принимать более осознанные решения и избежать типичных
ошибок.
♦ Принцип Питера является общим фундаментальным принципом, который гово-
рит о том, что сотрудники продвигаются по карьерной лестнице до уровня своей
некомпетентности. По сути это значит, что сотрудника продвигают до тех пор,
пока он не перестанет справляться со своими обязанностями. Так сотрудник и
остается на своей должности, потому что обычно никого нс понижают, а повы-
шать уже нельзя, поскольку он и так не справляется.
♦ Принцип Дилберта — это сатирический принцип, который говорит о том, что
наименее компетентных сотрудников повышают намеренно, для того чтобы от-
странить их от текущей операционной работы, с которой они не очень хорошо
справляются. В новой роли их вред будет наименее очевиден.
♦ Закон Путта — это уже технический закон, который применим в том числе к
IT-сфере, но не обязательно. В нем говорится о том, что техническая компетен-
ция обратно пропорциональна продвижению по карьерной лестнице в управлен-
ческой иерархии. То есть классный инженер вряд ли будет продвинут до высо-
кого менеджера Никому не хочется терять крутого технического специалиста,
потому что он хорошо справляется со своей работой, а руководитель из него
может и не получиться. Поэтому так и происходит, что со временем технические
отделы возглавляют люди, которые могут быть далеки от техники.
В целом, это не так и плохо, потому что для блестящего управленца нужны со-
вершенно другие навыки, чем для высококлассного инженера.
Практические выводы для новичка
♦ Осознанно выбирайте путь развития.
• Техническая экспертиза и управление — это разные карьерные треки.
• Честно оценивайте свои сильные стороны вам нравится noipyжаться в код
или организовывать работу команды?
♦ Готовьтесь к новой роли заранее.
• Не ждите повышения, чтобы начать развивать управленческие навыки.
• Участвуйте в обучении, берите на себя ответственность за часть проекта,
учитесь делегировать.
♦ Не стремитесь к росту «любой ценой».
• Карьера — это не только движение вверх, но и углубление экспертизы.
• Можно оставаться senior-разработчиком 10 лет и быть чрезвычайно ценным
специалистом.
♦ Анализируйте окружение.
• Наблюдайте, по каким принципам строится карьера в вашей компании.
• Это поможет понять, какие навыки действительно ценятся и куда развиваться.
Самое важное в построении карьеры — это готовность регулярно пересматривать
свои цели и открывать в себе новые стороны.
Возможно, вы начинали как инженер, но со временем обнаружили, что вам инте-
реснее не только развивать технические навыки, но и организовывать работу ко-
манды. видеть общую картину продукта и взаимодействовать с людьми. И это не
«измена» профессии, а естественное развитие.
- Глава 2-
Роли в команде
В этой главе мы будем говорить о ролях в 1Т-команде. Синонимами термина
«роль» являются «позиция» или «должность». Можно по-разному подходить к опи-
санию ролей, но я разделю их на три категории: продуктовые, технические и вспо-
могательные. И про каждую категорию ролей мы поговорим отдельно.
2.1. Продуктовые роли:
менеджер, аналитик, дизайнер
Продуктовые роли отвечают за продукт. То есть за то, что нужно пользователям от
продукта. Основное, что должно быть у продуктовых ролей, — это понимание
рынка и пользователей на этом рынке. Те, кто входит в продуктовую команду,
должны сделать так, чтобы пользователи хотели его купить: за качество, эффектив-
ность, скорость, вау-фичи и, возможно, за бренд. Те, кто входят в продуктовые роли,
занимаются тем, что анализируют конкурентов, чтобы не упустить что-то ценное.
Совет новичку
Если вы технический специалист, то не надо делиться с сотрудниками продуктовых
ролей всеми своими мыслями про технику, — в лучшем случае они подумают, что вы
зануда, в худшем — скажут, что не умеете работать в команде
Основные роли, которые входят в продуктовую команду:
♦ Менеджер — это ключевая роль, отвечающая за успех продукта. В разных ком-
паниях его обязанности могут распределяться стратегически (менеджер по про-
дукту) и т актически (владелец продукта). В некоторых компаниях есть тимлид.
♦ Тимлид (TL, Team Lead) — менеджер команды, который отвечает за результат ее
работы
Тимлид — одна из самых важных ролей в разработке ПО. Вы будете постоянно
слышать: «Тимлид не разрешил», «А ты спросил у тимлида?». Именно тимлид
отвечает за команду и за ее результат. Команда должна работать максимально
эффективно (то есть не переделывать уже сделанное), быть мотивирована на ре-
зультат (го есть попадать в оценки и не давать завышенные оценки) и достигать
поставленных задач (выполнять их в срок согласно требованиям). Тимлид — это
роль, которая находится где-то между продуктовой и технической командой, и
отвечает за следующие направления:
• подбор команды, адаптация и оценка, наставничество и развитие сотрудников,
мотивация и удержание — да, это всё задачи, за которые отвечает тимлид;
• управление задачами и коммуникациями, улучшение процессов и решение
конфликт ов, управление рисками — это тоже задачи тимлида;
• тимлид — и технический специалист, и, часто, senior-разработчик. Поэтому
качество результата, решение технических проблем, работа над техническим
долгом — это в том числе также задачи, которые решает тимлид;
• тимлид отвечает и за то, чтобы результат команды был максимальным. То
есть благодаря знанию технологии и умению общаться с людьми и помогать
своей команде тимлид должен приводить к наилучшему результату.
Тимлиду нужны хорошие технические (hard skills) и софтовые навыки (soft
skills). Первые (технические) — для того чтобы понимать процессы разработки
и архитектуру продукта, технологии разработки. Чтобы общаться с командой на
одном языке Вторые (софтовые) — чтобы взаимодействовать с сотрудниками
команды для достижения наилучшего результата.
Для новичка тимлид — главный после наставника в команде. Он поможет разо-
браться в процессах, подскажет путь развития и решит возникающие проблемы.
Не стесняйтесь обращаться к нему с вопросами, но старайтесь формулировать
их четко и заранее. Обычно тимлиды открыты к диалогу, но очень заняты.
Тимлиды не отвечают за го. зачем нужна фича. Поэтому, если у вас вопрос
именно по логике самой фичи, — например, вы не понимаете того, что от вас
хотят, то стоит идти продуктовому менеджеру или к владельцу продукта.
♦ Продуктовый менеджер (PM. Product Manager) — отвечает за стратегию раз-
вития продукта и его видение (vision), метрики продукта и окупаемость инвести-
ций в продукт. В целом именно РМ определяет, что делать в продукте, а что нет.
И он же несет ответственность за эти решения. РМ общается с бизнесом и кли-
ентами. РМ мыслит глобально, а не детально: нужна ли эта фича в продукте или
без нее можно обойтись Роль продуктового менеджера (РМ) часто отсутствует,
особенно в молодых компаниях и стартапах. Роль РМ может также отсутство-
вать, если команда работает по чистому Scruin, т. к. роль РМ в нем не преду-
смотрена (методология Scrum описана в главе 6).
♦ Владелец продукта (РО, Product Owner) — отвечает за реализацию и соблюде-
ние бэклога1 (тактика). Именно он взаимодействует с командой разработки и
конкретными задачами в бэклоге, управляет приоритетами в релизе и следит за
соблюдением сроков реализации и соблюдением требований Общается с ко-
мандой разработки Product Owner — это роль из Scrum. К РО надо идти, когда
нужно разобраться в деталях конкретной задачи.
1 Бэклог (от англ, backlog, невыполненная работа) — список задач, требований, функций, улучшений
и других компонентов, которые нужны для разработки конкретного продукта
В серьезных (больших) компаниях есть и владелец продукта, и продуктовый ме-
неджер.
Совет новичку
Если вы только начинаете карьеру в IT, понаблюдайте, как в вашей компании распре-
делены роли РМ и РО Это поможет понять, куда развиваться: в страте!ическое
управление продуктом (РМ) или в тактическую работу с командой (РО)
♦ Аналитик (Analyst)— детально прорабатывает требования. В зависимости от
специализации может выполнять разные функции, бизнес-анализа и системного
анализа.
♦ Бизнес-аналитик (Business Analyst, ВА) отвечает на вопросы «Что?» и «Для ко-
го?»— выявляет потребности пользователей и бизнеса, формулирует цели и
ценности будущей функциональности.
♦ Системный аналитик (Systems Analyst, SA) решает, как технически реализовать
требования: участвует в формировании технических требований, продумывает
интеграции и ограничения.
Аналогия из жизни
Владелец ресторана (он выступает в лице заказчика) высказывает требования о том,
какой н хочет о।крыть ресторан в новой концепции: «Я хочу открыть модное кафе
для молодежи, в котором можно будет насладиться самым лучшим кофе и свежей вы-
печкой»
Задача именно бизнес-аналитика — выяснить, что такое «модное» кафе, что такое
«лучшее кофе», уточнить, свежая выпечка — это привезенная или испеченная на мес-
те. Результат работы бизнес-аналитика — это меню, включая напитки, цена, описание
дизайна и составленная картина целевой аудитории Всё это бизнес-аналитик согла-
сует с заказчиком Бизнес-аналитик отвечает на вопросы «Что?» и «Для кого?»
Системный аналитик уже может не общаться напрямую с заказчиком (хотя может и
общаться), но взаимодействует с бизнес-аналигиком и результатом его работы Сис-
темный аналитик отвечает на вопрос «Как?» Как приготовить блюда (рецептура), как
сварить кофе (какое зерно какой способ обжарки), как будет выглядеть кухня и какая
потребуется техника, как будет осуществляться оплата товара и его упаковка, если
требуеюя.
Конечною исполнителя ижересует не абстрактная концепция, а конкретная рецепту-
ра Например, повар станет готовить то, что будет представлено в техноло-ической
карте, и по указанному рецепту. Тс есть исполнитель работает с результатом работы
именно системного аналитика
Можно сказать, что бизнес-аналитик и системный аналитик соотносятся как
продуктовый менеджер и владелец продукта.
На практике бизнес-аналитик в небольших командах, имеющих до пяти сотруд-
ников, при наличии опытного РО может отсутствовать. Кроме того, вполне зако-
номерным ростом для В А является рост в РО, когда аналитик обладает уже доста-
точными навыками в работе с требованиями и хочет развития. Отмечу только то,
что не стоит пытаться перейти в роль РО, минуя навыки работы с требованиями.
♦ Выделяют также отдельно такую роль, как аналитик данных (Data Analyst). Это
особая роль, и ее не следует напрямую сравнивать с системным или бизнес-
аналитиком. Задача аналитика данных — провести анализ данных с целью выяв-
ления каких-либо закономерностей (еше говорят, инсайтов), позволяющих при-
нять решение. Аналитик данных, например, может проанализировать ситуацию
в конкретных магазинах и рекомендовать установку касс самообслуживания в
тех магазинах, где есть проблемы с очередями. Задача новичка — не перепутать
аналитика данных с системным и продуктовым аналитиком.
♦ Дизайнер (Designer) отвечает за пользовательский интерфейс (UI, User Interface)
и пользовательский опыт (UX, User Experience). Важно понимать, что дизайнер
не просто рисует красивые картинки или «красивые интерфейсы», как часто ду-
мают. Его работа — продумывать решения, которые делают продукт удобным
для пользователя.
Простой пример
Форма регистрации. Дизайнер решает, сколько полей нужно оставить, чтобы пользо-
ватель не ус г ал и не зак рыл страницу не заполнив данные От правильного решения
зависит не только удобство, но и конверсия: компания может потерять клиента, если
интерфейс неудобен.
Вместе с аналитиками дизайнер формирует ожидания пользователя. Когда эти
ожидания становятся ясны, они создают задания для команды разработки. То
есть, по сути, переводят бизнес-требования в технические требования, чтобы
команда могла реализовать продукт так, как задумано, и пользователи получили
удобный и понятный опыт работы.
Задача новичка при общении с дизайнером — обращать внимание на следующие
моменты:
• если вы технический специалист и понимаете, что реализация не будет соот-
ветствовать (или уже не соответствует) макетам, то должны незамедлительно
об этом сообщить и дизайнеру, и РО. Если они скажут, что это нормально, то
лучше поговорите с наставником или тимлидом. Часто бывает так, что на
словах договорились, а РМ или заказчика не устроит финальный вариант, ко-
торый отличается от макета;
• макеты должны содержать компоненты, которые ранее использовались в про-
дукте. Либо, если предложен новый компоненг, это должно явно обозначаться;
• дизайнер может нарисовать только ситуацию, когда всё хорошо (белый сце-
нарий), но забыть про крайние случаи. Всегда спрашивайте и просите фикси-
ровать ответы (дизайнера или аналитика). Например: «А как выглядит эта
кнопка, если она заблокирована*7», «Что видит пользователь, если данные
еше загружаются?». «Как выглядит экран, если данных нет совсем?»;
• даже для начинающего специалиста хорошо подчеркивать вопросы, связан-
ные с версткой и анимацией. Уточните, возможна ли ситуация, когда разре-
шение экрана будет не таким, как на макете, и существуют ли соответствую-
щие требования. Анимация может выглядеть красиво, но потреблять ресурсы
компьютера и значительно увеличивать затраты на задачу, — поговорите об
этом, но не с дизайнером, а с РО или РМ: нужны ли действительно те анима-
ции. которые заложены в макет.
2.2. Технические роли:
разработчик, тестировщик, DevOps
Теперь поговорим о технических ролях («технарях», как их часто называют). Это
разработчики, тестировщики и DevOps-инженеры
♦ Разработчик программного обеспечения (Software Developer) — тот, кто зани-
мается разработкой на каком-либо языке программирования. Это одна из самых
многочисленных ролей в IT. Именно разработчики создают приложения — на
основании требований, которые им принесли, создается продукт. В России
крайне сильно мнение разработчиков, и некоторые опытные могут убедить про-
дуктовую команду в том, что решение неудачное. Часто можно встретить про-
дукты, в которых невозможно работать,— и всё потому, что их делали нро-
1раммисты, а продуктовая команда или не написала требования, или не просле-
дила за реализацией.
Наиболее распространены frontend-разработчики и backend разработчики, хотя
встречаются и другие разработчики,
• Frontend-разработчик реализует интерфейс, с которым взаимодействует
пользователь приложения. Именно то, с чем взаимодействует пользователь в
программе, реализовано frontend-разработчиком, — например, внешний вид
сайта в браузере. Чаще всего в настоящее время frontcnd-разработчики пишут
код под корректную работу в браузерах. Froniend-разработчики обычно плот-
но взаимодействуют в основном с дизайнерами. Они говорят дизайнерам о
возможностях. Типичный пример: «Окна с таким дизайном у нас нет, давай
используем похожее?»
• Backend-разработчик реализует основную логику работ ы приложения. Чаще
всего реализация внутренней логики (алгоритмов) выполняется именно
backend-разработчиком. Пользователи обычно не видят работу backend-
разработчика, но видят результат его работы. Например, если вам неправиль-
но рассчитали сумму скидки, то это, скорее всего, ошибка в работе backend-
разработчика. Если frontend-разработчик работает в основном с дизайнером,
то backend-разработчик — с системным аналитиком. Ему не интересны цвета,
формы, расположение кнопок и т. п., ему интересно то, как будет работать
конкретная функция, которая реализуется при нажатии на кнопку.
Frontend- и backend-разработчики часто взаимодействуют и договарива-
ются о том, как именно будет сделана та или иная функциональность. На-
пример, кто сформирует ошибку на то, что ИНН не соответствует нужной
длине при вводе. Взаимодействие между frontend и backend осуществляет-
ся чаще всего через API (подробнее об этом будет рассказано далее), хотя
наверняка есть и какие-то экзотические способы взаимодействия.
♦ Мобильный разработчик (Mobile Developer) реализует всю необходимую логику
и визуальную часть для мобильных устройств иод Android и iOS.
Задача новичка при общении с разработчиком (если вы не технический специа-
лист) не спрашивать: «Почему так медленно?» Гораздо лучше уточнить «Что
является самым сложным в этой задаче?» Иногда простой вопрос о том, как
можно уменьшить затраты, даст лучший результат. Понимание сложности по-
может лучше планировать работу.
♦ Часто в командах разработки можно встретить техлида — технического лидера.
Техлид (Tech Lead) — это тот, кто отвечает за то, как должна быть технически
реализована конкретная задача в продукте:
• техлид знает архитектуру продукта, особенности работы, реализацию кон-
кретных элементов системы и так далее. Техлид максимально погружен в код
и может точно сказать, что и где необходимо реализовать, какие ждут под-
водные камни и в каких модулях потребуется сделать доработки;
• техлид следит за качеством, соблюдением архитектуры и дизайна системы,
занимается проектированием сложных задач;
• техлид обычно обладает самыми экспертными знаниями в продукте, поэтому
лично занимается ревью кода (или его важных частей), обучением и переда-
чей знаний;
Совет аналитику
Если вы аналитик, перед финализацией требований покажите черни зик техлиду. Один
комментарий я духе «мы так сделать не сможем из-за ограничений архитектуры» по-
может вам сэкономить нервы и время,
• техлид формирует и расставляет приоритеты в техническом долге продукта и
зачастую сам же и занимается их решением. А если не сам, то следит за тем,
чтобы было сделано как задумано.
Совет новичку
Техлиды обычно очень загружены сложными задачами, поэтому их время — ценный
ресурс. Чтобы ваше общение с ними было эффективным, готовьтесь к вопросам зара-
нее: четко опишите проблему, отмерьте, чтс уже пробовали сделать и какой результат
ожидали. Не бойтесь спрашивать э непонятных моментах— техлиды ценят тех кзо
хочет оазобраться, и обычно не терпят тех, кто хочет выглядеть всезнайкой Всегда
делайте заметки по ответам, чтобы не возвращаться к одним и тем же темам Помни-
те, что техлид отвечает за техническую сторону продукта и заинтересован в том. что-
бы вы быстрее освоились в проекте
♦ Тестировщик (QA Engineer) занимается проверкой продукта, реализованного
разработчиками, на соответствие требованиям, а также на удобство использова-
ния. на нагрузку, проводит стресс-проверку и многое другое.
Кроме проверки продукта на соответствие явным требованиям, указанным в по-
становке задачи, тестировщики занимаются и неявными проверками на соответ-
ствие неочевидным требованиям, содержащимся в описаниях продукта, — на-
пример, к безопасности или к скорости работы. Или вообще не описанным ни-
где. но соответствующим здравому смыслу. Например, хотя в интерфейсе про-
граммы не будет упомянуто, что в интернет-заказе нельзя указывать отрица-
тельное количество товара, но и не должно быть возможности уйти в минус, и
задача тестировщика — именно это проверить.
Как вы уже поняли, тестировщики проверяют не только указанные аналитиком
сценарии, отрицательные и альтернативные сценарии, но и фиксируют результа-
ты в документах: описывают как сами сценарии воспроизведения (тест-кейсы),
так и результаты проверки.
Совет новичку
Если вы разработчик, то прежде чем отдавать задачу е тест убедитесь, что и вы, и QA
понимаете ожидаемый результат одинаково. Не заставляйте QA вернуть вам задачу
сразу после взятия в тест.
Выделяют ручных тестировщиков (QA manual engineer), тестировщиков-автома-
тизаторов (QA automation engineer) и тестировщиков-универсалов (fullstack QA),
которые объединяют в себе роли ручного тестировщика и тестировщика-авто-
матизатора.
♦ Инженер по ручному тестированию (QA Manual Engineer) — ручной тестиров-
щик. <<Ручной» означает, что он занимается проверками вручную, без написания
кода,— проверяет программу на соответствие требованиям Например, если
разработчик реализует функцию отправки сообщения в мессенджер, то в задачу
ручною тестировщика входит:
• настройка программы.
• отправка сообщения;
• проверка того, что сообщение отправлено;
• проверка того, что сообщение доставлено.
Проверяются и различные негативные сценарии: отсутствие связи при отправке,
неверный адрес получателя и любые другие реальные сценарии.
Ручной тестировщик может задействовать для проверки дополнительные инст-
рументы. Например, если проверяется работа API, то могут использоваться спе-
циальные программы для отправки и получения запросов.
Кроме того, ручной тестировщик проверяет работу приложения под нагрузкой,
если требуется эмулировать работу большого количества устройств. Для этого
также используются специализированные инструменты, и ручной тестировщик
должен уметь работать с ними.
Совет новичку
Если QA прислал баг, который не воспроизводится не надо его сразу закрывать. По-
просите записать видео или показать на созвоне. Разница в версиях браузера, кеше
или окружении — это тоже часть проблемы, которую нужно решить
♦ Тестировщик-автоматпизатор (QA automation engineer) — специалист по авто-
матическому тестированию. Он пишет программу, позволяющую в автоматиче-
ском режиме проверять работу тестируемого приложения. На самом деле тести-
ровщик-автоматизатор — это, по сути, тот же разработчик, но специализирую-
щийся не на написании кода приложения, а на написании кода приложения для
тестирования приложения.
Совет новичку
Начинающим специалиоам часто кажется, что автоматизагоры «круче» ручных тес-
тировщиков. На практике— это две разные профессии, требующие разных навыков.
Ручное (вотирование учит глубокому пониманию продукта и пользователя, а автома-
тизация — программированию Если у вас есть выбор, то начните с ручного тестиро-
вания опытный ручной тестировщик всегда ценен, а полученный опыт стане! основой,
если вы решите двигаться в сторону автоматизации
♦ DevOps-инженер (DevOps engineer) занимается организацией доставки в Про-
дакшен того, что разработчики непосредственно запрограммировали. На его от-
ветственности организация и управление CI/CD, поддержка работоспособности
сервисов и взаимодействие с облачными сервисами. Фактически именно силами
devops-инженеров и происходит доставка продукта в продакшен и его обновление.
Термин «DevOps» образован от Development and Operations, то есть буквально
«разработка и эксплуатация». В целом методология DevOps направлена на то,
чтобы объединять команду разработки и команду эксплуатации с целью повы-
шения эффективности доставки обновлений. DevOps-инженеры — это автома-
тизаторы работы, они создают инструменты, позволяющие упростить доставку
за счет ее автоматизации. Кроме того, DevOps-инженеры организуют монито-
ринг и информирование.
Простыми словами, если представить, что разработчики — это повара, которые
готовят новое блюдо (фичу), то DevOps-инженер — это сотрудник упаковки и
службы доставки и менеджер по кухне.
Его задача — сделать так, чтобы:
• готовое блюдо быстро и без ошибок упаковали;
• дос тавил и нуждающим ся гостям (пол ь зовател ям);
• на кухне (серверах) всегда были нужные продукты (ресурсы), горел свет и
работало оборудование.
Советы новичку при общении с DevOps-инженером
Не просиге доступ к серверу, даже к тестовому, без объяснения причин Наг ри мер,
если у вас проблема с какими-то данными в базе данных, то сообщите о этом явно.
Например так: «Мне нужно посмотреть, почему в таблице заказов не обновляются
статусы, какие логи мне стоит изучить?» DevOps-инженеры обеспечивают стабиль-
ность инфраструктуры, поэтому не готовы просто так всем раздавать права
Сообщайте об изменениях, которые нужны в окружении заранее! Например, ес-
ли задача требует повой библиотеки, изменения версии основного фреймворка
или открыгия нового порта, то об этом нужно сказать, как только это станет из-
вестно, а не к моменту, когда код уже написан. Это важно с учетом того, что
инфраструктура часто описывается кодом (1аС, Infrastructure as Code), и измене-
ния в ней требуют времени.
Финальный совет, но очень важный
Если вы что-то сломали в инфраструктуре или окружении, то не пытайтесь это тихо
починить, если не уверены на 100%. Лучше сразу идти к DevOps-инженеру и при-
знаться в том, что вы автор проблемы. Поверьте, быстрая совместная починка ценит-
ся гораздо выше, чем попытка скрыть аварию, которая может привести к простою ко-
манды.
2.3. Вспомогательные роли:
технический писатель, поддержка
♦ Технический писатель (Technical Writers), техпис, занимается подготовкой поль-
зовательской или технической документации.
• Пользовательская документация — это публичная документация по тому,
как работать с продуктом, как его настраивать.
• Техническая документация — содержит информацию о внутреннем устрой-
стве продукта схемы взаимодействия, потоки данных, компоненты и т. п.
Техническая документация обычно не является публичной, то есть не дос-
тупна пользователям.
Совет новичку
Проверяйте факты, которые описаны гехписами, но не стиль оформления. Техписы
оформляют статью, но точность того что написано, проверяет техническая команда.
♦ Инженер технической поддержки (Support Engineer) Основная задача, которую
решает инженер технической поддержки, это решение проблем пользователей
продукта, Выделяют инженеров нескольких линий — чем больше цифра, тем
выше уровень знаний и больше сложность решаемых проблем. Задача инженера
технической поддержки— как можно скорее решить заявку от клиента Тут
важно уложиться в заложенные метрики, например. SLA
Совет новичку
Если вы не понимаете, почему пользователи жалуются на новую функцию, то сходите
к поддержке. Они пришлют видео или другие материалы. А также передадут вам боли
клиента, которые невозможно было предусмотреть заранее
♦ SRE-инженер (Site Reliability Engineer). SRE-инженеры занимаются обеспечени-
ем надежности и доступности систем. SRE-инженер — это специалист, который
применяет инженерный подход к задачам доставки обновлений. Его цель —
обеспечить надежность системы при одновременном внедрении новых функций.
SRE-инженер работает с метриками (SLA, SLO. SLI). автоматизирует ручные
рутинные операции и управляет инцидентами. Он использует те же инструмент
ты, что и DevOps, но применяет их с акцентом на мониторинг, надежность и
управление рисками.
♦ Менеджер пи работе с клиентами (CSM, Customer Success Manager), Занимает-
ся консультированием клиентов по тому, как наилучшим образом достигать це-
лей клиентов, используя продукт, CSM’bi предоставляют рекомендации по оп-
тимизации работы с продуктом. Кроме того, CSM выявляют возможности апсел-
ла (upsell) или кросселла (cross-sell). Это техники увеличения продаж,
предполагающие дополнительную продажу клиенту более дорогой версии про-
дукта или продажу дополнительных продуктов (или частей). Это, с одной сто-
роны, ведет к большей удовлетворенности клиента продуктом, а с другой —
увеличению дохода от клиента.
Совет новичку
Зспомогательные роли отлично подходят тем. кто хочет работать в 1Т но не уверен в
своих навыках, — например, в навыке разработчика или тестировщика Они позволя-
ют разобраться в продукте и влиять на удовлетворенность пользователей от пользо-
вания продуктом Опыт в этих областях может стать основной для перехода в другие
IT-специапьности: продуктовые, менеджерские или технические
- Глава 3-
Первые дни в команде
3.1. Как пройти онбординг и не потеряться?
Период адаптации нового сотрудника — один из самых сложных периодов Помню
свои первые месяцы на новом месте, когда голова пухла от количества информа-
ции, казалось, что ничего не получается, и в какие-io моменты даже хотелось уйти.
И только помощь моего коллеги помогла мне разобраться в том, что тут и как.
В этой главе мы подробно поговорим о том, что такое онбординг и как его хорошо
и уверенно пройти.
Онбординг — это не знакомство с коллегами и не экскурсия по офису (кто где си-
дит). Онбординг — это даже не набор инструкций, которые надо изучить.
Онбординг— это процесс, цель которого— сделать вас самостоятельным, полез-
ным (и в идеале эффективным) членом команды как можно раньше В России оч-
бординг редко бывает идеальным. В какой-то из организаций вам дадут подробный!
план действий, а где-то не дадут ничего и лишь скажут: «Разбирайся, если будут
вопросы, то приходи».
Далее приведена информация о том, что важно знать и делать, чтобы пройти этот
путь без стресса.
3.1.1. Поймите контекст, а не бросайтесь в задачи
Не бросайтесь сразу писать код, тестировать или собирать требования. Сначала
разберитесь с контекстом компании и команды, в которой вы работаете. Кон-
текст — это все тс внешние и внутренние факторы, которые определяют условия
работы и влияют на принятие решений. Чтобы лучше понять контекст, найдите от-
веты на следующие вопросы.
♦ Что делает ваша команда и для кого?
• Кто конечные пользователи продукта?
• Кто реально платит за него? (Часто это не тот же человек, кто использует.)
• В чем уникальность продукта на рынке?
♦ Какие у команды настоящие приоритеты?
Документы могут говорить одно, а реальные дедлайны и обсуждения в чатах —
совсем другое. Слушайте, о чем чаще всего говорят на стендапах, какие задачи
помечают как «блокеры».
♦ Какие решения здесь считаются правильными?
В каждой компании свой подход к качеству кода, тестированию, документиро-
ванию То, что было «лучшей практикой» на прошлом месте (если оно у вас бы-
ло), здесь может оказаться неприменимым.
Почему это важно?
Без этого контекста вы будете работать «как привыкли» (или «как правильным ка-
жется вам»), а не гак, как принято в этой компании или в этой команде. Особенно
критично, если вы сменили:
♦ бизнес-домен (допустим, перешли из финтеха в геймдев);
♦ тип компании (из стартапа в корпорацию);
♦ роль (из тестировщика в аналитика).
Примеры из жизни
1. Сотрудник, перешедший из поддержки в разработку, продолжает действовать в па-
радигме «закрыть максимум заявок» Но в разработке ценность измеряется не коли-
чеством решенных тикетов, а созданием функций, которые предотвращают эти заяв-
ки Вместо быстрых костылей здесь нужны продуманные архитектурные решения.
2. Новый разработчик в команде получает задачу на реализацию, в которой требуется
работа с файлами. На предыдущем месте он уже работал с похожими задачами и
знает, что нужно использовать определенную библиотеку Разработчик тратит вромя
на реализацию с ее помощью, отдает код на ревью и моментально получает инфор-
мацию о том. что внешние библиотеки использовать нельзя без аудита со стороны
ИБ (потому что какое-то время назад произошла утечка данных) и принято для таких
задач использовать другую библиотеку. Итог время упущено, задача не сделана.
3.1,2. Задавайте вопросы
Самая частая ошибка новичков — молчать из-за стыда или страха показаться не-
компетентным. Помните, что не бывает глупых вопросов, бывают незаданные. В
российских реалиях именно вопросы помогают адаптироваться в разы быстрее.
Вашим коллегам в голову не придет проконсультировать вас по каким-то специ-
фичным терминам, ведь для них это рутина.
Что спрашивать в первую очеоедь?
♦ Где искать актуальную документацию?
Часто она устарела или существует только в переписке. Вместо общего вопроса
«Где документация?» спросите конкретнее: «Я нашел этот документ по процес-
су X — он еще актуален?»
♦ Как работают процессы в команде и компаний?
Интересуйтесь не только своей зоной, но и смежными отделами — это поможет
понять общую картину.
♦ Кто за что отвечает?
В российских компаниях роли часто размыты. Один сотрудник может совме-
щать обязанности тестировщика и технического писателя.
Как правильно спрашивать?
♦ Покажите, что вы разбирались: «Я посмотрел в наш)' wiki-систему (систему
управления знаниями), но информация там не обновлялась три года. Есть ли об-
новленные материалы?»
♦ Уточняйте разницу между формальным и реальным: «По регламенту мы долж-
ны согласовывать через Трекер-систему, но я вижу, что команда решает вопро-
сы в чате. Как правильнее поступить?»
♦ Задавайте наставнику вопросы: «Помогите, пожалуйста, составить карту ответ-
ственности. К кому обращаться по вопросам дизайна? А по API?»
Особенности коммуникации в России
♦ Информация в чатах может быть полуофициальной. То, что обсуждается в кор-
поративных чатах, часто имеет такой же вес, как и формальные документы.
♦ Личные договоренности важнее регламентов. Новичок, следующий только офи-
циальным инструкциям, может столкнуться с непониманием
♦ Мессенджеры — основной канал коммуникации. Будьте готовы к большому по-
току информации в неформальных каналах.
Пример из жизни
Новичок неделю пытался разобра<ься с процессом код-ревью по документации, пока
не спросил «Я вижу, в регламенте указан один процесс, нс в чате код-ревью проходит
иначе. Какой подход правильный?» Оказалось команда пелгода как перешла на но-
вый процесс, но не обновила документацию.
Помните! Ваши вопросы не только помогают вам адаптироваться, но и часто выяв-
ляют устаревшие процессы и документацию, помогая всей команде. В российских
компаниях ценят инициативу, но только когда она подкреплена желанием разо-
браться, а не продемонстрировать знания.
3.1.3. Получение доступов
Не ждите, пока кто-то вспомнит о ваших доступах Доступ к системам — это ваши
проблемы
В российских компаниях процессы выдачи доступов часто запутанны. Загрузка ко-
манды. бюрократия и человеческий фактор могут затянуть ваш старт на дни, а то и
на недели. Ваша задача — проявить инициативу, но делать это нужно грамотно. Не
переусердствуйте, но и не дайте о себе забыть.
Составьте список основных систем в первые несколько дней
Узнайте у руководителя, наставника или тимлида стандартный набор порталов, ко-
торыми пользуется команда. Опытные сотрудники могут забыть упомянуть оче-
видные для них системы Обращайте внимание на названия в чатах и на рабочих
доска*.
Типичный набор в российской компании (это гигиенический минимум):
♦ Трекер для управления задачами.
♦ Git — репозитории кода и CI/CD
♦ Документация или корпоративная wiki-система.
♦ Чат — основная коммуникация.
Совет новичку
На встрече (если такие есть) спросите: «Какие системы критичны для моей работы в
первую неделю?» Или по-простому: «Без каких программ и доступов я не смогу рабо-
тать в первые дни?»
Запрашивайте доступы целенаправленно
Не ждиге автоматических приглашений В перегруженных командах это может за-
нять недели. Помните, в российских IT-компаниях часто совмещают роли, и про
вас могут просто забыть.
Как делать правильно?
♦ Используйте специальные чаты или канаты для запросов, если они есть.
♦ Четко перечисляйте, что вам нужно: «Мне нужен доступ к репозиторию froniend-
арр и проекту Jira "Рестораны"».
♦ Уточните, как предоставляется доступ. Может быть, следует задать вопрос:
«Moiy я отправить запрос системным администраторам самостоятельно?».
Настройте окружение по чек-листу
Даже опытные специалисты тратят дни на настройку из-за специфических требова-
ний компании.
Ваши действия:
♦ Попросите гайд (guide, руководство) по настройке — он часто есть, но о нем за-
бывают (хотя, может быть, он и есть, но не очень актуальный).
♦ Уточните версии ПО, с которыми нужно работать, — в разных компаниях ис-
пользуют разные версии тех же инструментов.
♦ Проверьте VPN и корпоративные сертификаты — частая проблема для любой
компании.
Напоминайте вежливо, но настойчиво
Молчаливое ожидание воспринимается как отсутствие интереса к работе.
Формулы для напоминания:
♦ «Привет! Напоминаю о доступе к Jira — без него не могу понять, что именно
нужно сделать».
♦ «Вижу, что команда работает в GitLab. Могу я помочь ускорить получение дос-
тупа? Из-за отсутствия доступа я не могу работать с проектом».
Особенности российских реалий:
♦ Ответственность размыта: HR, тимлид, 1Т-отдел — каждый думает, что доступы
выдает другой.
♦ Неформальные каналы работают быстрее: вопрос, заданный в курилке, часто
решается быстрее официального запроса (помните, что лучше ходить в офис!).
♦ Тестовые периоды: некоторые доступы могут давать постепенно, по мере ваше-
го погружения в проект.
Пример из жизни
Новичок неделю ждал доступ к тестовой среде, пока не узнал в чате, что нужно лично
написать системному администратору в Telegram. Оказалось, это негласное правило,
которого нет в документации. В итоге новичок получил негативную обратную связь по
первой неделе своей работы.
Совет новичку
Будьте активны. Ваша активность в решении организационных вопросов — первый
сигнал команде о вашей мотивации и самостоятельности. В российских условиях это
ценится не меньше технических навыков.
3.1.4. Изучение процессов команды
Придя в новую команду, нельзя сразу начинать менять процессы или рассказывать
о том, как правильно организовать работу, и уж тем более упоминать, как всё хо-
рошо было на прошлом месте, или о том, что вы прочитали в книге или на каком-то
портале. Помните, это очень обижает коллектив и сотрудников. Сначала нужно по-
нять, почему процессы сложились именно так. За каждым, на ваш взгляд, неиде-
альным решением стоит опыт прошлых ошибок или технические ограничения.
Создание и оценка задач
♦ Узнайте жизненный цикл задачи: как она попадает в работу, кто ее утверждает,
как меняются статусы. Без этого вы будете теряться в трекере задач.
♦ Разберитесь с оценкой: в одних командах три сторипоинта — это полдня рабо-
ты, в других — два дня. Уточните, насколько оценки строгие.
♦ Определите ключевых людей: кто расставляет приоритеты (чаще продакт или
тимлид). С ними нужно выстроить постоянный контакт.
Пример из жизни
Новичок недепю делал задачу с низким приоритетом, потому что не знал, что тимлид
помечает срочные задачи красным ярлыком в трекере. А приоритет в команде исполь-
зуется только для ошибок.
Код-ревью
♦ Уточните формальные и неформальные правила: сколько апрувов нужно, кого
обязательно звать на ревью из-за его экспертизы.
♦ Узнайте про стиль коммуникации, в некоторых командах принято прямо указы-
вать на ошибки, в других — мягко предлагать улучшения.
Совет новичку
Используйте код-ревью как возможность учиться, а не только критиковать.
Релизы
♦ Разберитесь в графике и процессе: как часто выходят обновления, кто отвечает
за обновление клиентов, какие проверки обязательны перед релизом.
♦ Поймите уровень стабильности: в банковских проектах к релизу подходят стро-
же, чем в стартапах.
Стендапы
♦ Узнайте формат: в некоторых командах это строго «что сделалусделаю/проблемы»,
в других — более свободное обсуждение.
♦ Научитесь говорить по делу: коллеги ценят, когда вы экономите их время.
Ретроспективы
♦ Поймите цель: это не поиск виноватых, а возможность улучшить процессы
♦ Сначала наблюдайте, ногом предлагайте: поймите, что действительно волнует
команду
Не спешите «улучшать»
♦ Сначала поймите контекст: тот странный процесс согласования может быть
следствием прошлого провального релиза.
♦ Проявите уважение: ваши предложения будут услышаны после того, ках вы по-
кажете себя надежным специалистом.
♦ Задавайте вопросы правильно, вместо «это неэффективно» спросите: «Я заме-
тил, что мы делаем гак. Не могли бы вы рассказать, почему был выбран такой
подход?»
Пример из жизни
Разработчик пытался упростить процесс тестирования, не зная, что его сложность
связана с требованиями безопасности для государственной структуры.
Совет новичку
Ваша задача а первые недели — не менять процессы и даже не пытаться об этом го-
ворить. Нужно сначала понять логику процессов и встроиться в команду. Помните, вы
будете выглядеть выскочкой, если попробуете сразу рассказать, как лучше Когда вы
разберетесь в причинах существующих правил, ваши предложения по улучшению бу-
дут гораздо белее своевременными.
3.1.5. Возьмите первую реальную задачу
Очень часто новичкам предлагают начать с исправления небольших багов — и это
лучший способ стартовать. Обычно вам дают исправлять ошибки среднего приори-
тета, срок исправления которых можно подвинуть. Такие задачи важны, они боль-
ше помогут вам не показать команде, в чем вы эксперт, а разобраться в проекте.
Иногда исправление ошибки — это одна строчка кода, но чтобы ее найти и допи-
сать, придется потратить несколько дней.
Что дает такая механическая реализация (без сложной логики)?
♦ Пройти полный цикл разработки на практике Вы не просто исправите код — вы
увидиге, как работает весь механизм:
• от создания задачи в трекере до код-ревью;
• от тестирования до релиза;
• от документации до обсуждения на стендапе.
Пример
Исправляя опечатку в интерфейсе, вы поймете как устроен процесс обновления вер-
сий, кто отвечает за выкатку и какие проверки нужны перед выпуском
♦ Познакомиться с кодом через конкретный пример. Вместо абстрактного чтения
тысяч строк вы изучаете код целенаправленно.
• видите, как организованы модули;
• понимаете стандарты оформления;
• узнаете, какие библиотеки использует команда.
Совет новичку
Исправляя баг в одном модуле, вы заодно изучите смежные области— это эффек-
тивнее, чем читать документацию.
♦ Начать настоящие обсуждения с коллегами. Ваша задача станет поводом для
общения и налаживания коммуникации:
на код-ревью вы получите конкретные замечания по своему коду;
• на стендапе сможете рассказать о реальном прогрессе;
• сможете задавать точечные вопросы по архитектуре.
Как получить первую задачу, если вам ее не дают?
♦ Проявите инициативу: «Я изучил основные процессы и готов взять первую за-
дачу или исправление ошибки».
♦ Если есть возможность выбора, то берите простые задачи. Попросите что-то
вроде «исправить текст в сообщении об ошибке» или «добавить ватидацию поля».
♦ Используйте наставника: «Не могли бы вы посоветовать, с какой задачи тучшс
начать?»
Чего избегать в первой задаче?
♦ Не берите сложные и плавающие ошибки. Многочасовой дебаггинг, особенно
если не понятно, как воспроизвести ошибку, может отбить всю мотивацию.
♦ Не скрывайте проблемы. Лучше спросить гри раза, чем три дня биться над ре-
шением. Нужен баланс: нельзя бежать при первой проблеме, но и сидеть днями
не надо.
♦ Не переписывайте код! Ваша цель — вписаться в существующую архитектуру, а
не показать, что вы самый умный.
♦ Помните о том, что первая задача — это то, как вас встретят в команде. Решите
быстро и без ненужных вопросов — у вас будет хорошая репутация, а запутае-
тесь и нс признаетесь, подумают, что вы слабый специалист.
3.2. Ключевые люди:
к кому обращаться с вопросами?
Первые дни в команде требуют понимания того, кто и за что отвечает. В россий-
ских IT-командах важно различать не только официальные роли, но и фактические,
которые отличаются от формальной структуры.
3.2.1. Непосредственный руководитель
Менеджер, руководитель, тимлид — ваш основной контакт для решения ключевых
вопросов. Скорее всего, он проводил с вами собеседование, и вы уже с ним знако-
мы. К нему следует обращаться, когда:
♦ нужно определить приоритеты задач;
♦ возникают конфликтные ситуации;
♦ гребуется обсудить карьерное развитие;
♦ другие способы решения проблемы не помогли.
Пример из жизни
При наличии двух задач’ срочной и сложной — руководитель подскажет, какая важнее
для бизнеса в текущий момент.
3.2.2. Технический наставник
Практически в каждой компании выделяют явного наставника. Иногда за это даже
доплачивают. Это может быть старший разработчик или техлид, который помогает
разобраться в технических аспектах работы:
♦ архитектура и кодовая база;
♦ стандарты разработки;
♦ процессы код-ревью;
♦ инструменты и методологии.
Помните, что с наставником крайне важно наладить эффективное взаимодействие:
♦ готовьте конкретные технические вопросы;
♦ согласуйте регулярность встреч;
♦ фиксируйте полученные ответы.
3.2.3. Бадди (Buddy)
Во многих компаниях новичку назначают бадди — коллегу, который помогает осво-
иться в первые недели (иногда его также называют ментором). Вообще-то предпола-
гается, что бадди и технический наставник — эго один и гот же человек, но на самом
деле бадди — это, скорее, тот, кто реально помогает Он может вообще не разбирать-
ся в том, чем занимаетесь вы, но быть прекрасным и открытым человеком. Обычно
бадди — это люди, которым не всё равно. Если бадди есть, то его задачи:
♦ объяснение неформальных правил команды;
♦ помощь в ориентации в корпоративных системах:
♦ консультации по корпоративной культуре;
♦ подсказки, к кому обращаться с разными вопросами.
Рекомендации по работе с бадди:
♦ договоритесь о рехулярных коротких встречах;
♦ задавайте вопросы, которые неудобно обсуждать с руководителем;
♦ уточняйте непонятные организационные моменты.
3.2.4. Специалисты по направлениям
В команде обычно есть эксперты в разных областях:
♦ Архитектор (чаще на несколько команд) — вопросы проектирования систем.
♦ Старший разработчик (техлид или senior) — особенности конкретных модулей.
♦ Тестировщик — тестирование и качество.
♦ DevOps- инженер — развертывание и инфраструктура.
♦ Аналитик — требования и бизнес-логика.
♦ Дизайнер — интерфейсы и пользовательский опыт.
Совет новичку
Составьте список компетенций коллег — это поможет быстрее находить нужных спе-
циалистов.
3.2.5. Особенности российских команд
Нужно понимать особенности российских команд и уметь работать с ними. Скорее
всего, у вас еще немного опыта, поэтому некоторые моменты могут вас удивлять
или быть непонятными. Разберем детально типичные ситуации.
♦ Совмещение ролей — один сотрудник часто выполняет несколько функций. Это
специфика очень многих компаний, даже средних и больших. Тут логика про-
стая: чем меньше компания, тем больше совмещают Для стартапов это вообще
норма.
♦ Неформальное лидерство — влияние не всегда соответствует должности. По-
пробуйте определить, кто является в команде «серым кардиналом». Некоторые
сотрудники даже на руководящих должностях прислушиваются к словам своих
подчиненных.
♦ Гибкая коммуникация— вы должны быть готовы к неформальным каналам об-
щения. Не надо подлизываться или пытаться попасть в закрытый крут, но не нуж-
но и отделяться или быть отшельником. Общайтесь неформально по аналогии с
тем, как делают остальные, — это может дать новичку новые возможности.
♦ Расхождение формальных и реальных процессов — фактические процедуры или
процессы могут отличаться от официальных, которые описаны в документах.
Обращение с вопросами
Прежде чем что-то у кого-то спросить, сначала проверьте документацию и историю
обсуждений. Многие не готовы тратить свое время на объяснение чего-либо боль-
ше, чем один раз. Если у вас используются различные каналы с большим количест-
вом участников, то нужно правильно определить канал или конкретного человека —
технические, организационные и административные вопросы решаются через раз-
ных людей.
Если вы уже всё проверили и не нашли материалов, используйте конкретные фор-
мулировки — опишите проблему, предпринятые действия и полученный результат.
Ну и в конце концов, будьте тактичны: соблюдайте рабочие часы для нетривиаль-
ных вопросов и всегда благодарите за помощь.
В российских IT-компаниях ценятся:
♦ прямые и четкие формулировки,
♦ предварительная самостоятельная работа над проблемой;
♦ уважение к рабочему времени коллег;
♦ благодарность за помощь и фиксация решений.
Никто не ожидает от новичка мгновенного понимания всех процессов. Отсутствие
инициативы и скрытые проблемы приносят больше вреда, чем своевременно задан-
ные вопросы, даже самому’ суровому' техлиду. Способность находить нужных спе-
циалистов и грамотно формулировать запросы — важный профессиональный на-
вык, который развивается с опытом.
3.3. Корпоративная культура и негласные правила
Когда я только выходил на свою первую работу, корпоративную культуру мне опи-
сывали предельно просто: вот брошюра, вот ценности, вот миссия. «Мы современ-
ные», «мы про людей», «мы одна команда». Все выглядело аккуратно и даже вну-
шительно, но интуитивно доверия не вызывало. Слишком уж гладко это звучало.
Со временем стало понятно: настоящая корпоративная культура живет вовсе не в
презентациях для новичков и не на корпоративном сайте. Она проявляется в том,
как люди ведут себя каждый день, — на созвонах, в переписке, на кухне, в сложных
ситуациях.
В российских компаниях культура почти никогда не вырастает из регламентов Ее
формируют люди и их взаимодействие. То, как общаются собственники и топ-
менеджеры. То, как договариваются руководители между собой. То, как сотрудни-
ки реагируют на ошибки, дедлайны и инициативу коллег. И очень часто реальная
картина сильно отличается от того, что красиво описано в приветственных мате-
риалах.
Не зря управленцы .любят повторять фразу, давно ставшую классикой: «Культура
ест стратегию на завтрак». Можно выдумать какую угодно стратегию, но если она
не совпадает с культурой, то стратегия просго не заработает.
♦ Почему это особенно заметно у нас? Потому что противоречия всплывают мо-
ментально.
♦ Можно объявить переход на холакратию1, но если ключевые решения по-
прежнему принимает один человек, то никакой «самоорганизации» не случится.
1 Холакратия (Holacracy) — система управления, в которой кет привычных начальников должностей
и иерархии «сверху вниз». Вместо этого власть и ответственность распределяются между всеми
сотрудниками в рамках их ролей. Холакратия требует очень высокого уровня самоорганизации.
♦ Можно запретить переработки в регламенте, но если руководитель стабильно
пишет в общий чат ближе к полуночи или в выходные и ждет ответа, то все бы-
стро поймут, что регламент здесь ничего не значит.
♦ Можно сколько угодно говорить о поддержке инициативы, но если за ошибку
прилетает публичный разнос, то идеи закончатся сами собой.
♦ Можно внедрять DevOps и автоматизацию, но если команды живут по принципу
«это не наша зона ответственности», то процесс превратится в бесконечную це-
почку согласований.
Российская специфика: культура держится на людях,
а не на процессах
Во многих отечественных командах культура буквально «держится» на конкретных
людях. Поэтому, приходя в новую компанию, имеет смысл смотреть не столько на
документы, сколько на повседневное поведение:
♦ Опаздывают ли на встречи — и считается ли это нормой?
♦ Перебивают ли друг друга на созвонах?
♦ Обсуждают ли проблемы открыто или предпочитают шептаться потом на кухне?
♦ Ждут ли от новичка инициативы или, наоборот, молчаливого исполнения задач?
♦ Решаются ли вопросы через процессы или через личные договоренности?
♦ Как реагируют на ошибки — разбирают или ищут виноватого?
Корпоративная культура — это то, как компания живет изо дня в день. Что здесь
считается допустимым, а что — нет. Как принимаются решения на самом деле, а не
«по регламенту». Стратегия может быть идеальной, но без культуры она останется
на слайдах. И наоборот: сильная культура иногда вытягивает даже не самую удач-
ную стратегию.
3 .3.1. Как новичку читать негласные правила?
Итак, мы разобрались, что культура— это люди и их отношения. Но как понять ее
в первые недели, когда вы еше ничего не знаете? Далее — простой и рабочий план.
Наблюдайте за коммуникацией:
иерархия реальная или декларативная?
Формально многие российские 1Т-компании говорят об открытости и «плоской
структуре». На практике иерархггя часто никуда не исчезает — она просто стано-
вится неофициальной.
Посмотрите, может ли начинающий специалист (junior) спокойно поспорить с тим-
лидом на митинге? Или мнение старшего не обсуждается?
Вы должны держаться уважительно и спокойно. Обращение «на ты» с руководите-
лем — часто норма, но лучше дождаться инициативы с его стороны.
Присмотритесь к неформальному общению:
где проходит граница работы?
Обратите внимание, говорят ли коллеги о задачах за обедом или предпочитают там
обсуждать нерабочие вопросы? Как отмечают успехи? Приняты ли шутки и само-
ирония?
Не игнорируйте кофе-брейки и неформальные чаты Именно там лучше всего вид-
ны реальные связи и роли в команде.
Разберитесь с процессами скорость или качество?
Для российского ТТ в целом характерен быстрый темп, но отношение к качеству
сильно отличается от команды к команде
Понаблюдайте, насколько строго соблюдаются договоренности? Что важнее — за-
крыть задачу любой ценой иди сделать аккуратно и без костылей?
Еще на собеседовании или в первые дни задайте простой вопрос: «Как здесь отно-
сятся к техническому долгу?» Ответ обычно многое проясняет.
3 .3.2. Чек-лист: чего лучше не делать,
даже если никто не предупреждал
♦ Не лезьте в legacy-код, не разобравшись в контексте. Фраза «Кто это вообще пи-
сал?» может оказаться про человека, который сидит рядом с вами.
♦ Не игнорируйте код-стайл команды и не лезьте с красотой в код, который не
трогаете. Ваш «более красивый вариант» легко воспринимается как неуважение
и просто пустая работа.
♦ Не пропускайте стендапы без причины. Это почти всегда читается как сигнал
«мне не до вас».
♦ Не выкатывайте изменения в продакшен в одиночку, особенно если вы новичок.
Разгребать последствия будут другие.
Совет новичку
Первые две-три недели — это не время доказывать, что Bdi самый умный в команде.
Это время наблюдать и впитывать. Зедите себя как исследователь в новой среде:
смотрите, слушайте, задавайте уточняющие вопросы вроде «А почему здесь принято
делать именно так?» Фиксируйте закономерности. Помните: то. что отлично работало
на прошлом месте, здесь может дать сбой. Сначала разберитесь в местных обыча-
ях — и только потом предлагайте изменения.
Встроиться в команду — значит, научиться говорить с ней на одном языке. И этот
язык состоит не только из терминов и технологий, но и из десятков негласных пра-
вил. Именно они и формируют настоящую корпоративную культуру.
3.4. План онбординга:
что узнать и сделать в первые дни
Может бьиъ, вам повезет, и вы устроитесь в компанию, где вам сразу выдадут го-
товый план работ. Следуйте ему. Надо понимать, что план обычно содержит при-
мерный список областей, которые нужно узнать.
Если плана пет — действуйте по этому руководству. Помните, что независимо от
того, есть у вас бадди, наставник или план онбординга, ваша главная задача на ис-
пытательном сроке — продемонстрировать, что вы становитесь самостоятельным и
полезным членом команды. Компания брала вас (даже если вы новичок), чтобы по-
лучить пользу, так что не говорите, что вас не обучили и не помогли
Надеюсь, что вы знаете о правиле обучения и развития 70/20/10. Смысл его в сле-
дующем:
♦ 70% обучения — эго практика. Ваша основная работа и задачи;
♦ 20% — общение с коллегами. Вопросы, код-ревью, совещания;
♦ 10% — формальное обучение. Чтение документации, прохождение курсов.
Как можно видеть, только 10% процесса— это обучение и чтение документации!
Сфокусируйтесь на практике! Но не пренебрегайте общением. То есть ваше обуче-
ние — это в первую очередь ваша задача.
Ваш главный инструмент адаптации — это обучение в работе. Помните, что прак-
тика — это 70% процесса развития. Не бойтесь брать первые задачи, пусть они бу-
дут небольшими. Именно через реальную работу вы поймете:
♦ как на самом деле устроены процессы. Теория из документов всегда расходится
с практикой;
♦ где скрыты полводные камни в кодовой базе или в коммуникации;
♦ кто является настоящим экспертом в той или иной области.
Совет новичку
Вместо того чтобы неделю читать про процесс кед-ревью, сделайте пул-реквесг по
мелкой задаче 1ы за один день узнаете больше, чем из всех гайдлайнов.
20% пропесса— обучение через коммуникацию с коллегами. Ваши коллеги и на-
ставник — база знаний. Задавайте вопросы, но делайте это грамотно.
♦ Наблюдайте за тем, как коллеги решают задачи, какие инструменты используют.
♦ Просите честную обратную связь после завершения какой-то части работы.
♦ Участвуйте в неформальном общении. Многие нюансы работы команды обсуж-
даются именно там.
Классическая ситуация, когда новичок потратил день, пытаясь настроить локальное
окружение, а затем спросил соседа по команде и решил проблему за 10 минут.
1 0% процесса — обучение по материалам. Это тот самый минимум, который даст
вам компания: доступы к базам знаний, записанные вс гречи и демоне грации, опи-
сание процессов Б российских реалиях на это! пункт можно рассчитывать меньше
всего — документация часто устарела, а тренинг может оказаться записью трехлет-
ней давности.
Пройдемся по тому, что нужно знать на каждом месячном интервале. Редко встре-
чи проводят каждую неделю, обычно это от 2 до 4 недель.
3 .4,1 Первые 30 дней:
цель — сохранить базу и понять контекст
Ваша главная цель в первый месяц — не показать себя, а избежать ошибок и вник-
нуть в работу команды.
Что сделать и узнать?
♦ Люди и процессы (20% времени).
• Познакомьтесь с тимлидом и командой. Узнайте, кто за что отвечает.
• Найдите бадди (наставника) или самого дружелюбного коллегу Это ваша
главная опора.
• Заведите список контактов: кто за что отвечает и с кем надо согласовывать
решения.
• Поймите ритм команды: график стендапов, демонстраций, ретроспектив.
♦ Инструменты и доступы (10% времени).
• Прочитайте документацию по проекту (если она есть). Поймите, что делает
продукт и для кого
• Изучите стандарты команды и компании.
♦ Код и продукт (70% времени).
• Настройте рабочее окружение. Установите всё необходимое ПО.
• Получите доступ к системам: Git, CI/CD, таск-трекер, чаты, документация
(Confluence, wiki).
• Изучите, как работают процессы: как взять задачу, как запушить код. как
проходит код-ревью, как пройти тестирование.
• Возьмите первую простую задачу в работу. Цель— не сделать ее быстрее
всех, а понять процесс изнутри. Но не затягивайте. Нормально, если вы оши-
бетесь и сделаете задачу в 2-3 раза дольше, чем это сделал бы опытный со-
трудник, но не в 10 раз
Советы новичку на первый месяц
• Записывайте всё! 11ароли. команды, ссылки, имена Память новичка перегружена
• Задавайте уточняющие вопросы Не «я не понял», а «я понял, что нужно сделать А
и Б, н. не ясен момент с 3. пожалуйста, подскажите»
• Не критикуйте legacy-код и процессы Сначала узнайте истерию их появления.
• Первые 2-3 недели соблюдайте Формальный график, чтобы понять реальные ожи-
дания насчет рабочего времени
3.4.2.31-60 дней:
цель — стать предсказуемым исполнителем
Второй месяц — время показать, что вы можете самостоятельно закрывать задачи.
Что сделать и узнать?
♦ Углубиться в продукт и архитектуру (30% времени).
• Поймите, как ваши задачи вписываются в общую архитектуру проекта.
• Изучите основные модули системы и их взаимодействие.
• Начните разбираться в техническом долге команды.
♦ Повысить качество своего вклада (60% времени).
• Берите задачи средней сложности и закрывайте их в срок, не превышающий
50% от оценки.
• Активно участвуйте в ревью: и как автор, и как ревьюер (если позволят).
• Перед сдачей задачи проверяйте ее сами. Пишите тесты или делайте любые
другие проверки, которые приняты в команде.
• Начните предупреждать о проблемах заранее «Я упираюсь в блокер», «Эту
задачу, скорее всего, не успею к пятнице».
♦ Интегрироваться в команду (10% времени).
• Начните высказывать свое мнение на обсуждениях (тактично и по делу).
• Предлагай ге небольшие улучшения в документации или процессе, если види-
те явные пробелы. Особенно актуально будет, если вы предложите поправить
документы для новичков.
Советы новичку на второй месяц
• Снижайте частоту вопросов по рутинным вещам. Старайтесь не задавать вопрос
второй раз, если получили на него ответ. Опытных сотрудников это очень раз-
дражает Помните, что нади было сразу записывать полученные ответы.
• Не молчите о проблемах. Если вы зашли в -улик, сообщите об этом наставнику
как можно раньше. В российских реалиях срыв дедлайна из-за замалчивания
проблемы — частая причина провала испытательного срока.
• Научитесь говорить «нет» Если у вас уже есть срочная задача, а вас просят
сделать еще одну уточните приоритеты у руководителя; «Я сейчас делаю зада-
чу X, она срочная Какой задаче отдать приоритет?»
3.4.3.61-90 дней:
цель — стать полноценным членом команды
Последний месяц испытательного срока— время доказать, что вы не просто ис-
полнитель, а сотрудник, который думает о пользе для команды и продукта.
Что сделать и узнать?
♦ Проявить инициативу и экспертизу (50% времени).
• Берите более сложные и комплексные задачи. Но не перегибайте!
• Предложите улучшение, основанное на реальном опыте, и которое действи-
тельно поможет.
• Помогите другому новичку — это может показаться странным, но, объясняя
ему, вы сами поймете суть проблемы.
♦ Взять на себя ответственность (40% времени).
• Самостоятельно ведите задачу от начала и до конца, включая все обязатель-
ные этапы.
• Проанализируйте, какая из ваших задач вызвала больше всего вопросов на
ревью, и работайте над этими слабыми местами,
♦ Стать частью системы (10% времени),
• Получите обратную связь от тимлида о вашем прогрессе. Уточните, какие зо-
ны роста он видит.
• Поймите, как ваша работа влияет на бизнес-метрики.
Советы новичку на третий месяц
• Подготовьтесь к итоговой встрече испытательному сроку. Заранее подумай-
те, что вы сделали, чего достигли, с какими сложностями столкнулись. Неболь-
шая реклама своих достижений не повредит
• Продолжайте учиться. Надеюсь, что вы уже не новичок, но ваш рост в компании
только начинается
• Помните также о том, что испытательный срок не только для вас но и для ком-
пании. Но не зазнавайтесь
3.4,4, Завершение испытательного срока:
как пройти финальную встречу?
Обычно в конце испытательного срока проходит отдельная встреча с руководством.
На ней может присутствовать ваш непосредственный руководитель, тимлид (если
это отдельный человек), а иногда — руководитель рангом выше (например, дирек-
тор по разработке). В такой обстановке коллеги могут вести себя неестественно:
кто-то замолкает, кто-то, наоборот, начинает активно хвалить процессы или вообще
говорить что-то отстраненное. Не путайтесь.
Почему так происходит?
♦ Все упирается в корпоративную культуру, о которой мы говорили ранее.
♦ В зрелых командах к мнению руководителя действительно прислушиваются, и
разговор проходит достаточно открыто.
♦ В других случаях коллеги могут бояться негативной обратной связи или не хо-
тят портить отношения с начальством.
Ваша тактика на встрече:
♦ Говорите по факту и сохраняйте нейтралитет. Вас спросили— вы ответили.
Спросили не вас — не лезьте. Не стоит проявлять излишнюю инициативу и за-
кидывать руководство негативом или потоком предложений по улучшению
♦ Помните: фокус может быть не на вас. Не факт, что руководитель хочет чего-то
именно от вас Часто на таких встречах проверяют качество работы вашего ру-
ководителя, наставника или HR: как прошел онбординг, всё ли было понятно,
хорошо ли вы влились в команду. А еще бывает, что за наставничество доплачи-
вают. поэтому руководитель хочет понять, насколько хорошо наставник сделал
свою работу.
♦ Готовьтесь заранее. Продумайте ответы на вероятные вопросы.
• «Как прошло ваше погружение?»
• «С какими сложностями столкнулись?»
• «Что понравилось, а что можно улучшить в процессах команды?»
♦ Давайте взвешенные оценки. Вместо «У нас бардак в документации» скажите:
«Документация очень помогла в начале, но я бы предложил дополнить ее разде-
лом по настройке, т к там есть несколько неочевидных моментов». Если крити-
куете, то обстоятельства, а не людей.
Руководителя высшего звена не нужно бояться
Прямой начальник (тимлид) принимает ключевое решение о вашем прохождении
испытательного срока, основываясь на трех месяцах вашей работы. Руководитель,
который пришел на итоговую встречу и до этого вас не видел, не будет делать вы-
воды по одной фразе или ответу.
Его цель — не поймать вас на ошибке, а составить обшее впечатление о процессах
в команде и качестве онбординга. Ну и познакомиться с коллегой
Он оценивает не столько вас. сколько систему. Ваши ответы для него — источник
данных о том, как работает его подразделение: хорошо ли выстроен процесс адап-
тации новичков, нет ли системных сбоев.
Он видит сотни сотрудников. Для вас эта встреча— событие. Для нею — часть
рутины.
Совет новичку
Не используйте эту встречу как личный рычаг давления Ваша цель — продемонстри-
ровать зрелость и лояльность команде, а не выявить все ее недошагки. Вы еще не
видели полной картины. Ведите себя спокойно и уверенно.
Что делать, если встречи нет?
Бывает и так, что по окончании испытательного срока вам просто пишут «все ок,
вы прошли» или не говорят ничего. А бывает, что даже ничего не пишут. Молчать
в этой ситуации — ошибка.
Ваши действия;
♦ Проявите инициативу. Обратитесь к тому, кто вас нанимал (тимлиду, менеджеру
по персоналу), и прямо, но вежливо попросите обратную связь.
♦ Сформулируйте запрос правильно. Не «Я прошел или нет?», а:
• «Я хотел бы понять, насколько моя работа за эти три месяца соответствовала
ожиданиям?»
• «Какие у вас замечания к моей работе? На что мне стоит обратить внимание в
ближайшие месяцы?»
• «Все ли я делаю правильно с точки зрения процессов и работы в команде?»
Совет новичку
Хотеть получить обратную связь — это нормально и профессионально. Ваше желание
разобраться в ожиданиях руководства говорит о вашей ответственности. Молчание же
могут воспринять как отсутствие интереса или самоуверенность
- ЧАСТЫ I-
Основы
ПРОЦЕССОВ РАЗРАБОТКИ
- Глава 4-
Жизненный цикл ПО
от идеи до запуска
4.1. Этапы создания программного продукта
Любой программный продукт проходит стадии рождения, развития и завершения
жи шейного пути (смерти). Это естественный цикл, которому следуют все реше-
ния — от небольших стартапов до крупных enterprise-систем.
Новичку нужно очень четко понимать, на каком именно этапе сейчас находится
продукт, т. к. это будет влиять на род его деятельности. Новые продукты требуют
опыта и навыков, но работать с ними обычно интереснее из-за бешеной динамики.
Продукты на стадии развития предполагают равномерный темп и подходят тем, кто
не любит сидеть ночами и выходными Завершающие продукты для опытных раз-
работчиков обычно не интересны и не предполагают роста, на них можно пойти
только тогда, когда других вариантов нет. Однако продукты на завершающей ста-
дии прекрасно могут подойти новичкам, поскольку на этом этапе основной фокус
смещается на сопровождение, исправление ошибок и оптимизацию. Это идеальный
момент для того, чтобы понять, как изначально прекрасные архитектурные реше-
ния сталкиваются с суровой реальностью, обрастают «костылями» под давлением
бизнеса и превращаются в технологический долг. Я бы также рекомендовал нович-
кам продукты в стадии развития, когда процессы выверены, архитектура сформи-
рована, а задачи понятны.
4.1.1. Рождение программного продукта
Первый этап жизненного цикла продукта — это формирование идеи. Он обычно
кажется самым простым и не требующим затрат. Продукт существует лишь в мыс-
лях и набросках. Однако именно здесь закладываются преимущества или соверша-
ются роковые ошибки.
С чего всё начинается?
Не думайте, что продукт — это чье-то озарение или гениальная идея. Программный
продукт редко рождается на пустом месте. Чаще всего идея появляется из одного из
источников.
♦ Проблема. Кто-то (бизнес, пользователь, вы сами) сталкивается с неудобством,
которое можно решить с помощью технологии.
Пример
При изменении □ составе блюда не хочется перепечатывать всю технологическую
карту целиком
♦ Возможность. Чаще всего это внешний толчок: на рынке что-то поменялось или
появилась новая технология, которая открываег двери для сервиса, о котором
раньше и не думали. Не бизнес придумывает идею, а сама жизнь подкидывает
шанс. Возникает мысль: «А сейчас-то это стало реально сделать!»
Пример
Пример идеи на основании технологии «Сейчас почти у каждого официанта есть
планшет. Давайте позволим нашим гостям самим делать заказ прямо со своего уст-
ройства — через наше приложение вместо бумажных меню Это ускорит обслужива-
ние и выглядит современно».
♦ Стратегия. Это внутренняя потребность бизнеса. Компания ставит цель (рас-
ширить долю рынка, повысить лояльность, запустить новый продукт), и под эту
цель ищется или создается IT-решение.
Пример
«Наша аудитория стареет, а молодежь уходит к конкурентам с их мобильными прило
жениями. Нам нужно срочно запустить приложение с программой лояльности и он-
лайн заказом, чтобы удержать и привлечь новых клиентов»
Исследование рынка
Прежде чем погружаться в детали, важно провести первичное исследование. Его
цель — доказать или опровергнуть, что идея стоит времени и денег. Это не просто
«поговорить», а система из четырех шагов:
1. Интервью.
Найдите 10-15 потенциальных пользователей. Спросите не «Вам нравится наша
идея?», а «Как вы решаете эту проблему сейчас? Сколько врсмени/денег это от-
нимает?» Цель— подтвердить, что проблема действительно существует, и она
болезненна.
2. Анализ конкурентов.
Как конкуренты уже решают ту же проблему? Изучите 3-5 конкурентов-игро-
ков. Выпиши ге их сильные и слабые стороны.
3. Технический анализ.
А можно ли это вообще реализовать в разумные сроки? Обсудите с технически-
ми специалистами, какие технологии использоваз ь, есть ли готовые решения для
интеграции, в чем главные технические риски, в какую сумму обойдется инфра-
структура дтя работы нашего продукта. Может оказаться, что технологии недос-
таточно развиты или будут стоить больших денег.
4. Юридический анализ.
Особенно важен в России. Нужно понять требования, которым должен соответ-
ствовать продукт'. Даже простой на первый взгляд продукт неожиданно должен
начать соответствовать целому списку законов, подзаконных актов и других до-
кументов, обязательных для исполнения.
Типовые примеры
• Если работаете с персональными данными — помните про 152-ФЗ и необходи-
мость хранить данные на серверах з РФ
• Если это финуслуги — нужна ли лицензия ЦБ9
• Если работаете с госсектором — готовы ли вы к сложным интеграциям с ЕСИА
(Госуслуги)?
Совет новичку
Если вы только пришли в новую для себя область, то поинтересуйтесь у коллег, какие
законы вы должны знать. Почти наверняка сам сходу ответят про специфические за-
коны, Постановления Правительства или даже приказы, с которыми обязательно нуж-
но ознакомиться.
Формирование видения продукта
Видение продукта (Product Vision) — это не список функций и не техническое за-
дание. Основной вопрос: «Что мы создаем, для кого и почему продукт будет ус-
пешным?» (В приложении 2 вы найдете список ключевых вопросов, которые нужно
задавать на этом этапе.)
Любой неучтенный вопрос может позже стать «миной замедленного действия»,
требующей огромных ресурсов для устранения.
Пример из жизни
Мы допустили Фундаментальную ошибку на старте одного проекта Разрабатывая но-
вый продукт мы сразу заложили требование, он должен работать исключительно на
выделенных серверах заказчика. Мы не стали предусматривать модель общего хос-
тинга для нескольких клиентов
Почему? Потому что все наши предыдущие продукты поставлялись именно так— в
инфраструктуру клиента. И клиенты всегда этого ’ребовали
Но позже выяснилось, что мы сильно ошиблись. Продукт . казался очень ресурсоем-
ким Из-за этого многие небольшие компании просто не могли позволить себе серверы
подходящей мощности. Мы упирались в потолок стоимости внедрения.
Если бы мы изначально предусмотрели возможность мультитенантности (работы не-
скольких клиентов на одном сервере), то смогли бы предложить им более легкий и
дешевый старт. Но архитектура была уже зафиксирована, Осознанно отказавшись от
этой опции на этапе проектирования мы сделали ошибку которую уже не смогли ис-
править в будущем. Это стало для нас важнейшим уроком.
Следует понимать, что на этапе видения надо помнить про законы той страны, доя
которой создается продукт.
Совет новичку
Если вы собираете персональные данные граждан РФ их запись, хранение и использова-
ние должны происходить на серверах, физически расположенных на территории России.
Для работы в отдельных отраслях (например, строительство, транспорт, торговля)
продукт должен быть интегрирован с государственными сис1емами (например, ГИС
ЖКХ, ЕГАИС, Маркировка). Эти интеграции сложны, требуют сертификации и могут
сильно повлиять на сроки и бюджет.
Видение продукта— это инвестиция в будущее продукта. Глубокое и вдумчивое
прохождение этого этапа с привлечением всех заинтересованных сторон (бизнес,
маркетинг, разработка) позволяет избежать дорогостоящих переделок, заложить
масштабируемую архитектуру и создать продукт, который действительно решает
проблемы пользователя и приносит прибыть.
Стратегия и карта продукта
Если видение продукта отвечает' на вопрос «что и зачем?», то стратегия и карта
продукта — на вопрос «куда?».
♦ Стратегия продукта (Product Strategy) — это перечень задач, благодаря реали-
зации которых мы придем к тому продукту, который будет востребован. Это не
просто список фич, а ответы на ключевые вопросы:
• На чем фокусируемся? На привлечении новых пользователей или ка удержа-
нии текущих?
• Как будем побеждать? За счет низких цен, современного красивого интер-
фейса, уникальной функциональности или интеграции с Госуслугами?
• Какие гипотезы проверяем?
♦ Карта продукта (Product Roadmap) — обычно составляется на срок 6-12 месяцев
Нужно понимать, что оценок еще нет, и это не жесткий план, а скорее ориентир.
Совет новичку
Продуктовая карга (roadmap) — это не юридический документ, а инструмент коммуни-
кации с бизнесом и командой. Он должен меняться, когда вы получаете новые данные
Проектирование решения
На этом этапе мы переходим к ответу на вопрос «как?».
Что здесь происходит?
♦ Дизайнеры создают UX-прототипы— прообраз будущего интерфейса. Показы-
вают, как пользователь будет выполнять сценарии.
♦ Архитекторы проектируют техническое решение: сколько будет сервисов и как
они станут взаимодействовать, какие базы данных будут использоваться, как
обеспечить безопасность.
♦ Аналитики детализируют логику: «Если пользователь нажал сюда, система
должна проверить его права в а затем...».
Риски этапа в России:
♦ Неучтенная интеграция Спроектировали красивый личный кабинет, но забыли,
что для входа через Госуслуги нужна отдельная интеграция.
♦ Типовой ИХ. Скопировали интерфейс западного продукта, не учтя, что ваши
пользователи привыкли к другому расположению кнопок (например, из-за опы-
та работы с 1С).
Результат этапа: не просто макеты и схемы, а согласованное понимание между биз-
несом, дизайнерами и разработчиками.
Оценка и запуск в разработку
Цель этапа оценки — оценить затраты, риски. Цель установочной встречи (kick-
off) — принять решение о том, пойдет лн продукт в работу.
СОВЕТНОВИЧКУ
Важно разделять эти два этапа, оценка и установочная встреча Оценка предшествует
установочной встрече. Не стоит на этапе кик-офф заниматься переоценкой, т. к. это
снизит доверие команды к процессу
Установочная встреча— это старт работы, цель которого— добиться четких дого-
воренностей.
♦ Присутствуют все участники: менеджер, дизайнер, аналитик, разработчики, тес-
тировщики. Могут присутствовать и стейкхолдеры (заинтересованные стороны).
♦ Менеджер показывает цель и ценность проекта («Мы делаем это. чтобы завое-
вать 10% ресторанного рынка»).
♦ Дизайнер и аналитик показывают, что и как будет работать.
♦ Архитектор озвучивает ключевые технические решения и план работы.
Здесь желательно получить ответ на главный вопрос: все ли понимают свою пер-
вую задачу и друг друга?
Если после установочной встречи у команды больше вопросов, чем ответов —
встреча прошла впустую. Идеальный итог — когда разработчики уже могут начать
рабогу без лишних уточнений.
4.1.2. Развитие программного продукта
Развитие программного продукта — это вторая фаза его жизненного цикла. Она
наступает после первого успешного релиза. Это самый длинный и динамичный
этап, который продолжается до тех пор, пока продукт остается востребованным на
рынке.
Пример из жизни
Ярчайший пример продукта, который находится очень долго в стадии развития, — это
операционная система Microsoft Windows Мы пользуемся ей десятилетиями, даже не
задумываясь, что та же современная Windows— это результат непрерывного много-
летнего развития, при этом наследующая черты самых первых версий.
Почему нельзя просто «сделать и забыть»?
Поделюсь мыслью, которая иногда возникает у новичков. Может возникнуть иллю-
зия, что можно сделать один раз хороший продукт, реализовать в нем всё, что нуж-
но, и забыть. Это невозможно. Как только вы создадите «идеальный» продукт,
пользователи сразу же захотят изменений, в продукте выявятся ошибки, и развитие
будет продолжаться.
Вот, что происходит:
♦ постоянный поток обратной связи от реальных пользователей выявляет новые
потребности и недочеты, которые невозможно было предвидеть на этапе проек-
тирования;
♦ меняется рынок: появляются новые конкуренты, технологии и законодательные
требования (особенно это актуально для РФ с постоянно меняющимися требо-
ваниями в финтехе и e-commerce);
♦ технический долг: решения, которые были оптимальны на старте, со временем
требуют пересмотра и рефакторинга, чтобы система оставалась гибкой и под-
держиваемой. Часто у продуктов заканчивается срок поддержки, и их использо-
вание становится просто небезопасным.
Ключевые процессы этапа развития
Приведу основные этапы, которые характерны практически для любого продукта,
который находится на этапе развития
Планирование итераций
Развитие продукта идет не хаотично, а циклами (итерациями). В зависимости от
методологии команды (Scrum. Kanban) эти циклы длятся от 1 до 4 недель. На пла-
нировании команда вместе с менеджером решает, какие функции из бэклога про-
дукта будут разработаны в следующей итерации.
Совет новичку
На этом этапе вы научитесь работать с бэклогом продукта. Вы увидите, как часто ме-
няются в нем задачи и приоритеты по каждой задаче Что вчера было «срочно», сего-
дня уже может быть не интересно. Будьте готовы к таким изменениям.
Регулярные выпуски обновлений
Если у продукта стабильный и предсказуемый процесс выпуска новых версий, то
это признак зрелой команды. Если процесс непонятен, непредсказуем, то это, ско-
рее, стартап.
Совет новичку
Частые и небольшие обновления обычно лучше, чем редкие и громоздкие, т. к. .ни
позволяют быстрее получать обратную связь и снижают риски
Мониторинг и аналитика
Запуск фичи — это не конец работы, а начало никла отслеживания (мониторинга).
Крайне важно отслеживать, как новые функции используют клиенты. Это могут
быть либо специальные встроенные механизмы, либо универсальные (например,
Яндекс Метрика). Если не отслеживать метрики и использование функций, то мож-
но погрязнуть в поддержке функций, которые никто не использовал.
Пример из жизни
Мы несколько раз в продукте убирали неиспользуемую на наш взгляд, функциональ-
ность Ей было уже несколькс лет, и не было никаких оснований полагать, что ее к го-то
применяет В тот момент у нас еще не было информации о том, что именно использует-
ся в продукте. Но в итоге оказалось, что некоторые клиенты задействовали функцио-
нальность необычным образом и завязывались на нее, используя не по прямому назна-
чению В итоге мы были вынуждены в срочном порядке возвращать функциональность
назад или искагь альтернативные варианты решений бизнес-запросов у клиентов.
Поддержка и эксплуатация
Продукт должен не только развиваться, но и стабильно работать. Этим занимаются
DevOps/SRE-инженеры и команда поддержки. Их работа— обеспечивать доступ-
ность, производительность и быстрое решение инцидентов.
Учитывайте российскую специфику При работе с госсектором или крупными кор-
порациями будьте готовы к длительным процедурам приемки. Это особенно акту-
ально для продуктов, которые устанавливаются на серверы заказчика («on-premise»).
Совет новичку
Этап развития— лучшее время для профессионального роста Вы увидите полный
цикл работы над продуктом, научитесь работать с обратной связью и поймете, как
теория из учебников применяется в реальных условиях Ваша задача на этом этапе —
быть гибким, любознательным и не бояться предлагать улучшения.
Итак, мы увидели, что этап развит ия — эго непрерывный поток доработок и ис-
правления ошибок. Но как выглядит процесс работы над каждым таким этаном?
Этот процесс и описывает жизненный цикл разработки — тот самый мини-цикл,
который повторяется снова и снова для каждой новой задачи внутри этапа развития
продукта.
Жизненный цикл разработки: основные этапы
Давайте рассмотрим эти этапы на примере разработки функции «Онлайн-прсдзаказ
столика» для приложения ресторана
1. Аналитика — сбор требований, их согласование с заказчиком и формирование
задачи на разработку.
Владелец ресторана хочет уменьшить количество звонков и позволить гостям
бронировать столики онлайн. Аналитик выясняет: нужно ли показывать схему
зала? Нужна ли предоплата? Как долго удерживать бронь? Формулируется зада-
ча: «Реализовать возможность бронирования столика на конкретное время через
мобильное приложение».
2. Разбор задачи с командой — на основании собранных требований происходит
детальный разбор, уточнение деталей задачи и выявление упущенных требований
На встрече выясняется, что администраторам нужна панель управления бронями
(подтверждение, отмена). Также нужно продумать, что делать, если гость опаз-
дывает, — нужны ли уведомления?
3. Исследование способов решения задачи — на основании собранных и согла-
сованных требований проводится исследование, как задачу можно решить,
сколько на это потребуется времени. Этот этап не является обязательным и ну-
жен, только если команда разработки не может оценить задачу или не знает, как
лучше это сделать.
Разработчики исследуют: использовать ли для уведомлений SMS (дорого, но на-
дежно) или push-уведомления (дешевле, но пользователь может их отключить)?
Как интегрировать систему брони с графиком работы официантов?
4. Проектирование архитектуры решения задачи — формирование архитекту-
ры будущего решения.
Техлид решает: создать отдельную таблицу в базе данных для бронирований,
разработать API для создания/отмены брони, продумать, как приложение будет
в реальном времени проверять свободные столики.
5. Программирование задачи — непосредственно программирование.
Фронтенд-разработчик верстает экраны выбора даты, времени и количества гос-
тей. Бэкенд-разработчик пишет логику проверки доступности столиков и записи
брони в базу данных.
6 Ручное тестирование — проверка на соответствие требованиям задачи. Тем са-
мым, что были описаны и согласованы на этапе аналитики + дополнительным
сценариям
Тестировщик проверяет: можно ли забронировать столик на нужное время?
Корректно ли приходит SMS-подтверждение? Проверяются также отрицатель-
ные и альтернативные сценарии: можно ли забронировать столик на прошед-
шую дату? Что будет, если два человека одновременно попробуют заброниро-
вать последний столик?
7. Регрессионное тестирование — проверка, корректно ли работает вся ранее
реализованная функциональность.
Тестировщик проверяет, что новая функция бронирования не сломача работу
корзины, меню и процесса оплаты еды навынос.
8. Демонстрация функциональности — всем заинтересованным лицам демонст-
рируется работа задачи.
Команда показывает владельцу ресторана готовую функцию в работе: как кли-
ент бронирует столик и как новая бронь появляется на планшете у администра-
тора.
9 Выпуск версии — после веек успешных проверок и исправления замечаний
все нужные задачи собираются для выпуска в версии.
Функция «Онлайн-бронирование» вместе с исправлением нескольких мелких
багов в меню упаковывается в обновление приложения версии 2.1.
10. Развертывание после успешного выпуска версии, для того чтобы функцио-
нальность появилась у клиента, необходимо произвести развертывание (уста-
новку) новой версии программного продукта.
Версия 2.1 публикуется в магазинах приложений (Лрр Store, Google Play). Адми-
нистраторы ресторана устанавливают обновление на свой планшет управления.
11. Документирование— этап подготовки описания (статья, видео), что это за
функциональность, как ей пользоваться, как настроить и, возможно, сообщения
о типовых проблемах.
Создается страница в базе знаний: «Как управлять бронированиями столиков» для
администраторов и «Как забронировать столик через приложение» дея гостей.
В зависимости от типа программного обеспечения могут быть также выделены и
дополнительные этапы.
1. Резрессионное тестирование версии— этап, на котором осуществляются по-
вторно цикл тестирования и выявляются ошибки.
Перед тем как отдать обновление владельцу ресторана, тестировщики еще раз
полностью проверяют все основные возможности приложения (заказ еды, опла-
та, акции, личный кабинет) с уже включенной в него функцией бронирования.
Этот этап может (и должен) быть автоматизирован, то есть выполняться не руч-
ным тестированием, а специальными инструментами, в которых все нужные
действия производятся роботом.
2. Приемка версии — этап, когда клиент, которому версия планируется к уста-
новке, осуществляет ее приемку.
Владелец ресторана лично тестирует функцию бронирования на тестовом стен-
де: создает несколько броней, отменяет их, проверяет уведомления. Только по-
сле его письменного подтверждения «всё работает, как я ожидал» новая версия
запускается для всех гостей.
Когда развитие замедляется...
Рано или поздно каждый продукт достигает стадии зрелости:
♦ основные потребности пользователей удовлетворены;
♦ рынок насышен;
♦ стоимость разработки новых значимых функций начинает превышать потенци-
альную выгоду.
На этом этапе команда переключается на режим поддержки: исправление критиче-
ских багов и обеспечение безопасности. Это сигнал о том, что продукт приближа-
ется к завершению своего жизненного цикла.
4.1.3. Смерть программного продукта
Любой продукт рано или поздно умирает. Иногда это естественно — пользователи
переходят на новые решения или технологии устареваю!. Иногда— болезненно:
бизнес теряет источник дохода, а команда вынуждена поддерживать продукт, кото-
рый давно пора было закрыть.
Смерть продукта может быть быстрой — например, когда старое решение созна-
тельно заменяют новым.
Но гораздо хуже долгая и мучительная смерть, когда компания продолжает нести
расходы на поддержку устаревшей системы, а найти специалистов, способных ее
обслуживать, становится всё труднее.
Пример из жизни
В 2024 году немецкие железные дороги разместили вакансию системного администра-
тора, который должен уметь работать с Windows 3.11 и, желательно, с MS-DOS.
Это не шутка, а реальность: крупные организации не всегда могут позволить себе
замену старых систем, потому что их модернизация стоит миллионов.
В мире enterprise-разработки смена продукта— это всегда деньги. Очень большие
деньги.
И если разработчик сталкивается с «устареванием технологий», то для клиента это
не его проблема, а проблема компании-разработчика.
Ни одна команда не хочет терять клиента только из-за старой платформы — и по-
этому многие продукты продолжают поддерживаться еще долго после того, как
морально устарели.
Иногда «смерть» продукта— благо: она освобождает ресурсы и позволяет сфоку-
сироваться на создании нового решения, на новых технологиях и с новыми идеями.
Важно лишь одно — вовремя распознать момент, ко1да развитие продукта уже не
создает ценности.
Пример из жизни
В 1998 году проект Newton MessagePad был закрыт Стивом Джобсом вскоре после его
возвращения в Apple Несмотря на всю болезненность этого решения, оно позволило
компании сфокусироваться на создании iMac и, позднее, на iPhone и iPad, которые,
как мы все знаем, стали супервостребованы и популярны
Почему в принципе продукты умирают?
Существуют разные причины, почему программные продукты умирают
Технологическое устаревание
Библиотеки, используемые в разработке, перестают поддерживаться, серверы —
обновляться, архитектура — выдерживать нагрузку или иные запросы пользовате-
лей. В конце концов это приводит к тому, что пользоваться становится небезопасно.
Пример
Беб-приложение на старой версии PHP или AngularJS становится небезопасным а
перенос на новую платформу стоит дороже, чем разработка с нуля
Потеря рынка
Появляются новые конкуренты с лучшей рекламой, удобством пользования, более
быстрой доставкой ценности или агрессивной ценовой политикой.
Пример
Многие локальные CRM-сисемы были вытеснены современными облачными реше-
ниями. работающими по подписке.
Изменения законодательства
Особенно актуально в России. Законы о персональных данных, маркировке, инте-
грациях и налоговой отчетности меняются быстро. Иногда старый продукт просто
не может быть адаптирован под новые требования.
Экономическая неэффективность
Если на поддержку продукта уходит больше, чем он приносит, то продукт проще
закрыть, чем поддерживать.
Часто такое происходит с продуктами, которые поддерживаются по инерции, по-
тому что у нескольких клиентов решение работает и решает их задачи.
Как умирает продукт на самом деле?
Смерть продукта — это не просто точка, это процесс, который может затянуться по
времени.
♦ Этап остановки в развитии.
• Команда прекращает добавлять новые функции, оставляя только критические
исправления.
• Первые признаки: roadmap исчезает, релизы становятся редкими, команда со-
кращается
♦ Этап вывода из эксплуатации.
• Компания официально объявляет дату' окончания поддержки (EOL, End of
Life).
• Хороший тон — дать клиентам от 6 до 24 месяцев для перехода.
♦ Этап миграции пользователей.
• Очень здорово, если организация не просто юворит о том, что поддержка
прекращается, а предлагает альтернативу свой новый продукт, партнерское
решение или инструкции по переходу на другой продукт.
• На этом этапе важна коммуникация, иначе компания может потерять доверие
клиент ов.
♦ Техническое отключение.
• Закрытие серверов, архивирование данных, удаление инфраструктуры
• Если продукт работает локально: передача документации, снятие обяза-
тельств по обновлениям.
Российская специфика
В России «смерть продукта» часто растягивается на годы. Так происходит по сле-
дующим причинам:
♦ Клиенты госсектора и крупного бизнеса требуют длительной поддержки, даже
если продукт устарел. Именно они диктуют условия, а зачастую небольшие
компании разработки не могут отказаться от крупных клиентов
♦ Миграция на новое ПО может требовать повторной сертификации, что усложня-
ет отказ. Для бизнеса сертификация — это деньги, опять же не все могут себе
позволить вложиться заново и пройти все обязательные этапы.
♦ Некоторые компании вынуждены поддерживать работу на устаревших техноло-
гиях из-за отсутствия совместимых решений.
Пример из жизни
Одна компания много лет развивала складскую систему, написанную на устаревшем
фреймворке Со временем стало очевидно, что поддержка стоит дороже новых про-
даж. Разработка новой версии продукта (фактически новое решение) велась парал-
лельно, но клиенты госсектора отказались на нее переходить — требовалось заново
проходить сертификацию а эю дорого и долго
В итоге продукт поддерживали еще целых четыре года после официального закрытия,
пока последний клиент не подписал акт о миграции. Техническая смеоть наступила
только спустя 7 лет после решения о прекращении развития.
Совет новичку
Не бойтесь того, что у продукта наступает «смерть». Дольше всего живут не те компа-
нии. которые держатся за прошлое, а те, которые умеют создавать новые актуальные
решения.
В этом вопросе, на мой взгляд, допустима прямая аналогия с эволюцией живых су-
ществ, и хорошо описывает ситуацию цитата из Чарльза Дарвина: «Выживает не
самый сильный и не самый умный, а тот, кто лучше всех приспосабливается к из-
менениям».
Закрытие продукта должно рассматриваться как шаг к созданию нового решения,
которое заменит старое.
Важно понять, что смерть программного продукта— это не катастрофа, а законо-
мерный финал жизненного цикла. Большинство решений не живут вечно: они ста-
реют технологически, теряют аудиторию, становятся нерентабельными или заме-
няются более современными альтернативами.
4.2. Роль каждого участника на разных этапах
На разных этапах жизненного цикла продукта в нем принимают участие разные
специалисты. Нужно понимать, что одни и те же специалисты при этом занимают
принципиально разные позиции: где-то главный тот, кто пришел с идеей, а техни-
ческие специалисты, скорее, советуют. Где-го, наоборот, основная нагрузка на ин-
женеров Далее рассмотрены этапы и разные роли участников с описанием того,
кто и что делает на каждом этапе.
4,2.1. Идея и рождение продукта
На этом этапе главное — проверить, что идея не умрет сразу после запуска.
♦ Бизнес-заказчик, или стейкхолдер.
Формулирует бизнес-идеи и ограничения: зачем решение нужно компании, ка-
кой результат ожидается, какие есть бюджетные и временные рамки Именно он
формирует идею — например; «удержать аудиторию молодых людей до 30 лет»
или «выйти в новую страну».
♦ Менеджер продукта (Product Manager / Product Owner).
Фиксирует проблему, которую нужно решить, в виде понятной и достижимой
цели. Он же проводит интервью с потенциальными пользователями, анализиру-
ет рынок и конкурентов. Формирует видение продукта — что создается и поче-
му. Менеджер продукта должен найти и предоставить доказательства и обосно-
вания, почему цель будет достигнута. Тут недостаточно лозунгов — нужен кон-
кретный план
♦ Бизнес-аналитик (БА).
Переходит от цели, которую озвучил и согласовал РМ, к конкретным задачам.
Бизнес-аналитик по кусочкам раскладывает цель и формирует уже некое про-
дуктовое описание. Оно уже гораздо более объемное и большое, и именно тут
появляется достаточно четкое понимание, что все-таки будет получено БА по-
стоянно взаимодействует с РМ, и. в целом, это может быть один и тот же человек.
♦ Технический лидер (архитектор).
Оценивает техническую реализуемость идеи, потенциальные риски, требования
к инфраструктуре и стоимости разработки. Предупреждает о сложных или неоп-
равданно дорогих решениях. Его задача — вовремя сказать: «Ребята, ваша фича
потребует серверов, которые стоят как крыло от Boeing, Вы уверены, что клиен-
ты будут готовы столько платить за инфраструктуру? Может, упростим?»
♦ Юрист (эта роль ранее не упоминалась, т. к. он обычно нс участвует в разработ-
ке, но, как показывает практика, наличие IT-юриста крайне необходимо, особен-
но в России).
Юрист проверяет требования законодательства (например, в России — это 152-
ФЗ, отраслевые регуляторы, лицензии, интеграции с государственными систе-
мами). Он сразу говорит: «Работаете с персональными данными? Помните про
152-ФЗ и серверы в РФ. Это финуслуга? Готовьтесь к лицензии ЦБ. Интеграция
с госорганами? Значит, будет ЕСИА».
Совет новичку
Если вы разработчик или тестировщик, на этом этапе вас могут не позвать. Но если
позвали — слушайте! Понимание, зачем создается продукт, поможет вам потом при-
нимать верные решения в коде и тестах.
4.2.2. Проектирование решения
После проверки идеи команда переходит к детализации будущего продукта.
♦ Дизайнер.
Формирует интерфейсы .для пользователя Создает образ продукта, который по-
зволяет понять, как продукт будет выглядеть и как пользователь станет взаимо-
действовать с продуктом. Он рисует не просто красивые картинки, а прототи-
пы — макеты, по которым можно понять, как пользователь будет решать свои
задачи. Дизайнер следит, чтобы кнопки были на привычных местах (учитывая,
например, что пользователи 1С привыкли к одному, а пользователи VK— к
другому).
♦ Бизнес-аналитик.
Детализирует логику работы, правила, сценарии, условия, последовательность
действий системы. Оформляет требования, которые лягут в основу технических
задач. Детализация логики может выглядеть, например, так: «Если пользователь
нажал "Забронировать”, система должна проверить его права, затем послать за-
прос в базу...»
♦ Архитектор и ведущие разработчики.
Определяют архитектуру и создают основу продукта. Решают, сколько будет
сервисов, как они станут общаться, какую базу данных выбрать, как обеспечить
безопасность. Именно они закладывают те основы, которые потом позволят (или
не позволят) продукту' масштабироваться.
♦ Менеджер продукта.
Следит, чтобы решение соответствовало Product Vision, принимает решения о
приоритетах и компромиссах между ценностью и сложностью реализации.
Именно он принимает непростые решения: «Да, эта фича очень крутая, но без
нее можно прожить в первой версии, чтобы успеть к запуску к указанному сроку».
4.2.3. Оценка и запуск в разработку
На этом этапе команда подтверждает понимание продукта и оценивает объем работ.
♦ Менеджер
Организует kick-off, фиксирует договоренности, проверяет, что все участники
одинаково понимают требования и свою первую задачу.
♦ Разработчики и тестировщики.
Задают уточняющие вопросы, выявляют скрытые риски, оценивают трудоем-
кость. Формируют реалистичные сроки выполнения задач. Они смотрят на зада-
чи и прототипы и задают уточняющие вопросы; «А что если два человека одно-
временно забронируют один столик? А как мы будем обрабатывать ошибки от
SMS-шлюза?».
♦ Вся команда.
Результат успешного ктск-off возможность начать разработку без многочис-
ленных уточнений и переделок
4.2.4. Разработка, тестирование и выпуск версии
Этап активной инженерной работы. Самый длинный и интенсивный этап Тут глав-
ные — инженеры.
♦ Разработчики (Frontend, Backend, Mobile).
Реализуют функциональность, проводят код-ревью, участвуют в технических
обсуждениях, поддерживают качество кода. Приходят к менеджеру, предлагают
более удачные решения и честно говорят о проблемах.
♦ Тестировщики (QA).
Проверяют соответствие реализации требованиям, ищут ошибки, проводят рег-
рессионное тестирование и обеспечивают качество перед выпуском. Они дума-
ют не только о «белых» сценариях, но и о том, что будет, если пользователь ста-
нет испытывать систему на прочность. Их главный страх — выпустить баг, ко-
торый все увидят.
♦ DevOps / SRE-инженеры.
Отвечают за инфраструктуру, CI/CD, безопасность, развертывание и стабиль-
ность окружений. Обеспечивают техническую сторону выпуска новых версий.
Именно на них лежит забота о том, чтобы новую версию можно было легко и
безболезненно установить.
♦ Менеджер продукта.
Уточняет приоритеты, обновляет бэклог, взаимодействует с заказчиками и сле-
дит за тем, чтобы команда двигалась в нужном направлении.
♦ Аналитик и дизайнер.
Отвечают на вопросы, уточняют требования, корректируют при необходимости
прототипы, чтобы функциональность соответствовала ]ребованиям. Очень часто
так бывает, что из-за сложности требования пересматривают, и тогда аналитики
и дизайнеры должны эти требования отразить.
♦ Российская специфика.
На этом этапе могут появиться незапланированные интеграции с государствен-
ными или отраслевыми системами (например, ГИС ЖКХ) — это усложняет ар-
хитектуру и требует участия опытных специалистов.
4.2.5. Развитие и поддержка продукта
После выхода первой версии начинается этап, который длится дольше всех.
♦ Менеджер продукта.
Отслеживает метрики и поведение пользователей, принимает решения о даль-
нейших у тучшениях, оптимизациях и новых функциях Решает, что улучшать
дальше: добавить новую функцию, которую так хотел заказчик, или сначала пе-
ределать тормозящий старый модуль?
♦ Разработчики и тестировщики.
Работают итерациями: улучшают продукт, исправляют ошибки, устраняют тех-
нический долг. На этом этапе начинается борьба с техническим долгом— накоп-
ленными «костылями» в коде, которые мешают развивагься.
♦ DevOps / SRE.
Обеспечивают стабильность работы иод на1рузкой, мониторинг и оперативное
решение инцидентов. Следят, чтобы система не «упала» под нагрузкой. Для рос-
сийских продуктов, особенно в госсекторе, они же обеспечивают соответствие
требованиям к хранению данных.
♦ Служба поддержки (Support).
Первой получает обращения пользователей, помогает выявлять реальные про-
блемы и передает информацию команде. Они первые, кто слышат крики пользо-
вателей о том, что «всё сломалось».
4.2.6. Завершение жизненного цикла
Когда продукт перестает быть востребованным или экономически оправданным,
начинается его завершение.
♦ Менеджер продукта.
Определяет сроки окончания поддержки (EOL), уведомляет клиентов, описыва-
ет возможные варианты миграции
♦ Аналитики и разработчики
Готовят инструкции по миграции данных, архивируют необходимые компонен-
ты, обеспечивают возможность безопасного завершения использования продук-
та Делают всё, чтобы клиент мог уйти без боли.
♦ DevOps.
Отключают сервисы, архивируют данные, завершают работу инфраструктуры.
♦ Юрист.
Контролирует соблюдение договорных обязательств и требований законода-
тельства при закрытии продукта.
♦ Российская специфика.
В сегменте госсектора закрытие продукта может занимать годы из-за требова-
ний сертификации и сложности миграции. Команда иногда вынуждена поддер-
живать устаревшие решения значительно дольше, чем планировалось.
4.2.7. Вывод
Командная работа — основа успешного продукта. Понимание ролей на каждом
этапе помогает участникам принимать правильные решения и видеть продукт не
как набор задач, а как целостную систему.
Совет новичку
Ча каждом этапе разработки вы будете сталкиваться с задачами, которые выходят за
рамки вашей роли. Не бойтесь интересоваться тем, что делают коллеги: как аналитик
формирует требования, почему дизайнер выбрал определенный сценарий, как разра-
ботчики оценивают сложность, почему DevOps настаивает на дополнительных про-
верках. Чем лучше вы понимаете работу соседних ролей, тем быстрее сможете расти
как специалист Главное — задавайте вопросы и не ограничивайтесь только своей ча-
стью задачи: продукт создается командой, а не отдельными исполни 1 елями.
4.3. Основные принципы разработки
Существует достаточное количество принципов, которых нужно придерживаться
при разработке ПО. Я расскажу про те, которые будут полезны именно новичкам. А
опытным IT-специалистам будет не лишним про них тоже вспомнить.
4.3.1. KISS
Принцип KISS (Keep It Simple, Stupid) я поставил на первое место. Если не стре-
миться к дословному переводу, я бы перевел его как «делай проще».
При проектировании и разработке решении иногда бывает так, что сразу «заклады-
ваются на будушее». То есть разработчик использует не самые простые методы,
алгоритмы или подходы и обязательно находит для этого аргументы Например:
«так гибче» или «завтра это можно будет легко расширить». В проектируемом ре-
шении при этом появляются какие-либо избыточные или неочевидные модули —
например, чтобы «система выдерживала нагрузку».
Аналогия из жизни
Я хочу сделать омлет Мне нужны его компоненты: яйца, молоко, соло и масло для
жарки А также инструменты: например, миска, венчик и сковорода Чтобы приготовить
омлет, я использую минимум действий: разбиваю яйца добавляю молоко и соль,
смешиваю всё это венчиком и выливаю на сковороду. Из грязной посуды у меня оста-
ются миска, венчик и сковорода.
Но чтобы приготовить тот же омлет, можно использовать и мноюфункциональный
комбайн Из тех же продуктов получится тот же самый омлет, но мороки вокруг ком-
байна будет больше. Скорее всего, он куда-тс убран, потом не собран, и нужно найти
ту самую подходящую насадку, затем искать розетку включать и тратить электричест-
во, пару секунд использовать и, возможно, мыть потом все задействованные элементы.
И все же это не значит, что многофункциональный комбайн вовсе не нужен — нужен,
полезен, но для своих целей. Например, чтобы сделать безе из 1 1 яичных белков, на-
до получить устойчивую густую пену Делать такое вручную тяжело, а комбайн отлич-
но справится.
К сожалению, со сложными решениями приходится потом жить. Не стоит думать,
что такие решения принимаются недостаточно опытными разработчиками, — на-
против, часто бывает, что разработчик обладает большим опытом, разносторонни-
ми знаниями и предлагает, на его взгляд, «оптимальные» решения. На практике же
выходит, что потом работать с этими решениями как пользователям, так и осталь-
ным разработчикам сложно. Они не понимают, к чему была придумана именно та-
кая архитектура, зачем в ней столько слоев, сложностей, компонентов и т. д.
Принцип KISS следует относить не только к проектированию и разработке, но и к
требованиям к продукту. Помним, что продукт должен быть такой сложности, что-
бы обеспечивать те требования, которые к нему предъявляют. Если продуктовая
команда приносит завышенные требования (функциональные или нефункциональ-
ные), то иногда только это приводит к сложным решениям. Нужно критически оце-
нивать требования, которые усложняют архитектуру или код. Если требования не
основаны на каких-то аргументах, экспериментах, а просто взяты из головы, но при
этом существенно влияют на решение, то начните с упрощения.
Обращаю ваше внимание на то, что принцип KISS нс говорит, что всё должно быть
обязательно примитивно. Он означает, что предлагаемые решения должны быть
сопоставимой сложности. Если задача простая, используйте простые способы.
Примеры из жизни
Вспомните первые пульты дистанционного управления На них можно было насчитать
дс 50 кнопок (возможно, кто-то помнит или видел такие пульты с кнопками «INDEX»,
«OSD». «С1 'В», «A/В») Управлять с его помощью телевизором было сложно, хотя по
факту хватало и 10 кнопок. Но у нас дома даже имелась тетрадь с описанием того, как
правильно настроить каналы и что какая кнопка делала В современном! мире, где ка-
нал можно переключить голосом, подобные решения кажутся чрезмерно сложными.
Возьмем другой пример, поисковая страница Google На ней нет ничего лишнего!
И если это не эталон, то точно одно из лучших решений, которое однозначно подска-
зывает пользователю, куда чбить слово для поиска
Совет новичку
Делайте проще: сначала работающее решение, затем — красивое. Не делайте слож-
ных решений без веской причины.
4.3.2. YAGNI
Принцип YAGNI (You Aren’t Gonna Need It) — второй в моем личном рейтинге по-
сле KISS.
Буквально он означает «вам это не понадобится». Принцип YAGNI говорит о том,
что надо делать ровно ту функциональность, которая требуется. На мой взгляд, он
крайне близок к принципу KISS. Смысл его в том, чтобы не «делать на всякий слу-
чай». То есть, опять же, не делать «на будущее» или «впрок».
Что раздражает при разработке? Изменения требований, особенно в задаче, которая
почти готова. Если продуктовая команда постоянно меняет требования, что-то до-
бавляет. передумывает, го иногда это приводит к существенным переделкам. А кто
же любит переделывать работу, которая вот-вот закончится? Разработчики, когда
часто с таким встречаются, начинают перезакладываться, то есть делать работу с
запасом, на случай, если завтра появится новое требование.
Но иногда продуктовая команда не меняет требования, а разработчики просто так
делают «на будущее».
Примеры из жизни
Возможно, вы r-спомните версию Microsoft Word, в которой были такие функции, как
вставка буквицы (декоративная первая буква абзаца), панель инструментов «Резюме»
(вы, скорее всего ими не пользовались), множестве редко используемых шаблонов.
В итоге пользователи не использовали функции, продукт потреблял всё больше памя-
ти, удобства падало, недовольство росло.
С выходом Office 2007 был реализован и упрощенный интерфейс. Но до этого компа-
ния потратила тысячи часов на создание того, чем практически никто не пользовался
В этой книге не рассмотрены такие принципы проектирования, как, например,
SOLID. Их полезно знать и применять на практике, но думаю, что о них будет рас-
сказано в других книгах —- по проектированию. А я все-таки использую принцип
YAGNI и не добавлю в эту книгу лишнего «на всякий случай».
Совет новичку
Не делайте «на всякий случай» Сделайте ровне то, что просят сегодня, а то, что по-
просят завтра, — это завтрашняя задача
4.3.3. DRY
Принцип DRY (Don't Repeat Yourself) — «не повторяйся».
У каждой части системы, которая выполняет какую-либо функцию или решает за-
дачу, должно быть единственное место реализации. Дублирование не только кода,
но и логики, и даже конфигурации, обязательно ведет к ошибкам и сложностям при
изменении. Многие думают, что этот принцип для программистов На самом деле
нет — он для всех, кто делает именно продукт. Не должно быть дублирующихся
функций или логики.
Я думаю, что те, кто пишут код или проектируют системы, понимают, как наруша-
ется этот принцип. Мы делаем что-то очень и очень похожее (или вообще одно и то
же) разными способами.
Почему это важно в России?
♦ Изменение регуляторных требований
Если закон (например, правило расчета НДС) изменился, а он был продублиро-
ван в 10 местах, вы гарантированно где-то забудете его поправить.
♦ Поддержка в условиях стресса.
При исправлении ошибок дублирование всегда вызывает проблемы. Вы точно
забудете исправить дубль где-либо еще.
Приведу пример ситуации, чтобы показать проблему, а затем расскажу, как решить.
Есть какая то система, которая должна валидировать ИНН. ИНН юридического ли-
ца— это 10 цифр, а физического — 12
Проверку можно сделать в трех местах: на визуальной части (frontend), на части
бизнес-логики (backend) или на уровне базы данных.
Худший вариант — сделать везде. Почему? Потому что в случае изменения форма-
та ИНН придется везде менять проверки в трех местах. Это будет как раз наруше-
ние принципа DRY.
Но где же правильно?
Сделать на frontend — кажется хорошей идеей, потому что пользователь не сможет
ошибиться при вводе. Минус решения: если появится возможность вносить данные
не через визуализацию (а они появятся, например, при импорте документов), при-
дется делать проверку в части бизнес-логики (backend) или на уровне базы данных.
Мы получили дублирование.
Тогда видит ся, что надо делать проверку на уровне БД, чтобы точно никаким обра-
зом не допустить проблему? Тоже нет, и вот почему.
База данных — самый сложный в масштабировании ресурс. Если вы заставляете
БД выполнять сложные вычисления (проверку ИНН) для каждой записи, вы трати-
те ее процессорное время. БД — это хранилище, а не место для бизнес-логики.
♦ Кроме того, проверка на уровне БД — это еще и плохой UX. При этом цепочка
ошибки выглядит так:
1. Пользователь заполнил форму.
2. Отправил запрос.
3. Бэкенд принял данные.
4. БД попыталась сохранить и выдала ошибку (например, Check Constraint
Violation).
5. Бэкенд должен «перевести» техническую ошибку БД в понятный текст и пе-
редать дальше.
6. Пользователь получил ошибку' спустя какое-то время, а не мгновенно.
♦ Добавим сложность тестирования.
Логику в коде легко покрыть unit-тестами. Тестировать логику внутри БД (триг-
геры, хранимые процедуры) гораздо сложнее — это требует поднятия всей ин-
фраструктуры БД.
♦ И версионирование.
Код бэкенда хранится в системе хранения (git)— его легко откатить или срав-
нить версии. Изменения в схеме БД (constraints) сложнее отслеживать и синхро-
низировать между разными окружениями (dev/test'prod).
Кажется, что нам остается только часть бизнес-логики (backend)?
В целом верно, но не совсем. Да. действительно, самым лучшим местом будет яв-
ляться именно бэкенд. Но! В идеале визуализация (фронтенд) и БД должны полу-
чать правила валидации из метаданных бэкенда, если это возможно.
Вы можете спросить. «Зачем тогда валидация на фронтенде, если бэкенд всё равно
проверит?»
Валидация на фронтенде нужна для удобства пользователя (UX). Пользователь
должен сразу понять свою ошибку еще до попытки отправки данных, а лучше —
даже на этапе ввода (например, подсветить ошибку красным цветом).
В БД тоже нужны проверки, но механизмы передачи с backend либо отсутствуют,
либо сложны. Поэтому для баз данных надо использовать ограничения (Constraints)
как рубеж зашиты целостности данных. Например, значение не должно быть MULL
и должно быть уникальным.
Совет для новичков
Иногда дублирование лучше, мем сложная связное гь. Посмотрите на то, что получается.
Если очень сложно, то вы делаете что-то не то. Решение должно быть лаконичным.
Отсюда вытекает еще один принцип — единого источника истины (Single Source of
Truth, SSOT). Согласно этому принципу, логика (в нашем случае — алгоритм вали-
дации ИНН) или данные должны определяться или храниться в одном месте. Все
остальные части системы, которым нужны эти данные или логика, обращаются к
этому источнику, а не хранят свою собственную копию или копию алгоритма.
4.3.4. Fail Fast
Принцип Fail Fast— «падай быстро». В изначальной версии принцип говорит о
том, что система, как только что-то пошло не так, должна прекратить работу и со-
общить об ошибке, а не пытаться продолжать работу.
Почему это важно?
♦ Экономия времени — лучше получить ошибку при вводе данных на форме сра-
зу, чем через какое-то время с негативом об использовании.
♦ Упрощение отладки — пользователю легче найти ошибку, когда она возникает
сразу в месте ввода данных, а не проявляется как странное сообщение в конце
всех действий (или вообще на другой вкладке).
♦ Предсказуемость системы — система ничего не говорит об ошибках, ведет себя
непредсказуемо.
Однако принцип «падай быстрое следует рассматривать шире, чем просто подход
по обработке ошибок в программе. Речь о быстрой проверке гипотез и ошибок. Ка-
кое бы вы ни придумали классное решение, вы всё равно можете ошибиться, и
лучше быстрее выпустить решение и проверить, работает ли оно так классно, как
изначально задумывалось, или нет. Лучше выпустить то, что сделано, и проверить,
действительно ли это то. что надо, чем месяцами отлаживать то. что в итоге будет
никому не нужно. Если вы ошиблись, то пойдете дальше в поисках следующих
правильных решений. Это соответствует духу Agile, о котором пойдет речь в главе 6.
Пример из жизни
Знали ли вы, что компания Netflix начинала с проката DVD по почте9 В компании тес-
тировали разные модели подписки и взаимодействия с клиентами В связи с развити-
ем скорости Интернета и снижением стоимости стало понятно, что будущее— за
стримингом В настоящее аремя Netflix — очень успешная компания.
* * *
Есть еще множество разных принципов, с которыми вы будете знакомиться по мере
своего профессионального роста, но с нарушением упомянутых здесь принципов
вы будете сталкиваться постоянно, и нужно помнить про них всегда.
-Глава 5-
Безопасность в разработке
программного обеспечения
Безопасность ПО — это область, которую часто считают сложной и неинтересной.
Это происходит потому, что требования безопасности объективно противоречат
основным целям бизнеса и разработки они замедляют вывод продукта на рынок,
увеличивают затраты и заставляют инженеров переделывать уже созданные реше-
ния. что воспринимается как препятствие и рутина. Со мной не согласятся, пожа-
луй, только специалисты по информационной безопасности. Но. тем не менее, во-
прос безопасности ПО пропустить нельзя. Безопасность — важная составляющая
любого продукта, и ею надо заниматься, несмотря пи на что! Часто про безопас-
ность в ПО начинают вспоминать слишком поздно, когда уже возникла какая-то
проблема — в .лучшем случае при проведении аудита, а в худшем — после утечки
или потери данных или вообше остановки в работе. Такое особенно актуально в
молодых проектах и небольших компаниях, поскольку крупные компании или
имеют своих специалистов по безопасности, или научены жизненным опытом.
Важно сразу зафиксировать: безопасность — это не отдельный этап в разработке
ПО (хотя в проектах этап «аудит безопасности» действительно может явно выде-
ляться) и не зона ответственности одного специалиста (например, часто думают,
что это некий инженер по безопасности). Безопасность напрямую зависит от того,
какие требования заложены в продукт, как проектируется система, какие компо-
ненты выбираются, как пишется код. И на каждом этапе команда делает какие-то
допущения, которые в итоге могут приводить к проблемам в безопасности.
Например, не заложенное на этапе аналитики требование о том, что все действия
пользователя должны сохраняться в специальном журнале аудита и храниться там
какое-то время, приведет к тому, что впоследствии нельзя будет выяснить, кто же
конкретно допустил ошибочное действие и как именно это действие было совер-
шено. Аналогично и разработчики мог^л не подумать об SQL-уязвимостях, что мо-
жет привести к потере части данных.
5.1. Базовые принципы безопасности
при разработке
В реальных проектах проблемы с безопасностью редко возникают из-за злого
умысла. Гораздо чаще это результат спешки, недооценки рисков или классического
желания менеджеров «сделать попроше и побыстрее».
Примеры из жизни
• В лог добавили конфиденциальную информацию (ключ, пароль) для отладки и за-
были удалить.
• Тестовый пароль попал в конфигурацию и ушел в репозиторий.
• Сервису выдали расширенные права на случай проблем
Каждое такое решение но отдельности кажется незначительным Но со временем
они накапливаются и формируют систему, в которой есть уязвимости или другие
проблемы с безопасностью Именно поэтому безопасность— это коллективная от-
ветственность. начиная от архитекторов и разработчиков и заканчивая тестировщи-
ками, DcvOps-инженерами и менеджерами. Любой, кто «срезал угол», может под-
ставить всю команду — проблему потом решать всем
Безопасность начинается с того, как разработчики работают с данными. Хорошо,
когда команда понимает, что любые поступающие данные могут содержать то, что
приведет к проблеме: данные будут удалены, к ним получен доступ, которого не
должно быть, и т. д. Особенно это касается продуктов, разрабатываемых для боль-
шого количества пользователей и доступных в Интернете. Среди пользователей
найдутся те, кто просто из любопытства попытается сломать продукт, а будут и те,
кто целенаправленно станет пытаться совершить мошеннические действия (фрод).
То, что вводит пользователь в поля ввода, или зафужает в виде файлов, или вызы-
вает через методы API, — всё это требует проверки и валидации. В противном слу-
чае — проблемы.
5.1.1. Логи
Отдельного внимания заслуживают лоти. Логи— необходимый инструмент для
поддержки и отладки, но именно через них часто происходят утечки В логах не
должно быть;
♦ паролей и PIN-кодов;
♦ токенов и ключей доступа;
♦ платежных данных;
♦ персональных данных, не требующихся для диагностики проблемы.
Важно помнить, что логи обычно доступны большему числу людей, чем основной
код, и могут храниться значительно дольше, чем предполагалось изначально.
Совет новичку
Не пишите в лог указанную здесь инфоомацию даже для отладки. Забудете удалить
Если очень надо, то пробуйте настроить автоматическую маскировку для того логгера,
который используется в вашем проекте.
5.1.2. Пароли, секреты и чувствительные данные
Пароли требуют особого отношения. Они не должны храниться в открытом виде
ни при каких условиях. Более того, пароли следует хранить так, чтобы их невоз-
можно было восстановить даже при утечке базы данных. Если пароль можно рас-
шифровать средствами обратного инжиниринга — это архитектурная ошибка, не-
зависимо от используемого алгоритма.
То же относится к токенам, АРГ-ключам, сертификатам и другим секретам. Их
нельзя хранить в коде, конфигурационных файлах или загружать в репозиторий с
кодом (даже если репозиторий закрытый!). Для хранения секретов существуют
специализированные сервисы, и их использование должно быть стандартной прак-
тикой команды.
Совет новичку
При работе с секретами спросите, как они должны храниться и где задаваться, на-
пример. если вы аналитик, и вам отправили ло'ин и пароль от заказчика, то уточните у
ксплог. где нужно хранить такую информацию, если она тестовая. А если продуктив-
ная? Если вы разработчик, то сразу уточняйте по тем данным, которые вы должны бу-
дете хранить для работы кода есть ли стандарты или правила по хранению инфор-
мации. по записи ее в лог.
5.1.3. «велосипеды» и безопасность
Молодые разработчики часто стремятся реализовать новые компоненты самостоя-
тельно. Это могут быть любые внутренние решения: от очередей сообщений до ме-
ханизмов шифрования. Внутри разработки собственные самописные решения при
наличии готовых решений обычно называют «велосипедами». С опытом разработ-
чики понимают, что создавать «велосипеды» — это почти всегда плохо.
Действительно, многие из таких компонентов, связанных с безопасностью (аутен-
тификация. управление доступами, хранение паролей, шифрование), можно реали-
зовать своими силами. Проблема в том. что для типовых задач такие решения поч-
ти всегда хуже готовых.
♦ Во-первых, это время и ресурсы. Разработка собственного решения отвлекает от
задач, которые напрямую создают ценность для продукта. То есть время тратит-
ся на то, на что тратить время не нужно.
♦ Во-вторых, ошибки. Создать сложный компонент без ошибок невозможно. Даже
если решение кажется простым, в эксплуатации всплывают редкие и неприят-
ные баги.
♦ В-третьих, уязвимости. Самописные решения часто создаются без полноценного
учета вопросов безопасности. В результате уязвимости обнаруживаются либо
внешним аудитом, либо уже после инцидента. Иногда это приводит не к дора-
боткам, а к отказу заказчика от продукта.
Есть и проблема сопровождения. Для популярных решений почти всегда можно
найти документацию, примеры и ответы на вопросы. Для собственных — нет. Со
временем даже сами разработчики могут перестат ь полностью понимать, как имен-
но всё работает. А особенно интересная работа начинается тогда, когда автор тако-
го «уникального» решения увольняется.
Помните!
Собственные решения не всегда зло. ко для стандартных программных компонентов,
особенно, связанных с безопасностью, готовые и проверенные инструменты почти
всегда надежнее.
5.2. Доступы, роли и принцип минимальных привилегий
Прежде чем углубляться в детали, давайте договоримся о главном правиле: никому
не давать лишнего. Для соблюдения этого правила существует несколько меха-
низмов, описанных далее.
5.2.1. Аутентификация и авторизация
Эти два термина (аутентификацию и авторизацию) пугают очень часто, хотя это
разные понятия. Путают их не только новички, но и опытные IT-специалисты.
♦ Аутентификация отвечает на вопрос «Кто вы такой?»
♦ Авторизация отвечает на вопрос: «Что вам разрешено делать?»
Сначала система должна убедиться, что пользователь действительно тог, за кого
себя выдает (аутентификация). II только после этого проверяется набор его прав
(авторизация).
Примеры того, как запомнить разницу
1. При входе в офис зы предъявляете пропуск— это аутентификация. Для доступа
уже на конкретный этаж и, тем более, в конкретные кабинеты нужны дополнитель-
ные права — это авторизация
2. Если вы идете на концерт или любое другое крупное мероприятие (театр, хоккей,
футбол), то при входе у вас всегда проверяют билет — зто аутентификация (вы
межето пройти внутрь), а далее — занять свое кресло или попасть в определенный
сектор — вы сможете при наличии соответствующих данных в вашем билете — это
авторизация
Нужно понимать, чго критичны как ошибки аутентификации, так и ошибки автори-
зации Многие новички полагают, что ошибки в аутентификации более критичны,
чем в авторизации. Я бы сказал, что ошибки в авторизации бывают даже более
опасны. Например, пользователь может иметь доступ к системе на чтение, но по
какой-либо причине получает права на запись. Представьте, что какой-то пользова-
тель получил возможность редактировать любые ваши сообщения в социальной
сети. Или — пример из жизни — представьте, что любой желающий, который ку-
пил билет на концерт, сможет пройти за кулисы к тем, кто выступает, не имея соот-
ветствующей привилегии.
5.2.2. Принцип минимальных привилегий
Один из базовых принципов безопасности так и называется: принцип минимальных
привилегий. Пользователь, сервис или компонент системы должен иметь только те
права, которые ему действительно необходимы для выполнения своей задачи.
Логика простая: если кто-то взломает аккаунт с правами «только чтение», ущерб
будет небольшим. Но если у взломанного сепвиса есть доступ ко всему подряд, по-
следствия могут быть очень серьезными. Управление доступом — это как раз спо-
соб ограничить и четко решить, кто и что может делать.
Бывают следующие доступы:
♦ к пользователям системы;
♦ к сервисным аккаунтам;
♦ к базам данных;
♦ к административным интерфейсам;
♦ к инфраструктуре и хостам.
Чем больше прав доступа, тем выше цена ошибки. Как следствие, команда на всех
этапах должна .думать и применять в продукте этот принцип минимальных приви-
легий. Например, добавление новой функции в продукт не должно работать без
специальной привилегии, то есть если в требованиях забыли указать про требова-
ние о привилегии, и разработчик, который реализует функцию, также о нем забыл,
то в итоге новая функция будет недоступна. Неправильно делать наоборот: функ-
ция будет доступна, если не задать привилегию. Это подход: «запрещено всё, что
не разрешено».
5.2.3. Безопасность в распределенных системах
Отдельное внимание следует уделить безопасности в распределенных системах —
наборах независимых компьютеров, которые с точки зрения конечного пользовате-
ля воспринимаются как единая система (подробнее о том. что такое распределенная
система, рассказано в приложении 1).
В распределенных системах требования к безопасности возрастают автоматически.
Чем больше сервисов и точек взаимодействия, тем выше риски и больше проблем.
Например, здесь базовым является требование к шифрованию данных при передаче
до сервера. Так, сейчас практически любой браузер при открытии сайта скажет вам
о том, что он небезопасный, если у него нет шифрования (работает по протоколу
нттр, а не https). Даже в приватных сетях трафик между клиентом и сервером дол-
жен быть защищен. Для взаимодействия между компонентами иногда допускают
работу без шифрования, но только при четком понимании инфраструктуры, — на-
пример, если компоненты находятся «далеко» друг от друга, то шифрование обяза-
тельно. Здесь под понятием «далеко» я понимаю ситуацию, когда данные сохраня-
ются в облачную базу данных, хотя сама обработка происходит локально При этом
важно помнить, что шифрование зребует процессорного времени и снижает произ-
водительность, то есть использование шифрование негативно влияет на работу'
пользователя или требует больше ресурсов.
Все те места, где хранятся данные (базы данных, брокеры сообщений, файлы),
должны быть защищены паролями, ключами доступа или другими аналогичными
механизмами. Используемые компоненты и библиотеки должны быть актуальных
версий, чтобы в них нс было известных критичных уязвимостей, которые могут
повредить работе всего продукта.
Но нужно и следовать здравому смыслу. В некоторых случаях повысить безопас-
ность можно за счет упрощения, а не усложнения системы Например, чувстви-
тельные данные можно вообще не передавать по сети, а обрабатывать локально
(подсчитали на месте и уже расчет отправили на сервер). Обратная сторона такого
решения — повышение нагрузки на клиентскую часть, то есть более высокие тре-
бования к компьютеру, на котором данные обрабатываются Такие принципы могут
закладываться как на этапе аналитики (когда требования явно указываются), так и
на этапе проектирования системы.
5.3. Аудит и тестирование безопасности
При работе с крупными заказчиками вопрос аудита безопасности — эго лишь во-
прос времени. Хорошо, если компания-разработчик самостоятельно проводит аудит
еще до того, как продукт выходит на рынок. Однако даже этого бывает недостаточ-
но, г. к. аудит проводят сторонние компании по требованию заказчика (платит за
такое удовольствие обычно тоже заказчик). Результатом становится список замеча-
ний, которые команда должна рассмотреть и либо предоставить обоснование их
неприменимости, либо устранить замечания.
Совет новичку
Нужно заранее договориться о том, какие уязвимости считаются критичными, а какие
нет Это должно влиять на сроки исправления. Для этого обычно используют обще-
принятые классификации— например. CVE (Common Vulnerabilities and Exposures).
Если вы будете ориентироваться только на мнение заказчика, а не на какую-либо об-
щепринятую классификацию, то, поверьте, большая часть уязвимостей будет иметь
критичный уровень, и вам станет сложнее объяснять почему это не так.
Здесь рекомендуется типовой подход критичные уязвимости исправляются бесплатно
за счет компании-разработчика и в ближайшем релизе (это е ваших же интересах), ос-
та пькые — в рамках отдельных работ, возможно, даже платных Применим и более
жесткий подход, но только помните, чтс исправить минорные замечания по безопас-
ности может быть дорого и неэффективно.
Тестирование безопасности включает в себя;
♦ тестирование на проникновение (подбор паролей, SQL-инъекции. XSS);
♦ проверки на соответствие стандартам и законам:
♦ аудит кода и политик безопасности;
♦ проверку устойчивости к атакам и защищенности данных.
Большая часть таких проверок выполняется с помощью специализированных про-
грамм (сканеров), но интерпретация результатов почти всегда требует участия
профильных специалистов
Пример из жизни
В одном проекте мы столкнулись с классическим архитектурным противоречием Биз-
нес-заказчик настаивал на использовании WebVtew — это было ключевым требовани-
ем, чтобы он мог гибко управлять контентом внутри нашего приложения без выпуска
обновлений. Аудит безопасности этого же заказчика проведенный сканером, выявил в
нашем продукте возможность демонстрировать сторонний контент и управлять нашим
приложением. То есть требования бизнеса вошли в противоречие с требованиями
безопасности В итоге вопрос, конечно удалось решить, но без интерпретации чело-
веком мы бы точно были вынуждены полностью вырезать требуемую заказчиком
функциональность, тем самым нарушив услония контракта ради формальною соот-
ветствия отчету сканера.
Иногда вопросами безопасности начинают заниматься только после утечки данных
или потери доступа. В таких случаях затраты оказываются несоизмеримо выше,
чем при подходе, когда вопросам безопасности уделяют время. В реальной практи-
ке это может привести не только к финансовым потерям, но даже к закрытию ком-
пании.
В безопасности можно использовать принцип: всё, что не разрешено, — запрещено.
Если есть сомнения, можно ли легировать данные, хранить их «как есть»? или пере-
давать дальше, разумно считать, что этого делать нельзя, пока не доказано обрат-
ное Привычка думать о безопасности заранее — одна из тех вещей, которые отли-
чают просто разработчика от профессионала.
5.4. Законодательные требования и российская практика
Важно помнить про требования к безопасности от государственных и иных надзор-
ных органов. Это отдельная тема безопасности, которая обычно не может быть
найдена специальными сканерами. Если мы говорим про Россию, то это вопросы
безопасности, связанные в первую очередь с ФЗ-152 «О персональных данных».
Как только продукт начинает хранить или обрабатывать персональные данные,
компания обязана соблюдать установленные требования и быть готовой к провер-
кам. Это потребуется и для случаев, если продукт создаватся для использования
внутри компании.
При этом под персональные данные попадает гораздо больше информации, чем
ожидают новички: помимо понятных всем имени и фамилии, даты рождения и
иных личных данных, включая номер паспорта, телефон, к персональным данным
относятся даже адреса e-mail и IP-адреса, а также другие данные, которые не ка-
жутся персональными. То есть вопросы хранения требуют привлечения юристов
для понимания того, являю гея ли те или иные данные персональными или нет.
Отдельно подниму вопрос, связанный с влиянием крупных заказчиков, которые
могут быть значительно крупнее компании-разработчика. Само собой, компании-
разработчики всегда хотят получить крупного заказчика. И часто готовы согласить-
ся на любые его условия. В реальности крупные заказчики часто формируют свои
уникальные требования к безопасности продукта, и далеко не всегда эти требова-
ния согласуются с архитектурой продукта, законодательными требованиями или
другими общепринятыми требованиями ПБ.
Пример из жизни
Один из заказчиков поставит жесткое условие продукт должен стоять только на их
внутренних серверах. Логика простая: «Это наше требование Данные не должны по-
кидать внутренний контур».
Но возникла проблема. Наш сервис с самого начала строился как «облачный». Про-
дукт просто не был рассчитан на работу в изолированном контуре. В итоге мы оказа-
лись перед выбором- либо полностью переписывать программу под эти требования
либо искать компромисс и объяснять, что в «облаке» данные тоже защищены не хуже
чем во внутреннем контуре.
Компании, которые разрабатывают ПО, должны быть готовы к самым неожидан-
ным новым требованиям, предсказать заранее которые невозможно. У вас может
быть лучший на рынке продукт с точки зрения информационной безопасности, но
он всё равно не подойдет под специфичные требования заказчика.
- Глава 6-
Гибкие методологии для новичков
В этой главе мы договорим о том, как на самом деле устроен процесс работы ко-
манд разработки и почему современные методики называют «гибкими».
В идеальном мире заказчик точно знает, чего хочет, а разработчик просто пишет
код по инструкции. В реальности всё иначе: требования меняются на ходу, техно-
логии не позволяют сделать то, что нужно, а правила безопасности внезапно за-
прещают то, что еще вчера было можно. Именно для такого «неидеального» мира и
придумали гибкие подходы.
6.1. Суть Agile
Независимо от проекта, работа команды должна быть организована Сегодня в IT,
включая Россию, стандартом де-факто стати гибкие методологии. Часто можно ус-
лышать термины «Agile-иодход» или «Agile-методологии». При этом важно пони-
мать: сам по себе Agile — это не методология.
Agile (с английскою — «гибкий») — это философия, набор принципов разработки,
описанный в Agile Manifesto. Это, скорее, образ мышления, но не готовая инструк-
ция к действию. Поэтому, говоря «Agile-методология», мы, по сути, имеем в виду
конкретные методики, которые реализуют эти принципы на практике.
Две самые распространенные из таких методологий— это Scrum и Kanban (вот
именно они и являются методологиями!). Безусловно, у каждой из них есть множе-
ство вариаций и адаптаций, но их базовые версии остаются основой для работы
большинства 1Т-команд.
В основе Agile лежат Agile-манифест и принципы. Ознакомиться с ними можно в
приложении 2.
Говоря упрощенно, Agile— это подход, при кот ором большой проект не делают
целиком и сразу. Вместо этого его дробят на короткие итерации (например, по две
недели). В конце каждой итерации команда показывает заказчику рабочий кусок
продукта, получает обратную связь и сразу вносит правки. Такой подход еще назы-
ваю! итеративным и инкрементным, поскольку за каждую итерацию мы получаем
прирост ценности.
Это позволяет быстро менять требования, оперативно исправлять ошибки и посто-
янно держать фокус на реальном результате, а не на бесконечных планах и доку-
ментах. Вся работа строится на тесном контакте внутри команды и с заказчиком, а
главным итогом становится работающий код продукта
Важно понимать, что за гибкость приходится платить. Поиск т ою самого решения
проходит через множество итераций, и если сложить затраты на каждую итерацию,
то сумма затрат окажется больше, чем реализация по заранее составленному техни-
ческому заданию (ТЗ).
Графически работу по Agile и работу по ТЗ можно представить следующим обра-
зом (рис. 6.1): черные стрелки — это итерации, каждая завершается некоторым до-
бавлением ценности продукту, пунктирная стрелка — это работа по ТЗ. Круг — это
функциональность продукта, которая устроит заказчика (это не точка, это именно
какая-то область). Видно, что, работая по ТЗ, мы не попадаем в требуемую область,
a Agile в конце концов приводит нас к цели, однако затраты могул быть достаточно
большими.
Однако в этом и заключается ключевой момент — создать идеальное ТЗ, в котором
учтены все нюансы и нет ни одной ошибки, невозможно. Поэтому Agile-подход
основан на том, что требования будут меняться, и пытаться предусмотреть всё за-
ранее — это глупость. Лучше постоянно корректировать работу по ходу движения,
чем тратить месяцы на создание «идеального плана?», который всё равно окажется
неверным.
Пример из жизни
В начале 2000-х ФБР США запустило проект Virtual Case File (VCF) — цифровую сис-
тему для замены устаревших бумажных архивов Разработку вели по классическому
подходу— сначала несколько лет создавали техническое задание, где пытались пре-
дусмотреть каждую деталь будущей работы.
3 результате проект был официально закрыт в апреле 2005 года, хотя он всё еще на-
ходился на стадии разработки. Потратив 170 миллионов долларов за четыре года
разработки ФБР получило полностью неработоспособную систему, которую пришлось
зыкинуть. К моменту завершения проекта первоначальные требования безнадежно
устарели: изменились законы, методы расследований и технологии Идеально спроек-
тированная система оказалась бесполезной — она решала несуществующие проблемы.
Кстати, такой подход, когда проект проходит строго последовательные этапы:
сбор требований —> аналитика —> проектирование —> программирование —>
тестирование —> сдача, называется водопадным (waterfall).
Именно по такому принципу и разрабатывалась провальная система для ФБР. Во-
допад работает по принципу фиксации всех требований в самом начале без воз-
можности изменения плана. Как показывает пример VCF, для сложных и долго-
срочных проектов это часто приводит к катастрофе.
А теперь давайте разберемся подробно в том, как устроены Scrum и Kanban.
6.2. Scrum: спринты, бэклоги, роли
Для того чтобы лучше объяснить некоторые термины, я буду использовать ту же
«кухонную» аналогию. И, конечно, расскажу про то, что реально вас ждет в России.
6.2.1. Основа: три столпа Scrum
♦ Прозрачность.
• Принцип (по учебнику). Все участники понимают цель, видят текущий про-
ipecc и знают о возникающих проблемах.
• Аналогия. Как на открытой кухне, где все (в том числе гости) видят, как про-
исходит готовка, и знают, кто что готовит, а о подгоревшем блюде сразу уз-
нают без лишних слов.
• Российская практика. Часто поступает не вся информация. Задача новичка —
научиться читать между сгрок и задавать уточняющие вопросы.
♦ Инспекция.
• Принцип (по учебнику). Команда регулярно проверяет npoipecc и оценивает
результаты.
• Аналогия. Шеф-повар регулярно пробует блюда, чтобы убедиться в их соот-
ветствии рецепту, а также следит, чтобы работники не отставали от графика.
• Российская практика. Может превращаться в формальный отчет для началь-
ника, Важно показывать реальные проблемы, а не «быть хорошим».
♦ Адаптация.
• Принцип (по учебнику). Обнаружив отклонение от пели, команда немедлен-
но корректирует работу.
• Аналогия. На кухне сразу стараются исправить пересоленное блюдо, а не пы-
таются подать его гостям.
• Российская практика. «Мы всегда так делали» — частая реакция на предло-
жения об изменении процессов. Меняйте подход постепенно.
6.2.2. Ключевые роли
♦ Владелец продукта (Product Owner).
• Роль (по учебнику). Определяет, что делать, формируя и приоритезируя спи-
сок задач (бэклог). Представляет интересы заказчика.
• Аналогия. Шеф-повар решает, какие блюда готовить, чтобы ужин получился
идеальным.
• Российская практика. Иногда это менеджер, который одновременно отвечает
за несколько проектов и физически не успевает глубоко вникать в каждый.
Будьте готовы, что это не настоящий владелец продукта.
♦ Скрам-мастер (Scrum Master).
• Роль (по учебнику). Организует процесс, устраняет препятствия и помогает
команде работать эффективнее. Это лидер (у него нет формальной власти), а
не начальник.
• Аналогия. Старший повар (или су-шеф), который следит, чтобы на кухне все
было организовано, а повара не мешали друг другу.
• Российская практика. Scrum-мастер редко бывает выделенным на одну ко-
манду. Чаще эту роль совмещает один из членов команды либо он обслужи-
вает несколько команд сразу.
• Команда разработки (Dev Team).
• Роль (по учебнику). Самоорганизующаяся группа специалистов (разработчи-
ки, тестировщики, аналитики), которая решает, как сделать продукт.
• Аналогия. Повара, которые, чтобы выполнить заказ, сами распределяют, кто
режет овощи, а кто готовит соус.
• Российская практика. Часто сохраняется негласная иерархия. Решения senior-
разработчиков редко оспариваются джунами.
Важное правило, разделение ролей
Не может быть так, чтобы Scrum-мастер и Product Owner были одним человеком* Это
важное ограничение. Они являются в некотором роде антагонистами. РО защищает
интересы бизнеса и хочет больше функциональности и побыстрее, а Scrum-мастер
защищает интересы команды и следит за устойчивым темпом работы и здоровьем в
коллективе. Их баланс — ключ к здоровому и эффективному процессу
6.2.3. Основные артефакты
♦ Бэклог продукта,
• Определение (по учебнику). Главный приоритизированный список всех тре-
бований к продукту.
• Аналогия. Книга рецептов шеф-повара со всеми блюдами, которые он хотел
бы приготовить
• Российская практика. Часто превращается в список задач без четких приори-
тетов, но хорошо, если есть понятные приоритетные задачи хотя бы на один-
два спринта (игерании).
♦ Бэклог спринта.
• Определение. Задачи, выбранные из бэклога продукта для выполнения в те-
кущем спринте
• Аналогия. Меню на сегодняшний банкет— конкретные блюда, которые бу-
дут приготовлены.
• Российская практика. Часто пополняется срочными («нужно вчера») задача-
ми от руководства.
♦ Инкремент.
• Определение. Готовая к использованию часть продукта, созданная за спринт.
• Аналогия. Готовое блюдо, которое уже можно подать гостям, но это всегда
доделанное блюдо. Даже если заказано несколько блюд, их выносят по го-
товности.
• Российская практика Иногда фичи не доделаны до конца, но их показывают
как выполненные.
6.2,4. Регулярные события
♦ Планирование спринта.
• Событие (по учебнику). Команда выбирает задачи из бэклога продукта на
следующий спринт, исходя из цели предстоящего спринта Длина спринта
(итерации) обычно составляет 2- 4 недели. Начинается спринт с планирова-
ния и заканчивается демонстрацией и затем ретроспективой.
• Аналогия. Шеф с поварами решают, какие блюда будут подготовлены сего-
дня, исходя из наличия или отсутствия продуктов, и кто за что отвечает. Цель
определяется менеджером, исходя из потребностей ресторана: например,
банкет, или праздник, или тематическая кухня. Но конкретные блюда готовят
повара
• Российская практика. РО или менеджер часто сами определяют состав сприн-
та. Технические специалисты подключаются позже для опенки сроков. Об-
суждение сводится к «успеем / не успеем», а не к анализу ценности задач.
Иногда цель — «надо успеть».
Совет
Уточняйте непонятные моменты сразу не надейтесь разобраться по ходу.
♦ Ежедневный стендап.
• Событие (по учебнику). 15-минутная встреча для синхронизации: что сделал,
что планирую сделать, какие препятствия.
• Аналогия: Утренняя летучка поваров у плиты: «Вчера приготовил соус, сего-
дня делаю гренки, проблема — нет анчоусов».
• Российская практика. Может длиться 30-45 минут с углублением в техниче-
ские детали. Старшие сотрудники говорят больше, младшие отмалчиваются.
Часто превращается в отчет перед тимлидом.
Совет
Учитесь говорить кратко. Детали обсуждайте после стендапа с заинтересованными
лицами.
♦ Обзор спринта (демо).
• Событие (по учебнику). Демонстрация готового инкремента и сбор обратной
связи от заказчиков и РО. Важно! Команда разработки демонстрирует РО
проделанную работу, а РО принимает решение о том, принимать ли задачу.
• Аналогия. Дегустация блюд гостями. Повара рассказывают про свои блюда:
«Попробуйте тирамису! Как вам консистенция?»
• Российская практика РО или заказчик часто отсутствует. Демонстрация пре-
вращается в формальный отчет для галочки. Обратная связь либо отсутству-
ет, либо не влияет на следующие енринты.
Совет
Готовьте к демо заранее показывайте именно ценность для пользователя
♦ Ретроспектива.
• Событие (по учебнику). Анализ процессов команды за итерацию и поиск пу-
тей улучшения.
• Аналогия. Обсуждение после ужина: «Сегодня работали быстрее, потому что
подготовили овощи с у гра. Завтра сделаем так же».
• Российская практика Проводится формально или пропускается. Команда из-
бегает обсуждать реальные проблемы, особенно связанные с руководством.
Итог: «продолжаем как есть».
Совет
Начинайте с малого — предложите улучшить один конкретный процесс
6.2.5. Резюме для новичка в России
Scrum в российских компаниях редко соответствует учебнику. Ваша задача — по-
нять правила игры в вашей команде и адаптироваться к ним, постепенно помогая
команде двигаться к эталону, ведь даже в разных командах одной компании могут
быть своп особенности. Начинайте с малого, задавайте вопросы на планировании,
готовьтесь к демо, предлагайте небольшие улучшения на ретроспективах.
Совет новичку
Начинайте с наблюдения Понять, как Scrum работает именно в вашей компании, —
важнее, чем знать теорию и пытаться навязать ее команде. Если видите несоответст-
вия — не спешите критиковать. Сначала узнайте историю: «А почему у нас ретроспек-
тивы длятся 15 минут?» Ответ может быть практическим. «Потому что в прошлом гаду
двухчасогые ретро не приводили к изменениям»
Несмотря ни на какие особенности и нюансы. Scrum — это очень структурирован-
ный фреймворк. В нем четко определены правила, роли и события. Эта жесткость
создает дисциплину и оставляет мало шансов отклониться от процесса (хотя всегда
остается шанс подогнать процесс под себя), чтобы не скатиться в собственное
«уникальное» решение
Именно поэтому в среде разработчиков распространены шутливые термины
«скрам. но. » или «скрамно» Они как раз описывают ситуацию, когда команда
вроде бы пытается работать по Scrum, но на практике постоянно нарушает его пра-
вила: не проводит ретроспективы, игнорирует длительность встреч или смешивает
роли. В итоге получается не настоящий Scrum, а его неудачная имитация, лишенная
главных преимуществ.
Примеры специфики «Scrum, но» в России:
♦ «Скрам, но начальник всегда прав» — когда формально есть демократия, но фи-
нальное слово остается за руководителем.
♦ «Скрам, но без ретроспектив» — команда боится говорить о проблемах открыто.
♦ «Скрам, но с авралами» — когда спринты постоянно прерываются «срочными»
задачами.
Ваша задача как новичка — не бороться с системой, а понять местные правила и
постепенно, маленькими шагами, помогать команде двигаться к бо iee осознанной
работе.
В итоге Scrum — как кулинарный рецепт в теории всё четко, но на практике каж-
дый шеф добавляет что-то свое.
6.3. Kanban: визуализация workflow, ограничения WIP
В отличие от Scrum с его четкими правилами и ролями. Kanban — это гораздо бо-
лее свободный (или, говорят еще, гибкий) подход. Его философию можно описать
так: «Начните с визуализации процесса, добавьте щраничения на каждый этап и
двигайтесь к постепенным улучшениям».
6.3.1. Базовые принципы Kanban
♦ Визуализируйте поток работ. Вся работа команды видна на Kanban-доске —
обычно это столбцы, которые отражают этапы выполнения задачи (например’
«Бэклог», «Аналит ика», «Разработка», «Тестирование», «Готово»).
♦ Ограничьте количество задач в работе (WIP. Work In Progress). Это ключевое
правило! На каждом этапе можно одновременно выполнять только определенное
количество задач (меньше можно, больше — нет). Новую задачу можно взять з
работу, только когда освободится «слот».
♦ Управляйте потоком. Команда следит за тем, как задачи движутся по доске, и
старается сделать этот поток максимально быстрым, то есть стремится сделать
так, чтобы задача как можно скорее доходила до конца доски.
♦ Сделайте правила процесса явными. Все понимают, когда задача считается вы-
полненной на каждом этапе.
♦ Внедряйте улучшения постепенно. Kanban не требует резких перемен, он поощ-
ряет маленькие, но постоянные улучшения процессов.
6.3.2. Типы задач в Kanban
Обычно на доске выделяют четыре типа работ, а точнее — классов обслуживания:
♦ Стандаршые задачи.
Основная работа по разработке новой функциональности или исправлению
ошибки Это классические доработки или улучшения, которые нужны клиентам.
Рис. 6.2. Пример Kanban-доски
♦ Задачи с фиксированной датой.
Это мотут быть те же самые задачи, но их особенность состоит в том, что если
они не будут выполнены в срок, то становятся не нужны. Такой срок может оп-
ределять новый закон, доработки по которому нужно успеть сделать к опреде-
ленной дате, иначе — штраф.
♦ Нематериальные задачи.
Это задачи по рефакторингу, улучшению архитектуры, обновлению библиотек,
короче — технический долг. Они обычно дают какой-то понятный бонус —
например, автоматизация тестов уменьшает время на ручные проверки и выпуск
релизов.
♦ Срочные задачи / Блокеры.
Критичные инциденты или задачи, которые требуют немедленного вмешатель-
ства и переключают всю команду.
Типичная Kanban-доска может выглядеть, как показано на рис. 6.2.
6.3.3. Важные нюансы
♦ Отраничение есть не на всех колонках Оно нужно только на тех этапах, где вы-
полняется работа. Например, нет ограничений на количество задач в очереди и
нет ограничений на количество задач, готовых к релизу (хотя тут можно поспо-
рить).
♦ Можно разделить колонки, требующие действий (кроме последней), на два эта-
па; на «В работе» и «Готово».
• «В работе»: задача находится в процессе выполнения (левая часть).
• «Готово [для передачи]»: задача завершена на этом этапе и готова к взятию в
работу на следующем (правая часть).
Например, колонка «Аналитика» может быть разделена на две одновре-
менные работы (на схеме, приведенной па рис. 6.2, жирным выделена
цифра 2): «В разработке» и «Готово для разработки». При этом на схеме
одна задача показывается как готовая к разработке, а другая — как нахо-
дящаяся на стадии обработки аналитиком. Разработчик тогда видит, какие
задачи уже можно брать, не отвлекая аналитика лишними вопросами.
♦ Первая строка — для записи срочных задач. Срочные задачи не участвуют в об-
щих лимитах, но имеют свои собственные. Именно поэтому, хотя в колонке
«Разработка» содержится пять задач, на схеме жирной цифрой показано, что их
4, а одна задача является срочной.
6.3.4. Аналогия: кухня ресторана
с ограниченными мощностями
Представьте кухню, где есть только две сковородки, одна духовка и одна плита.
Это ваше ограничение.
♦ Визуализация. Шеф видит всю готовящуюся еду на разных стадиях.
♦ Ограничение числа задач в работе. Нельзя начать готовить новые стейки, если
все сковородки заняты. Нужно дождаться, когда один стейк будет готов, и ско-
вородка освободится.
♦ Поток. Задача шефа — не дать поварам застрять каждому на своем этапе, чтобы
кухня не остановилась, а блюда выходили равномерно
6.3.5- Метрики Kanban
Чтобы понимать, как обстоят дела в команде, можно отслеживать метрики Cycle
Time и Lead Time.
♦ Lead Time (время выполнения) — общее время с момента поступления задачи в
систему (в бэклог) до ее полного завершения.
Для новичка — это время, которое заказчик ждет вашу работу: «от заказа до по-
дачи на стол».
♦ Cycle Time (время цикла) — время, когда задача находилась в активной работе: с
момента, когда вы ее взяли в работу, до момента завершения.
Для новичка это время вашей непосредственной работы над задачей: «от пер-
вой строчки кода до последней».
Зачем это новичку? Стремитесь уменьшать свое время цикла. Это показатель вашей
личной эффективности.
6.3.6. Kanban в российских реалиях:
плюсы и подводные камни
♦ Гибкость против хаоса.
Формальная свобода Kanban в России часто приводит к тому, что доска есть, а
лимитов нет. В итоге каждый берет много задач, ничего не успеваег доделать, и
команда получает большое количество недоделанных задач
Совет
Сразу установите лимиты или не называйте свой процесс Kanban.
♦ Низкая ответственность и WIP-лимиты.
Бывает, что лимиты формально есть, но сотрудники, не желая помогать колле-
гам, «втихаря» начинают новые задачи и перевешивают их на доске только по
готовности. Это говорит о низкой командной ответственности и сводит пользу
от лимитов на нет.
Совет
Обсудите этот вопрос на ретроспективе и договоритесь так не делать Не работает?
Думайте: дело в процессах или в людях? Может, Kanban не для вас?
♦ «Срочные» задачи убивают поток.
Российский бизнес любит срочность. В КапЬал-командах это выливается в то,
что половина доски завешана красными стикерами «СРОЧНО!», которые сры-
вают все планы и лимиты. Пот ок останавливается.
Совет
Договоритесь сразу, сколько срочных задач может быть в работе.
♦ Отсутствие регулярного планирования.
В Scrum есть четкие спринты, в Kanban — часто нет. В России ото может озна-
чать, что новые задачи прилетают бесконтрольно в любой момент, а приоритеты
меняются по несколько раз на дню. Первое — не является проблемой, т к появ-
ление новых задач не является злом, а второе — является, особенно если вы уже
взяли задачу в работу.
Совет
Договоритесь, что задача не может быть просто так отменена За каждую отмененную
задачу руководитель обещает выполнить задачу из технического долга.
♦ Проблема узких специализаций.
Kanban плохо работает, koi да в команде есть строгое разделение на бэкенд,
фронтенд и мобильную разработку. Если все задачи в «Разработке» — это
бэкенд, а фронтендеры простаивают, система дает сбой. Kanban эффективен, ко-
гда команда в значительной степени взаимозаменяема.
Совет
Не вводите Kanban, если не хотите помогать друг другу и изучать новую технологию
♦ Ежедневные митинги.
Если у вас их нет, то вы можете предложить их ввести. В этом случае по доске
надо идти справа налево и по каждой конкретной задаче обсуждать, что мешает
перевесить ее вправо. Призывайте коллег помогать двигать задачи, если они не
заняты
6.3.7. Что нужно знать новичку в российской КапЬап-команде?
♦ Сначала поймите реальные WIP-лимиты. Даже если их нет на доске, спросите:
«Сколько задач я могу взять в работу одновременно?» Ориентируйтесь на 1-2
задачи, чтобы показывать стабильный результат.
♦ Научитесь говорить «нет» (или «после этой»). Если у вас уже есть задачи по ли-
миту, а вам подкидывают новую, тактично сообщите: «Я как раз заканчиваю за-
дачу X, возьму ее в работу, когда закончу с этой».
♦ Следите за своим потоком Ваша цель — не просто брать задачи, а закрывать их.
Старайтесь доводить начатое до конца, а не перескакивать с одной на другую.
♦ Будьте инициативны в визуализации. Если вы видите, что задача заблокирована
(например, ждете ответа от другого отдела), создайте для этого отдельный стол-
бец «Блокер» или «Ожидание». Так проблема будет видна всем. Но еще лучше
не делать такие столбцы, а помочь разблокировать задачу
♦ Предлагайте ввести ретроспективы. Если их нет, предложите проводить корот -
кие встречи по 30 минут раз в неделю-две, чтобы обсудить один вопрос: «Что
нам мешало на этой неделе завершать задачи быстрее?»
Финальный совет новичку
Kanban — это мощный инструмент, который в российских условиях требует от всей
команды самостоятельности и дисциплины. Ваша главная задача— не поддаваться
хаосу, а использовать принципы Kanban для создания предсказуемого личного рабо-
чего ритма, даже если вся команда работает иначе. Начинайте с малою, визуализи-
руйте свою работу, ограничьте свой личный WlP и всегда доводите задачи до конца.
Это лучший способ показать свою эффективность
6.4. Резюме: Kanban или Scrum — когда что выбрать?
Если у вас. как у новичка, есть возможность выбора методологии (Kanban или
Scrum), го пользуйтесь следующими принципами:
♦ Выбирайте Scrum, если:
• вам нужны максимальные структура и предсказуемость;
• вы готовы к понятным ро;тям и правилам;
• продукт допускает планирование на 1 -4 недели вперед;
• команда молодая или не обладает высоким уровнем ответственности
♦ Выбирайте Kanban, если:
• у вас поток непредсказуемых или срочных задач (например, поддержка.
DevOps);
• вам важны гибкость и возможность менять приоритеты по задачам в любой
момент;
• команда обладает высокой самоорганизацией и ответственностью, т. к. пра-
вила Kanban легко нарушить, и это сразу бьет по скорости реализации задач.
6.5. Ваш первый спринт:
практическое руководство для новичка
Итак, вы изучили материалы no Scrum и Kanban. Но что делагь, когда вы приходите
в команду и вам говорят: «Завтра начинается новый спринт» или «Смотри на доску,
бери задачу в работу»? Эта часть — ваша шпаргалка по тому, что делать.
6.5.1 Чек-лист первого дня: что нужно выяснить о процессе?
Не молчите! Задайте эти вопросы наставнику или скрам-мастеру в первый же день.
Но не перегибайте, соблюдайте тактичность.
♦ Ваши вопросы по процессу в целом:
• «По какому процессу мы работаем: Scrum, Kanban или гибридный вариант?»
• «Где находится наш бэклог? Где доска с задачами?»
• «Как часто и в какое время проходят митинги?»
♦ Если вам говорят «Scrum»:
• «Какова длина нашего спринта?»
• «Когда следующее планирование спринта?»
• «Кто наши владелец продукта (РО) и скрам-мастер?»
♦ Если вам говорят «Kanban»:
• «Какие WIP-лимиты у нас установлены9»
• «Как мы рабогаем со срочными задачами?»
• «Как часто проходит планирование пополнения доски?»
• «Как часто мы релизим готовые задачи?»
6.5.2. Типичные ошибки новичка, и как их избежать
Ошибка 1. Молчать на стендапе
Почему это ошибка? Команда не понимает, чем вы заняты, и не может помочь. Вы
выглядите пассивным.
Как поступать правильно? Готовьтесь за 5 минут до встречи. Говорите четко по схеме:
♦ «Вчера сделал [конкретный результат]».
♦ «Сегодня планирую сделать [конкретный план]».
♦ «Проблема: [что мешает], мне нужна помощь с [чем именно]».
Ошибка 2. Брать задачу и уходить в тишину на несколько дней
Почему это ошибка? Вы можете уйти в неправильном направлении и потратить
время впустую.
Как поступать правильно9 В первые дни уточните, всё ли делаете так, как надо. По-
сле нескольких часов работы над задачей покажите наставнику или коллеге, что у
вас получилось, и спросите «Я двигаюсь в правильном направлении?»
Ошибка 3. Бояться сказать, что не успеваете
Почему не сказать — это ошибка? В Scrum это сорвет спринт, в Kanban — создаст
«узкое место» в потоке.
Как поступать правильно? Сообщайте о рисках как можно раньше. Фраза: «Я пока
не уверен, что успею к сроку, потому что [причина]. Давайте обсудим, что можно
сделать?»
6.5.3. Как понять, что процесс сломан?
Иногда проблемы — это не ваша некомпетентность, а системные сбои.
♦ Признаки сломанного Scrum:
• «Скрам. но...». Вам постоянно говорят: «У нас скрам, но вот это правило мы
не соблюдаем».
• Ретроспективы — это фикция. Никто не говорит о реальных проблемах, и
ничего не меняется,
• РО отсутствует. Некому ответить на ваши вопросы по задаче
♦ Признаки сломанного Kanban:
• Доска есть, лимитов нет. Каждый берег сколько хочет задач, ничего не за-
вершается
• Все задачи — срочные. Половина доски висит в красных стикерах, нет огра-
ничений на срочные задачи.
• Задачи неделями висят в «Готово для тестирования». Поток не движется.
6.5.4. Ваши действия
♦ Сначала понаблюдайте.
Не критикуйте процесс с порога. Возможно, у команды были веские причины
прийти к такой реализации. Задавайте тактичные вопросы: «А как у нас принято
поступать в ситуации, когда...?»
♦ Покажите потери на цифрах
Вместо критики используйте метрики. Покажите команде и бизнесу реальный
Cycle Time или Lead Time. Цифры «задача висела в тестировании 10 дней из 12»
убеждают лучше любых споров.
♦ Ищите союзников.
Найдите тех, кого текущий хаос раздражает так же сильно. Внедрять изменения
в одиночку против системы невозможно — вам нужны единомышленники внут-
ри команды.
♦ Внедряйте малые изменения (Kaizen').
Не пытайтесь починить всё сразу. Предложите одно маленькое правило — на-
пример. «не берем новую задачу, пока не поможем закрыть ту, что в тестирова-
Кайдзен — японская философия или практика, которая фокусируется на непрерывном совершенст-
вовании процессов производства, разработки, вспомогательных бизнес-пропессоь и управления, а
также всех аспектов жизни.
нии». Или: «давайте на ретроспективе выберем только одно действие на спринт,
но реально его внедрим»
♦ Визуализируйте скрытое.
Если лимитов нет, просто покажите, сколько задач одновременно находится в
работе на одною человека.
♦ Верните смысл ролям.
Если РО отсутствует, начните фиксировать вопросы, на которые нет ответов, и
покажите, как это стопорит команду и поставку ценности. Бизнес быстрее пой-
дет на контакт, когда поймет, что отсутствие ответов стоит им денег.
6.6. Разговорник новичка:
фразы для разных событий
На планировании спринта
Вместо: «Я не понял эту задачу».
Лучше сказать: «Правильно ли я понял, что в этой задаче главное — добиться [кон-
кретная цель]?»
На стендапе
Вместо: «Я разбирался в коде».
Лучше сказать: «Вчера я разобрался с модулем X и начал реализовывать метод Y.
Сегодня планирую его закончить и написать тесты. Вопрос; не могли бы вы под-
сказать, как в нашем проекте принято обрабатывать ошибки в этом месте?»
Когда задача заблокирована
Вместо: «Я жду ответа от Васи».
Лучше сказать. «Моя задача X заблокирована, потому что я жду данные от команды
Y. Я уже напомнил им вчера и сегодня утром. [Имя], может, поможешь ускорить?»
На ретроспективе
Вместо; «У нас всё плохо».
Лучше сказать; «Я заметил, что мы часто гратим время на настройку окружения.
Предлагаю попробовать создать для этого пошаговую инструкцию для новичков.
Я готов взять это на себя».
Главный совет
Ваша цель в первые дни и недели — не изменить процессы и не блеснуть продуктив-
ностью, а понять правила игры и вписаться в поток команды. Будьте активны, зада-
вайте вопросы и не бойтесь просить помощи.
- Глава 7-
Управление задачами и приоритизация
7.1. Системы управления задачами, требованиями,
проектами и продуктами
На старте карьеры все указанные в заголовке понятия часто смешиваются. Но по-
нимание разницы между ними— это первый шаг к профессионализму. Давайте
разберемся по порядку, используя тему с аналогией в работе ресторана.
♦ Продукт: ресторан.
• Суть. Продукт развивается и живет гак долго, пока им пользуются, его разви-
тие не имеет четкой даты окончания.
• Аналогия. Это сам ресторан с его тематикой, кухней и атмосферой. Ваша
главная ценность. Например, ресторан классической русской кухни.
• В IT. Это программный продукт, который вы создаете и постоянно улучшаете
для пользователей. Например: «Мобильное приложение банка» или «Корпо-
ративная CRM-сисгема».
♦ Проект: запуск нового меню или банкета.
• Суть. Проект имеет начало и конец. После его завершения продукт получает
новое качество или функцию.
• Аналогия. Это ограниченная по времени инициатива внутри ресторана: под-
готовка новогоднего банкета или введение сезонного меню. У проекта есть
четкая цель, бюджет и сроки.
• В IT. Это временная инициатива с конкретной целью в рамках продукта. На-
пример: «Проект по запуску ипотечного кредитования в мобильном прило-
жении».
♦ Требование: рецепт блюда.
• Суть Требование отвечает на вопрос «ЧТО мы делаем?», но не «КАК мы это
делаем технически».
• Аналогия. 'Это рецепт и стандарт подачи блюда. В нем описано, что должно
получиться: ингредиенты, этапы приготовления, внешний вид и вкус.
• В 1Т. Это то, что должен делать продукт, чтобы удовлетворить потребность
пользователя Например: «Пользователь должен иметь возможность подать
заявку на ипотеку через мобильное приложение: существует возможность за-
полнения анкеты и загрузка фотографии Есть возможность хранить чернови-
ки неотправленных заявок».
♦ Задача: действие повара на кухне.
• Суть: Задача отвечает на вопрос «КАК мы это делаем?» и «КТО за это отве-
чает?».
• Аналогия. Это конкретное действие повара для выполнения рецепта: нарезать
овощи, приготовить соус, собрать блюдо на тарелке.
• В IT Это конкретное действие, которое выполняет член команды (разработ-
чик, тестировщик, дизайнер) для реализации требования. Например: «Разра-
ботать форму для ввода паспортных данных»?, «Реализовать API-методы для
проверки кредитной истории».
Иными словами, ваш JT-продукт (например, приложение банка) реализует проекты
(запуск ипотеки), состоящие из требований (функция подачи заявки), которые раз-
биваются на задачи (написание кода, создание дизайна).
7.1.1. Почему важно понимать контекст?
Понимание контекста (разницы между продуктом, проектом, требованием и зада-
чей) — это го, что отличает специалиста-профессионала от простого исполнителя.
Без этого понимания ваша работа превращается в слепое выполнение указаний, и
вам будет сложнее подниматься по карьерной лестнице.
Причины
♦ Решение одной задачи # успех проекта. Можно безупречно выполнить десятки
задач, но не достичь цели проекта.
• Аналогия. Повар может идеально нарезать все овоши, но если горячее блюдо
подать через час после холодных закусок, ужин у гостей будет испорчен.
• В IT. Ра >работчик может написать безупречный код для кнопки, но если вся
цепочка оформления заявки неудобна, пользователи не дойдут до конца, и
проект по увеличению продаж провалится.
♦ Одна задача может остановить весь проект. Незначительная, на первый
взгляд, задача может оказаться критической.
• Аналогия. Если забыть заказать соль к банкету, все остальные действия пова-
ров теряют смысл.
• В IT. Несвоевременное выполнение задачи «Настроить интеграцию с пла-
тежным шлюзом» заблокирует запуск всего проекта онлайн-оплат.
♦ Не все требования обязательны для успеха. Иногда проект можно и нужно
запустить без реализации всех «хотелок». Жизненно важно отличать «must have»
(обязательно нужно!) от «could have» (желательно).
• Аналогия Ресторан можно успешно открыть без эксклюзивного десерта от
известного шефа, но нельзя — без работающей кассы, продуктов, сотрудни-
ков и готовых блюд.
• В IT. Приложение для заказа такси можно выпустить без функции предвари-
тельного выбора музыки в салоне, но нельзя — без функции вызова автомо-
биля и расчета стоимости.
Главный вывод
Пытайтесь понять, что именно вы делаете. Не просто «закрываете задачу», (проси-
те себя:
♦ Как моя задача влияет на общий результат?
♦ Что случится, если я сделаю это позже или иначе?
♦ Без чего проект действительно не может обойтись?
Такое мышление не просто делает вас ценнее — оно превращает вас из винтика в
соавтора результата. Вы начинаете видеть систему, а не просто код.
Совет новичку
Когда вам дают новую задачу, всегда спрашивайте себя (или даже того, кто принес
задачу): «В рамках какою проекта или продукта я работаю и какое требование реали
зую?», «Как моя задача влияет на общий результат?», «Что случится, если я сделаю
это пезже или иначе?» Понимание этого контекста превращает вас из простого испол-
нителя в ценного участника команды, который видит цель своей работы понимает
цель компании.
7.1.2. Системы управления задачами
Системы управления задачами (таск-трекеры или трекеры)— это ежедневный ин-
струмент для командной работы. Здесь располагаются задачи, с которыми работает
команда и лично вы — в виде карточек на доске (Kanban) или в бэклоте. Фокус —
на исполнении и прогрессе.
♦ Примеры: Jira, Yandex Tracker, Trello, Wrike, Asana.
♦ Кто использует: разработчики, тестировщики, дизайнеры, тимлиды.
♦ Доступ клиентов обычно нет (это «кухня» команды). Иногда — доступ на чте-
ние для отслеживания прогресса.
Что нужно знать новичку?
♦ Это ваша основная рабочая среда.
♦ Умение четко описать задачу, вовремя обновлять статус и логировагь время ра-
боты — норма.
♦ Изучите workflow вашей команды (например: Open —> In Progress -> Testing —>
Done). Уточните, кто и когда должен переводить статусы
Российская специфика
♦ Крупные компании и госсектор: Yandex tracker (часто обязателен), Wrikc (по-
пулярен для кросс-функциональных проектов).
♦ Средние компании: Jira, Asana.
♦ Стартапы и небольшие команды: Trello, Notion.
♦ Важно! После 2022 года многие компании переходят с Jira на другие российские
решения
7.1.3. Системы управления требованиями (СУТ)
В трекере указываются текущие задачи, но где-то надо хранить все требования,
ведь они могут меняться — и это будут новые задачи. Поэтому задачи и требования
должны быть разделены. В системах управления требованиями (СУТ) содержится
информация о том, что нужно сделать. Здесь хранятся требования, пользователь-
ские истории и сценарии.
♦ Кто использует: бизнес-аналитики, продакт-менеджеры, архитекторы.
♦ Доступ клиентов: частичный доступ для согласования требований.
Преимущества СУТ
♦ Можно вести параллельно несколько версий требований.
♦ Прозрачность для всех участников.
♦ Отслеживание привязки функций к версиям продукта.
Российская реальность
Большинство компаний обходятся без специализированных СУТ. Требования
хранят’
♦ в wiki-системах (Confluence, Яндекс.Вики);
♦ в электронных таблицах;
♦ в Битрикс24 и других корпоративных порталах.
Что делать, если СУТ нет?
♦ Используйте единую структуру (например, создайте шаблон) для всех требова-
ний. Пусть это будет простая таблица с парой колонок, но этим вы уже сделаете
первый шаг.
♦ Четко отмечайте статусы и привязывайте их к задачам. Так как если функцио-
нальность меняется, то надо всегда понимать, в какой версии ее привнесли. Тут
один из самых простых вариантов — прямо в самих, требованиях указывать но-
мер задачи из трекера, тогда вы сможете всегда понять, что сделано, когда сде-
лано, а что только запланировано.
♦ Риск: разрозненные (то есть разбросанные по разным частям вашей wiki) требо-
вания приводят к путанице и ошибкам. Связывайте их (давайте ссылки), объ-
единяйте и переписывайте, но точно не делайте вид, что вы ничего не нашли.
Подавайте пример коллегам.
Совет новичку
Во многих российских компаниях требования хранятся в головах избранных людей.
Будьте настойчивы, но деликатны: просите фиксировать их в документах (wiki) или
фиксируйте сами.
Новичку часто сходу видно недостатки в том, как хранятся требования в конкретной
компании (например, неудачная структура). Не пытайтесь это поменять, но фиксируйте
свои замечания (и предложения). Со временем вы сможете двинуться вверх по карьер-
ной лестнице, просто предложив удачные решения для существующих проблем
7.1,4. ALM-системы — единые платформы
для всего жизненного цикла
ALM (Application Lifecycle Management) — это система управления жизненным
циклом приложений. Она связывает управление требованиями, задачами, кодом,
тестированием и сборками. ALM позволяет отследить полный путь: от требования
до работающего кола.
Российская специфика
Полноценные ALM-системы — удел крупных корпораций, хотя уже есть россий-
ские решения. Чаще используются связки. Например:
♦ Yandex Tracker - Яндекс.Вики + GitLab,
♦ Битрикс24 + 1С + собственные решения.
7.1.5. Другие системы управления в IT
♦ Управление проектами (Wnke, «1С:РМ Управление проектами», MS Project) —
сроки, ресурсы, бюджет.
♦ Управление продуктом (Productboard, аналоги в Битрикс24) — стратегия, бэкло-
ги, лорожные карты
♦ Управление тестированием (TestRail, Testlt, Qase, Zephyr) — тест-кейсы, плани-
рование тестов.
♦ Контроль версий (Git, GitLab, GitHub, GitVerse) — хранение кода и управление им.
Советы новичку
1. Составьте список используемых решений;
• В какой системе мы ведем задачи? Какой у нас трекер? (Ваша ежедневная работа.)
• Где хранятся требования?
• Как задачи связаны с требованиями и кодом?
• Где можно увидеть дорожную карту продукта?
2. Не теряйтесь в требованиях. Если в компании нет четкой системы, то поступайте
следующим образом
• Всегда уточняйте источник истины: «Это актуальные требования?*
• Фиксируйте несоответствия. «Я нашел два варианта требований — какой верный?»
• Сохраняйте ссылки на требования в задачах' в описании или хотя бы в коммен-
тарии.
7.2. Методы приоритизации задач
Вам знакомо чувство, когда заказчики, менеджеры и коллеги говорят: «Это сроч-
но!», а в бэклоге уже 200 задач? Поздравляю — вы столкнулись с главной пробле-
мой разработки: всё сделать невозможно, нужно выбирать
7.2.1. Важнее не срок, а место в очереди
Конкретные сроки часто зависят от точности оценок, срочности задач, но приори-
тет задачи в бэклоге — это осознанное решение. Расстановка приоритетов — слож-
ный навык, поэтому в командах этим обычно занимается один человек: Product
Owner (владелец продукта) или менеджер.
Совет новичку
Если к вам приходят с просьбой сделать что-то «очень срочно», спросите: «Понимаю.
Давайте уточним у [имя Product Owner / руководителя], как это повлияет на теку-
щие приоритеты?» Так вы не говорите «нет», а перенаправляете решение к тому,
кто отвечает за результат работы команды
7.2.2. Две большие разницы: продуктовые и проектные задачи
В России подход к приоритизации сильно зависит от типа задач.
Продуктовые задачи (развитие основного продукта)
Пример: улучшение интерфейса мобильного банка
♦ Ценность для пользователя — сделает ли это продукт лучше?
♦ Затраты — сколько сил потребует?
♦ Риски — можем ли что-то сломать?
♦ Зависимости — нужны ли другие отделы'команды?
♦ Окно возможностей — актуально ли к определенной дате (например, к запуску
налогового вычета)?
Проектные задачи (платные доработки для конкретных клиентов)
Пример: интеграция «1С?> с системой банка для корпоративного клиента.
♦ Финансовая выгода — сколько сразу принесет денег?
♦ Штрафы — есть ли риск заплатить пеню за срыв сроков?
♦ Обязательства — чго обещали клиенту в договоре?
Российская специфика
Во многих российских компаниях, особенно в условиях экономии, в бэклоге преоб-
ладают платные проектные задачи. Это нормально, но если продукт перестает раз-
виваться — это тревожный сигнал.
7.2.3. Практические методики приоритизации
Рассмотрим наиболее распространенные методики, которые позволяют расставить
приоритеты.
Ценность/Затраты (Value/Effort)
'Это простая и наглядная методика. Работает она так: оцениваем каждую задачу по
двум осям, ценность для бизнеса и трудозатраты (усилия) от команды (рис. 7.1).
« С । ратегические ходы »
Высокая
цен ноето
«Быстрые победы»
Низкая
ценность
О
О
о о
Тактические задачи
О
Не делать / пересмотреть
--------------------►
Низкие затраты
Б ысокие затраты
Рис. 7.1. Пример расположения задач согласно методике Ценность/Затраты
В результате получается диаграмма, в которой приоритет в первую очередь отдает-
ся задачам «ценные» и «дешевые». Они будут первыми в бэклоге. Остальные мож-
но даже не рассматривать, а вернуться к ним позже, когда будет понятно, что самые
приоритетные завершены Почему не стоит сразу тратить на них время? В целом
можно сделать и так. но если задач наберется достаточное количество, то по мере
реализации у команды будет появляться опыт как в оценке задач, так и в ценности
их для бизнеса.
Пример
• йысокая ценность / Низкие затраты «Добавить оплату через «СберПэй» в интер-
нет-магазин». Быстрая реализация, а охват — все клиенты Сбера.
• Низкая ценность / Высокие затраты: «Переписать дизайн личного кабинета в кор-
поративных цветах» Трудоемко, а польза сомнительна.
Эта методика проста и наглядна, однако точность оценки ценности и затрат у таких
задач может страдать и достаточно субъективна.
В этой методике есть и существенный недостаток. Можно получить продукт с ку-
чей классных фишек, но не реализующий самую основную бизнес-потребность
пользователя, потому что она оказалась очень дорогой.
Аналогия с открытием ресторана
У вас ограниченный бюджет, и согласно методике «ценность против затрат», можно
вложить деньги в классную посуду, а возможно даже технику и прочий инвентарь. Но
вот незадача, если так сделать, то можно оказаться в ситуации, что не найдено под-
ходящее место для ресторана и нет квалифицированного персонала, например, пова-
ров просто потому что это оказалось дорого
Безусловно, приведенная аналогия с рестораном абсурдна, а вот в разработке такой
абсурд действительно может случиться. Поэтому, на мой взгляд, использовать ме-
тодику ценности против затрат можно, когда продукт уже находится на плато, то
есть в нем уже реализованы все основные бизнес-функции. Если же продукт нахо-
дится в стадии рождения, то лучше использовать другой подход.
Совет новичку
Предложите команде на встрече быстренько разложить 10-15 ближайших задач на
доске по принципу VafueyEffcn. Это займет 15 минут, но сразу прояснит приоритеты
MoSCoW
Эта методика применима для жестких дедлайнов и запусков. Работает она так: де-
лим гадачи на четыре категории:
♦ М (Must have) — без этого нельзя.
Пример: расчет стоимости кредита в банковском приложении.
Российский пример: при запуске нового сервиса на «Госуслугах» в категорию
Must have автоматически попадают функции, требуемые законодательством (на-
пример, интеграция с ФНС).
♦ S (Should have) — очень важно, но можно запустить без этого.
Пример: история ранее рассчитанных кредитов.
♦ С (Could have) — хорошо бы иметь.
Пример: возможность отправить расчет кредита на e-mail.
♦ W (Won’t have) — нс в этот раз.
Важно!
В категории М должно быть не больше 30-40% задач. Если больше — план нереа-
листичен.
Недостатком такой методики является отсутствие расстановки приоритетов внутри
каждой группы.
Действуйте следующим образом: сузьте до минимума количество задач в категории
обязательных и реализовывайте их внутри категории так, как предложат техниче-
ские специалисты. А уже по другим категориям используйте предыдущую методи-
ку Ценность/Затраты.
RICE
Эта методика применима для зрелых продуктов и реализует подход, который дает
количественную характеристику приоритета. То есть конкретное значение в циф-
рах. Чем это число больше, тем выше у задачи приоритет. Методика разработана
компанией Intercom.
RICE-методика названа по аббревиатуре 4 факторов:
♦ Reach (охват) — количество пользователей, которых затронет реализация дан-
ной задачи за определенный период времени. Например, если после реализации
функция татронет 10 тыс пользователей, то Reach будет равно 10 000.
♦ Impact (влияние) — сила влияния операции или транзакции на каждого пользо-
вателя из охваченных Например, исправление критической ошибки, которая не
позволяет выполнить какую-либо основную функцию в системе (например, ав-
торизоваться), — это 3, а изменение орфографической ошибки — 0,25.
♦ Confidence (уверенность) — это поправочный коэффициент для двух преды-
дущих факторов. Он принимает значение от 50% до 100%. Всё, что ниже 50%,
следует принимать как 0%, То есть 50% — это низкая уверенность, например,
личное предположение, 80% — средняя степень уверенности, основанная на
аналогиях или иных непрямых доказательствах. 100% — это максимальная сте-
пень уверенности, основанная на данных А/В-тестов
♦ Effort (усилия) — затраты всех членов команды на реализацию задачи.
Метрика определяется путем перемножения значений «охвата», «влияния» и «цен-
ности» и деления на «усилия».
Российский пример для маркетплейса:
♦ Reach (охват): функция «уведомление о скидке» — 50 000 пользователей/месяц.
♦ Impact (влияние): 2 (высокое, пользователи активно реагируют).
♦ Confidence (уверенность): 100% (подтверждено АВ тестами).
♦ Effort (усилия): 5 человеко-дней.
♦ RICE = (50 000 х 2 х 1) / 5 = 20 000.
Использовать эту методику имеет смысл, когда есть данные для точных расчетов.
Для стартапов или при создании нового продукта она часто не подходит — нет ста-
тистики.
В российских компаниях ценность часто определяется следующим образом:
♦ Прямой доход/экономия.
Пример: внедрение робога-оператора в кол-центр мобильного оператора для
экономии на зарплат ах.
♦ Стоимость задержки (Cost of Delay).
Пример: не запустили онлайн-продление ОСАГО к очередном}' всплеску спро-
са — потеряли 10 млн руб. потенциального оборота.
Метрика Полярной звезды
Каждое подразделение может использовать в работе свои метрики — например,
команды продаж — метрики дохода, а команды поддержки — метрику удовлетво-
ренности. Такой подход способен привести к тому, что будут оптимизированы
процессы, направленные на достижение своей целевой метрики, а в целом компа-
ния и продукт будут двигаться не туда. Как в известной басне «Лебедь, рак и щука».
Полагаю, что кому-либо из вас известны случаи, когда при достижении локальной
цели общие результаты оставляли желать лучшего. Например, маркетинг привлек
нерелевантных пользователей ради своей локальной метрики «количество новых
клиентов», а продукт не может их удержать.
Чтобы такого не происходило, в отделах, кот орые работают над одним продуктом,
следует воспользоваться метрикой Полярной звезды.
Метрика Полярной звезды (North Star Metric, NSM) — это общая метрика, опреде-
ляющая ценность для ключевых пользователей. NSM должна отвечать на вопрос:
«По какому критерию определяется, что продукт успешен и что клиенты получают
от него реальную пользу?»
Для продуктовой команды NSM важнее, чем доход, потому что доход — это ре-
зультат ценности.
Примеры NSM для компаний из разных сфер:
♦ сервис такси — количество поездок;
♦ сервис сообщений — количество отправленных сообщений;
♦ сервис бронирования отелей — количество успешных бронирований;
♦ интернет-магазин — количество выкупленных заказов.
Как видите, ни у одного примера нет такой NSM-метрики, как выручка или прибыль.
Совет новичку
Спросите на одном из первых совещаний: «Какая у нас главная метрика продукта?»
Ответ сразу покажет, что в компании считают по-настоящему ценным
7.2.4. Главное правило приоритизации
Делайте в первую очередь то. что приносит максимум ценности и требует миниму-
ма усилий.
Но помните, что самая ценная задача— та. которая решает реальную проблему
пользователя и ведет продукт к его По.тярной звезде. Ваша задача как профессио-
нала— не просто «закрывать таски», а понимать, как каждый из них влияет на об-
щий успех.
7.3. Как правильно оценивать трудозатраты,
сроки выполнения и ценность для бизнеса?
Оценка в IT — это нс точная наука, а вероятностный прогноз. Пожалуй, еще более
неточные оценки бывают разве что на стройке. Хотя и тут можно поспорить. В от-
личие от них, оценка, например, того, сколько времени блюдо будет доставляться
из ресторана, достаточно точна. Разработка — процесс творческий, и в отличие от
заводского производства, где на каждое действие есть нормо-час, в IT нет двух
одинаковых задач. Ни один разработчик не может дать оценку с точностью до часа.
Российская специфика здесь находит свое выражение в том, что в российских ком-
паниях иногда присутствует культура жесткого планирования «сверху», когда сро-
ки спускаются без учета реальных возможностей команды. Ваша задача— нау-
читься давать реалистичные оценки и аргументировать их.
7.3.1. Относительные оценки: почему они работают лучше?
Люди плохо оценивают всё в абсолютных величинах, но хорошо сравнивают в от-
носительных.
Пример из жизни
Зозьмите два мобильных телефона и попробуйте определить вес каждого в граммах.
Без весов это будет сложно. А вот понять, какой тяжелее, и даже сказать примерно, во
сколько раз — вы сможете легко.
Исходя из этого, в IT используют относительные единицы оценки.
Story Points (сторипоинты)
С их помощью определяется относительная оценка задачи, учитывающая: объем,
сложность и неопределенность.
Работает это так:
]. Выбирается эталонная простая задача = 1 SP (story point).
2. Используется последовательность Фибоначчи: 1, 2, 3, 5. 8. 13...
3. Чем больше задача — тем выше неопределенность.
Примеры для интернет-магазина.
♦ изменить цвет кнопки — 1 SP;
♦ добавить новый способ оплаты — 8 SP;
♦ реализовать систему кэшбэка — 13 SP.
Покер планирования (Planning Poker)
Команда коллективно оценивает задачи. Каждый выбирает каргу с оценкой в за-
крытую, затем результаты — особенно крайние значения — обсуждаются.
Оценки в футболках (T-Shirt Sizes)
Задачи оцениваются по размерам: XS, S, М. L, XL. Методика та же — определить,
футболка какого размера «налезет» на задачу.
Часы «идеальные» и «реальные»: аналогия с аэропортом
Допустим, дорога в аэропорт занимает 1 час. Но что может пойти не так?
♦ Проверка багажа при входе в метро: +10 минут.
♦ Пробка на подъезде к аэропорту: +20 минут.
♦ Ожидание лифта, автобуса: +10 минут.
Итог: один «идеальный» час превращается в 1,5-2 «реальных» часа.
Точно так же и в разработке. При оценке нужно учитывать:
♦ написание кода;
♦ тестирование и автотестирование;
♦ деплой компонентов;
♦ внезапные совещания,
♦ помощь коллегам.
Метод критической цепи: умный подход к запасам
При планировании связанных задач часто закладывают запас на каждый этап, но
это неэффективно.
Пример неправильного подхода:
1. Собрать вещи: 30 минут (запас 15).
2. Доехать до мегро: 20 минут (запас 10).
3. Проехать на метро: 40 минут (запас 20).
4. Итого: 100 минут работы + 45 минут запаса
Метод критической цепи предлагает следующий подход: берем реальное время
(100 минут) и добавляем общий буфер на неопределенность (30% = 30 минут).
Итого: 130 минут вместо 145.
В больших проектах такая экономия может составлять недели и месяцы
Признаки качественной оценки:
♦ Оценивает тот, кто делает. Менеджеры часто занижают оценки, разработчики
ошибаются в обе стороны. Роль менеджера — уточнять, а не диктовать
Российская практика, в условиях цейтнота менеджеры могут давить. Ваша зада-
ча — спокойно аргументировать свою оценку.
♦ Требования должны быть ясны. Кажущаяся простой задача после уточнения
требований может переоцениваться в несколько раз.
Совет новичку
Если требования размыты, так и скажите: «Не могу оценить точно, пека не пойму, что
именно нужно сделать»
♦ Учитываются все затраты. Не только код, но и тестирование, деплой, докумен-
тация.
Российская практика в стартапах часто экономят на тестировании. Предупреди-
те о рисках такого подхода.
♦ Декомпозиция задач. Чем меньше задача — тем точнее оценка. Большие задачи
нужно дробить.
Совет новичку
Задачи больше 8 SP обычно требуют декомпозиции
♦ Проведение ретроспективы оценок: сравнивать прогноз с реальностью, выявлять
причины расхождений.
Российская специфика: в некоторых компаниях ретроспективы проводят фор-
мально. Настаивайте на их ценности.
Помните! Оценка— это не гарантия, а прогноз. Его точность может быть хуже
прогноза погоды. Лучше дать реалистичную оценку и уложиться в нее, чем обе-
щать нереальные сроки и подвести команду и бизнес.
Цель оценки — не «угадать» сроки, а принять правильные решения какие задачи
делать, в каком порядке, и понимать их реальную стоимость.
7.3.2. От относительных оценок к реальным срокам
Бизнес не интересуют оценки в майках, story point или других «попугаях». Бизнес
очень любит красивые и круглые цифры и даты. Например, 1 сентября или 31 де-
кабря. И часто всё подгоняется под желание большого босса получить результат к
какой-то конкретной дате, независимо от объема работ и возможностей команды.
Иногда в роли такого большого босса выступают государственные органы, которые
издают законы, заставляющие отодвинуть в сторону любые задачи и срочно взяться
за их реализацию.
Пример из жизни
Если вы думаете, что принятые законы дают время на адаптацию программного обес-
печения, то приведу такой интересный пример.
В Индии S ноября 2016 года около 20 00 правительство объявило о том, что банкноты
номиналом 500 и 1000 рупий перестают быть законным платежным средством с полу-
ночи следующего дня А эти банкноты составляли более 80% всех наличных денег е
стране.
То есть у людей было менее четырех часов для того, чтобы решить i зпрос со своими
купюрами, и оборот наличных в стране фактически остановился
Л программное обеспечение в банкоматах было не готово работать с новыми купюра-
ми. потому что банкоматы надо было физически перепрограммировать.
А потом не говорите, что месяц на подготовку' — это очень мало.
Бывают, конечно, даты, взятые не из воздуха, а полученные по вполне понятным
причинам. Например, вряд ли будет актуально делать новую акцию на цветы уже
после 8 марта: туг дата действительно важна. Аналогично это касается и вопроса
различных изменений в законах и подзаконных актах. Например, вступление како-
го-либо правила с определенной даты. Безусловно, в этом случае дата реализации
крайне важна.
7.3.3. Как перевести Story Points r сроки?
Если вы работаете no Scrum, го после нескольких спрпнтов команда узнает свою
скорость (velocity) — сколько SP она стабильно делает за спринт.
Пример:
♦ Скорость команды: 40 SP за 2-недельный спринт.
♦ Задача оценена в 8 SP
♦ Значит, задача займет примерно 2-3 дня работы одного разработчика.
При расчете срока необходимо закладывать буфер на риски — в этом случае он
прибавляется к трудозатратам.
Учитывать в таком буфере следует:
♦ внезапные совещания (15-20% времени);
♦ помощь коллегам,
♦ согласования и ожидания;
♦ болезни и отпуска.
Совет новичку
Всегда озвучивайте на какой период рассчитана ваша опенке: «Эта оценка актуальна
на ближайший спринт. Через месяц приоритеты могут измениться».
В Канбане используется другой подход измерения времени выполнения (cycle
lune). Команда анализирует, сколько времени в среднем задачи проводят в работе
от начала до завершения.
Пример:
♦ средний cycle lime команды: 3 дня;
♦ новая задача— похожей сложности;
♦ прогноз: будет готова через 3-4 дня.
7.3.4. Как определить ценность для бизнеса?
Суть любой приоритизации: делать в первую очередь наиболее ценное и наименее
затратное. Но как определить ценность9
Метрика Доход/Экономия
Метрика Доход/Экономия учитывает прямой или косвенный доход от реализации
задачи.
Пример
Внедрение робота-оператора - кол-центр для экономии на зарплатах
Совет новичку
Спросите: «Сколько денег это сэкономит или заработает в год?» Если ответа нет —
ценносто не доказана.
Российская реальность
В кризис ценность часто определяется не доходом, а выживанием. Задача «сократить
расходы на облачную инфраструктуру на 40%» может быть важнее всех новых функций
Стоимость задержки
Стоимость задержки (Cost of Delay) учитывает, во что обойдется задержка реали-
зации.
Пример
Не запустили тнлайн-продление ОСАГО к сезонному всплеску— потеряли 10 млн
руб. оборота
Модель Кано
Модель Кано представляет собой классификацию функций по удовлетворенности:
♦ базовые — без них продукт нежизнеспособен (кофейня без эспрессо);
♦ вау-фичи — вызывают восторг;
♦ линейные — чем больше, тем лучше.
Совет новичку
Покажите продукт-менеджеру вашу классификацию функций по Кано. Это поможет
проверить гипотезы о ценности.
Оценка возможностей
Оценка возможностей (Oppommity Scoring) — поиск ^болевых точек» пользователей.
Пример
Опрос пользователей «Банк онлайн» выявил, что 60% не могут найти историю ..пера
ций старше 3 месяцев — это стало основанием для улучшения.
Совет новичку
Посмотрите отзывы в Арр Store/Google Play — там часто есть готовые идеи для улуч-
шений
Удовлетворенность клиентов
Удовлетворенность клиентов (CSAT/NPS1) — показатель удовлетворенности кли-
ента после конкретного взаимодействия с продуктом.
Российская специфика
Многие компании формально собирают NPS, но не используют для приоритизации
Спросите. «Как последний опрос NPS повлиял на наш бэклог?»
Помните, что ценность фичи, которой еще нельзя пользоваться, независимо от того,
по какой методике она определена, — это лишь гипотетическая ценность. Истин-
ную ценность часто можно оценить только после выпуска продукта.
Совет новичку
Если сомневаетесь в ценности задачи — предложите выпустить минимальную версию
(MVP) и измерить результат на реальных пользователях.
1 CSAT (Customer Satisfaction Score)— пока1атель удовлетворенности клиентов. Измеряете* сразу
после взаимодействия с продуктом или услугой (например, после звонка з поддержку, покупки в.
приложении). NPS (Nel Promoter Score) — индекс лояльности клиентов. Показывает, готовы ли клиен-
ты рекомендовать ваш продукт другим людям.
7.4. Основы OKR/KPI:
как задачи связаны с целями компании?
Если вам как разработчику поставили цель «увеличить скорость загрузки страницы
на 20%», то может показаться, что это просто очередная задача из бэклога, которая
не очень и нужна. Но если понять, откуда она берется, то работа резко обретает
смысл. Оказывается, что решение указанной задачи поможет достичь цели компа-
нии «снизить процент оттока пользователей на 15%». В этом случае вы уже не про-
сто оптимизируете код — вы помогаете бизнесу удерживать клиентов
Даже если лично у вас нет OKR и KPI, вам всё равно следует прочитать этот
раздел, чтобы понять, как работает целеполагание, и достичь нужных вам резуль-
татов.
Понимание логики целеполагания требуется вам, чтобы:
♦ Осознанно выбирать задачи.
Не просто выполнять то, что дали, а понимать, какие из задач действительно
двигают продукт или проект вперед.
♦ Аргументировать свою позицию.
Когда вы предлагаете потратить время на технический долг, вы сможете объяс-
нить это не как «хотелку», а как вклад в стратегические цели (например, «ско-
рость вывода новых фич» или «надежность системы»).
♦ Доз ввариваться о ресурсах.
Чтобы попросить дополнительного тестировщика или время на рефакторинг,
нужно уметь показать, как это повлияет на обший результат, а не просто сказать,
что команда не успевает.
♦ Стать партнером, а нс исполнителем.
Когда вы видите общую картину, вы начинаете предлагать решения, а не просто
исправлять ошибки. Эго ключевое отличие старшего специалиста от начинающего.
OKR и KPI— это просто самые распространенные термины, которыми бизнес го-
ворит о целях. Разобравшись в них, вы придете к пониманию того, чего на самом
деле хочет компания, даже если формально эти системы не используются.
7.4.1. Два иида целей: KPI и OKR
Выделяют два разных подхода к постановке целей KPI и OKR.
KPI
KPI (Key Performance Indicators)— это ключевые показатели эффективности. KPI
измеряют текущую деятельность и оценивают операционную (регулярную) работу.
Примеры КРГ в IT:
♦ для команды поддержки: «Среднее время решения обращения нс более 4 часов»;
♦ для отдела разработки: «Количество критических инцидентов в продакшене = О»;
♦ для DevOps: «Доступность системы 99.9%».
OKR
OKR (Objectives and Key Results) — это цели и ключевые результаты. OKR исполь-
зуется для достижения стратегических целей команды и компании.
Пример OKR для продукта:
♦ цель — стать самым удобным банковским приложением для молодежи;
♦ ключевые результаты;
• повысить оценку пользователей в Арр Store с 4,5 до 4,8;
• запустить 3 новые функции, востребованные людьми в возрасте до 30 лет;
• увеличить NPS с 30 до 50.
Успешные компании обычно используют обе системы:
♦ KPI — для контроля качества текущих процессов,
♦ OKR — для достижения прорывных результатов.
То есть иметь и KPI, и OKR — абсолютно нормально.
OKR формируются сверху вниз: от уровня компании к подразделению (отделу),
команде и конкретному сотруднику.
Так, например, может выглядеть формирование OKR от компании к конкретной
команде.
♦ Уровень I. Компания.
• Цель: стать лидером рынка в области ритейла в сегменте В2В-решений.
• Ключевые результаты:
° увеличить долю рынка с 15% до 25%;
° запустить 3 новых продукта для корпоративных клиентов;
° достичь NPS 60-г.
♦ Уровень 2. Отдел разработки.
• Цель: создать платформу для быстрого запуска новых клиентов с их индиви-
дуальными доработками.
• Ключевые результаты:
° внедрить микросервисную архитектуру;
° сократить время выхода на рынок с 6 до 3 месяцев;
° обеспечить 99,95% доступности сервисов.
♦ Уровень 3. Команда backend-разработки.
• Цель — построить систему обработки данных, которая уйдет от монолита в
микросервисы.
• Ключевые результаты:
° разделить монолит на микросервисы;
° обеспечить время восстановления системы < 15 минут;
° снизить задержку ответа критических API до 100 мс.
Хотя стратегические OKR задаются руководством, их конкретная реализация
должна обсуждаться с командами.
Пример неправильного подхода:
♦ Руководство; «Хотим увеличить доход на 30%».
♦ Команда: «Но мы не контролируем ценообразование и продажи».
Пример правильною подхода:
♦ Руководство «Наша цель — рост дохода на 30%».
♦ Команда разработки: «Мы можем внести свой вклад через:
• улучшение конверсии на 15% за счет оптимизации UX;
• снижение расходов на инфраструктуру на 20%;
• ускорение вывода новых платных функций на рынок».
7,4.2. Российская специфика KPI и OKR
В российских компаниях часто происходит формальное заимствование подходов
без понимания самого их смысла. OKR превращаются в список обычных задач, а
KPI — в инструмент для штрафов.
В российских компаниях часто наблюдаются два противоположных подхода:
♦ Задачи спускаются сверху:
• цели спускаются без обсуждения;
• цели могут меняться из-за изменения приоритетов компании:
• команды не чувствуют ответственности за результат;
• низкая вовлеченность исполнителей.
♦ Полная независимость — каждая команда сама по себе"
• отсутствие единой стратегии;
• дублирование усилий;
• конфликт интересов между отделами.
Совет новичку
Если вам спускают OKR, которые кажутся нереалистичными, то не отвергайте их сра-
зу, а предложите альтернативный путь достижения цели; запросите дополнительную
информацию о контексте предложите поэкспеоиментиоовать с MVP
7.4,3. Кому подходят KPI, а кому — OKR?
Нужно понимать, что разным ролям подходят разные цели. Кому-то больше подхо-
дит KPI, кому-то CKR, хотя возможно и их совмещение.
♦ KPI хорошо работают для ролей с повторяющимися процессами:
• тестировщики (количество найденных критических багов);
• DevOps ин женеры (врем я доступное ги системы);
• специалисты поддержки (время решения обращений);
• операционные менеджеры.
♦ OKR более эффективны для творческих и стратегических ролей:
• разработчики (решение сложной технической задачи);
• продуктовые дизайнеры (улучшение пользовательского опыта),
• архитекторы (внедрение новых технологических стеков).
• проду кт-менеджеры.
7.4.4. Работают ли цели?
Мой личный опыт показывает, что несмотря на всю нелюбовь сотрудников к целям
и несмотря на все недостатки работы с К_Р! и OKR, они работают и работают доста-
точно эффективно. Однако успех зависит от правильной реализации:
♦ цели должны быть амбициозными, но достижимыми;
♦ прогресс должен быть виден всем участникам;
♦ система не должна превращаться в бюрократию.
Совет новичку
Начните с малого — сформулируйте личные OKR на первый квартал работы Напри-
мер, цель: стать полноценным членом команды Ключевые результаты самостоя-
тельн закрыть 10 задач из бэклога, получить положительный отзыв от тимлида по
code review, изучить основную бизнес-логику продукта
7.4.5. Российская специфика постановки целей
В российских 1Т-компаниях сложились свои особенности работы с целями.
♦ Гибридные системы — многие компании используют смесь КР1 и OKR. Бывают
еще некие подходы к нормированию труда— например, нужно выполнить в
день не менее 10 заявок.
♦ Жесткая привязка к деньгам— во многих российских компаниях достижение
KPI напрямую влияет на премиальную часть. То есть у сотрудников часть вы-
плат зависит от достижения КР1. Также такое практикуют и с OKR, несмотря на
го, что OKR — эго вообще не про деньги.
♦ Цели часто спускаются топ-менеджментом без учета мнения команды.
♦ Для сложных задач типа «улучшить архитектуру» бывает трудно подобрать
измеримые показатели, но т акие цели вес равно лоявляют ся
Если в вашей компании и лично на вашу роль внедрена система KPI, обязательно
уточните следующее:
♦ Какие именно данные используются для расчета показателей?
♦ Насколько показатель зависит лично от вас9
♦ Как часто происходит пересмотр КРР
7.4.6, Чьи цели стоит изучить в первую очередь?
♦ Цели компании в целом.
Изучите, если она есть, миссию, стратегические цели на год или квартал. Часто
они публикуются во внутренней wiki-системе или озвучиваются на общих соб-
раниях, если такие есть.
♦ Цели вашего непосредственною руководителя (тимлида/менеджера).
Спросите прямо: «У вас есть KPJ или OKR9 Какие три ключевых результата для
нашего отдела являются самыми важными в этом периоде? Как моя работа мо-
жет максимально помочь в их достижении?». Во-первых, сам интерес к целям
босса может повысить ваш рейтинг в его глазах, во-вторых, если вы еще и по-
можете ему их достичь, то отношение к вам будет лучше, чем к остальным.
♦ Цели смежного подразделения.
Попробуйте узнать цели подразделений, с которыми вы работаете. С одной сто-
роны, вы сможете получить новых друзей, если им поможете, с другой стороны,
сможете занести им цели, которые полезны вам (даже через руководителя).
7.4.7. Когда KPI важнее здравого смысла?
В погоне за выполнением формальных показателей команды иногда попадают в
ловушку, где KPI становится важнее бизнес-рсзультата. Важно уметь это распозна-
вать и мягко сигнализировать о проблеме.
Реальный пример из российской практики:
♦ Ситуация: КР1 команды разработки — «количество завершенных задач в спринте».
Команда начинает дробить крупные задачи на десятки мелких, искусственно на-
кручивая показатель. В итоге — формально КР1 выполнен, но бизнес-ценность
не создана, т. к. ни одна крупная фича не была закончена.
♦ Что делать?
Аккуратно показать руководителю эту связь: «Я заметил, что в этом месяце мы
закрыли 50 задач, но все ини были мелкими. При этом ключевая фича «X» для
клиента так и не сдвинулась с места. Возможно, нам стоит пересмотреть KPI,
чтобы он лучше отражал реальный прогресс?»
Другой пример
♦ Ситуация: KPI отдела тестирования — «минимум 90% тест-кейсов должны быть
пройдены».
Чтобы достичь такого KPI, тестировщики могут пропустить важные сценарии,
проверяя в первую очередь легкие. Результат — в версию, которая доходит до
клиентов, попадают серьезные ошибки, но KPI формально выполнен.
♦ Что делать?
Предложить добавить в KPI весовые коэффициенты для тест-кейсов разной кри-
тичности или метрику «количество пропущенных критических багов».
7.4.8. Что еще полезно знать о цепях других?
♦ «Скрытые» цели.
Помимо официальных OKR, у людей есть личные цели. Например, «стать экс-
пертом по . в команде» или «запустить крупный проект» Помо1ая коллегам в
их личных целях, вы помогаете создать профессиональные отношения.
♦ Приоритеты целей.
Узнайте, какие цели для вашею руководителя или команды являются основны-
ми, а какие — нет. Это поможет вам правильно расставить приоритеты и опера-
тивно переключаться между задачами, когда это будет необходимо
♦ Метрики успеха.
Спросите не только о самой цели, но и о том, как именно измеряется ее дости-
жение. Это поможет вам самим предлагать конкретные, измеримые улучшения.
♦ Зависимости.
Цели вашего тимлида почти наверняка зависят от целей других отделов. Пони-
мая эти связи, вы начинаете видеть бизнес-процессы в целом и можете предла-
гать более системные решения.
♦ Российская специфика.
Во многих российских компаниях инициатива и личная заинтересованность це-
нятся особенно высоко Умение видеть абсурд в K.PI и понимать цели партнеров
выделит вас как ценного сотрудника, а не просто исполнителя.
Советы новичку
Создайте для себя личную «Карту влияния». В центре — ваша основная роль. Нари-
суйте стрелки к целям вашего тимлида, продукт-менеджера, смежных команд и даже
ключевых В2В-партнеров. Подпишите, как ваши ежедневные задачи (аналитика, напи-
сание кода, тестирование, деппой) влияют на каждую из этих целей Это простое уп-
ражнение кардинально изменит ваше понимание ценноси вашей работы
Если вы работаете в В2В-сегменте, то у ваших партнеров тоже есть свои цели и KPI.
Ваш успех зависит от того, насколько вы поможете им достичь их показателей. Не
удивляйтесь, если лредепенные проекты находятся в активной шадии. а по другим
надо всё время напоминать.
7.4.9. Что делать, если цели нужны вам?
Не просто говорите: «Дайте мне цели». Подходите конструктивно с предложения-
ми. Ваша цель — понять контекст и показать свою вовлеченность.
Фразы для диалога:
♦ «Я хочу лучше понять, как моя работа влияет на обший результат. Не могли бы
вы поделиться своими OKR на квартал, чтобы я мог ориентироваться на них?»
♦ «Чтобы я мог правильно расставлять приоритеты в своих задачах, давайте по-
смотрим, какие из них больше всего влияют на ваши ключевые показатели».
♦ «Я вижу, что мы много работаем над [ваш текущий проект]. На какой ключевой
результат компании это работает?»
7.4.10. Что делать,
если и компании нет ясных целей?
Иногда в компании не говорят о явных целях и метриках. Если вы действительно
хотите показать результат, а не только мотивированы на деньги, то можете про-
явить инициативу и сделать следующее:
♦ Спросите на встрече с руководителем- «Какие результаты важны для нашего
отдела в этом квартале?»
♦ Предложите провести сессйю по целеполаганию — даже для небольшой команды.
♦ Сформулируйте личные цели на основе понимания продукта и пользователей.
♦ Используйте метрику Полярной звезды как ориентир. Если ее нет. то предложи-
те сформулировать и зафиксировать ее — хотя бы как одну из целей.
7.4.11. Составление целей — это отдельная работа
Многие новички ошибочно полагают, что сформулировать цели достаточно легко.
В реальности качественная цель — это результат аналитической работы:
♦ проанализировать предыдущие периоды;
♦ изучить метрики продукта;
♦ учесть возможности команды;
♦ согласовать со смежными отделами;
♦ проверить на реалистичность.
Совет новичку
Начните вести личный реестр целей — документ куда вы будете записывать: идеи пс
улучшению продуктов/лроцессов, наблюдения за проблемами пользователей, предло-
жения по оптимизации работы команды, данные для обоснования своих предложений.
7.4.12. Примеры из практики для разных ролей
♦ Для разработчика:
• в начале квартала: «Хочу улучшить производительность приложения»;
• в течение квартала: собираете данные о медленных запросах, анализируете
логи, считаете потенциальный эффект;
• к концу квартала: у вас есть готовое обоснование для OKR на следующий пе-
риод с конкретными цифрами и расчетами.
♦ Для тестировщика:
• наблюдение- «30% багов обнаруживаются уже после релиза»,
• сбор данных: анализ причин, расчет времени на исправление;
• результат: обоснованное предложение по внедрению автоматизации регрес-
сионного тестирования.
♦ Для DevOps-инженера:
• идея: уменьшить время развертывания;
• данные: сейчас деплой занимает 40 минут, из них 25 минут — ручные опера-
ции;
• расчет: автоматизация сэкономит 20 человеко-часов в месяц;
• готовый OKR: снизить время деплоя до 15 минут к концу квартала
Российская специфика
Во многих компаниях процесс целеполагания формализован и происходит в строго
отведенные периоды (обычно в конце кваргала). Если вы придете с неподготовлен-
ными предложениями, их просто не успеют рассмотреть.
7.4.13. Ошибки, которые часто допускают
♦ Предлагать цели без расчетов — «давайте сделаем быстрее». Для целей нужны
четкие метрики.
♦ Формулировать размыто— «улучшить качество кода». Опять же метрики —
качество кода улучшилось, как метрика изменилась?
♦ Не учитывать ресурсы — предлагать изменения, требующие 200 человеко-часов,
когда доступно 50.
Важно понимать, что качественные цели не появляются сами по себе — их нужно
ютовить заранее, как шеф-повар готовит ингредиенты для сложного блюда. Начи-
найте эту работу’ в начале отчетного периода, и к моменту планирования у вас бу-
дет весомый задел тля обсуждения.
- ЧАСТИН-
КОМАНДНОЕ ВЗАИМОДЕЙСТВИЕ
- Глава 8-
Эффективная коммуникация
8.1. Принципы конструктивного общения
Конструктивное общение любят абсолютно все. Команды разработки — не исклю-
чение. Новичку нужно понимать базовые принципы коммуникации и использовать
их в своей работе.
♦ Будьте прямолинейным, но не грубым. Оставайтесь вежливым.
В 1Т ценят ясность и экономию времени. Не нужно заходить издалека и задавать
много наводящих вопросов — говорите сразу по делу В российской 1Т-культуре
прямота приветствуется, однако важно сохранять уважительный тон. Не грубите
и не ждите, что вам ответят моментально.
♦ Задавайте вопросы полностью в одном сообшении, а не разделяйте их на
множество маленьких.
И отвечайте тоже полностью. Допустимо разбивать один длинный ответ на не-
сколько вопросов, но не надо писать, как в личной переписке, как с другом.
Можно поприветствовать коллегу и сразу задать вопрос. Не ждите ответного
«Привет!» Некоторых это раздражаез.
Прежде чем написать сообщение, сформулируйте его: «Какую конкретную про-
блему я хочу решить?». Начинайте сразу с нее.
♦ Опирайтесь на факты, а не на эмоции.
Не надо говорить «у меня ничего не работает» или «всё сломалось». Что сотруд-
нику делать с этой информацией? Он не должен своими вопросами допытывать-
ся у вас о сути проблемы. Мнение о новичке, который не дает конкретной ин-
формации, быстро испортится.
Вместо этого четко изложите ситуацию — например, опишите сценарий, скажи-
те, что вы уже сделали, и затем задайте вопрос или озвучьте просьбу. Покажите,
что вы цените время другого человека: «Перезапустил сервис— не помогло
Проверил логи — там нет сообщений об ошибках, но информация о самих дан-
ных есть, то есть сервис работает. Возможно, дело в настройках сети, но не уве-
рен Подскажете, в каком направлении искать9» — такое сообщение показывает,
что вы уже приложили усилия.
♦ Уважайте время своих колле!.
Постоянно отвлекать коллегу личными сообщениями и упоминаниями в общих
чатах — это еще один способ вызвать раздражение Без необходимости нс стоит
этого делать.
Просто пересылать переписку или добавлять в переписку людей, которым она
не нужна, — признак неумения работать с информацией.
♦ Умейте слушать и переспрашивать.
Очень много проблем в работе возникает из-за простого недопонимания (mis-
communication). Каждый участник переписки может прочитать свое.
После любого обсуждения, особенно устного, полезно резюмировать догово-
ренности: «Понял. Значит, к пятнице я делаю А и Б, а ты к среде обеспечиваешь
доступ к тестовым данным Всё верно?» Это страхует от ошибок и «испорченно-
го телефона».
Совет новичку
Привыкайте уточнять и переформулировать. Фразы «Правильно ли я понял, что...» и
«Давай уточню одну деталь » — это нормальные рабочие фразы. Более того, их обя-
зательно использовать, когда диалог оказался достаточно большим.
♦ Сообщайте о проблемах заранее.
Очень частая ошибка новичка — не сообщить о том, когда становится ясно, что
задача не будет выполнена вовремя. Если вы новичок, то надеюсь, что вы не по-
лучите задачу, которая находится на критическом пути, но бывает так, что это
все-таки происходит. Поэтому сообщайте о проблемах заранее или как только
поняли, что что-то идет не по плану. Руководители ценят не тех, кто никогда не
ошибается, а тех, кто предупреждает о проблемах заранее.
Неважно, новичок вы или нет, но если вы понимаете, что не укладываетесь в
срок или столкнулись со сложными проблемами, то говорите об этом. И, по воз-
можности, говорите не только о проблеме, а о возможных вариантах ее решения.
♦ Критикуйте решение, а не человека.
«Что за ерунда тут написана?» — используйте эту фразу, если хотите нажить се-
бе врагов. Она обижает собеседника и закрывает диалог.
«В этом модуле я вижу высокую связанность. Пола1 аю, его будет сложно тести-
ровать. Давайте обсудим, как можно выделить эту логику' в отдельный сер-
вис?» — лучше гак.
Совет новичку
2 некоторых российских командах тон общения может быть резковатым. Часто это
следствие высокой нагрузки на команду, а не признак неуважения. Старайтесь отде-
лять эмоции от сути замечания. Посмотрите, как этот же сотрудник общается с други-
ми, может быть, это просто его характерная черта
♦ Выбирайте правильный канал для общения.
Можно выделить три уровня:
• личная переписка используется для индивидуальных вопросов, сомнений,
обсуждения ошибок или деликатных тем;
• командный чат или задача в трекере — для рабочих вопросов, где нужно
мнение или помощь нескольких участников;
• общий чат отдела или компании — для официальных объявлений, итогов и
решений, касающихся большого количества людей.
Спросите себя: «Кому действительно необходимо это знать?» Выбирайте канал
соответственно. Посмотрите на действия других людей (даже если это руково-
дитель) и поймите, действительно ли надо делать так же? Не пытайтесь равнять-
ся на руководителя, у него могут быть свои мотивы писать что-то публично.
♦ Фиксируйте договоренности.
Если что-то не записано, то этого не было. Нужен протокол. Решение надо за-
креплять письменно по нескольким причинам:
• вы неправильно поняли друг друга,
• вы поняли друг друга правильно, но что-то забыли.
Протокол позволит вернуться к этому позже. Идеально — с датами и фамилиями.
После любой более или менее важной договоренности сразу зафиксируйте ее
письменно. «Договорились: я делаю [что], ты отвечаешь за [что], к [сроку]». От-
правьте это собеседнику.
♦ Фокусируйтесь на решении, а не на конфликте.
У каждого из вас могут быть сложные вопросы и противоположная точка зре-
ния. Нужно обсуждать эти вопросы, а не превращать разговор в противостояние.
Сравните два подхода:
• конфронтационный: «Ваш отдел постоянно всё задерживает!»
• конструктивный: «Я обратил внимание, что интеграция с вашим сервисом
стала узким местом для нас. Давайте вместе подумаем, как ускорить процесс,
возможно, мы что-то делаем некорректно?»
В некоторых коллективах существует негласное правило: «жаловаться — непро-
дуктивно». Поэтому говорите не о том, «что плохо», а о том, «как можно сделать
лучше».
♦ Сохраняйте спокойствие и профессиональный тон.
Усталость и раздражение — это те эмоции, которые вы рано или поздно будете
испытывать на любой, даже самой лучшей работе. Однако эмоциональные со-
общения создают напряженную атмосферу и подрывают доверие. Новичкам та-
кое могут не простить.
В условиях жестких дедлайнов и меняющихся требований, характерных для
многих российских проектов, выдержка и хладнокровие ценятся высоко. Не на-
до быть безучастным, надо реагировать профессионально
Совет новичку
Если чувствуете, что эмоции захлестывают, отложите отправку сообщения или пись-
ма. Сделайте перерыв, переключитесь на что-то другое, перечитайте и отредактируй-
те текст, убрав из него личную оценку, и предложите конструктив
♦ Вкладывайтесь в рабочие отношения.
Вам будут охотнее помогать и пойдут навстречу, если у вас сложились хорошие
рабочие отношения Помощь в смежном вопросе, простая человеческая под-
держка — это то, что поможет вам решить проблему в будущем. Практически с
каждым можно выстроить общий диалог. Даже с самыми «неудобными» со-
трудниками.
В российском IT неформальные связи часто облегчают решение рабочих вопро-
сов. С вами будут больше считаться и охотнее сотрудничать, даже если это не
нужно кому-то другому
Совет новичку
Участвуйте в командной жизни, проявляйте искренний интерес к коллегам: как к спе-
циалистам и как к людям
Главный вывод: эффективная коммуникация — это не всегда талант. Это, скорее,
развиваемый навык. Начните с пары принципов, внедрите их. Вы заметите, как ме-
няется отношение коллег и растуз ваша личная эффективность и ваш авторитет.
8.2. Методы эффективной коммуникации
В любой команде существуют несколько способов взаимодействия, начиная от
обычных утренних встреч и заканчивая письмами. Я разделю их на следующие
грушгы:
♦ регулярные встречи;
♦ встречи один на один;
♦ обсуждение вопроса, проблемы или задачи;
♦ внутренняя документация
8 .2.1. Регулярные встречи команды
Такие встречи обычно проходят с определенным интервалом, реже — по необхо-
димости, и на них собирается команда или, иногда, внешние слушатели (речь про
демонстрацию). Ежедневные стендапы, планирование, демонстрации, уточнения
бэклогов и ретроспективы подробно рассматриваются в главе 9. Здесь же я больше
расскажу именно про эффективность в коммуникациях.
8 .2.2. Встречи один на один
С каждым сотрудником время от времени надо поговорить один на один. Это
встречи, которые так и называются: один на один (one to one, 1-to-l или 1-2-1). На
них предполагается более откровенный разговор, чем на встречах команды Б моей
практике подобные диалоги происходят обычно между руководителем и одним из
членов команды.
Целей у таких встреч несколько.
♦ сотруднику иногда нужно выговориться, поделиться проблемами. Нс обязатель-
но, что руководитель сможет все их решить;
♦ сотрудник может рассказать про какие-то личные моменты, для рассказа о кото-
рых нет другого подходящего места, например, о личных беспокойствах, вопро-
се зарплаты, конфликте с кем-то;
♦ руководитель также может здесь поделиться своими идеями, проблемами и во-
просами. Например, встреча один на один— это прекрасное место для того,
чтобы поговорить о планируемом повышении и обсудить планы и желания со-
трудника о том, куда он хочет двигаться.
Встречи один на один должны оставаться таковыми — темы разговоров нельзя
описывать или выкладывать в общих чатах, а также передавать кому-то (выше-
стоящему руководителю, HR). Но не надо и скрывать факт того, что такие встречи
проводятся. Тем нс менее, если возник вопрос, который требует вынесения на дру-
гой уровень, то это стоит обсудить и договориться, что эта информация уйдет вовне.
Встречи могут проводиться и с сотрудниками, нс находящимися в прямом подчи-
нении. То есть это может быть в т ом числе встреча с руководителем руководителя.
Встречи один на один могут носить как регулярный, так и случайный характер, но
они должны быть. В резульгатс таких встреч выстраиваются доверительные отно-
шения между их участниками.
Совет новичку
Не бойтесь встреч один на один. Заэанее записывайте вопросы для разговора: что
идет не гак, что нравится, что нужно. Это тот самый удобный момент, когда можно по-
говорить с руководителем или наставником.
8 .2.3. Форматы эффективного обсуждения
опросов и проблем
Часто возникают ситуации, которые необходимо обсудить, — например, вопросы,
возникшие на регулярных встречах, но не требующие присутствия всех их участ-
ников. Такие встречи могут занимать достаточно много времени и часто призва-
ны решить один конкретный вопрос. В этом разделе я расскажу о возможных ва-
риантах проведения таких встреч и о том, как провести такую встречу наиболее
эффективно.
E-mail
Я отметил этот вариант, потому что иногда действительно встречаются ситуации,
когда вопросы и проблемы в команде пытаются решить по почте. Переписка в поч-
те — наименее эффективный способ коммуникации в командах разработки. Я на-
деюсь, что вы не работаете в команде, где почта — это самый популярный способ
взаимодействия. Если вам не повезло, и непосредственный руководитель общается
с вами только через e-mail, то я рекомендую быстрее оттуда бежать.
Нельзя сказать, что почта не нужна. Нужна и даже обязательна в следующих с.1учаях:
♦ формальные согласования с заказчиком;
♦ отчеты с большим количеством материалов;
♦ важные информационные материалы, которые могут потребоваться в будущем
или требуют вдумчивого решения. К таким, например, относятся изменения в
правилах работы, которые при необходимости нужно произвести.
Но если внимательно посмотреть на список возникающих обычно вопросов, то вы
увидите, что нет никаких оснований общаться внутри команды именно с помощью
e-mail. Болес того, я повторюсь, чго общение через e-mail недопустимо, когда мож-
но просто поговорить. Зафиксировать результат — да, можно в почте, но обсудить
вопрос или проблему — нет.
Чаты
Команды разработки достаточно много времени проводят в чатах. Ведь у чата есть
одно преимущество — за ним можно не следить постоянно, а ответить, когда удоб-
но, не отвлекаясь от решения текущей задачи. Кроме того, чаты эффективны в рас-
пределенных командах, иногда находящихся в разных часовых поясах.
Чаты полезны в случаях.
♦ обсуждения оперативных вопросов, не требутощих глубокого погружения, когда
кто-то из членов команды может знать ответ или решение;
♦ короткого незначительного обсуждения или решения общего вопроса.
Чаты не стоит использовать в качестве хранилищ важной информации, тем более,
если она нигде более не содержится. Вы можете в чате отправить ссылку на доку-
мент, хранящийся в надежном источнике, но не следует публиковать гам сам доку-
мент, если чат станет его единственным хранилищем.
Аудиозвонки
Если вопрос не удается решить за несколько минут в чате, то для его решения ино-
гда эффективнее созвониться.
У многих разработчиков в команде возникает стойкое нежелание общаться по те-
лефону, поскольку они предпочитают, чтобы вопросы были четко сформулированы
письменно. В части случаев это справедливо; зачем поднимать трубку лишь для
того, чтобы услышать поток сознания, особенно если самому' звонящему проблема
до конца не ясна. Особенно напрягают ситуации, когда проблему или задачу нс хо-
тят сформулировать, а пытаются «накидать». В таких ситуациях действительно
аудиозвонок — это только потеря времени.
Совершенно другое дело, когда конкретные вопрос или проблему нужно сосредо-
точенно обсудить с несколькими сотрудниками в формате полною погружения.
Тут аудиозвонок может явиться гораздо лучшим решением При этом, если есть
понятная повестка созвона. содержащая конкретные вопросы, то, возможно, на раз-
говор согласится даже самый неуступчивый сотрудник.
Но всё же учтите, что многим некомфорт но общаться голосом, и они предпочитают
письменное общение, — с уважением относитесь к таким сотрудникам, однако не
позволяйте им без необходимости игнорировать важные встречи, которые будут
проводиться в аудио- или видсоформате.
Видеовстреча
Еще более эффективным способом коммуникации для решения вопросов является
видеоконтакт. Не просто звонок, а именно встреча, когда можно увидеть собесед-
ника. Почему? В момент видеозвонка можно увидеть и понять, на одной ли вы вол-
не с тем, с кем общаетесь. Невербальная коммуникация очень важна. Аудиовстрече
без камер, особенно если вопрос обсуждается более чем парой собеседников, мо-
жет помешать то, что участники начинают заниматься параллельно несколькими
другими делами. Например, отвечают кому-либо в чате или отвлекаются на чтение
почты. А общаясь под камерой, сотрудник знает, что за ним могуэ и будут наблю-
дать, даже если он в тот момент ничего не говорит.
Когда лучше проводить видеовстречу:
♦ видеовстрече стоит уделить внимание в сложных переговорах или в конфликт-
ных ситуациях;
♦ генерацию идей или принятие ключевых решений также имеет смысл проводить
именно в формате видеозвонка;
♦ общение с клиентами, знакомство с сотрудником, доверительный разговор тет-а-
тет также удобно проводить с включенной камерой.
Видеовстреча — идеальный вариант для решения ключевого, сложного и объемно-
го вопроса, требующего погружения всех участников, когда нет технической воз-
можности пообщаться лицом к лицу.
Очная встреча
Видео хоть и передаег часть жестов и мимики, но не все Практически самым эф-
фективным способом коммуникации является очная встреча. Очная встреча— это
больше возможностей увидеть собеседника или посмотреть на коллектив Как го-
ворят, можно взглянуть глаза в глаза Основные особенности очной встречи:
♦ в режиме оффлайн гораздо сложнее выпасть из диалога, ведь окружающие при-
сутствуют и всё видят. Хотя, конечно, это не всех останавливает;
♦ эмоциональная связь появиисгся быстрее и лучше. Это особенно важно д,гя
ключевых встреч Те же шутки вживую воспринимаю гея лучше;
♦ отсутствует задержка в передаче материалов — нет оснований для сбоев;
♦ отсутствует возможность утечки информации
Очная встреча у доски
Я специально выделил очную встречу у доски, а не стал относить ее к очной встре-
че в целом. Такие встречи являются самым эффективным способом коммуникации.
В чем же столь значительное ее отличие от просто очной встречи?
♦ Восприятие информации.
Известно, что многие воспринимают визуальные образы лучше, чем слова. А на
доске можно писать и рисовать— метафоры отлично запоминаются, а написан-
ное рукой лучше сохраняет ся в памяти.
♦ Флипчарты, маркеры и стикеры, даже самые удобные, работают у доски гораздо
понятнее.
Оторвать бумажный листик, написать на нем что-то и провести между записями
стрелку — легко, но показать это сразу всем участникам — сложно. А на доске
несложно быстро набросать требуемую схему, которую увидят все собеседники.
♦ Сотрудники, принимающие участие в обсуждении у доски, не склонны отвле-
каться на социальные сети или мобильные телефоны. Это рождает большую во-
влеченность.
♦ В обсуждениях прямо у доски появляется большая сфокусированность и снижа-
ется рассеянность.
Информация здесь не просто проговаривается, а фиксируется, и к ней можно
вернуться через несколько минут.
♦ У доски нет проблем с качеством картинки, разрешением монитора и оттенками
цветов.
На видеовстречах иногда бывает так, что для кого-то шрифт кажется слишком
мелким, а для кого-то— крупным, ведь все рабо1ают с разным оборудованием.
Само собой, у обычной доски такого не будет.
♦ Быстрота в решениях.
Стоя у доски, можно мгновенно передать маркер собеседнику, чтобы он быстрее
донес свою мысль.
♦ Готовые результаты.
Несмотря на то, что на доске получаются не всегда идеальные материалы, чер-
новые варианты всё равно гам присутствуют — на их основании можно в памя-
ти восстановить нужную информацию через какое-то время. А можно и просто
сфотографировать доску на смартфон.
♦ Еще со школы мы знаем, что информация, которую мы записали в тетради или
на доске, запоминается лучше, чем напечатанная в учебнике.
Лично у меня рядом с рабочим местом всегда были две доски, маркеры разных цве-
тов и стикеры. При очном общении я очень часто вставал и рисовал на доске мате-
риалы — они сохранялись у людей в памяти значительное время. И даже когда ма-
териалы давно были стерты, я слышал фразы вроде. «Помнишь, мы рисовали это у
тебя на доске». Возьмите себе за правило так делать, и вы увидите, насколько эф-
фективно будут решаться ваши задачи
Совет новичку
Не стесняйтесь брать маркеры и рисовать на доске. Даже те. кто лучше воспринимают
информацию голосом, подтянутся и будут участвовать в обсуждении.
Внутренняя документация
Документация — это тоже способ коммуникации. Для хранения долгосрочных ма-
териалов лучше использовать ту систему документации, в которой можно найти
документ поиском по тексту. Например, Confluence. Не зная точного названия до-
кумента. в ней можно найти нужный документ при помощи поиска.
В каких случаях нужно использовать именно формат внутренней коммуникации?
♦ Хранение материалов, требующих передачи знаний, — они могут быть полез-
ными в будущем.
♦ Хранение материалов, описывающих цели, миссии, OKR, и тому подобных до-
кументов, требующих письменной фиксации.
♦ Хранение сложных материалов, требующих погружения и исследования, — они
могут быть впоследствии изменены и уточнены.
♦ Хранение документов, в которых прописаны правила работы команды и компа-
нии: гайдлайнов, стандартов.
♦ Хранение материалов, содержащих постоянно возникающие типовые вопросы.
Например, у всех новичков появляются примерно одни и те же вопросы (формы
заявления на отпуск, заказа оборудования, заявки па доступ и т. п.) — лучше со-
хранить ответы на них в отдельный доступный документ.
♦ Хранение архивов важных протоколов или переговоров, особенно с заказчиками.
Внутренняя документация — полезна в долгосрочной перспективе, ее сложно под-
держивать. но со временем она даег результаты. Это игра вдолгую, и опа не подхо-
дит для решения быстрых и срочных вопросов.
Почему же я говорю здесь, что внутренняя документация — это тоже способ комму-
никации? А все дело в гом, что современные инструменты позволяют комментировать
каждое слово или предложение. Подобная коммуникация является uyiy6o вербальной,
однако для формальных и ключевых документов это абсолютно нормально.
Российская проблема
Документацию часто не обновляют, и она устаревает Если вы нашли несоответствие,
тс сами внесите правку или сообщите ответственным coiрудникам. Станьте гем, кто
улучшает, а не просто ругает.
8.3. Язык команды:
как понимать технические термины?
«Давайте не будем брать в спринт новые фичи, пока не пофиксим все критические ба-
ги». Если эта фраза вам понятна, то полагаю, что вы можете пропустить этот раздел.
Когда вы только-только пришли в IT или впервые слышите речь коллег, то их раз-
говоры могут показаться ьам бессмысленным потоком странных слов Это нор-
мально — профессионатьные жаргоны характерны для многих отраслей.
Особенность российских IT-компаний в том, что тут смешиваются русский и анг-
лийский языки. Бывает, что сотрудники поработали какое-то время за границей, и в
их речи больше английских слов Другие же, напротив, работали в России и в ком-
паниях, где иностранные 1Т-специалисты — не основной состав, гам будет больше
русских аналогов.
Откуда вообще берутся такие странные слова?
♦ Английский.
Большинство терминов — прямые заимствования, используемые некоторыми,
чтобы казаться умнее или профессиональнее.
♦ Сленг.
Обычно это английское слово из IT (может быть, переведенное), произнесенное
на русский манер: «зарелизить», «баг».
♦ Сокращения
Для скорости длинные названия превращаются в аббревиатуры (CI/CD, MVP,
SLA). Это не особенность российского IT — это общемировой тренд.
♦ Специфика компании.
В каждой отрасли или компании могут быть свои внутренние названия для про-
ектов, процессов или клиентов. Думаю, что вы слышали про НДС или НДФЛ
(это виды налогов). Таких терминов достаточно в каждой отрасли.
Совет новичку
При общении не с IT-специалистами, например, заказчиками, старайтесь не использо-
вать непонятные слова, применяйте аналоги на русском языке. Например, не «пофик-
сить баг», а «исправить ошибку». Так вы не будете выглядеть странно.
Что делать новичку, когда вы слышите непонятную фразу?
1, Не паникуйте и не делайте вид, что поняли, если не поняли.
2. Поспрашивайте, но правильно. Не говорите: «Я ничего не понял». Так гоже
можно, только это может разозлить коллегу и поставить собеседника в тупик.
Спросите четко:
• «Поясни, пожалуйста, чю значит [непонятное слово] в нашем контексте?»
• «Я пока не знаком с этой аббревиатурой. Расшифруешь?»
Самый простой способ проверить себя — так и сказать: «Правильно ли я понял,
что...» — и повторить своими словами, как вы это поняли Так вы сразу прове-
ряете свое понимание.
3. Ведите личный словарь заведите файл или заметку. Как только слышите но-
вое слово — сразу записывайте.
4. Ищите письменные источники. Идеально было бы прочитать документы (исто-
рии, требования)— так вы сможете найти нужный непонятный термин Воз-
можно, у вас во внутренней wiki-системе компании есть глоссарий.
В российских коллективах, особенно в технических, чаше ценят прямоту, а не же-
лание показать, что вы самый умный. Фраза «Я новичок, объясни, что значит этот
термин?» вызовет гораздо больше желания помочь, чем попытка манипулировать
тем, в чем вы не разбираетесь, — будете только глупо выглядеть Главная ловушка
для новичка— боязнь переспросить, чтобы «не выглядеть глупо». На деле всё на-
оборот. задавая вопросы, вы показываете желание разобраться и сделать работу
правильно Со временем вы привыкнете и будете всё говорить правильно
Совет новичку
Не пытайтесь вставлять только что изученные слова в свою речь, чтобы казаться ум-
нее Используйте понятные термины, вы будете выглядеть профессионально. Гораздо
хуже если вы скажете что-то, используя неверный термин, и сядете в лужу
В приложении 1 к книге собраны термины, которые мо!ут быть полезны новичку.
Вывод
Не надо бояться специфичного языка команды. Не учите наизусть термины Осваи-
вайте термины естественно и постепенно, через вопросы и погружение в работу Ва-
ша цель— не блеснуть знанием всех терминов, а понимать, что происходит, и быть
понятым другими людьми
8.4. Особенности взаимодействия
в российских командах
Нельзя сказать, что в российских IT-командах в этом плане всё однозначно.
8.4.1. Типы компаний
Существуют два типа компаний: консервативные и современные.
♦ Консервативные компании — с четкой иерархией и сильной вертикалью власти:
один большой начальник ставит задачу начальнику поменьше и так далее. Осо-
бенно это заметно в крупных компаниях, корпорациях с госучастием и в тради-
ционных отраслях, которые уже работают с IT
Особенности работы в таких компаниях:
• Решения часто спускаются вниз как директивы. Нельзя поспорить или обсудить.
• Ответственность за неудачи перекладывается вниз по цепочке. Виноваты ря-
довые сотрудники.
• Чем выше руководитель, тем сложнее до него донести информацию. С очень
большими руководителями общаются только на «Вы» и только по имени и
отчеству.
ЧТО ДЕЛАТЬ НОВИЧКУ
Изучите иерархию и не пытайтесь обойти непосредственного руководителя. Сначала
обсудите вопрос с ним. Будьте готовы к тому, что итоговое решение может прийти
«сверху», даже если команда предлагала иные варианты или была протия
♦ Современные компании— в стартапах, средних и небольших фирмах или в
фирмах, которые изначально пришли с Запада, где более «плоская» иерархия и
более простые отношения.
Особенности работы современных компаний:
• Решения могут приниматься коллегиально, но за лидером (например, СТО)
остается последнее слово. Командам дают возможность договориться, а не
спускают решение сверху.
• Открытый диалог. Можно подойти ко всем, вплоть до генерального директора,
и обсудить вопрос. Но I рани цы дозволенного все-таки не стоит нарушать.
• Ответственность разделяется между всеми участниками.
• Общение чаще на «ты» и просто но имени (без отчества).
ЧТО ДЕЛАТЬ НОВИЧКУ?
Проявляйте инициативу и высказывайте мнение, но будьте готовы, что финальное
решение примет ответственное лицо. Не воспринимайie это как игнорирование ваше-
го мнения — скорее, это компромисс или выбор меньшего из зол.
8.4.2. Стиль общения
В IT-компаниях из России ценят прямоту и ясность, даже если она покажется рез-
кой. Вы можете услышать прямые слова критики в адрес принятого решения. И не
всегда они будут сопровождаться смягчающими комплиментами. Например, можно
спокойно услышать фразу: «Это плохое решение». 'Эго нормальная рабочая атмо-
сфера, в которой никого не хотят лично обидеть.
Что ДЕЛАТЬ НОВИЧКУ?
Учитесь отделять эмоции от сути. Не надо принимать критику работы на свой личный
счет. Отвечайте по существу: «Понял проблему. Предлагаю такой вариант исправле-
ния » Если не согласны, то мотивируйте свое решение. Если не можете предложить
вариант, то попросите время, н вернитесь с ответом.
В России крайне важно неформальное общение. Можно использовать самые силь-
ные факты и аргументы, но если вам не будут доверять, то вы можете застрять на
каком-то простом вопросе из-за любой ерунды или формального момента. И на-
оборот, если у вас хорошие отношения, вам помогут в самой сложной ситуации.
Совет новичку
Участвуйте в неформальной жизни команды и компании Это поможет познакомиться
с людьми, коюрые в будущем упростят решение рабочих вопросов Но соблюдайте
границы
8.4.3. Правила и процессы
«Строгость российских законов компенсируется необязательностью их исполне-
ния» — крылатая фраза, известная многим. Какие бы четкие, правильные и нужные
правила ни были прописаны, всегда существует разрыв между тем, что написано, и
тем, как всё работает на самом деле.
Что делать новичку?
Сначала понаблюдайте, как работают процессы в команде и компании. Спросите: «Как
у нас принято делать на практике в такой ситуации?» Не критикуйте решения, а узнай-
те причины, если это возможно В ситуации, когда действия прямо противоречат пра-
вилам задайте прямой вопрос наставнику или руководителю
Я сторонник такого подхода, что правила должны работать так, чтобы их невоз-
можно было нарушить.
Аналогия из жизни
Вс многих странах мира, в том числе и у нас, можно в дорожной разметке увидеть
сплошную линию или двойную сплошную, которую нельзя пересека1Ь. Обычно такие
линии делают для безопасности Будут ли ее пересекать? Да, будут. Будут ли проблемы
с безопасностью'? Да. будут. При этом важно отметить что лучшим решением проблемы
является не просто нарисовать двойную сплошную и поставить камеру, а установить
бетонный ограничитель, который не позволит поехать по запрещенной полосе.
Также и в разработке. Если вам уже довелось описывать правила, думайте о том,
как будет контролироваться их исполнение. Идеальный вариант — автоматический
контроль, благо в 1Т-сфере много автоматических средств.
В компании бывают сложные периоды. В такие моменты будьте готовы к повы-
шенной нагрузке и более жесткому общению. Но будьте тем. на кого можно поло-
житься, — это высоко ценится и запоминается.
8.4.4. Взаимодействие между командами
Иногда в рамках одной компании пояа,1яюгся разные противоборствующие команды
или подразделения. Возникает конфликт, и конструктивной работы не получается.
Совет новичку
Старайтесь не вовлекаться в явные конфликты, возможно они вызваны личными
проблемами. Будьте профессионалом, коюрый в первую очеоедь четко выполняет
задачи для компании и для продукта.
8.4.5. Особенности работы
с заказчиками и руководством
Иногда руководители или даже заказчики ожидают, что команды разработки будут
делать то, что им скажут, и не станут задавать лишних вопросов. В некоторых си-
туациях может оказаться так, что в итоге бизнес не получит желаемого, а виновата
будет разработка, потому что сделала не то, что «на самом деле надо».
Что ДЕЛАТЬ НОВИЧКУ?
Задавайте вопрос, какую бизнес-цель или проблему решит заказчик. Со временем
предлагайте улучшения, но обязательна аргументируйте их. но не своим мнением, а
пользой для бизнеса’ «Если сделать так, как я предлагаю, это сократит вероятность
возникновения критического сбоя».
- Глава 9-
Командные ритуалы и встречи
В этой главе я подробно расскажу про те встречи, которые есть практически у всех
современных команд. Большинство из указанных встреч взяты из Scrum, но их ис-
пользуют и другие команды, даже не работающие с этим фреймворком.
9.1. Ежедневные стендапы:
что говорить и как слушать?
Ежедневные стендапы предназначены для быстрого выявления возникших про-
блем и озвучивания планов на рабочий день. Такие стендапы иногда в командах
называют «летучка». «дейли мигинг» (или просто «дейли») или просто «стендап».
Встреча должна быть короткий — не более 20 минут даже для большой команды,
для маленькой— нс более I0 минут Обычно они проводятся в первой половине
дня, чтобы всем членам команды было комфортно, уже понятно, кто отсутствует и
на кого нужно переместить срочную рабогу.
Совет
Если у вас встреча занимает больше 20 минут, и вы проводите ее очно у доски, то
проводите встречу стоя. Люди просто не любят долго стоять.
Типовые вопросы:
— Что делал вчера?
— Что планирую делать сегодня?
— Какие есть препятствия или проблемы?
Но помните про Kanban— там вопросы начинаются с конца доски: «Что нужно
сделать, чтобы переместить эту задачу на следующий этап?»
Надо понимать, что стендап нужен не просто для того, что сказать о проблемах, а для
того, чтобы решить их в дальнейшем. Если кому-то из коллег гребуется помощь, а вы
знаете, как его проблему решить или чем помочь, то сообщите ему об этом и догово-
ритесь с ним рассмотреть вопрос после встречи Не нужно пытаться разобраться с
проблемой здесь и сейчас, особенно если это локальный вопрос, который интересен
только этому коллеге. Даже если вы нсвичок, то всё равно можете обладать нужны-
ми навыками или недавно видели материалы, в когорых есть ответ на нужный во-
прос. Нормально сказать: «Как раз на днях читал это в правилах работы Давай оста-
немся после встречи, и я расскажу, какие материалы видел и где их найтго>.
Российская практика
У нас стендапы часто превращаются в формальность. «Вчера делал задачу А, сего-
дня буду продолжать делать задачу А, проблем нет». Это не приносит пользы, обсуж-
дайте такие уныпые стендапы на ретроспективе Не бывает так, что у сотрудника не
возникает сложностей, вопросов или проблем: или он просто не хочет о них говорить,
или не занимается задачей Даже самым крутым специалистам часто хочется с кем-то
посоветоваться и что-то обсудить. Безусловно, может случиться и так, что у сотрудни-
ка нет проблем На это только иногда и не может повторяться изо дня в день.
Развивайте культуру взаимопомощи в команде, не молчите о проблемах, но не да-
вайте ежедневным встречам затягиваться. Если вы новичок, это не значит, что вся
команда должна слушать только о ваших проблемах десятки минут.
Совет новичку
Говорите о реальных сложностях. Фраза «Не получается настроить стенд, нужна по-
мощь» — нормальна и полезна Молчание создает ложное впечатление прогресса,
что может приводить к срыву сроков. Как следствие, может возникнуть негатив «Чего
же ты молчал?»
9.2. Уточнение бэклога продукта
Бэклог, как мы уже знаем, — это приоритезированный список задач, требований и
идей продукта. Чтобы условно перевести идею в задачу и присвоить ей приоритет,
нужно понять требования по задаче и соответствующим образом ее оценить.
Когда у вас будет достигнуто понимание того, что хочет бизнес (зафиксирована
идея), и что эта задача действительно нужна бизнесу, проводится встреча для ее
разбора. Этот процесс называется уточнением бэклога продукта (Grooming или
Product Backlog Refinement). На такой встрече рассматриваются все непонятные
моменты, задаче дается оценка и ей присваивается в бэклоге нужный приоритет.
Иногда на такой встрече обсуждают одну задачу, а иногда — несколько неболь-
ших. Порой бывает и так, что на встрече разбираются задачи с уже более или менее
готовыми требованиями.
Логично, что команда при этом должна понимать, что от нее хотят. Поэтому иде-
альная для разработчика последовательность рассмотрения — сначала аналитика,
потом разбор, а для аналитика — сначала разбор с командой, потом аналитика. Но
на практике зачастую бывает нужна примерная сценка задачи еще до ее полного
описания. Это помогает правильно расставить приоритеты, а иногда— понять,
стоит ли вообше браться за эту задачу
Поэтому часто поступают так — проводят предварительный высокоуровневый раз-
бор. Процесс выглядит следующим образом:
1. Аналитик показывает команде суть задачи без детальных требований— «что»
нужно сделать; общую идею и минимальные требования.
2. Команда дает примерную опенку — этого хватает, чтобы понять порядок цифр.
3. На основе этих цифр заказчик принимает решение, реализовывать задачу, отло-
жить ее или вовсе от нее отказаться.
И только в случае, если задача всё же остается в бэклоге с высоким приоритетом,
аналитик погружается в детали и пишет полные требования. Таким образом, пред-
варительная оценка — это инструмент для управления приоритетами, а не для точ-
ного планирования.
Следует здесь отметить и российскую специфику:
♦ примерная оценка часто становится итоговой.
Гак бывает, потому что компаниям-заказчикам необходимо фиксировать бюд-
жет на какую-то доработку. За редким исключением, бюджеты фиксированы.
Бывает, конечно, резервный фонд, но это редкость. При этом, если заложить
риски, то заказчики могут попросить детально объяснить, откуда взялась «такая
большая оценка за такую небольшую доработку». Я слышал такое тысячи раз;
♦ в условиях сжатых сроков и желания получить решение как можно скорее этап
разбора могут проигнорировать.
В результате задачу с проблемами отдают к команду: «разберемся по ходу де-
ла». На мой взгляд — это главная причина срывов сроков и низкого качества:
♦ внезапно могут поменяться приоритеты.
Задача, которую вчера детально разобрали и поставили в план, сетодня может
быть отменена или заменена новой, более срочной. К этому нужно быть мораль-
но ютовым и не раздражаться.
Советы новичку
• На этапе уточнения задавайте максимум е опросов Не молчите, если вам что-то
непонятно Очень и очень хорошо задавать вопросы в формате «А что будет, ес-
ли. ?» или «А как система должна обработать вот эту ситуацию .?». Если вы с ко-
мандой что-то явно не укажете, а заказчик заплатит за работу, весьма вероятно
что вам сообщат, что это неучтенное требование — ваша сшибка которую конеч-
но вы обязаны исправить бесплатно
• Всегда говорите, какую оценку вы даете, и указывайте, заложили ли вы риски Ко-
гда даете какую-либо оценку, обязательно говорите; «Это предварительная оценка
без учета рисков. После детального описания и согласования требований она мо-
жет измениться на 50%».
• Научитесо распознавать срочные и плохо проработанные задачи Если в задаче
нет критериев готовности [Definition of Done), есть описание только основных сце-
нариев и нет альтернативных и отрицательных сценариев, а также нет ответов на
ваши ключевые вопросы, — этс сигнал что задала не готова к работе Сообщайте
об этом явно.
• Если в команде в принципе слабая аналитика, то учитесь задавать вопросы бизне-
су и выяснять, что же все-таки надо Важно понять суть задачи Я встречал множе-
ство задач, в которых была согласована аналитика, а после решения задачи выяс-
нялось, что сделали не то.
9.2.1. Как разбирать объемные и нетиповые задачи?
Сложные задачи требуют более глубокого погружения. Чтобы сохранить эффек-
тивность, рекомендую разбить их на этапы:
1. Выявление потребности.
Аналитик определяет реальную потребность клиента и изучает, как система ра-
ботав сейчас.
2. Черновой вариант.
Аналитик готовит верхнеуровневые требования — самые общие, без детальной
проработки. Главное — понять цель заказчика и то, как она соотносится с теку-
щей системой
3. Первичный разбор (мозговой штурм).
Команда встречается и разбирает черновые материалы. Желательно, чтобы уча-
стники ознакомились с задачей заранее.
4. Глубокая аналитика.
Аналитик фиксирует итоги обсуждения и проводит детальную проработку. Ис-
ходная задача обычно разбивается на несколько более мелких.
5. Финальный разбор.
Получившиеся подзадачи снова разбираются с командой, но уже детально.
Основной смысл такого подхода, когда и заказчик не знает, делать задачу или нет,
и команда не понимает, как ее оценить, в том, что команда не тратит время на де-
тальный разбор всех задач подряд. Вместо этого используется вариант с двумя эта-
пами:
1. Быстрая оценка масштаба для принятия решения.
2. Детальная проработка только для одобренных задач
Разница лишь в количестве итераций: для простых задач хватает одного цикла, для
сложных — нескольких.
Российские реалии
На практике часто сталкиваиися с двумя проблемами Во-первых, заказчик (особенно
внутренний, хотя бывает и внешний) действительно может не знать, чего хочет, фор-
мулируя требования крайне размыто: «Нам нужно что-то для анализа», или вообще
предлагает свое решение, не формулируя проблему, во-вторых, поскольку он просит
как можно скорее оценить задачу, то с учетом проблемы, отмеченной первой, может
получиться так, что задача окажется в несколько раз объемнее.
Совет новичку
Заша задача на этале первичного разбора — задавать максимально конкретные во-
просы. Не бойтесь сказать, что вам не хватает информации для оценки. Если вы
разбираете задачу и проговариваете ограничения или допущения то сразу записы-
вайте их. Есть шанс, что ваши ограничения заказчик так и не увидит, если вы их не
зафиксируете
9.2.2. Критерии успеха и ограничения
Встреч по разбору может быть несколько. Хороший результат— когда большая
задача разбита на подзадачи с оценкой по 1-2 дня па каждую.
Если достичь этого сложно (например, для совершенно нового модуля), старайтесь,
чтобы подзадача умещалась в одну итерацию (например, итерация в 2 недели). Вы
не получите полностью готовое решение, но поймете, что движетесь в верном на-
правлении.
Конечно, можно попытаться разобрать большую задачу за одну встречу, но это
чревато ошибками и упущениями, Удерживать фокус команды долго сложно, по-
этому лучше ограничивать встречу одним часом.
Этот итеративный подход позволяет эффективно прорабатывать даже самые слож-
ные задачи, не перегружая коман ду и минимизируя риски.
Российские реалии
В российских компаниях, особенно работающих по каскадной (водопадной) модели
или с госзаказчиками, бывает обратная ситуация' задачи разбирают и утверждают за
много месяцев до начала реализации За это время могут поменяться и требования, и
реалии, но процесс пересмотра может оказаться чрезвычайно сложным
Совет новичку
Если вы начинаете работать над задачей, которая была разобрана давно, потратьте
время на быструю ревизию Проверьте, не изменилось ли что-то в смежных системах,
не появились ли новые требования, в том числе в законах. Сообщите команде, если
обнаружите несоответствия, — так переделок будет меньше
Обратите внимание, что детально разбирать задачу необходимо ближе к тому мо-
менту, когда планируется начать ее реализацию. В противном случае некоторые
тонкости могут быть утеряны, и придется восстанавливать их повторно.
Условно изобразить процесс работы над задачей можно в виде диаграммы, пред-
ставленной на рис. 9.1.
Задача размера XL Разбор с командой Задача размера L Разбор с командой
Задача размера L
Рис. 9.1. Процесс работы команды над большой задачей
Задача размера М Задача размера М
Задача размера L
Тут необходимо соблюдать некий баланс. При попытке разбиения задачи нужно
придерживаться INVEST-модели пользовательской истории1 — например, разбить
' INVEST-модель пользовательской истории описана в приложении 2.
задачу на подзадачи (в некоторых командах практикуют такой подход). Подзадачи
могут не обладать указанными ранее требованиями к задаче (бизнес-ценностью,
понятностью и тестируемостью), то есть сами по себе не нести бизнес-ценностп
или не быть пригодными для тестирования по сценариям, как. например, в случае
разделения задачи по технологическим слоям:
♦ разработка frontend;
♦ разработка backend;
♦ разработка mobile.
В этом случае историю можно проверить целиком только тогда, когда выполнены
все подзадачи. Иногда в виде отдельной подзадачи также выделяют этап тестиро-
вания.
Российские реалии
Разбиение задач по технологическим слоям (frontend,’backend) — распространенная
практика, особенно ч крупных компаниях с четким разделением ролей Разработку та-
ких подзадач могут вести разные команды, отвечающие за различные части системы.
Проблемы в таких командах обнаруживаются поздно
Совет новичку
Даже если задача разделена по технологическим слоям, постарайтесь синхронизиро-
ваться со всеми участниками, даже если вы входите ь состав одной команды. Можете
предложить провести короткую встречу, чтобы свериться и не обнаружить нестыковку
в день сдачи работы Проявляя инициативу в коммуникации между командами, вы
становитесь ценным сотрудником
9.3. Планирование итерации (спринта)
Цель планирования — спланировать работы на определенный период времени.
Основные свойства планирования итерации:
♦ в планировании участвуют все члены команды. Это нужно чтобы команда по-
нимала свои задачи. Идеально, если озвучивается цель итерации;
♦ итерацию мо1ут называть «спринтом» (это термин из Scrum). Команда должна
зафиксировать объем работ, которые планирует выполнить за итерацию, и отве-
чает за этот результат;
♦ команда может взять дополнительные «бонусные» задачи, но обычно нс гаран-
тирует их реализацию;
♦ задачи, выполненные в результате итерации, должны соответствовать критериям
либо команда может заранее уточнить, что часть критериев не будет реализова-
на. Например, команда покажет черновой вариант без финального тестирования
с отрицательными сценариями. Это нормальный подход — не стоит упрекать
команду за то, что она показывает сырой продукт. Лучше сразу увидеть пробле-
мы, чем дождаться финального тестирования, после чего всё переделывать и пе-
ретестировать;
♦ планироваться могут любые задачи, в том числе ошибки или консультации.
Российская специфика
Иногда планирование сводится к разбору целей, которые спущены сверху. Важно
учиться аргументированн обсуждать реалистичные сроки, основываясь на оценках, а
не только на желаниях руководства.
9.4. Демонстрация: обзор спринта
Демонстрация (демо) проводится для того, чтобы показать, что задача работает, и
получить обратную связь. В скраме демонстрация вместе с обсуждением прогресса
и планов называется обзор спринта (Sprint Review).
Основные характеристики обзора спринта:
♦ Демонстрация может как носить регулярный характер (например, по результа-
там спринта), так и проводиться по мере выполнения конкретных задач.
♦ Демонстрацию можно проводить сразу по нескольким задачам — думаю, это оче-
видно: если за итерацию сделали несколько задач, то можно все их и показать.
♦ Лучше проводить небольшие итерации, но чаше.
♦ Для ключевых задач лучше делать отдельные демонстрации — на них может
возникнуть много вопросов.
♦ В демонстрации может участвовать как вся команда (для ключевых задач —
точно вся), так и только часть команды, занимающаяся реализацией. В целом, на
мой взгляд, командный дух от демонстрации неключевых задач не страдает.
Российские реалии
• Демочстоации часто превращаются в формальность, особенно если заказчик или
владелец продукта в ней не участвуют. Команда показывает работу, но реальная
обратная связь будет позже и уже в совсем другом тоне.
• В условиях постоянной нехватки времени демонстрации могут переносить, сокра-
щать или отменять, что приводит к непониманию и появлению ошибок В конце
концов опять же заказчик остается недовольным
• ь некоторых компаниях особенно в госсекторе или крупных корпорациях, демон-
страция — это не столько обсуждение, сколько формальный отчет о выполненной
работе, где критика не приветствуется.
Совет новичку
Не бойтесь демонстрировать свою работу с первых же задач. Да, это может быть
стресс Но тем быстрее вы вырастете в глазах своих коллег как по команде, так и по
компании. Продумайте сценарий который вы будете показывать, н> не стоит заучи-
вать всё наизусть и усердно репетировать, — всё должно быть естественно и понятно
Если в сценарии предполагается ожидание (например, подождать 5 минут), то поду-
майте либо о том, как его сократить (установить 1 минуту вместо 5 для демонстра-
ции), либо чем заполнить паузу (можно показать другую маленькую задачу). Не пуай-
тесь, если во время демонстрации заметят какую-то шибку или проблему, просто со-
общите, что еы ее видите, записали и исправите или передадите нужным людям.
9.5. Ретроспектива:
даем и получаем обратную связь
Ретроспектива проводится для того, чтобы порефлексировать, обсудить результа-
ты работы свои и команды, запланировать улучшения.
Основные свойства ретроспективы:
♦ Ретроспективы не должны быть частыми. Раз в месяц— это нормально, даже
если спринты раз в две недели. Отдельные итерации работы можно пропускать.
Не надо пытаться вытянуть проблемы, если их нет.
♦ Чтобы не забывалось, лучше фиксировать вопросы и проблемы в течение сприн-
та или другой работы.
♦ Если вопрос важный, то можно посвятить ретроспективу одному ключевому во-
просу. Не обязательно разобрать всё на свете.
♦ Ретроспективы касаются вопросов всей команды, личные вопросы лучше обсу-
ждать отдельно.
♦ На ретроспективе должны присутствовать все, включая руководителя. Обычно
на ретроспективе нет «лишних» людей, но могут быть приглашенные «гости».
♦ Должен быть кто-го, кто проведет ретроспективу, — это может быть как руко-
водитель, так и любой член команды. Можно пригласить кого-то стороннего,
кто умеет проводить ретроспективы, — фасилитатора. Это тот, кто не должен
принимать никакую из сторон, но поможет найти решение или докопаться до
сути проблемы
♦ Я даже рекомендую приглашать на роль фасилитатора какого-то руководителя
высокого ранга (в качестве ведущего встречи, который поможет группе прийти к
решению), особенно если он умеет проводить ретроспективы, а не забивает всё
своими идеями, — результаты таких ретроспектив могут удивить своей резуль-
тативностью Это можно делать не часто — например, раз в полгода.
♦ Плохо не проводить ретроспективы. Наивно думать, что команде нечего сказать.
♦ На ретроспективе запишите, что планируете изменить, и начните следующую
ретроспективу с достижений прошлой.
Российские реалии
• Ретроспективы часто воспринимаются сотрудниками как формальность или «раз-
бор полетов» с поиском виноватых, особеннт, если команда не доверяет руковод-
ству Из-за этого люди могут молчать или говорить только о незначительных про-
блемах
• Также подавлять открытое обсуждение (даже не специально) может непосредст-
венный руководитель, который вызвался быть ведущим ретроспективы
• Итоги оегроснектив часто ни к чему не приводят— решения записываются, но не
выполняются, что демотивирует команду.
Совет новичку
Ретроспектива — это самое нужное место, где можно изменить процессы в команде
Даже будучи нивичком, вы можете заметить то, к чему опытные коллеги уже привыкли
Говорите о конкретных ситуациях, а не об общих проблемах. Например «Р прошлый
вторник я по>ерял два часа, потому что не мог найти актуальные настройки для под-
ключения к тестовой базе. Предлагаю завести для таких данных единый документ».
Не бойтесь задавать уточняющие вопросы, если не понимаете суть обсуждаемой кол-
легами проблемы. Ваша свежий взгляд может быть очень ценным
- Глава 10-
Режим работы команды
В российской корпоративной культуре до сих пор часто встречается подход, со-
гласно которому о проблемах не принято говорить. Из-за этого о них и связанных с
ними авариях предпочитают молчать до последнего. Однако замалчивание иногда
лишь превращает небольшую проблему в серьезную аварию.
В этой главе мы разберемся с тем, как перестать бояться плохих новост ей и эффек-
тивно действовать, когда всё идет не по плану Вы узнаете, чем отличается разме-
ренный темп от «режима тушения пожара», научитесь вовремя подключать руко-
водство через механизм эскалации и поймете, как сохранять лицо в самых непро-
стых диалогах с заказчиками
10.1. «Спокойная разработка»
и «Аварийный режим»
Большая часть упомянутых ранее процессов наблюдается в то время, пока всё спо-
койно, то есть не случилось никаких аварий. Но они иногда случаются. Случаются
абсолютно у всех, какие бы вы или ваша компания усилия ни предпринимали, ава-
рии всё равно будут, потому что зависят не всегда от действий команды.
Не буду повторно вдаваться в детали спокойного режима работы', проходят еже-
дневные или другие регулярные встречи, обсуждения, демонстрации и ретроспек-
тивы. Команды заняты работой над задачами или исправлением ошибок. Это всё,
что мы рассматривали ранее.
Аварийный режим работы достаточно часто называют «режим тушения пожара».
Его признаки:
♦ В этот момент все обычные ритуалы могут быть отменены. Даже если они и ос-
таются в календаре, то часть из них может быть забыта, или на них придут не
все Возможно, что отменены будут и регулярные встречи, а также и другие за-
планированные ранее.
♦ Вместо обычных встреч могут быть организованы другие — аварийные, воз-
можно, периодические, например, каждые 2 часа.
♦ В некоторых случаях организуется круглосуточное дежурство.
♦ В особенно критических ситуациях могут быть остановлены вообще все процес-
сы, которые мешают восстановлению
10.1.1. Работа команды в аварийном режиме
Прежде всего эгу команду надо создать. В некоторых компаниях готовы к авариям.
Это как МЧС, которое готово к проблемам, — это их работа. В ряде компаний так-
же есть спасатели, которые понимают, что делать, и организуют работу других (на-
зову их «координаторами»). Если такой команды спасателей нет, то обычно она
может создаваться спонтанно. И тут важный момент — во главе нее может встать
не самый опытный или техничный, а самый активный или просто самый 1ромкий
или суетной Очень здорово, когда этот сотрудник еше и хороший технический
специалист, но во время пожара не технический скил выходит на первое место в
плане организации работы.
Идеально, если есть план аварийного восстановления (Disaster Recovery Plan, DRP),
и он может быть применим, но такое случается не всегда. DRP бывают разного
формата, но самое важное, что в нем расписано, кто и что должен делать для вос-
становления. DRP рождается задолго до аварии и требует усилий и времени. По-
скольку DRP есть не всегда, или он в ряде случаев неприменим, то решения в ре-
жиме аварии часто принимаются спонтанно и не всегда обдуманно, — всё зависит
от ситуации, опыта и навыков команды или координатора. Процессы игнорируют-
ся, и план действий вырабатывается по ходу разбора проблемы.
Задача команды — не запустить идеально работающее решение, а убрать проблему.
Иногда проблемы решаются обходными решениями (костылями), с которыми поз-
же предстоит разобраться.
Уровень стресса в аварийном режиме обычно критический, особенно у тех, кто не
часто принимает участие в авариях.
10.1.2. Действия новичка в режиме «пожара»
♦ Нужно понимать, что началась авария.
Очень и очень глупо подходить к сотруднику, который занят исправлением си-
туации, с вопросом, который к аварии не относится. Например, если попросить
помочь разобраться с повседневной задачей (допустим, ревью кода) в такой мо-
мент, то в лучшем случае вам скажут, что заняты, в худшем — отправят подальше
и подумают. что вы не понимаете, где границы разумного. Даже если вам кажется,
что сотрудник спокойно сидит, подумайте три раза, прежде чем к нему подойти.
♦ Не умничайте и не пытайтесь указывать, что команда работает не по правилам,
которым вас учили.
Наверняка сотрудники будут пренебрегать правилами, но не стоит указывать им
на это — они, скорее всего, понимают, что делают. Более того, ваш коммента-
рий может вызвать волну негатива. Держите язык за зубами, если вас не спра-
шивают.
♦ Не паникуйте.
Если вас привлекли для решения, а вам не понятно, что конкретно от вас ждут,
то сразу спрашивайте. «Потом» разобраться не получится — вы либо понимаете
сразу, либо говорите, что не понимаете, что от вас требуется.
♦ Записывайте происходящее (ведите протокол).
Если вас допустили до решения, но не дают активных действий, го хотя бы на-
пишите, что поняли. Нужно обязательно отмечать время события и порядок дей-
С1вий. Пишите ключевые события, а не всё подряд. Например;
1. 13:37 — создали аварийный чат.
2. 14:15 — у Николая появилась рабочая гипотеза.
3. 14:30 — Анатолий выдал обходное решение, полученное в результате про-
работки гипотезы.
4. 14:32 — Дмитрий установил обходное решение и проверил его работу
♦ После аварийного режима.
Приходите на анализ и выявление причин проблемы (постмортем). Основная
цель— добиться действий для того, чтобы ситуация не повторилась. Если были
применены обходные решения, то нужно зафиксировать, что их следует исправить.
10.1.3. Если вы активный участник команды,
которая занимается аварией
Если вы выступаете в роли того, кто исправляет аварию, и для вас это относительно
первая крупная авария в такой роли, то соблюдайте несколько правил:
1. Остановитесь на 30 секунд и немного подышите. Не надо бежать что-то делать
сломя голову.
2. Псрезатрузите ваше приложение. Если не помогло, то сервер целиком. Как бы
ни банально это звучало, но часто проблема лечится банальной перезагрузкой
приложения или сервера.
3. Выясните точно, что произошло. Вопросы, которые необходимо задавать:
• Что именно не работает9
• Для кою не работает (все пользователи, определенный регион, конкретный
клиент)?
• Когда (или после чего) началось?
• Есть ли в логах ошибки, коды ошибок, иные проявления проблемы?
• Что уже предприняли и вернуши ли назад или оставили как есть9
• Были ли обновления в нашем продукте пли смежных продуктах? В инфра-
структуре?
4. Отдавайте четкие и понятные команды, если применимо, то конкретным лю-
дям. Например: «Вася, проверь доступность кластера БД. Ответь в чат по го-
товности».
5 Если есть возможность, то запретите доступ к приложению, в котором про-
изошла авария. Идеально, если вы можете это запретить. Важно, чтобы никто
сбоку не пытался параллельно чинить проблему.
6. Особое внимание уделяйте работе с базой данных. Самые большие проблемы
возникают, когда во время решения проблемы вы делаете еще хуже Поэтому
если вы работаете на продуктивном сервере с правами на запись и удаление, то
делайте это в специальном режиме, многие средства для работы с БД позволя-
ют соответственно настроить продуктивные серверы и страхуют их на всякий
случай (например, не позволяют случайно удалить все записи, вместо одной).
Изучите эти средства заранее в той системе, с которой работаете.
7. Если изучаете файлы, логи или любую дру|ую информацию с нродуктива. то
используйте отдельный монитор — например, продуктив всегда должен быть
на правом мониторе. Так меньше шансов запутаться.
8. Информируйте по запросу, но попросите одно контактное лицо, чтобы не дуб-
лировать информацию. Можете назначить себе заместителя, который будет пе-
редавать информацию с ваших слов в чат
9. Если договорились собираться раз в какое-то время, то не игнорируйте встречи.
Иногда полезно просто прерваться.
10. Если застряли, то говорите об этом — даже с новичком. Сам факт объяснения
поможет вам разобраться в ситуации.
10.1.4. Почему вообще возникает
аварийный режим работы?
Существуют несколько причин возникновения проблемы.
Самые обидные для команд разработки аварии — это те, что вызваны ошибками
или иными техническими проблемами (например, сервер не выдерживает нагруз-
ку). Указанные ранее действия ориентированы как раз на описание того, что делать
в случае такой ошибки. Являются ли аварии, вызванные ошибками, самыми про-
блемными? Обычно нет. Да, аварии случаются, но обычно страдает не вся система,
а ее часть, или не все клиенты, а только некоторые. Хотя бывают и очень серьезные
ошибки, способные приводить к значительным финансовым и репутационным по-
терям. В этом случае обычно сразу говорят о плохом качестве.
Но не думайте, что аварийный режим— это всегда ошибка в программе. Очень
часто проблемы возникают по независящим от команды обстоятельствам. Так. сбои
в инфраструктуре тоже могут приводить к возникновению аварий. Именно на этот
случай нужен план восстановления.
Пример из жизни
30 марта 2025 года у Яндекса произошла авария связанная с отказом энергоснабже-
ния в одном из центров обработки денных (ЦОД). Это привело к остановке как части
сервисов самого Яндекса, так и сторонних приложений, использующих инфраструкту-
ру Яндекса
К сожалению, бывают случаи, когда к аварии приводит интеграция с какой-либо
системой.
Пример из жизни
В одном из проектов клиент поменял внешнюю систему которая формирует данные
для нашей системы. Ошибка в новой внешней системе привела к тому, чю данные в
нашу систему стали поступать в десятикратном размере То есть дублируясь по де-
сять раз Сервис не был рассчитан на такую нагрузку и остановился
Иные причины:
♦ кибератаки и инциденты безопасности — например, вирусы или DDoS-агака;
♦ ошибка в «ручных» действиях (человеческий фактор);
♦ недостаток ресурсов — например, места на диске;
♦ отсутствие мониторинга и алертинга, которые бы заранее говорили о потенци-
альных проблемах. Например, что место на диске заканчивается;
♦ слабое тестирование или отсутствие какого-либо вида тестирования — напри-
мер, нагрузочного.
Одно из самых очевидных, важных, но часто игнорируемых действий — это анализ
того, что явилось причиной ошибки. «Потушили пожар» — и забыли о проблеме.
Неважно, новичок вы или опытный сотрудник, следите за тем. чтобы после аварии
обсудили, запланировали и, главное, выполнили действия, направленные па то,
чтобы снизить и риск появления аварий, и последствия их появления.
10.2. Эскалация проблем: когда и к кому обращаться?
Эскалация необходима для тех случаев, когда проблема не может решиться на вашем
уровне. Не следует бояться эскалировать, но нс стоит этим и злоупотреблять. Кроме
того, ни к чему часто пугать сотрудников тем, что вы будете эскалировать.
Новичок сталкивается не с крупными проектными проблемами, а со своими ло-
кальными, которые могут показаться руководителю незначительными. Давайте
рассмотрим наиболее распространенные варианты проблем.
10.2.1. Нет доступа к системе (почта, трекер и т. п.)
Если вы не можете начать работу, потому что вам не выдали права, хотя должны
были это сделать ранее, то действовать можно так:
1. Самостоятельно узнать, как подается заявка на доступ, и подать ее.
2. Если на следующий рабочий день ничего не изменилось, то нужно:
• вежливо напомнить ответственным, если доступ так и нс открыт.
• эскалировать напрямую к своему руководителю или тимлиду. Формулировка;
«Я не могу приступить к задаче, потому что второй день жду доступ к систе-
ме. Это блокирует всю мою работу. Можешь помочь решить вопрос?»;
• если и это не помогает, то эскалируйте вышестоящему руководителю или —
альтернативный вариант — в HR-отдел.
10.2.2. Непонятные или противоречивые требования в задаче
Вы можете столкнуться с ситуацией, когда в задаче написано одно, аналитик гово-
рит другое, а в коде написано третье, и вы не понимаете, что именно делать.
Если в течение пары часов вам не удастся прояснить ситуацию (перечитать, спро-
сить у коллег, изучить код), то необходимо:
1 Собрать факты: выписать три варианта из задачи, слов аналитика и кода, сделать
скриншоты.
2. Обратиться к автору задачи и показать противоречие: «В задаче сказано одно, но в
модуле используется другая логика. Какой вариант верный для этой доработки?»
3. Если ответа нет или он не проясняет ситуацию — эскалировать к руководителю.
Формулировка: «В задаче [номер] есть противоречие в требованиях [суть]. Я
уточнил у [имя аналитика], но вопрос остался без однозначного решения. Я не
могу двигаться дальше, рискуя сделать не то. Нужно целевое решение».
10.2.3. Отсутствие обратной связи от смежного отдела
Если вам нужна помощь от другой команды, а вам нс отвечают, то нужно действо-
вать следующим образом:
1. Выполните повторное напоминание.
2 Подождите хотя бы один рабочий день ответа после повторного напоминания.
3. Если ответ так и не появится, то на следующий день напомните, упомянув срок.
«Привет, напоминаю о вопросе по [тема]. Мне нужно это понять сегодня, чтобы
не срывать график».
4. Если к концу дня ответа всё еше не будет, то эскалируйте к своему руководите-
лю. Формулировка «Меня блокирует вопрос по [тема]. Я обратился к [имя] [да-
та и время], напомнил, но ответа нет. Наша задача [номер] стоит. Попроси, по-
жалуйста, помочь получить ответ»
В целом в этом нет ничего страшного, никаких гневных писем и угроз.
Важные принципы для новичка при любой эскалации:
♦ Эскалируйте раньше, чем станет поздно. Лучше сообщить о потенциальном
срыве за три дня, чем молчать до дня дедлайна.
♦ Эскалация— это не жалоба, а отчет о проблеме и запрос на помощь. Вы не
ябедничаете на коллегу, а информируете руководителя о риске для проекта.
♦ Всегда предлагайте варианты решения. Если нужны люди со специальными
правами, то спросите, что вы можете и должны сделать, чтобы решить вопрос.
♦ Фиксируйте всё письменно (в чате, задаче, e-mail). То, что вы проговорили голо-
сом, может забыться. Написанный текст — это ваши же доказательства, что вы
не сидели сложа руки.
♦ После эскатации будьте готовы к действию Как только проблема решится, сра-
зу возвращайтесь к работе и обязательно сообщите, что блокер снят.
10.3. Сложные переговоры с заказчиками
и стейкхолдерами
Некоторые специалисты из IT никогда не сталкиваются напрямую с заказчиком.
Так, разработчики и тестировщики очень часто даже не знакомы с клиентами. Это в
целом нормально. С заказчиками гораздо чаще общаются аналит ики, ведь их задача
нередко сводится к тому, чтобы согласовать работу.
Однако, в отличие от заказчиков, с которыми действительно встречаются не все
сотрудники, со стейкхолдерами встречи происходить могут. Чем более продуктовая
у вас команда, тем чаще вы встречаетесь со стейкхолдерами — теми, у кого есть
интерес к разрабатываемому продукту Это, например, могут быть основатели ком-
пании или те, кто выделяет бюджет на продукт, — они часто хотят понимать, куда
движется продукт и какие у него приоритетные задачи.
Рано или поздно каждый новичок сталкивается со стейкхолдерами, имеющими
свою точку зрения, в ряде случаев не совпадающую с его Как следствие, может
возникнуть некоторая напряженность, способная перерасти в конфликт, вплоть до
того, что продукт может быть закрыт, или у нею сменится команда. Конечно, это
совсем крайний случай, но исключать такое нельзя.
Рассмотрим типовые ситуации, которые чаще всего встречаются.
10.3.1 Желание заказчика получить решение
в нереалистичные сроки
Часто в разработке иронично шутят: «Ну и, конечно, эта задача нужна вчера?»,
имея в виду, что каждая задача обязательно н>жна как можно скорее.
♦ Во-первых, не надо сразу соглашаться с запредельными сроками — следует
уточнить, почему называются именно такие сроки и с чем они связаны. Очень
часто это просто ни на чем не основанное желание. Вам также могут сказать, что
об ускорении задачи попросило начальство.
♦ Во вторых, если эта задача требует взаимодействия со сторонней командой,
уточните ее готовность. Пусть, например, планируется интеграция с мессендже-
ром МАХ. Готова ли она в нужном объеме на той стороне? Если не готова или
находится в работе, то объясните, что не можете взять на себя какие-либо обяза-
тельства. т. к. решение вопроса зависит не только от вас.
♦ В-трегьих, если задача действительно срочная, то можно предложить заказчику
заменить ею другую задачу из бэклога, если таковая есть.
♦ В четвертых, вы можете предложить уменьшить объем требований по задаче.
Например, сделать возможной работу только по основным сценариям
Если вы новичок, то вряд ли вам доверят вести ключевые переговоры, но если вас
попросят ответить на какие-либо вопросы (например, дать оценку задаче), то чест-
но говорите то, что можете сказать. Если вы не знаете ответа и вам требуется про
консультироваться с командой или наставником, то так и скажите. Пусть лучше вы
заберете с собой домашнюю работу, чем подпишетесь под сроками.
Совет новичку
Если не можете дать оценку или срок, не давайте. Учтите, что заказчику, особенно то-
му. кю плати г деньги, абсолютна не интересно, что вы работаете в компании второй
день. Если вы присутствуете на встрече, значит, являетесь полноценным участником,
с которого спрос такой же как и с других.
10.3.2. Непонимание сложности или стоимости задачи
Это то, с чем вы будете сталкиваться очень часто. Даже ваш руководитель или его
начальник могут задать простой вопрос: «Почему такая большая оценка, это всею
лишь...»
Тут есть несколько вариантов ситуации:
♦ первый — сотрудники, оценивающие задачу, закладывают риски, поэтому оцен-
ка значительно вырастает;
♦ второй — оценка такая, потому что задача сложная лично для вас, и вы, чтобы
нс подвести команду, даете ее с запасом;
♦ третий — оценка такая, потому что задача действительно сложная.
В первом случае, когда закладываются риски, вы должны явно об этом сказать. На-
пример. если не готовы APT или тестовый контур, которые нужны вам для работы,
то это надо четко отметить. Если у вас есть примеры, поясняющие, почему ранее
задачи из-за аналогичных проблем значительно увеличивались, то непременно их
приведите. Вам наверняка будут обещать, что в этот раз всё будет иначе, но вы
спокойно и уверенно стойте на своем.
Во втором случае, когда вы не знакомы с рабочей областью, необходимо действо-
вать аналогично. Даже если вы работаете давно, а вас просят доработать конкрет-
ный модуль, в котором вы не разбираетесь, то этим и аргументируйте. Если с вами
нс согласятся, вы можете предложить провести исследование, способное дать точ-
ную оценку задачи. Кроме того, можно попросить, чтобы такую оценку дал другой
коллега, но только если работать над задачей будет он сам. Возьмите за правило-
если вам говорят, что какой-то сотрудник оценил задачу в два раза меньше, то
пусть он ее и делаег. Если вы уже на встрече, хоть и новичок, то значит — без вас
никуда. Но учтите при этом, что если взяли обязательства, то их придется соблюдать.
В третьем случае, когда оценка дана, по вашему' мнению, объективно, необходимо
подробно объяснить, почему она такая. Если вы общаетесь с заказчиком, который
не разбирается в том, что вы делаете (например, вы программист), то попробуйте
объяснить ему ситуацию на языке аналогий или примеров, чтобы попытаться на-
чать говорить на одном языке: «Чтобы начать жить в доме, недостаточно просто
возвести фундамент, стены и крышу, надо провести коммуникации, выполнить от-
делку, поставить и собрать мебель». Аналогии не всегда бывают уместны, но в не-
которых случаях, и такой способ подходит.
В ряде случаев заказчика интересует не сложность, а стоимость. Если компания, в
которой вы работаете, готова софинансировагь работы. — например, потому что
это полезно для продукта, то попробуйте узнать об этом до встречи с заказчиком.
Такое софинансировзние даст заказчику возможность оплатить не всю работу, а
тишь ее согласованную часть. Однако при этом важно не пытаться всегда быть хо-
рошим для заказчика, а отстаивать свои интересы.
10.3,3. Изменение требований к задаче
Как уже отмечалось ранее, особенности оценок в России таковы, что предвари-
тельная оценка становится часто финальной. И с требованиями ситуация аналогич-
ная. В частности, в процессе реализации задачи требования могут измениться. Бы-
вает, незначительно, а бывает, что серьезно. Основная проблема здесь в том, что
часть работы уже могла быть выполнена, то есть время потрачено, а задачу надо
переделывать.
Если у вас есть бюджет на риски, а иногда в крупных задачах так и бывает, то мож-
но попробовать использовать его. То есть согласиться па новые требования, но под
условия.
Если бюджета на риски нет, а переделки предполагаются значительные, и вы оза-
бочены тем, что бюджета не хватит, или что он весь уйдет на переделки и ничего не
останется на другие проекты, то предложите заказчику совместно пересмотреть
требования так. чтобы вписаться в остаток бюджета.
Ваша задача — не слепо, без спора, соглашаться на новые требования, а искать
компромисс в решении. Вы должны максимально открыть уже сделанные затраты и
предложить доступные варианты, показав, сколько стоит каждая задача
В некоторых случаях партнерские отношения с заказчиком позволяют перенести
затраты в другие его проекты. Конечно, для компании это не всегда удобно, но всё
же лучше, чем сделать бесполезную задачу.
Самым неправильным будет продолжать делать задачу согласно исходным требо-
ваниям. если они уже стали неактуальными, и об этом вам явно сказано. Иногда
лучшим решением будет вообще остановить задачу на той стадии, которая есть, и
попросить компенсировать уже понесенные затраты
10.3.4. Базовые принципы любых переговоров
♦ Говорите на языке ценности, а не технологий. Заказчику не важно, сколько
строк кода вы написали или какие библиотеки используете. Ему важно услы-
шать «Эта доработка сократит время обработки заявки с 10 минут до 2» или
«Это исправление уменьшит количество жалоб на 30%».
♦ Подкрепляйте свои аргументы данными: цифрами, трафиками, отчетами Не
просто скажите: «Это сложно», а «Аналогичная интеграция в предыдущем про-
екте заняла 40 человеко-дней из-за неготовности API партнера».
♦ Не переходите на личности. Не надо говорить что-то наподобие «вы неправиль-
но ставите задачу» — корректно приведите информацию о ситуации: «В теку-
щей формулировке есть несколько допущений, которые могут привести к про-
блемам».
♦ Слушайте и повторяйте слова заказчика так, как вы их поняли. «Правильно ли я
понял, что ваша основная боль — это...?» Это показывает, что вы его слышите и
правильно понимаете.
♦ Предлагайте альтернативные варианты. Почти никогда не говорите просто
«нет». Скажите: «Сделать именно так, как вы просите, к пятнице — технически
невозможно. Но у нас есть друтой вариант, который поможет в решении про-
блемы».
Чего нельзя делать новичку:
♦ давать обещания или окончательные оценки без согласования с тимлидом, на-
ставником или руководителем;
♦ спорить и рут аться с заказчиком, переходить на эмоции, даже если заказчик не
прав;
♦ молчать, если вас прямо спрашивают, а вы не знаете ответа. Лучше сказать. «Я
не могу дать ответ, мне надо уточнить ею у старшего коллеги» или «Вернусь с
ответом не позднее следующего рабочего дня после встречи».
Сложные переговоры — это управление ожиданиями через открытость и предло-
жение выбора Вы должны не просто стоять на своем, даже если вы правы, а по-
мочь заказчику принять лучшее для проекта решение.
-ЧАСТЫУ-
УЧАСТИЕ СПЕЦИАЛИСТОВ
НЕТЕХНИЧЕСКИХ РОЛЕЙ В РАЗРАБОТКЕ
ПРОГРАММНЫХ ПРОДУКТОВ
-Глава 11 -
Работа с требованиями
Требования в разработке — это основа для всего Идея заказчика не может быть
реализована до того момента, пока она не будет зафиксирована в виде требований.
Разработчик реализует задачу, а тестировщик проверяет ее согласно гребованиям, и
приемка работы также выполняется на соответствие гребованиям. Мы понимаем,
ошибка это или фича, на основании требований. Плохо проработанные требова-
ния — это, в конце концов, недовольный заказчик, которому говорят, что «этого не
было в требованиях».
Из этой главы вы узнаете про то, как работать с требованиями, какие они бывают и
как их писать, как правильно получать их и использовать в дальнейшей работе.
11.1. Методы сбора требований от пользователей
Существует множество методик, помогающих понять, что на самом деле нужно
заказчику.
В зависимости от того, создается новый продукт или происходит доработка (улуч-
шение) текущего, предусмотрены несколько вариантов работы.
Для новых продуктов или новых крупных модулей можно использовать подходы
Customer Development (CustDev) или Jobs То Be Done (JTBD). Смысл этих практик
сводится к тому, чтобы не создать то, что никому не нужно.
11.1.1. CustDev
Цель CustDev — убедиться в том. что создается продукт, который решает реальные
проблемы или достигает нужных бизнесу целей Продукт должен выполнять нуж-
ные функции. И тут очень тонка грань между нужной функцией и функцией, кото-
рая только кажется нужной.
Примеры ненужных функций из жизни
• Возможно, некоторые пс мнят, что в одной из давних версий Microsoft Word появил-
ся помошник-скрепка. который по задумке служил для того, чтобы помочь пользо-
вателю разобраться в интерфейсе нового продукт Этакая вау-фича Но со вре-
менем от этого помощника отказались— пользователям был нужен интуитивный
интерфейс, а не мешающий помощник.
• Другой пример — очки Google Glass (умные очки), которые были призваны стать
следующей ступенью развития за смартфонами. Продукт сказался слишком доро-
гим (1500 долларов), недолговечным и технически ограниченным. Полагаю, это бы
со временем решили. Но возникли проблемы с конфиденциальностью, когда люди
не понимали, работает камера очков или нет, — многие чувствовали себя неком-
фортно рядом с пользователями в таких очках. Да и полностью отказаться от
смартфонов и перейти на очки оказалось невозможно, потому что они не могли
предложить все те функции, которыми обладают смартфоны.
Как проводится CustDev?
Не следует делать выводы на основании цифр, догадок или георий. Нужно гово-
рить с клиентом.
Совет
Если вы заказчик, и с вами не хотят поговорить. — это сигнал о том, что что-то не так.
Можно задать вопрос, почему никто не выходит на контакт. Если же вы, нэпрогив. участ-
ник команды, который собирает требования, то обращайтесь к тому, кто разбирается.
Не надо убеждать клиента в чем-то — лучше выслушать его и понять. 80°/о времени
нужно слушать Если вы клиент, и вас о чем-либо спрашивают, постарайтесь отве-
тить как можно честнее, не уходя в размышления о том, что было бы неплохо, если
бы...
Вопросы должны быть открытыми (то есть такими, на которые нельзя ответить
«Да» или «Нет»),
Нужно узнать, есть ли реальная боль, а не выдуманная «хотелка». Если есть какая-
то проблема, то как клиенты решают ее сейчас?
Задавайте вопросы о проблеме, а не о решении. Например: «Что вас больше всего
раздражает в этом [конкретном] процессе?» Если мы говорим о приложении, кото-
рое помогает в ремонте, то вместо вопроса «Что должно быть в этом сервисе по
планированию ремонтов9» нужно задавать примерно такие вопросы: «Как вы пла-
нировали свой ремонт0 Сколько времени ушло на поиск прораба и строительной
компании? С какими сложностями вы столкнулись при составлении сметы?»
Российские реалии
В России заказчики и пользователи часто неохотно делятся подробностями. Дове-
рие нужно заслужить. Если вы заказчик, то попробуйте довериться тем, кто с вами
говорит, — возможно, это просто реализация подхода CustDev.
При создании продуктов для крупного бизнеса или для госзаказчиков нужно учи-
тывать следующую особенность: пользователь продукта и лицо, принимающее ре-
шение (Л ПР), — это очень часто разные люди с различными потребностями. Сле-
дует четко понимать, что лицо, которое согласует требования, может оказаться не
тем, кто будет пользоваться продуктом. Например, пользователь автомата по про-
даже жетонов в метро — это обычный пассажир, а заказчик системы — это метро-
политен.
Совет новичку — техническому специалисту
Если вас отправляют на интервью с пользователем веша главная роль — наблюда-
тель и технический специалист (может быть, даже «технический переводчик»). Слу-
шайте, что говорит пользователь, и мысленно переводите это в возможные сценарии.
Замечайте фразы вроде «а вот здесь мы обычно обходим это вот так» — это прямое
указание на проблему в текущем процессе Ваша задача — не вести интервью, а за-
писывать технические детали и задавать уточняющие вопросы пс ним: «А как часто
вы сталкиваетесь с этой ошибкой?», «Что вы делаете, когда система "висит"?».
11.1.2. Jobs to Be Done (JTSD)
Здесь лучше сразу начать с примера.
Пример из жизни
У меня есть автомобиль, но я езжу на работу на метро. Почему? Потому что на работу
и с работы нужно ехать по пробкам, да еще искать место для парковки. В итоге про-
ехать пару остановок на метро мне кажется лучшей идеей, чем поехать на машине Но
при этом я регулярно использую автомобиль, например, чтобы съездить на дачу, за
город или в новое место, купить продукты (я люблю их сам выбирать) или отвезти се-
мью в гости
• Метро лучше выполняет работу по доставке меня на работу
• Машина лучше выполняет работу по доставке меня за город.
То есть я использую то, что выполняет работу лучше в конкретной ситуации
Подход JTBD говорит о том, что сам по себе продукт не нужен, а нужен результат
того, что делает продукт.
Методика JTBD позволяет смотреть на то, «что клиент хочет получить в результате
выполнения работы». Покупатели пылесоса не хотят устройство с кучей разных
функций, они хотят, чтобы не было пыли и грязи.
Формулировка JTBD выглядит так.
Когда [СИТУАЦИЯ], я хочу [МОТИВАЦИЯ], чтобы [ЖЕЛАЕМЫЙ РЕЗУЛЬТАТ]
Продолжение предыдущего примера из жизни
Когда я еду на работу в будний день утром, то хочу выбрать самый быстрый и пред-
сказуемый способ передвижения, чтобы не терять время в пробках и не тратиться на
парковку.
Зачем использовать такой подход?
♦ Появляется понимание мотивации клиентов.
♦ Создаются решения, которые решают проблемы, а не просто вау-фичи.
♦ Улучшается маркетинг, т. к. люди начинают понимать, «зачем им этот продукт»,
а не «что это».
♦ Находятся новые продуктовые возможности.
Как проводится JTSD?
Похоже на CustDev, но с фокусом на то, почему клиент начал искать решение.
Нужно искать клиентов, коюрые уже купили продукт и начали им пользоваться.
Цель в том, чтобы проследить их путь к решению, включая выявление триггера. —
то есть того момента, когда они поняли. что им нужен продукт или решение.
Вог примерные вопросы.
♦ Что произошло в тот момент, когда вы решили, что нужен продукт?
♦ Что вы делали или пробовали, чтобы решить проблему до этого?
♦ Что именно привело к выбору именно этого решения и продукта ?
♦ Выбранное решение оправдало ожидания? Помогло?
♦ Если бы продукта не было, что бы вы делали?
В России основанием для покупки продукта часто является нс поиск эффективно-
сти, а реакция на внешнее давление — принятый новый закон (например. 152-ФЗ о
персональных данных), требование крупного партнера или необходимость отчи-
таться перед проверяющими органами.
Совет новичку
В рамках JTBD ваша задача — помочь выявить узкие места в текущих процессах, свя-
занных с выполнением рабшы. Если пользователь говорит: «Мы сейчас это делаем
через Excel-таблицы, и это занимает три дня», спросите: «А чго отнимает больше все-
го времени? Свод данных из разных мест или проверка на ошибки?» Так вы. ьозмож-
но, найдете точку для ценного улучшения
11.1.3. Работа с существующими продуктами
Если нет необходимости создавать продукт с нуля, то я рекомендую использовать
следующие методы.
♦ Интервью с заказчиками и пользователями (напомню, что в В2Б пользователи и
заказчики — это разные люди). Интервью позволяет понять процесс изнутри, а
не так, как видят его разработчики.
♦ Наблюдение за процессом, который нужно изменить. Это позволяет выявить
разницу между тем. о чем рассказали, и тем, чго на самом деле делают.
♦ Анализ документации и метрик. Возможно, есть метрики или какие-то формаль-
ные правила, которые необходимо знать и следовать им.
Учтите, что документация может очень быстро устареть. Особенно это касается
внутренних документов в крупных компаниях. Всегда проверяйте их актуальность.
Совет новичку
При анализе метрик не смотрите просто на цифры Ищите аномалии и узкие месга.
Резкий провал на каком-то шаге воронки (например, много пользователей добавляют
товар в корзину, нс мало переходят к оплате) — это прямое указание на проблему, ко-
торую нужно исследовать.
11.2. Виды требований
Существует несколько видов требований, которые необходимо знать, — как тем,
кто их пишет, так и тем, кто согласует. Понимание того, какие виды требований в
принципе существуют, нужно для того, чтобы неожиданно не столкнуться с про-
блемами Поскольку эта книга все-таки для новичков, то акцент я сделаю на их со-
держании
11.2.1. Требования по содержанию
По содержанию выделяют следующие виды требований:
♦ Функциональные требования (ФТ)— это основные требования к системе, как
система реагирует на действия пользователя или другой системы. Например,
вход в банковское приложение с использованием пин-кода— это типичное
функциональное требование. ФТ обычно не вызывают вопросов
♦ Нефункциональные требования (НФТ) — это тоже основные требования к про-
дукту, но они напрямую не связаны с выполнением функций продукта (именно
поэтому они и называются нефункциональными); с какой скоростью приложе-
ние работает (производительность), как обеспечивается безопасность продукта,
насколько продукт стабильно работает в случае сбоев (надежность) и так далее
Вот примеры НФТ:
• время реакции на действие пользователя не должно превышать 100 мс;
• вопрос о том, как продукт должен поставляться и обновляться: централизо-
ванно через сервер или через отдельный архив и ручную установку.
К сожалению, иногда про нефункциональные требования вспоминают только в
тот момент, когда возникают какие-либо проблемы. Например, продукт работает
как задумано, но очень медленно — пользователь нажимает кнопку и ожидает
несколько минут. В этом случае претензии могут быть взаимны: заказчик гово-
рит о том, что продуктом невозможно пользоваться, а команда разработки —
что требование о скорости работы не было указано. В приложении 2 к книге
приведены основные виды нефункциональных гребований.
Совет новичку
В России следует уделять особое внимание нормативным требованиям и требовани-
ям к безопасности Эти вопросы обычно регулируются федеральными законами и
обязательны для соблюдения
Иногда сложно однозначно сказать, является требование функциональным или нет.
Например, безопасность продукта часто выделяется вообще в отдельный блок тре-
бований либо ее относят к функциональным или, напротив, к нефункциональным,
но посмотрите на приведенный ранее пример с банковским приложением— это
явно функциональное требование. А для продуктов, связанных с информационной
безопасностью, все требования по безопасности будут функциональными.
Важно другое— все требования нужно фиксировать! Следует своевременно выде-
лить и описать требования, поскольку они могут значительно повлиять на архитек-
туру ироду к г э.
Вот пример требований для мобильного банковского приложения:
♦ При вводе цифрового кода не должны отображаться вводимые символы. Вместо
них отображаются символы * (звездочка).
♦ Сохраненный код не должен храниться в открытом виде в хранилище.
♦ При наличии доступа к хранилищу с кодами не должно быть возможности рас-
шифровать код— следует использовать механизм хеширования с защитой от
перебора по словарю.
Помимо требований, которые относятся к содержанию, также полезно знать и про
другие виды требований.
11.2.2. Требования по источнику
По источнику выделяют следующие виды требований:
♦ Требования заказчиков и стейкхолдеров — это требования не только пользова-
телей продукта, но и поддержки или юристов.
♦ Ограничения— это заданные условия, в которых может работать продукт. По
своей сути их часто можно отнести к нефункциональным требованиям. Напри-
мер, один из видов ограничений — это ограничение бюджета на ежемесячные
затраты. Ограничения также бывают чисто технологическими — например, с
требованием поддержки определенных операционных систем.
♦ Переходные требования — это требования к продукту, которые должны соблю-
даться при переходе. Например, при миграции с одного продукта на другой.
11.2.3. Требования по уровню иерархии
По уровню иерархии выделяют следующие виды требований:
♦ Бизнес-требования — высокоуровневые требования к продукту.
♦ Требования пользователя— описывают то. что пользователи могут делать в
сисгеме.
♦ Системные требования — память, диск, сеть и другие требования к системе.
Совет для новичка
Используйте шаблон требований Не важно, в рели заказчика или в роли технического
специалиста вы выступаете, — нужно проследить, чтобы а требованиях явно были
указаны следующие пункты бизнес-цель (зачем реализуется требуемая функцио-
нальность), потребность пользователя (кто делает и что делает), функциональные
требования (конкретные функции), ключевые НФТ (например, безопасность и соответ
ствие требований закону), ограничения (ограничения в реализуемой функции).
11.3. Создание пользовательских историй и сценариев
Когда информация собрана, ее необходимо описать в понятых для команды разра-
ботки терминах. Поэтому теперь мы перейдем к формату требований. В современ-
ном 1Т требования описываются в формате пользовательских историй (User Stories)
и сценариев использования (Use Cases). Однако также достаточно распространены
критерии приемки (Acceptance Criteria) и отраничения (Constraints). Одновременно
могут сочетаться все варианты форматов.
11.3.1. Формат требований
Наиболее универсальный инструмент для описания требований— пользователь-
ская история (User Story. US). Ее стандартный формат выглядит так:
Я, как [ПОЛЬЗОВАТЕЛЬ], хочу [ДЕЙСТВИЕ], чтобы [ЗАКРЫТАЯ ПОТРЕБНОСТЬ].
Вот пример пользовательской истории для мобильного банковского приложения:
Я, как владелец мобильного телефона, хочу установить PIN-код для входа в мо-
бильное приложение, чтобы никто не мог воспользоваться банковскими услуга-
ми без моего ведома
Несмотря на го. что это достаточно простой формат, даже при его использовании
иногда забывают (опускают) последнюю часть, которая как раз и раскрывает суть
требования.
Совет по формату
Не боитесь уточнять роль пользователя В российских роалиях часто есть специфические
роли, которые важно выделить, поскольку такое выделение дает лучшее понимание.
Примеры из жизни
• Пример из Госуслуг вместо просто «пользователь» уточните: «Я. как физическое
лицо, зарегистрированное на портале Госуслуги, хочу подписать заявление уси-
ленной квалифицированной электронной подписью (КЭП), чтобы отправить его в
ведомство без личного визита».
• Пример из В2Б «Я, как бухгалтер в организации, являющейся агентом НДС, хочу
сформировать и выгрузить журнал учета счетов-фактур в формате, утвержденном
ФНС. чтобы гередать его а чало!овую через кабинет налоюпла1елыцика».
Узнав, чего хочет заказчик, важно описать решение так, чтобы оно было еще и реа-
лизуемо и не вызвало негодования в вопросах о сроках и цене. Можно придумать
какое угодно решение, но его нельзя будет реализовать, если оно технически не-
реализуемо или реализация его окажется чрезмерно дорогой. Достаточно часто в
разработке идут на компромиссы в требованиях именно из-за дороговизны реше-
ния, а не по причине его нереализуемое™.
Не думайте, что дорогой бывает только сама разработка (время на написание ко-
да). Большая часть затрат приходится на инфраструктуру, тестирование и сопро-
вождение. Поэтому решения нужно согласовать с разработчиками и подтвердить
у заказчика
Для пользовательской истории разработана специальная INVEST-модель. которая
позволяет создавать качественные пользовательские истории Подробное описание
lNVEST-модели приведено в приложении 2 и будет полезно в первую очередь тем
специалистам, которые работают с требованиями.
Продолжая работу с пользовательскими историями, аналитик формулирует резуль-
тат своей работ ы в виде:
♦ критериев приемки (что считается выполнением требования);
♦ ограничений (технических, бизнесовых, юридических и др.);
♦ сценариев использования (use cases), описывающих, как пользователь взаимо-
действует с системой
Критерии приемки и ограничения
♦ Критерии приемки — это список условий, которые должны быть выполнены для
того, чтобы принять задачу. Фактически это требования, но сформулированные
в формате критериев Вот пример такого критерия: «Длина пароля должна быть
не менее 12 символов».
♦ Ограничения — это условия, только при соблюдении которых система работает.
Ограничения нужны, чтобы пользователи не пытались использовать систему
так, как не задумывалось Например: «Функция продукта доступна только в Ян-
декс Браузере».
Критерии приемки и ограничения (а также сценарии использования) важны для
всех: и для заказчика, и для команды разработки. Если вы заказчик, требуйте пока-
зать вам критерии и ограничения. Просите явно включить в них важные для вас
пункты. Критерии приемки и отраничения — это, фактически, суть договора. Все
ошибки и проблемы в работе продукта будут возникать из-за того, указывались ли
те или иные пункты в критериях и ограничениях.
Продолжим рассмотрение примера с мобильным банковским приложением на ос-
нове пользовательской истории. Учтите, что это лишь демонстрация подхода —
реальный перечень критериев и ограничений обычно гораздо шире.
Критерии приемки для мобильного банковского приложения
♦ Вход в личный кабинет мобильного приложения возможен только после успеш-
ной проверки.
♦ В качестве проверки может использоваться PIN-код или биометрическая аутен-
тификация
♦ Пользователь может отключить вход по биометрии.
♦ Если работа с приложением не велась в течение 10 минут, при повторном входе
требуется повторная проверка.
♦ Пароль должен изменяться не реже одного раза в 180 дней.
♦ После трех неудачных попыток входа пользователь должен подождать 30 минут
до следующей попытки.
Ограничения
♦ SMS-сообщения не защищаются приложением, т. к. являются частью функцио-
нальности телефона и не контролируются самим приложением.
♦ Вход по биоме 1рии возможен только при условии, что она настроена на устрой-
стве пользователя.
♦ На одром телефоне одновременно может работать только одно мобильное при-
ложение банка для одного пользователя.
♦ Длина PIN-кода должна составлять от 4 до 8 символов, причем допускаются
только цифры.
* ♦ ♦
В России нужно всегда учитывать требования государственных органов (законы,
подзаконные акты, указания, приказы и т. п.), поэтому обязательно добавляйте кри-
терии, ссылающиеся на них, например.
♦ Пароль должен соответствовать требованиям ФСТЭК для систем с высшим
классом защиты’
• минимальная длина нс менее 12 символов;
• сложность: обязательное использование прописных и строчных букв, цифр и
спецсимволов;
• срок жизни регулярная смена пароля (каждые 30 дней), запрет повторения
старых паролей.
У заказчиков часто бывают относительные старьте системы со значительными осо-
бенностями или специфичная инфраструктура. Такие особенности нужно явно ука-
зывать во избежание каких-либо проблем в будущем. Это важно для обеих сторон
(заказчик и команда). Вот несколько примеров:
♦ Интеграция с «1С» должна работать через выгрузку в формате XML, совмести-
мом с конфигурацией «Бухгалтерия предприятия 3.0», т. к. обновление конфи-
гурации у клиента невозможно в ближайший год.
♦ Должна присутствовать поддержка браузера «Яндекс Браузер» с плагином
«КриптоПро ЭЦП», так как на веб-сайтах требуется электронная подпись.
Когда критерии приемки и ограничения сформулированы, полезно вернуться к ис-
ходной пользовательской истории и проверить, соответствует ли она новым дета-
лям. Иногда после уточнений требования стоит скорректировать, чтобы сохранить
их точность и логическую связность.
Сценарии использования
Критерии приемки и ограничения дают понимание того, какие функции должны
быть реализованы, но нс отвечают на вопрос, как пользователь будет с ними взаи-
модействовать.
Для описания конкретного поведения применяют сценарии использования. Они по-
казывают, как должны работать функции в реальных ситуациях.
Особенности сценариев использования
♦ Каждый сценарий имеет номер и название. В нем прописывается исходное со-
стояние продукта, действия пользователя (или реакции продукта) и, само собой,
ожидаемый результат.
♦ Выделяют основные, альтернативные и отрицательные сценарии:
• основные сценарии (может быть один) — описывают основной ожидаемый
путь. Ради основных сценариев и реализуется задача. 11м, например, преду-
сматривается успешный вход пользователя в мобильное приложение;
• альтернативные сценарии— это тоже варианты развития, которые могут
произойти, но в каких-то иных (альтернативных) ситуациях. Например, аль-
тернативная возможность входа для мобильного приложения — не по пин-
коду, а по биометрии или с подтверждающим СМС-сообщением;
• отрицательные сценарии — дополняют основные и альтернативные для тех
случаев, когда что-то идет не так. Описывают например, как будет вести се-
бя система, если нет связи или неверно введен пароль.
Иногда в аналитике не выделяют явно отрицательные и альтернативные сцена-
рии. Важно не выделение тех или других, а описание максимального количества
возможных ситуаций.
♦ Сценариев должно быть достаточно, чтобы у разработки не возникало ьопросов.
Но и перегибать не надо, добавляя очень похожие или одинаковые сценарии.
♦ Сценарии использования не должны противоречить критериям приемки.
Воз примеры сценариев использования для мобильного банковского приложения
Сценарий 1. Основной успешный сценарий
♦ Исходное состояние: приложение установлено, телефон разблокирован, биомет-
рия настроена, вход по коду активирован, вход по биометрии запрещен
♦ Шаги.
I. Пользователь открывает мобильное приложение.
2. Появляется экран ввода пароля. Кнопка входа по биометрии недоступна.
3. Пользователь вводит корректный код и нажимает «Ввод».
♦ Ожидаемый результат: происходит переход на основной экран приложения.
Сценарий 2. Неверно введенный код
♦ Исходное состояние: то же, что и в Сценарии 1.
♦ Шаги;
1. Пользователь открывает мобильное приложение
2 Появляется экран ввода пароля. Кнопка входа по биометрии недоступна.
3. Пользователь вводит некорректный код и нажимает «Ввод».
4. Появляется сообщение «Некорректный код, у вас осталось 2 попытки».
♦ После грех неудачных попыток приложение блокируется на 30 минут.
* * ♦
Во многих странах есть свои уникальные решения. Например, в России.
♦ Для сервиса Госуслуг: «Пользователь может при попытке входа в Госуслуги ис-
пользовать не только СМС-проверку, но и возможность подтверждения через
мессенджер МАХ».
♦ Для E-commerce: «При оплате через СБП (система быстрых платежей) и возвра-
те товара деньги должны быть зачислены на тот же счет, с которого было произ-
ведено списание».
Чем больше сценариев и чем полнее они, тем лучше. Но не стоит выдумывать похожие
сценарии только ради количества — должна различаться именно суть сценариев.
Совет всем
Сценарии использования, критерии приемки и ограничения нужн.> внимательно читать
и согласовывать всем Проблем будет меньше. Если вы заказчик не надейтесь на то,
чю команда до чего-то догадается В конце концов, платить за то, что вы что-то забы-
ли, придется, скорее всего, вам
Изменение и дополнение сценариев использования
Достаточно частая ситуация — внесение изменений или дополнений в уже сущест-
вующие сценарии использования. В разработке по Agile это считается нормой.
Также часто встречается ситуация, когда часть сценариев уже реализована, а
часть — нет.
Существуют два подхода к ведению изменений:
1. Создавать отдельную страницу или версию для каждого нового или измененно-
го сценария.
2. Вести одну страницу, где для каждого измененного требования указывается но-
мер задачи из трскинговой системы или системы управления проектами.
Наиболее правильным и удобным вариантом является использование специализи-
рованной системы управления требованиями (СУТ). Эт о может быть:
♦ отдельное приложение для управления требованиями;
♦ или часть ALM-системы (Application Lifecycle Management), которая управляет
полным жизненным циклом приложений.
Если в вашей компании есть СУТ — вам повезло Если используется ALM-систе-
ма — повезло вдвойне.
К сожалению, многие компании нс используют специализированные системы.
Чаще всего требования ведут в wiki-подобных системах или даже в электронных
таблицах.
Если специальных систем нет, необходимо продумать правила работы:
♦ при использовании Confluence (или другого wiki-подобного редактора) можно
подключить плагины для работы с требованиями.
♦ если таких плагинов нет, можно использовать специальный шаблон, позволяю-
щий отслеживать историю изменений.
Список советов для новичков
♦ В российских компаниях часто используют Confluence + Jira (или их российские
аналоги). Настройте связь между страницей с требованием и задачей в трекере.
Используйте теги и статусы (например, [Согласовано]. [В разработке], [Требует
уточнения у заказчика]).
♦ Ведите одну страницу для всех требований по одному бизнес-сценарию (напри-
мер, входа в мобильное банковское приложение). Там должны быть реализован-
ные, coiнасованные и несохнасованные сценарии. Отмечайте в них задачи из тре-
кинге вой системы, в рамках которых производились или производятся доработки.
Иначе появляется риск, что аналитики разработчики или тестировщики найдут
несколько вариантов требований и не будут понимать, какие из них актуальны,
или будут думать, что в продукте ошибка.
♦ В российских реатиях часто требуется письменное согласование требований с
заказчиком. Даже если вы работаете по Agile, фиксируйте ключевые решения по
почте или в корпоративном мессенджере и прикрепляйте ссылку к задаче. Это
защитит вас от возможных проблем с несогласованными требованиями.
♦ Если продукт имеет локальную версию (для установки на серверы клиента) и об-
лачную. ведите требования отдельно для каждой ветки. То, что в облаке уже в раз-
работке, в локальной версии у клиента может быть только в планах на обновление.
Важное замечание!
В одностороннем порядке изменить требсвания нельзя, даже если команда говорит <
том, что то, как в них написано, сделать невозможно. У вас просто не примут pa6oiy, и
переделка будет выполняться за счет вашей компании, а не за счет заказчика
11.3.2. Макеты
Если в задаче предполагается добавление визуальных экранов пли их изменение,
необходимо приложить соответствующие макеты, показывающие, как должно вы-
глядеть итоговое решение.
Для нашего примера с мобильным приложением, очевидно, потребуются макеты
экрана ввода кода и экрана с сообщением об ошибке. Варианты таких макетов
представлены на рис. 11.1.
Без макетов разработчик реализует интерфейс «как понял» или «как видит», что
почти всегда приводит к расхождениям с ожиданиями. Поэтому разработка про-
дукта без утвержденных макетов недопустима.
Введите код
Неверный ПИН-код!
Осталось 2 попытки
1 2 3
4 5 6
7 8 9
0^
1 2 3
4 5 6
7 8 9
0«—
Рис. 11.1. Пример макета экран ввода кода (слева)
и экран с сообщением об ошибке (справа)
Для разработчика макет — это не просто картинка. Он должен быть собран из го-
товых компонентов, используемых дизайнером. Разработчик применяет те же ком-
поненты, но уже в коде. Таким образом, визуально результат совпадает, а каждый
специалист работает в своей среде.
В продуктовой разработке обязательно использование дизайн-системы. Она вклю-
чает в себя:
♦ библиотеку 01-компонентов;
♦ библиотеку кода:
♦ правила и принципы их применения.
Дизайн-система обеспечивает единый внешний вид для всех интерфейсов продук-
та. Помимо этого, за счет использования типовых компонентов ускоряется разра-
ботка. И также уменьшается риск несоотвегсгвия реализации макету.
В России могут быть свои специфичные требования даже к макетам. Например:
♦ дизайн-системы: помимо глобальных (Material, Apple UI), в России активно раз-
виваются локальные дизайн-системы. Например, методические рекомендации
по проектированию интерфейсов систем управления для государственных сер-
висов, дизайн-системы крупных банков или продуктовых компаний. Если ваш
продукт интегрируется с их экосистемой — это может бьпь строгим требованием;
♦ контент и локализация' макеты должны быть выполнены на русском языке. При
этом всегда проверяйте, как интерфейс выглядит с полными названиями, учиты-
вая, что, например, текст на кнопке «Submil» короче, чем на кнопке «Подтвер-
дить»;
♦ юридические требования к UI: на некоторых формах (например, оферты, плате-
жей) шрифт, размер кнопок и расположение юридических текстов могут регла-
ментироваться. Это тоже часть ограничений.
Когда требования и макеты согласованы, команды часто уходят в «свободное пла-
вание» и не возвращаются к ним до момента, когда задача готова.
11.4. Участие в приемке готовых функций
Закончив свою работу над продуктом, команда разработки пригласит всех заинте-
ресованных лиц (стейкхолдеров) на его демонстрацию. Задача на этом этапе —
убедиться в том, что всё в нем работает так, как нужно бизнесу и пользователям.
Если вы думаете, что продукт будет сделан ровно так, как вы себе представляли, то
вы глубоко заблуждаетесь. По пути разработки продукта задачу могли не так по-
нять или просто изменить (не обязательно упростить), потому что так, как изна-
чально хотелось, было сделать нельзя (или сложно) Причем самое интересное, что
иногда про это никто и нигде не скажет до момента демонстрации. Поэтому при-
нимать участие в приемке готовых функций очень важно. Этот этап называется
приемочным тестированием (User Acceptance Testing).
Совет новичку
Не надо пыаться найти на этом этапе всевозможные технические ошибки — это за-
дача команды тестировщиков. Вам, если вы стейкхолдер или другое заинтересован-
ное лицо нужно понять — это действительно та фича, которая нужна бизнесу, и ре-
шит ли ее реализация в том виде, как вам показывают, проблемы бизнеса Если вы
сотрудник команды разработки, уделите время не техническим особенностям (напри-
мер, показу множества однотипных сценариев), а тем бизнес-ценностям, которые по-
лучит заказчик.
11.4.1. Подготовка к приемке
Основным источником правды на этом этане являются материалы из предыдущего
раздела; сценарии использования, критерии приемки и так далее Нужно заранее
подготовиться к приемке и напомнить себе, что именно ожидается.
Чек-лист для заказчика
Промежуток времени между согласованием требований и демонстраций обычно
значителен, и можно что-то позабыть.
♦ Посмотрите на картину целиком, и вы будете в контексте того, что показываю!.
♦ Проверьте, не внесли ли в продукт какие-либо изменения, которых не должно
было быть. Например, поменяли макеты или изменили ключевой сценарий. На
демонстрации вы сможете задать вопросы, если вас это не устраивает.
♦ Запишите себе вопросы, которые вас интересуют.
Чек-лист для технических специалистов
♦ Подготовьте сценарии, предназначенные для демонстрирования. Возможно, что
показывать все альтернативные и отрицательные сценарии не имеет смысла.
Может быть, имеет смысл какие-то сценарии объединить
♦ Подумайте, чем заполнить паузы, если по истории они должны быть.
♦ Подготовьте окружение. Желательно проводить демонстрацию на окружении,
которое максимально близко к продуктивному. Например, если используются
банковские карты, то их номер по формату должен быть как настоящий (16
цифр). Если задействуются какие-то названия или имена, то они должны соот-
ветствовать настоящим. Например, имя пользователя не «Тестеров Тестер Тес-
терович», а «Петров Николай Степанович».
♦ Само собой, не забудьте позвать заинтересованных пользователей, которым бу-
дет полезна фича, даже если они не являются прямыми заказчиками
11.4.2. Приемка работы
Любая демонстрация должна начинаться со вступительного слова: что за задача,
как сделали, какие особенности Не все заказчики помнят, что вы делали, не все
читали требования и знакомы с критериями. Ну и в целом, на встрече могут при-
сутствовать и другие лица, которые не понимают, о чем речь.
♦ Сценарии должны демонстрироваться ровно так. как написано. Конечно, допус-
тимы небольшие отклонения, если они нужны для понимания контекста или
просто будут полезны.
♦ На демонстрации в основных сценариях нежелательно значительно уходить в
сторон}'. Если вы заказчик, то не выдумывайте дополнительные сценарии — у
вас было на это время раньше, когда сценарии писались. Если вы технический
специалист, то вообше следуйте плану.
♦ Если какие-то сценарии не готовы или в продукте заранее найдены ошибки, ко-
торые еще не исправлены, то надо честно об этом сказать. Например- «Функ-
циональность готова, но на подготовке к демонстрации мы обнаружили ошибку
среднего приоритета, которая будет исправлена в течение недели до официаль-
ного релиза. Номер в системе ...»
♦ Если во время демонстрации обнаруживается ранее неизвестная ошибка или
проблема, то она (а точнее, ее номер) должна быть отмечена в протоколе по
результатам проведенной встречи. При этом например, нет смысла заводить
ошибку на опечатку, но она должна быть зафиксирована при приемке и ис-
правлена.
♦ Также нужно знать о таком термине, как критерии готовности (definition of
done). Задача считается сделанной только тогда, когда выполнены все пункты
критериев готовности. Например: задача переведена в трекере в статус «Гото-
во», проставлена версия релиза, запущены и выполнены без ошибок тесты, со-
ставлена пользовательская документация. Такой подход позволяет значительно
улучшить качество. На этапе приемки можно узнать о критериях готовности ко-
манды и спросить, выполнены ли они.
11 АЗ. Принятие решения
По каждой задаче должен быть выбран один из трех вариантов:
♦ Принято.
Все ключевые критерии выполнены, сценарии продемонстрированы. Заказчик
доволен. Функция готова к выпуску. Могут быть минорные замечания.
♦ Принято с замечаниями.
Основные сценарии работают как ожидалось, но найдены некоторые проблемы
или ошибки: мажорные или минорные. Даже с ними система позволяет решать
задачу бизнеса и может быть выпущена.
♦ Отклонено.
Наблюдается критическое отклонение или не работает один из ключевых сцена-
риев. Задача не может быть выпущена и отправляется на доработку.
Решение должно быть зафиксировано. Если были найдены ошибки и проблемы, то
они должны быт ь также отмечены.
11.4.4. Некоторые особенности приемки е России
Неуказанные требования
Заказчик на демонстрации говорит что-то вроде: «Мы этого ожидали — думали,
что вы сами догадаетесь».
Решение
На этапе приемки уже поздно об этом говорить. Но если что-то такое всплыло —
нужно фиксировать это как отдельное улучшение на будущее. Используйте при
этом прототипы и макеты (см. разд. 11.3.2), чтобы визуализировать ожидания, если
их нет
Несоответствие ожиданий
Обычно возмущение выглядит примерно так: «У нас на старом продукте работает
иначе».
Решение
Если соответствующего требования нет в истории, и заказчик придумал это на хо-
ду, то необходимо объяснить ему, почему всё сделано именно так. Например «Та-
кой подход позволяет уменьшить число ошибок или сократить время». Если таких
аргументов нет, но и требований нет, тс. предлагайте заказчику оформить пожела-
ния отдельной доработкой Если вы заказчик, го вспомните, что на этапе согласо-
вания требований надо было явно прописывать то, чего вы ожидаете.
Отклонение от темы
Иногда заказчики уходят от основного вопроса, то есть отклоняются от темы.
Решение
Необходимо корректно указать, что сейчас проводится демонстрация согласно сце-
нариям и по определенным задачам, а не по всему продукту. Не надо пытаться что-
то показать, если вы не готовы.
11.4.5. В итоге
Цель приемки — успешно принять работу, а не искать повода докопаться Подхо-
дить к вопросу нужно с умом. Если команда отклонилась от требований или даже
изменила их в одностороннем порядке, то не принимайте задачу, если ваша цель не
достигнута. Если же есть незначительные замечания, то попросите их зафиксиро-
вать и прислать после демонстрации номера задач и сроки исправления. Если же вы
видите, что функциональность готова и, возможно, сделана даже лучше, чем вы
изначально планировали и согласовали, то договоритесь о том, чтобы измененные
требования были отражены и согласованы с вами, прежде чем вы дадите добро на
выпуск.
- Глава 12-
Нюансы участия нетехнических
специалистов в разработке ПО
Большая часть IT-специалистов в компании — это именно разработчики, или, как
еще говорят, программисты. В этой главе мы поговорим о том, что нужно знать о
разработке специалисту, не являющемуся разработчиком, о том, почему нужны
требования, и о том, как желание сделать задачу быстрее оборачивается тем, что ее
приходится переделывать.
12.1. От требования к задаче:
что видит разработчик?
Когда разработчик получает задачу, его первая мысль: «Как это разделить на части
и встроить в текущий продукт?» И действительно, цель любого разработчика —
разделить целевую задачу на следующие составляющие:
♦ Фронтенд (видимая часть).
Это то, что видит и с чем взаимодействует пользователь. Например, страница с
поиском содержит окно ввода и кнопку «Поиск». Разработчиков фронтенда на-
зывают «фронтендерами»
♦ Бэкенд (основная логика).
Это то, что пользователь не видит, но ожидает, что оно будет действовать. Так,
при вводе текста для поиска и нажатии на кнопку «Поиск» пользователь ожида-
ет увидеть найденные согласно ею запросу страницы. Разработчиков бэкенда
называют «бэкендерами».
Такое разделение происходит в большинстве задач. И если же разработчик выпол-
няет одновременно обе эти функции, то есть реализует задачу и на фронтенде, и на
бэкенде, его называют «фулстек-разработчнком».
Само собой, задачи бывают разные: некоторые требуют больше затрат одних спе-
циалистов, некоторые — других. Но разделение задачи на фронтенд и бэкенд про-
исходит практически всегда. И обычно из вот такого разделения задачи на части и
рождаются подзадачи, по каждой из которых может появиться оценка.
Совет новичку
Если вы новичок в команде разработки, и вам нужно понимать оценки, а в команде
есть и фронтендеры, и бэкендеры, то всегда интересуйтесь, на какого специалиста
приходится эта оценка Иначе может получиться так, что один сотрудник будет пере-
гружен, а другой, наоборот, станет сидеть без дела.
После того как все условно договорились, что будет на бэкенде, а что на фронтен-
де, каждый занятый в задаче специалист производит разбиение своей части задачи
на подзадачи — например, выделение API, изменение схемы базы данных, добав-
ление нужной библиотеки, реализация логики, написание модульных тестов.
Важный момент!
Именно разработчики пишут модульные тесты (еще говорят: unit-тесты), гарантирую-
щие, что написанная функция (или модуль) будет выполнять ту функцию, которую в
нее запожили. Тестиоовщики (даже автоматизаторы) не пишут модульные тесты
Часто самая сложная часть — это не написать новый код, а аккуратно вписать его в
старый, ничего не сломав. Иногда кажется, что нужно сделать простое изменение,
но это можег привести к ошибкам и проблемам, а также к тому, что оценка по зада-
че покажется кат ас трофической.
Отсюда возникает самый неприятный для менеджеров момент — ошибка в оценке.
Поскольку разработчик лишь предполагает, в какие конкретно места проекта будут
вносится изменения, в реальном коде всё может оказаться значительно сложнее
(или проще, но обычно — сложнее).
Опыт разработчика — это не только и не столько умение быстро писать алгоритмы,
а знание структуры текущего проекта: где находится какой модуль, как происходит
взаимодействие модулей, как хранятся данные и так далее.
Почему это важно знать сотрудникам нетехнических ролей? Для реалистичного
планирования: понимая объем скрытой работы, вы не будете удивляться, почему
«простая кнопка» оценивается в 5 дней, а не в 2 часа.
12.2. Проблема неполных требований
А теперь представьте ситуацию, что задача описана не полностью или в ней нет
ключевых требований. Тот, кто писал аналитику, думал о том, что опытные разра-
ботчики подскажут, как лучше. Такое действительно может быть, но это случается
редко. Обычно в голове про1раммиста сидит мысль не о том, правильная ли это за-
дача, а о том, как указанные требования вписать в существующий код И програм-
мист будет оптимизировать именно свое время и стараться переиспользовать мак-
симум из существующего.
Отсюда возникает интересный момент. Если в требования по задаче, которая уже
взята в разработку, внести изменения, то весь стройный план, сформировавшийся в
голове программиста, может рухнуть. Одна маленькая и забытая деталь способна
всё сломать. Не всегда всё бывает уж так плачевно, но иногда чье-то «ой, а еше тут
есть один нюанс» приводит к увеличению оценки в несколько раз.
Для понимания ситуации рассмотрим пример Он слегка надуманный, но четко от-
ражает суть проблемы.
♦ Требование к исходной задаче: «Сделайте страницу, где кладовщик может на-
жать кнопку и списать товар».
♦ План в голове. Программист создает одну страницу, одну таблицу в базе данных
и одну кнопку «Списать». Работа на два дня.
• Тот самый «один нюанс».
Когда разработка уже идет, аналитик вспоминает: «Ой, забыл сказать! Нам же
нужно видеть, кто именно списал товар, и сделать так, чтобы обычный грузчик
не мог списывать больше 10 единиц, это разрешено только старшему смены».
Почему рушится выстроенный в голове программиста план? Для заказчика это ню-
анс, а для программиста он меняет всё.
♦ База данных Теперь нельзя просто хранить остаток товара. Нужно создавать
таблицу «Пользователи», таблицу «Роли» и таблицу «Логи дейст вий».
♦ Безопасность. Надо внедрять систему регистрации, логинов, паролей и восста-
новления этих паролей.
♦ Интерфейс. Вместо одной кнопки придется делать экран входа, профиль пользо-
вателя и систему разграничения прав (админка).
♦ Логика. Понадобится прописывать условия проверок на каждое действие.
В итоге оценка задачи из двух дней превращается в две недели. И если код уже был
написан под «одного анонимного пользователя», его приходится буквально перепи-
сывать с нуля, т. к. исходная архитектура не предполагала деления на разные роли.
12.3. Что непрограммистам важно знать
про стек технологий и фреймворк?
Если продолжить метафору ресторана, то стек технологий — это полностью рабо-
тающий ресторан, в котором есть правила для официантов, кухни, клининга, хос-
тес, службы доставки. А фреймворк — франшиза (готовая бизнес-модель) этого
ресторана.
В ней есть конкретные правила:
♦ Требования к помещению и расположению. Ресторан должен быть расположен в
соответствующем мест. Не имеет смысла открывать дорогой итальянский рес-
торан в бедных районах.
♦ Планировка кухни. Вы не можете поставить плиту гам, где рядом стоит холо-
дильник .
♦ Стандарты обслуживания. Правила обслуживания гостей должны соблюдаться.
Кухня должна также соблюдать стандарты приготовления.
♦ Меню и состав. Блюдо готовится по рецепту с использованием заранее пропи-
санных технологических карт, а не придумывается на ходу.
Точно так же и в разработке: фреймворк должен быть корректно выбран согласно
потребностям бизнеса, и он стандартизирует работу разработки. Менять фреймворк
обычно стоит очень дорого — это как покупать новую франшизу в существующий
ресторан. Обновлять части стека можно, это дешевле, чем менять фреймворк, но
затраты понести всё равно придется
Спепиатисту, не являющемуся разработчиком, надо иметь представление о том, на
каком стеке пишет команда разработки. Но зачем непрш рам мисту это знать?
Основных мотива два:
♦ нужно понимать, почему был выбран именно такой стек, а не друзой (на каком
основании);
♦ и в какую сумму обойдется его использование
Иногда можно столкнуться с ситуацией, что стек был выбран, потому что он явля-
ется новым или интересным для какого-то разработчика. Не удивляйтесь, такое
легко может быть.
На самом деле стек должен быть устоявшимся (ориентированным на популярные
технологии), и самое главное — популярные технологии именно в России. А «по-
пулярные» — это значит, что с ними знакомо большое количество специалистов,
которые смогут решать задачу. Например, нельзя допускать ситуации, когда иде-
ально подходящий язык программирования знают лишь два сотрудника, да и то в
другом регионе.
Особое внимание следует уделить узким нишевым технологиям (специфичные
языки или фреймворки). Плюс таких технологий в том, что они идеально решают
конкретную задачу (или класс задач), но минус состоит в том, что обычно сами ре-
шения могут стоить дорого, специалистов по ним мало и с решением проблем ни-
кто не поможет.
Вывод
Если команда предлагает использовато нишевую технологию для тилевой задачи —
стоит спросить «Почему?» Если для уникальной задачи предлагают самый популяр-
ный стек, то стоит уточнить «Хватит ли его?-».
12,4. Окончание срока поддержки
Если технология совсем новая, то может случится гак, что через непродолжитель-
ное время она перестанет поддерживаться разработчиками, потому что продукт
оказался не востребован. Это может касаться и крупных компаний. Они так же за-
пускают старт ап-продукты или технологии и так же сворачивают их А вам потом с
этим жить.
Нужно при этом понимать то, что у разных версий продуктов и технологий есть
разные циклы поддержки. Например, одна и та же технология разных версий может
поддерживаться очень разное время. Поддержка — это выпуск обновлений, ис-
правление ошибок, а не т олько новые фичи.
Многие продуктовые компании выпускают решения двух видов.
♦ Long-Term Support (LTS-версии) — это версия продукта, в которой обеспечива-
ется длительная техническая поддержка.
Версии LTS — стабильные, в них включаются в том числе исправления уязви-
мостей и другие важные улучшения. Срок поддержки таких продуктов составля-
ет обычно годы. С другой стороны, в LTS-версиях могут отсутствовать совре-
менные и актуальные решения, введение новых важных функций происходит
медленнее.
♦ Non-LTS (Short-Term Support)— это версия продукта, в которой не обеспечива-
ется длительная техническая поддержка
Версии Non-LTS обладают гораздо меньшим циклом поддержки — обычно это
месяцы. Но многие удачные решения из Non-LTS переходят в следующие вер-
сии LTS.
Если проводить аналогию с рестораном, то можно сказать, что LTS-решение — это
классическое блюдо, которое не выводят из меню в течение длительного времени, а
Non-LTS — это блюдо сезонное, которое хочется попробовать. Если оно будет
удачным, то, возможно, его перенесут в постоянное меню.
Совет
Когда выбирается новая технология, всегда спрашивайте, какой у нее срок окончания
поддержки, и уточняйте, LTS ли это версия или не LTS
» ♦ ♦
И в заключение. Всегда спрашивайте команду о том, какие есть главные ограниче-
ния у выбранной технологии, фреймворка или стека Вам нужно понимать, с каки-
ми проблемами вы можете столкнуться через какое-то время
12.5. Работа с кодом и системами контроля версий
Давайте поговорим о том, как вести разработку нескольких фичей одновременно.
Современные команды разработки должны иметь возможность параллельно рабо-
тать со всем необходимым кодом. При этом важно, чтобы изменения, вносимые
каждым программистом, с одной стороны, не влияли на работу других участников
команды и не нарушали стабильность продукта, а с другой — чтобы все завершен-
ные фичи были корректно объединены и вошли в итоговый релиз без побочных
эффектов. Такой подход в разработке реализуется с помощью специальных меха-
низмов организации работы с кодом — систем контроля версий.
Суть системы контроля версия сводится к тому, что каждый программист работает
со своей копией программы, вносит в нее необходимые изменения и можег совер-
шенно ничего не знать про то, что в этот момент делают другие (они друг другу не
мешают). Программу можно нс просто писать, но еше и проверять. Когда код напи-
сан и все необходимые проверки выполнены, начинается процесс слияния версий
Для примера с ремонтом квартиры это выглядело бы забавно: сантехнику выдали
свою копию квартиры, и он может отдельно монтировать там санузлы (как будто
он работает на одном этаже), электрику в точно такой же квартире можно зани-
маться только электрикой, при этом у штукатуров есть своя квартира, где не задей-
ствованы ни сантехник, ни электрик. Когда каждый сделает свою работу, их копии
квартир объединяют в единую квартиру. Фантастика.
В разработке же это возможно, и нет никакой фантастики. Каждый пршраммист
работает со своей версией кода (веткой, branch), вносит в нее нужные изменения, а
затем изменения соединяются в одну основную ветку (которая, например, называ-
ется master). Для реализации такого подхода и придумали систему управления
версиями. Самая распространенная в настоящий момент — Git. Де-факто Git вы-
теснила старые централизованные системы (SVN, CVS) благодаря распределен-
ной архитектуре — у каждого разработчика есть полная копия истории на своем
компьютере. Любой программист (даже junior) должен уметь работать с Git или
другой системой управления версиями — в противном случае у него не получится
принять участие в разработке продукта.
Совет новичку
Поинтересуйтесь у коллег, какую систему контроля версий используют в компании
Если вы программист, то без этого вы даже не начнете работу.
Рассмотрим пример с разработкой мобильного приложения. Здесь один нротрам-
мист делает окно для входа пользователя, второй — страницу с персональной
информацией, третий — с предложениями для клиента мобильного приложения.
И мы в итоге получим продукт, который будет содержать в себе все указанные воз-
можности. Однако между правками может пройти достаточное время, поскольку
они могут завершаться не одновременно, а по мере готовности. Сам процесс объе-
динения изменений, сделанных, участвующими в проекте программистами, называ-
ется «слиянием», хотя часто можно услышать «merge».
При этом могут возникать и серьезные ограничения. Представьте, например, что
сантехник и электрик пересеклись в какой-то точке. В жизни электропровод и гру-
ба с водой могут пересекаться. К примеру, на кухне — это вообще элементарно.
Если задача очень большая (например, рефакторинг), то такое может легко про-
изойти. На стройке это может вызвать серьезные проблемы и переделку В разра-
ботке — тоже, и называют такую ситуацию «конфликт слияния» (merge conflict),
однако разработчики должны уметь решать такие конфликты. Решить конфликт —
это договориться, как развести «свет» и «воду», то есть сделать так. чтобы обе до-
работки работали и не мешали друг другу.
При этом крайне важно отслеживать ситуации, когда разные сотрудники работают
над одной областью кода. Обычно (но не всегда) одна область кода— это связан-
ные по функциональности задачи. Например, оплата по СБП в двух разных бан-
ках — это связанная функциональность.
Иногда, если не обнаружить такую связанную функциональность на каком-то эта-
пе, го это может привести в конце концов к тому, что одну из задач придется пере-
делывать. И, возможно, целиком. Так что по возможности старайтесь не давать од-
новременно в работу задачи из одной области разным разработчикам. А если избе-
жать этого нельзя, то нужно обязательно предупредить их об этом, чтобы не допус-
тить переделки.
12.6. Ревью кода, сборка и развертывание
Когда код написан, это еще не означает, что его тут же можно проверять Надо по-
нимать. что существуют процедуры, направленные на обеспечение качества напи-
санного кода, а также на то, чтобы этот код был преобразован и доставлен на точки
проверки (и позже до клиента).
12.6.1. Ревью кода
Все изменения в общий код (то есть код, который будет у всех) попадают через
специальный механизм — запрос на слияние (pull request/merge request, PR/MR).
Смысл этого механизма в том, что произведенные в коде изменения сначала про-
сматриваются. а затем одобряются другими разработчиками — тут уже действует
механизм просмотра кода (code review), позволяющий вносить уточнения в любую
строчку документа без полного копирования самого документа.
На этом этапе:
♦ производятся автоматические проверки (CI, Continuous Integration)— запуска-
ются тесты, проверяется стиль кода, собирается проект. Если что-то ломается
(например, падает тест), го автору придется сначала это починить;
♦ коллеги-разработчики изучают код, задают вопросы, предлагают улучшения.
Иногда замечания могут быть очень критичными и приходится переделывать
решение целиком — если, например, оно медленно работает или небезопасно.
С момента создания запроса на слияние до момента его завершения может пройти
достаточно много времени, — например, неделя и даже больше. Но если всё сдела-
но качественно, то решение может зайти быстро.
Совет новичку
Если вы че представляете, как выглядит pud request, ю попросите коллегу-разработ-
чика показать вам пример из программы которую вы делаете
При выполнении запроса на слияние (pull request) следует соблюдать следующие
принципы:
♦ должна быть выстроена система автоматического контроля качества, включающая
многие интересные практики: статический анализ кода, автоматическое тестиро-
вание, соблюдение стиля кодирования, автоматическое добавление владельцев
кода (code owner) и любые другие проверки, которые требуются вашему' продук-
ту. Таким образом изменения до целевой версии доходят уже проверенные;
♦ работа с кодом должна происходить таким образом, чтобы максимально снизить
человеческие действия— всё, что может выполняться автоматически, должно
выполняться автоматически. Кроме того, должна быть выстроена максимальная
защита от случайных и непроверенных изменений — например, защита основ-
ного кода (основной ветки) от прямых изменений (коммитов);
♦ каждое предложение на изменение должно иметь законченную функциональ-
ность. Два не связанных изменения не должны попадать в один запрос;
♦ для ключевых версий используется система тегов— таким образом, всегда
можно вернуться к нужному тегу и внести изменения;
♦ процесс должен быть организован таким образом, чтобы не остановить разра-
ботку продукта., и чтобы в любой момент времени разработчик мог внести но-
вые изменения, даже если параллельно идет другой процесс, — например, вы-
пуска релиза.
Совет новичку
В какой бы роли вы ни состояли, если вы специалист технической команды (команды
разработки), разберитесь в той системе, которая используется у вас. Это нужно, что-
бы понимать разработчиков
Для чего нужны ревью и CI?
♦ Ревью и автоматические проверки снижают появление рисков Ошибка, найден-
ная на ревью, стоит и разработке, и бизнесу дешевле той, что попала к клиенту.
♦ При ревью кода происходит процесс обучения разработчиков и осмысления ими
того, что нового в нем появилось. В следующий раз уже другой разработчик
вспомнит, что связанная или похожая задача уже решалась.
12.6.2. Сборка
После успешного ревью и слияния кода в основную ветку срабатывает процесс
сборки— автоматизированный процесс, который написанный код и все зависимо-
сти (библиотеки) упаковывает в готовый к работе артефакт Например:
♦ для веб-приложения — это набор файлов (HTML, CSS, JS);
♦ для мобильного приложения — файл *.арк или *.ipa;
♦ для серверного приложения — Docker-образ или jar-файл.
Метафорой сборки может служить процесс на кондитерской фабрике, когда по ре-
цепту (код) смешиваются ингредиенты (библиотеки) и выпекается готовый торт
(аргефакт). упакованный в коробку (образ).
Что может здесь пойти не так? Сборка может упасть. Например, из-за конфлик-
тующих версий или из-за проблем с инфраструктурой (нет Интернета, закончилось
место на диске).
Почему это важно?
Если сборка не проходит, продукт нельзя развернуть и поставить: ни в тестирование,
ни клиенту.
12.6.3. Развертывание
Развертывание — доставка собранного артефакта в целевую среду В мегафоре —
это доставка блюда клиенту.
Думаю, очевидно, что код должен быть сначала протестирован (про тестирование
подробно рассказано в главе 13). Но даже протестированный код (а точнее, арте-
факт) не должен доставляться всем клиентам в один момент.
Существуют несколько подходов к тому, какие клиенты и в каком количестве по-
лучат новый код. Их называют «стратегиями развертывания», и они важны для
управления рисками.
Совет новичку
Если хотите разобраться со стратегией развертывания, то поговорите с командой
DevOps — обычно за то. какая стратегия развертывания применяется в продукте, от-
вечают именно они
Почему это важно для всех, а не только для разработчиков?
♦ Можно и нужно планировать обновления. Зная стратегию развертывания, вы,
как менеджер или аналитик, можете планировать коммуникацию с пользовате-
лями, готовить инструкции.
♦ Для управления рисками. Понимание, что релиз это управляемый процесс с
возможностями постепенного обновления и отката, позволяет адекватно реаги-
ровать на вопросы бизнеса о сроках и стабильности.
Ключевой вывод для нетехнического специалиста
Когда разработчик говорит «Задача сделана, но еще не в тесте», он обычно имеет в
виду, что код находится где-то в стадии Ревью —> Сборка -»Доставка
12.7. Технический долг и управление legacy-кодом
Со временем в любом продукте появляется технический долг. Для менеджера или
члена продуктовой команды термин legacy и технический долг означают в основ-
ном огорчение. Придется тратить время на задачи, которые не дадут никакой биз-
нес-ценности. но при этом на них, скорее всего, будет потрачено большое количе-
ство времени, а как следствие может случиться еще и большое количество ошибок.
12.7.1. Legacy-код
Legacy-код — это не плохой код, как можно подумать. Это существующий код, ко-
торый обладав следующими свойствами:
♦ он работает и выполняет требуемые функции, то есть закрывает потребности
бизнеса;
♦ он имеет низкую поддерживаем ость, то есть его тяжело изменить или дополнить
так, чтобы не сломать существующую функциональность, но добавить новую.
Бывает ли плохой legacy-код? Конечно, бывает.
Бывает нормальный legacy-код? Тоже бывает.
Например, код, написанный давно на устаревших технологиях. Он может быть
плохо документирован, в нем никто не разбирается, но он работает и работает без
ошибок. — это и есть legacy-код.
А бывает наоборот — код еще свежий, а в нем уже тяжело разобраться и понять его.
Аналогия из жизни
Квартира, которая досталась по наследству или от прежних хозяев, может быть как в
относительно новом, так и в старом доме. Но лри этом ремонт в ней может быть сде-
лан совершенно по-разному
Бывает так, что даже в старых демах можно увидеть хороший, уд тбный и подходящий
для жизни ремонт: коммуникации работают, батареи греют. Да. есть вопросы к плани-
ровке или к высоте потолков но в целом это хорошее и удобное для жизни жилье
А бывают новостройки с ужасным ремонтом по каким-то причинам в доме холодно,
юрячую воду нужно ждать по пять минут и т.п. Да и ь целом вкус прежних хозяев
сильно отличается ст вашего.
Оба варианта — это legacy-ремонты, но первый, хоть и не новый, но нормальный и по-
зволяющий жить в комфортных условиях, а второй — молодей, но уже непрактичный.
Вполне логично, что со временем в продуктах, которые работают годами, часть ко-
да становится legacy. Модули не трогают, ничего не меняют, а сотрудники меняют-
ся, технологии развиваются.
Нужно ли что-то делать с legacy-кодом? Если он работает и не мешает развиваться
бизнесу — нет, не надо его трогать. Но нужно следующее:
♦ изучить, как работает существующий код, и понять его. На выходе идеально по-
лучить схемы его работы и особенности в виде заметок;
♦ дополнить код тестами, если планируется его доработка;
♦ изменения должны быть небольшими и дающими результат, чтобы в случае по-
явления проблем можно было быстро их исправить;
♦ в случае реальных проблем — подумать о рефакторинге, но при этом следует
обеспечить качество изменений: нужно будет организовать аналитику поведе-
ния и проведение автоматических тестов
12.7.2. Технический долг
Технический долг появляется в результате разработки кода с тем, чтобы быстрее
достичь бизнес-ценности, но поступиться качеством.
Бизнес всегда хочет получить задачу побыстрее и подешевле. И так бывает, что
разработчики делают фичи быстрее, и бизнес доволен. Однако со временем начи-
нают происходить странные ситуации:
♦ как бы команда и бизнес ни хотели, но сделать еще одну фичу «быстро» не по-
лучается;
♦ как бы команда и бизнес ни хотели, но в выпускаемых задачах находится боль-
шое количество ошибок;
♦ как бы команда и бизнес ни хотели, но выполнить некоторые требования по ско-
рости работы или производительности не получается.
Так происходит, потому что в продукте растет технический долг.
Аналогия из жизни
Технический долг в реальной жизни встречается чаше, чем кажется. Просто мы ею
так не называем.
Вы наверняка знаете о том, что автомобилю нужно регулярно проводить техническое
обслуживание Можно не делать его? В целом, можно, н т со временем машина начнет
«сыпаться» — появляется все больше проблем.
Нужно также помнить, что обслуживать нужно всю технику, которая есть в доме ино-
гда просто чистить, иногда смазывать, а иногда делать и более сложные манипуля-
ции — например, менять фильтр или расходники
Определенный запас прочности есть у всех вешей, но лучше регулярно проводить
техобслуживание, чем потом чинить что-ю, что сломалось из-за того, что не было во-
время обслужено
В случаях с автомобилем, если не исправлять технический долг, то можно остаться
без машины. С разработкой то же самое - можно остаться без репу1ации. с огром-
ными штрафами и без команды.
Типы технического долга
Нужно понимать, что технический долг может появляться по разным причинам.
Поэтому укажу наиболее распространенные;
♦ Технический долг, возникший в результате срочной разработки.
Команда, создавая такой технический долг, сразу знает, что она сделала «не
очень качественно», но пошла на уступки бизнесу. Чаще всего такое происходит
из-за сроков На основании такого технического долга можно сразу создать за-
дачи по его решению, поскольку обычно понятно, что делать. Но затраты могут
быть соизмеримы с реализацией самой задачи, которая дала такой технический
долг. Чаще всего такой технический долг проявляется в ограничении использо-
вания функциональности, ее несовместимости с другими функциями системы,
сложности дальнейшей доработки в таком виде, чтобы полностью не сломать
работу задачи.
♦ Технический долг, возникший из-за недостатка опыта, изменившихся требова-
ний или плохого дизайна
В этом случае не всегда вообще можно понять, что технический долг существу-
ет. Он проявляется позже — например, через будущие ошибки, упущенные сце-
нарии, которые не должны были быть упущены, или увеличение затрат на реа-
лизацию будущих задач. Такой технический долг заранее обычно невозможно
выявить, и, как следствие, затраты на его устранение обычно сложно оценить
заранее.
♦ Архитектурный технический долг — самый сложный и затратный по исправлению.
♦ Некорректно выбранная архитектура или неактуальность архитектуры предъяв-
ляемым требованиям. Например, при проектировании имелись одни требования
к продукту, но со временем они значительно поменялись, и принятая архитекту-
ра к новым вызовам оказалась не готова. Устаревшие и неподдерживаемые тех-
нологии — это тоже архитектурный технический долг. Затраты на исправление
архитектурного технического долга обычно значительны.
Что делать с техническим долгом?
Самое первое, что нужно сделать с любым техническим долгом, — это его завести
и описать. Не говорить о том, как всё плохо, или что качеству не уделяется время,
или чго не хватает ресурсов, а просто завести и описать.
Если со случаями очевидного технического долга завести и описать задачу относи-
тельно просто, потому что команда знает о его существовании, то о техническом
долге, возникшем непреднамеренно, надо еще узнать. Завести задачу по архитек-
турному долгу тоже достаточно просто, но вот описать, что с ним делать, уже зна-
чительно сложнее.
Второе — это оценить задачу по закрытию технического долга и получаемую вы-
году. То есть понять стоимость возврата технического долга и его размер. На осно-
вании этого можно попробовать расставить приоритеты И еще в приоритет надо
добавить риск сломать что-нибудь.
Если команда не очень хорошо умеет работать с техническим долгом (желание и
умение это разные вещи), то следует начинать с небольших задач, максимально
покрытых тестами. Вообще, заниматься исправлением технического долга команде,
не имеющей соответствующего опыта и не имеющей автотестов, — это провальная
затея.
А что делать, если нет тестов? Написать их. Возможно, это и есть тот самый гех-
долг, который нужно вернуть, — ведь автотесты абсолютно безопасны с точки зре-
ния рисков.
Третье — планирование технического долга в общем бэклоге.
Если команда настаивает на крупном рефакторинге, то следует:
1. До его начала определиться с тем, как будет оцениваться результат. А действи-
тельно ли стало лучше? Спойлер: многие рефакторинга на первой итерации сде-
лают только хуже.
2. Описать область рефакторинга, то есть те модули и, главное, бизнес-функпии,
которые будут изменены
3. Максимально его разделить на части и выпускать релизы по частям, желательно,
не совмещая с критичными для бизнеса задачами
4. Использовать возможность включения «старой» логики (фича-флаг). То есть
возможность проведения управляемого пилота по рефакторингу.
5. Нужно иметь план отката на случай, если что-то пойдет не так. Не надейтесь на
то. чт о всё обязательно пойдет как надо
Что делать,
если времени на возврат технического долга не дают?
Бывает, что команде выделяют 10-15-20% времени на некие технические задачи.
Это время команда может тратить на «свои» задачи, а не на продуктовые. Но так
бывает далеко не всегда.
Иногда бывает гак, что бизнес не готов выделять время на возвраты долга. Что же
делать, когда тот, кто берет деньги в долг, не возвращает их потом? Очевидно, что
не давать ему в долг. Легко сказать...
Самым эффективным способом возврата технического долга является ситуация,
когда возврат технического долга должен быть включен в объем, реализуемый в
какой-либо задаче. То есть при выполнении какой-то реализации исправляется и
часть технического долга, связанная с этой задачей. Например, при реализации
очередного отчета в продукте исправляется технический долг, связанный с общей
логикой формирования данных, механизмами фильтрации или архитектурой по-
строения отчетности, используемой в этом модуле.
Такой подход часто называют правилом бойскаута: оставлять код после себя чуть
чище, чем он был до вашего прихода.
Бизнес не должны шокировать оценки. Например, затраты с возвратом техдолга не
могут быть значительно выше, чем без возврата. Чтобы так делать, нужно опять
думать над разделением технического долга.
Если же ну совсем никак, а обманывать продуктовую команду не хочется, то мож-
но ничего не делать. Бизнес сам дойдет до состояния, когда потребуется что-то ме-
нять. Нс устроит скорость, количество ошибок, мнение клиентов или что-то еще, но
это произойдет. И тут вы опять должны иметь г отовый список задач
Будьте готовы к тому, что в продукте будет и технический долг, и код в нем будет
legacy. Невозможно этого избежать, нужно научиться с этим работать. Старайтесь
смотреть в будущее, думайте не о том, как сделать быстрее сегодня, а как внести
изменения в завтра. В этом вопросе профессионалы отличаются от любителей —
здесь как при игре в бильярд: важно не просто забить шар, а оставить возможность
для следующего удара. Любители просто забивают шар и не думают о том, какой
удар будет следующим, профессионал же сразу думает о том. как будет действо-
вать дальше. Важно не просто сделать задачу, а оставить возможность для того,
чтобы сделать следующий шаг.
12.8. Версионирование, прямая
и обратная совместимость
Версионирование— это процесс нумерации версий продукта или его компонентов.
Несмотря на важность этого процесса, он достаточно понятный. Холя иногда вызы-
вает некоторый ступор как у технических, так и нетехнических специалистов, ко-
торые нумеруют версии кто и как захочет.
Аналогия из жизни
Чтобы понять, зачем нужны правила нумерации версий предогвьте. что вы выходите
на улицу и видите, что у всех домоа нет номеров, а только названия вроде «Дом Ан-
тона» или «Красная вилла» Как понять, куда идти? Нужно знать все названия Служ-
бы доставки были бы в большой печали. Так и в разработке: было бы очень сложно
понять, что за изменения ждут, если позволить каждому называть версии как захочется.
Поэтому в продуктах существуют четкие правила нумерации версий Думаю, что
каждый, кто читает эту книгу, хоть раз встречался с номерами версий продукта.
Например, номер версии продукта, состоящий из двух чисел: 1.2. Бывает больше —
например, три числа, разделенные точкой. Бывают дополнительные буквы и другие
символы или упоминания. Иногда версии включают словесные названия
Однако существуют достаточно четкие правила нумерации версий, которых необ-
ходимо придерживаться, и далее я объясню, почему
12.8.1. Семантическое версионирование
Семантическое версионирование ("Semantic Versioning, SemVer) — это правила ну-
мерации версий, согласно которым версия состоит из префикса «V» и грех чисел,
разделенных точками: vfmajor].[minor].[patchJ:
♦ [major] — существенные изменения, которые могут нарушать обратную совмес-
тимость:
♦ [minor] — изменения и добавление новых функций, которые не нарушают об-
ратную совместимость,
♦ [patch] — исправления ошибок или уязвимостей.
Семантическое версионирование — это, пожалуй, самый популярный способ вер-
сионирования. Оно настолько популярно, что даже имеет свой сайт semver.org, ко-
торый поддерживает несколько языков.
Примеры нумерации версий
• v1 0 0 - выпущен стабильный релиз.
• v1.1,u — в релиз добавлена новая функциональность (одна или несколько), може1
быть, исправлены ошибки
• vl 1.1 — исправлена ошибка или несколько ошибок.
• v2.no— выпущен новый релиз, произошли существенные изменения, возможн.--
потеряна совместимость
12.8.2. Прямая и обратная совместимость
Важно понимать, что такое в принципе прямая и обратная совместимости, т. к.
в разработке программного обеспечения с этим вопросом сталкиваются постоянно.
В этом вопросе я сразу начну с аналогии работы на кухне.
Пример прямой совместимости на кухне
Предсгавьте, что у вас есть какая-то либо посуда для приготовления еды Допустим,
это обычная сковорода Зы жарите на ней мясо и овощи И у вас возникает потреб-
ность приготовить на новой сковороде какое-ю новое блюде — например, вы решили
приготовить сырники. Вы наверняка легко это сделаете, потому что сковородка умеет
жарить. Это называется прямая совместимость
Пример отсутствия прямой совместимости
Возьмем ту же самую обычную сковороду, но в этот раз заменим то на чем гото-
вим, — то есть плиту Мы возьмем новую современную индукционную плиту И тут
может случится проблема, если ваша самая обычная сковорода не имеет возможно-
сти работы на индукционной плите Это называется потерей прямой совместимости,
потому что старое оборудование (сковорода) не может работать с новой технологией.
Итого, прямая совместимость означает, что «старая» кухня может готовить «но-
вые» блюда.
Теперь про обратную совместимость. Обратная совместимость означает, что новая
кухня может готовить и те блюда, которые готовились раньше.
Пример обратной совместимости на кухне
Представьте, что вы купили новую сковороду, коюрая может работать на индукцион-
ной плите, но у вас плита не индукционная. Ваша новая сковородка всё равно пре-
красно будет выполнять свои функции, т к. может работать и на обычной плите Но-
вые сковороды сделаны так, чтобы работать и на индукционных, и на обычных плитах.
Пример потери обратной совместимости
Вы купили новую сковороду, но оказалось, что у нее какое-тг специфичное покрытие,
и использовать привычную металлическую лопатку нельзя, а нужно иметь деревянную
или силиконовую.
Как это ни парадоксально звучит, но обычно предполагают наличие именно обратной
совместимости, а не прямой. То есть новое должно поддерживав работу старого.
Теперь от аналогии перейдем к программному обеспечению.
♦ Прямая совместимость — это возможность старой версии иро!раммного обес-
печения работать с новыми версиями данных, форматов, протоколов
• если выходит новая версия API, то старая версия программы всё равно может
работать с этой новой версией API;
• если выходит новая версия формата документа, то старая версия программы
всё равно может корректно работать с документами, сохраненными в этом
формате.
Очевидно, что если есть новые функции, то старая программа поддерживать их
совсем не обязана и в большинстве случаев не будет, но вот то. что старая вер-
сия программы должна будет работать с новыми форматами, протоколами и
версиями, — это означает наличие прямой совместимости.
Если же старая версия программы не сможет открыть новый формат или не под-
держивает новый протокол или API. то это означает, что отсутствует прямая со-
вместимость.
Многим знакома ситуация, когда скопированный файл не открывается на дру-
гом компьютере из-за того, что он сохранен в слишком свежей версии. Это от-
сутствие прямой совместимости.
♦ Обратная совместимость — это возможность новой версии программного
обеспечения работать со старыми версиями данных, форматов и протоколов:
• если по АР1 приходит janpoc старой версии, то новая программа должна кор-
ректно его отработать;
• если в новой профамме открыть документ, сохраненный в старой версии
программы, то произойдет успешное открытие.
С точки зрения разработки программного обеспечения, сохранить обратную со-
вместимость проще и требуется она чаще. Ну и большинство полагает , что по
умолчанию обратная совместимость присутствует, то есть новые программы мо
гут работать со старыми документами, API и протоколами.
12.8.3. Связь версионности и совместимости
♦ Если используется SemVer (major.minor.patch), то изменение старшей (major)
версии означает возможную потерю обратной совместимости. Если, например,
изменяется старшая версия в API, то это означает, что старые программы не
смогут работать по новому API.
♦ Если же major сохраняется, а изменяется minor, то обратная совместимость со-
храняется, а вот прямая совместимость не гарантируется.
♦ Если же major и minor не изменяются, а меняется patch, то сохраняется и прямая,
и обратная совместимость.
Совет
Всегда спрашивайте почему в продукте теряется обратная совместимость, и можно
ли ее сохранить Если нельзя, то подумайте, как информировать об этом клиентов.
- Глава 13-
Нюансы участия нетехнических
специалистов в тестировании ПО
Тестирование программного обеспечения — это один из самых популярных спосо-
бов начать карьеру в IT. Это связано с тем. что тестирование кажется понятным и,
на первый взгляд, не требует специальных знаний. С одной стороны, это действи-
тельно так, а с другой, тестирование — достаточно сложный процесс, если подхо-
дить к нему комплексно и системно. В этой главе вы узнаете про то, какие в прин-
ципе бывают виды тестирования, про основные артефакты тестирования, про авто-
матические тесты и про приемочное тестирование.
13.1. Виды тестирования
Существует множество видов тестирования и его классификаций: ручное, автома-
тическое, стресс-тестирование и нагрузочное, дымовое тестирование, тестирование
на обратную совместимость.
Совет новичку, не являющемуся тестировщиком
Не пытайтесь сходу разобраться во всех видах тестов, которые вообще существуют
Сфокусируйтесь на видах тестирования, критичных конкретно для вашей команды.
Спросите у старших коллег: «Какие виды тестирования у нас заложены в процесс
команды и почему именно эти?»
Зачем нужно так много видов тестов?
Каждый вид тестов закрывает определенный набор требований, ситуаций или рис-
ков Например, для проверки того, как система ведет себя под нагрузкой, использу-
ется нагрузочное тестирование.
Не стоит думать, что все компании используют одновременно все виды тестов. Это
дорого. А тестирование — это первое, на чем можно сэкономить Ведь затрат больше,
а выгода не очень понятна.
В разные моменты времени (па разных этапах разработки) задействуют разные ви-
ды тестов. Так, ближе к выпуску чаше применяют нагрузочное тестирование —
чтобы проверить, как система ведет себя под нагрузкой, и меньше — ручное тести-
рование задач, поскольку обычно задачи к этому времени уже проверены.
Вот типовой набор видов для большинства российских компаний;
♦ Ручное функциональное тестирование (чаще говорят просто ручное тестирова-
ние)— это тестирование, выполняемое непосредственно человеком-
тестировщиком, в котором проверяется, соответствует ли поведение продукта
заявленным требованиям. Например, происходит ли при вводе пин-кода и нажа-
тии кнопки «Вход» проверка на корректность и вход.
♦ Автоматическое функциональное тестирование {автоматическое тестирова-
ние) — все действия выполняются не вручную, а каким-либо «роботом» или ин-
струментом. который умеет сам нажимать кнопки, проверять тексты, статусы,
значения в базах данных и читать файлы. Сценарии те же, но проверяются они
не человеком. Особенность такою тестирования в том, что пишут автоматиче-
ские тесты тоже люди, хотя и с определенным профилем.
Автотесты создаются примерно по такой схеме: сначала определяются сцена-
рии, затем эти сценарии реализуются в коде (программируется, например, нажа-
тие цифр и кнопки «Вход»), после чего проверяется, что последовала правиль-
ная реакция (отображается корректный экран). Автоматические тесты — доро-
гие. так как их разработка занимает время, сопровождение также стоит денег,
поэтому автотесты применяют на длительных проектах.
♦ Регрессионное тестирование — проверка, что новые функции не сломали ста-
рые. Такое тестирование может производиться вручную или автоматически (это,
соответственно, ручное регрессионное тестирование или автоматическое рег-
рессионное тестирование). Когда на автоматизацию нет времени и/или денег,
оно часто выполняется вручную по чек-листам.
На практике достаточно распространена ситуация, когда используется автоматиче-
ское регрессионное тестирование. При этом автоматическое тестирование новой
функциональности обычно не встречается. То есть типовой процесс выглядит так:
1. После реализации задачи она проверяется вручную (ручное тестирование).
2. Затем пишутся автоматические тесты на эту же функциональность
3. При этом оба указанных этапа могут быть значительно разделены по времени.
Вполне распространены (но не обязательны) ситуации, когда автотесты пишутся
в том же релизе, в котором реализуется функциональность задачи.
4 Существует также подход, кот орый называется разработка через тестирование
(Test-Driven Development, TDD), когда сначала программист создает модульный
тест (само собой, он не должен успешно проходить), а только затем пишется ку-
сочек кода, при выполнении которого тест должен успешно пройти.
5. Аналогичный подход в тестировании называется Acceptance Test-Dnven Devel-
opment (ATDD). Смысл его аналогичен: сначала автотесты пишутся на функ-
циональность, которая еще не реализована, и, естественно, они не работают
(«красные»). Затем, когда функциональность готова, автотесты начинают ус-
пешно выполняться (становятся «зелеными»).
13.2. Ручное тестирование:
проверяем как пользователь
Ручное тестирование — проверка задачи на соответствие поставленным требова-
ниям. Это обязательный этап в разработке.
Суть его сводится к следующему: сотрудник читает требования и вручную удосто-
веряется, что функциональность работает так, как требованиями и предусмотрено.
Проверки могут осуществляться с использованием различных технических средств,
ее упрощающих:
♦ инструменты проверки API (например, Postman);
♦ инструменты эмуляции данных;
♦ генераторы большого количества данных;
♦ генераторы случайных значений.
У опытного инженера по тестированию в запасе есть достаточное количество инст-
рументов, упрощающих его работу.
Но следует помнить, что первое ручное тестирование должно выполняться про-
граммистом. Все «белые» и альтернативные сценарии использования, указанные в
постановке требований, должны проверяться именно программистом до передачи
тестировщику.
Несмотря на кажущуюся очевидную вещь: «проверь, что сделал», протраммисгы
очень и очень часто игнорируют проверки даже «белых» сценариев и передают за-
дачу в тестирование без базовых проверок. Иногда это излишняя самоуверенность,
иногда— безответственность, иногда— лень. По моему мнению, чем выше уро-
вень программиста, тем более тщательные проверки он делает. Но в любом cjiynae
проверять основные сценарии программист обязан.
Почему плохо отдавать вообще непроверенную задачу инженеру по тестированию?
♦ Это потеря времени: тестировщик готовит тесты, проверяет задачу на соответст-
вие сценарию, убеждается, что тесты не проходят, а затем тратит время на пояс-
нения программисту. Программист делает исправления и отправляет задачу на
ретест (повторное тестирование). Очевидно, что это минимум двойные затраты
на тестирование плюс затраты на коммуникацию.
♦ Это переключение контекста и простой. Когда инженер по тестированию берет
задачу в работу, программист обычно начинает делать другую задачу. Когда
тестировщик найдет ошибку, разработчик вынужден будет прерваться на ее ис-
правление, а тестировщик — ждать поступления задачи на ретест (то есть нахо-
диться в простое) либо переключиться на другую задачу, если такая есть.
Как решить проблему того, что на тест передают абсолютно непроверенную зада-
чу? Составить правила, задающие условия, при которых задача может быть переда-
на в тестирование (аналог критериев готовности, только для этапа тестирования).
И требовать их соблюдения всеми участниками процесса.
Совет новичку
Если вы видите, чтс в вашей команде разработчики не проводят базовые проверки,
поднимите вопрос на ретроспективе.
13.2.1. Общий подход к ручному тестированию
Что включает в себя в принципе типовое ручное тестирование
1 Ознакомление с требованиями
2. Формирование списка тестовых сценариев.
3. Проведение проверки согласно сценариям.
4. При обнаружении ошибок — сообщение об этом.
Самое сложное из этого и при том ценное, на мой взгляд, — эго сформировать спи-
сок тестовых сценариев (тест-кейсов). Суть его сводится к описанию того, что
планируется проверить и в каких условиях.
Естественно, сценарии составляются на основании требований, однако инженер по
тестированию должен знать, как работает приложение в целом. Например, для не-
которых продуктов крайне важны вопросы обратной совместимости. В сценариях
использования пункты, связанные с обратной совместимостью, могут отсутство-
вать, однако тестировщик должен их проверить.
Слабые тестировщики составляют тестовые сценарии согласно сценариям исполь-
зования: один к одному. Сколько пользовательских сценариев аналитик придумал,
столько тестовых сценариев тестировщик и написал. Согласитесь — работа не
пыльная, но и не ценная Ее может и должен делать разработчик. Задача же инже-
нера по тестированию состоит в том, что он должен проверять не только основные
сценарии, составленные аналитиком, но и другие важные сценарии.
♦ Корнер-кейсы (comer case) — это проверка поведения системы в крайних значе-
ниях или в редких случаях.
Классический пример — проверка длины пароля. Предполагается, что пользова-
тель может задать (например, для почты) очень короткий пароль. Такой пароль
легко подобрать перебором. И в требования часто закладывается ограничение по
минимальной длине пароля. А вот длину максимального пароля иногда не огра-
ничивают: ну какому нормальному человеку придет в голову задавать слишком
длинный пароль? А вот злоумышленник может так сделать с целью «сломать»
систему или просто навредить. Маловероятно, что аналитик, описывая требова-
ния к паролю, укажет в нем ораничение максимальной длины, скорее, вы уви-
дите требования к заглавным и прописным буквам, специальным символам,
цифрам. Поэтому проверять достаточно длинные пароли будет тестировщик.
♦ Негативные (отрицательные) сценарии — я бы сказал, что это поведение сис-
темы, когда что-то идет не так или не по плану Вспомним пример с кодом входа
в мобильное приложение:
• положительный сценарий — успешный ввод корректного кода. Такой сцена-
рий пишет аналитик, и очевидно, что он должен быть в требованиях;
• альтернативный сценарий— неверный кол входа. Такой сценарий тоже пи-
шет аналитик — это нормально, что пользователь ошибается, в этом и смысл
проверки. И такой сценарий должен быть в требованиях. А еще в требовани-
ях должен быть сценарий, учитывающий, что пользователь вводит код не-
верно не один раз, а несколько. С условием, например, блокировать работу на
30 минут, если код введен неправильно три раза;
• отрицательный сценарий — пользователь не вводит никакого кода и нажима-
ет «Ввод». Такой сценарий аналитик описывать не станет — это задача тес-
тировщика; найти такой сценарий и провести на него проверку. Какое, по
вашему мнению, ожидается поведение? А теперь откройте какое-нибудь мо-
бильное приложение на своем смартфоне, где есть код, и посмотрите приме-
нимость такого сценария
Закончить раздел про сложность тестирования хотелось бы старым анекдотом из
Ишернега.
Тестировщик заходит в бар и заказывает'
— кружку пива,
— 2 кружки пива;
— О кружек пива;
— 9999999999 кружек пива;
— ящерицу в стакане;
---1 кружку пива;
— йцукен кружек пива
Первый реальный клиент заходит в бар и спрашивает где туалет Бар вспыхивает
пламенем, все погибают.
13.2.2. Что делать, если задачу нельзя проверить в тестовой среде?
Рассмотрим интересный случай — задачу нельзя проверить на тестовой среде. Во-
прос: что делать в такой ситуации?
Очевидный ответ — не брать такую задачу в разработку. И он правильный. Еше на
этапе разбора задачи команда уже должна знать, как ее протестировать. И если
проверку нельзя провести на тестовой среде — надо будет сделать ее на среде про-
дуктивной. Многие члены команды разработки вздрогнут от такого предложения.
Поэтому допустимы альтернативные варианты тестирования:
♦ действительно на продуктивной среде — при enterprise-разработке нужно быть
готовым и к такому;
♦ на эмуляторах (заглушках)— необходимо заложить дополнительное время на
разработку таких эмуляторов При этом следует понимать, что работа на эмуля-
торах гарантированно отличается от работы в реальной жизни То есть на эмуля-
торах всё будет работать, а в жизни — возможно — нет.
Но иногда бывают ситуации, когда задачу нет возможности проверить силами ко-
манды разработки.
В этом случае еще на этапе разбора задачи обговаривайте, где будет производиться
тестирование и чьими силами. В крайнем случае это может быть продуктивная сре-
да и клиент. И сразу надо озаботиться тем, как opi авизовать передачу проблемных
сценариев, логов к ним и другой полезной информации, которая позволит испра-
вить возникшие замечания.
Совет новичку
Хороший тестировщик ценится не столько за умение находить баги в очевидных мес-
тах, сколько за способность предвидеть, как функциональность задачи будет исполь-
зоваться и с какими ограничениями, а также за знание предметной области и специ-
фики продукта. Например, его поведение при наличии «плохого» Интернета, желания
псльзователя попытаться обмануть продукт или найти в нем дыру И за понимание
сочетаемости функций в продукте
13.3. Формирование тест-кейсов,
чек-листов и работа с ними
При ручном тестировании достаточно много рутины: сценарии нужно проверять,
находить ошибки, исправлять и снова перепроверять.. Если нашлась ошибка, и раз-
работчик ее поправил, то он мог сломать что-то другое (та самая регрессия), а от-
сутствие автотестов может привести к тому, что придется всё перепроверять рука-
ми. Эта работа требует терпения, и бывает, что в рутине можно что-то забыть.
Чтобы такого не происходило, существуют тест-кейсы и чек-листы.
Наблюдение
Хорошей проверкой на уровень зрелости компании является наличие в ней требова-
ний и стандартов по тест-кейсам и чек-листэм. Если тестировщики проверяют без них,
то это незрелая компания (может быть, стартап), если же в компании имеется четкая
иерархия и требования к тест-кейсам, то это уже более зрелая IT-компания.
13.3.1. Тест-кейсы
Тест-кейс — это один конкретный тестовый сценарий, который позволяет прове-
рять один кейс (одну ситуацию). Его структура должна содержать название, на-
чальные условия (что и где включено и как настроено), конкретные шаги и резуль-
таты.
Рассмотрим пример с аутентификацией по ПИН-коду:
♦ Название: успешный вход в мобильное приложение по ПИН-коду.
♦ Начальные условия:
• есть доступ в Интернет;
• установлено и настроено мобильное приложение;
• установлен пин-код для входа 1432.
♦ Ша] 'и и резул ы аты:
• от крываем мобильное приложение;
• открывается страница с пин-кодом (скрин);
• нажимаем цифры пин-кода 1432;
• успешная авторизация по пин-коду;
• открытие главной страницы (скрин).
Как видите, тестовый сценарий, или, он же, тест-кейс (его пишет ручной тести-
ровщик), очень похож на сценарий использования (его пишет аналитик). Однако
тест-кейс более компактный (скорее атомарный) и более конкретный (содержит
конкретные данные).
Обычно один сценарий использования распадается на несколько тест-кейсов. Тест-
кейсы в первую очередь используются ручными тестировщиками для проведения
проверок, а также гестировщиками-автоматизаторами для написания автотестов по
уже готовым сценариям. В этом случае автотест— это программная реализация
тест-кейса.
Совет новичку, не являющемуся тестировщиком
Несмотря на то, что тест-кейсы используются в первую очередь QA, не будет лишним
спросить у команды, имеют ли они какую-нибудь систему для ведения тест-кейсоЕ и
можно пи ознакомиться с тест-кейсами. Разработчик может найти □ них полезные ма
териалы о том. как настроить какую-либо функциональность. Аналитик— посмотреть
в них интересующие его сценарии, если не понимает, как работает система, или ему
просто интеоесно узнать, какие вообще бывают сценарии Технический писатель —
найти информацию о том, как работает система. Кроме того, тест-кейсы очень полез-
ны также и для новых тестировщиков, которые только пришли в компанию, — если
гест-кейсы ведутся по приведенным ранее правилам, то вход, адаптация и погруже-
ние в работу будут происходить быс’рее
В России тест-кейсы — это материал не только для тестировщиков и команд разра-
богки, а для всей компании и даже для заказчиков Так. некоторые заказчики тоже
готовы изучать тест-кейсы, написанные в компании, и просят делиться с ними их
материалами, чтобы понять, что мы могли пропустить, или, напротив, взять что-
либо из них себе на вооружение. А некоторые даже требуют показать наличие тест-
кейсов
Совет новичку
Для согласования с заказчиком обычно используются сценарии использования, а не
тест-кейсы, поэтому, если их не просят, не над: пытаться их навязать. Кроме того,
помните, что сценарии использования пишутся до начала реализации, а тест-кейсы —
уже на основании сценариев использования
И еще один интересный момент. Тест-кейсы реально описывают го. как система
работает. Поэтому, если у вас нет документации, но есть тест-кейсы, вам крупно
повезло — на основании тест-кейсов можно написать документацию.
Итак, тест-кейсы— это полные тестовые сценарии, содержащие все необходимые
данные. Однако выделяют еще и вторую сущность, которую тоже часто использу-
ют в тестировании, — это чск-листы.
13.3.2. Чек-листы
Чек-лист— это список того, что необходимо проверить без детального плана.
В чек-листе нет подробного описания каждой проверки, и он уже может показаться
не столь полезен, особенно новичкам. Однако это не совсем так. В чек-лист вклю-
чают важные проверки, которые нужно не забыть.
Наверняка вы используете чек-листы в повседневной жизни: список покупок (хлеб,
молоко, яйца)— это классический пример чек-лисга. В нем обычно не пишут-
«Хлеб ржаной фирмы "Веселый хлеб’’ весом 300 г» — это обычно понятно. Чек-
лист в тестировании может выглядеть гак:
♦ проверка на вход с корректным пин-код ом;
♦ проверка на вход с некоррекгным пин-кодом;
♦ проверка на вход с биометрией;
♦ проверка двух факторов.
Однако чек-лист может быть также достаточно универсальным и включать не толь-
ко функциональные проверки, но и другие варианты проверок. Приведу несколько
примеров.
♦ Пусть команда разрабатывает и мобильную, и веб-всрсию продукта. Нормаль-
ной практикой будет включить в чек-лист следующие проверки:
• проверка на Android;
• проверка на iPhone;
• проверка в Chromium;
• проверка в Safari;
• проверка в MS Edge.
♦ Чек-лист дчя тестирования веб-приложений может состоять из такого списка:
• функциональное тестирование;
• тестирование производительности;
• тестирование удобст ва и спол ьзования;
• тестирование совместимости (список из предыдущего примера — это пример
списка на совместимость);
• тестирование безопасности.
Чек-листы полезны абсолютно всем, даже опытным тестировщикам. Более того,
чек-листы полезны и аналитикам Они позволяют не забыть важные сценарии ис-
пользования, потому что в них включаются пункты, которые надо не забыть опи-
сать Я привел здесь всего лишь пару вариантов, но реальные чек-листы могут быть
большими
13.3.3. Системы управления тестированием
Для работы с тестовыми сценариями, чек-листами, их наборами и комбинациями
используются также специальные системы для работы с тестовой документаци-
ей — системы управления тестированием, СУТ (Test Management System, TMS).
В России есть свои достойные разработки, которые позволяют удобно покрывать
основные потребности тестировщиков. Стартапы могут использовать для хранения
документов и Excel-таблички, что не очень удобно для тест-кейсов, но для чек-
листов вполне подходит.
Совет новичку-тестировшику
Если вы тестировщик, то вопрос о том, какая СУТ используется, должен возникнуть
еще на этане собеседования в компанию. Если вам скажут, что никакую СУТ не ис-
пользуют, то стоит расспросить о причинах этого Может быть, вы будете первый, кто
ее станет внедрять.
Более того, при использовании СУТ можно посмотреть даже то, что делал конкрет-
ный тестировщик, — проверил ли он какой-то сценарий и нашел ли ошибку.
Профессиональные тестировщики используют не просто тест-кейсы или чек-листы,
но умеют формировать из них тестовые отчеты, наборы и другие артефакты, назы-
ваемые тестовой документацией. Если вы работаете в компании, где беспокоятся
о качестве продукта, то у вас должна быть хорошая тестовая документация, понят-
но оформленные для новичка тест-кейсы и заполненные чек-листы.
13.4. Автотесты: мифы и реальность
Сколько раз мне приходилось слышать разные мифы про автотесты: и что автотес-
ты полностью заменяют ручное тестирование, и что автотесты сразу находят все
баги, и что автотесты можно сделать за то же время, что и выполнить ручную про-
верку, и что автотесты решат все проблемы с качеством продукта. На них возлага-
ются огромные надежды, и кто только не считает их «серебряной пулей». Но авто-
тесты — это долго и дорою. Чтобы понять, что это лишь мифы, необходимо пони-
мать, как в принципе работают автотесты.
Совет новичку
Ожидания должны соответствовать возможностям компании. В России отношение к
автотестам часто полярное: от «автотесты — это дорогая игрушка, они ничего не на-
ходят» до «напишем 100% покрытие и будем жить спокойно». Истина, как всегда, по-
середине.
Бюджет— главный враг автотестов Многие заказчики воспринимают автотесты
как ненужную статью расходов, результат которой нельзя увидеть и ощутить. Зада-
218 Часть IV. Участие специалистов нетехнических ролей в разработке программных продуктов
ча компании— объяснять их ценность на языке снижения рисков и экономии в
долгосрочной перспективе.
Чтобы написать хотя бы один автотест, необходимо иметь готовое окружение, на
котором этот автотест будет работать. Окружение— это то, на чем тест (не обяза-
тельно автоматический) будет запускаться. Например, если говорят, что в компа-
нии создано «тестовое» окружение, это значит, что в ней развернуты некие серви-
сы — возможно, база данных, и другие компоненты, необходимые для работы при-
ложения. В этих сервисах должны иметься определенные настройки, в базе должны
лежать нужные данные и т. п. Создать такое окружение иногда очень непросто —
проверяемых действий может быть весьма много, кроме того, могут быть задейст-
вованы визуальные интерфейсы: формы ввода, кнопки, выпадающие списки и т. п.
При этом, если вы работаете с БД, то необходимо каким-то образом добавлять в нее
данные. Если в продукте предусмотрены визуальные элементы (из визуальных
элементов состоят визуальные интерфейсы, упомянутые ранее), то необходимо как-
то научиться работать с ними: вводить данные, выбирать значения, нажимать кноп-
ки и т. п. Если у вас есть источники конфигурации (например, файлы), то их надо
правильно менять. Если есть хранилище секретов, то с ним тоже нужно работать.
И так далее.
И если работа компонентов бэкенда хоть и разнообразна, но обычно допускает
серьезную автоматизацию, то с фронтендом не всё так просто. Разработчики, соз-
давая новый продукт, часто не задумываются о его пригодности к автоматическому
тестированию. Это в дальнейшем вызывает серьезные проблемы. Дело в том. что
автоматизировать проверку того, что видит пользователь приложения, зачастую
довольно сложно. Отступы, шрифты, дизайн и всё такое прочее человеку увидеть
легко, научить же «робота» выявлять подобные неточности весьма трудно. Например,
если элементы «наезжают» друг на друга, то человек это сразу заметит, а «робот»
может пропустить — ему главное, чтобы они на форме присутствовали. Снимать
скриншоты практически бессмысленно любое изменение потребует переделки, а
это новый скриншот. Кроме того, компоненты визуализации — относительно дру-
гих функций — работают достаточно медленно, особенно если дизайнером преду-
смотрена еше и анимация.
В итоге получается, что подготовить тестовое окружение иногда бывает значитель-
но сложнее, чем написать первый тест. Такое бывает практически всегда.
Возьмем, например, наше тестовое мобильное банковское приложение, которое
проверяет пин-код. Чтобы написать автотест, необходимо следушее:
1. Выделить ресурсы — сами хосты, скорее всего, виртуальные.
2. Выполнить сборку сервисов и их deploy на тестовые хосты.
3. Выполнить настройку сервисов, включая БД.
4. Завести где-то в наших сервисах необходимого пользователя.
5. Научить стороннее приложение нажимать на кнопки.
6. Научить стороннее приложение обрабатывать ошибки.
И это мы еще не написали ни одного теста, а .тишь подготовились к работе, органи-
зовав тестовое окружение.
И хочется теперь — на примере функциональных автотестов — вернуться к вопро-
су разработки через тестирование (TDD). Подготовка в целом любого окруже-
ния — это время, а значит, разработка через приемочное тестирование может и бу-
дет серьезно осложнена, если вообще окажется целесообразна. Можно упро-
стить — сделать снапшоты настроек (снапшот — это снимок ситуации, то есть
состояние, к которому можно будет вернуться, восстановив из снапшота, — что-то
вроде сохранения позиции в компьютерной игре), чтобы быстро поднимать тесто-
вое окружение. Но тогда необходимо понимать, ио каким критериям эти снапшоты
будут создаваться и пересоздаваться. Хотя это вполне рабочая схема.
Может показаться, что я вообще не сторонник автотестов. Конечно, это не так — я
считаю их необходимыми и крайне важными, особенно в коммерческой разработке,
когда мы готовы сделать регрессионное тестирование.
С каких автотестов начать, если у вас их нет, но вы очень хотите, чтобы они были?
Не стремитесь к 100% покрытию, особенно если у вас вообше нет автотестов. Нач-
ните с самого важного:
♦ критичный для бизнеса сценарий — например, расчет кредита или формирова-
ние отчета для налоговой;
♦ часто ломающаяся функциональность — та, на которую больше всего жалоб от
пользователей, или где совершается больше всего ошибок;
♦ ядро продукта — это то, без чего продукт не работает (например, авторизация
через ЕСИА/1 осу слуги).
13.5. Участие в приемочном тестировании
В главе 11 уже шла речь об участии в приемке. Этот раздел гоже связан с прием-
кой, но его материал следует рассматривать именно с точки зрения приемочного
тестирования. Команда может быть уверена в том, что сделала качественный про-
дукт, но пока его не приняли, работа не считается выполненной.
Приемочное тестирование (User Acceptance Testing, DAT)— это момент, когда
готовый продукт проверяет не команда разработки, а конечный пользователь или
заказчик. В России в связи с этим чаще всего ожидают появления заполненного ак-
та приемо-сдаточных испытаний Ваша задача как специалиста, если вы являетесь
участником приемочного тестирования, — обеспечить, чтобы этот процесс прошел
гладко и продукт был принят без замечаний.
Достаточно часто приемочное тестирование организовано так. что в него входят
представители обеих сторон, совместно выполняющие все работы
Цели приемочного тестирования:
♦ подтвердить, что система решает бизнес-задачи заказчика;
♦ убедиться, что продукт соответствует договору/ТЗ (иногда — госконтракту);
♦ выявить расхождения между ожиданиями заказчика и их реализацией в продук-
те до его запуска в промышленную эксплуатацию;
♦ получить формальное подтверждение (акт) для получения оплаты.
Наиболее распространенные форматы:
♦ формальное приемочное тестирование (характ ерно для госзаказчиков и крупных
предприятий).
Проводится по протоколу испытаний, возможно, с привлечением комиссии. Ре-
зультат — подписанный акт приемки;
♦ бета-тестирование с ограниченным кругом пользователей (для SaaS^crapranoB)
Например, запуск новой версии мобильного банка для сотрудников банка и их
семей;
♦ пилотная эксплуатация (аналог предыдущего пункта, когда нельзя выделить
круг пользователей в продукте).
Например, запуск продукта в одном департаменте, филиале, отделе или любой
другой структурной единице заказчика перед полным внедрением.
Типовой сценарий проведения приемочного тестирования:
1. Вступительное слово: обсуждаются цели, правила, сроки. Важно зафиксировать
состав комиссии.
2. Самостоятельная работа пользователей: заказчик выполняет сценарии. Вы нахо-
дитесь на связи для оперативных вопросов.
3. Ежедневныс/ежснедельные стендапы: короткие встречи для обсуждения про-
гресса и блокеров.
4. Финальное совещание: подведение итогов, обсуждение списка замечаний, опре-
деление статуса приемки.
13.5.1. Фиксация замечаний
Нельзя позволять заказчику просто говорить «здесь ошибка». Используйте специ-
альную форму № и название сценария, шаг, ожидаемое поведение, фактическое
поведение.
Управляйте ожиданиями заказчика:
♦ Если найдена блокирующая ошибка (система не работает) — немедленно сооб-
щите команде. Возможно, тестирование придется приостановить.
♦ Если замечание не по ТЗ (хотят, чтобы кнопка была другого цвета) — фикси-
руйте его как предложение на доработку (Change Request). Объясните, что это
может повлиять на сроки и бюджет
♦ Не спорьте с пользователем Ваша роль — зафиксировать его восприятие.
Итоговые документы:
♦ Протокол испытаний — фактический документ с результатами протона всех
сценариев.
♦ Акт о выявленных замечаниях (или «Лист замечаний»)— официальный пере-
чень недоработок.
♦ Акт приемо-сдаточных испытаний — главный юридический документ. Подпи-
сывается, когда критические замечания устранены и заказчик согласен принять
продукт. Часто включает приложение со списком сценариев и результатами их
выполнения.
13.5.2. Типичные риски и проблемы
♦ Заказчик пытается проверить то, чего нет в 3'3, и выставить это как блокирую-
щее замечание.
• Действие: четко очертите рамки приемочного тестирования. Всегда имейте
под рукой согласованное ТЗ.
♦ Неготовность заказчика: нет выделенных пользователей, нет времени на тести-
рование.
• Действие: своевременно внесите в договорЛтлан обязательства заказчика по
участию в приемочном тестировании. Пусть он назначит со своей стороны
ответственного координатора.
♦ Проблемы с окружением: стенд работает медленно или не работает, нет тесто-
вых данных.
• Действие: проведите за день до приемочного тестирования полный прогон
сценариев силами своей команды.
♦ Юридические проволочки: заказчик тянет с подписанием акта, даже если всё
работает
• Действие: используйте для арзументации промежуточные акты о выполнении
этапов или протоколы о готовности. Четко фиксируйте даты и результаты.
Финальный совет новичку
Гпэвная задача успешной приемки — сделать так, чтобы заказчик сам пришел к выво-
ду, что система работает и полезна. Будьте максимально прозрачны и открыты, доку-
ментируйте каждый шаг и помните, приемочное тестирование— это финальная со-
вместная работа перед тем, как продукт начнет приносить реальную ценность.
- Глава 14-
Качество и документация
Тестирование программного обеспечения используют для того, чтобы продукт был
качественным, то есть чтобы в нем не было ошибок, и он соответствовал требова-
ниям. Однако качесз во ПО — вопрос гораздо более широкий, чем тестирование.
Тестирование — это лишь контроль качества (Quality Control). А само обеспечение
качества (Quality Assurance) — это меры, направленные на то, чтобы его обеспе-
чить.
В аналогии с работой ресторана можно сказать, что контроль качества (тестирова-
ние) — это работа повара, который пробует блюдо перед подачей или проверяет, не
подгорело ли оно. Если блюдо плохое, он отправляет его на переделку. Но это не
мешает повару ошибиться снова.
Обеспечение качества— это работа шеф-повара и управляющего, которые создают
условия, чтобы блюдо изначально не могло получиться плохим (или значительно
снижают вероятность этого).
В частности, это следующие действия:
♦ выбор только свежих продуктов (анализ требований);
♦ заточка ножей и настройка оборудования (подготовка инфраструктуры и инст-
рументов);
♦ создание четких технологических карт и рецептов (стандарты разработки):
♦ обучение персонала, контроль соблюдения стандартов и чистоты на кухне (ор-
ганизация процессов).
Вопросы качества программного обеспечения — это одни из самых сложных во-
просов. с которыми приходится сталкиваться. Существует несколько проблем, свя-
занных с обеспечением качества.
Каждый видит качество по-своему, и поэтому нет единой универсальной метрики:
для кого-то это число ошибок, для кого-то затраты, кто-то смотрит на цену сопро-
вождения или риск полной остановки. Даже деньги, на языке которых .любит гово-
рить бизнес, не являются прямым показателем качества. Затраты в обеспечение ка-
чества тяжело соизмерить с результатом этих вложений. Можно вкладывать огром-
ные средства и силы, но нс получить абсолютно качественный продукт. Но и
обратное тоже неверно: нельзя ничего не делать и иметь качественный продукт.
К тому же затраты в качество — это в некоторых случаях снижение скорости раз-
работки, лежащее в основе противостояния между качеством и скоростью постав-
ки. В России бизнесу нужно решение максимально быстро, само собой, с «хоро-
шими уровнем качества и, само собой, «чтобы подешевле», поэтому «давайте без
автотестов». Но чтобы сделать качественное решение, надо потратить силы анали-
тиков для проработки, архитекторов и разработчиков на проектирование, тести-
ровщиков на проверки. Это нельзя сделать быстро В долгосрочной перспективе
быстрые решения, которые часто хочег бизнес, чтобы получить свои бонусы, при-
водят к тому, что продукт деградирует, то есть к снижению качества для многих
пользователей.
В конце концов, качество нельзя обеспечить, только следуя четким процессам и
используя самые современные инструменты и технологии. Качество — это культу
ра и люди. Если разработчик, нарушая правила, устанавливает на продуктивный
сервер какой-то фикс по некритической ошибке и делает ситуацию еще хуже — это
не просто процессная проблема, это проблема культуры: менеджера, пришедшею к
разработчику с такой просьбой, разработчика, не подумавшего головой, и всей ко-
манды, позволившей выполнить такую операцию.
Качество — это марафон, а не спринт.
14.1. Что такое качество ПО
с точки зрения разных ролей?
Давайте для начала определимся с гем, кто и как видит понятие «качественное про-
граммное обеспечение».
14.1.1. Качество глазами пользователя продукта
Хочется верить, что продукт создается именно для пользователя. Качественный
продукт для конечного пользователя означает сумму следующих слагаемых.
♦ Удобство и простоту использования.
Продукт должен обладать интуитивно понятным интерфейсом и нс требовать
инструкций, пособий и видеообучений, чтобы начать им пользоваться.
♦ Отсутствие ошибок, которые бы мешали работать.
Особенно ра здражают ошибки, появляющиеся, когда пользователь уже проделал
какой-то длинный путь, и ему приходится начинать заново. Пли данные вообще
теряются, деньги списываются по два раза, и т. д., и т. п.
♦ Быстродействие.
Продукт должен работать быстро пользователь нажимает кнопку, и действие
тут же совершается. Если операция сама по себе долгая, то это должно быть
подсвечено, например, полосой загрузки.
♦ Полезные функции без доплаты.
Пользователь хочет, чтобы ценных и полезных функций было как можно боль-
ше, а платить за них нужно было как можно меньше. Какие попало функции мо-
гут быть ему не нужны.
♦ Скорость и качество реакции на проблемы.
Если в компании есть служба поддержки или иной помощник, то проблема
пользователя решится максимально быстро, а не будет получена отписка
А вот примеры, когда пользователь считает продукт некачественным:
♦ когда есть бесплатные или более дешевые аналоги. Например, зачем пользо-
ваться приложением управляющей компании, которая берет комиссию, когда в
любом мобильном банке эта же операция выполняется бесплатно?
♦ когда для того чтобы подать показания счетчиков, нужно подождать по не-
сколько минут, чтобы загрузились их поля ввода, а потом ввести в них показа-
ния каждого;
♦ когда после обновления приложения в нем ломается ключевая функция. Напри-
мер, перестали работать вход в приложение или ключевая операция оплаты.
Совет новичку
Всегда думайте так, как думает пользователь продукта Не должно быть значков аб-
бревиатур и других тонкостей, в которых пользователь не разбирается В целом, но-
вичкам в этом плане легче всего: взгляд еще не замылен, и посмотреть на проблему
пользователя со стороны ему легче, чем опытным сотрудникам. Пользуйтесь этим и
задавайте неудобные вопросы.
14.1.2, Качество глазами заказчика
Хорошо, когда заказчик и пользователь — это одна и та же персона. Однако для
многих сегментов это не так. Для сегмента В2В это не гак почти всегда. А зна-
чит, у заказчика будет свое понимание того, что такое качественный продукт.
♦ Соответствие согласованным бизнес-требованиям.
Зачастую заказчику не важно, что сделанная функция будет выглядеть нелогич-
но или неудобно. Если гак написано в требованиях, то гак и надо сделать. Эго
можно объяснить поговоркой: «что русскому хорошо, то немцу смерть». Не всё,
что кажется логичным разработчикам, является нормой щгя заказчика и тех, кто
стоит за ним.
Приведу пример
В требованиях написано что пароль должен генерироваться автоматически и состо-
ять только из цифр и строчных (маленьких) букв латинского алфавита Это может вы-
звать недоумение и непонимание. Но если узнать у заказчика, почему ему нужно, что-
бы было именно так. и предложить ему лучший (и белее простой) вариант, то можно
выяснить, что в используемых у заказчика клавиатурах нет кнопок <Shift> и <Caps
Lock>, а значит, там невозможно ввести прописные (большие) буквы
Совет новичку
Не пытайтесь переубедить заказчика в том что уже согласовано, без понимания корня
причины Не спорьте — может быть, причина гораздо глубже, чем зы думаете.
♦ Соблюдение бюджета и срока разработки.
Как я уже отмечал, бюджет согласуется заранее, и, как следствие, его увеличе-
ние для заказчика — это низкое качество работы всей команды, а значит, и про-
дукта Аналогично и со сроками. Если огромный проект выстроен на основании
недостаточных сроков, то можно не успеть сделать его вовремя. Или получить
штрафы от государства за то, что продукт не успели доделать для соотвеютвия
какому-то новому закону.
Совет новичку
Лучше оценить сроки пессимистично и сдать потом продукт раньше срока, чем под-
вести и не успеть.
♦ Соответствие требованиям законов и прочих обязательных указаний
Если продукт работает не так, как положено, и за это причитается наказание, то
продукт, по мнению заказчика, будет некачественным. Например, если он по-
зволяет продавать алкогольные напитки после положенного времени, что при-
водит к штрафам.
Совет новичку
Ваша задача как профессионала (хоть и начинающего) — знать о законах. Обрат итесь
к руководителю, юристу или кому-либо еще. кто разбирается в этом, и уточните, мож-
но ли вообще делать так, как предлагает заказчик Заказчики ждут, что вы проверите
их требования и скажете, можно так сделать или нельзя
♦ Оправдание вложенных средств (окупаемость инвестиций).
Продукт создается для достижения каких-либо целей и задач. Например, если
задача — снизить затраты на зарплату сотрудникам, вложив средства в аппараты
по продаже жетонов для проезда в метро, то продукт может оказаться некачест-
венным в силу того, что такие аппараты нужно обслуживать (или они будут час-
то ломаться), а их обслуживание (ремонт) обходится в большие деньги. Так что
грош цена такому решению.
♦ Продукт при покупке и сопровождении дешевле, чем у конкурентов.
При множестве минусов более дешевого продукта заказчик может купить имен-
но его просто потому, что он окажется дешевле.
Совет новичку
Смотрите, что предлагают конкуренты и на каких условиях, прежде чем сделать свое
предложение Если ваше предложение дороже, то покажите, чем выгоднее именно
ваш продукт
♦ Качественная документация.
Каждая фича имеет подробное описание, дающее возможность тратить меньше
времени на обучение сотрудников. Если документации нет или ее поступление
226 Часть IV. Участие специалистов нетехничесиих ролей в разработке программных продуктов
сильно отстает от релиза продукта, или в ней мною дыр (описанием охвачены
не все функции), то это признак низкого качества.
Совет новичку
Процесс работы нужно выстроить так. чтобы фичу нельзя было выдать вовне без до-
кументации. Меняйте в вашей трекинговой системе процессы так, чтобы можн. было
либо не закрыть задачу без документации, либо легко отследить, где она не написана.
14.1.3. Качество глазами разработчика
Если продукт, по мнению разработчиков, качественный, го состав команды будет
меняться редко, а продукт — развиваться успешнее.
♦ Архитектура продукта позволяет легко вносить изменения.
Если любое изменение приводит к тому, что команда разработки начинает стра-
дать и утверждать, что это очень сложно, значит, по мнению разработчиков,
продукт некачественный.
Совет новичку
Спросите у команды, насколько часто она попадает в среднюю оценку по задаче.
Нормально, если вам скажут, что сценки сильно отличаются от реальных усилий.
♦ Достаточное покрытие тестами.
Код должен быть покрыт автоматическими и модульными тестами для выявле-
ния ошибок. Кроме того, продукт должен быть пригоден к покрытию тестами.
Если тесты писать сложно и дорого, их мало или они нестабильны — значит,
сами разработчики считают продукт некачественным.
Совет новичку
Откровенно задавайте вопросы, что с тестами и как осуществляется регрессия.
♦ Современные инструменты, актуальные фреймворки, удобные CI/CD-инстру-
менты и понятные процессы.
Если продукт построен на современном стеке, а команда постоянно работает над
улучшением технологий, предлагает и вкладывается в автоматизацию сборки,
тестирования, обновления, то продукт качественный.
Совет новичку
Выясните уровень автоматизации и готовность команды вкладываться в нее и инст-
рументы.
♦ Удовлетворенность от задач и проектов.
Проекты должны доходить до эксплуатации. Идеально, когда можно самому
увидеть то, как работает продукт, и воспользоваться им. Если задачи разные и
интересные, сроки адекватные и дают время на исправление технических про-
блем — это хороший продукт.
Совет новичку
Можно спросить, как много членов команды поменялось за последний год, и вы пой-
мете, чю вас ждет на новом месте.
14.1.4. Качество глазами тестировщика
Несмотря на то, что тестировщики тоже входят в команду разработки, у них обыч-
но имеется свое представление о том, что такое качественный продукт. Вот основ-
ные ценности.
♦ Предсказуемость поведения и стабильность воспроизведения.
Очень неприятно, когда команда делает одну функциональность и ломает дру-
гую, совершенно не связанную с ней. Это признак неудачных решений, и если
так происходит, то ошибок появляется всё больше, и становится непонятно, как
их найти. Как следствие, продукт воспринимается менее качественным. Анало-
гично и со стабильностью если ошибка регулярно воспроизводится, то ее мож-
но устранить, а если нет — это большая проблема
Совет новичку
Узнайте у команды, как мною ошибок им удается найти в процессе работы и не допус-
тить до продакшена.
♦ Покрытие автотестами и модульными тестами.
Это прямые затраты на ручное тестирование. Если покрытие автоматическими
тестами низкое, значит, затраты на ручное тестирование возрастают, и продукт
становится проверять дольше и дороже. Это приводит к ошибкам. Всё это вызы-
вает у QA ощущение некачественного продукта.
♦ Качество процессов и тестовой документации.
Если тестовая документация ведется по правилам, хорошо составлена, структу-
рирована. и всё описано в виде тест-кейсов, а не только чек-листов, — это. по
мнению тестировщиков, признаки хорошего и качественно] о продукта.
Совет новичку
Спросите в команде о том, какая используется СУТ, как ведутся тест-кейсы и есть ли
правила и контроль
14.1.5. Качество глазами менеджера проекта
Основной вопрос, который волнует менеджера проекта: «Можно ли это сделать в
срок, в бюджет и с довольной командой?» Поэтому качество для менеджера вьпля-
дит так.
♦ Соблюдение сроков и оценок.
Как часто команда разработки попадает в сроки и в оценки, требуются ли .для
выполнения проекта переработки и нужно ли закладывать дополнительные риски.
♦ Удовлетворенность заказчика.
Если все спецификации и акты подписываются вовремя, заказчик принимает дора-
ботки в кратчайшие сроки и нс создает много замечаний, то это хороший продукт.
♦ Эффективность команды
♦ Если оценки не вызывают у заказчика удивления, не требуют объяснения, поче-
му такая большая стоимость, и при этом соблюдаются, а со временем трудоза-
траты не растут, а падают, то это признак хорошего качества.
♦ Скорость исправления.
В случае возникновения каких-либо замечаний их исправление осуществляется
в короткие сроки без каких-либо длительных и сложных процедур.
Как видите, нет универсально хорошего качества. Для каждого оно свое. Но нужно
понимать, что взаимосвязь есть. Вряд ли у продукта, в котором нет автотестов, низ-
кий уровень автоматизации и много ручной работы, вы найдете значительное коли-
чество удовлетворенных заказчиков и конечных пользователей. Это возможно
лишь при малом числе стейкхолдеров. Если же их много, команда просто не спра-
вится или выпуск релизов затянется на месяцы.
14.2. Участие в создании документации
Может показаться, что документация — эго не самая важная составляющая про-
дукта, ведь, как гласит один из принципов Agile-манифеста, «работающий продукт
важнее исчерпывающей документации». Но нужно помнить, что в том же манифе-
сте указано, что правая часть указанного принципа (здесь это «исчерпывающая до-
кументация») так же важна.
Документация бывает разного вида и используется на разных этапах жизненного
цикла. В общем случае выделяют несколько видов документации. Рассмотрим их
подробнее.
14.2.1. Пользовательская документация
Пользовательская документация— это документация для пользователя, что может
быть проще.
♦ Основные требования:
• должна быть на родном языке пользователя. В России, соответственно, на
русском языке;
• должна бьпь понятна пользователю, не иметь специфичных, незнакомых
обычному пользователю терминов и сокращений;
• должна быть удобной, простой и понятной, чтобы в ней можно было легко
найти нужную информацию. Использование изображений и видео крайне
желательно.
♦ Кто формирует?
Технические писатели или, может быть, сами команды разработки, если нет вы-
деленных техписов.
Хорошо с этой задачей справляются тестировщики, т. к. они формируют тест-
кейсы и у них есть все материалы, и аналитики, которые готовят пользователь-
ские сценарии и знают, как должна работать система
♦ Особенности
Если технические писатели описывают документацию после выпуска релиза, то,
с одной стороны, это затягивает публикацию для клиентов, т к. без документа-
ции отдавать продукт не всегда хорошо (в некоторых случаях это вообще невоз-
можно, если документация — это часть обязательной работы, без которой рабо-
та не принимается), а с другой — технические писатели повторно проверяют ра-
боту системы и могут находить в ней ошибки. Это еще один цикл проверки ПО.
Совет новичку
В новой компании первое, что пы можете оценить, — это как раз качество пользова-
тельской документации выстроены ли процессы ее написания понятна ли она вам
как новому человеку, net ко ли ее найти. Уточните, каким образом она появляется (от-
дельная команда ее делает или своя) и является ли она частью критериев готовности
по задаче.
14.2.2. Техническая документация
Техническая документация — это документация для команды разработки, которая
необходима ей, чтобы сделать фичу. Например, к технической документации отно-
сятся: пользовательские истории, требования, технические задания, документация
на API, архитектурные и технические решения.
♦ Основные требования:
• техническая документация должна иметься и должна быть актуальной —
это два самых главных принципа технической документации. Иногда коман-
ды работают по неактуальной (например, устаревшей) документации, что
всегда приводит к лишним затратам;
• внутренняя техническая документация должна создаваться на основе единых
форматов для всей команды, а лучше — для всей компании. Например, фор-
мат требований может быть принят либо в виде пользовательской истории,
сценариев использования и критериев приемки, либо в виде ТЗ по ГОСТ.
Диаграммы — в одном формате, например. BPMN1. Инструменты — единые
для всех. Абсолютно нормально, что неподготовленный сотрудник не сможет
сходу со всем этим разобраться;
1 BPMN-диаграмма — это схема, которая отображает бизнес-процессы в нотации BPMN (Business
Process Mode) and Notation). Она показывает, в какой последовательности совершаются рабочие
действия и перемещаются потоки информации.
• техническая документация должна храниться в едином пространстве в четкой
иерархии. Это может быть значительно более сложная иерархия, чем у поль-
зовательской документации, если это оправдано.
♦ Кто формирует?
Аналитики, архитекторы, другие технические специалисты.
♦ Особенности.
• Техническая документация, полученная от внешней стороны, должна быть
проверена еще на этапе аналитики — проверяется ее актуальность и возмож-
ность использования (доступность). Например, если в ней указан какой-то
метод в .API — нужно проверить, вызывается ли он и дает ли тот ответ, кото-
рый заявлен Если это не сделать сразу, то команда гарантированно потратит
время на такую проверку, и всё вернется назад на этап аналитики.
• Если происходит интеграция с внешними сервисами, то также на этапе сбора
требований следует запросить доступ к тестовому окружению и проверить,
что оно доступно! Во многих компаниях существуют ограничения (например,
закрытые порты), и если доступ не проверить, то команда не сможет выпол-
нить задачу.
• Если документация поступает от заказчика в формате ТЗ по ГОСТ, а команда
работает в формате пользовательских историй, то документацию необходимо
переработать в формат, принятый в команде и/или компании.
• Команда разработки может оставлять в виде технической документации ре-
зультаты своей работы — например, получившуюся детальную схему рабо-
ты, которая может быть полезна при доработках.
• Часть технической документации может попадать в пользовательскую доку-
ментацию. Например, описание методов АР) может быть частью и техниче-
ской, и пользовательской документации.
Совет новичку
Всегда уточняйте, какую документацию должны подготовить команды разработки,
аналитики или архитекторы по завершении работ. Это будет полезно в любой роли
Возможно, гак вы узнаете, что имение вы должны подготовить документ, а для участ-
ников команды это настолько обыденное действие, что они могут просто забыть вам
об этом сказать
14.2,3. Проектная документация
Проектная документация — это документация по тому, как идет статус проекта.
♦ Основные требования.
• гак же, как и техническая, проектная документация должна иметься и должна
быть актуальной;
• в нее включаются информация о ходе статуса проекта, текущих проблемах и
договоренностях;
• она формируется согласно определенным требованиям к документации в
компании. Однако формат может быть изменен, если заказчик требует со-
блюдения своего формата.
♦ Кто формирует?
Руководитель проекта совместно с заказчиком.
♦ Особенности.
• Проектная документация появляется раньше всего и заканчивается позже
всего на проекте. Проектный документ уже должен быть открыт даже на ста-
тусе предпроекта. Только когда подпишутся все акты и работы будут приня-
ты и оплачены, закончится существование проектной документации.
• Должен существовать реестр актуальных проектов, выполненных и отмечен-
ных проектов
• У каждого проекта должен быть условный статус (всё по плану или сроки
прошли) и перечень проблем, которые мешают движению.
• Команды разработки (программисты, тестировщики. DevOps) обычно ничего
не знают про статус проекта и не пользуются проектной документацией. Ин-
формацию о проблемах до них доносит руководитель или другой менеджер.
14.2.4. Процессная документация
Процессная документация — это документация, описываю!цая правила и регла-
менты работы в команде и компании.
♦ Основные требования.
Общих универсальных правил обычно нет. Даже внутри одной компании фор-
мат процессной документации может различаться. Например, заявления хранят-
ся на общем портале компании, и их необходимо скачать и распечатать, прежде
чем отдать А правила работы с доской команды могут быть написаны внутри ее
wik i-пространства.
♦ Кто формирует?
Сотрудники компании — каждый в своей области: команда, руководство, 1Т-отдел,
HR, поддержка.
♦ Особенности.
• Процессная документаиия компании может быть совершенно разной, создан-
ной по разным стандартам и раскиданной по разным порталам.
• Часто она нигде не зафиксирована, и ее нужно просто знать.
Совет новичку
Спросите об общих правилах в команде и компании. Записывайте то, что вам ответят.
В противном случае вы межете получить негатив— например <<Я же тебе говорил,
что заявление на отпуск сначала подписывается у непосредственного руководителя, а
потом у генерального директора!» Формируйте ЧАВО (частые запросы) для себя по-
том поделитесь ими с нсвыми коллегами.
Как видите, в создании документации принимают участие сотрудники с разными
ролями технические писатели, разработчики, руководство. Но существуют некото-
рые общие особенности, которые я бы рекомендовал соблюдать.
♦ Пишите документацию зам, где нельзя ее получить автоматически. Не надо тра-
тить время на то, что можно не делать.
• Не надо дублировать документацию на API, если ее можно документировать
из кода (речь здесь про специальные генераторы API-документации на осно-
вании кода). Не всё так можно сделать и не везде, но посмотрите, может, это
ваш случай Это касается как публичной документации, гак и внутренней.
• Документация на код должна содержаться в месте хранения кода, если это
возможно. Не используйте отдельные страницы, которые сложно найти, за-
действуйте Markdown (это специальный язык разметки текста) или другие
специальные языки разметки. Так у вас всегда будет актуальная документация.
♦ Пишите коротко и по делу, с учетом профиля того, для кого предназначена
документация. Пользователи продукта и разработчики эго разные целевые
аудитории, документация для них вряд ли будет выглядеть одинаково.
♦ Документация — это не обязательно текст, это могут быть приложенные файлы.
Например, нормально иметь приложенную postman-коллекцию в аналитике. Это
для целевой аудизории будет просто и понятно,
♦ Используйте современные инструменты, а не только doc-документы, — напри-
мер, публичную wiki-систему с легким и удобным поиском. А может быть, вы
пойдете дальше и используете подход Docs-as-Code, по которому документация
разрабатывается по тем же принципам, что и код,
Невозможно вообще обходиться без документации. Даже то, что вы помните сей-
час, со временем забудется. Чем выше вы поднимаетесь по карьерной лестнице, тем
больше вам необходимо знаний. Со временем одни знания будут вытесняться дру-
гими, и лучшим способом всё запомнить станет именно сохранение созданной до-
кументации. Не жадничайте, делитесь ею с другими сотрудниками — не надо спе-
циально что-то рассылать, если вас не просят, а просто сохраните созданные доку-
менты в публичную вики, и наверняка они кому-то потребуются. У меня самого
были ситуации, когда я находил гам через какое-го время свои же документы, хотя
совершенно не помнил, что их писал. И думал при этом, какой же я был тогда мо-
лодец, что написал их!
14.3. Работа с обратной связью от пользователей
Обратная связь от конечных пользователей — это самое ценное, что может быть,
потому что она исходит от тех, кто реально использует продукт, и к тому же она
бесплатная. Консзрукгивная, конкретная, с четкими предложениями и полезная —
в общем, та, которую никто не видел. Собирать обратную связь, затем обрабаты-
вать ее и запускать конкретные действия достаточно сложно.
14.3.1. Сбор обратной связи
Существует несколько источников того, откуда обратная связь может быть получена.
Служба поддержки
Независимо от того, продукт предназначен для компаний или для единичных поль-
зователей, всё равно все обращаются в службу поддержки: с вопросами, проблема-
ми и пожеланиями.
Особенности в России
♦ часто пользователи не звонят, а именно пишут в мессенджер или другой чат,
если он есть;
♦ если есть чат, то пользователи обычно ждут мгновенного ответа;
♦ звонок — это крайняя ситуация, когда либо не работао какая-то критическая
функциональность, либо пользователю не ответили в чате.
Идеально ввести автоматическую классификацию запросов. На основании даже
верхнсуровневого результата вы поймете, куда стоит приложить усилия.
Магазины приложений
Это характерно в первую очередь для мобильных приложений и только для сегмен-
та В2С (то есть для получения обратной связи от обычных пользователей, а не от
компаний)
В России отзывы могут быть достаточно эмоциональны, и за этим иногда сложно
найти настоящую причину того, что надо улучшить.
Необходимо отвечать на отзывы, если они конструктивны. Компания, которая от-
вечает на от зывы о своих приложениях, имее1 все шансы на то, чтобы сделать ка-
чественный и удобный продукт, который превзойдет конкурентов, хотя бы на ос-
новании того, что вы отвечаете.
Необходимо наладить работу по обработке отзывов и попытаться использовать
имеющуюся классификацию.
Каналы, чаты, соцсети и форумы
Здесь не имеет значения, каков продукт: В2В или В2С. Для некоторых продуктов
сообщество формируется спонтанно и неожиданно на каком-либо профильном пор-
тале Нужно отслеживать и их. Хорошо также давать возможность писать коммен-
тарии и использовать эмоции.
Можно попробовать применить автоматические системы щея сбора информации о
поиске упоминаний о компании. Это хорошо работает в социальных сетях.
Можно также выступать от имени компании. Туг важно не просто отвечать одно-
типно и формально — надо давать те ответы, которые покажут вас как честную
компанию, которая заботится о своих пользователях.
Формы обратной связи
Это могут быть формы на сайте или даже встроенные в сам продукт. Во втором
случае не стоит эти возможности навязывать — пользователь может захотеть оста-
вить обратную связь, но часто пользователей раздражает, когда формы возникают в
рядовых моментах. Вспомните сами о желании маркетплейса получить обратную
связь по каждой покупке.
Особенности в России:
♦ не злоупотребляйте и не навязывайте необходимость получения обратной связи;
♦ небольшая благодарность (скидка или бонус) гораздо лучше мотивирует пользо-
вателей оставлять обратную связь. Но для такой схемы нужно уметь работать с
большим объемом обращений
Давайте тем, кто обратился, обратную связь, если это возможно. И не только по
негативным отзывам. Например, если отзыв ценный и повлиял на продукт, го со-
общите об этом Возможно, этот же человек напишет еще пожелания, и вы их ис-
пользуете. Само собой, старайтесь отвечать на конструктивную критику.
Прямое интервью и тесты использования
С их помощью организуется работа по сбору7 обратной связи по какой-либо функ-
ции в продукте или другому важному изменению.
Особенности в России:
♦ сложно подобрать пользователей, которые дадут хорошую и честную обратную
связь, но иногда так бывает;
♦ хорошо работает система мотивации за участие: дополнительные баллы, пода-
рок или скидка;
♦ при таком опросе отзывы будут мягче, чем анонимные на сайте.
Это самый сложный вариант, т. к. он требует значительной подготовки (для интер-
вью нужны вопросы) и последующей обработки. Вряд ти опросы будут такими же
объемными по количеству, как оставленные в магазине приложений.
14.3.2. Обработка обратной связи
Достаточно сложно не просто собрать обратную связь, но и обработать ее таким
образом, чтобы получить из нее что-то ценное и реализуемое.
Необходимо ввести классификацию.
♦ Ошибки или проблема в программном обеспечении.
• На их основании должны создаваться задачи в трекере — само собой, сер-
висная поддержка должна иметь такую возможность, но нужно четко опреде-
литься с приоритетами. Например, даже минорная ошибка может быть по-
вышена в приоритете, если создает нагрузки на сервисную службу или вызы-
вает негатив пользователя.
• Используйте для их анализа понятия «приоритет» и «серьезность»:
° серьезность — насколько отмеченная проблема критична для продукта.
Это определяет уровень объективного влияния ошибки на систему, но не
обязательно на всех пользователей. Проблему можно квалифицировать
как серьезную, когда что-то совсем не работает;
° приоритет — насколько быстро надо исправить проблему. Это зависит от
субъективного восприятия пользователями ошибки в продукте. Приоритет
проблемы может быть установлен высоким, когда пользователи получают
от ошибки серьезный дискомфор].
♦ Предложение по улучшению или жалоба на неудобство в использовании.
• Предложения могут противоречить выбранной стратегии или концепции. Не
обязательно делать так, как хочет пользователь, — оцените целесообразность
и стоимость его реализации. Если это ценно, добавьте в бэклог.
• Необходимо, чтобы кто-то отвечал за такие запросы Часто в компаниях
предложения остаются даже не рассмотренными именно потому, что нет ме-
ханизма работы с обратной связью Такие вопросы должны решаться с руко-
водителями. Новичку одному взять на себя организацию работы с обратной
связью нереально.
♦ Вопросы по работе функциональности.
• Если много однотипных запросов по какой-то теме, то можно расширить
формат работы: снять видео, написать ЧАВО с ответом на типовые вопросы.
• В некоторых случаях можно и нужно использовать искусственный интел-
лект — например, в формате бота. В этом случае пользователь получает
практически мгновенный ответ и не отвлекает команду на типовые вопросы.
Без сомнения, каждый блок такой классификации может иметь вложенную иерар-
хию. Но нужно четко понимать, что с ней делать.
Совет новичку
Можно использовать готовый шаблон в трекинговой системе с полями которые долж-
ны быть заполнены. Например, использовать базовые поля: тип (ошибка, улучшение,
вопрос), шаги воспроизведения, ожидаемый результат, фактический результат, до-
полнительная информация (скриншот видео). Подобная схема ускорит работу, и не
надо будет уточнять детали,
Работа с негативной обратной связью
В ряде случаев обратная связь может быть негативной. Иногда это чрезмерные
эмоции — что характерно для российских пользователей. В такой ситуации нужно
действовать следующим образом.
1. Не молчать. Не стоит просто замолчать в расчете, что проблема сама исчезнет.
2. Не надо оправдывать или критиковать в ответ. Если проблема действительно
есть, необходимо извиниться и признать проблему.
3 Запросить недостающую информацию, если не хватает деталей, чтобы решить
проблему.
4. Сообщить о плане действий по решению проблемы.
Примерные от веты могут выглядет ь примерно так;
♦ «Спасибо, что сообщили Понимаем ваше разочарование, приносим извинения
за неудобства».
♦ «Чтобы мы могли быстрее решить проблему, не могли бы вы уточнить: на каком
именно шаге возникает ошибка ...»
♦ Если проблема известна: «Мы уже знаем об этой проблеме, исправление выйдет
в обновлении . Предварительный срок выхода ...»
♦ Если новая: «Мы передали информацию разработчикам, они изучают проблему.
Дадим ответ в течение грех рабочих дней».
Совет
В России особенно ценится человеческое отношение Даже стандартный ответ, но
написанный живым языком, а не копией из инструкции, может сильно изменить вос-
приятие.
Особенности обратной связи при работе с бизнес-заказчиками
Для сегмента В2В есть свои особенности, которые надо знать, особенно новичку
♦ В некоторых случаях нужна формальная обратная связь - ответ в чате может не
подойти, иногда нужен официальный ответ письмом на бланке или в протоколе
совещания
♦ Так как пользователь и заказчик — это разные люди, то можно получить жалобу
не от заказчика, а от его коллег или подчиненных. Например, жалоба может зву-
чать так: «После перехода на новый продукт скорость работы отдела замедли-
лась». Для решения такой проблемы переходите от эмоций («замедлилась») к
конкретным цифрам, которые можно измерить. Установите их и договоритесь о
разумном пороге, когда вы и заказчик будете считать, что проблема ушла.
В противном случае вы станете бесконечно решать проблему за свой счет.
♦ Следует разделять обратную связь на ошибки и новые требования. Некоторые
представители заказчика могут попытаться (даже не специально) сразу накидать
по продукту новых пожеланий или просто утверждать, что пользоваться им не
удобно. Бездумное выполнение таких пожеланий может привести к тому, что
заказчик посчитает, что теперь вы всегда будете ему должны, и начнет требо-
вать решений там, где это не планировалось. Действия должны быть четкими:
ошибки исправляются бесплатно в рамках обязательств, все новые требования,
которые не предусмотрены ТЗ. должны решаться через дополнительные запро-
сы на изменения (Change Request) и оплачиваться отдельно.
Какие ошибки новичку совершать не нужно?
♦ Игнорировать негативную обратную связь или удалять негативные отзывы.
Будьте честны и не пытайтесь скрыть негатив, если он есть. Это как двойка, ко-
торую вы пытались когда-то скрыть от родителей, — ничего хорошего не полу-
чится.
♦ Не надо обещать то, что не будет сделано вовремя. Распространенная практи-
ка — пообещать и потом озадачить команду с формулировкой «мы уже пообе-
щали» В такой ситуации доверие будет потеряно
♦ Собирать информацию, но ничего не делагь. Если возникла идея собрать обрат-
ную связь, а потом ничего с ней не делать, то лучше и не начинать. Пользовате-
ли поймут, что отзывам никто не уделяет' внимания, и мнение о продукте только
ухудшится.
♦ Принимать обратную связь на свой счет. Если это первый ваш продукт, и руга-
ют функцию, которую вы сделали, то не принимайте это как личную обратную
связь. Если вы действительно сделали неудачное решение, го обработайте об-
ратную связь и сделайте продукт лучше. Если же никакой конкретики нет, а есть
просто эмоции «мне не нравится», то будьте профессионалом — не обижайтесь
и не критикуйте.
- ЧАСТЬ V-
ИНСТРУМЕНТЫ IT-КОМАНДЫ
И ПРОФЕССИОНАЛЬНОЕ РАЗВИТИЕ
СОТРУДНИКОВ
- Глава 15-
Базовые инструменты
Разработка ПО похожа на строительство и ремонт — тут есть этапы проектирова-
ния, реализации, проверки и сдачи работ, а также гарантийные обязательства.
Вряд ли ремонт делает один человек (хотя и такое бывает— прост о медленно),
обычно это бригада из специалистов разных профилей; штукатур, маляр, плиточ-
ник и т. п. В бригаду могут входить 2-3 человека с одним профилем, но вряд ли
больше. Ведь если специалистов много, то они мешают друг другу, даже если за-
нимаются разными задачами: один плитку кладет, а другой штукатурит, сантехник
проводит канализацию, а электрик делает разводку. Почему мешают? У них есть
зоны пересечения — общие зоны влияния и потребления: инструменты путаются, у
кого-то пыльные работы, а кому-то пыль категорически сейчас мешает, кому-то
воду отключить нужно, а кому-то электричество.
В разработке ПО аналогично. Если команда состоит не из двух человек, то они друг
другу начинают мешать, даже если выполняют разные задачи. Почему? У них тоже
есть зоны пересечения —- общие зоны влияния. Это куски кода, которые пересека-
ются, даже если задачи разные, — это просто неизбежно.
И если на ремонте квартиры вопрос решается последовательной работой нескольких
специалистов, просто мест приложения сил у них. должно быть достаточно много,
тогда простоя ни у кого не будет, то в разработке ПО такой вариант не устраивает —
тут один код, который постоянно меняется. С другой стороны— у команды разра-
ботки и возможностей иногда больше, и есть свои хитрости, приемы и инструменты
Многие базовые инструменты в разработке созданы для того, чтобы работать сразу
командой И хотя базовые инструменты ориентированы прежде всего на разработ-
чиков, я рекомендую и нетехническим специалистам изучить эту главу Во-первых,
это поможет вам лучше понимать профессиональный язык команд, а во-вторых,
некоторые подходы могут оказаться эффективными и за пределами чисто техниче-
ской сферы.
15.1. Инструменты совместной работы
Инструментов совместной работы IT-команд достаточно много, причем некоторым
из них не уделяется особенного внимания, и они воспринимаются командами как
само собой разумеющиеся, несмотря на го. что еще некоторое время наган подоб-
ных инструментов просто не существовало.
Далее мы рассмотрим основные вицы инструментов совместной работы, которые
используются в командах.
15.1.1. Таск-трекеры
Таск-трекеры — это системы трекинга и управления задачами, основной инстру-
мент, в котором ведется учет задач и проектов. Любая современная команда разра-
ботки использует трекинговые системы. Вот наиболее распространенные: Jira,
Trello, Яндекс Трекер, Asana, Bitrix24, Kallen, YouTrack. На первый взгляд таск-
трекер кажется простым инсфументом, ведь по сути это просто список задач с
описанием и метками. На деле же современные таск-трекеры обладают множеством
разных возможностей.
♦ Любой таск-трекер имеет возможность заводить отдельные задачи с описанием
и объединять задачи в проекте.
♦ Каждой заведенной в таск-трекере задаче присваивается настраиваемый ста-
тус — например: «В очереди», «В работе», «В тестировании», «Готово».
♦ Во многих таск-трсксрах есть возможность учитывать время (time nacking), ко-
торое планировали потратить и которое потратил конкретный сотрудник.
♦ На основании задач в таск-трекерах удобно формировать список работ, выпу-
щенных в релизе.
♦ Каждый сотрудник работает с таск-трекером и отмечает там свои результаты.
♦ У многих трекеров есть API для интеграции с другими сервисами.
15.1.2. Базы знаний
Хранить обычные файлы документов (тексты, таблицы, PDF) даже на общих дис-
ках малоэффективно в связи с тем. что поиск по их содержимому очень ограничен,
да и иерархия у них обычно отсутствует. То есть каждый такой документ полезен,
но быстро найти его по содержимому практически невозможно (или очень сложно).
Специализированные базы знаний лишены этих недостатков: они обеспечивают
сквозной поиск по всем материалам и позволяют выстраивать четкую иерархию.
В базе знаний хранится вся документация, используемая в компании. В качестве
такой базы могут выступать различные системы, приспособленные для хранения
документации, в том числе wiki-системы, расположенные во внутреннем простран-
стве компании Например: Confluence, Notion, Яндекс Вики, Bitnx24.
Идеально, когда базы знаний интегрированы с другими системами, в частности, с
трекером В таком случае удобно отслеживать то, какой задачей вызвано изменение
документации, или, наоборот, взглянув на документ, понязь, какие задачи повлияли
на документацию. Поиск в этом случае не нужен, используются прямые ссылки.
Многие компании используют комплекс инструментов для управления разработ-
кой, интегрированных между собой. Конечно, использовать связку продуктов от
одного вендора обычно чуть проще, чем совмещать инструменты разных компаний,
но конкуренты не стоят на месте, и знать их возможности весьма полезно.
15.1.3. Системы коммуникации
Это различные чаты, мессенджеры, видсовстречи. Особенных требований к мес-
сенджерам и средствам коммуникации обычно нет, но, используя их, нужно быть
внимательным Так, если чаты, как правило, не имеют значительных ограничений,
то системы видеосвязи часто в использовании весьма ограничены, — например,
имеют лимит на количество участников, и если к общению пытается присоеди-
ниться кто-то сверх лимита, то его просто не пускают.
Важно, чтобы для всей компании это был единый инструмент общения. Не может
одна половина компании общаться в одном мессенджере, а вторая — в другом, это
просто неудобно.
Идеально, если это продукт, который может быть интегрирован в ежедневный ка-
лендарь, — тогда не потребуется дополнительного времени для работы, всё будет
происходить само собой: например, из календаря можно создать встречу, и все сра-
зу получат нужную ссылку, которую не придется специально искать.
15.1.4. Системы управления кодом
и системы автоматизации
Системы управления кодом используются в первую очередь командами разработки
и подробно рассматривались ранее (см. гзаву 12), поэтому повторно здесь на них
мы останавливаться не будем.
Системы автоматизации (CI/CD)— это мошные средства, которые автоматизи-
руют ручные действия: не только сборку кода, как многие считают, но также его
тестирование и развертывание. Например, с их помощью можно организовать тес-
товый стенд буквально за несколько щелчков мыши. Системы автоматизации по-
зволяют ускорять релизы и сокращать число ошибок и ручных действий Чтобы
подготовить такие системы к успешной работе, их следует полностью настроить в
соответствии с тестовыми данными. Системы автоматизации в основном исполь-
зуются именно профильными специалистами (разработчиками, тестировщиками,
DevOps), но они также могут быть популярны и у других специалистов (например,
аналитиков).
Совет новичку
Скорее всего, вам должны предоставить доступ ко всем упомянутым здесь системам.
Если же вы понимаете что вам чего-то не хватает, например, wiki, то спросите у сво-
его наставника Возможно, вам просто забыли предоставить доступы.
15.1.5. Другие инструменты командной коммуникации
♦ Календари и почта — они должны быть интегрированы как минимум между со-
бой. В идеальном случае — должна поддерживаться экосистема продуктов, ко-
торая использу ется в компании.
♦ Файлообменники — тут нужно быть внимательным, т: к. если в обмениваемых
файлах содержатся персональные данные (а они часто есть), то требуется раз-
мещать серверы на территории РФ (152 ФЗ). Файлообменники идеально интег-
рируются с системами поддержки электронного документооборота.
15.1.6. Интеграция инструмента
Сами по себе инструменты могут быть очень удобными, но ценность представляет
именно возможность интеграции их с другими системами. Даже если кажется, что
интеграция не нужна, то очень вероятно, что со временем у вас появится потреб-
ность в том, чтобы данные, хранящиеся в одной системе, были доступны из другой.
Если таких систем не две, а больше (а скорее всего, их будет больше), то вы навер-
няка захотите иметь полную интеграцию между всеми системами.
Если у вас есть желание предложить к интеграции новый инструмент, то прежде
изучите и учтите следующее:
♦ инструмент должен решать конкретную задачу или закрывать проблему На-
пример, если задачи теряются, то нужен трекер, а если требуется хранить доку-
менты, то нужна база знаний (wiki);
♦ у него должны иметься возможности интеграции с другими системами и вы-
грузке данных. Даже если вы думаете, что вам не нужна интеграция какого-либо
инструмента с другими, то запомните: со временем она потребуется. Так что
ищите сразу подходящие для интеграции инструменты;
♦ выбирайте инструменты с учетом требований безопасности, возможности опла-
ты, стоимости лицензии и сопровождения, языка (многие пользователи могут
работать только на русском), наличия мобильной и десктопной версии (обычно
нужны обе).
Следует правильно подбирать и внедрять инструменты совместной работы. Если
всё сделано правильно, то эффективность команды повышается, а количество оши-
бок из-за недопонимания снижается.
15.2. Основы работы с метриками и аналитикой
Эффективность практически любого процесса должна измеряться Идеальный ва-
риант измерений — это метрика, то есть числовая характеристика какой-либо ве-
личины. Метрики позволяют сделать картину объективной. А для ключевых мет-
рик это важно вдвойне. Используя метрики, вы сможете после внедрения нового
продукта или новой функции увидеть, как изменились его метрики Например, по-
лезно знать, что внедрение нового продукта повысило скорость обслуживания по-
сетителей на 15%.
15.2.1, Зачем в принципе нужны метрики?
♦ Они повышают объективность происходящего — вместо эмоций вы получаете
факты.
♦ Позволяют выявлять проблемы — например, снижение выручки.
♦ Позволяют принимать решение. Например, дают возможность узнать, способен
ли новый продукт повысить скорость работы и на сколько. Тогда можно будет
даже заключить с заказчиком договор, что продукт будет куплен в случае уве-
личения скорости работы на 10%.
♦ Прогноз по ситуации. Например, за счет метрик можно определить, когда на
систему происходит максимальная и минимальная нагрузка.
Метрики могут использоваться в самых разных сферах и областях:
♦ например, это могут быть бизнес-метрики, которые интересны бизнесу: доход,
средний чек, конверсия;
♦ мирики самого продукта: число активных пользователей, коэффициент возвра-
та пользователей;
♦ метрики эксплуатации и мониторинга: доступность продукта, время от клика,
пропускная способность;
♦ и даже метрики эффективности работы команды: время от идеи до появления на
рынке (Time to Market, ТТМ), количество инцидентов после выпуска релиза.
Само собой, для каждой категории метрик используются свои инструменты: неко-
торые метрики извлекаются из финансовых отчетов компании, многие метрики
приходится закладывать в продукт, а какие-то (например, метрики эффективности
команды) позволяют собирать те инструменты, что используются командами (на-
пример, трекер позволяет собирать время на задачи).
15.2.2. Недостатки при использовании метрик
♦ Чистота получения метрик
Иногда нет корреляций между действиями и метриками, хотя кажется, чго они
есть. Например, выручка заведения выросла, но не потому, чго компания вкла-
дывалась в развитие, а потому что возле этого заведения сдали новый жилой
комплекс, и количество посетителей выросло. Если при этом в компании запус-
тили какие-то активности (например, маркетинговую), то можно прийти к лож-
ному выводу о том, что активность была полезной, хотя это не она повлияла на
результат.
♦ Метрик бывает слишком много, и это мешает сделать выводы.
Лучше иметь одну метрику, но полезную, чем десять ни о чем. Многие увлека-
ются сбором метрик, и в итоге получают не работу с метрикой, а огромные дос-
ки со множеством графиков или цифр С этим сложно работать и делать выводы,
а главное — принимать решения,
♦ Метрики не используются для принятия решений.
Это тоже распространенная проблема. Некоторые очень любят собирать метри-
ки, но ничего с ними не делают. Например, видят, как меняются какие-то метри-
ки, но не планируют ничего менять. Это бесполезная работа.
♦ Мегрики подгоняются под ожидаемый результат.
Например, если ввести в Mai азине премию сотрудникам, зависящую от количе-
ства чеков, то можно увидеть как результаты неожиданно вырастут, но при этом
выручка не увеличится. Почему? Сотрудники будут просить покупателей разде-
лять покупки.
♦ Некоторые метрики сильно запаздывают.
Метрика полезна и эффективна, но принимать решение по ее результатам уже
слишком поздно. Например, в компании начинается неожиданный спад в про-
дажах. Чтобы предотвратить спад, нужно было начать действовать раньше, чем
он начался.
Как видите, с метриками можно заиграться. Потратить много сил на сбор и чистоту
метрик, но не использовать их в работе или не делать из них выводов.
15.2.3. Входные и выходные метрики
Существуют два основных вида метрик: входные и выходные.
♦ Выходные .метрики — это ценные ключевые показатели. Они фиксируют то, что
хотелось бы улучшить. Основная проблема выходных метрик в том, что они яв-
ляются запазоывающими, то есть становятся известны, только когда прошел ин-
тервал измерения. Например, выходная метрика — это количество критических
ошибок за квартал. Она показывает уровень качества, но на нее тяжело повлиять
в процессе работы. Для бизнеса классические выходные метрики — это размер
выручки или чистой прибыли, индекс клиентской лояльности (NPS), доля рын-
ка. Выходные метрики часто сравнивают с входными метриками.
♦ Входные метрики — это метрики, на которые команды могут напрямую влиять
ежедневно Их показатели предсказывают будущие результаты. Например, ко-
личество задач, покрытых автотестами, — эго пример хорошей входной метри-
ки. Она напрямую не говорит о том, что качество будет высоким (помните главу
про качество?), однако позволяет предсказать факт того, что снизится количест-
во регрессионных ошибок.
С входными метриками проше работать, потому что их легче контролировать, но
они не так важны, как выходные, которые контролировать сложнее.
Совет новичку
Начинайте с маго'о (две-три метрики), фокусируйтесь на том, что действительно важ-
но, но при этом легко измеряется (простые и понятные но ценные метрики). Исполь-
зуйте результат измерения как инструмент для принятия обоснованных решений.
В метрики, которыми Boi пользуетесь должны попасть как входные, так и выходные
15.2.4. Особенности работы в России
Если ваш продукт интегрирован с государственными системами, то метрики ис-
пользования этих интеграции (успешность, время ответа) могут быть государст-
венной тайной или регулироваться отдельными законами или постановлениями.
Поэтому до начала разработки продукта согласуйте сбор технических метрик (без
персональных данных) с юристами и службой безопасности заказчика.
Учтите, что многие заказчики (В2В) очень внимательно относятся к тому, что со-
бираемые метрики могут быть использованы третьими лицами (например, конку-
рентами). Поэтому перед сбором бизнес-метрик или метрик по продукту нужно со-
гласовать с заказчиком это решение.
15.2.5. Аналитика метрик
Недостаточно просто собрать метрики — их нужно обработать, чтобы сделать на
их основе выводы и предложения.
Метрики можно сравнивать за разные интервалы времени — например, год к году
или месяц к месяцу. Смысл этого в том, что выбирается определенный интервал и
сравнивается с т аким же, но в прошлую итерацию. Такая методика хороша тем, что
позволяет учитывать сезонные особенности. Например, повышение продаж перед
новогодними праздниками — это абсолютно понятное явление, и логично сравни-
вать этот показатель с данными за новогодние праздники предыдущего года То же
самое касается и посещения кино, фуд-кортов и других мест: на каникулах наблю-
дается рос]', а в будни — спад.
Можно проводить и анализ всплесков. Например, по метрике скорости ответа на
какой-либо сервис. Если происходит резкое увеличение времени ответа в тот или
иной интерват времени (сервер долго не отвечает), это может привести к тому, что
клиенты не будут ждать и станут закрывать приложение, то есть откажутся от ис-
пользования продукта. А это и снижение количества пользователей, и, возможно,
снижение прибыли. Если своевременно обнаружить такую проблему и исправить
ее, то можно снизить получаемый негативный эффект. Например, если бэкап сер-
вера делается не в очень удачное время, когда продуктом пользуются много посе-
тителей, го норматьным решением будет перенести бэкап на другое время или во-
обще пересмотреть этот подход.
Следует также анализировать версии продуктов — это позволяет выявлять про-
блемные места в новых версиях продукта. Например, команда в одном из обновле-
ний добавила неэффективный запрос. Это привело к тому, что пользователи пере-
стали использовать платную фичу.
Если говорить метафорически, то метрика — это лишь ответ на незаданный вопрос.
Вспомните, что «42» — это ответ на «Главный вопрос жизни, Вселенной и всего
такого» — знаменитая шутка из книги Дугласа Адамса «Автостопом по галактике».
Аналитика метрик позволяет попробовать найти тог самый вопрос.
- Глава 16-
ИИ в работе 1Т-команды
Искусственный интеллект (ИИ, AI oi Artificial Intelligence) вошел в нашу жизнь
очень быстро. Он стал использоваться в очень многих отраслях; и, конечно же, в
отрасли разработки программного обеспечения, и в смежных. В этой главе мы по-
говорим о том, где конкретно ИИ будет полезен в 1Т. а также о том, где не надо
полностью на него полагаться.
Стоит понимать, что использовать ИИ в современной работе нужно всем, как
опытным специалистам, так и начинающим Если вы яростный противник ИИ. то
помните, что специалисты того же уровня, используя ИИ, будут решать задачи бы-
стрее и даже, возможно, качественнее. Если же вы, напротив, пытаетесь решать
любые запросы через ИИ, то рекомендую обратить внимание на часть этой главы,
посвященную этическим аспектам и ограничениям.
16,1. Базовые инструменты ИИ
для автоматизации рутины
Вы должны понимать, что термин «Искусственный интеллект» очень емкий, и в
него каждый вкладываез что-то свое. Мы рассмотрим сначала базовые инструмен-
ты, пригодные для работы любого сотрудника компании, а затем перейдем к более
профильной теме использования ИИ для разработчиков.
16.1.1. Варианты использования ИИ
любым сотрудником компании
Далее приведен небольшой обзор доступных вариантов тех ситуаций, где вообще
может использоваться ИИ.
Вы должны понимать, что указанный здесь перечень не является исчерпывающим,
и каждый день ИИ всё глубже проникает в те области, об использовании его в ко-
торых раньше мы и подумать не могли.
Работа с текстом
Типовые задачи, с которыми ИИ хорошо справляется, генерация текста по описа-
нию, редактура и исправление ошибок, резюмирование и выдержка из длинных до-
кументов, перевод.
Нужно учитывать особенности использования ИИ в РФ; для конфиденциальных
данных следует задействовать российские ИИ — по крайней мере, данные не уйдут
за рубеж, а в целом лучше вообще не обрабатывать конфиденциальные данные с
помощью ИИ.
Надо обязательно проверять факты, т. к ИИ склонен придумывать их и путать
(«галлюцинировать»). Особенно это важно в работе с юридическими документами
и специфичными терминами.
Пример
Есть закон 54-ФЗ «О применении контрольно-кассовой техники при осуществлении рас-
четов в Российской Федерации», а есть фискальный накопитель (ФН), который исполь-
зуется в кассовой технике Вот пример того, как ИИ смешал одно понятие с другим, и я
получил такой результат; «После обновления перестала работать касса с ФН-54».
Тестирование
ИИ также хорошо справляется с типовыми задачами в тестировании— например, с
генерацией тест-кейсов и чек-листов, написанием скриптов для автотестов, анатизом
результатов тестов, отчетом об ошибках, симуляцией пользовательских сценариев.
Если вы используете ИИ в тестировании, то и здесь нужно учитывать особенности
работы в РФ— проверяйте сценарии на соответствие требованиям. Так, если явно
не указать, то можно получить некорректные данные — например, несуществую-
щий в России ИНН или налог, которого либо нет, либо не с той ставкой.
Помните, что для некоторых видов тестирования использовать ИИ невозможно.
Например, ИИ не пригоден для UX-тес гировани я (по крайней мере, пока) Пробле-
ма в том, что ИИ не понимаег. что такое «удобно пользователю». Например, ИИ
может написать автотест для формы, но не заметит, что кнопка «Отправить» слива-
ется с фоном.
Поиск решений
Помните также, чго ИИ можно использовать для случаев задач, в которых у вас
недостаточно компетенций или знаний. Надо только сформировать соответствую-
щий промлт и при необходимости ответить на уточняющие вопросы.
Пример
Вам нужно решить задачу оповещения пользователя ь мессенджере при изменении
какого-либо важного файла в GitHub Чтобы получить возможные варианты, вы опи-
сываете задачу и получаете варианты действий.
Совет новичку
ИИ обычно хочет сразу дать ответ, но чтобы повысить точность, зы можете использо-
вать подход, в котором в промпт добавляется примерно такой запрос: «Сначала задай
уточняющие вопросы, чтобы ответ был более корректным».
Учтите при этом, что некоторые решения мотуг быть непригодны для России из-за
санкций, поэтому промпт лучше сразу вводить с их учетом
Специфические задачи
ИИ иногда хорошо решает специфические задачи — такие как преобразование го-
лоса, распознавание изображений, составление протокола или повестки встречи,
приоритизация задач, написание деловых писем, формирование правил работы. Но
учитывайте при этом особенности работы в РФ: для некоторых запросов — напри-
мер, преобразования речи в текст (транскрибаштя аудио), — лучше использовать
российские ИИ-инструменты.
В настоящее время инструменты ИИ встраиваются во многие системы и инстру
менты — например, в wiki-систему, которую использует ваша компания. Не надо
отгораживаться от таких инструментов, они позволяют существенно сэкономить
время. Посмотрите, есть ли такие функции в тех инструментах, на которых вы за-
висаете или тратите на них много времени.
16.1.2. ИИ для разработчиков
В разработке ПО выделяют следующие элементы ИИ: модели, инструменты, вы-
числения и дополнительные технологии. Эти же элементы характерны не только
для разработки ПО, но и для любых друтих областей, где используется ИИ, однако
в разработке они проявляются наиболее ярко. Рассмотрим каждый такой элемент
подробнее.
Модели
Модели по своей сути — это сложные алгоритмы, заточенные под решение кон-
кретных задач. Примерами могут служить большие языковые модели (Large
Language Models, LLM) или диффузионные модели (Diffusion Models), специализи-
рующиеся на генерации визуального контента: изображений, видео и ЗО-объектов.
Смысл использования здесь ИИ в том, что вы можете создать конкретную модель и
применить ее для своих целей. Например, задействовать GPT для создания текста
пли Kandinsky — для генерации изображений Если проводить кулинарную анало-
гию, то это как уже готовый соус болоньезе, который нужно лишь добавить к пасте —
и блюдо готово.
Разработчики и архитекторы ПО тоже используют модели, но специализирован-
ные, — например, Claude Sonnet, DeepSeek Coder, OpenAI ol/o3, созданные именно
для того, чтобы проектировать архитектуру или работать с кодом. Они также по-
нимают команды на человеческом языке — хотя и предназначены для создания и
редактирования кода.
Инструменты
Многие пользуются ИИ и предполагают, что инструмент для работы с ними — это
обычное окно браузера (чат), в котором можно сформулировать запрос, прикрепить
файл и получить ответ Это верно, но тишь отчасти. Разработчики используют для
создания ПО специальные инструменты — интегрированные среды разработки
(Integrated Development Environment, IDE). И им гораздо удобнее, когда ИИ встроен
в саму среду разработки, — тогда процесс написания кода не разрывается на пере-
ключения между инструментами с потерей контекста. Этот вопрос решается либо
специальными платинами для сред разработки, либо специализированными интег-
рированными средами с встроенными функциями ИИ.
В отличие от обычного браузера, который хоть и может хранить всю историю пе-
реписки, но не знает всего контекста, специализированные инструменты «видят»
весь проект (и код в нем целиком). То есть обладают контекстным пониманием
всего проекта. Такой подход позволяет ИИ не просто отвечать на вопросы по типо-
вому шаблону, а ориентироваться на конкретный код и комментарии из него, а
также знать и использовать контекст программы. — то есть по факт у быть в курсе
всего тот о, что т ворится в коде. И, как следствие, генерировать код, который будет
встроен в существующую кодовую базу При этом ИИ — чтобы решить поставлен-
ную задачу— предлагает внести изменения сразу во все необходимые файлы.
И это не только код новой функции, но и дополнительная функциональность. —
например, модульные тесты. Разработчику остается только просмотреть то, что
предложил сделать ИИ.
Более того, многие инструменты ИИ позволяют перед тем, как вносить изменения,
согласовать их, то есть реально формируют план тою, что они предлагают сделать.
Задача разработчика — путем диалога с ИИ довести этот план до конкретной реа-
лизации.
Один и тот же инструмент ИИ может использовать разные модели и переключаться
между ними.
Вычисления
Крайне важно понимать, что работа модели требует вычислительных ресурсов, и
достаточно больших. Многое зависит от конкретной модели: есть относительно
простые модели, и им надо меньше ресурсов, есть сложные — они требуют больше.
Всё зависит от задачи
Для работы модели используют специальные токены — минимальные смысловые
единицы текста, кода или изображения, на которые модель разбивает для обработ-
ки входные данные. Токены также нужны, чтобы модель не обнулялась на каждый
ответ из диатота. Чем больше окно токенов, тем больше информации модель мо-
жет обработать за один раз
При выполнении вычислений реализуются два варианта работы: облачный и ло-
кальный.
♦ Облачные вычисления (Cloud).
В кулинарной аналогии — это огромная кухня или даже целое производство. Вы
отправляете туда заказ, они готовят его на своих мощных промышленных печах
и привозят готовое блюдо. Это быстро и эффективно, но каждый заказ стоит де-
нег (токенов).
♦ Локальные вычисления (Local/Edge).
Это домашняя плита и духовой шкаф (если есть). Вы скачиваете рецепт (модель)
к себе на компьютер и запускаете. Это бесплатно, и данные никуда не отправ-
ляются, но если ваша плита имеет только одну конфорку (оборудование слабое),
а духового шкафа (видеокарты) нет, то сложный пирог вы будете готовить очень
и очень долго.
Дополнительные технологии
Как вы уже, наверно, поняли, работа ИИ осуществляется с использованием специ-
фичных технологий, требующих, например, для локальных вычислений видеокарт
с мощными графическими процессорами (GPU). Можно, конечно, обойтись и
обычным процессором (CPU), но это как сравнить фирменный многопрофильный
миксер и обычный кухонный нож. Нарезать продукт можно и обычным ножом, но
миксер это сделает значительно качественнее и быстрее.
В классическом подходе, чтобы ИИ узнал о новых документах (погрузился в кон-
текст), модель нужно дообучать. Это требует использования мошных GPU, недель
работы специалистов и больших затрат на электроэнергию. При этом, чтобы сни-
зить у ИИ вероятность галлюцинаций, применяются дополнительные инструменты.
векторные БД и технология RAG (Retrieval-Augmented Generation, генерация, до-
полненная поиском);
♦ векторные БД позволяют искать решение не по точному совпадению, а по похо-
жему смыслу. Если бы в такой базе хранили продукты, то они лежали бы не по
алфавиту, а по «похожести»: острые перцы — в одном углу, цитрусовые — в
другом. В процессе поиска ответа на ваш вопрос система находит в миллионах
документов именно те фрагменты, которые подходят по контексту, даже если
слова не совпадают буквально;
♦ с использованием технологии RAG модель не просто полагается на память, а
сначала берет актуальные данные из векторной базы, добавляет их к запросу
пользователя и уже на этой основе формирует точный ответ.
16.1.3. Промпты
Теперь, когда вы примерно представляете себе, что такое ИИ в разработке, пора
перейти к практическим советам. Самое важное: вы должны уметь писать промпты
(prompts) — запросы, качество написания которых влияет на результат того, что
вам выдаст ИИ. Вот, например, пример плохого иромпта: «Напиши тест-кейсы для
логина». Хороший же промпт должен быть конкретным, с контекстом и со струк-
турой (листинг 16 1).
Роль: Ты senior СА-инженер ь крупном российском банке.
Задача: Создай подробный чек-лист для ручного тестирования формы входа в мобильное
приложение.
Контекст: Форма имеет два поля.’ телефон (в формате +7 XXX XXX XX XX) и пароль (от 8 до
2С символов, латиница-цифры) Есть кнопка «Войти», ссылка «Забыл пароль» и чекбокс
«Запомнить меня».
Требования к результату:
Перечисли позитивные сценарии (успешный вход).
Перечисли негативные сценарии (неверный телефон, неверный пароль, пустые поля, XSS-
инъекция).
Особое внимание удели российским реалиям: проверка на ввод номера в форматах 8ХХХ и
+7ХХХ, обработка случая, если SIM-карта с номером перемещена в другой телефон.
Оформи результат в виде таблицы с колонками: ID, Название сценария, шаги, Ожидаемый
результат. Приоритет (High/Medium/Low).
Ключевые элементы хороших промптов
Результат будет заметно лучше, если указать в Промпте следующие параметры:
♦ Роль, от имени которой должен быть получен результат (например, тестиров-
щик, бизнес-аналитик и т. п.)_
♦ Контекст; проект, ограничения, целевая аудитория.
♦ Четкое описание тог о, что нужно сделать.
♦ Требования к формату и структуре: текст или таблица, список, код целиком или
только кусок.
♦ Особые условия: например, учитывать законы РФ.
16-2. Использование ИИ
для анализа данных и исследований
В российской разработке решения часто принимаются на основании интуиции или
под давлением руководства, а на глубокий анализ времени порой не хватает. В таких
условиях крайне важна возможность быстро анализировать данные и проводить ис-
следования. И именно тут ИИ приходит на помощь, позволяя находить скрытые за-
кономерности, прогнозировать проблемы и доказывать гипотезы цифрами.
16.2.1. Работа с данными и аналитика
♦ Типовые задачи: анализ логов, поиск аномалий, генерация тестовых данных, на-
писание скриптов для обработки данных, визуализация и выводы по данным.
♦ Особенности использования в России: для генерации реалистичных российских
тестовых данных (ФИО, ИНН, номера телефонов) используйте запросы к ИИ с
конкретным Промптом. Например, просите четко: «Сгенерируй массив из 10 ва-
лидных по формату, но вымышленных ИНН юридических лиц».
16.2.2. Задачи анализа данных для ИИ
Искусственном}' интеллекту для анализа данных можно передавать следующие задачи.
♦ Вопросы из серии «Что произошло?».
Это описание исторических данных, поиск аномалий и отклонений, агрегация
данных. Например: «Как вчера на сайте вела себя конверсия?»
♦ Вопросы из серии «Почему произошло?» (диагностическая аналитика).
Это поиск причинно-следственных связей. Например- «Какие ошибки, отмечен-
ные в логе за последний день, могли стать причиной падения конверсии на сай-
те?»
♦ Вопросы из серии «Что произойдет?» (предиктивная аналитика).
Это прогнозирование на основании исторических данных. Например: «Какой
будет отток клиентов, если не починить ошибку в течение месяца?»
♦ Вопросы из серии «Что мы можем узнать?» (исследовательский анализ).
Это генерация гипотез на основании неструктурированных данных. Например:
«Проанализируй отзыв из магазина приложений за последний месяц и выдели
основные темы жалоб».
16.2.3. Особенности и ограничения при работе с аналитикой
Существует ряд особенностей и ограничений, которые нужно учитывать при рабо-
те с ИИ.
♦ Качество данных.
Это крайне важная характеристика для любого анализа данных, а не только для
тех. которые передаются для обработки в ИИ. Получение качественных очи-
щенных от мусора данных — это вообще сама по себе сложная задача (для очи-
стки данных тоже можно использовать ИИ, но нужно четко сформулировать са-
му задачу очистки). Так что если вы передаете данные с ошибками, то не ожи-
дайте, что произойдет чудо и вы получите точный результат.
♦ Неверные выводы.
Неверно составленные запросы могут привести к неверным выводам. Так, если
неверно задать промпт с запросом о том, какая категория пользователей пишет
больше всего жалоб, то можно получить, к примеру, информацию, что это люди
старше 60 лет. И в этом случае ИИ может посчитать их проблемными. А истин-
ная проблема состоит в неудобстве интерфейса для людей старше 60 лет.
♦ Юридические ограничения.
Помните, что персональные данные нужно сначала избавить от персональной
информации (анонимизировать — то есть удалить ФИО, телефоны и дру1ую
личную информацию). Кроме того, для части данных в принципе запрещено ис-
пользовать ИИ. а тем более задействовать зарубежные сервисы (вплоть до уго-
ловного наказания).
Надо учитывать также и то, что некоторые зарубежные сервисы, которые вы ис-
пользуете в работе, находятся в зоне риска, поскольку в любой момент могут
быть отключены на территории РФ Поэтому лучше всегда ориентироваться на
российские аналоги.
Совет для новичка
Начните с небольших экспериментов Сначала автоматизируйте подготовку одного ка-
кого-либо отчета, который вы сейчас делаете вручную. Добейтесь, чтобы ИИ готовил
для вас приемлемую сырую выгрузку и предварительные выводы. После чего интер-
претируйте результаты и добавляйте контекст (например, знание российских законов
или бизнес-процессоя в компании), а уже затем принимайте решения. ИИ позволяет
упростить обработку данных, а не делать выводы
Привлекая к работе ИИ, нужно учитывать особенности его логики и выводов, кото-
рые он делает. И лучше не говорить заказчику, что предъявляемую ему работу вы-
полнил ИИ.
16.3. Этические аспекты и ограничения ИИ
В России достаточно строгие законы, и многие заказчики — особенно государст-
венные — не доверяют ИИ. Тем более не поощряется работа с зарубежными серви-
сами. И хак следствие, использование вами ИИ может привести к юридическим
последствиям и репутационным потерям.
Привлекая к работе ИИ, вы должны тщательно следить за тем, где будет храниться
весь код проекта, и принимать меры, чтобы он не утек в сеть, тем более зарубеж-
ную. Возможные варианты — либо локальная работа, либо на серверах российских
компаний.
Многие популярные среди разработчиков инструменты могут быть запрещены для
использования в РФ — например, GiiHub Copilot, несмотря на то, что работа само-
го GitHub не ограничивается. Нужно искат ь подходящие российские аналоги, и
многие наши компании развивают такие инструменты.
ИИ может придумать то, чего не существует. Я сталкивался с таким, когда пытался
выстроить в трекере оптимальный запрос, и получал запросы, которые были син-
таксически неверны. А также получал не полностью правильные ответы при по-
пытке выяснить, как работают цепочки сертификат ов.
Совет
Никогда не следует полностью доверять ответам искусственного интеллекта Несмот-
ря на их полную убежденность в своих ответах, многие из них бывают некорректными.
Пример из жизни
Попробуйте задать нейросети два вопроса, но ь разных сессиях.
1. Начиная с какой версии Java 8 поддерживается TLS 13?
2. Поддерживается ли TLS 1 3 в Java 8?
Одна из популярных нейросетей ответила мне на первый вопрос так (короткий ответ):
«TLS 1.3 официально поддерживается в Java, начиная с Java 11».
И та же самая нейросеть на второй вопрос ответила так: «Да, TLS 1.3 поддерживается
в Java 8, но начиная с определенных обновлений».
Кстати, другая нейросеть дала по смыслу одинаковый ответ на два эти вопроса.
В работе с ИИ весьма важно учитывать необходимость понимать и проверять то,
что он создает. К примеру, при формировании SQL-запроса можно задать ему сле-
дующий уточняющий вопрос: «Почему ты использовал LEFT JOIN, а не INNER
JOIN?»
Некоторые ИИ-решения распространяются в виде плагина к IDE, и вы можете
столкнуться со сложностями при использовании их именно с той IDE, в которой
работаете вы. Да, инструмент сам по себе может быть замечательным, но лично вам
пользоваться им будет неудобно.
16.3.1. Где ИИ неприменим...
В настоящее время сфер или областей, где не используется искусственный интел-
лект, всё меньше. Однако они все-таки есть. Я опущу вопрос о том, сможет ли ИИ
делать научные открытия, а лучше перейду к тем моментам, которые актуальны
именно для разработки ПО.
♦ ИИ не обладаез критическим мышлением и, возможно, не до конца понимает
бизнес-контекст вашей компании. Он может сгенерировать красивый отчет с аб-
солютно неверными выводами.
♦ Как я уже отмечал, к некоторым видам тестирования ИИ сейчас не готов — это,
например, UX-тестирование (удобство использования).
♦ ИИ не несет ответственности (юридические последствия). Если ИИ ошибется в
расчете формулы для декларации в налоговую, то отвечать за это и переделы-
вать декларацию будете вы. а Ий может ответить вам что-то вроде «Точно, спа-
сибо, что нашел ошибку».
♦ ИИ плохо работает со свежей или с узкоспециализированной информацией.
Не спрашивайте у ИИ про вчерашнее изменение в API Госуслуг или тонкости
115-ФЗ. Информация может устареть.
Учитывайте вопросы безопасности и конфиденциальности — никогда не загружай-
те в публичные ИИ-сервисы:
♦ код с проприетарной бизнес-логикой — то есть тех продуктов, код которых не
является общедоступным;
♦ персональные данные клиентов — это прямое нарушение закона;
♦ паспортные данные, логины/пароли, ключи API и другую конфиденциальную
информацию.
16.3.2. Правила работы с ИИ
Чтобы проблем в работе было меньше, следуйте приведенным далее правилам.
♦ Границы применения:
• используйте ИИ для генерации общей структуры документа, шаблонного
текста (например, обычных писем) и при обучении на публичных (общедос-
тупных) данных;
• не используйте ИИ для принятия решений без контроля со стороны человека
и понятной человеку логики. Нельзя отдать ИИ вопросы выдачи кредитов,
собеседований, оценок и даже приоритета ошибок без контроля со стороны
человека.
♦ Алгоритмическая предвзятость.
Всегда нужно пытаться понять, нет ли в работе ИИ перекосов. Поэтому надо
найти ответы на следующие вопросы:
• Отражают ли данные для обучения всё разнообразие вашей системы (продук-
та)? Например, если речь идет о пользователях, то учтены ли регионы, воз-
раст, пол,доход?
• Дает ли ИИ статистически одинаковые результаты для разных групп? На-
пример, одинаковую точность распознавания речи для мужского и женского
голоса, для речи с разными акцентами?
• В России особенно — не заложены ли в данные искажения или несправедли-
вость9 Например, привлечение в результате некорректной работы ИИ мень-
шего количества цифровых данных о людях в возрасте старше 50 лет.
♦ Прозрачность и объясни мосты
Даже если модель сложная, вы должны уметь объяснить логику ее работы (не
математику, а бизнес-логику).
♦ Использование локальных и контролируемых инструментов.
Например, для генерации кода для вашего проекта лучше задействовать те инст-
рументы, которые можно развернуть внутри периметра компании. Так данные
не утекут в сеть.
16.3.3. Вывод
Искусственный интеллект не снимает с вас ответственности за принимаемые реше-
ния, а, наоборот, повышает ее. Если вы используете ИИ, то вам нужно быть уве-
ренным в том, что система работает безопасно и с соблюдением требований закона.
Вы должны развивать в себе не только навык промпт-инженера. но и этическую и
юридическую грамотность. Это и отличает профессионала, который использует ИИ
только когда и где надо, от любителя быстрых результатов.
-Глава 17-
Профессиональное развитие
в команде
Надеюсь, что вы успешно прошли испытательный срок и уже адаптировались. Со
временем у вас появится желание профессионального развития. Желание разви-
ваться, вероятно, возникав!, когда вы уже поняли, что понимаете все происходящие
процессы, в которых задействованы, и началась некоторая ругина. Наивно думать,
чго к вам обязательно кто-то придет и скажет: «Что-то ты засиделся на одном мес-
те, пора бы двигаться дальше». Даже если такое и происходит, то не факт, что забо-
тятся именно о вашем профессиональном росте, хотя это тоже возможно Скорее
всего, хотят, чтобы вы расширили свой кругозор для решения новых задач бизнеса.
Кроме того, важно понимать, что профессиональное развитие не обязательно свя-
зано с тем, что вам прибавят зарплату. Можно иметь прекрасные профессиональ-
ные навыки, но не уметь применять их или просто быть токсичным или не нравить-
ся руководителю.
Обращу также внимание еще на один важный момент: вы должны показать, что те
профессиональные навыки, которыми обладаете, принесли компании новую цен-
ность. Перед очень многими руководителями стоит задача удерживать фонд опла-
ты труда в определенных пределах. А значит, финансовое поощрение могут полу-
чить не все, а только те, кто доказал свою пользу для компании.
Цель этой главы — рассказать вам о том, как превратиться из новичка в востребо-
ванного специалиста. А в следующей главе мы поговорим о прохождении оценки.
17,1. Постановка целей и развитие навыков
Первое, что нужно сделать, — это правильно расставить цели. Наверняка вы слы-
шали про постановку- целей «по SMART». Буквально это означает, что цель должна
быть конкретной, измеримой, достижимой, актуальной и ограниченной по времени
(образовано по первым буквам английских слов Specific, Measurable, Achievable,
Relevant, Time-bound). Пример плохой цели: «Снизить количество критических
ошибок в продукте». Пример хорошей: «Снизить количество критических ошибок
в продукте на 50% (с 10 до 5) в течение следующего квартала (до 31 марта) путем
внедрения этапа автоматизированного тестирования при выпуске релиза».
Достаточно часто цели можно получить у своего руководителя. Они могут быть
изначально сформулированы совсем не по SMART, но тут уже всё зависит от вас.
А в некоторых случаях цели нужно сформулировать самому.
Совет
Даже если вы придумываете цели сами, io согласуйте их с непосредственным руко-
водителем Это превращает ваше личное развитие в инвестицию компании и вас. по-
вышает шансы получить бюджет на курсы или время на обучение в рабочее время.
Учтите также, что поставленные вами цели вряд ли должны включать стремление
прокачаться в каком-нибудь языке программирования. Причина здесь в том, что
бизнесу от этого нет никакой пользы. Это ошибка очень многих новичков, которые
говорят о профессиональном развитии в контексте только своего личного (даже не
профессионального) интереса. Тем не менее развитие технических навыков тоже
важно и нужно, но этого недостаточно.
На деле нужно развивать следующие навыки.
♦ Технические (hard-skills) — это основа, без нее обычно никак.
Для каждой роли — это свои уникальные навыки: для разработчика, тестиров-
щика и аналитика они будут разными. Технические навыки еще называют
«хард-скилами» (я даже встречал термин «жесткие навыки»),
♦ Нетехнические (soft-skills, «мягкие навыки»).
Навыки лидера: умение проводить встречи, презентовать продукты, вести пере-
говоры с коллегами и заказчиками, умение разрешать конфликты и управлять
своим временем (то есть попадать в оценки). Эти навыки важны абсолютно для
всех. Я уже говорил о том, что разработка— это взаимодействие в команде. Без
софг-скилов это сделать невозможно.
♦ Знания и навыки работ ы в домене.
Это уникальные знания, которые характерны именно для гой области, в которой
вы работаете. Такие навыки вырабатываются годами. Знание законов, стандартов,
требований, приказов и других документов, а также понимание бизнес-процессов
клиентов и возможность предложить решение, позволяющее решить проблему
клиента за меньшие деньги,— всё это входит в набор уникальных знаний. Такие
навыки сложно получить в компании из другого сектора. Так что, если вы имеете
опыт работы в финтехе, то он может быть бесполезен в телекоме, потому что там
свои правила, законы и стандарты, и даже категории клиентов.
♦ Бизнес-навыки.
Это навыки, которые интересны бизнесу и тем, кто работает с финансами: за
сколько окупится фича, как считается экономика команды и компании (понима-
ние бизнес-модели), работа с приоритетами и бэклогом. Они не связаны с техно-
логиями напрямую, но важны для бизнеса.
Совет
Составьте личную матрицу целей, исходя из собственных навыков и уровня Отметьте
текущий уровень ло каждому навыку (от 1 до 5) и поставьте цель на какой-либо пери-
од— напоимер, год. Сфокусиоуйтесь на усилении своих сильных сторон (делать из
хорошего — отличное) и на подтягивании совсем слабых (без которых не получить по-
вышение).
17.2. Как строить планы развития?
Итак, у вас есть цель (или цели) и понимание важных навыков. Теперь нужно свя-
зать одно с другим. Это следует делат ь через разделение цели на конкретные этапы
и задачи.
Например, цель снижения количества критических ошибок может состоять из не-
скольких этапов (приведу здесь два, чтобы вы поняли суть), задач и сроков в каждом.
♦ Этап 1: подготовка и планирование (первые 2 недели квартала).
• Задача 1: анализ текущей ситуации и выбор инструментов.
• Задача 2: разработка стратегии тестирования.
♦ Этап 2: внедрение и разработка автотестов (середина квартала)
• Задача 3: настройка инфраструктуры и среды тестирования.
• Задача 4: написание первых автоматизированных тестов.
Более того, рекомендую также расписать действия более подробно и также указать
тех, кто сможет помочь. У вас может получиться примерно такой результат
♦ Этап 1 • подготовка и планирование
• Задача 1: анализ текущей ситуации и выбор инструментов (первые 2 недели
квартала).
° Действие 1.1. Собрать и проанализировать статистику по всем 10 текущим
критическим ошибкам, зафиксировать их причины и частоту возникнове-
ния. Помощь: тестировщики команды, которые проверяют ошибки.
° Действие 1.2. Изучить рынок инструментов для автоматизированного тес-
тирования (Selenium, Cypress и т. д.). Помощь: QA-lead.
° Действие 1.3. Выбрать и обосновать один конкретный инструмент, подхо-
дящий под стек технологий продукта. Помощь: непосредственный руко-
водитель.
Удачным форматом стала бы таблица, содержащая колонку с результатом по каж-
дому действию.
Важно понимать, что подобные документы (личная дорожная карта) прекрасно от-
ражают ваш вклад в общую работу команды, особенно если содержат ссылки и ма-
териалы. Например, ссылки на задачи в трекере или материалы, которые пригодят-
ся другим членам команды. В главе 18 будет рассмотрена процедура оценки, учи-
тывающая подобные вклады сотрудников
В заключение этого раздела хотелось бы сказать об ошибках, которые часто до-
пускают.
♦ Ошибка 1. Сидеть и ничего не делать, ждать, когда вас заметят. Технологии ус-
таревают, рынок меняется Если ваш проект старый и не развивается, вы рискуе-
те остаться никому не нужным В российских компаниях часто нет выстроенной
системы обучения. Проявите инициативу сами.
♦ Ошибка 2. Пытаться использовать модные иностранные технологии, не востре-
бованные или даже недоступные в РФ Не стоит изучать то, что нельзя приме-
нить из-за санкций или отсутствия спроса.
♦ Ошибка 3. Игнорировать подготовку документации. Причем писать документа-
цию следует на 1рамотном русском языке. Умение письменно выражать свои
мысли — огромное конкурентное преимущество.
♦ Ошибка 4. Не уметь презентовать свои достижения. Учитесь фиксировать и рас-
сказывать о своих успехах на языке бизнес-ценности («сэкономил N часов ко-
манде», «предотвратил риск штрафа»),
17.3. Поиск ментора и наставничество
В России во многих компаниях выстроенные системы обучения вообще отсутству-
ют, и задача обучения часто ложится на плечи того, кто этого обучения хочет.
В самом начале пути в любой компании новичку обычно предоставляется настав-
ник. О нем я мно! о раз рассказывал. Иногда его также называют ментором.
Вам очень повезло, если ваш наставник действительно уделял вам время и был за-
интересован в вашем результате. Несмотря на то, что наставничество в России с 1
марта 2025 года официально должно оплачиваться, многие компании продолжают
работать по старинке: наставник можег быть формальный, никто с нею его работу
не снимал, а тут еще и новичок, которого надо обучать. Итог прост: новичок кру-
тится сам по себе, а наставник занят своими делами.
К счастью, так бывает не всегда, и во многих компаниях находятся отзывчивые
люди, которые делятся как своим опытом работы в конкретной компании, так и
профессиональными навыками Поиск наставника, ментора или хотя бы просто то-
варища (бадди)— эго то, что позволит быстрее адаптироваться и стать полноцен-
ным участником команды и компании.
В разд. 3.2, «Ключевые люби: к кому обращаться с вопросами?», мы уже касались
основных ролей, с которыми сталкивается новичок. Напомню, что это (помимо не-
посредственно руководителя и профильных специалистов) технический наставник
и бадди (или ментор).
17.3.1. Наставник
Это гот, кто объясняет вам внутренние процессы, показывает инструменты, отвеча-
ет на общие вопросы и помогает с первыми рабочими задачами. С ним часто уста-
навливаются формальные и относительно временные отношения (в качестве его
личною проекта) — например, только на время вашего испытательного срока.
В основном, наставник учит согласно принципу «делай как я» и предполагает ми-
нимум самодеятельности. Если вы ошибаетесь, го это ошибка в работ е наставника,
часто квалифицируемая как его недоработка.
Однако на пути врастания сотрудника в компанию одною только официально на-
значенного наставника точно будет мало, поскольку закончится адаптация, и на-
ставник перестанет им быть. Поэтому идеально найти не просто наставника, но и
.ментора.
17.3.2. Ментор
♦ Не объясняет базовые и элементарные вещи, предполагая, что вы их уже знаете
и прошли. Он предлагает решать проблемы или достигать цели.
♦ Ментор помогает сфокусироваться не на конкретных технических задачах, а,
скорее, на общем развитии (помните, что есть не только хард-скилы). личност-
ном росте и карьере, а также на решении сложных ситуаций.
♦ С ним обычно устанавливаются более длительные и часто менее формальные
отношения. Они могут быть, конечно, и формальными, но вряд ли должны за-
вершаться после официального закрытия испытательного срока
♦ Ментор часто не дает конкретных ответов на вопросы в той или иной ситуа-
ции — он часто предлагает вам самому найти решение, задавая правильные во-
просы нужным людям. Он может это делать специально, предоставляя вам воз-
можность развиваться или искать свой путь. Но может и не знать правильного
ответа, а просто направить вас на его поиск, помогая советом
♦ Хороший ментор позволяет вам ошибаться (в разумных пределах) — ведь часто
мы учимся только тогда, когда ошибаемся сами.
♦ Ментор может познакомить вас с нужными людьми, объяснить, как с кем себя
вести, и дать конкретный совет, — это отличает ментора от наставника.
Само собой, найти себе настоящего ментора весьма сложно, потому что им может
стать только опытный сотрудник компании, который часто сфокусирован на реше-
нии ее стратегических задач, — например, системный архитектор или технический
лидер. И это не обязательно будет технический специалист — в роли ментора для
вас может выступить опытный менеджер, владелец продукта или аналитик.
Совет
Ментора надо искать самому Хорошие ментопы вряд ли придут и скажут «давай я те-
бе пом згу».
Вам нужно самому понять, кто из работников компании может стать вашим менто-
ром. Часто выбор ментора — процесс неочевидный, вы можете найти его в сосед-
нем подразделении или вообще в смежной команде. Чтобы начать с ним взаимо-
действовать, просто попросите совета. Не стесняйтесь, спросите его, как поступить
в той или иной ситуации.
Если внутри компании подходящей на роль ментора кандидатуры нет, используйте
для его поиска профессиональные сообщества: мигапы, конференции и другие по-
добные мероприятия. В них тоже надо не просто сидеть и слушать, а активно участ-
вовать, задавая вопросы и включаясь в дискуссии. Этим вы можете заинтересовать
кого-либо из их участников, кто захочет примерить на себя роль вашего ментора.
Не следует исключать также социальные сети и даже специальные сайты и сообще-
ства, в которых гоже можно найти ментора. Правда, такие сети, сайты и сообщест-
ва могут быть штатными. А может, стоит обратиться к бывшим коллегам, если, ко-
нечно, у вас остались подходящие связи.
Как правильно обратиться к потенциальному ментору?
Мало найти подходящую на роль вашего ментора кандидатуру и понять, что он вам
вроде как подходит, — нужно еще выстроить с ним отношения так, чтобы он дей-
ствительно захотел им стать. Не очень хороший подход — заявить в лоб: «Я начи-
нающий специалист. Не могли бы вы стать моим ментором?». Такого рода предло-
жение может показаться ему слишком абстрактным, причем обязывающим к долго-
срочным и непонятным отношениям.
Хороший подход основан на следующем правиле: сначала конкретный вопрос, за-
тем конкретная помощь, затем предложение о взаимности.
Совет
Вы можете обратиться к потенциальному ментору письменно, нс просьба должна со-
держать в себе следующие моменты: уважение к уже выполненной им работе (напри-
мер, докладу или задаче), информацию о том, что у вас есть связанная проблема, с
которой вы пробовали разобраться, и у вас не получилось (важн» показато, что вы не
ищете легких путей, а пытаетесь разобраться сами), а затем просьбу о небольшой
помощи (например, 20 минут общения) и обещание, что вы будете взаимны и поможе-
те при необходимости.
Если ваш диалог состоится, аккуратно спросите, можно ли и в другие разы обра-
щаться за советом или помощью, но не забывайте о взаимности.
Выстраивание отношений с ментором
Есть несколько принципов, которые нужно соблюдать:
♦ Уважайте время ментора. Готовьтесь к встречам: присылайте вопросы заранее,
формулируйте проблему четко.
♦ Не просите разжевать то, что легко найти Вы должны приходить с анализом и с
действиями
♦ Принимайте критику и действуйте так. как вам советуют. Никто не убивает от-
ношения быстрее, чем тот, кто постоянно спрашивает совета, но никогда ему не
следует.
♦ Не забывайте благодарить и делиться результатами успеха. Простого «спасибо»
после встречи уже достаточно. Если ментор реально помог вам вырасти или ре-
шить проблему, то будет уместен и небольшой ему подарок.
♦ Ментор — не психолог и не друг. Не нойте и не жалуйтесь, фокусируйтесь на
профессиональном развитии и решении профессиональных проблем.
♦ Вы должны иметь собственное мнение и пробовать предлагать его. Ментор дает
советы, основанные на его собственном опыте. Ваш опыт и ситуации могут от-
личаться.
Помните, что ментор лишь ускоряет ваше развитие, но идти по этому пути должны
вы сами. Активно учитесь, делайте проекты, предлагайте свои решения. Тогда мен-
тор сможет сам в какой-то момент попросить у вас помощи и поддержки.
17.4. Участие в комьюнити и конференциях
Профессиональное развитие невозможно без взаимодействия с коллегами. Выступ-
ление на конференциях — это самый лучший вариант с ними пообщаться. По если
вы чувствуете, что выступление на конференциях — не самая ваша сильная сторо-
на, то можно участвовать в дискуссиях, просто задавая вопросы. Если и с этим про-
блемы, то нужно хотя бы пытаться понимать, чем живет 1Т-комьюнити (или, еще
говорят, «IT-сообщесгво»), принимая участие в различных обсуждениях.
17.4.1. Основные цели участия в комьюнити и конференциях
У каждого из нас свои цели, но, в обшем и целом, выделяют следующие:
♦ Развитие.
Важно понимать, какие доступные в России технологии вообще существуют и,
более того, используются у коллег, а также какие подводные камни при этом
мшут быть.
♦ Самореклама.
Выступление на докладе говорит о том, что вы развиваетесь, что вам интересно,
и некоторые компании могут захотеть иметь такого специалиста. Или хотя бы
захотят получить ваш контакт. Кроме того — это один из плюсиков в резюме
♦ Смена проекта или работы
Сейчас даже идеальное резюме может попасть под фильгр ИИ и не дойдег до
работодателя. В России хорошие вакансии часто закрываются по рекомендаци-
ям. Компании выплачивают своим сотрудникам бонусы за того приведенного
ими специалиста, кто прошел испытательный срок. Получается, что опять надо с
кем-то знакомиться и общаться.
♦ Сообщества позволяют выйти из информационного вакуума.
В них можно узнать, как другие компании решают похожие проблемы. Напри-
мер, обходятся со следованием новым законам.
♦ Поиск ментора.
Этому был посвяшен предыдущий раздел.
♦ Эмоциональная разрядка.
Многие конференции — это интересно, это общение с .людьми, которые пони-
мают ваши боли. Сообщество — это своего рода группа поддержки.
17А2. План участия
Совет
Не нужно пытаться на первой же конференции выступать — надо сначала поня1ь, как
работает система. Аналогично ведите себя и в сообществах— не пытайтесь сразу
везде ответить или всем посоветовать.
В связи с этим я рекомендую придерживаться примерно такого подхода.
♦ Этап 1. пассивный участник (2-3 месяца)
• Что делать: ходить на митапы, смотреть записи конференций прошлых лет.
• Цель: составить карту интересных сообществ, понять их культуру, сформи-
ровать список людей, которые вам интересны.
• На конференции: задавайте вопрос докладчику после выступления. Если не
успели, го подойдите после выступления, поблагодарите и спросите что-
нибудь уточняющее
♦ Этап 2: активный участник (3-12 месяцев)
• Что делать, задавать вопросы в чатах сообществ. 11омо1ать другим новичкам
(отвечать на вопросы, на которые вы уже знаете ответ).
• Цель: стать тем, кого уже знают в сообществе.
• На конференции: используйте паузы для общения и новых знакомств. Подхо-
дите к людям и знакомьтесь. Но не будьте навязчивы, не пытайтесь взять
контакт у всех подряд. Если знакомство состоялось, поделитесь информацией
о себе, заранее подумав о том. что будете говорить.
♦ Этап 3: спикер (больше года)
• Что делать- выступить на мероприятии в компании Если есть мигал — это
хорошо. Если нет, то попробуйте просто выступить с чем-то интересным.
Далее пробуйте выходить на конференции. Не думайте, что ваш доклад сразу
же одобрят, надо пробовать.
• Цель: перейти из категории слушателей в категорию спикеров.
17.4.3. Ошибки новичка
Чего точно не стоит делать:
♦ приходить только отдохнуть и послушать. Возможно, вы что-то и запомните, но
новые контакты и знакомства не заведете;
♦ пытаться везде задавать вопросы о работе, — например, при любой встрече или
в общих чатах Используйте для этого специальные каналы;
♦ вступать в споры и доказывать свою правоту. Цель комьюнити — это обмен
опытом, а не победа в дискуссии;
♦ критиковать компанию (команду, проект), в которой работаете, или любую дру-
гую. Вы не знаете, кто в аудитории может быть связан с вашим работодателем
или с вашим потенциальным работодателем
- Глава 18-
Как в IT-командах устроены оценка
и обратная связь?
Когда любой новый сотрудник перестает быть новичком, он начинает думать, как
пройти оценку. Эта глава посвящена рассказу о том, как организована оценка в
российских командах, как нужно работать с обратной связью и что говорить на
встречах с руководителем (и как нужно читать между строк). Мы также поговорим
здесь про то, что такое индивидуальный план развития и как с ним работать.
В конце главы я расскажу про специфику развития оценок в России.
Ранее, в главе 17, «Профессиональное развитие в команде», уже поднимался во-
прос профессионального развития Оценка и профессиональное развитие, безус-
ловно, связаны, но не следует думать, что ваш профессиональный рост неминуемо
приведет к успешной оценке.
Существуют несколько вариантов активностей, связанных с оценкой или с ростом
сотрудника внутри компании:
♦ оценка эффективности (часто даже в России она называется Performance
Review’, или аттестация} — наиболее популярная процедура, в процессе кото-
рой оценивается работа сотрудника, и по ее результатам может меняться его
грейд или зарплата, а также выплачиваться премия;
♦ встречи один на один (опе-1о-опе) — это периодические и обычно неформальные
встречи, которые призваны выявить имеющиеся у сотрудника проблемы и дать
ему возможность поделиться ими с руководителем. Такие встречи не связаны
напрямую с оценкой сотрудника, но нужны, чтобы подсказать ему правильное
направление движения;
♦ индивидуальные планы развития (ИПР) — это документ, в котором отражены
активности, которые нужно выполнить сотруднику, чтобы вырасти.
В каждой компании есть свои особенности, которые невозможно отразить в рамках
одной книги, однако общие черты все-гаки имеются, и о них мы поговорим далее.
18.1 Циклы оценки: Performance Review
и встречи один на один
Рассмотрим подробно оценку эффективности и отметим проблемы, с которыми со-
трудники сталкиваются при ее проведении. Кроме того, проговорим здесь и про
встречи один на один.
18.1.1. Оценка эффективности
Оценка эффективности, или Performance Review, или аттестация — это то, что есть
в каждой компании. В некоторых компаниях отсутствует формальная процедура
опенки, однако неформальная все-таки есть всегда.
Наиболее распространены следующие варианты оценки.
♦ Оценка 180/360— это конкретный вариант оценки эффективности Оценка 180
включает оценку от непосредственного руководителя и от самого сотрудника, а
оценка 360 — включает уже оценку большим количеством людей, как подчи-
ненных сотрудника, так и его руководителей, или просто коллег из команды.
К ней также могут привлекаться дополнительные сотрудники, напрямую не свя-
занные с командой (обычно они мотут дать характеристику, поскольку плотно
работают с тем, кто проходит оценку).
♦ Оценка по целям (выполнение KPI или OKR) — оценка по выполнению заранее
установленных целей.
♦ Неформальная процедура— оценка как таковая не зафиксирована и о ее прове-
дении нужно договариваться с руководителем.
Совет новичку
Нормальной практикой будет еще на этапе собеседования уточнить, как в компании
производится оценка. Не стесняйтесь об этом спрашивать. Многих работодателей пу-
гает (расстраивает) то, что сотрудник не интересуется возможностями роста.— это
может быть сигналом, что он не планирует задерживаться
Процедура оценки в компании обычно четко описана и регламентирована. Так. это
может быть ежегодно проводящаяся оценка сотрудника по установленным крите-
риям. Существуют специальные матрицы компетенции, кот орые включают различ-
ные навыки (hard skills, sofl skills), на оачадение которыми проверяется сотрудник.
При этом нужно быть готовым к тому, что оценка не всегда будет объективной, а
сами критерии далеки от понятия SMART. Например, среди критериев часто встре-
чаются такие пункты, как «инициативность» или «нацеленность на результат».
Вот типичный сценарий того, как проходит оценка.
1. За 2-4 недели служба HR рассылает напоминания и формы.
2. Вы заполняете форму самооценки. Часто это таблица с разделами;
• Достижения за период: перечень выполненных задач, проектов, внедренных
улучшений.
• Соответствие компетенциям: оценка по шкале (например, от 1 до 5) по таким
пунктам, как «Профессионализм», «Коммуникация», «Инициативность»
Ключевой момент: нужно подкреплять оценку примерами.
• Цели на следующий период: что планируете делать
3. Ваш руководитель заполняет такую же форму на вас.
4. Проходит встреча (30-60 минут), где вы обсуждаете:
• Совпадения-расхождения в оценках.
• Сильные стороны и зоны роста.
• Итоговую оценку (рейтинг) и се последствия.
Иногда результаты проведенной аттестации могут озвучиваться сразу, но моту] и
уйти на согласование и составление обратной связи на какое-то количество дней.
Часто руководитель согласовывает опенку со своим начальством, а иногда и со
службой HR.
В российских реалиях бывает так, что итог аттестации зависит не только от кон-
кретных навыков сотрудника, а от мнения о нем самою руководителя и от его впе-
чатления. А иногда итог может зависеть от того, насколько хорошо у вашего руко-
водителя складываются отношения с вышестоящим начальством: одобрит оно ре-
зультат или нет.
Сами итоги могут озвучиваться устно и расплывчато: «Нужно поработать над ком-
муникацией», «В следующем году ждем от тебя большего». А иногда вы получаете
положительный финальный вердикт (не исключено, тоже устно) и, возможно, из-
менение грейда, оклада или премию.
Наиболее распространенные проблемы при проведении оценки эффективности.
♦ Проблема 1. Вся годовая работа оценивается по тому, что вы успели вспомнить
и описать, а не по тому, что было сделано за год.
• Что делать? Ведите список достижений с первого дня. Только пишите так,
чтобы можно было самому потом это понять. Сохраняйте ссылки на трекер
или wiki. Самому себе потом скажете «спасибо».
♦ Проблема 2. Нечеткие характеристики— например, непонятно, что означает
«инициативность» на уровне 4 из 5.
• Что делать? Просите конкретики до заполнения формы. Спросите у HR или
руководителя, есть ли в компании требования и и их расшифровка. Если нет,
то предлагайте свою интерпретацию с примерами.
♦ Проблема 3 Официальная оценка воспринимается лишь как формальность, а
решение о повышении уже принято.
• Что делать? Не боритесь с системой, используйте ее. Результат оценки эф-
фективности — это документ, который упростит руководителю задачу обос-
новать ваше повышение перед начальством.
18.1.2. Встречи один на один
В отличие от оценки эффективности, которая является формальной и редкой про-
цедурой, встречи один на один (one-to-one, 1:1)— это неформальные встречи со-
трудника со своим непосредственным руководителем. Их главная цель — не оцен-
ка. а выявление проблем, синхронизация и поддержка. Периодичность таких
встреч — от раза в неделю до раза в месяц (не реже).
Ваша задача на встречах 11 — получить максимум возможно го для своего разви-
тия. Рекомендую использовать следующий формат.
♦ Оперативные вопросы (5 минут).
• Краткий статус но ключевым текущим задачам (что сделано, что в процессе).
• Есть ли что-то, что блокирует работу' прямо сейчас.
♦ Фокус-тема (10 мин.). Выберите одну тему для встречи:
• Вариант А (Карьера): «Я хотел бы обсудить мой потенциал роста в направ-
лении [например, автоматизации тестирования]. Каких навыков мне не хва-
тает?»
• Вариант Б (Проект): «У меня есть идея, как улучшить процесс [например,
сбора требований]. Можем обсудить?»
• Вариант В (Проблема): «Я столкнулся с трудностью в задаче |описать]. Ну-
жен совет, как подступиться».
♦ Обратная связь (5 мин.).
• Есть ли что-то, что я могу делать лучше? (Просите конкретики.)
• Иногда: рассказать руководителю (дать ему обратную связь) о процессах,
происходящих в команде (корректно и конструктивно).
♦ Люди и отношения (5 мин.).
• Обсудите, всё ли хорошо в команте с коммуникацией.
• Нужно ли наладить контакт с кем-то из смежных отделов?
Почему такой подход работает?
♦ Снимает нагрузку с руководителя — ему не нужно придумывать, о чем гово-
рить.
♦ Демонстрирует вашу активность и желание развиваться.
♦ Позволяет обсуждать карьеру в неформальном ключе.
Ошибки при проведении встреч формата один на один.
♦ приходить без повестки.
• Итог: встреча превращается в монолог руководителя или обсуждение сиюми-
нутных проблем;
♦ скрывать проблемы
• Итог: вы не говорите о проблемах, руководитель думает, чго все хорошо.
Возможный срыи сроков становится сюрпризом, руководитель будет разоча-
рован, а ваша репутация подорвана,
♦ только жаловаться.
• Итог: вы становитесь источником проблем. Вместо этого на каждую пробле-
му по возможности предлагайте вариант решения;
♦ никогда не говорить о карьере и вашем желании развиваться (если это действи-
тельно нужно).
• Итог вы остаетесь без развития в карьере. Помните, что о ваших амбициях
могут не знать. Вместо этого раз в три месяца включайте в повестку пункт о
развитии: «Мне интересна гема А. Есть ли з наших планах задачи, где я мог
бы в этом поучаствовать?»
* ♦ ♦
Так что не ждите пассивно ежегодной оценки эффективности, а готовьтесь к ней
заранее и используйте для этого вс гречи 1:1. В условиях российской ГГ-культуры.
где многое решаюг личные отношения, регулярный качественный диалог с руково-
дителем — самый эффективный инструмент карьерного развития.
18,2. Ведение журнала достижений
для регулярной оценки
Сотруднику не всегда можно повлиять на результат оценки, особенно если сама
оценка субъективна и строится на мнении руководителя, но, тем не менее, нужно
сделать максимум возможного, чтобы успешно пройти оценку. Для этого надо
фиксировать всё то ценное, что вы делаете в процессе работы, чтобы потом, когда
придет время, показать результаты. Ведь без регулярных записей очень сложно
вспомнить, что было несколько месяцев назад.
Зачем в принципе вести журнал достижений (помимо того, чтобы успешно пройти
оценку)?
♦ Когда вы постоянно хорошо работаете, это становится нормой В журнале вы
фиксируете, насколько более сложные задачи вы делаете со временем.
♦ Чтобы приходить к руководству не с эмоциями («я много работал»), а с кон-
кретным списком дел, доказывающих ваши достижения и, как следствие, вашу7
стоимость.
♦ Для собственного роста— вы увидите свои сильные стороны и то, что надо
улучшить.
♦ При смене работы можно быстро сформировать резюме. Имея журнал достиже-
ний, будет проше показать, что именно вы делаете.
♦ Если вас вдруг обвинят в низкой эффективности или в том, что вы мало сделали
за прошедший временной интервал, вы сможете показать факты.
Основные принципы ведения журнала достижений:
♦ Делайте записи регулярно, но не тратьте на них много времени.
Норма — не более пяти минут в день или 30 минут в неделю. Неделя-две — это
нормальный интервал для записи. Делать записи каждый день бессмысленно —
уже через полгода будет нереально обработать около сотни записей. Лучше их
будег 5-7, но ценных.
♦ Фиксируйте ценное для бизнеса, а не только для себя.
Делайте акцент не на том, что сделали очередную задачу или прокачали скил в
какой-то технологии. Пишите, какую ценность это принесло бизнесу, какую
проблему вы решили и как кому-то помогли
♦ Технические улучшения или скилы можно фиксировать, если бизнес поймет их
ценность
Например, вы изучили редкую, но актуальную в вашей команде техно логию, что
поможет снизить риск простоя в случае болезни кого-либо из владеющих ей со-
трудников или позволит делать какую-то задачу без привлечения специалистов
из другой команды
♦ Если вы реализуете не технические задачи, а дополнительные — это тоже важно
фиксировать.
'Это, например, может быть адаптация новых сотрудников, участие в закрытии
вакансии, помощь другой команде.
♦ Фиксируйте итоговый результат, а не процесс.
Правильно так: проанализировал изменения в API и выявил недокументирован-
ные изменения, что позволило команде сэкономить 4G часов.
♦ Фиксируйте результат в виде ссылок на документы, задачи и т. п.
С их помощью вы сможете предоставить реальные факты достижений.
♦ Фиксируйте род компетенций: профессиональные, инициативность и т. п. и обя-
зательно месяц, в котором они проявлялись.
Это в дальнейшем упростит формирование документа для оценки.
♦ Раз в месяц-два делайте ревизию журнала: удалите дубли, раскройте не очень
понятные пункты (со временем такое будет).
Частые ошибки:
♦ писать расплывчато или так, что потом будет не понятно, о чем речь. Например,
«помогал команде в решении критической ошибки». Через месяц вы забудете,
что это была за ошибка:
♦ присваивать чужие достижения или говорить, что это только ваша заслуга;
♦ не писать сразу, а откладывать записи. Потом забывается, что было;
♦ использовать журнал для фиксации негатива и проблем. Это лотом никому не
понадобится.
Далее мы поговорим о том, как, используя журнал достижений, готовиться к оцен-
ке эффективности
18.3. Подготовка и прохождение Performance Review
В действительности подготовка к оценке начинается с того момента, когда произ-
водилась предыдущая оценка, а для новичка — с момента прихода в компанию.
Узнав о том, что вам предстоит Performance Review, нужно подготовиться к ней и
пройти несколько стадий:
1. Исходная подготовка.
На этой стадии надо уточнить (или узнать, кто проходит оценку в первый раз),
изменились ли правила и как. Проблема в том, что для тех, кто проводит оцен-
ку,— это рутина, и они могут забыть сказать вам о том, что с предыдущей
оценки в правила добавились какие-то изменения. Ваша задача — подготовиться
и прочитать изменения, чтобы быть готовым к новым вводным.
Совет новичку
Сначала причитайте правила, затем посоветуйтесь с теми кто недавно проходил
оценку эффективности, если такие есть. Если таких нет, то спросите совета у опытных
коллег, а если в их ответах есть отличия от того, что вы прочитали, то уточните, в чем
дело Возможно, так вы поможете коллеге, который также готовится к оценке. Если
вам давали обратную связь по предыдущей оценке, то обязательно найдите ее и изу-
чите. Посмотрите пункты, которые вам вписали. Будьте готовы к тему, чтобы отчи-
таться о результатах. Если вам есть что сказать, а вас не спросили то будьте готовы
сами заявить о достижениях по представленному списку.
2. После этого нужно провести ревизию журнала достижений. Сделайте следующее:
• открываете журнал за период с предыдущей оценки;
• группируете достижения по компетенциям из матрицы оценки (например,
«Професс! юнализм», «Инициативность»);
• для каждой компетенции выбираете значимые примеры — идеально, если
они будут с метриками;
• формируете итоговый документ и отправляете руководителю до встречи,
чтобы он был готов.
3. Напишите документ с самооценкой (даже если этого явно не требуется). При-
мерный формат;
• Введение — на чем вы были сфокусированы. Например: обеспечение качест-
ва релизов, автоматизация рутины, развитие процессов
• Раздел «Достижения и результаты» (основная часть):
° сгруппируйте их по целям/проектам, а пе по месяцам;
° по каждому пункту примените подход СДР (Ситуация —> Действие —> Ре-
зультат) или КДР (Контекст —> Действие —> Результат);
° используйте цифры и факты;
° вставляйте ссылки на доказательства (тикеты, документы, благодарности).
• Раздел «Развитие компетенций» — покажите, как вы выросли, что освоили и
как это помогло бизнесу.
• Раздел «Зоны роста и цели на следующий период»:
° не описывайте слабости в качестве проблем. Переформулируйте их в «об-
ласти для развития»;
° сформулируйте цели на следующий период. Они должны быть составлены
по SMART и связаны с бизнес-целями команды.
• Отправьте самооценку непосредственному руководителю заранее (за не-
сколько дней до встречи). Дайте ему время с ней ознакомиться и подгото-
виться. Не пытайтесь презентовать самооценку вышестоящему руководству
без учета мнения своего руководителя.
4 Накануне встречи— подготовьте ответы на возможные вопросы и подумайте
над форматом презентации, если требуется.
5 . Проведите саму встречу. Советы во время встречи:
• ведите себя как коллега;
• используйте подготовленные материалы;
• не перебивайте — сначала выслушайте версию руководителя полностью:
• задавайте уточняющие вопросы, если что-то не понимаете;
• фиксируйте договоренности.
Если встреча проходит плохо (вас критикуют несправедливо):
♦ сохраняйте спокойствие и не спорьте на эмоциях,
♦ просите факты и конкретику: «Чтобы я мог понять и исправить, не могли бы вы
привести пример, когда это проявилось?»;
♦ если чувствуете, что не можете адекватно ответить, возьмите тайм-аут;
♦ если оценка явно необъективна, можно апеллировать к фактам из своей само-
оценки.
Особенности, которые нужно учитывать:
♦ решение часто принимается до встречи. Ваша встреча — это формальность для
озвучивания решения. Но ваша подготовка может:
• дать руководителю новые аргументы для борьбы за ваше повышение;
• кардинально изменить его мнение о вас, если оно еще не до конца сформи-
ровано;
• дать основу для следующей итерации.
♦ Делайте акцент на лояльности и на командной работе. В России часто ценят не
только результат, но и то, как вы вписываетесь в коллектив. В самооценку обя-
зательно включайте пункты о помощи коллегам, менторстве, участии в корпора-
тивной жизни.
♦ Держите баланс — не очень скромно и не очень агрессивно. Уверенно и настой-
чиво, но уважительно. Прямое и агрессивное самопродвижение может оттолк-
нуть. Излишняя скромность тоже вредна Достижения должны быть понятны
бизнесу и выглядеть как вклад в общее дело, а не как одолжение.
18.4. Как воспринимать обратную связь?
Кажется, что нет ничего особенного в том, чтобы воспринимать обратную связь
(ОС), но нужно вести себя так, чтобы встреча прошла с пользой и не вызвала про-
блем в будущем. Итак, практические правила
♦ Благодарите, даже если вам кажется, что критика несправедлива. Первая фраза:
«Спасибо, что поделился мнением. Это важно для меня». Это позволяет распо-
ложить к себе того, с кем вы ведете разговор, и выключает защитную реакцию.
♦ Уточняйте, а не оправдывайтесь. Вместо «Я не виноват, потому что...» спросите:
«Можешь привести конкретный пример, когда я [событие]? Я хочу полностью
понять ситуацию».
♦ Работайте с фактами, а не с эмоциями. Например, если кто-то говорит, что вы
сорвали сроки, то нужно уточнить, о каком конкретно факте пошла речь и при-
чем тут именно вы. Например, эмоция звучит так: «Ты сорвал все сроки по про-
екту», а факт звучит так: «Задача была сдана на два дня позже дедлайна, указан-
ного в Jira» (факт).
♦ Сфокусируйтесь на будущих целях и задачах, а не на том. что было. Задайте
ключевой вопрос: «Что я должен сделать по-другому в следующий раз. чтобы
результат был лучше?»
♦ Не принимайте критику на свой счет — критикуют ваши действия или результа-
ты, а не вашу личность.
Совет
Просите продублировать обратную связь письмом, чтобы вы могли позже вернуться к
ней и посмотреть, куда надо двигаться В противном случае вы забудете то, о чем вам
говорили.
18.4.1. Неформальная обратная связь
Нужно быть готовым к тому, что часть значимой обратной связи будет передавать-
ся неформально. Учитывать эти неформальные моменты нужно всем, а не только
новичкам. Примеры таких моментов представлены в табл. 18.1.
Таблица 18.1 Примеры неформальной обратной связи
Как выглядит? Что на самом деле значит?
Руководитель спрашивает в нефор- мальной обстановке: «Ну что, как продвигается? Всё нормально? Какие сложности?» Это не просто вежливость. Это ситуация, когда руководитель пытается получить информацию о скрытых проблемах попытка выявить неже- лание просить помощи
Неформальный разговор с коллегой в случайном месте (кухня, кулер). «Слушай, по поводу той задачи вооб- ще молодец, конечно, но . мне кажется, можно было немного иначе» Возможно, ваш подход или задача, которую вы создали, кому-то принесли проблемы. Это мягкое указание на ошибку с попыткой со хранить лицо
Шутки и подколы в команде «О, наш докуменгировщик вселенского масштаба пришел!» Замаскированная критика через юмор Позво- ляет указать на проблему, не вступая в прямой конфликт
Вас внезапно начинают ставить адреса- том копии письма по проекту, о котором вы не знали Сигнал о том, чтс ваша зона ответственности будет расширяться На вас смотрят как на потенциальную замену/помощь
Ваши предложения на встречах встре- чают молчанием или быстро переходят к следующей теме Ваши идеи не считают ценными или реализуе- мыми, но не хотят говориш об этом прямо, чтобы не демотивировать, не обидеть или не вызвать у вас неадекватную реакцию
Совет новичку
Если что-то сказано с глазу на глаз, а не в рамках официальной встречи, то именно
это часто самая важная обратная связь. Отнеситесь к ней серьезно
18.4.2. Ошибки новичков
Наиболее распространенные ошибки новичков
♦ Ожидание только формальной обратной связи. Ошибка здесь в том, чтобы ждать
производимой раз в год оценки, чтобы понять, что о вас думают
• Решение. Просить неформальную ОС у коллег и руководителя раз в 1-2 месяца.
♦ Восприятие критики как атаки на вас. Не надо защищаться или обижаться.
• Решение. Помнить, что в профессиональной среде критикуют работу, но не
переходят на личности.
♦ Игнорирование невербальных сигналов. Ошибка здесь в том, чтобы не замечать,
что коллеги после ваших предложений переписываются в отдельном чате, куда
вас не добавили.
• Решение. Развивать эмоциональный интеллект. Если чувствуете проблемы в
коллективе, то аккуратно спросите у коллеги, которому больше всего дове-
ряете: «Мне показалось, что моя идея не зашла, Можешь честно сказать, по-
чему?»
♦ Сравнение себя с другими. Ошибка говорить, что вас обделили, а кого-то поощ-
рили.
• Решение. Фокусироваться на своем росте относительно себя, а не сравнивать
с другими.
♦ Молчание о своих достижениях. Почему-то многие считают, что работа говорит
сама за себя, а руководитель должен помнить все. Ошибка состоит в том, что вы
молчите о своих достижениях.
• Решение. Учиться скромно, но регулярно информировать о своих результа-
тах. Не надо пытаться показать, какой вы уникальный и какую задачу реши-
ли. Фиксируйте то, что помогло компании. Например: «Задача X выполнена,
и это позволило сократить время обработки заявки на 15%».
18.4.3, Что делать с результатами оценки?
После получения формальной или неформальной ОС нужно действовать следую-
щим образом.
♦ Успокойтесь, особенно если ОС была не такой, какую вы ожидали, Должно
пройти не менее дня, а лучше — выходные. Нс принимайте решений на эмоциях.
♦ Проанализируйте и разбейте все пункты на три блока:
1. С чем вы согласны. Над этим надо поработать.
2. Что требует уточнения. Эти вопросы нужно задать через несколько дней (не
месяцев).
3. С чем вы не согласны и почему. Это то, что можно будет аргументированно
обсудить при случае. Но не надо спорить сразу. Разберите это позже.
На основании того, что написано в пунктах первого блока (то, над чем надо пора-
ботать), и на основании пунктов, уточненных в блоке 2, создайте ИПР —
индивидуальный план развития (далее описано, как это сделать).
Совет
Не думайте, что дав вам обратную связь, для вас обязаны составить и ИПР. Проявите
активную позицию и составьте его сами, если считаете, что руководство не проявляет
к вам интереса. Это покажет серьезность ваших намерений развиваться. Быстрее
растут именно те. кто сами заявляют о себе При этом не надо долбать руководителя,
чтобы он вам помог, — лучше используйте ИИ
Составив план, проведите встречу с руководителем, чтобы зафиксировать то. что в
нем написано, или скорректировать некоторые пункты.
Назначайте сами промежуточные встречи согласно тому, как двигаетесь. Опять же,
не думайте, что за вами будут бегать.
18.5. Составление индивидуального плана развития
Обратная связь, которая предоставляется вам руководителем по результатам оцен-
ки. может содержать общие цели или общие вектора развития, но для того чтобы их
достичь, лучше составить индивидуальный план развития. По сути, он раскрывает
то, как поставленные цели должны быть достигнуты.
Главный вопрос при составлении ИПР звучит так: «Какие навыки и компетенции
мне необходимо развить в ближайшие 6-12 месяцев, чтобы стать более ценным
специалистом в этой компании9»
18.5.1 Основные принципы, лежащие в основе ИПР
♦ ИПР — это взаимная договоренность. Вы, как сотрудник, тратите время и уси-
лия, а компания — ресурсы (деньги, время, экспертизу менторов). Цель — по-
высить свою ценность и эффективность для компании.
♦ ИПР привязан к бизнес-контексту. Это не абстрактные технические задачи или
обучение, а привязка к реальным проблемам команды, компании и, в конце кон-
цов. клиентов.
♦ ИПР — это инструмент, который показывает ваши карьерные ожидания и помо-
гает удержать вас в компании.
18.5.2. Структура ИПР
В некоторых компаниях для ИПР используются уже готовые шаблоны. Но, в об-
щем и целом, во всех вариантах таких шаблонов содержится примерно одно и то
же.
♦ Шапка документа включает базовою информацию о сотруднике и периоде, на
который ИПР составляется. И что очень важно, в шапке должна быть указана
цель (или цели).
♦ Текущее состояние (этот пункт часто отсутствует) — это краткое описание на-
чальной точки Материалы для него обычно берутся из результатов оценки. На-
пример: глубокое знание доменной области, слабое знание SQL, неуверенное
проведение демонстраций перед заказчиками.
♦ План действий — эго сама суть ИПР. Обычно представляет собой таблицу, ко-
торая состоит из следующих столбцов:
• Развиваемый навык.
Это могут быть технические навыки, софт-скилы и любые другие. Напри-
мер, те навыки, которые отмечены в начальной точке, как недостаточно
развитые: «Работа с данными (SQL) для анализа», «Проведение демонст-
раций».
• Конкретные действия для развития каждого навыка.
То есть шаги, которые необходимо сделать, чтобы достичь цели. Напри-
мер, для SQL: «Пройти курсы новичка», «Самостоятельно найти причину
ошибки в работе отчета», «Составить полностью новый аналитический
отчет».
• Критерии успеха.
Их нельзя упускать— это крайне важный пункт, который говорит о том,
что навык получен. Например (для предыдущих шагов): «Получен серти-
фикат», «Исправлена ошибка и получено подтверждение ревью от коллег
по ошибке», «Отчет успешно и корректно формирует данные на продук-
тивной среде».
• Срок для каждого шага.
• Ресурсы и поддержка.
Эго то, что может дать компания, — например, бюджет на обучение, дос-
туп к тестовой среде, консультации конкретного сотрудника.
Могут быть и другие пункты, но они носят опциональный или формальный характер.
18.5.3. Шаги по составлению ИПР
На основании имеющегося в компании шаблона сначала составляется черновик
плана развития — именно черновик, потому что он пока еще не вачидирован у ру-
ководителя
Для валидации документа необходима встреча. Руководитель может внести в пред-
ложенный ему черновик свои правки как по цели (целям), так и по пунктам. При
этом надо быть готовым к тому, что некоторые пункты, которые вы включили в
план, не будут нужны бизнесу Например, обучение за 150 тыс. рублей руководи-
тель может не одобрить, потому что не увидит в нем ценности.
Когда вы договоритесь с руководителем по всем вопросам, считайте, что это уже
чистовик. И по нему можно начинать работать и периодически встречаться На-
помню, что организация встреч— это ваша задача, а не задача руководителя.
Встречи 1:1 — эго один из форматов, когда можно и нужно обсуждать ИПР.
Также помните, что ИПР следует периодически актуализировать и заполнять. Не
ленитесь, сразу вносите в него достижения и новые пункты.
Совет
Не относитесь к ИПР так, как будто он не сможет измениться. Цели б компании меня-
ются, наставник может уволиться, и ИПР тоже будет меняться, адаптируясь под цели
компании или под объективную реальность. Если вы записали в план пункт о том,
чтобы выучить технологию, которая за год перестала быть актуальной, то ИПР при-
дется пересматривать Взгляните на документ глазами своего руководителя; зачем
ему повышать и развивать сотрудника, который не умеет адаптироваться1’
18.6. Российская специфика оценки сотрудников
В России в оценке сотрудников работает некий гибрид, включающий в себя запад-
ные практики (OKR, KPI, Performance Review) и местные особенности, которые
явно не написаны (негласные правила), но серьезно влияют на результат.
18.6.1. Основные особенности российской специфики
Нужно разделять официальную и реальную ситуации. Например, у вас есть КР1, он
понятный и содержит минимум субъективных моментов Но итоговый результат
будет зависеть не только от него, а еще и от ваших личных отношений с руководи-
телем, восприятия вас как части команды («свой») и заметности у «нужных лю-
дей». Нельзя игнорировать неформальные правила. Если вы не считаетесь в кол-
лективе «своим» или не входите в доверенный круг руководителя, есть шанс, что
при самых хороших KPI у вас будут самые худшие результаты.
Нужно понимать, что пословица «Один в поле не воин» применима и к оценке.
В России чрезмерное выпячивание личного успеха в ущерб команде («высовываться»)
может быть воспринято негативно Вы должны признавать вклад коллег и команды.
Ваши личные достижения должны преподноситься как вклад в общий успех.
Нужно быть готовым к тому, что вам не будут прямо говорить о проблеме или вас
or крыто не будут критиковать. Если ваш руководитель или старшие коллеги ис-
пользуют обтекаемые формулировки вроде «Давай подумаем над этим вместе»,
«Есть небольшая мысль...», то это на самом деле означает, что вы что-то делаете не
так. Вам нужно научиться считывать подтекст.
Бывает, конечно, и противоположный подход, когда руководитель или старший
коллега ругает ваше решение, но со временем принимает его и может даже пред-
ставить его как свое. Вы должны учитывать, что это за человек, и опять же нау-
читься считывать подтекст.
Надо быть готовым и к тому, что конкретное решение принимает не абстрактная сис-
тема, а конкретный человек Эго может быть как ваш прямой руководитель, так и
начатьнпк вашего руководителя. Мнение последнего может быть субъективным и
сформировано на основании пары негативных отзывов или личных выводов. Следует
адаптироваться под цели того, кто действительно принимает решение. Вы должны
понять, что именно важно начальнику: соблюдение сроков, инициативность, беспро-
блсмность? Ответ именно на этот вопрос поможет вам быстрее подняться.
18.6.2. Неформальные критерии оценки
Вы также должны понимать, что, помимо формальных КР1, вас будут оценивать по
параметрам, которые не часто пишут в матрицах компетенций.
♦ Надежность.
На вас можно положиться в срочном и важном деле? Вы предупреждаете о про-
блемах заранее? Надежность ценится выше, чем гениальность в совокупности с
нестабильностью. Вы решаете проблемы или создаете их? Вы приносите руко-
водителю готовые решения или их варианты, а не только вопросы? Умеете дого-
вориться с кем надо?
♦ Лояльность.
Не только компании, но и непосредственному руководителю. Если вы публично
критикуете решения начальства, даже обоснованно, то в большинстве россий-
ских компаний вы не вырастете. Если вы с кем-либо не согласны, обсуждайте
это с ним с глазу па глаз в формате 1:1.
♦ Готовность к неудобству.
Готовы ли вы принимать правила игры, даже если они кажутся нелогичными?
Например, работать с устаревшим техпроцессом.
♦ Правильная видимость.
Не яркая самопрезентация, а умение тактично информировать о своих успехах
тем. от кого зависит решение Тех, кто хвастается и шумит о том, какой он мо-
лодец, не любят. Но и молчунов не замечают — нужно уметь аккуратно под-
черкнуть и свой вклад, и достижения, но сделать это так, чтобы все поняли, бла-
годаря кому это произошло. Поищите того, кого ценят, но кто не шумит налево
и направо; возможно, стоит перенять этот сто навык
18.6.3. Практические советы для роста
♦ Найдите того, кто поможет вам расшифровать истинный смысл сказанного на
совещании или в обратной связи.
♦ Протоколируйте все действия: договоренности на словах, устные поручения,
изменения в требованиях. Краткое подтверждающее письмо («Как я понял из
нашего разговора, мы договорились, что...») спасает в большинстве спорных си-
ту аг шй.
♦ Создайте репутацию адекватного специалиста Того, кто оценивает риски. В ус-
ловиях нестабильности эго ценится.
♦ Не пренебрегайте корпоративными ритуалами и правилами. Посещайте дейли
митинги, летучки, корпоративы. Это площадки для неформального общения и
повышения видимости.
♦ Управляйте ожиданиями. Лучше честно сказать «сделаю к пятнице», чем обе-
щать на среду и сорвать срок. В России особенно болезненно относятся к срыву
обещаний.
♦ В случае конфликта или несправедливой оценки не идите «на принцип» сразу.
Используйте многоступенчатую тактику: спокойный разговор с руководите-
лем —> привлечение HR (как медиатора), и только потом, если ничего не помога-
ет, эскалация выше. Но помните: после эскалации остаться в команде будет поч-
ти невозможно.
* * *
Работа в российской системе оценки требует двойного фокуса: на результатах (что
делать) и на отношениях (как делать и с кем). Игнорирование любой из этих сторон
ведет к отсутствию роста и развития. Ваша задача — стать не просто хорошим тех-
ническим специалистом, а тем, кто понимает, как взаимодействовать с людьми.
Заключение
Когда я только начинал свой путь в разработке, у меня не было книги, которая объ-
ясняла бы простые и важные веши целиком. Знания приходилось собирать по кус-
кам: что-то — от коллег, что-то — через собственные ошибки, что-то — через дол-
гие разговоры с командами, заказчиками и руководителями Понимание того, как
на самом деле устроена разработка ПО, пришло ко мне гораздо позже, чем первые
технические навыки.
За годы работы я видел много талантливых людей. Одни быстро росли, потому что
рано начинали смотреть на продукт шире своей задачи. Другие застревали на мес-
те, хотя отлично знали инструменты. Почти всегда причина была не в способно-
стях, а в отсутствии общей картины: как связаны требования и код, процессы и лю-
ди, бизнес и технологии. Эту книгу я задумывал именно как попытку дать такую
картину гем, кто только входит в профессию.
Мне бы хотелось, чтобы она сэкономила читателю несколько лет поиска очевид-
ных, но редко проговариваемых вещей: как не потеряться в первые месяцы, как за-
давать вопросы, как относиться к процессам, как разговаривать с коллегами и не
бояться непонятного.
Может, кто-то из вас в итоге пойдет гораздо дальше меня. И это замечательно: ка-
ждое новое поколение профессионалов должно прыгать выше предыдущего. Даже
если со временем вы смените стек, компанию или вообще уйдеге в дру1ую роль,
база останется тем самым фундаментом, к которому вы еще не раз вернетесь.
Разработка программного обеспечения — это не только код и методологии. Это
ответственность за результат, уважение к людям рядом и способность постоянно
учиться. Если книга помогла вам почувствовать это чуть раньше, чем обычно при-
ходит такое понимание, значит, она выполнила свою задачу.
Желаю вам интересных проектов, сильных команд и той профессиональной дороги,
о которой через годы будет приятно вспомнить.
Приложения
- Приложение 1 -
Глоссарий современных
терминов разработки
П1.1. Продуктовые термины
Продуктовые термины используются всеми, кто занят разработкой ПО: менедже-
рами, техническими и продуктовыми специалистами.
MVP, Minimum Viable Product (минимально жизнеспособный продукт)— первая
версия продукта с базовой функциональностью. Это то, с чем уже могут работать
пользователи, при этом он не имеет пока всех функций, которые они хотели бы от
него получить, — лишь необходимый минимум.
ТТМ, Time То Market (время выхода на рынок) — ключевой показатель, обозна-
чающий время, которое должно пройти от появления идеи до момента, когда реше-
ние и его первая версия (MVP) окажутся у реального пользователя. Термин исполь-
зуют как для новых продуктов, так и для конкретных идей в уже работающем про-
дукте.
Бэклог— упорядоченный по приоритетности список всех задач, функций и ис-
правлений ошибок, которые необходимо реализовать в продукте. Очень важно
помнить, что в этом списке должны быть расставлены приоритеты. Без приорите-
тов -— это не бэклог.
Стейкхолдеры — все люди или организации, которые так или иначе заинтересова-
ны в результате вашего проекта или могут на него повлиять. В настоящее время
понятие стало максимально широким: это не только те, кто дает деньги, но и те. кто
будет пользоваться продуктом, а также те, кто его создает. Если бэклог — это спи-
сок задач, то стейкхолдеры — это те люди, чьи желания и потребности превраща-
ются в строчки этого списка.
Product Owner — владелец продукта (РО). отвечающий за бэклог и приоритеты. РО
выступает «мостом» между бизнесом, включая стейкхолдеров, и командой разра-
ботки. РО принимает решения о том, что именно нужно делать, чтобы продукт
приносил деньги и пользу.
Тимлид (Team Lead) — главный сотрудник в инженерной команде. Это опытный
специалист (чаше всего уровня «сеньор»), совмещающий в себе две роли: техниче-
ского лидера и менеджера людей. Это не просто «самый умный программист», а
человек, который отвечает за то, чтобы команда работала как единый механизм.
Если РО говорит, куда мы идем, то тимлид отвечает за то, кто и в каком состоянии
туда дойдет.
Кик-офф (от англ, kick-off — удар по мячу в центре поля, начинающий футболь-
ный матч) — первая официальная встреча команды и стейкхолдеров для запуска
работы над проектом. Если бэклог— это список того, что нужно сделать, то кик-
офф — тот момент, когда все участники процесса собираются вместе, чтобы дого-
вориться о правилах шры.
Адженда (от англ, agenda— повестка дня. произносится «адженда» или «аген-
да») — это план встречи или мероприятия. Это список вопросов, которые нужно
обсудить, и целей, которых нужно достичь за отведенное время.
Нетворкинг (от англ, networking — плетение сети) — процесс создания и развития
сети полезных знакомств В 2026 году это не просто «обмен визитками», а умение
выстраивать долгосрочные и доверительные отношения с людьми, чтобы в буду-
щем вы могли помогать друг другу решать профессиональные или личные задачи.
В IT-среде нетворкинг— это один из самых быстрых способов найти классного
специалиста в команду, узнать о «подводных камнях» новой технологии или полу-
чить совет от того, кто уже решал вашу проблему.
РОС (это английские буквы, читается как «пи-о-си», иногда «пок») дословно
«доказательство концепции» (Proof of Concept), пробная реализация для проверки
идеи.
Фича (от англ, feature — особенность) — в разработке ПО ее часто понимают как
конкретную функцию или особенность продукта. Это может быть уникальное ре-
шение, которое добавляет ценности продукту. Например, возможность поставить
динамическую видеозаставку на смартфоне — это фича.
Вау-фича — фича, которая доставляет пользователю приятное удивление или вос-
хищение. Она может быть абсолютно бесполезной, но вызывать эмоции (как пра-
вило, положительные, но не обязательно). Bay-фичи обычно создают, чтобы поль-
зователю запомнится продукт, но пользователь может узнать о вау-фиче только во
время использования и не знать о ней заранее. При этом вау фичи со временем мо-
гут использоваться в продуктах конкурентов, поэтом)’ что порой это лишь классная
идея, которую никак нельзя защитить от использования.
Примеры вау-фич
• Подсветка банковской карточки во время успешной оплаты — это вау-фича. кото-
рая эффект нг выгляди г.
• Разблокировка телефона отпечатком папьца — это тоже в свое время была вау-
фича. Сейчас это уже самс собой разумеющееся требование к любому смартфону.
• Первоначальный лимит в 140 символов е Twitter— этс также была вау-фича. сей-
час уже не актуальная.
• Функция смартфона, которая автоматически извлекает код из SMS и вводит его
для подтверждения платежа — это очень удобное и полезное решение и тоже вау-
фича.
Киллер-фича — уникальная неповторимая особенность в вашем продукте, которая
«убивает» конкурентов, Это может быть фича, не имеющая аналогов в их продук-
тах, Многие готовы купить ваш продукт только благодаря киллер-фиче. То есть,
если вау-фича предназначена для того, чтобы восхитить пользователя (вишенка на
торте), то киллер-фича привлекает и удерживает пользователей (основная причина
успеха). Если про вау-фичу пользователь может не знать заранее, то благодаря кил-
лер-фиче продукт покупается. Придумать настоящую киллер-фичу действительно
сложно, а чтобы повторить ту, что придумали конкуренты, требуются колоссаль-
ные усилия. Иногда для привлечения внимания пользователей вау-фичу заменяют
термином «киллер-фича» и пытаются выдать желаемое за действительное.
Примеры из жизни
• Мультитач-интерфейс (масштабирование и прокрутка жестами)— это киллер-
фича, внедренная в 2007 году компанией Apple iPhone покупали за возможность
не пользоваться физическими кнопками, а использовать только тач-экран Сейчас
это уже стандарт, но в свое время — именно киллер-фича.
• Доступ ко всей музыке мира по подписке Компания Spotify впервые предложила
платить не за одну конкретную песню, а за возможность прослушивать любые дос-
тупные треки за абонентскую плату в месяц Сейчас же получение по подписке
книг, музыки, видео, автомобилей не вызывает удивления
• Возможность самостоятельной сборки и доставки мебели из IKEA — это тоже кил-
лер-фича компании. Покупатель знает, что ему придется самому собирать мебель,
но вряд пи кого-то это пугает, ведь мебель из IKEA собирается просто и по понят-
ной инструкции
Баг (от англ, bug — ошибка) — жаргонное название ошибки в коде или работе про-
граммы. Баг приводит к неправильному или непредсказуемому поведению систе-
мы. Примет) бага — возврат к начальной заставке на смартфоне после перезагрузки.
Часто в разработке можно услышать: «Это не баг, а фича». Тут имеется в виду си-
туация, когда поведение продукта для пользователя является неожиданным (непра-
вильным), но было предусмотрено разработчиками:
♦ Серьезное отношение.
Например, система редактирования графики с бесплатной лицензией может от-
казаться сохранить изменения — это заложено в продукт, но не понравится
пользователю, т. к. он узнает об этом только в момент сохранения. Такое пове-
дение изначально было заложено в требования, но пользователь ошибочно по-
считал его ошибкой.
♦ Ироничное отношение.
Поведение, о котором никто не подумал. Например, при попытке уменьшения
количества покупок в киоске фастфуда выбранная позиция не удаляется, а по-
зволяет уйти в минус.
Так что, если действие приводит к нежелательному поведению, которое не было
предусмотрено, то это баг. а фича — это особенность запланированная. Тут нужно
быть крайне аккуратным при ее исправлении, поскольку иногда пользователи зна-
ют про такие особенности и используют их в работе.
Пример: скрытие файлов в UNIX/Linux
Возможность скрывать файлы, добавляя точку перед их именем (например .env), из-
начально возникла из-за ошибки в ранней версии UNIX — она не была исправлена, а
вместо этого стала стандартной фичей операционной системы, позволяющей пользо-
вателям легко скрывать системные файлы Эта функция используется и в настоящее
время.
Фрод (от англ, fraud— мошенничество)— это любые мошеннические действия в
цифровой среде, целью которых является получение незаконной выгоды. Из-за ис-
пользования нейросетей фрод стал изощреннее, но суть осталась прежней — обма-
нуть систему, чтобы украсть деньги, данные или ресурсы.
UI (User Interface) — дословно «пользовательский интерфейс». Это то, как выгля-
дит приложение, — какие используются цвета, шрифты, визуальные эффекты,
сглаживание и т.п. Задача L4-дизайнера— сделать продукт привлекательным и
современным. Пользователю должен правиться дизайн.
UX (User Experience) — дословно «пользовательский опыт». Если U1 — это то, как
выглядит приложение, то UX — это то, насколько нам удобно пользоваться прило-
жением. какие впечатления, эмоции и результат получает человек от взаимодейст-
вия с вашим продуктом LTX — это не только про «удобство», это про предвосхи-
щение желаний. Плохой UX заставляет пользователя уходить и не пользоваться
приложением.
SaaS (читается как «саас>>)— модель, при которой вы пользуетесь программой че-
рез Интернет. Она уже где-то установлена, настроена и работает, а вы просто опла-
чиваете подписку (например, «Кинопоиск»— это SaaS-продукт). Вам не нужно
ничего устанавливать, приложение обновляется само и доступно с любого устрой-
ства. Но ваши данные при этом хранятся на сторонних серверах. Если Интернет
пропал — программа не работает (может быть частичная работа, если файлы ска-
чаны).
On-Premise (читается как «он-премис») — ситуация, когда вы покупаете программу
и устанавливаете ее на свои собственные серверы (внутри контура компании) Это
дает вам над ней полный контроль и безопасность данные физически у вас, никто
со стороны к ним не подберется. Но вам понадобятся свои системные администра-
торы, чтобы обновлять программу и обслуживать серверы.
Аналогия из жизни: праздничный ужин
Представьте, что вы хотите отметить праздник.
• SaaS — это поход в ресторан. Вы приходите на всё готовое. Вам не нужно поку-
пать плиту, мыть посуду или думать, как работает вытяжка Вы просто выбираете
блюдо из меню (бэклог ресторана) и платите по счету Если s ресторане ремонт
(обновление софта)— это проблемы владельца, а не ваши. Но вы едите то, что
дают, и не можете заглянуть в холодильник к шеф-повару.
• On-Premise— это ужин дома. Бы сами покупаете продукты, у вас своя плита и
свои кастрюли Вы точно знаете, что продукты свежие (безопасность данных). Вы
можете готовить как хотите и когда хотите. Но если плита сломается (сервер упа-
дет) — чинить ее придется вам самим в разгар праздника. И посуду мыть гоже вам.
Application Programming Interface (API) — это набор правил, которые позволяют
приложениям взаимодействовать друг с другом.
Аналогия из жизни- что такое API?
Е ресторане или кафе в роли API выступают меню и официант.
1. Гость ресторана просит меню и начинает его изучать (клиент делает запрос на
сервер для получения списка возможных действий). Можно в целом обойтись без
меню, если гость постоянный, но меню можег быть изменено, и тогда гость не
сможет заказать привычного блюда.
Более того, даже сам процесс работы с меню может измениться. Например, к бу-
мажному меню добавится электронное или доступное через приложение (подробно
об изменении вс взаимодействии рассказывается в разделе о прямой и обратной
совместимости главы 12).
2 Выбрав нужные варианты из меню, гость делает конкретный заказ у официанта
Например заказывает пиццу «Маргарита» и чай (клиент вызывает определенный
метод и передает необходимые параметры).
3. Официант контролирует корректность заказа. Например, уточняет, какой именно чай
требуется (сервер может отклонить запрос, если не соблюдены условия из API).
4 Если всё хорошо, заказ начинает обрабатываться на кухне Если выявляются ка-
кие-либо ошибки, например, компоненты для «Маргариты» закончились, официант
может вернуться с информацией для гостя (сервер возвращает ошибку).
5. Когда заказ гоюв, официант приносит его гостю или может сообщить ему, что он
можег его забрать (сервер возвращает результат запроса).
Официанта можег заменить мобильное (или иное; приложение, предлагаемое ресто-
раном гостю, чтобы он мог произвести заказ, но сам принцип работы с меню сохранит-
ся. При этом в меню не содержится информация том, как приготовить еду, поскольку
гостю это вряд ли интересно
П1.2. Термины, используемые в работе
с людьми и командами
Эти термины будет полезно знать всем, т. к. каждый участник команды с кем-либо
взаимодействует.
Онбординг (от англ, onboarding — «принятие на борт») — процесс адаптации пович-
ка. помогающий ему погрузиться в рабочие процессы, особенности работы команды
и компании. Итог онбординга — выход на ожидаемый уровень продуктивности.
Джун, миддл, сеньор — это три ступени эволюции специалиста. Разница между ними
определяется не только годами опыта, но и уровнем ответственности; джуниорам
говорят, что и как нужно делать, миддлы — крепкие профессионалы, а сеньоры сами
говорят, что и как нужно делать, и могут показать это на своем примере.
Bus Factor (эффект автобуса) — мера риска, которая показывает количество участ-
ников команды, после «исчезновения» которых проект не сможет продолжаться и
просто встанет. Обычно говорят так; «Сколько человек должен сбить автобус, что-
бы проект остановился?». Если это всего один человек (например, только один
сеньор знает, как работает ваш главный сервер), то ваш Bus Factor равен единице.
Это критически опасно для бизнеса. Почти всегда путают и говорят, что Bus-
фактор надо понижать, тем самым предполагая, что нужно увеличивать число уча-
стников, разбирающихся в проекте (в действительности его надо повышать).
QA — обеспечение качества (Quality Assurance), тестирование. Чаще всего, когда
говорят QA, то предполагают, что речь идет о конкретной роли тестировщика, а не
о процессе обеспечения качества.
DevOps— культура и практики, объединяющие разработку (Development) и экс-
плуатацию (Operations). Часто термин применяется именно к конкретным сотруд-
никам, которые занимаются DevOps, например. «Наши DevOps'bi настроили CI/CD
пайплайны» (если вы не поняли, о чем здесь речь, не страшно — см. пояснение чуть
далее в пункте про CI/CD). Хотя DevOps — это действительно культура (филосо-
фия), в реальной жизни так часто называют DevOps-инжснеров
П1.3. Технические термины
Это термины, которые используются в первую очередь в технических командах
(программистами, тестировщиками, DevOps-инженерами). Представители нетехни-
ческих команд мотут изучить их, чтобы лучше понимать, о чем говорят техниче-
ские специалисты.
Костыль — это быстрое, временное и часто «некрасивое» решение технической
проблемы. Ситуация, когда вместо того чтобы устранить причину поломки, про-
граммист придумывает хитрую «подпорку», чтобы все просто не развалилось пря-
мо сейчас. Обычно «костыли» используют, когда нужно «пофиксить баг' еще вчера»
или когда на правильное решение (рефакторинг) нет времени, бюджета или сил.
Аналогия из жизни
Представьте, что у вас в кухонном шкафу сломалась петля, и дверца постоянно отви-
сает и открывается
• Правильное решение: пойти в магазин, купить новую петлю, выровнять ее по
уровню и надежно прикрутить. Этс долго и требует инструментов.
• Костыль, подпереть дверцу шваброй или приклеить ее на кусок синей изоленты
(или скотча).
Велосипед— решение, означающее изобретение того, что уже давно придумано и
работает. Если программист говорит: «Ты зачем велосипед изобретаешь?», это оз-
начает: «Не нужно писать с нуля код для того, что уже давно реализовано в гото-
вых библиотеках, фреймворках или стандартных инструментах».
Аналогия из жизни
Представьте, что вам нужно забить гвоздь в стену. У вас есть два варианта
• Правильный подход (использование готового инструмента): вы берете моло-
ток и забиваете гвоздь В сумме это несколько минут.
• Изобретение велосипеда: вы тратите час на то, чтобы найти палку, примотать к
ней камень изолентой (это «костыль» из предыдущего примера) и пытаетесь этим
сооружением забить гвоздь. В итоге вы тратите кучу времени, результат получает-
ся кривой, и молоток всё равно работает лучше.
Апрув (от англ, approve — одобрять, утверждать) — термин, означающий одобре-
ние, подтверждение или согласие с чем-либо (задачей, проектом, документом, ли-
дом, заявкой, контентом) после проверки.
Технический долг — ситуация, когда вы «занимаете» время у будущего ради быст-
рого результата сегодня. Этот долг почти всегда состоит из результатов создания
«костылей» и использования «велосипедов».
Рефакторинг— процесс улучшения внутренней структуры кода без изменения его
внешнего поведения. Попросту говоря, это генеральная уборка и переработка про-
граммы, чтобы она стала понятнее, надежнее и быстрее, но при этом для пользова-
теля всё работало точно так же, как и раньше с точки зрения логики (но нс скоро-
сти). Рефакторинг — это основной способ выплаты технического долга: не добав-
ление новых функций, а приведение в порядок тех, что уже написаны. Именно этот
этап нужен, чтобы убрать «костыли» и «велосипеды».
Фронтено (Frontend) — это всё, что пользователь видит на экране и с чем он может
взаимодействовать напрямую. Кнопки, формы регистрации, анимации, шрифты и
выпадающие меню— это и есть фронтенд: не просто «картинка», а сложный ин-
терфейс, который должен одинаково идеально работать на экранах разного размера
и разрешения.
Бэкенд (Backend)— внутренняя, скрытая от глаз пользователя часть продукта, в
которой реализована вся логика приложения. Когда пользователь нажимает на
кнопку, то всю основную логику реализует бэкенд. Важно, чтобы базовые проверки
реализовывались на бэкенде. Если фронтенд — это то, что вы видите, то бэкенд —
это то, благодаря чему всё это на самом деле работает.
Распределенные системы — архитектура, при которой приложение работает не на
одном мощном компьютере, а на множестве связанных серверов. Для пользователя
это выглядит как единый сервис, но внутри задачи распределяются между большим
количеством серверов (их могут быть тысячи). Практически любое современное
крупное приложение, требующее доступа в Интернет (Telegram. YouTube, банков-
ские системы),— построено на этой архитектуре. Распределенные системы —
единственный способ обеспечить работу сервиса для большого количества пользо-
вателей с возможностью защититься от сбоев.
Микросервисы (Microservices) — это подход в архитектуре, когда одно большое
приложение разделяется па множество маленьких независимых программ (серви-
сов). Каждый такой сервис отвечает только за одну конкретную задачу и общается
с другими через эндпоинты.
Контейнер— способ упаковки программы со всеми ее зависимостями (настройка-
ми, библиотеками, кодом) в один изолированный «ящик». который будет работать
абсолютно одинаково на любом компьютере Главной технологией контейнеров
является Docker Если микросервис — это логическая деталь вашей программы, то
контейнер — это стандартизированная коробка, в которой эта деталь хранится и
перевозится
Эндпоинт (Endpoint) — дословно «конечная точка». Это конкретный адрес (URL),
но которому одна программа может обратиться к другой, чтобы получить данные
или отдать команду. Когда все общение в 1Т строится на микросервисах, эндпоин-
ты — это те самые точки, через которые общаются фронтенд и бэкенд.
Enirypoint— дословно «точка входа». Это место, с которого программа начинает
свою работу. Если эндпоинг— это конкретная точка, куда можно постучаться, то
enirypoint — это точка входа, с которой запускается весь процесс. Термин исполь-
зуется в двух смыслах:
♦ в коде — это первая строчка кода, которая выполняется при запуске приложения
(точка старта программы);
♦ в инфраструктуре — это главная команда, которая оживляет ваш микросервис.
Код-фриз (Code Freeze) — период «заморозки» изменений в той части кода, кото-
рая готовится к выпуску. Это не значит, что программисты перестают работать и
оптимизировать код приложения, — перекрывается для добавления новых функций
только основной код, чтобы команда могла исправить имеющиеся в нем проблемы
В современной разработке это работает гибко: разработчики продолжают писать
код для будущих задач в своих «черновиках» (ветках), но в ту версию, которая вот-
вот уйдет к пользователю, вносить в период код-фриза ничего нельзя, кроме ис-
правления ошибок. Таким образом, код-фриз — это период времени на стабилиза-
цию и исправление ошибок в основном коде программы.
Flaky-тесты (от англ, flaky— слоистый, крошащийся, в сленге— «ненадеж-
ный») — тесты, которые ведут себя непредсказуемо: при одном и том же коде они
могут то проходить успешно, то падать без видимых причин. Это одна из самых
раздражающих проблем в разработке. Если обычный тест — это независимый су-
дья, то флэки-тест— судья с разным настроением: сегодня он разрешил вам про-
должить игру, а завтра за то же самое выгнал с поля.
C1/CD — непрерывная интеграция (Continuous Integration) и непрерывная достав-
ка/развертывание (Continuous Delivery/Dcployment). Сложный для понимания не
технического специалиста термин, но понять его весьма важно. Состоит он из
двух част ей
♦ непрерывная интеграция (Continuous Integration, CI) — воспринимается в совре-
менной разработке как само собой разумеющееся и, по сути, является стандар-
том. Если попросить разработчика коротко объяснить, что такое CI, то он, ско-
рее всего, скажет что-то вроде «успешное прохождение сборок на Jenkins».
Слово «интеграция» в рассматриваемом случае означает, что мы интегрируем
вновь написанный код в основной код приложения. А вот слово «непрерывный»
я понимаю как то, что все изменения происходят в моменте, не откладывая на
будущее. То есть проверка запускается еще до того, как код интегрирован.
Аналогия из жизни
Здесь хорошо подходит метафора со сборкой лазла У вас уже частично собрана не-
кая часть пазла, и вы хотите добавить еще одну деталь Непрерывная интеграция
детали в пазл — это, по сути, процесс проверки, подойдет ли кажущаяся подходящей
деталь в предполагаемое место, или примерка ее Иногда кажется, что деталь подхо-
дит, но в действительности мы ошибаемся и оказывается, что на самом деле это не
так С кодом точно так же: мы написали подходящий фрагмент и проверяем — как он
подойдет. Именно эта проверка — и есть CI.
♦ непрерывная доставка, или развертывание (Continuous Delivery / Deployment,
CD),— это логическое продолжение процесса, когда проверенный код отправ-
ляется в жизнь. Если CI — это про качество кода, то CD — это про доставку это-
го кода пользователю. Если попросить разработчика охарактеризовать CD од-
ним словом, он, скорее ucei о, скажет «деплой» (от англ, deploy — развертывать).
Слово «доставка» здесь означает, что наш код успешно доехал до серверов, где
им могут пользоваться. А «непрерывность» — что этот процесс автоматизиро-
ван: как только код прошел все проверки (С1), он без лишних задержек и ручно-
го труда программистов оказывается на рабочем сайте или в приложении.
Аналогия из жизни
Если продолжать метафору с пазлом, то представьте, что вы собираете огромную
картину не просто на столе, а на городской площади для выставки
• CI — это когда вы приложили новую деталь к фрагменту у себя в мастерской и
убедились, что она идеально подошла по пазам и цвету.
• CD— эго процесс, ко>да строитель забирает ваш проверенный фрагмент, везет
его на плошадь и вставляет в общую картину на виду у всех прохожих. Причем де-
лает это мгновенн’ и без ошибок. В итоге прохожие (пользователи') всегда видя!
самую актуальную и максимально собранную версию картины, а вам не нужно ка-
ждый раз лично бегать на площадь
Таким образом, CI/CD (Continuous Integration/Continuous Delivery) — процесс не-
прерывной доставки с фокусом на развертывание в продуктивной среде в любой
момент. Результат: артефакт развернут в staging-среде и готов к ручному релизу в
продакшн-среде. Еще говорят о «развертывании в один клик».
Теперь проверим, что означает: «Наши DevOps'bi настроили CI/CD пайплайны».
У вас должно быть в голове что-то вроде «Маши DevOps-инженеры (специалисты
по автоматизации) сделали так, чтобы код, который написан разработчиком, мог
сам проверяться и доставляться до сайта или приложения».
PRjMR — пул-реквест или мерж-реквест (PulVMerge Request). Запрос на слияние
вашей ветки кода с основной. Используется теми, кто пишет код. Если сказали, что
задача на этапе PR/MR, то код написан и проходят проверки (С1) либо ревью.
Модульные тесты (или unit-тесты)— самый первый и самый детальный уровень
проверки кода. Это маленькие автоматические программки, которые проверяют
работу отдельных, минимальных «кирпичиков» вашего приложения (функций или
методов) в полной изоляции от всего остального Unit-тесты— это фундамент
C1/CD. Потому что без них вы не узнаете, что именно сломалось.
- Приложение 2 -
Справочные материалы
П2.1. Ключевые вопросы
для формирования Product Vision
Этот список вопросов поможет вам структурировать работу на этапе формирования
видения продукта (Product Vision). Не обязательно иметь ответы на все вопросы
сразу, но каждый из них должен быть рассмотрен.
♦ Блок А. Рынок, Ценность и Монетизация.
• Целевая аудитория. Кто конечный пользователь? Кто принимает решение о
покупке?
• Проблема пользователя. Какую конкретную проблему мы решаем? Как поль-
зователь решает ее сейчас?
• Уникальное ценностное предложение. Почему пользователь выберет нас, а не
конкурента или текущее решение?
• Конкуренты. Кто наши прямые и косвенные конкуренты? В чем их сильные и
слабые стороны?
• Монетизация. Как продукт будет зарабатывать (подписка, единоразовая по-
купка, комиссия, реклама)?
• Ценообразование. Сколько готов платить пользователь? Каковы его регуляр-
ные затраты при использовании продукта?
♦ Блок Б. Техническое и Эксплуатационное видение.
• Технологический стек. Какие технологии и языки программирования будут
использоваться?
• Архитектура. Как продукт будет масштабироваться (горизонтально или вер-
тикально)? Будет ли это мультитенантное решение?
• Надежность и безопасность. Какие требования к доступности (uptime) и безо-
пасности данных?
• Лицензирование. Как будет лицензироваться сам продукт? Какие сторонние
лицензии потребуются?
• Регулирование. Нужны ли государственные сертификаты или лицензии для
работы продукта?
• Режим работы. Требуется ли возможность работы в режиме оффлайн?
• Системные требования. Какие требования к оборудованию и инфраструктуре
у клиента?
♦ Блок В. Команда и Поставка.
• Команда для старта. Какие роли (разработчики, дизайнеры, продукт-
менеджер) необходимы на старте?
• Процесс поставки. Как продукт будет доставляться до пользователя (SaaS,
установка на сервер, магазин приложений)?
• Обновления. Как будет организован процесс обновлений и технической под-
держки?
Это далеко не полный перечень, и на старте не обязательно иметь ответы на все
вопросы. Чтобы получить еще вопросы, попробуйте использовать ИИ. Важно по-
нимать любой из вопросов может всплыть неожиданно — и стоить бизнесу дорого.
П2.2. Полная карта этапов
жизненного цикла разработки
На рис. П2.1 представлена полная карга этапов жизненного цикла разработки.
Пунктиром выделены необязательные этапы и движения. Обратите внимание, что
на схеме показаны только основные переходы между этапами Так. например, на
ней не указаны движения к этапу «Протраммирование» в случае найденных оши-
бок на любом из этапов
П2.3> Манифест и принципы Agile
П2.3.1. Agile-манифест разработки программного обеспечения
Мы постоянно открываем для себя более совершенные методы разработки про-
граммного обеспечения, занимаясь разработкой непосредственно и помогая в этом
другим.
Благодаря проделанной работе мы смогли осознать следующее:
♦ люди и взаимодействие важнее процессов и инструментов;
♦ работающее ПО важнее исчерпывающей документации,
♦ сотрудничество с клиентом важнее согласования условий контракта;
♦ готовность к изменениям важнее следования плану.
То есть, не отрицая важности того, что справа, мы все-гаки больше ценим то, что
слева.
Рис. П2.1 Полная карта этапов жизненного цикла разработки
Основополагающие принципы Agile-манифеста
1. Наивысшим приоритетом для нас является удовлетворение потребностей за-
казчика благодаря регулярной и ранней поставке ценного программного обес-
печения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентною преимущества.
3. Работающий продукт следует выпускать как можно чаше, с периодичностью от
пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы ра-
бота была сделана, создайте условия, обеспечьте поддержку и полностью до-
верьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса
8. Инвесторы, разработчики и пользователи должны иметь возможность поддер-
живать постоянный ритм бесконечно. Agile помогает наладить такой устойчи-
вый процесс разработки.
9 Постоянное внимание к техническому совершенству и качеству проектирова-
ния повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у
самоорганизующихся команд.
12 Команда должна систематически анализировать возможные способы улучше-
ния эффективности и соответ ственно корректировать стиль своей работы.
Авторы: Кент Бек, Майк Бидл, Эрик ван Беннекум, Алистер Кокберн, Уорд Кан-
нингем, Мартин Фаулер, Джеймс Грепнинг, Джим Хайсмит, Эндрю Хант, Рон
Джефрис, Джон Керн, Брайан Марик, Роберт С. Мартин, Стив Меллор, Кен Шва-
бер, Джефф Сазерленд, Дэйв Томас.
Оригиналы материалов на hftps://agilemanifesto.org/.
П2.4. Классификация нефункциональных требований
Нефункциональные требования (НФТ) — это все характеристики системы, не свя-
занные напрямую с ее функциями, но определяющие, как эти функции работают.
Выделяют следующие нефункциональные требования:
♦ Производительность — то есть то, как система способна справляться с нагруз-
ками и как быстро реагировать на действия пользователя (или другой системы).
Например: сайт должен выдерживать на!рузку в 100 запросов б секунду (request
per second, RPS), и при этом длительность загрузки страницы не должна превы-
шать 2 секунд.
♦ Масштабируемость — возможность горизонтального (добавление новых сер-
веров при росте нагрузки) или вертикального (увеличение мощности оборудова-
ния) масштабирования.
♦ Надежность — то, насколько надежен программный продукт, то есть сколько
времени он работает (uptime). Измеряют эту величину в процентах (ино1да гово-
рят о числе девяток) — например, 99,9% («три девятки») или 99,99% («четыре
девятки»), Можно проценты перевести в абсолютные единицы, секунды, мину-
ты, часы. Например, 99,9% — это значит, что продукт может не работать 31 536
секунд (примерно 525 минут — чуть меньше 9 часов) в год. Достигаются такие
результаты за счет избыточности (программной или аппаратной),
♦ Безопасность— под требованиями безопасности чаще всего предполагается
разграничение прав доступа, при котором пользователь может не иметь доступа
к части возможностей. Однако иногда в требования безопасности включаются и
требования по шифрованию данных — например, шифрованию графика.
♦ Поставка и обновление— несмотря на то, что сервис может быть облачным, то
есть конечный пользователь ничего не знает о том, как продукт обновляется, к
продукту могут предъявляться требования, особенно по сто обновлению. На-
пример. для сервисов с большим количеством клиентов рекомендуется произво-
дить обновление постепенно: например, 1%, затем 10%, затем остальные. Одна-
ко продукт должен позволять постепенное обновление, поэтому важно такие
требования прописать.
♦ Настройка — требование относительно того, как настраиваются части системы.
Для продуктов, которые используют большое количество установок для одного
пользователя, необходимо подумать о том, как можно управлять настройками
централизованно. Представьте, что будет, если кто-то должен произвести тыся-
чу раз настройку какого-либо приложения, если оно установлено на тысяче хос-
тов. Несмотря на то. что существуют специализированные средства управления
конфигурацией (например. Ansible), в продукте наличие таких возможностей
упрощает работу'
♦ Хранение данных — необходимо ориентироваться на то, что существуют законы
и иные требования, регулирующие хранение данных. Например, хранение пер-
сональных данных требует соблюдения соответствующего закона, а хранение
банковских данных подпадает под законы о банковской деятельности. Кроме то-
го, есть также требования о том, что данные могул храниться только в опреде-
ленной инфраструктуре: некоторые страны требуют, что персональные данные
хранились на серверах, расположенных внутри страны, а требования безопасно-
сти некоторых компаний предписывают, что некоторые критичные данные
должны храниться только в инфраструктуре самой компании.
♦ Удобство использования (UX) — насколько удобно и интуитивно понятно рабо-
тать с продуктом (в частности, с интерфейсом). В LX выделяют как минимум:
эргономику (логичность расположение элементов и удобство их использования),
обучаемость (время для начала работы нового пользователя) и доступность для
людей с ограниченными возможностями
♦ Совместимость — определяет способность системы работать в определенном
окружении. Например, с разными операционными системами или с различными
браузерами.
♦ Сопровождаемость — определяет легкость внесения изменений и обновлений.
Выделяют обычно тестируемость (возможность и наличие инструментов) и мо-
дульность.
♦ Соответствие юридическим и нормативным требованиям — определяет, на-
сколько система соответствует законодательству и отраслевым стандартам. Это
не обязательно законы, но и различные стандарты, требования к лицензиям, ис-
пользованным в продукте.
П2.5. INVEST-модель для пользовательской истории
Пользовательская история (User Story) — это не строгое техническое задание, а ос-
нова для диалога. Поясним каждую «букву» в этой модели:
♦ 1 — Independent (Независимая).
История должна быть максимально независимой от других. Это означает:
• работать над историями в любом порядке;
• избегать блокировок из-за других задач;
• упрощать планирование и оценку.
Ограничение: полная независимость редко достижима, но к ней нужно стре-
миться.
♦ N — Negotiable (Обсуждаемая).
• в процессе обсуждения могут уточняться детали или история может быть пе-
ресмотрена;
• это позволяв! найти оптимальное решение для достижения цели.
♦ V — Valuable (Ценная).
История должна приносить пользу продукту. Если этого нет. то история не нуж-
на. Это то, что указывается в формуле как «Закрытая потребность».
♦ Е — Estimable (Оцениваемая).
Команда должна суметь оценить историю. Если команда не может этого сде-
лать, то можно провести исследование и либо переформулировать саму исто-
рию. либо пересмотреть подход.
♦ S — Small (Маленькая).
История должна быть небольшой. Идеально: 1-3 рабочих дня. Но максимум —
не более 1 итерации (1-4 недели).
♦ Т — Testable (Тестируемая).
История должна быть такой, чтобы ее могли проверить. Если история— это
просто набор желаний без критериев для проверки, то это не пользовательская
история.
Предметный указатель
А KPI (Key Performance Indicators). 133, 268, 280, 281
Acceptance Test-Driven Development (ATDD), 210 Agile, 25, 102,103 ALM-система (Application Lifecycle Management), 121, 186 Artificial Intelligence, AI, 248 L Lead Time (время выполнения), 111 Legacy-код. 201,202 Long-Term Support (LTS), 197
В 0
Backend-pa гработчик, 45 OKR, 134,268,280
c P
Confluence. 150, 187 Cycle Time (время цикла). 111 Performance Review, 267,273,280 Product Ownei, 105
D s
DevOps-инженер, 48 SaaS-сервисы, 34 Scrum, 25, 77, 102, 104, 105, 107, 108, 112, 113, 114, 115, 130
Frontend-разработчик, 45 Scrum-мастер, 105 Short-Tenn Support, 197
1 T
INVEST модель, 183 IT-комьюнити, 264 Test Management System, TMS, 217 Time to Market, TTM, 244
К и
Kaizen, 115 Kanban, 77,102, 104, 108,109,110, 111, 112, 113, 114, 115, 119, 156 Unit-тесты, 194 UX-тестирование. 249
А
Аварийный режим работы, 1 65
Автоматическое регрессионное
тестирование, 210
Автоматическое функциональное
тестирование, 210
Авторизация, 97
Анализ всплесков, 246
Аналитик, 43, 44
Аттестация, 267
Аудит безопасности, 99
Аутентификация, 96, 97
Аутсорс, 26, 27, 28, 31
Аутстафф, 26, 27, 28, 31
Б
Бадди, 59, 261
База знаний, 241, 243
Безопасность ПО, 94
Бизнес-аналитик, 43
Большие языковые модели (Large Language
Models, LLM), 250
Бэкенд, 193
Блклог, 42, 157
В
Варианты использования ИИ, 248
Векторные БД, 252
Велосипеды, 96
Версии LTS, 197
Версии Non-LTS, 197
Версионирование, 205
Видение продукта (Product Vision), 74
Владелец продукта, 42
Водопадный подход (waterfall), 104
Встречи один на один, 146, 267, 270
Входные метрики, 245
Выходные метрики, 245
Г
Графические процессоры (GPU), 252
д
Дизайнер, 44
Диффузионные модели (Diffusion Models),
250
Е
Ежедневные стендапы. 156
Ж
Жизненный цикл разработки, 78
Журнал достижений, 271
3
Закон Путта, 39
Запрос на слияние (pull request/merge
request, PR, MR), 199
Запросы на изменения (Change Request),
236
И
Импортозамещение, 22
Индивидуальные планы развития (ИПР),
267, 278
Инженер технической поддержки, 49
Интегрированные среды разработки
(Integrated Development Environment. IDF).
251
Искусственный интеллект, 248
К
Канбан. 131
Карта продукта (Product Roadmap), 75
Категории ролей. 41
Ключевые показатели эффективности. 133
Консервативные компании, 152
Контекст, 51, 118
Контроль качества (Quality Control), 222
Конфликт слияния (merge conflict), 198
Корнер-кейсы, 212
Критерии готовности, 158
Критерии приемки, 183
Л
Лицо, принимающее решение (ЛПР), 177
Логи, 95
м
Макеты, 187
Менеджер. 41
Ментор. 59, 261, 262, 263
Метод критической цепи, 129
Метрика, 243, 245, 247
Метрика Полярной звезды, 126
Механизм просмотра кода (code review),
199
Мобильный разработчик, 46
Модульные тесты, 194
н
Нагрузочное тестирование. 209
Наставник. 262
Негативные (отрицательные) сценарии, 212
Нетехнические навыки (soft-skills), 259
Нефункциональные требования (НФТ), 180
О
Обеспечение качества (Quality Assurance),
222
Обзор спринта, 162
Обратная связь, 232, 234, 275
Обратная совместимость, 208
Ограничения, 183
Онбординг, 51
Оценка. 258, 260
Оценка 180/360, 268
Оценка эффективности, 267
п
Первичное исследование, 73
План аварийного восстановления, 166
Подход CustDev, 176
Подход Docs-as-Code, 232
Подход JTBD, 178
Подход SMART. 268, 274
Пользовательская документация, 228
Пользовательские истории (User Stones),
182
Пользовательский опыт (User Experience,
UX), 20, 44
Постановка целей по SMART, 258
Правило бойскаута, 205
Предварительная оценка, 158
Приемочное тестирование (User Acceptance
Testing. UAT), 189,219
Принцип DRY, 90
Принцип Fail Fast, 92
Принцип KISS, 88, 89
Принцип YAGNI, 90
Принцип Дилберта, 39
Принцип минимальных привилегий, 97, 98
Принцип Питера, 39
Продуктовые задачи, 122
Продуктовый менеджер, 42
Проектная документация, 230
Проектные задачи, 123
Промпт, 250, 252
Прототипы, 85
Процессная документация. 231
Прямая совместимость, 207
Р
Развертывание, 201
Разработка через тестирование (Test-Driven
Development, FDD), 210, 219
Разработчик. 45
Распределенные системы, 98
Ретроспектива, 163
Ручное регрессионное тестирование, 210
Ручное тестирование, 211
Ручное функциональное тестирование, 210
С
Сборка, 200
Связанная функциональность, 198
Семантическое всрсиопирование (Semantic
Versioning, Sent Ver), 206
Система Git, 198
Системный аналитик, 43
Системы автоматизации (CI/CD), 242
Системы коммуникации, 242
Системы контроля версий, 197
Стек технологий.195
Системы управления задачами, 119
Системы управления тестированием (СУТ),
217.227
Системы управления требованиями (СУТ),
120
Скейлап (scale-up), 17
Снапшоты, 219
Современные компании, 153
Специализированная система управления
требованиями (СУТ), 186
Специализированные модели, 250
Спокойный режим работы. 165
Стратегия поодукта (Product Strategy), 75
Сценарии использования (Use Cases), 182,
185,215
Т
Таек-трекеры, 241
Тестирование безопасности, 100
Тестирование на эмуляторах, 213
Тестировщик. 4о
Т ест-кейс, 214, 215, 249
Тестовая документация, 217
Тестовое окружение, 218
Тестовые сценарии (тсст-кейсы), 212
Техлид, 46
Техническая документ ация, 229
1 ехнические навыки (hard-skills), 259
Технический долг, 202, 203
Технический писатель, 49
Технология RAG (Retrieval-Augmented
Generation, генерация, дополненная
поиском). 252
Тимлид. 41,68
Токены, 251
Транскрибация аудио, 250
Требования по источнику, 181
Требования по уровню иерархии,181
Трекинговые системы, 241
У
Уточнение бэклога продукта, 157
Ф
Файлообменники,243
Формат BPMN, 229
Фримиум-модель. 35
Фронтенд, 193
Фулстек-ратработчик, 193
Функциональные требования (ФТ), 180
Фреймворк, 195
X
Холакратия. 61
ц
Цели и ключевые результаты. 134
ч
Чек-лист, 216, 249
ш
Шифрование данных. 99
э
Эскалация, 169
Разработка
программного
обеспечения
Практическое руководство
для новичков в 1Т-команде
Системное
понимание
процессов
разработки
в российских
реалиях
Рабо га в И команде требует не только профессиональных знаний, но и понимания процессов, ролей и прин
ципов взаимодействия внутри проекта Эта книга помогает пройти путь от первого дня в проекте до уверен-
ного профессиональною роста.
Незнакомые процессы, непонятные термины, страх задать «глупый» вопрос всё это знакомо каждому
новичку в IT. В книг е нет абстрактных теории и сложных технических терминов Тол ько практические навыки
работы в команде.
Что внутри:
Как устроены российские IT-компа н и и и доступные карьерные пути
Практическое руководство по процессам разработки
Эффективная коммуникация в команде и участие в рабочих встречах
Пошаговый план развития: от адаптации до оценки результатов и повышения
Современные инструменты и методы работы с учетом российской специфики
Для кого эта книга:
Для начинающих специалистов всех направлении - аналитиков, тестировщиков, продуктовых менедже-
ров, продуктовых дизайнеров (UX/UI) и разработчиков, которые хотят быстро влиться в команду и понять, как
устроена разработка ПО.
Александр Литвинчук эксперт в области управления разработкой и Agile- коуч. Сертифицированный специалист Scrum Alliance
(CSM). iCAgile (ICP-ATF. ICP-ENT) и Scaled Agile (SAFe Agilist) Более чем за 20 лет прошел путь от npoiраммиста до руководи-
теля крупных подразделении и коуча по гибким ме’одслогиям. Участвовал в создании ПО на всех уровнях — от стартапов
до высоконагруженных систем федерального масштаба Автор умеет переводить сложные процессы на язык здравого смысла
и адаптировать международные практики под российские реалии Связаться с автором можно по адресу электронной почты
htvinchuckifiyandex.ru
191036, Санкт-Петербург,
Гончарная ул.,20
Тел.: (812) 717-10-50,
339-54-17,339-54-28
E-mail: mail@bhv.ru
Internet: www.bhv.ru
(bhv®