#полезности
Хороший канал с авторским

Коллега ведёт очень приятный канал https://t.me/how_to_be_a_pm

Юля как ПМ с декабря 2020 года, разрабатывает образовательные продукты (сейчас в основном для школьников, но есть и для взрослых).

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

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

Настоятельно рекомендую почитать её посты, особенно https://t.me/how_to_be_a_pm/5

​#мнение
Методология не методология?)

Здравствуй, дорогой читатель. Это будет крамольный пост. Надеюсь он заставит тебя порефлексировать. Никакой фрустрации!

Давай сперва начнем с простого вопроса. Какие ты знаешь методологии управления проектами?
Сразу хочется выдать стандартный перечень вроде "Waterfall, Scrum, Agile, Kanban, PMBOK, Prince2 и т.д." Но давай разберемся.

Waterfall - это нарицательное, которое ввел У. Ройс для обозначения предиктивного жизненного цикла разработки ПО. Получается waterfall это просто SDLC.
Scrum - фреймворк управления разработкой продукта.
Agile - набор ценностей и принципов, мировоззрение или философия.
Kanban - метод выявления, управления и развития сервисами нематериального производства.
PMBOK - свод знаний по управлению проектами.
Prince2 - метод по управлению проектами.

Этот список можно продолжать довольно далеко, но я уверен с 75% что ни одной методологии в вашем перечне окажется. Как так? Почему тогда во всех вакансиях пишут "знания методологий". В сердцах хочется воскликнуть, "Да что такое эта ваша методология?"

Давай так и сделаем, заодно разберемся. Похожий вопрос появился в одном чате, привожу ссылку на старт треда https://t.me/kanban_talks/39680

Методика - это конкретное инженерное решение, это делай раз, делай два, делай три - профит. Способ применения чего-то определенного и описанного четко.
Аналогия - чертеж табуретки.

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

Метод - это методика придумывания методик - это уровень чуть выше. Это способ придумывания способов решения проблем.
Аналогия - ящик с инструментами, с помощью которого можно сделать как табуретку, так и доску для серфинга.

Методология - это наука, это способ создания методов - еще более высокий уровень абстракции. Совокупность знаний из различных областей, которая позволяет придумывать методы и все иже с ним.
Аналогия - столярное дело. Знания о том, как применять ящики с инструментами, наполнять их, придумывать новые.

P.S. А теперь вернись к первому вопросу. Так что же у нас есть из методологий в арсенале?

#полезности
Обзор PMBOK 7

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

P.S. Ваню я так называю за глаза, за качество материалов и вклад в популяризацию проектного управления.

Экспресс-обзор PMBoK7:
- Предыдущая версия vs новая (и почему PMBoK 6 не устарел)
- Кратко о PMBoK 7: 12 принципах и 8 доменах - как я на них смотрю и как проще запомнить новую структуру?
- Тем кто планировал сдавать экзамен PMP - на что ориентироваться, нужно ли переучиваться?

1 час 35 минут: https://youtu.be/Y5oDQAYpWjI

#полезности
Полезные каналы и группы. Расширение
Это не продолжение, а именно развитие поста, что выкладывал ранее.
Телеграм давно стал больше чем мессенджером. В нем бурной жизнью живут множество экосистем различных комьюнити. Не является исключением комьюнити ПМов и ежели с ним. Прилагаю список групп и занятных каналов, откуда можно черпать знания, вдохновения и друзей:

Сообщества:
@agile_ru - Можно узнать как правильно имплементировать скрам и почему lean не до конца работает в IT;
@BA_PO_PM_PdM - сидят суровые менеджеры и аналитики, которые расскажут за кровавый энтерпрайз;
@kanban_talks - чат практиков канбан-метода, помогают и разъясняют;
@PM_lunch - сообщество менеджеров проектов преимущественно из СПб, регулярно собираются оффлайн и кушают еду;
@spbspm - более "серьезное" сообщество менеджеров IT проектов из СПб, проводящее регулярные мини-митапы
@pmin_ru - приверженцы PMBOK и акулы календарно-сетевого планирования;
@ru_scrum - сообщество скрам-мастеров и практиков скрама. Хейтерам не заходить;
@FrancisBaconClub - сообщество IT-шников про теорию систем, психология, теория вариаций и прочие жуткие вещи. Новичкам не рекомендуется;
@technicalexcellenceru - uруппа практиков инженерных навыков: TDD, Pair Programming, CI/CD, DevOps
@TeamLeadTalks - чат сообщества тимлидов с суровой культурой, не для слабонервных;
@OgileKambanScram - группа для разбора и объяснения неправильных статей и видео про agile и около него;
@pmclubvrn - клуб проектного управления преимущественно из Воронежа;
@Scrum_Community - сообщество скрам-мастеров вокруг Раффайзена.

