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

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

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

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

Для многих людей с техническим складом ума коммуникации остаются областью, где мало логики и много эзотерики. Мы системно разложим типовые коммуникации тимлида, переложим их в матрицы и фреймы. В итоге вы получите 9-недельный пошаговый план развития своей компетентности в коммуникациях от уровня «новичок» до уровня «шаман».

Нужно ли новоиспечённому тимлиду обучаться руководству командой? Конечно. Но как при этом не ограничиться навыками, нужными руководителю, и продолжать развиваться в своей специальности? А ещё при этом помогать развиваться своей команде?

Про это и поговорим. А ещё про то, чем опасны регулярные встречи, почему знание деталей не равно компетентности, сколько времени руководитель должен посвящать программированию, чему можно научиться у стажёра и чем полезен процесс преподавания.

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

Я расскажу, как менялись процессы разработки, а также роль и задачи тимлида по мере роста бэклога, размера команды и в зависимости от стиля взаимодействия с внешними заказчиками:
- много заказчиков, а тимлид один;
- много заказчиков, тимлид один, но на входе в команду стоит project manager;
- есть отдельные product owner'ы для важных бизнес-линеек, тимлид один, но их нужно больше:)
- много продуктов, много product owner'ов, есть отдельные команды и тимлиды в них;
- появление релиз-менеджеров в командах, которые поддерживают процессы и появление общего процесса улучшения процессов разработки в командах.

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

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

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

I would like to cover examples of how diversity changed the way Spotify is driving its product. I will show how by changing the approach to diversity and inclusion teams can change the way they work. I will cover some practical steps of what has been done in Spotify to address diversity and inclusion issues and what benefits it gave the company, local committees and countries where the company is represented.

Для экзистенциалиста человек потому не поддается определению, что первоначально ничего собой не представляет. Человеком он становится лишь впоследствии, причем таким человеком, каким он сделает себя сам.
(с) Жан-Поль Сартр. Экзистенциализм - это гуманизм

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

И вроде всё хорошо, но вместе с прямохождением в голову начинает лезть всякое.
Вот была у тебя одна система ценностей: хороший код = хорошая работа. Написал сервис = пошёл домой. Сделал фичу = получил премию. А тут целый день на митингах, разговоры, разговоры, разговоры, а потом начинаешь думать: что же полезного-то я сделал. И с ужасом понимаешь, что ничего. “Тварь ли я дрожащая…”, и всякое такое. Но на самом деле…

Для кого этот доклад: для таких, каким я был (и есть) сам. Для тех, кто писал код, а потом вдруг понял, что времени на это всё меньше и меньше. Для тех, кто понял, что работать с людьми - это, вообще-то, не просто. Ну и для тех, кто пока ничего ещё не понял, но уже что-то такое начал подозревать. А менеджеров от природы я почти и не видел.

Тимлидами не рождаются — тимлидами становятся.

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

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

Этап первый: проявляем задатки тимлида, или все начинается с самоменеджмента.
1) Проявляй самостоятельность.
2) Помогай.
3) Анализируй.

Этап второй: я стала тимлидом. Что же дальше?
4) Терпение, терпение и еще раз терпение.
5) Тотальная честность.
6) Делегируй.
7) Экспериментируй.
8) Обучайся.
9) “Мы подумали, и я решила” (с).

Есть ли жизнь без тимлидов, проджект-менеджеров и жесткого давления? Конечно!
Один из принципов agile-манифеста гласит: "Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им".

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

* Категоризация людей по их компетенциям и развешивание ярлыков приводят к переработкам, увеличению срока разработки проекта, увеличению WIP, снижению качества продукта, снижению предсказуемости разработки, демотивирует команду.
* Отсутствие ярлыков с компетенциями не означает отсутствие специализации.
* Для стимулирования естественной или "органической" специализации мы используем: общее владение кодом, разработчик самостоятельно выбирает себе задачи без ограничений, peer code review, общее командное обсуждение требований, общая командная декомпозиция задач.

Три месяца назад моя команда CodeMonkeys работала только над одним компонентом DodoIS - кассой ресторана, в основном на C#.

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

Я отвечу на вопросы, касающиеся фичакоманд, в том числе:
* Чем фичакоманда отличается от привычной проектной команды или традиционной компонентной команды?
* Какие преимущества дает фичакоманда бизнесу?
* Как фичакоманда влияет на качество кода?
* Какие практики экстремального программирования помогают её вырастить?

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