Статьи:
@psilonsk
@pm_god
@managerjournal
@selihovkin
@pmdaily
@borisbutton
@beardpm
@ravingrabbid
@sn_hack
@how_to_be_a_pm
@pmclub
@myscrum

События:
@PM_Events
@agile_events
@it_drinkups
@kanban_events
@product_events
@agile_ru_webinars

Канал временно на паузе на неделю, идет квартальное планирование и чувствую себя Грейджоем "То что мертво умереть не может".

#полезности
Занятная конфа от Тинькофф
22 октября приглашаем на Tinkoff Agile Conference. Обсудим лидерство, командообразование, инженерные подходы и практики управления. Тема этого года — «Масштабирование изменений от команд до организации».

Эксперты отрасли и agile-тренеры расскажут о менеджменте инноваций, инженерных подходах, практическом опыте построения компаний. Всего — 16 докладов от спикеров из Авито, Альфа-Банка, Тинькофф, Циана, Scrumtrek и других компаний. Будут воркшопы и, разумеется, афтепати.

Онлайн-трансляция главного зала бесплатна для всех, нужна только регистрация. Участие в конференции офлайн в Москве — пожертвование 2000 ₽ в Фонд борьбы с лейкемией. Регистрируйтесь и переходите по ссылке для оплаты в ответном письме. Очное участие возможно только с QR-кодом.

Подробная программа и регистрация по ссылке: https://v.tinkoff.ru/tac2021

P.S. Нет не продался, это дружественная реклама, организует ее знакомый.

#полезности
Составим компанию PMBoK

Многие в проектном управлении слышали эти заветные слова ПМБОК, некоторые даже пролистывали его и преисполнялись. Но немногие знают что подобных сводов в целом довольно много.
Перечислим некоторые из них:

1) Project Management Body of Knowledge (PMBoK)
2) Business Analysis Body of Knowledge (BABoK)
3) Business Process Management Common Body of Knowledge (CBoK)
4) Data Management Body of Knowledge (DMBoK)
5) Software Engineering Body of Knowledge (SWBoK)
6) Systems Engineering Body of Knowledge (SEBoK)
7) Business Architecture Body of Knowledge (BIZBoK)
8) Information Technology Architecture Body of Knowledge (ITABoK)
9) The Digital Practitioner Body of Knowledge (DPBoK)
10) Automation Body of Knowledge (ABoK)
11) Body of Knowledge and Curriculum to Advance Systems Engineering (BoKCASE)
12) Enterprise Architecture Body of Knowledge (EABoK)

Как уже догадался искушенный читатель почти в любой области есть своды знаний, которые претендуют на звание стандартов.
Они все разные, от 30 страниц в своде по развитию систем и до 1100 в своде по разработке ПО, где то описаны всеобъемлющие подходы и модели, как в SEBoK, а где то только общие черты как в BIZBoK. Общее у них одно - они описывают выжимку хороших практик и структурируют знания в определенной области. Почти как ГОСТы и IEEE).

Правда есть одно большое НО - это BoK-и именно то чем они являются, они не международные или государственные стандарты (хотя PMBoK очень пытается) и делая что-то ровно по ним ним нельзя сделать правильно. Вести холивары за чтобы процессы анализа были как в условном BABoK и по Вигерсу! не имеет особого смысла. Поэтому просто используйте мудрость этих документов и опыт ваших предшественников. Ведь нельзя сказать, что опыт был неправильным, верно?)

#полезности
Канал вместо избранного

Дорогой читатель, я завел канал https://t.me/pm_know_wh , чтобы складировать там все, что не успеваю читать. Почему именно для тебя? Возможно я никогда не прочту эти материалы и они просто останутся лежать до следующей очистки избранного, но тебе они могут быть полезны.

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

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

Есть 3 секретных шаблона:

Шаблон 1: управленческий поединок
Моя роль
На какой должности/роли ты работаешь?
Какие у тебя обязанности и полномочия?

Контекст
Какое направление у компании (FMCG, R&D ML или...)?
Кто вас окружает (какая корпоративная структура/иерархия)?

Проблема
В чем заключается текущая ситуация?
Кого она затрагивает?

Моя цель
Я хочу добиться X, потому что Y

Другие действующие лица
Каковы их роли?
Какие у них интересы/мотивы?

Шаблон 2: методика «ситуации-проблема-решение»
Ситуация
Что случилось, фактология, контекст

Проблема
К чему это привело, почему это проблема

Решение
Предложи какой-нибудь вариант решения, который, по твоему, поможет закрыть проблему (это пункт тоже желателен, потому что тут ты дашь ещё больше контекста + подумаешь «об чат»)

Шаблон 3: взгляд со стороны
Наблюдение
Я заметил что X, перечисление фактов

Ситуация
Это происходит в X, описание контекста ситуации и окружения