- Зачем управлять знаниями в команде?
- Как вписать управление знаниями в рабочий процесс?
- Что такое "компетенция", "компетентность", "модели компетенций"?
- Как оценивать экспертность и передавать опыт.
- Разбор кейсов: "уход ценного сотрудника", "хочу больше получать", "управление знаниями в процессе разработки".

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

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

Когда у команды широкий и разношерстный спектр задач, требуется четкое понимание того, кто из коллег чем занят, на что он способен.

Мы расскажем о том, как применили две модели, две различные техники создания матрицы компетенций (hard-skills matrix или competency matrix) и привязали к ним процесс обучения и управления знаниями, управления ресурсами внутри команды: knowledge sharing sessions, тренинги, обучения, тесты на понимание, чек-листы и другое, о том, какой, вообще, от этого профит бизнесу и как его обосновать. Нам это позволило понять точки роста сотрудников и в качестве success story добиться для них смены позиции или расширения набора навыков.

После доклада вы сможете применить технику по построению карты навыков и знаний вашей команды.

Доклад будет представлен на опыте отделов разработки и технической поддержки компании Iponweb, мы работаем по модели SaaS, у нас порядка 50 проектов, которые используют один стек и компоненты (http-server, predict machine, reporting), но имеют разную кодовую базу для бизнес-логики. Для нашей компании период включения нового сотрудника в проект сократился с 4-5 до 2-3 месяцев, мы сформировали план обучения и документирования, добавили разнообразные методы управления знаниями и полностью обновили адаптационный план для новых разработчиков.

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

В прошлом нашем докладе на Teamlead conf “Оцениваем разработчиков на основе объективных данных” мы рассказывали, как можно подойти к вопросу измерения работы отдельного разработчика. Теперь мы собираемся поговорить уже не об отдельных разработчиках, а о командах разработки и расскажем, как оценивать эффективность процессов, которые вы заводите в своих командах. Также немного поговорим про теорию ограничения систем и как ее применять для изменения процессов разработки.

Обсудим следующие вещи:
* Немного повторим тезисы предыдущего доклада:
** Где брать данные для метрик? github/gitlab/bitbucket, таск-трекеры, мессенджеры.
** Почему нет одной-единственной хорошей метрики.
** Подход от проблем.

* Поговорим про конкретные процессы в команде и метрики, нужные для их измерения:
** Метрики для процесса планирования.
** Метрики для процесса имплементации в коде.
** Метрики для процесса код-ревью.
** Метрики для процесса тестирования.

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

"Договорились и сделали!" Да? Ага, как же...
Сколько раз, получив от сотрудника положительный ответ или даже клятвенное заверение, что "все будет пучком", мы в итоге получали противоположный результат?

А сколько раз за "да, хорошо" нам четко слышалось "только отстань, все равно завтра уже и сам забудешь"?
Вот и выходит что договорились, да не договорились...

* А почему так получается, и что теперь делать с "этим человеком"?
* А есть ли, вообще, разница между договоренностью, обещанием и обязательством?
* А как увеличить шансы на то, чтобы вышло так, как договорились?

Можно контролировать договоренность, напоминать о ней каждые пять минут. Но это же почти то же самое, что сделать самому! А может, научиться создавать более прочные договоренности?
Вот об этом мы и поговорим!

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

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

Часто перед нами встают вопросы и проблемы:
1) Кого повышать? Заслуживает ли человек повышения?
2) Какой вклад этот человек вносит в развитие продукта?
3) Каков вклад этого человека по отношению к другим членам команды?
4) Как правильно контролировать и учитывать экстренные задачи в общей эффективности?
5) Как контролировать и поддерживать своё внимание к каждому члену команды?
6) Как не забыть чьих-то заслуг или проколов?
7) Как ввести что-то новое, чтобы усилить интерес и вовлеченность коллег?
8) Как настроить команду на соревновательный дух, который идёт на благо продукта?
9) Как мотивировать команду через систему понятных наград и возможностей?

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

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

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

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

Рассказ будет о том, как это воплотить в жизнь, при этом сохранив целостность решения.

Свой доклад я основываю более чем на 5-летнем опыте руководства и взаимодействия с командами разработки (разных размеров и конфигураций). 

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

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

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