Следствие
'Из-за этого' + @наблюдение'+ 'произошло в' + @ситуации + 'и привело к' + @последствию/влиянию.

Главный вопрос
Открытый вопрос, который раскрывает чего вы хотите достичь в этом случае и почему.

P.S. Ни в коем случае не используй эти шаблоны, если не хочешь чтобы окружающие вас поняли и не завяливали множеством уточняющих вопросов. Доказано, что такие шаблоны сокращают время обсуждения в разы и делают его более продуктивными, не важно это обсуждение с руководителем, коллегой или в чатике телеграм. А это совершенно не то, чего ты хочешь, верно?)
2 шаблон от @@revealed_dave

#мнение
Как понять что человек руководитель

Нужно задать ему 2 вопроса:
1) Почему ты хочешь быть/оставаться руководителем?
2) За что ты получаешь/хочешь получать свою зарплату?

Ответы на них достаточно важны, так как позволяют отличать администратора от руководителя. Я не утверждаю что администратор это плохо, это хорошая и конкретная дифференциация труда, но она имеет свои ограничения, которые часто как раз должен преодолевать руководитель.

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

P.S. Кстати вопросы универсальны, подходят как для повышения, так и для собеседования и на них достаточно по разному отвечают джуны и стажеры.

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

Критерием достижимости будем считать количество выпитого сидра и интересных вечеров.

#спонтанный_междусобойчик
Настроение на кутеж
Открытие канала надо отметить, поэтому собираемся @artemletya (Айти ПМ) и @Slava_na_velosipede (Стройка ПМ) в баре. Будем пить, есть и разговаривать о всяком менеджерском.

Место: г. Санкт-Петербург, Социалистическая, 21 "Рыжий рорри"
Время: в 20.45.

Обсуждение здесь

#иное
Бары и менеджеры. Официально
Продолжение теста гипотезы о потребности в сообществе исключительно для встреч менеджеров в барах.

Критерием достижимости будем считать количество выпитого сидра и интересных вечеров.

P.S. Управляю этим как проектом, есть даже устав и Ганта с бюджетом. Из интересного в целях масштабирование на другие города, использование ботов для анонсов и самоорганизации и договоренности с барами. Естественно совершенно неформально.

#официальный_междусобойчик #СПб
Первый дринкап менеджеров
Запустим площадку для встреч менеджеров в барах. Ключевой идеей является синергия атмосферы бара, суровых людей из менеджмента и юмора. Никогда такого не было и вот опять.

Тебе понравится встреча, если:
1) Ты работаешь управленцем или имеешь такой опыт;
2) Любишь общаться с коллегами;
3) Интересно узнать какую шутку можно повторить более 3000 раз.

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

Место: г. Санкт-Петербург, Чкаловский проспект, 50 "Арден"
Время: в 19.00 20 октября (среда)

Обсуждение здесь

#рецепт
Что делать если хочется что-то поменять?
Приветствую тебя, дорогой читатель!

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

Во-первых: полномочия на изменения есть далеко не всегда. Не каждый РП имеет полномочия на управление командой;

Во-вторых: многие работают в крупных организациях, где процессы спущены сверху и вот так просто их не поменяешь.
Так как же вести себя менеджеру, чтобы устранить проблему в процессах? Я бы даже предложил так:

1) Выявить процесс.

Не просто менять что-то абстрактное что не нравится, а конкретно сформулировать что будет объектом усилий и его границы "от сих до сих". Четко сформулировать что идет на вход, а что на выход.

Поздравляю, теперь ты знаешь хотя бы с чем будешь иметь дело и это поможет в пункте 2;

2) Понять потребности.

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

3) Подтвердить проблему.

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

Если в результате информации из пункта 2 и общения окажется что проблема не подтвердилась, то не отчаивайся! У тебя всегда есть инструменты cause-effect диаграмма, FMEA анализ, casual-loop диаграмма, канбан-доска и т.д. За счет этого ты вполне можешь подтвердить что проблема есть и показать это окружающим.

Если же ни общение, ни анализ процесса тебе не помогли, что ж. Залезай на бронивичок и косплей Ленина с "доколе!".

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

4) Получить добро на решение проблемы.

Даже если ты показал участникам проблему, они могут просто не признать что ее надо решать и решать именно тебе. Поэтому нужно сперва показать что вы получите от решения проблемы - "вижен лучшей жизни" или бенефиты (если решим проблему А, то станет лучше Б вот на столько). Ну и конечно получи явное добро либо от большинства группы, либо от самого влиятельного.

5) Применить менеджерские инструменты

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

​#рецепт
Продолжение поста про изменение процессов
6) Готовьтесь огрести

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

Люди могут:

- саботировать процесс
- строить потемкинские деревни
- впадать в итальянскую забастовку и т.д.

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

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

P.S. Многое что есть группах людей (особенно в энтерпрайз компаниях) происходит вопреки, казалось бы, здравому смыслу. Все потому что есть люди и с ними сложно. Главная сила менеджера состоит в умении превращать оковы из людей в возможности
P.P.S. Часть 6 не моя, она от @pimenas Леши Пименова

​#рецепт
Не путаем показатели
Небольшая шпаргалка по показателям, которые очень часто проскальзывают в речи менеджеров по делу и без. Надеюсь после прочтения будет только по делу)

Прогнозируемость = вероятность ошибки прогнозирования.
Эффективность = затраты / результат
Результативность = фактический результат / плановый результат
Точность = абсолютная величина ошибки планирования или погрешность.
План-факт = плановый результат - фактический результат
Производительность = количество результата в единицу времени.
Стабильность = величина отклонения от среднего.

Как только ты перестанешь путать это, можно топать в более тонкие материи вроде Fill Rate, Capacity/Velocity, Lead time, Time to Market, Tact time, Service Level (без A и E) и прочее прочее.

#полезности
Словарь джуна
Коллеги создали табличку с мудреными словами. Авось кому будет полезно.

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

https://docs.google.com/spreadsheets/d/1X1uYlGl9KA5GayIoYOwVKB-1XoBFkA97FqWXSkw73n8/edit?usp=sharing

P.S. Не мое, Автор @egormaryushko

#рецепт
Как включаться в работу на новом месте
Здравствуй, дорогой читатель. Этот пост будет слегка сумбурным и не подкрепленным какими-то прочитанными ресурсами или словами экспертов. Просто мое мнение в чистом виде. И что самое неприятное, так это то что это мнение основано на том, чего я не делал сразу или делал скверно.

Я хочу поговорить о следующем: ты прошел собес, оформился, начался твой первый день и поехал онбординг (если он есть, ха). Речь пойдет не об онбординге для менеджеров как таковом, где разъясняется как все устроено с маленькой буквы. А именно о "КАК все устроено".

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

Я пришел к следующему рецепту из 5 шагов:

1. Дневник людей;
2. Сделать работу каждого руками;
3. Дневник изменений;
4. Личный проект по онбордингу;
5. Регламенты работы менеджера.

Давай подробно разберем каждый из них.

Дневник людей
Ты вел когда-нибудь дневник себя самого? Вот тоже самое, но только про вон тех ребят. По каждому коллеге пиши заметки. Сегодня Василий Петрович был бодрячком, делай проброску в топик кафки поля по задаче. Нужно записывать не так много:

- Настроение и поведение;
- Интересы и вещи которые раздражают;
- Привычки;
- Сильные стороны (это самое сложное).

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

Сделать работу каждого руками
Под каждым имей в виду каждого стейкхолдера. Хочешь понять разработчиков и особенности их работы? Попросись сделать что-то простое сам, с помощью чего ты сможешь понять почему у ребят так долго идет ревью или бомбежку от IDE. Ну и конечно ты станешь к ним ближе, потому что их проблемы буквально станут твоими проблемами и ты их переживешь.

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

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

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

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

Такие причинно-следственные связи нужны чтобы можно было видеть картину целиком. Ну и это открывает путь к ТОС, системного мышлению, cause&effect и т.п

#рецепт
Как включаться в работу на новом месте. Часть 2
Личный проект по онбордингу
Классический проект. С треугольником, только вместо бюджета 1 ресурс - ты сам.
Обязательные артефакты:
1. Устав. Бизнес-кейс, цели, критерии достижения целей, детерминирующие риски, допущения, поставки, ограничения. Такой устав кстати выступает хорошим "контрактом" на испытательный срок, так как описывает что нужно сделать чтобы его пройти с отличием;
2. Матрица требований. Описание того, что конкретно нужно сделать за испытательный срок или онбординг;
3. Реестр рисков. Что может помешать пройти всему как по маслу? Очень даже может быть злющий тимлид, который попросит на выход если ты ему не понравишься и откажется сотрудничать;
4. Матрица коммуникаций. В каждой компании есть набор встреч, созвонов и тд. Знать как они проходят и когда очень важно;
5. Календарный план. Нужно спланировать свое время, чтобы успеть все сделать и не перегрузится.

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

Регламент работы менеджера
Не-не, это не для того чтобы покрыть все свою работу (задницу) бумагами. А именно для того чтобы понять что и как надо делать. Тебе нужно по долгу службы писать ТЗ? Окей, напиши для себя как здесь пишут ТЗ. Сам процесс записи медиативный и позволяет раскладывать информацию по полочкам.

От таких заметок есть и еще несколько польз.:

1. Всегда можно подсмотреть как делается что-то;
2. Если нужно уйти в отпуск/заболеть, то так проще передавать дела.

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

P.S.S Нет пункта "сходить в бар с коллегами", потому что это маст-хев и по умолчанию.