Основные поинты:
* Составление портрета кандидата: как определить, кого именно надо нанимать?
* Взаимодействие с HR-менеджером или рекрутером внутри команды.
* Как выстроить коммуникацию с рекрутинговыми агентствами.
* Как вести себя на собеседовании: нетворкинг во время интервью.
* 9 из 10 кандидатов придется отказать после собеседования: как это сделать и заполучить лояльных компании специалистов?

In this talk I would like to cover the organisational structure of Spotify. What is the line between giving more autonomy to the squads while expecting accountability from them? I will cover how the organisational model of Spotify transformed over time experiencing a hyper-growth phase in terms of hiring and scaling of the product and maintaining the company culture. I will describe the leadership model of teams and how we transformed from the approach of Chapter Leads to Engineering managers.

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

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

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

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

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

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

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

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

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

Должен всем и каждому.

После полутора лет работы тимлидом в Lamoda я хотел бы рассказать о том, как я справляюсь со всеми этими задачами, и какие подходы показали себя лучше всего.

Многие команды пытаются работать по Scrum, но обещанной Agile-экспертами магии не случается. Зато порой случаются конфликты, зафейленые спринты и недовольство. Почему так происходит?
“Scrum is: Lightweight; Simple to understand; Difficult to master”(с) Scrum Guide
В Scrum-гайде сказано, что несмотря на простоту, Scrum-ом непросто овладеть. И опыт полностью это подтверждает. В гайде описаны роли, мероприятия и артефакты, но не написано, как правильно организовать работу.
На нашем практическом воркшопе, вы научитесь одному важному практическому навыку. А именно - как в рамках Scrum-фреймворка создать в команде рабочие договоренности, которые заставят Scrum действительно работать.

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

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

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

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

Все боятся брать на работу джуниоров по причине того, что их надо доучивать, их надо интегрировать в команду, с ними надо много работать и ждать, пока они станут нормальными специалистами. А взять джуна на удалёнку — задача вообще невозможная. Как кажется.

Особенность нашей компании в том, что в ней работают только джуны, и почти вся основная команда работает удалённо, при этом разрабатывая быстро и качественно. Как мы этого добились? Что мы для этого использовали и почему достаточно сделать один шаг, чтобы работа с джунами стала более приятной.

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

Эти изменения не так просты, как может казаться на старте. И кажется что это все изменится быстро.

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

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

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

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

Год спустя у меня 30 человек, запущено 6 приложений и большие планы на ближайшие пару лет.

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

В своем докладе я расскажу о процессе организации эффективной команды разработки в banki.ru. Рассмотрим процесс становления команды и какие этапы мы прошли. Расскажу, как мы нанимаем людей в команду, как мы наладили общение и обмен знаниями между командами разработки и как развиваем разработчиков и тестеров внутри команды и отдела.

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

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

За 15 лет .NET отдел в JetBrains вырос из одного продукта-расширения для Visual Studio 2003 в более полудюжины продуктов, которые разрабатывают более 90 человек. Эти продукты запускаются на разных операционных системах, интегрируются в 5 разных версий студии, имеют общие части и тесно взаимодействуют друг с другом. Релизный цикл также изменился от feature-driven релизов примерно раз в год до регулярных date-driven релизов каждые четыре месяца, не считая багфиксов.

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

Я расскажу:
- как нам удаётся сохранять систему стабильной при 900 коммитов ежедневно;
- как и когда билды доставляются пользователям;
- как фичи попадают в продакшн;
- как мы следим за производительностью;
- о том, что ещё хотелось бы сделать.

Планируя сроки релиза, я всегда задавался вопросом: а как в плане учесть то время, которое команда потратит на исправление багов? Попытки оценить риски и предсказать трудозатраты на баги проваливались иногда с небольшим, а иногда с очень большим треском. Баги клиентов всплывали в самый неудобный момент, отрывая добрую половину команды на расследование и исправление. Как результат - сорванные сроки релиза, работа до ночи, чтобы нагнать упущенное время.

Мы проанализировали проблемы, которые возникают при работе с продашн-багами. Учитывая эти проблемы, стали планировать и управлять трудозатратами на исправление дефектов. Изменили workflow работы и ввели новые роли в командах. В результате создали систему, которая навела порядок в работе с багами. Теперь, если мы срываем релизы, то баги продакшна тут ни при чем :)

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