Сколько времени занимает работа

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

В среднем человек бодрствует около 16 часов. На работу, дорогу и всё, что с ней связано, уходит 8–10 часов, а иногда и больше. Получается, профессиональная сфера занимает от ½ до ⅓ активного времени.

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

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

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

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

Сначала ресурс, потом мотивация

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

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

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

На перестройку привычки может уйти от 21 до 40 дней. В этот период сопротивление нормально: новая модель поведения ещё не стала автоматической. Несколько неудачных дней не отменяют весь процесс.

Сильные стороны помогают тратить меньше усилий

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

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

Так можно объяснить ситуацию, когда человек формально справляется с обязанностями, но не чувствует удовлетворения. Результат есть, а ощущения, что работа даётся естественно и приносит пользу, не возникает.

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

Фокус внимания меняет отношение к рутине

Даже интересная работа состоит из повторяющихся действий. Вопрос в том, что именно вы в них замечаете.

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

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

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

Если задачи не вдохновляют

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

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

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

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

Ритуалы снижают внутреннее сопротивление

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

• Свободное письмо в течение 5–7 минут помогает выгрузить накопившиеся мысли.
• Фраза «Я выбираю заниматься своей работой», произнесённая вслух, возвращает ощущение собственного решения.
• Короткая прогулка, чашка чая без телефона или несколько минут тишины дают паузу перед следующей задачей.

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

Психолог Centicore Group Наталья Дремина рассматривает рабочее состояние через повседневные привычки, сильные стороны и фокус внимания.

Удовольствие от работы можно тренировать

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

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

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

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

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

RUNIT by AGIMA — ежегодный фестиваль IT и спорта, который проводится в Москве летом. Впервые он прошел в 2018 году и собрал около сотни сотрудников AGIMA и их друзей, а уже в 2025 году в фестивале приняло участие 10 тысяч IT-специалистов. В этом году фестиваль пройдёт 5 июля в Мещерском парке.

Хотелось узнать, что бег и спорт делают с человеком по-настоящему — куда заводят, какие решения подсказывают, какие оставляют впечатления и воспоминания, над чем потом смеёшься. Получилось честно и местами неожиданно. Героев в этой статье четверо: Алексей Озеров (IT_One), Сайыына Колесова (КРОК), Млада Николаева (AGIMA) и Алексей Лосев (БФТ-Холдинг). Дальше — их дистанция, от старта до финиша.

Старт: «Сайыына, зачем тебе это?»

Почти у всех бег начинался с чужой компании — буквально.

Сайыына Колесова впервые побежала на RUNIT by AGIMA в 2024-м, в разгар адаптации в новой компании, когда записывалась подряд на все активности: «Мне показалось, что будет клёво большой командой в одинаковых футболках пробежать свои дистанции. Раньше я завидовала тем, кто приходит на забеги со своей командой, тоже хотелось быть частью такого драйвового сообщества». Воодушевившись, она выбрала десять километров — и до сих пор об этом жалеет, потому что дистанция далась непросто: «Я бежала и думала: «Сайыына, зачем тебе это?».

Но добежала. И, что важнее, унесла с финиша положительные эмоции: «Я увидела, как много моих коллег тоже увлечены спортом — даже из моего департамента, о чём я и не подозревала. Увидела друзей-коллег с новой стороны, да и себя показала — выжившей. С тех пор наши отношения только крепнут.

Для Алексея Озерова фестиваль — вообще точка отсчёта. «Это особенный для меня забег, с него начался мой беговой путь. Два года назад я пробежал здесь свои первые пять километров и чуть не умер. Год назад тут же была первая десятка». Следующая цель Алексея тоже привязана к фестивалю: первый в жизни полумарафон он хочет пробежать именно на RUNIT by AGIMA.

Стена: не всё так просто

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

Стена Алексея Лосева показалась мне особенно суровой. Он бегает ультратрейлы, и его главная история — «Золотое кольцо» под Суздалем с титульной дистанцией 110 километров. Первая попытка закончилась сходом на девяносто четвёртом километре. Со стороны — обидно, оставалось чуть-чуть. Но он принял это решение как человек, привыкший смотреть вдолгую: «В тот год дистанция была сто пятнадцать километров, каждый давался тяжело. Я решил сойти, чтобы не только вернуться, но и продолжать участвовать в таких событиях долгие годы». Он вернулся через два года подготовки.

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

У Млады Николаевой, которая помимо бега занимается пауэрлифтингом и тайским боксом, была своя стена — жара на петербургском полумарафоне «Северная столица». После первой в жизни половинки (прим. полумарафон, 21 километр) она шла за личным рекордом: «Питер, плоско, лето — что может пойти не так? Ответ: всё».

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

Передышка: футбол, халявные футболки и первое место

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

Самая киношная — у Алексея Озерова, и она про футбол. «Во время легендарного чемпионата Европы, когда наша сборная обыграла Голландию 3:1, я работал в приёмной комиссии Бауманки. После той игры мы на радостях гуляли всю ночь, а утром напрямик пришли в кабинет приёмной комиссии, обвесили его флагами и с раскрашенными в цвета российского флага лицами весь день принимали документы у будущей технической элиты страны».

У Сайыыны Колесовой — история о том, как она случайно стала спортсменкой. Она долго считала себя человеком неспортивным и физкультуру терпеть не могла, пока тётя — тренер по лёгкой атлетике — не отдала ей ворох командных футболок со сборов. «Я ходила в этих халявных футболках на физру, и однажды физрук без объяснений перевёл меня в другую группу. А там оказались университетские легкоатлеты с особой программой. Тренеры, видимо, решили, что футболки мои по праву и я из какой-то сборной. Не спросили, к счастью». Так она «вступила в атлеты», сдала нормативы не хуже других, начала сама ходить в зал и бегать по утрам, доехала до соревнований в Германии: «Ну короче, с тех пор я на спорте».

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

Итог: первое место. «До сих пор одно из самых ярких и смешных воспоминаний. Мы все были просто большие дети, которые с восторгом соревнуются и шутят».

Второе дыхание: что изменил спорт

Самое интересное начинается, когда спрашиваешь не «что спорт дал», а «что поменял».

У Алексея Лосева два таких открытия, и оба выросли прямо из его гонок. Первое — про то, как браться за неподъёмное: «Сложную задачу начинаешь решать, сделав один шаг». Тот самый шаг из лагеря волонтёров, перенесённый в кабинет. Второе он усвоил на финишном отрезке, когда силы кончились и в одиночку он уже не укладывался в лимит: «Я зацепился за группу других участников, вцепился зубами и „рюкзаком“ продолжил с хорошим темпом». Так была закрыта сложнейшая гонка его жизни — не в одиночку. Отсюда вывод: «Сверхдостижений можно добиться только с командой единомышленников».

О том же, но со стороны футбольного поля, говорит Алексей Озеров. «Спорт научил меня командной ответственности. Неважно, кто сыграл лучше, если в итоге вы проиграли. На работе это очень помогает: ты не разграничиваешь зону на свою и чужую, а фокусируешься на общем результате. Это качество я и в других очень ценю».

Млада вынесла из спорта другое — отношение к темпу: «В работе есть соблазн требовать от себя и команды одинаково высокой скорости всё время. Но в спорте так не бывает: есть дни, когда ты летишь, а есть дни, когда главная задача — не сломаться и сделать работу достойно».

Ещё одно важное качество, которое она нашла — спокойствие к ошибкам, своим и чужим: «Один сложный день не определяет человека, команду или весь проект. Иногда это просто сложный день. Выдохнули, разобрали, пошли дальше».

Есть у бега и совсем прикладная польза — он «разгружает» голову. «В процессе голова освобождается от мыслей и проблем, ты как ребёнок находишься в потоке. А вот по завершении, на перезагрузившуюся голову, частенько приходят новые мысли», — говорит Алексей Озеров.

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

Финиш: разные награды

А вот на финише наши герои расходятся — и это, пожалуй, то самое честное и неожиданное.

Для Алексея Озерова главное — эйфория: «Обычно я страдаю с первого до последнего километра, но на 70–80% дистанции накрывает адреналин и особое чувство, когда кажется, что можешь абсолютно всё. Вот это я люблю больше всего».

Алексей Лосев тоже говорит об эйфории от достижения результата, но про финиш стокилометрового трейла говорит почти без слов: «Эмоции сложно описать. Ты отдал себя всего».

Млада на том же финише чувствует другое и подбирает неожиданное для человека со штангой и боксёрскими перчатками слово — умиротворение. «Это не всегда эйфория с фанфарами. Иногда это тихое ощущение: «Я справилась». И оно мне очень дорого».

А у Сайыыны награда вообще не про себя: «Я восторгаюсь людьми — их силой воли, умением жить эту жизнь. Общие тренировки, соревнования или просто молчаливый бег к финишу, когда знаешь, что в этот момент мы все вместе абсолютно счастливы. Наши бегущие сердца бьются в унисон».

Почему RUNIT by AGIMA

Любопытно, что почти никто из них не говорит про секунды в протоколе.

«Это возможность увидеть коллег с другой стороны, позитивный формат и классная программа», — говорит Лосев, которому есть с чем сравнивать. Озеров привязан к фестивалю историей: здесь он начинал и здесь же хочет взять первый полумарафон. Колесова не скрывает мотивации и формулирует её очень обаятельно: «Меня привлекают коллеги. Они заманивают вкусняшками и пивом, и я не против — побегу с ними куда угодно, сколько угодно, возможно даже в +30. Фестиваль даёт почувствовать наше единство».

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

RUNIT by AGIMA пройдёт 5 июля в московском Мещерском парке. В программе — дистанции от детских 200 метров до полумарафона 21,1 км, командные зачёты и эстафеты, а после финиша — фестиваль с музыкой, фудкортом и зонами для своих.

Вместо вывода

Я попросил героев закончить фразу «бег научил меня тому, что…».

На мой взгляд, у Млады получилось мудро: «Устойчивость важнее героизма: не каждый день обязан быть победой, зато каждый может стать шажком вперёд».

А у Алексея Озерова парадоксально-честно: «Научиться бегу невозможно».

Практически гимн получился у Сайыыны Колесовой, им и хочется завершить эту статью: «Бег научил меня тому, что я могу бегать, могу бегать хорошо, быстро и долго. Я могу всё. Я могучий человек!»

Творческая среда требует аккуратного обращения: желание продолжать работу держится на ощущении мастерства, автономности и участия в общем процессе. Управленческая задача состоит в том, чтобы поддерживать внутреннюю энергию каждого участника команды — создавать условия, в которых интерес к ремеслу не угасает, а профессиональный рост становится естественным продолжением ежедневной работы. О том, как построить работу в творческих командах, рассказывает арт-директор Битрикс24 Роман Горшков.

Специфика мотивации в творческой работе

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

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

Как управлять мотивацией творческих команд

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

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

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

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

Культура роста без насилия

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

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

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

Матрица навыков поддерживает культуру ненасильственного роста

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

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

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

Автономность как главный операционный критерий

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

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

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

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

Отсутствие каких-либо KPI у творческих команд приводит к:

• неравному распределению объёма: кто-то перегружен, кто-то недостаточно загружен;
• несправедливой оценке: «заметные» задачи имеют больший удельный вес, в то время как важные, но менее заметные, игнорируются;
• непониманию реального объёма выполненного за сезон;

Цикл операционного лидерства: обучение → разрешение → поддержка

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

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

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

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

Третий — делаем первые пробы в новой зоне ответственности. Обеспечиваем поддержку, задаём правильные проактивные вопросы и так далее.

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

В таком режиме внимание удерживается на ремесле, а не на страхе ошибиться или угадать ожидания руководства. Постепенное укрепление уровня и ровная обратная связь создают естественное ощущение движения вперёд.

Тест займет 3 минуты, но откроет то, о чем ты не подозревал годами...

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

А если захочешь полного очищения — билет на Проектную исповедь уже ждет тебя.

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

Как начинается путь

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

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

История Александра: расти — значит меняться

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

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

Через несколько лет, когда компания росла и менялась, Александр решил попробовать себя на рынке и ушёл. Но спустя время вернулся:

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

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

«Учиться, учиться и ещё раз учиться. Иногда — у коллег, иногда — у себя самого. Сейчас для меня главное — быть не просто начальником, а тем, кто способен вдохновлять других и строить сильную команду».

Я, как HR-директор, часто наблюдаю за такими сотрудниками и вижу: их рост — это всегда результат личного желания меняться и работы системы. У нас принято поддерживать участие в программах MBA, профпереподготовках, открывать доступ к новым проектам. Это не «бонус» — это часть корпоративной культуры.

Мои наблюдения и советы

• Не бойтесь брать сложные задачи. Даже если страшно — именно это движет вперёд.
• Учитесь у коллег: у каждого есть что-то ценное, даже если работаете в разных департаментах.
• Открыто обсуждайте свои амбиции с руководителем. Внутри компании обычно найдётся проект, который станет новым этапом.
• Поддерживайте баланс. Не пренебрегайте отдыхом и не стесняйтесь говорить о своих границах.
• Давайте себе право на ошибку: иногда неудача — это часть пути к росту.

История Рустяма: проверка на прочность

Рустям — человек, который пришёл к нам уже с опытом работы у крупного международного вендора. Первое время ему казалось, что всё под контролем. Но реальность внесла свои коррективы:

«Помню, как в новогоднюю ночь пришлось вместе с клиентом устранять серьезный технический сбой. Это был стресс, но одновременно — проверка на прочность. Оказалось, что в компании всегда найдётся поддержка: руководители, коллеги, вся команда».

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

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

«У нас принято не только замечать успехи, но и обсуждать сложности. Мне помогали наставники — давали пространство для самостоятельности, помогали советом. Программы обучения, общие проекты с руководителями других отделов — все это позволяло смотреть шире».

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

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

Если кажется, что вы «застряли»: план перезапуска

• Аудит себя. В трех колонках: «что умею», «чего не хватает», «какую роль хочу через год».
• Разговор с руководителем (не отчёт, а совместный план): на чём фокусироваться, какой проект взять, кого попросить в наставники.
• Проект вне зоны привычного. Минимум один. Там, где страшно — там рост.
• Обучение «под задачу». Не «вообще курс», а конкретный модуль под текущий гэп.
• Публичность прогресса. Делитесь результатами внутри команды и смежных блоков. Видимость — топливо для возможностей.

История Дениса: ответственность, которая двигает

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

«Каждая выполненная задача — кирпичик к следующему уровню. Но ещё важнее — желание разбираться в новых направлениях, брать на себя больше, чем требуется».

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

«Меня часто спрашивают: что главное для роста? Всё просто: делайте свою работу максимально хорошо, не бойтесь брать дополнительную ответственность, предлагайте свои идеи. А ещё — учитесь у коллег. Иногда разговор с опытным сотрудником дает больше, чем неделя курсов».

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

Непопулярные истины карьерного роста

• Руководитель — не «лучший специалист», а «лучший интегратор». Вас будут оценивать по результатам команды, а не по числу личных подвигов.
• Перфекционизм ограничивает масштаб. Учитесь отличать «должно быть идеально» от «должно быть достаточно хорошо и вовремя».
• Стратегичность — это расписание. Если в календаре нет времени думать про 2–3-летний горизонт, стратегия не случится.
• Выгорание — не слабость, а сигнал. Ресурс — часть профессиональной ответственности. Сон, отпуск, делегирование — инструменты, а не привилегии.

История Виталия: быть лидером и инженером

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

«Компания поощряет активных: если хочешь обучать других — тебя поддержат, хочешь вести проект — дадут команду. Главное — быть готовым учиться постоянно».

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

«Я старался не терять техническую хватку, даже когда занял административную должность. Коллеги доверяют тем, кто говорит с ними на одном языке».

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

«Один научил анализировать сложные ситуации, другой — мотивировать команду, третий — не бояться брать ответственность даже за новые, незнакомые задачи. Совет, который я запомнил: ищи возможности сам — они не всегда лежат на поверхности».

Как формируется среда для роста

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

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

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

И последнее — про вдохновение

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

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

По данным, опубликованным в журнале Nature Human Behaviour, трёхдневные выходные без снижения зарплаты:

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

«Мы опасались, что люди будут спешить и только сильнее выматываться», — говорит социолог Вэнь Фань из Бостонского колледжа, ведущий автор исследования. — «Но этого не произошло. Напротив, стресс снизился».

Пандемия как триггер перемен

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

В исследовании участвовали 2896 сотрудников. Им дали 8 недель на перестройку процессов: меньше встреч и рутинных задач, больше смысла. За две недели до старта и через полгода участники заполняли опросники: «Насколько работа вас раздражает?» и «Как вы оцениваете своё психическое здоровье?» Ответы показали заметное улучшение всех метрик.

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

Немного критики

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

«Когда люди лучше отдохнули, они совершают меньше ошибок и работают интенсивнее», — говорит Педро Гомеш, экономист из Лондонского университета Биркбек. Однако Гомеш хотел бы увидеть более глубокий анализ влияния на производительность.

Вэнь Фань отмечает, что более 90% компаний решили сохранить четырёхдневную рабочую неделю после окончания эксперимента, что свидетельствует об отсутствии опасений по поводу падения прибыли.

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

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

А что вы думаете о четырёхдневной рабочей неделе? Успевали бы справляться со своими задачами? Если вы — менеджер, то поделитесь, как бы вы отнеслись к такому решению в отношении вашей команды?

Как держать себя в тонусе без абонемента к психологу? Разбираем 7 работающих техник.

Метод «10-10-10» — компилируем тревогу перед принятием решений

Уйти в стартап или остаться в корпорации? Затащить новую технологию в проект или не рисковать? Когда принятие решений превращается в цикл бесконечных сомнений, можно использовать метод «10-10-10».

В рамках него важно ответить на следующие вопросы:

• Будет ли это важно через 10 минут?
• Будет ли это важно через 10 дней?
• Будет ли это важно через 10 лет?

Почему это работает?

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

Метод, предложенный исследовательницей Сьюзи Уэлч, активно применяется в когнитивно-поведенческой терапии (КПТ) и стратегическом мышлении. Он помогает дистанцироваться от эмоций и оценивать ситуацию с более широкой перспективы.

Дыхание 4-7-8 — быстрая перезагрузка нервной системы перед демо

На проде баг, заказчик ждет отчёт, CI/CD свалился — паника. Чтобы быстро вернуть контроль, используйте технику дыхания 4-7-8.

Что делать?

1. Вдохните через нос на 4 счёта.
2. Задержите дыхание на 7 счётов.
3. Медленно выдохните через рот на 8 счётов.
4. Повторите 3–5 раз.

Почему это работает?

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

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

Grounding 5-4-3-2-1 — техника заземления перед тревожным созвоном

Ошибка в коде перед дедлайном, жёсткое ревью от тимлида или проваленное демо перед заказчиком — стресс накатывает волной, а пустота внутри нарастает, кажется, что всё выходит из-под контроля. В такие моменты помогает метод 5-4-3-2-1 – он быстро возвращает в реальность и снижает тревожность.

Что делать?

По очереди назовите:

• 5 вещей, которые вы видите (монитор, клавиатуру, кружку с кофе, окно, рисунок на стене).
• 4 вещи, которые вы слышите (жужжание компьютера, шум улицы, шаги коллеги, свой собственный голос).
• 3 вещи, которых касаетесь (стул, ткань футболки, мышка).
• 2 запаха, которые ощущаете (аромат кофе, свежий воздух).
• 1 вкус во рту (мятная жвачка, остатки обеда).

Почему это работает?

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

Когнитивная реструктуризация — не ведемся на токсичное ревью

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

Что делать?

1. Зафиксируйте автоматическую мысль.«Тимлид меня не уважает, раз так жёстко критикует мой код».
2. Оцените её обоснованность. Есть ли доказательства этому? Возможно, критикуют не вас, а предложенное решение.
3. Сформулируйте альтернативу. «Тимлид заботится о качестве кода, а его комментарии помогают мне расти».
4. Проанализируйте эмоции.Раздражение ослабло? Скорее всего, да.

Почему это работает?

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

Отложенное беспокойство — как не думать о баге всю ночь

Собеседование завтра, дедлайн через два дня, а вы зациклились на мысли: «А что, если я провалюсь?» Чем больше её проигрываете, тем сильнее тревога. Вместо того, чтобы весь день накручивать себя, попробуйте технику «отложенного беспокойства».

Что делать?

• Выберите фиксированное время (например, 18:00), когда будете тревожиться.
• Когда тревожная мысль появится, говорите себе: «Я подумаю об этом в 18:00».
• Когда придёт время, пересмотрите свои переживания — часто оказывается, что беспокоиться уже не о чем.

Почему это работает?

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

Прогрессивная мышечная релаксация (ПМР) — снятие напряжения после кодинга

Пальцы сжимаются в кулаки, плечи напряжены, челюсть скована — всё это сигналы стресса. Такое бывает перед важной презентацией, сложным код-ревью или после дня, полного дедлайнов. Чтобы прервать этот цикл, используйте прогрессивную мышечную релаксацию (ПМР).

Что делать?

1. Найдите спокойное место. Сядьте или лягте, закройте глаза.
2. Сожмите кулаки на 5 секунд, затем расслабьте.
3. Поднимите плечи к ушам, задержите на 5 секунд и отпустите.
4. Плотно сожмите зубы, затем расслабьте.
5. Напрягите икры, задержитесь на 5 секунд и отпустите.
6. Повторите 2–3 раза, начиная с наиболее напряжённых зон.

Почему это работает?

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

Холодная вода — быстрая перезагрузка нервной системы

Руки дрожат, сердце колотится, а в Jira появляется та самая таска? В такие моменты помогает резкий перепад температуры. Всего несколько секунд контакта с холодом резко снижают уровень стресса.

Что делать?

1. Ополосните холодной водой лицо или руки.
2. Подержите запястья под ней 10–20 секунд.
3. Приложите охлаждённый компресс к шее или лбу (если есть возможность).
4. Глубоко вдохните и выдохните, наблюдая, как тело реагирует на холод.

Почему это работает?

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

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

Когда пора к специалисту?

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

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

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

Зачем отделять "естественное" от "нормального"?

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

Нормальное — это:

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

Естественное — это:

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

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

Страх перед переменами

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

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

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

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

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

Идеального момента не существует

Ожидание идеального момента — это самая хитрая ловушка, в которую мы попадаем. Нам кажется, что нужно подождать: "ещё немного", "до понедельника", "до следующего месяца". Но правда в том, что идеального момента не бывает. Единственное время, когда вы можете что-то изменить, — это сейчас.

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

Мантры не нужны — нужны действия. Вместо того чтобы повторять себе, что "сегодня всё изменится", просто сделайте что-то. Пусть это будет даже незначительное улучшение, но оно уже двинет вас в нужном направлении.

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

Как принимать перемены

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

1. Неудачи — это опыт. Каждая ошибка учит вас чему-то новому. В следующий раз вы уже будете знать, чего избегать или как сделать лучше. Не воспринимайте провал как конец пути — это просто часть обучения.
2. Перестаньте ждать идеала. Перфекционизм парализует. Лучше сделать что-то "достаточно хорошо", чем ничего вообще. Помните: совершенство — это цель, к которой вы можете постепенно приближаться, но не с самого начала.
3. Разделите цель на шаги. Большие перемены пугают, потому что выглядят слишком сложными. Разбейте задачу на небольшие части и двигайтесь поэтапно. Каждый выполненный пункт приближает вас к результату.
4. Фокусируйтесь на настоящем. Не думайте о том, что будет через год, месяц или неделю. Сосредоточьтесь на том, что вы можете сделать сегодня. Маленькие шаги в настоящем строят большое будущее.
5. Создайте пространство для анализа. Найдите время, чтобы понять свои успехи и ошибки. Это позволит лучше понимать, куда двигаться дальше. 15 минут размышлений после завершённого этапа могут значительно ускорить ваш прогресс.
6. Позвольте себе отдыхать. Выгорание — главный враг перемен. Делайте перерывы, чтобы восстановить силы и сохранить мотивацию.
7. Будьте готовы к трудностям. Путь к изменениям никогда не бывает простым. Понимание этого заранее избавит от лишнего стресса.

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

Отдых и анализ – единственное, что вам поможет

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

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

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

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

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

• Риск — это норма. Примите его как неизбежность. Без риска нет роста, а значит, нет движения вперёд.
• Живите здесь и сейчас. Откладывая действия, вы упускаете возможности. Что-то можно начать уже сегодня: прочитать статью, изучить новую тему, сделать короткий шаг к цели.
• Сосредоточьтесь на процессе. Результат важен, но именно маленькие, регулярные действия приводят к успеху. Цените каждую победу, даже если она кажется незначительной.

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

Мы пообщались с сотрудниками и экспертами сопровождения Яндекс Практикума и составили обширный лонгрид, в котором вы найдете фишки для выстраивания эффективного и живого общения с командой.

Оглавление

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

Почему важно живое общение

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

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

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

Мидлам чаще приходится применять софт-скилы: помогать, давать обратную связь джунам, проводить встречи и т. д. Развитое живое общение поможет наладить с коллегами понимание и потенциально вырасти в должности — сеньоры пользуются софт-скилами чуть ли не чаще, чем хардами. И помочь в этом может Школа наставников Яндекс Практикума.

Как организовывать созвоны, от групповых до 1-2-1

Самые ходовые инструменты: Discord, Zoom, Microsoft.Teams, Google.Meet

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

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

У нас распределенная команда, все работают удаленно из разных точек России, поэтому я старался делать дополнительные слоты, в которые мы могли бы собраться и во что-то позалипать. Мы играли в онлайн-версию испорченного телефона: дорисовывали картинки друг за другом и дописывали истории, чтобы сплотить ребят. Для этого тоже использовали Discord.

В Zoom или Meet есть свои плюсы — можно записать митинги. Но есть и минусы: если кто-то что-то обсуждает, ты не можешь к ним как в офисе подойти и послушать, что они говорят. А Discord как раз это решает.

Как готовиться и проводить групповые созвоны

Для начала нужно объяснить, зачем человеку приходить на встречу. Сформируйте и зафиксируйте в описании цель встречи, адженду, тщательно продумайте состав участников: точно ли вам нужна вся команда?

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

Собирайте ожидания от встречи

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

Проводите разминки

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

Контролируйте общий план созвона, чтобы не отклоняться от курса

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

В такие моменты важно говорить уверенно: да, было!

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

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

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

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

Проводите шеринг и дебрифинг

Шеринг — это когда мы дали блок информации или провели какую-то активность, а потом спрашиваем, какие у вас чувства, эмоции относительно этого, что думаете?

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

Вернуться в начало

Что делать с 1-2-1

1-2-1 можно проводить регулярно, когда к команде присоединяется новый участник. Нужно отслеживать в каком он состоянии, как адаптируется.

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

Фиксируйте, что обсуждали ранее — лучше обезличенными формулировками

У меня всегда были записки о предыдущей встрече, что я должен сделать на следующей. Я выбирал однозначные обезличенные формулировки, чтобы человек понял и не ушел в защиту. Например, если у меня есть вопросы к перформансу сотрудника, я спрашивал: «Если 100% перформанса, это тебя никто не отвлекает, то какой у тебя сейчас процент от 100%?». Мы выявляли, что не так, и тогда можно было давать обратную связь о том, что мешает человеку достичь результата. То есть я пытался заставить его рефлексировать, дать ответ и возможность помочь ему.

Как давать обратную связь

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

Добавляйте конкретики

К примеру, даже в похвалу. Недостаточно просто сказать — «Ты классный сотрудник». Человек может испытать какую-то эмоцию, но что делать с этой информацией, непонятно. Важно сказать, что именно вы сюда вкладываете, что именно мне нужно продолжать делать в моей хорошей работе, чтобы она продолжала быть хорошей.

Сначала учите, а потом лечите и мочите

Это метод, при котором вы объясняете человеку, почему его действия плохие. Возможно, он просто не знает. Когда вы убедились, что он вас понял, то объясняете, как делать правильно, а уже потом даете фидбэк. До стадии «мочить» я не доходил, обычно во второй мы пытались выправить поведение.

Также есть метод «Пинок»:
P — это позитив,
IN — что-то, что можно доработать,
N — это негатив,
OK — самая важная часть — понял ли человек обратную связь.

Многие менеджеры команды сопровождения рассказывали, что команда просит не использовать метод сэндвича — позитивная обратная связь, потом критика, потом снова что-то приятное.

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

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

Вернуться в начало

Как разрешать конфликты

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

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

Выводите людей на чистоту

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

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

Как проводить брейнштормы

Самые ходовые инструменты: Miro, Jam, Draw.io, Microsoft Whiteboard, Plant UML

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

Важно ответить на такие вопросы:

• Кто модератор?
• Где проводить брейншторм?
• Как потом транслировать результаты?
• Сколько времени нужно заложить на выступление?
• Как эффективно выстроить коммуникацию?

На брейншторме должна быть «строгая» модерация

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

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

Разбивайте большую команду на маленькие группы

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

Мы использовали Miro и аналоги: в Meet есть Jam, Draw.io, но они не такие удобные. Для брейнштормов архитектуры мы готовим UML-диаграммы, их можно редактировать в режиме реального времени. То есть кто-то пишет код, и он появляется на картинке. Потом его можно перекинуть в Notion.

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

Вернуться в начало

Как организовать трекер

Самые ходовые инструменты: Jira, Notion, Redmine, Яндекс.Трекер, ClickUp

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

Выделите у цели четкие стадии работы

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

Кастомизируйте любой инструментарий под свой бизнес-процесс

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

Например, я использовал ClickUp, но там нельзя давать тикет по номеру. В Jira это очень удобно: название проекта, несколько букв и номер. Он легко запоминается, в ClickUp такой штуки нет. Там ID какой-то просто набор букв, и ты никогда в жизни его не запомнишь.

Используйте Kanban-доски

У нас командная работа организована в Notion по Kanban. Есть 4 вертикальные колонки: сделаны, в работе, в плане на спринт и жду ответ. А в горизонтальных колонках указаны ответственные. И, соответственно, они скрываются, открываются как выпадающие списки, то есть мы можем всегда зайти и посмотреть, кто что из нас делает.

Добавляйте фишки в оформление

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

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

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

Вернуться в начало

Как организовать общение в течение дня

Самые ходовые инструменты: Telegram, Mattermost, Slack, Discord

Мемы — это тимбилдинг

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

Заведите отдельный канал для разгрузки

У нас был канал в Discord, где можно было поделиться честным мнением о чем-то. Если ты не хочешь быть токсичным, но при этом хочешь выразить то, что тебе совсем не нравится, ты можешь написать туда: бесит Flask — и слить в канал свои переживания.

Сообщайте коллегам свои рабочие часы

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

Как в развитии софтов может помочь школа Яндекс Практикума

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

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

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

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

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

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

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

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

Школа наставников доступна всем, кто пройдет этапы отбора на роль наставника в Практикуме. Узнать, какие роли открыты сейчас, можно здесь.

Реклама АНО ДПО «Образовательные технологии Яндекса», LjN8JtbN9

Чтобы работа в команде была продуктивной, нужно найти для всех общий знаменатель с точки зрения знаний и постепенно расширять эту базу, чтобы лингвистам было проще общаться с ML-инженерами, а аналитикам с MLOpsa’ми. Причем хочется делать это так, чтобы всем в команде это было полезно и интересно. В статье я расскажу, как мы решали эту задачу.

Кейс 1: курс по машинному обучению

Началось все в 2020 году, когда я был единственным дата-сайентистом в одной команде. Ко мне часто обращались с вопросами про машинное обучение. Наши разработчики (крутые специалисты по C++, C# и веб-разработке на Python) спрашивали меня время от времени о том, как работают нейросети и чем они отличаются от других алгоритмов.

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

В качестве материала мы взяли уже готовый курс — Practical Deep Learning for Coders от fast.ai. Казалось бы, то, что нужно — практический курс с необходимым количеством теории, специально нацеленный на разработчиков. В качестве формата выбрали так называемый «перевернутый класс»: когда готовые лекции смотрите в своем темпе и встречаетесь на семинарские занятия, где разбираете сложные части уроков, обсуждаете интересные моменты, а семинарист (то есть я) отвечает на вопросы.

В команде у нас в основном были люди, которые пишут на C++ и C#. На первом семинаре все в первую очередь обсуждали, как питонисты живут без типов и насколько изящно (или не очень) переопределен оператор деления в pathlib. В чате, где мы все координировались, перед вторым семинаром не появилось ни одного вопроса — а если нет вопросов, то и встречаться незачем. Не уверен, смотрел ли кто-то вообще третью лекцию. После нее (напомню, это был 2020 год) начался карантин и наши очные встречи закончились.

Зачем и как учиться на работе?

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

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

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

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

Совместным обучением можно достичь и иных целей. Это может быть и тимбилдинг, когда все в одно время собираются и вместе читают статьи (возможно, с пиццей). Или ощущение, что мы работаем в R&D и занимаемся чем-то наукоемким — вместе изучаем что-то новое, находясь на острие знаний. В процессе мы также погружаемся в проекты друг друга и обмениваемся нашей уникальной экспертизой. Наконец, можно развивать культуру дискуссии: обсуждение статей, например, позволяет более безопасно обдумывать и критиковать идеи, чем когда речь заходит о коде коллег.

Но кросс-функциональность команды накладывает определенные требования к выстраиванию совместного обучения. Представьте команду исследователей, которая занимается компьютерным зрением, допустим, улучшением алгоритмов распознавания лиц. Для них таким совместным форматом может стать чтение статей c state-of-the-art в той теме, которая им интересна. Например, чем YOLOv8 отличается от предыдущего или додумался ли кто-то приделать модные диффузии к распознаванию лиц.

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

• NLP-исследователь. Ему может быть не очень интересно разбираться в Kubernetes и слушать про лучшие практики в Docker.
• Data Scientist, который больше общается с бизнесом и занимается поддержкой цикла проекта. От одного словосочетания «гиперболические эмбеддинги» (обсудить которые до появления мощных языковых моделей любили NLP’шники) его начинает клонить в сон.
• MLOps, на плечах которого ML-инфраструктура. Слушать про бизнес-темы, в частности, про то, что такое AI Canvas и как он помогает в разработке проекта, ему не очень интересно.

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

Почему онлайн-курс не удался?

Вернемся к разбору первого кейса и ответим на вопрос: почему не получилось?

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

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

Кейс 2: исследовательский семинар

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

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

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

Кроме того, выяснилось, что мы предпочитаем разные статьи. Ребята из нашей команды предпочитали статьи про конкретные инструменты для определенных задач (например, про SHAP), а коллеги — более фундаментальные и менее непосредственно применимые. В итоге у них возникало ощущение, что из-за нас научный семинар превращался в научпоп.

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

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

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

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

Кейс 3: книжный клуб

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

Почему?

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

Кейс 4: Friday Wins&Fails

Еще одна коллега пришла с идеей рассказывать про проекты с точки зрения бизнеса. Называлось это Friday Wins&Fails. Идея была такая: раз в несколько недель кто-то вызывается и проводит в пятницу небольшую презентацию об удачном или неудачном опыте. В этот раз цель была понятная — показать, что даже исследовательские проекты не существуют в вакууме, а имеют заказчиков, метрики успеха и необходимость об этом думать.

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

Основные ошибки

Я рассмотрел четыре неудачных кейса. В чем же были ошибки:

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

Кейс 5: снова онлайн-курс

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

Мы декомпозировали задачу на две части:

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

Начали с целеполагания.

Чем мы занимаемся? Берем задачу, анализируем данные, создаем ML-систему и поставляем клиенту. Человек, который общается с заказчиком, занимается статистикой и анализирует метрики, должен взаимодействовать с тем, кто непосредственно обучает модель. А тому, кто ее разрабатывает и выбирает подходы, нужно взаимодействовать с MLOps’ом, который это выкатывает и обеспечивает мониторинг метрик, который должен быть удобен первому человеку. То есть нам нужно надежно делать весь цикл и говорить друг с другом на одном языке.

Исходя из цели «говорить на одном языке» мы и выбирали материалы. В итоге сошлись на бесплатном курсе Full Stack Deep Learning. Он посвящен тому, как на практике вести ML-проекты от поиска идеи до мониторинга, а также используемым для этого инструментам.

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

В качестве формата снова выбрали перевернутый класс, но на каждый семинар выбирался ответственный, который кратко (на 20 минут) подсвечивал основные моменты в лекции через призму тех задач, с которыми встречаемся мы. Расписание и список рассказчиков с темами были заранее зафиксированы в вики. После рассказа каждый по очереди должен был за 2-5 минут поделиться своими соображениями о материале. Обсуждения вместе с идеями, что где можно попробовать или сделать лучше, и соответствующими action items фиксировались на отдельной странице.

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

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

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

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

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

Подводя итоги

Можно вывести ингредиенты успеха для совместного обучения в команде:

• Целеполагание. Нужно понять, чего вы хотите добиться, организуя совместное обучение. Мало поставить цель, важно еще и донести ее до команды и убедиться, что она ее приняла. Без этого едва ли получится достичь нужного уровня мотивации и вовлеченности.
• Формат. Важно продумать формат с учетом факторов гибридной или удаленной работы, других регулярных задач и прочих возможных ожидаемых и неожиданных проблем вроде потенциальной загруженности.
• Администрирование. Даже самой классной и ответственной команде иногда нужен волшебный пинок, который заставит их все-таки прочитать материал и посмотреть семинар. В самом мягком варианте — заранее назначенные ответственные и встреча в календаре.
• Ритм. Очень важно, чтобы встречи происходили с заранее обговоренной периодичностью, чтобы поддерживать привычку и не терять мотивацию.
• Релевантность. Материал должен быть релевантен рабочим задачам, которые выполняют участники. Если им кажется, что это не так (а вы уверены, что материал полезный), их нужно в этом убедить.
• Планирование. Лучше все шаги, встречи и даже сбор фидбэка продумать заранее. Если начать с мыслью, что «как-нибудь разберемся», любые потенциальные проблемы могут выбить из ритма.

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

Что от программиста хочет менеджер

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

• Ретроспектива — разговор о прошедших событиях с целью улучшить будущие;
• Стендап (летучка) — короткая утренняя регулярная встреча для синхронизации коллег на день;
• Планирование спринта — селекция задач на ближайший спринт;
• «Нытинги» — неформальные встречи с обсуждением наболевшего в жизни в целом.

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

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

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

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

Как бороться с нежеланием

Контейнирование

Если сократить число встреч не удается, на помощь вам может прийти психологическая техника — контейнирование. Нет, здесь имеется в виду не упаковка приложения в Docker. Это способ справиться с эмоциями.. Не подавить, как это принято в русской культуре, а именно:

• осознать, что испытываешь в преддверии митапа;
• дать чувствам название (например, разочарование).

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

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

• «взломать социальный код»: договориться о посещении встречи через раз, поставить обои с собой на митап с большим числом участников, где ваша речь не потребуется.

Ритмика: где взять время

Если ваш календарь «наводняется» встречами и вызывает негатив при одном просмотре, то добавление паттерна дня / недели поможет. Организм человека любит режим и умеренную повторяемость, потому не трогайте свой «островок безопасности» — обеденный перерыв, например. Когда коллега просматривает ваш Google-календарь и предлагает занять слот, настаивайте на «ритмичном» для вас времени. Или займите эти слоты вымышленным мероприятием с таким названием, чтобы сомнений не возникало: вы в этот момент заняты важным делом.

Календарь коллеги-аналитика. Хорошо, что разработчики — ценный ресурс. Шансы установить ритм, не занимая окно 11-12, повыше многих других профессий

Учитывайте базовые потребности

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

Усилием воли мы можем игнорировать нужду поесть и поспать, но в долгосрочной перспективе это выльется в необъяснимое, на первый взгляд, нежелание работать. Потому «рывки хакатонщика» (два дня не сплю, но сделаю) стоит практиковать вкупе с последующим мини-отпуском.

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

Заключение

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

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

Как всё начиналось

Как и у большинства разработчиков ПО, мои обязанности были довольно предсказуемыми. Я получал задачу с фиксированными сроками выполнения или сам решал, когда могу её сделать, согласовав с менеджером. Дальше спокойно писал код, регулярно ходил на дейли, единственные вопросы, которые у меня возникали — как лучше выполнить ТЗ, оптимально реализовать алгоритм или запрос в СУБД. А в должности ведущего разработчика вместе с этим распределял задачи между джунами и мидлами, общался с аналитиками и решал другие вопросы, связанные с реализацией системы для проекта.

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

Оказалось, что стать техменом в 38 лет — это, вероятно, как родить первенца в таком возрасте. Появилась масса вопросов, задач и проблем, о которых я не подозревал, хоть и считал себя уже зрелым и опытным специалистом. Выяснилось, что общаться с людьми и выстраивать работу команды — это ничуть не менее сложная задача, чем разработать алгоритм размещения контейнеров на судне, настроить ядро Linux под работу на 486 промышленном процессоре, или написать фреймворк для веб-приложений. Неопределённость и вероятность стали не изолированными математическими понятиями, а новой реальностью. Появилась ответственность не только за модуль в программе, но и за успех всего проекта. Тогда я понял, что мне ещё многому нужно научиться.

Я учился общаться и искать компромиссы

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

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

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

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

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

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

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

• сгруппировать вопросы,
• проработать варианты ответов,
• продумать возможные решения для разных вариантов.

Причём в процессе подготовки часть вопросов обычно решаются сами собой.

Мне помогли курсы и семинары по тайм-менеджменту. Навык управления своим временем здорово уменьшает процент суеты и нервозности и одновременно с этим добавляет структурности и предсказуемости в работе над проектом.

Оценивать будущий проект и не поддаваться давлению

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

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

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

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

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

Доверять команде и позволять ей выполнять свою работу

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

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

Работа с людьми стала для меня самым непривычным опытом

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

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

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

Не «Ты допустил ошибку», а: «Здесь допущена ошибка» — почувствуйте разницу.

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

• внимательно слушать;
• игнорировать намёки на грубость и попытки уйти от темы;
• переводить разговор в конструктивное русло.

То есть ставить акцент не та том, кто виноват, а на том, что делать; концентрировать внимание собеседника на общей задаче и способе её решения.

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

Как мне работается сейчас

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

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

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

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

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

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

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

Страх отправить резюме

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

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

Простой способ справиться со страхом

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

Страх не пройти собеседование

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

Чтобы каждое собеседование не ввергало вас в панику, выработайте навык их прохождения.

1. Учитесь рассуждать

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

2. Помните, что любое собеседование — это опыт

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

• какие вопросы чаще всего задают молодым специалистам (и понять, какие ответы уместны);
• отрепетировать самопрезентацию, чтобы мучительно не вспоминать свои сильные качества;
• придумать, как демонстрировать не только хард, но и софт-скилы;
• выяснить, что зацепило потенциального работодателя, а что, наоборот, смутило в вашем резюме.

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

3. Не относитесь к собеседованию как к экзамену

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

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

Простой способ справиться со страхом

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

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

Страх пройти собеседование

Бояться работы до того, как вам её предложили, не стоит. Но конечно, вас могут мучить самые разные мысли: «А вдруг они не поймут, что я чего-то не знаю и не умею», «А вдруг я не впишусь в коллектив, там же все крутые», «Кому я буду нужен со своими тупыми вопросами».

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

Простой способ справиться со страхом

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

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

Бояться и делать

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

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

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

Разбираем 7 причин, почему так происходит, и рассказываем, что с этим делать.

Причина № 1. Прогресс становится менее заметен

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

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

Что делать

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

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

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

Причина № 2. Хватаетесь за всё подряд

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

Что делать

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

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

1. Изучить синтаксис JavaScript.
2. Понять переменные.
3. Научиться пользоваться операторами — арифметическими, логическими, условными и сравнениями.
4. Освоить циклы.
5. Изучить функции.
6. Написать первую простую программу, например, вычисление факториала числа.

Теперь он знает, на чём нужно сфокусироваться, и не будет отвлекаться, например, на Document Object Model.

Причина № 3. Нет ощутимого результата работы

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

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

Что делать

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

Причина № 4. Вы устали

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

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

Так организм реагирует на перенапряжение. А ещё есть эмоциональные признаки:

• Не хочется браться за учёбу.
• Появляется прокрастинация.
• Мысли об образовании и самообразовании вызывают тревогу.

Что делать

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

Если взять отпуск возможности нет, тогда можно сделать следующее:

• Наладить распорядок дня. Ложитесь и вставайте примерно в одно время, спите минимум 6–8 часов, чтобы организм мог восстановиться, а мозг снова начал воспринимать информацию.

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

• Отложить занятия и возвращаться к ним постепенно. Когда почувствуете в себе силы заниматься, не кидайтесь в омут учёбы с головой. Возвращайтесь к самообразованию постепенно — например, по полчаса в день. Иначе есть риск перегрузить мозг информацией и снова выгореть.

Причина № 5. Отстали от учебной программы

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

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

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

Что делать

Есть слона по кусочкам. Даже самая большая задача не будет такой страшной, если разбить её на подзадачи.

• Закрыть долги по учёбе — звучит очень сложно, непонятно, как к этому подступиться.
• Составить план по закрытию долгов — уже проще.

Причина № 6. Не хватает поддержки

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

• «И зачем ты потратил такую гору денег на этот курс? Всё равно тебе не стать айтишником»
• «Что, захотел огромную зарплату? Не жили богато — нечего и начинать»
• «Ну что ты всё копаешься в своём компьютере? На завод иди»

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

Что делать

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

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

Если вы изучаете программирование самостоятельно, вступите в профильные сообщества и попросите более опытных разработчиков рассказать, с какими трудностями они сталкивались в начале пути. Скорее всего, им удалось с ними справиться — значит удастся и вам.

Причина № 7. Не получается монетизировать навыки

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

Появляются мысли вроде:

• «Меня никогда не заметят»
• «Другие намного лучше меня»
• «И зачем только я сюда сунулся»
• «Это просто не моё»

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

Что делать

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

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

Теперь давайте сделаем эту статью ещё полезнее!

Пропадала ли у вас мотивация во время обучения и как вы с этим справились? Или, может, вы испытываете трудности прямо сейчас?

Не стесняйтесь говорить о наболевшем — выговориться и получить поддержку можно в комментариях ⬇

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

Модель №1. Подписка (Freemium)

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

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

Преимущества модели подписки:

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

Недостатки модели подписки:

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

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

Еще один пример из нашего портфолио — авторский узкопрофильный сервис для диджеев https://jesteipool.ru.

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

Модель №2. Партнерская программа

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

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

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

Успех партнерской программы зависит от нескольких факторов:

1. Качество продвигаемых продуктов и услуг.
2. Эффективность маркетинговых усилий партнера и способность конвертировать посетителей в покупателей.
3. Достойное вознаграждение усилий и результатов партнера. Это влияет на поддержание лояльности и доверие между компанией и ее партнерами.

Модель №3. API как продукт

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

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

Например, использование карт Яндекса и Google на сайте происходит путем взаимодействия с их API. Стоимость зависит от количества пользователей, запрашивающих API карт, размещенных на сайте.

Например, в ChatGPT можно купить большой пакет, встроить бота в сайт или телеграм-канал и продавать услугу своим клиентам.

Модель №4. Данные как продукт

Данные можно использовать в качестве продукта разными способами:

1. Данные могут быть проданы компаниям или организациям, которым они нужны для исследований, анализа или принятия решений. Есть компании, которые  агрегируют несколько баз данных, перерабатывают их и продают итоговый документ конечному пользователю. Например, можно купить данные о подержанном автомобиле перед его покупкой. Сервис в едином PDF-документе предоставляет данные из страховой, из официального дилерского центра и данные ГИБДД о штрафах предыдущего владельца.
2. Данные также могут быть использованы для создания новых продуктов и услуг, таких как инструменты прогнозной аналитики или персонализированные рекомендации.
3. Данные могут быть использованы для улучшения существующих продуктов и услуг, например, для получения информации о поведении клиентов или тенденциях.

Модель №5. Реклама

Самая распространенная модель монетизации. Она заключается в размещении рекламы на сайте и последующем получении дохода от кликов или показов.

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

Выделим два вида рекламной модели:

1. Управление собственными баннерами

Рекламодатель напрямую связывается с владельцем сайта. Владелец сайта выделяет на веб-ресурсе рекламные места и страницы для показа баннеров. Далее он загружает через платформу Adfox баннеры разных форматов (gif, html, jpeg, png).

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

Adfox — независимая площадка. Поэтому споры по рекламным метрикам исключены. Это важно при взаимоотношениях площадки и рекламодателя.

Пример использования баннеров Adfox. Баннер расположен над меню сайта:

2. Показ рекламы из Рекламной сети Яндекса

Деньги за показ баннеров из РСЯ выплачивает Яндекс. Владелец сайта может вывести денежные средства на карту физического лица, либо на расчетный счет компании.

В примере ниже показано, как совмещать на одном сайте оба вида рекламы: баннеры РСЯ и баннеры Adfox.

Модель №6. Транзакции

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

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

К этой модели также относятся платные блоки и разделы на сайте. Пользователь оплачивает доступ к блоку или разделу и отображается там, либо размещает свои товары. У каждой площадки свои условия по стоимости и срокам отображения в блоке или разделе.

Преимущества транзакционной модели:

1. Владельцы транзакционных сервисов при формировании цен могут ориентироваться на два рыночных параметра:
   1) платежеспособность своей аудитории — сколько люди готовы заплатить за сервис;
   2) предложения конкурентов.
2. Владельцы сайтов могут отслеживать активность клиентов на сайте, чтобы лучше понять их поведение и предпочтения, и улучшать сервис для увеличения количества пользователей.

Недостатки транзакционной модели:

1. Требует постоянного трафика.
2. Подойдет не каждому онлайн-сервису.

Взаимодействие пользователей и владельца площадки полностью автоматизировано.

На сайте Archiprofi представлен пузырьковый принцип работы отображения профессионалов и объектов.

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

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

На третьем примере объекты отображаются по тому же пузырьковому принципу. Объект возможно добавить для всеобщего доступа только после внесения оплаты.

Примеры: auto.ru, avito.ru

Наша команда INDEXIS более 9 лет занимается веб-разработкой с продуктовым подходом. Мы выпустили более 100 веб-проектов и готовы помочь с созданием инструмента для развития в онлайне с учетом ваших бизнес-задач и интересов целевой аудитории.

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

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

1. Нет удовлетворения конечным продуктом

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

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

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

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

Чётко ограничьте свою зону ответственности и внутри неё делайте всё идеально, согласно вашим внутренним стандартам и убеждениям. Остальное — вне вашей юрисдикции. Без спросу за свою границу не суйтесь, пока не попросят. Ну а уже если попросят, то с радостью помогите — вашего энтузиазма хватит на весь проект.

2. Много рутины и однообразия

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

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

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

Шелдон Купер из сериала «Теория Большого Взрыва» однажды заменил своего друга Раджа программой. Тот расстроился, а вам это наоборот поможет избавиться от однообразия. Если получится как следует, то, может, и начальство оценит.

К сожалению, не всё поддаётся автоматизации. Бывает такая рутина, которая никак не укладывается в чёткие алгоритмы. Но заниматься ей всё равно придётся. В этом случае воспринимайте её как фитнес-тренировку. Включите ритмичную музыку, и вперёд. Через некоторое время вы заметите, что быстро и чётко расправляетесь со скучными однообразными задачами, чтобы перейти к чему-то более интересному. Это, конечно, не решение проблемы в корне, но способ поскорее от неё избавиться. Попробуйте, многим помогает.

3. Нет мотивации

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

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

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

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

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

4. Скучная работа

Знаете, как говорят: «Нет скучных профессий, есть люди, которые их скучно делают». И, действительно, подумайте сами: есть множество занятий, которые гораздо скучнее вашей работы. И всё равно люди их делают ежедневно.

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

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

Никто не мешает внести творческое разнообразие в тексты внутренней базы знаний. Главное, чтобы всё это не мешало процессу и не отображалось заказчику. А то бывали случаи: «Кто на боевой базе банка под администратором поставил в настройках «Должность руководителя» — суперхомяк?! ЦБ прочитал отчёты и очень удивился…«

5. Бесполезная работа

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

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

А как вы боретесь с рутиной на работе?

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

Эффективно ли это? Иногда. Есть ли другие способы сплотить команду? Безусловно. О них и поговорим.

1. Через тернии к звёздам
2. Регулярный менеджмент
3. Гуманизация
4. А что по играм?
5. Scrum
6. Выводы

1. Через тернии к звёздам

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

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

2. Регулярный менеджмент

Ни для кого не секрет, что основной клей, скрепляющий команду разработчиков, – это сама работа. Так что к вопросу менеджмента следует подойти с умом.

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

3. Гуманизация

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

Назову этот пункт «гуманизация». Необходимо создать такие условия, чтобы сотрудники понимали, что они работают в одной команде не только с девелоперами, тестировщиками или аналитиками, но еще с живыми интересными людьми. Необходимо включать камеры, чтобы видеть, что ты работаешь с человеком, а не роботом. Очень интересно смотреть на домашний интерьер, на то, что окружает человека, с которым ты работаешь — гитары, книги или картины. И конечно +100 к отношениям, когда ты видишь домашних питомцев — котиков, собачек, хомячков.

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

4. А что по играм?

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

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

Но есть и другие нетривиальные способы укрепить командный дух:

Приведем несколько примеров того, что есть в Selectel «нестандартного» для поддержания и укрепления командного духа.
UX-team support. Кружок психологической помощи в команде UX, где члены команды могут общаться в неформальной обстановке на любые темы: обсуждать трудности и успехи, радости и горести, чтобы получить поддержку или советы от коллег.#Шавадей, #Хинкалидей и чайные церемонии. Тот пример, когда традиция отдельной команды переросла в общекорпоративную. Каждую неделю инициативные коллеги организовывают заказ шавермы и хинкалей, к которому может присоединиться каждый желающий и в тёплом кругу обсудить гастрономические темы. Ежедневно коллеги собираются на так называемый «цяй» c теми же целями.Выездные стратегические сессии. Иногда для команды мы организовываем выездные стратегические сессии, которые направлены на детальную и сложную проработку ключевых задач отдела (например, создание нового продукта или план разработки новой фичи облака). Как правило, это выезд на 2–3 дня, чтобы можно было и плотно поговорить о рабочих задачах, ну и, конечно же, совместно отдохнуть.Ugly Powerpoint Party. Вечеринка со сделанными на скорую руку презентациями на самые разные темы (чаще всего смешными). Недавно мы провели CheerUp MeetUp в таком формате — получился неформальный митап для поддержки морального духа. Судя по фидбэку гостей и сотрудников, это именно то, в чём они так нуждались.

5. Scrum

Популярная методология управления проектами также идёт в копилку рабочих советов.

Иметь крепкую команду разработчиков — необходимость для ИТ-компании. Здесь, на мой взгляд, не обойтись без методологии Scrum, которая базируется на эффективном взаимодействии и распределении обязанностей внутри команды.Scrum пришёл из регби. Основная цель этого спорта — удержать в руках мяч, передавая игрокам своей команды, и устоять, когда противник сбивает с ног. В работе scrum-группы цель схожа: нужно реализовать задачу, поддерживая друг друга, подстраховывая и не давая ни коллегам, ни мячу (=проекту) упасть.Скрам предполагает Daily stand up meeting (ежедневные встречи, где каждый участник говорит о своих текущих задачах), работу спринтами (короткими временными интервалами с краткосрочными задачами), обзоры и ретроспективы с коллективным анализом проделанной работы. Вся эта совместная работа, безусловно, объединяет.

Также почитайте о тимбилдинге по методу «Эльбруса».

Выводы

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

А у вас есть интересные идеи по сплочению команды? Делитесь ими в комментариях.

Без лишних слов расскажем о том, где айтишнику будет приятно и полезно провести время в Москве в 2022 году.

FINE coffee

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

Где найти: ул. Волхонка, 9 стр.2

Российская государственная библиотека для молодежи

Здесь комфортно работать, как за своим ноутбуком (есть Wi-Fi и розетки), так и на специализированных графических станциях с предустановленным профессиональным софтом. Есть где распечатать модели на 3d-принтере, записать свой подкаст или музыкальный трек, посмотреть фильм, послушать лекции, посетить кафе с друзьями и, конечно же, почитать книги, периодику, причём не только в печатном виде, но и с экрана ваших собственных устройств.

Где найти: Большая Черкизовская, 4 корп. 1.

Enterprise Low Code Day 2022

Ежегодная бизнес-регата, на которой формируется новый взгляд на корпоративные Low Code решения, изо дня в день доказывающие свою эффективность. Главной темой #ELCD2022 станет снижение time-to-market для энтерпрайза без потери качества продукта — важнейшего показателя для современных компаний. Особенно критическим этот вопрос становится сегодня, когда рынок испытывает дефицит разработчиков.

В программу Enterprise Low Cod Day 2022 войдут: конференция с иностранными спикерами, развлечения и сюрпризы, воркшопы, парусная регата и продуктивный нетворкинг.

Где найти: 16 июня 2022 г., яхт-клуб «Нептун»

Рабочая станция

Отличная сеть коворкинг-пространств, для тех, кто нуждается в максимальном комфорте и покое для организации рабочего процесса. Площадка в Парке Горького расположена на краю Нескучного сада, в панорамные окна можно любоваться природой. В большой мягкой зоне можно отдохнуть на диванах или пуфиках. Рядом со Станцией находится кафе современной кухни на основе сезонных продуктов, в котором действует 20% скидка для резидентов. Всё, что нужно для продуктивной работы вне дома.

Где найти: Ленинский пр-т, 30А.

Старт Хаб

Бесплатная зона для нетворкинга, запущенная при поддержке Агентства инноваций Москвы. Чтобы провести деловую встречу или спокойно поработать, нужно всего лишь забронировать стол. Бронь можно оформить на один или два часа. Внутри пространства доступны бесплатный Wi-Fi, питьевая вода, чай и кофе на кухне, девайсы для печати документов. На территории площадки работает одноимённостей нная кофейня. Отличное место, чтобы провести встречу или пару часов за усердной работой.

Где найти: Берсеневская набережная, 6 стр.3.

F5 | Центр киберспорта

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

Где найти: Пр-т. Андропова, 38.

Я обучался в СОШ, филиал Тольяттинской академии управления. Это нестандартное место, о котором вы точно не знаете. Во-первых, СОШ находится в лесу на берегу Волги со своим пляжем.

Во-вторых, это индивидуальное модульное обучение, где ученик учится сам, а учитель только управляет его учебной деятельностью. Всё как в Оксфорде: имеешь хороший рейтинг – учишься бесплатно.

В-третьих, образовательная программа Тольяттинской академии управления – первый инновационный образовательный проект в России. Его создатель – Андрей Волков, который позже сделает Московскую школу управления «Сколково».

«Как меня занесло в оптимисты» – работа в «чёрной зоне», тюрьма строгого режима.

У меня была юношеское желание работать полицейским, но реформа в МВД не позволила это осуществить. Ко мне поступило экзотичное предложение по работе – тюрьма.

Причём, тюрьма строгого режима, так называемая «чёрная зона». Обучение психологии и дипломатии у меня происходило не на модных образовательных тренингах, а в формате российской действительности, воспетой группой Кровосток: «Я всегда хотел знать, что прячется под покровами. И чтобы последствия не оказались слишком суровыми». Начиная с младшего инспектора я дослужился до начальника отряда за четыре года. Потом принял решение поменять карьерный путь.

Главный принцип, который постулирует Ирина Хакамада на своих тренингах – это «заранее умереть». Выиграть в смертельном бою получится только у того самурая, который «уже мёртв». Она любит рассказывать, как в начале политической карьеры вела переговоры с настоящими бандитами, проигрывая худший сценарий беседы у себя в воображении. Я закалил свой характер в коммуникации с осужденными, будто прошёл институт по психологии. Этот опыт помогает мне эффективно взаимодействовать на равных позициях даже с министрами.

«Московские будни»: 200 резюме в день и три предложения по работе.

Переехав в Москву, я начал отправлять по 200 резюме в день в интересующие компании. Это была своеобразная тренировка дипломатии. Прежде, чем устроится в японскую компанию Asahi Glass Company, я прошёл 26 собеседований, из которых поступило 3 предложения. Одним из решающих факторов приглашения меня на работу стало то, что генеральный директор, Алексей Герин, оказался бывшим военным переводчиком. Его подкупило моё прошлое место работы.

Индустрия лингвистических технологий: от Всемирной летней Универсиады до CEO в ABBYY LS.

Моя карьера в индустрии лингвистических технологий началась в 2012 году. Я занимался лингвистической поддержкой крупных спортивных и дипломатических мероприятий. Начал с «Год Германии в России: 1000 лет вместе». Потом были «XXVII Всемирная летняя Универсиада», «Красноярский экономический форум» и «Восточный экономический форум».

На этих мероприятиях я получил уникальный опыт управления. Например, на Всемирной Летней Универсиаде в Казани одновременно работали свыше 330 специалистов-переводчиков: менеджеры спортсменов, письменные и устные переводчики, синхронисты.

Благодаря ударному старту в 2014 году меня пригласили возглавлять направление технических переводов в ABBYY LS, где впоследствии я занял пост CEO компании. Работа в ABBYY была серьёзным IT-челленджем и полноценным запуском моей карьеры в области лингвистических технологий. В компании я вёл флагманские облачные проекты, участвовал в спин-офф «SmartCat» с Иваном Смольниковым (платформа для автоматизации процессов перевода), а также запустили крутой продукт с Xerox (оргтехника, которая переводит по нажатию одной кнопки на любой язык) и «ABBYY Cloud» (единое облачное решение всех продуктов ABBYY). В своё время это были прогрессивные технологии, которые увеличивали производительность переводчиков в два-три раза.

Дроны не только про развлечения. Как стартап TraceAir строит объекты для СИБУР и Норникель.

Случайное знакомство свело меня в 2018 году с ребятами из стартапа ConTech – TraceAir. Помню, как мы быстро встретились на переговорах длительностью менее часа. Сразу нашли общий язык, так как разделяли подходы по управлению бизнесом. Я думал, что такого не бывает, но это произошло.

TraceAir, облачная веб-платформа и софта для контроля качества и хода строительства на основе данных с дронов (беспилотники, БПЛА), тогда существовала 3 года. После участия в известном стартап-акселераторе 500 startups TraceAir стал развиваться на рынке в США. При этом офис разработки продукта остаётся в Москве.

У нас собралась уникальная команда из 40 человек. Среди них: Дима Королёв, который летает на параплане и впоследствии сделал экзит из стартапа про них, Мария Хохлова, внучка советского физика и ректора МГУ Рема Викторовича Хохлова. Кстати, в честь него названа улица Академика Хохлова в Москве. Это и Брайен, работавший в Space X, и бывший CEO 2GIS – Иван Львов. Есть ребята, которые запускали систему навигации и автопилота для BMW и даже те, кто связал свою жизнь с Голливудом. Когда говорят, что «мы учимся у друг друга» — это не пустые корпоративные слова.

Сейчас TraceAir – это работа с инфраструктурными проектами, промышленным и дорожным строительством. С такими компаниями, как СИБУР, Норникель, Новатэк, Нипигаз (Амурский ГПЗ) и работа на трассе М-12. На рынке в США мы работаем с одними из самых крупных девелоперских компаний.

Уже не за горами то время, когда цифровое строительство целиком перейдёт на автоматизированную работу. И навсегда решит проблему с нарушением сроков сдачи жилья, ликвидирует «человеческий фактор» в строительстве (дефекты и ошибки со стороны подрядчиков). Для обычного человека это будет означать, что при покупке жилья он, как в компьютерной игре, станет непосредственным участником процесса строительства с помощью смартфона. И сможет наблюдать за изменениями строительства: прикладывать модули в 3D и получать наглядную информацию как по срокам, так и расходам объекта в режиме реального времени.

Перешёл на удаленку до того, как это стало мейнстримом

Было интересно, и первое время мы эффективно сотрудничали. Совмещать учёбу с работой в офисе мне было удобно, но потом у стартапа начались трудности, и мы перешли на удалёнку. Сохранять эффективность стало сложнее. Самая большая проблема была всё успеть. Тогда удалённая работа была не так хорошо налажена. Жил я далеко от места учёбы, и дорога занимала порядка 2,5 часов, а то и больше. Сейчас многие работают прямо в дороге, но тогда такой возможности не было. Возвращался домой я поздно, плюс не было быстрого интернета – в общем, работа из дома получалась совсем неэффективной. Поэтому со временем с тем стартапом мы полюбовно попрощались.

На пути в Лигу

Я начал искать другую работу, на которой я мог бы активно развиваться, но при этом так же успешно совмещать её с учёбой, как это было раньше. Устроился в «Яндекс» разработчиком сервисов для мобильных приложений. Проработал больше двух лет, после чего по приглашению хорошего друга перешёл в коммерческий банк. Там был классный проект и крутая команда, но спустя какое-то время моё развитие остановилось. Тогда ещё не было такого тренда, как сейчас, когда банки наподобие «Сбер» или «Тинькофф» позиционируют себя как ИТ-компании. Отсутствие перспектив лишало мотивации, поэтому через год у меня появилось новое предложение. В 2011 году я перешёл в мою нынешнюю команду.

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

Становиться лучше каждый день

15 лет я очень серьёзно занимался спортом. А что такое, по сути, спорт высших достижений? Это ежедневные тренировки во имя одной цели – становиться лучше. Там главная мотивация – самосовершенствование, без которого ничего не добиться. Когда ты каждый день стараешься развиваться, это входит в привычку и другая мотивация уже не нужна. В ИТ-сфере для меня действует то же правило и та же привычка. Когда есть понимание, что можно двигаться вперед и узнавать что-то новое, не нужно отдельно мотивировать себя на конкретную задачу или на то, чтобы идти на работу. Стремление к улучшению себя – само по себе неисчерпаемый источник энергии.

Обратная связь

Собственный план развития формирует для сотрудника максимально прозрачный путь в компании. Это дает чёткую картинку, в каком направлении двигаться – понимание, что человек делает и для чего. По моему опыту, большую эффективность показывает не тотальный контроль, а, наоборот, свобода с периодическим обсуждением проделанных шагов с руководством. Так выстраивается продуктивный тандем с руководителем: сотрудник действует самостоятельно, но при этом получает обратную связь и при необходимости корректирует свои действия. Отсутствие ограничений и в то же время поддержка босса реально помогают.

Борьба с рутиной

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

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

Наставничество

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

Я не линейный руководитель, прямой задачи мотивировать у меня нет. Но на мой взгляд, наиболее эффективная тактика – вдохновлять собственным примером. Действует как в развитии коллег на работе, так и в воспитании детей дома. Кроме того, во многих командах предоставляется возможность делиться опытом, готовить доклады, выступления по проектам. Внутреннее обучение и обмен опытом – одно из важнейших направлений в Лиге. Желание быть примером и вкладываться в развитие других людей – сильный мотивирующий фактор. Это как с детьми – ты их учишь и радуешься их достижениям и успехам.

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

О «голожопых» айтишниках в начале 2000-ых

Уже в банке я коммуницировал с огромным количеством бизнесменов, которые стремительно развивали собственное дело. Признаться, и я «бредил» своим проектом, чувствовав, что только компания, сделанная «собственными руками», способна эффективно капитализировать мои ресурсы. Внешняя среда подавала мне сигналы о необходимости трансформироваться: обострились разногласия между двумя собственниками банка, что мешало глобальной и ясной стратегии бизнеса. Один Партнер придерживался эволюции, другой ратовал за революцию. В таком состоянии хаоса на пороге банка оказалась небольшая команда молодых IT-специалистов, которые безуспешно пытались получить кредит на прототип своего бизнеса в сфере видеонаблюдения. К слову, шансы на получение кредита «голожопому айтишнику» были равны нулю в начале 2000-ых.  Ни один банк не предоставлял финансирование IT-cтартаперам, по причине невозможности обеспечить кредит залогом, не имея активов компании. Так же и произошло, как по методичке, с этими ребятами, которым отказал, уже не в первый раз, банк «Держава». Но, по стечению обстоятельств, коллеги познакомили меня с ними, понимая, что я увлекаюсь темой видеонаблюдения и обладаю широкой партнерской связью. Мы начали разговаривать про видеонаблюдение, и я увидел, что их продукт способен сделать рынок видеонаблюдения удобным, массовым и масштабируемым продуктом. Я отлично понимал, что идеи первичного привлечения денег в проект с помощью кредитования у ребят – обречены на провал. Нельзя начинать венчурный бизнес с кредита. Любой банк, который предоставил бы кредит – фактически стал бы держателем этого бизнеса на основании условий кредитования.

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

Путь от стремянки до инвестиций Skolkovo Ventures и Rusnano Sistema SICAR

Ключевым источником IT-знаний стала моя новая команда, с которой мы объездили все профильные выставки от Гонконга до Лас-Вегаса. Мы были участниками, посещали их с целью коммуникации с потенциальными клиентами. Моя зона ответственности в IT-стартапе заключалась в выстраивании взаимоотношений с инвестиционными партнерами, а уже вечером, не чураясь, я брал стремянку, создавал и тестировал первые пилотные проекты. На этом этапе было важно собрать информацию о потребностях клиента и способах развития продукта. После работы мы обсуждали продуктовые планы, покупали необходимую технику, и как разумно тратить бюджет, поскольку компания разрасталась. Я собственными руками, как и мечтал, делал ремонт в первых офисах и был погружен в рабочий процесс, зная все про каждого члена команды: от объема памяти на компьютерах разработчиков до времени, потраченного на дорогу сотрудниками до офиса. Эти скрупулёзные детали мне позволили оптимизировать нагрузку и создать оптимальные условия для продуктивной работы. Именно так я и погрузился в «мир IT и инвестиций», где прошел путь от закрытия сделок с ангелами до глубокого структурирования сделок с серьезными венчурными фондами, например, Skolkovo Ventures и Rusnano Sistema SICAR. В привлечении инвестиций мне сильно помогало экономические образование, а также общая любовь к математическим наукам. Да, меня нельзя назвать IT-разработчиком, но через бизнес-девелопмент я получил глубокие компетенции, которые позволили мне построить интернациональный IT-бизнес видеонаблюдения и видеоаналитики.

Менторы имеют значение

На этапе погружения в сферу я прибегал к поиску менторов. Я благодарен Андрею Фатахову, создателю самого большого бизнеса фотопечати через интернет, сервис NetPrint (cейчас его используют Yandex и Mail). С Андреем мы провели много утренних встреч в 7-8, где за чашкой кофе дискутировали о развитии Ivideon в будущем. Так же моими наставниками были инвестиционные Партнеры, которые находили время обсуждать мои сомнения и заблуждения по поводу развития компании.  Так мне удалось получить глубокую компетенцию в области управленческого и профессионального развития.

Успех бизнесмена всегда уникален, его не повторить

IT-стартаперам не стоит забывать про профильные события отрасли. Систематически я был модератором круглых столов крупной международной выставки «Securika Moscow», в рамках которой знакомился и общался с успешными предпринимателями сферы оборудования для обеспечения безопасности и противопожарной защиты.  Это сильно «погрузило» меня в профессиональную тусовку. Именно на ней я понял необходимость организации англоязычной технической поддержки в компании для масштабирования бизнеса. Как и многие начинающие предприниматели, я читал книги про маркетинг, управление, психологию общения и блоги конкурентов. Но стоит понимать, что успех всегда уникален, его невозможно повторить. Значение имеют только проблемы и ошибки, с которыми сталкиваются бизнесмены. Их можно систематизировать и таким способом минимизировать риски, но и этого недостаточно для успешного бизнеса. Ты можешь быть отличным теоретиком, но только личный контакт и встречи с ключевыми участниками рынка способны наполнить тебя компетенцией, пробудится от заблуждений и выйти на международный рынок.

Прежде чем встать на путь тестировщика, я получил два высших: первое – по профилю «Специальная психология и педагогика», второе – как инженер-специалист путей сообщения. В период учёбы в вузе я самостоятельно изучал программирование на Java, но потом десять лет работал в «РЖД», где написание программ было далеко не основным, а скорее – побочным занятием. Поэтому, когда позже я решил попробовать себя в коммерческой разработке и тестировании, пришлось сначала освежить знания языка на онлайн-курсах.

В «РЖД» я прошёл путь от обычного монтёра до начальника дорожной лаборатории. Соответственно, и задачи приходилось решать очень разные, но все они были так или иначе связаны с безопасностью движения поездов. Сначала я занимался обслуживанием и ремонтом оборудования, затем – проектировал и анализировал схемы автоматики и телемеханики, в том числе системы управления стрелками и светофорами. В дорожной лаборатории я анализировал деятельность подразделения – следил, насколько безотказно работают наши устройства, продумывал, как предотвращать и устранять неисправности, решал административные вопросы.

Моя повседневная работа не была напрямую связана с программированием, но я старался хотя бы частично автоматизировать выполнение задач и для этого писал приложения-«помощники». Одним из таких решений стал электронный ассистент для ведения технической документации. С ним я в 2018 году участвовал в корпоративном конкурсе «Новое звено» и занял второе место по области. Затем я ездил в Москву на полуфинал, но вскоре разочаровался и в конкурсе, и вообще в работе «РЖД». Я понял, что выше начальника лаборатории без «хороших знакомых» мне не подняться, и решил кардинально сменить сферу деятельности – перейти в IT.

Из Томска в Калининград

Ещё во время работы в «РЖД» я получил опыт переезда в другой город. После того как расформировали наш отдел в Томске, мне предложили перевод либо в Калининград, либо в Краснодар. Я выбрал первый вариант. Организовать переезд внутри страны оказалось в принципе не очень сложно, хотя и лёгким этот процесс не назовёшь. В таких ситуациях всегда немного страшно – что там, за стеной неизвестности. ?

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

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

Что касается вакансий, работа в Калининграде есть, и не только в IT.

«– Яжпрограммист! – Какие ваши доказательства?»

Когда я решил покинуть «РЖД», завёл резюме программиста Java на нескольких сервисах поиска работы – начал мониторить рынок труда и ходить на собеседования. Чаще всего работодателям нужен человек с опытом, а мне в этом плане было нечего им предложить. Чтобы собрать портфолио и получить формальное подтверждение своих навыков, я записался на онлайн-курсы Java-разработки.

Почему всё-таки Java? Я уже программировал на этом языке, и он пришелся мне по душе. Но IT-индустрия развивается очень быстро, так что знаний всегда не хватает. Появляются новые фреймворки, подходы и практики, о которых надо знать, чтобы «не отстать от поезда». Кроме того, мне важно было восполнить пробелы в знаниях, чтобы соответствовать требованиям работодателей.

Я наткнулся на рекламу GeekBrains в интернете – открыл лендинг, позвонил методистам и обстоятельно с ними поговорил. Меня интересовало буквально всё: как проходят курсы, в каком виде подается материал, что я получу по итогам обучения. Когда речь идёт о чем-то важном, я «докапываюсь» до каждой мелочи. Я записался на курсы и сейчас могу сказать, что в целом мои ожидания от обучения оправдались. Случались, правда, неприятные моменты, когда преподаватель неуверенно читал методичку. Тогда становилось ясно, что подготовка у него не очень. Но были и профессионалы: такие, как Иван Овчинников и Александр Фисунов – их вебинары я с удовольствием слушал и слушаю. Это, можно сказать, мои кумиры. ?

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

• Java 8. Полное руководство (Г. Шилдт).
• Java. Библиотека профессионала (К.Хорстманн).
• Java. Программирование для начинающих (М. МакГрат).
• Структуры данных и алгоритмы Java (Р. Лафоре).

В 2020 году, как раз перед началом всеобщей самоизоляции, мне позвонили из одной IT-компании и пригласили пройти собеседование на должность тестировщика. Это был поворотный момент, после которого я простился с «РЖД».

Учебный космошутер для души

За время обучения в GeekBrains я сделал два проекта: сетевой чатик и космический 2D-шутер «FireBorn». Когда я выбирал, что буду делать, решил, что Spring – это скучновато и обыденно, высоконагруженные БД – долго и напряжённо, а игра поможет одновременно испытать свои навыки и раскрыться творчески. Так и вышло. Мне давно хотелось разработать игру, и вот наконец представилась такая возможность.

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

1. правильно сгруппировать игровые объекты,
2. сделать мир игры родительским объектом,
3. вынести всю логику в отдельный класс – связующий для остальных классов.

Когда все внутриигровые объекты описаны и увязаны между собой, приходит время сделать их видимыми, то есть привязать к ним подходящие спрайты. Дальше с этой графикой нужно работать внутри классов – масштабировать её и подчинять её отображение логике поведения объектов.

Главное оружие любого разработчика игр, в том числе и на Java, – это DELTA TIME, время между кадрами, которое нужно правильно использовать. Именно в эти промежутки времени творится магия игр! Потому что на экране мы видим результат, а «судьбы вершатся» за кадром.

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

Я добавил в игру противников с базовым AI, плюс препятствия-астероиды, станцию, где игрок может пополнять боезапас и восстанавливать жизни, и особый артефакт, который позволяет перемещаться из любой точки карты прямо к станции. Для усиления игровой атмосферы я тщательно подбирал музыкальное сопровождение, звуки окружения, голосовые сообщения UI – пришлось прослушать с десяток гигабайт звуков и подкастов.

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

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

Моя первая работа в IT

Компания, где я сейчас работаю, создаёт и поддерживает продукты разного типа: веб-сайты, приложения с использованием дополненной реальности (AR), Android-приложения, мобильные игры. Чтобы попасть в отдел тестирования, я прошёл два очных собеседования. На первом меня спрашивали, что умею, знаю и уже писал, какие фреймворки использую. Вместо тестового задания я показал порт своей игры у себя на телефоне. И ещё добавил, что знаю, как применять Java в области тестирования.

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

В команде нас пятеро: самыми масштабными проектами занимаются три специалиста, и ещё два – курируют по небольшому продукту каждый. Недавно мы принимали участие в разработке сайта goldautumn2020.ru для электронной выставки Министерства Сельского Хозяйства РФ. О, да! Я надолго запомню эти две недели бессонных ночей и постоянного напряжения.

Что касается небольших проектов, это, во-первых, соцсеть brybe.com, где владельцы брендов и талантливые маркетологи встречаются, чтобы помочь друг другу.

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

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

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

Дело в том, что фирмы пользуются разными средствами автоматизации процессов: у одних инструментов есть GUI, у других – нет. Выбор инструментария зависит от результата, который необходимо получить, будь то работоспособность сайта, загруженность платформы или ещё что-то. Я создал решение, которое тестирует и back-, и front-составляющую проекта. Внутри фреймворка спрятан, во-первых, опросник всех endpoint – наружных и служебных, во-вторых, считыватель данных о том, как система реагирует на внешний раздражитель. Например, что будет, если сменить аватарку на валидную, а потом – на не валидную. В-третьих, фреймворк создаёт нагрузку на конкретный endpoint, при этом считывает и логирует характеристики сервера.

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

Тестирование на фоне пандемии

Так совпало, что на работу я вышел, когда в России поднималась «первая волна» COVID-19. А мне как раз надо было срочно вникнуть во все проекты отдела и взяться за их развитие. Пришлось, без преувеличения, сидеть в офисе одному, пока остальные сотрудники были дома на так называемой «самоизоляции».

Конечно, понадобилось перестраивать процессы внутри команды, и ситуация вынуждала действовать по принципу «Пришёл, увидел, победил», потому что времени на долгие эксперименты не было. Чтобы полностью адаптировать нашу работу к новым условиям, ушло около месяца. Подводным камнем на этом пути стал, как нетрудно догадаться, человеческий фактор. Мало кто рвётся «чинить то, что не сломано», даже если оно плохо работает. Поэтому для коллектива, как и для отдельных людей, решение проблемы всегда начинается с её осознания. И мы этот путь прошли. Сейчас всё в порядке – процессы наладились: коллеги в основном работают из дома, а при необходимости приезжают в офис.

Как новичку быстрее прокачаться?

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

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

Что дальше

Помимо тестирования мне сейчас интересна Frontend-разработка, так что собираюсь основательно взяться за изучение JavaScript. Почему-то никак он мне не даётся. Может, дело в специфике Java, после которой на JS сложнее переключиться, но раз уж я наметил, буду осваивать новый язык. Пока – для души, а там посмотрим.

Не стоять на месте и всегда развиваться — история о том, как заново найти себя. Технический директор компании BENFIN Андрей Перов рассказал, как сменил карьеру в образовании на бизнес по онлайн-страхованию.

С 2006 года я работал преподавателем и заместителем руководителя по информатизации образовательных процессов. В 2012 году мы создали команду единомышленников из профессионалов, которых я знал лично или косвенно.  Вместе с ними я стал выполнять разного рода ИТ проекты, так мы подрабатывали и развивались. В 2014 году осознал, что хочу найти себя в чем-то новом. Тем более, события, происходящие в образовании, сильно подталкивали меня к смене деятельности. Так я и оказался в новой, но родной для себя сфере — IT, но уже в бизнес-среде.

Образовательный коллапс

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

Найти себя в страховом бизнесе

Выбор нового дела всей жизни был для меня предельно прост. Страховой бизнес воплотил в себе синтез творческого подхода и ИТ технологий. Я увидел возможность действительно оказать значимое влияние на сферу страхования путем своих знаний в ИТ. Оказалось, страхование – один из самых нестабильных процессов со стороны управленческих решений и воздействия сторонних бизнесов. Для него нужна постоянная активность, как умственная, так и интеллектуальная. Такой бизнес требует нескончаемого поиска новых решений и способов выхода из сложных ситуаций. Разработка онлайн-платформы реализовала все мои потребности к креативному мышлению и мыслительному напряжению.

Трудности в начале

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

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

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

О будущем оптимизации бизнес-процессов

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

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

Советы для всех, кто хочет найти себя заново

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

Team lead мобильной разработки Secreate Дмитрий Кондаков расскажет, возможно ли без образования и технического склада ума за два года стать успешным программистом.

Изначально у меня не было цели связывать свою жизнь с ИТ. Более того, до определенного момента я этим даже не интересовался. В детстве я серьезно увлекался музыкой и думал, что меня ждет карьера музыканта. Началось все с фортепиано, но мы не сошлись с преподавателем, и поэтому я пошел в другое направление. Заметив такую страсть и талант к музыке, родители устроили меня в лучшую музыкальную школу Беларуси № 10 имени Евгения Глебова, где я научился играть на балалайке и последующие 11 лет полностью посвятил себя этому занятию. Я подавал большие надежды и мне предложили выступать вместе с оркестром, который должен был гастролировать по Беларуси и Японии.

Но, к сожалению, моим мечтам не суждено было сбыться. С самого детства у меня довольно редкое неврологическое заболевание — спинальная амиотрофия, болезнь Кугельберга-Веландера (мышечная дистрофия). Это прогрессирующее заболевание, которое оказало очень большое влияние на всю мою жизнь.

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

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

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

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

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

Кризис и смена направления

В 2010 году в Беларуси произошел кризис. В итоге, проработав с анкетами два месяца с тремя выходными, я заработал 1500 долларов, а из-за скачка курса на руки получил всего 500 долларов. Уроки музыки и вокала стали людям не нужны.

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

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

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

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

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

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

Переломный момент

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

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

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

Вторым моим проектом было приложение для Windows. Оно представляло собой учетную систему контроля справок для учеников. Затем, совместно с моей подругой программистом мы сделали приложение-справочник по женским заболеваниям на базе Android.

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

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

Как результат — за 6 дней я изучил с нуля до джуна JavaScript, React Native, Redux, и нам удалось договориться на удаленную работу. Через месяц нашего сотрудничества мне доверили крупный проект. Всего в компании я проработал 8 месяцев, уволившись из-за низкой заработной платы и нежелания подписывать со мной договор.

Поняв, что в Беларуси искать нечего, я начал поиски новой работы уже в России.

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

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

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

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

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

Через свою историю я пытался сказать, что не нужно капитулировать перед проблемами, они всегда будут встречаться на жизненном пути. Нужно не переставать искать себя и развиваться. А стать программистом можно в любом возрасте, с любым высшим образованием или его отсутствием и совершенно необязательно обладать «техническим складом ума».

Что почитать новичку

• Герберт Шилдт «Java 8».
• Филлипс Билл «Android. Программирование для профессионалов».

Ресурсы:

• Сайт learn.javascript.ru
• Документация React Native.

Краткие советы:

• Переписывать весь код руками.
• Не использовать prettier.
• Не использовать копипасту.

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

Внешняя мотивация

Информационная ценность и бизнес-смысл задачи

Это один из наиболее значимых факторов мотивации. Развивается ли ваша компания в своей сфере благодаря выполнению задачи? Делаете ли вы что-то новое, оттачиваете мастерство как специалист? Для себя я стараюсь отвечать на эти вопросы исходя из тенденций развития IT-инфраструктур. Недавно я начал изучать целых три языка — HTML, JS и PHP — для создания портала на базе платформы 1С. Поэтому сейчас для меня значимы и задачи из этих областей, позволяющие создавать что-то новое.

Материальная ценность задачи

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

Мнение коллег (в командных задачах)

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

Внутренняя мотивация

«Информационное голодание»

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

Ощущение пользы от своей работы

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

Цели и мечты

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

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

Учитывайте и ещё один важный момент: с профессиональным выгоранием или нелюбимой и непонятной работой не поможет справиться ни один из факторов мотивации. Старайтесь находить хотя бы один из них в каждой задаче — или не беритесь за задачи вообще. Потому что результат трудов человека с нулевой мотивацией будет максимально некачественным. А если так — сможете ли вы уважать самого себя как профессионала?

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

Определить цель

Я начал работать в компании, когда персональный план развития (personal development plan, PDP) в EPAM ещё составлялся в Excel. Сейчас мне удобнее всего планировать в Grow (этот инструмент доступен всем, кстати). Ты выбираешь, кем хочешь стать: например, ты junior .NET-разработчик и хочешь перейти на уровень middle. Система подсказывает, что нужно изучить, какие курсы посмотреть, что почитать, в целом каким требованиям необходимо соответствовать, чтобы претендовать на эту позицию, показывает так называемую матрицу скиллов. Но система не поможет определить, кем ты хочешь стать, это задача в любом случае требует самостоятельного изучения.

Чтобы понять, куда двигаться, я проанализировал, что вообще есть на рынке. Вебинары, которые проводились в компании, помогли мне разобраться в направлениях, понять, кто такой тимлид, менеджер проектов, архитектор. Я смог представить, что мне может быть интересно. Полдела сделано: я выбрал направление. Можно воспользоваться открытыми источниками с курсами, например LinkedIn/learning.

Для ведения своего дневника развития можно использовать любые другие инструменты — Trello, Google Sheets или даже просто календарь. Главное, вести запись, чтобы план всегда был перед глазами, и к нему можно было возвращаться.

Найти наставника

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

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

Если наставника заинтересовать, показать большое желание развиваться и увлечённость выбранным направлением, то получить какие-то советы и рекомендации станет проще.

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

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

Разбить цель на задачи

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

Например, я решил, что хочу пройти ассессмент, чтобы перейти на новую позицию — senior разработчик. Ассессмент — это процесс оценки соответствия сотрудника требованиям Global Competency Framework в EPAM, который необходимо пройти, чтобы получить рекомендацию для продвижения на определённый уровень. Grow подсказывает, что мне для этого нужно не только пройти курсы по новым технологиям, но и улучшить командные навыки, навыки общения с клиентами, а также получить рекомендации от команды. В любом случае это сводится к тому, что нужно расширять область воздействия, то есть браться за что-то дополнительное и пытаться довести до конца, попутно совершенствуя указанные навыки. Такой подробный план позволяет реалистично оценить, сколько сил и времени уйдёт на его выполнение. Часто люди не достигают целей, потому что не представляют, какое количество работы им придётся проделать для достижения результата.

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

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

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

Следовать дедлайнам

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

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

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

Отслеживать прогресс

Очень важный лично для меня пункт (собственно, это то, для чего я весь этот план составлял). План, будь то матрица или просто список задач, помогает следить за прогрессом, а ещё не впадать в отчаяние. Например, я поставил дату по задаче. Дата оказалась нереальной. Задача не выполнена, прогресса нет.

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

С какими трудностями придётся столкнуться

Потеря мотивации

Мотивацию обычно теряют, когда нет определённой цели.

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

Нехватка времени и большая загрузка на проектах

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

Поиск направления

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

В своё время мне очень помог курс лекций «Learning: How to learn» от Стэнфордского университета. Я смог понять, как наш мозг учится новому и придумывает идеи.

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

«Лаборатория Качества» живёт тестированием, вокруг него строится наша философия, наше благосостояние и будущее компании. Мы тестируем виртуальные программные продукты, и делаем это удалённо.

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

Мы ехали тестировать Эльбрус, а в итоге Эльбрус научил нас, как тестировать себя. За что мы ему безмерно благодарны.

Вместо предисловия

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

Обычный сценарий тимбилдинга в здоровой компании: коллеги съезжаются в комфортабельный загородный дом и начинают выполнять стандартные упражнения, например падать друг другу на руки, водить «слепых» коллег по лабиринтам, орать гимн компании под 3 аккорда и так далее…

Как может выглядеть тимбилдинг в компании, которая привыкла тестировать ПО и себя на прочность? Основатель компании перебирает все самые жёсткие варианты тимбилдинга. И, разочаровавшись в их эффективности, устраивает настоящее реалити-шоу!

Сценарий

Из разных уголков мира — компания-то удалёнщиков — съезжаются 4 ТОПа компании и их подчинённые, чтобы протестировать лимиты своих возможностей и взобраться на самую высокую точку Европы — Эльбрус (5642 метра).

Зачем?

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

Как готовились?

Организовали беговой клуб и тренировались своими силами. Делились результатами и прогрессом. Обязательное требование — пробегать 10 км за 70 минут.

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

Заставлять и уговаривать тоже никого не пришлось. Желающих было с избытком, но часть отсеялась по собственному желанию, а часть по медицинским показателям. В качестве дополнительного стимула компания взяла на себя основные расходы на экипировку, проживание, еду и гидов. Организацией и планированием со словами «хоть бы никто там не умер» вечерами занималась лично основательница «Лаборатории Качества» — Наталья Руколь.

Формат

Безумное сочетание проекта «Дом 2», «Последнего героя», фильма «Вертикаль» и шоу Бенни Хилла.

В главных ролях

Веганы, айтишники-интроверты, многодетные отцы, мачо-переговорщики, семейные парочки, рукастые тестировщики, феи-маркетологи, дымящие аналитики и другие.

А теперь о самом процессе тестирования

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

Начиналось всё вполне себе стандартно. Насколько вообще может быть стандартным воссоединение людей, которые работают в сотнях километров друг от друга. Историческая встреча проекта «Эльбрус» состоялась в аэропорту Минеральных Вод. Многие впервые увидели коллег вживую, поэтому в удивлённых глазах зачастую читался вопрос: «Привет, а ты…?», — неловкая пауза… затем следовал столь же неловкий ответ, после которого все радостно обнимались и делали вид, что узнали друг друга тут же, с первого взгляда. Команда притиралась, начинала переходить от формата цифрового общения к более тёплому — человеческому.

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

Затишье перед бурей

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

Тучи сгущаются

Утро Пятигорска встретило нас первой болью в ногах, скоростными сборами, трамбовкой всего скарба в «Мерседес Спринтер» с колоритным кавказским водителем и трансфером жёстким забросом всей пока ещё изнеженной делегации ближе к театру реальных действий — на высоту 1500 метров в Архыз.

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

Картина: одинокая обочина горной дороги, безлюдье, дождь и сопровождающий его туман, люди вышли на разведку близлежащего кустарника, а через пару минут к нам несётся наш уважаемый Биг Босс со странным для закоренелого вегана вопросом: «У кого есть колбаса?». Пока мы думаем, что такое укусило Наташу в горах, она уже командует вытащить палку дорогущего балыка, без пяти минут нашего обеда, находит нож, назначает Романа, нашего маркетолога, мясником и с радостными глазами тащит его за собой в подлесок.

А там сюр: одни-одинёшеньки на километры вокруг, под деревом жмутся друг к другу два безродных щенка, братик и сестричка. Откуда взялись — непонятно, как нашлись — тоже, но это и не нужно. Им уже режется деликатесный балык. Щенки и Биг Босс довольны, мясоеды в компании голодны, но тоже рады этому маленькому чуду. Водитель чуть ли не плачет, остаток пути проходит в умилении под звуки урчащих желудков.

Буря в Архызе

Как говорится, ничего не предвещало… Милая предгорная деревушка, детские 1500 метров, радушные кавказцы и обалденная природа. А ещё «щадящая» программа адаптации к высоте: подъём в 5 утра, температура +- 0 летом, в 5:30 пробежка в гору под углом 45 градусов, камни и буераки, коровьи лепёхи, мозоли, а на десерт — первый серьёзный трекинг к Софийским озёрам.

«Простой трекинг», — говорили они… «Это только разминка, — говорили они, — главное — не смотри назад, а если упадёшь, то не кричи и тормози всем телом». Сложность этого первого для офисного планктона восхождения могла затмить только красота вида, открывшегося на озёра в конце нашего маршрута.

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

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

Нет лучше теста на слаженность действий, чем рафтинг. Или ты слушаешь команды руководителя отдела ПРИМы, благоразумно севшей в центре и делегировавшей вёсла сотрудникам, или ты соскребаешь себя с берегов и пороговых камней горной реки. А ещё эти попытки задать ритм гребле суматошными криками: «И раз, и два». Невольно вспоминаешь байки про Галеры ЛК… (Намёк на то, что наши сотрудники пашут, как рабы на галерах). Так вот они какие, эти галеры, самом деле.

Редко ходить — говорили они…

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

Долина, или поляна Азау, по заверению местных жителей, переводится как «редко ходить». Так вот, это тот самый случай, когда название и реальность не имеют абсолютно ничего общего. Ходить было куда, ходить нужно было не так уж и редко, но что компенсировало стёртые к вечеру ноги и болящие суставы, так это:

• всё более красивые места, куда мы забредали;

• всё более яркие эмоции, что мы получали;

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

Функциональное тестирование Эльбрусом

И только нам стоило привыкнуть ко всей этой красоте, как в нашу горную идиллию ворвался его величество Эльбрус. Вначале он сделал это мягко и ненавязчиво. Подъёмник забрал нас в Азау и высадил на 3500. Эльбрус козырнул нам приятной погодой и иллюзией своей доступности и простоты восхождения. В тот день мы поднялись на 4200. Порадовались своей крутизне, отсутствию симптомов горной болезни и спустились чуть ниже, в так называемый приют. Мы же про себя назвали этот вагончик «душным кошмаром клаустрофоба».

И тут наша команда начала сбоить. Высота вытягивала силы быстрее, чем мы успевали их восстанавливать. Появились проблемы с дыханием, гудели мышцы, активизировались болячки и простуды, напряглись нервы. Буквально за одну ночь компания уставших, но в целом жизнерадостных людей превратилась в кучку угрюмых зомби, бредущих куда-то в одиночном режиме по своим делам. Вот тут наш тимбилдинг перешёл в фазу шоу «Последний герой», когда формально мы оставались командой, но по факту каждый стал топить за себя. Функциональное тестирование Эльбрусом начало выдавать дефект за дефектом. Функции улыбок и эмпатии отвалились напрочь. Функции добрых слов и ободрений работали через раз. Ребята устали и поникли.

Весь следующий день команда разваливалась и умирала. Мы кое-как вползли на 4600 и вернулись в очередной приют «Сердце Эльбруса» на 3800, где продолжили ныть и разлагаться.

Волевая скрепа Руколь

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

Расчёт был верным — чтобы создать что-то более крепкое и сильное, нужно сначала уничтожить старое и отжившее, дать ему уйти и разложиться, а потом перестроить всё заново, заложить новый фундамент. Предпоследние сутки перед восхождением должны были показать, удалось ли нам обрести за эти 10 дней командный дух или мы так и остались людьми, что привыкли отсиживаться по ту сторону монитора.

И знаете, то ли помогла волевая скрепа Руколь, то ли действительно сказался груз совместно пережитых лишений, а возможно, мы наконец-то привыкли к внезапно набранной высоте, ветрам и скрипу снега под ногами, но именно в тот день мы смогли рвануть сразу на 5050. Кардинально сменилось и поведение: мы шли более слаженно, примерно в одном ритме, подтягивали отстающих, подбадривали их на стоянках, а на конечной точке «Замёрзший ратрак» сделали вот такое замечательное фото.

24-часовая готовность

За оставшийся перед восхождением день удалось закрепить полученный эффект. В этот день мы отдыхали, отсыпались, отъедались, общались в уютной кафешке «Сердца Эльбруса», периодически забывая, что мы посреди горы, на высоте 3800.

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

Нагрузочное тестирование Эльбрусом

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

Резкая команда гида «Всё, выходим» вывела нас из мрачного оцепенения, мгновенный испуг на лицах сменила мрачная решимость и стремление идти до конца. Команда айтишников и офисного планктона уходила в ночь, выхватывая тусклыми фонариками 2–3 метра оледенелого горного подъёма перед собой. По склону можно было увидеть огни медленно ползущих вверх ратраков других групп восхождения. Во тьме казалось, что это какие-то таинственные светящиеся создания плывут в небе в направлении звёзд.

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

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

Погода постепенно наладилась, вместе с лучами солнца у кого-то открылось второе, а у некоторых — уже пятое дыхание. Короткие стоянки сменялись продолжительными марш-бросками. ЛКаши подустали, начали выбиваться из сил, но эффект единения, достигнутый в предпоследний день, не давал духу в группе упасть. Мы часто думали, что «вот ещё немного — и я достигну своего лимита, я больше не могу», но закалённая тренировками сила воли и поддержка команды помогали находить силы на новый рывок и отодвигать лимиты до сверхчеловеческих для работников IT-индустрии границ.

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

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

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

P. S. В итоге, забив на принципы, мы спустились ножками на несколько сотен метров, а дальше арендовали снегоходы и с ветерком прокатились до «Сердца Эльбруса». Там нас уже не стеснял режим, и потому было решено закатить небольшую пьянку, а впереди нас ждали ещё три дня в Пятигорске, но это уже совсем другая история…

Результаты

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

1. Во-первых, наладилась коммуникация между отделами. Управленческая информация циркулирует теперь более свободно, а не застревает в ведомости какого-то конкретного ТОПа. Отделы стали охотнее кооперироваться и уже провели стратегическую сессию, совместно наметив решение насущных задач.
2. Выпустили пар. Конфликты были, были и переходы на личности, впрочем как и слёзы, извинения и обнимашки. Никто не ушел обиженным.
3. Сотрудники увидели своих руководителей за пределами кабинетов и скайпов, живыми, в бою, с опухшими губами и соплями по всему лицу. Подорвало ли это авторитет? Скорее наоборот.
4. Стало меньше бюрократии. Там, где задачи должны решаться быстро, они стали решаться без лишних согласований, под честное слово, которое стало весить заметно больше.
5. Появились общие цели и ориентиры. Мы наконец-то поняли, что плывём в одной лодке (спасибо рафтингу) и чтобы преодолеть течение, грести лучше синхронно.
6. Заряд энергии, который передался всей компании и чувствуется даже спустя месяц.

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

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

Мой путь в ABBYY начался, когда я учился на 5 курсе МФТИ и думал, чем хочу заниматься. Я увлекался математикой и задачами по построению искусственного интеллекта, но при этом мне всегда было интересно, как устроены естественные языки и как можно научить машину понимать их. Поэтому в какой-то момент я заинтересовался компьютерной лингвистикой. ABBYY — мировой разработчик решений в области интеллектуальной обработки информации и лингвистики. Я принял участие в Дне открытых дверей ABBYY в МФТИ, решил за 2 часа несколько задач, и меня пригласили на вакансию онтоинженера.

Работа онтоинженером

Работа онтоинженера интересна тем, что она проектная и очень прикладная. Есть конкретная задача, которую нужно решить с помощью доступных технологий. Я начал работать в учебной группе: три месяца обучался, сдавал специальные экзамены по семантике, синтаксису и онтоинженерии. В информатике онтология — это попытка формализовать определённую область знаний. Онтоинженерия — это проектирование предметной области с помощью онтологий, описание структуры базы знаний, а также программирование на продукционном языке, который сконструировали в ABBYY. С помощью него описывается, как базы знаний должны наполняться из текстов. Наш отдел рос, задачи усложнялись, появлялось всё больше аналитических вопросов. В результате в департаменте обработки естественного языка (NLP) стали необходимы системные аналитики. Я на тот момент постоянно предлагал группе программистов что-то улучшить, упростить, сделать удобнее, автоматизировать тестирование. В итоге мне предложили роль системного аналитика — для меня это был горизонтальный рост. Я согласился, так как всё ещё искал себя (и сейчас ищу, на самом деле), и роль системного аналитика показалась мне перспективной. Мне казалось, что в качестве онтоинженера я уже сильно вырос: я участвовал во всё более сложных проектах с другими онтоинженерами, которые мне помогали. Пример такого проекта: технология для компании нефтегазового сектора, которая оптимизировала анализ отчётности со своих участков по всей стране. Каждый день в аналитический центр компании в Москве приходили сводки, которые анализировали несколько десятков человек. Я описывал онтологическую модель, с помощью которой технология извлекала из сводок нужную информацию.

Некоторые онтоинженеры у нас работают на этой позиции дольше и делают очень сложные проекты. К примеру, создают модели на машинном обучении, которые потом дообучаются на стороне клиента уже в продукте. Некоторые становятся тимлидами и руководят начинающими онтоинженерами. Другие, кому, как мне, интересны разные области, становятся системными аналитиками или программистами и занимаются разработкой. Программируют они уже не на продукционном языке, а на C++ или Python.

Работа системным аналитиком

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

Роль системного аналитика была своего рода экспериментальная, поэтому в какой-то момент моя работа всё больше становилась похожа на работу продакт-оунера или продакт-менеджера, только с внутренними заказчиками. Так я стал продакт-менеджером в отделе обработки естественного языка департамента исследований и разработок. Чем отличается должность продакт-менеджера в технологическом департаменте от продуктового? В продуктовом департаменте общаются с внешними потребителями, а в технологическом — с внутренними. Это могут быть менеджеры продуктовых департаментов или внутренние пользователи, которые занимаются проектной деятельностью для внешних заказчиков (онтоинженеры). В то же время у меня оставались задачи системного аналитика. Я формулировал для программистов требования бизнеса, которые мне передавал продуктовый департамент. В мои обязанности также входило обсуждение этих требований и формулирование конкретных технических требований для группы разработки в технологическом департаменте. Если ты, будучи аналитиком или продакт-менеджером, умеешь программировать, тебе будет гораздо проще. Это даст понимание того, чем занимаются программисты, а также как декомпозировать и измерить задачу.

Работа продакт-менеджером

Спустя год моя роль снова поменялась. Сейчас я продакт-менеджер, но уже отвечаю за продукт, точнее его отдельную часть, связанную с NLP. Это ещё одна новая роль для меня, в которой я продолжаю находиться внутри большой команды, глобально ответственной за одно направление, но теперь я ближе к маркетингу и заказчикам. Моя задача — создание продукта для внешнего пользователя. Так как я отвечаю не за отдельный продукт, а за компонент (у общего продукта есть директор), одна из задач — сделать так, чтобы продакт-менеджеры всех отдельных компонентов примерно одинаково понимали то, как должен развиваться продукт. Нужно делать так, чтобы компоненты подходили друг другу, развитие было согласовано, тестирование осуществлялось правильным образом. Сложно сказать, вертикальный это рост или горизонтальный. Эта позиция предполагает большую ответственность. Это усложнение и углубление моей роли в более продуктовом ключе. К тому же в работе я теперь активно использую английский язык как для чтения, так и для коммуникации с зарубежными коллегами. Иногда на это уходит до 50% рабочего дня.

Про горизонтальный рост

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

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

Как понять, куда расти дальше, если нет желания и/или возможности развиваться вертикально?

Во-первых, важна квалификация. Очевидно, чтобы программировать на C++, надо знать C++ и ещё много чего. Но дело не только в hard skills. Чтобы работа на новой позиции приносила радость, важно учесть три момента:

1. Какой большой красивой задачей вы хотите заниматься? Это может быть план на десятилетие. В моём случае это развитие искусственного интеллекта, в частности компьютерной лингвистики. Вы, может быть, хотите отправить человека на Марс (почему нет?). Подумайте о том, что вас увлекает, и сконцентрируйтесь на этом.
2. Затем нужно подумать, чем именно вы хотите наполнять свой рабочий день. Вы хотите взаимодействовать с людьми? Или хотите только программировать? Вам интереснее программирование, аналитика, тестирование или что-то ещё? Задачи для людей с одними и теми же hard skills, но разным темпераментом могут сильно отличаться.
3. Наконец, важно учесть скорость, с которой происходят события на работе. Подумайте, насколько быстро вам надоедает та или иная тема и насколько быстро хочется сменить деятельность. Если время идёт для вас слишком быстро, следует искать позиции, на которых в день будет не десять задач, а две. Если хочется, чтобы всё сменялось быстро, тоже ищите что-то другое. Это очень зависит от отдела и позиции: например, работая в исследовательском департаменте, вы занимаетесь вещами, которыми никто прежде не занимался. От того момента, когда вы решили что-то попробовать, до момента, когда у вас что-то получилось, может пройти очень большое количество времени. Другой полюс — это, например, sales-инженеры, которые из продукта или нескольких продуктов запрограммируют решения. То, что они делают сейчас, через час уже может попасть к клиенту.

Если говорить про мой опыт, онтоинженер в плане скорости событий где-то посередине. У аналитика всё идёт быстрее. Роль продакт-менеджера предполагает ещё более быструю смену событий и довольно высокий уровень абстракции, но при этом вы должны быть погружены в специфику задач разработчиков, с которыми вы регулярно взаимодействуете. Чем более стратегическая и абстрактная у вас позиция, тем быстрее ваши задачи сменяют друг друга. Опираясь на это правило, вы сможете понять, в каком направлении вам стоит развиваться в карьере в IT.

Настя, Senior Test Engineer, QA division manager

Совет 1: спрашивайте!

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

Совет 2: записывайте!

Появилась мысль о том, что можно сделать в проекте? Сохраните. Пришла в голову идея, как можно усовершенствовать свои навыки? Запишите. Потом можно пересмотреть эти заметки и почерпнуть что-то важное, а может, понять, что вы уже чего-то достигли. В кризисные моменты такие «сохранёнки» помогают вспомнить, почему вы вообще выбрали то, чем занимаетесь.

Совет 3: вдохновляйтесь!

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

Совет 4: играйте!

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

Совет 5: рассказывайте!

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

Антон, web-разработчик

Совет 6: читайте!

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

Отдельным подпунктом идёт документация в оригинале: original mode предпочтительнее — и потеря информации меньше, и прокачка языка сильнее.

Совет 7: отдыхайте с пользой!

Чаще всего, когда приходишь после работы домой, хочется отдохнуть — поваляться на диване, повтыкать в YouTube, почитать что-нибудь перед сном… Отдыхайте с умом! Возлежа на диване, разбирайтесь в issues на GitHub; предпочтите новому эпизоду сериала полезное выступление коллеги по цеху; вместо подсчёта овец щёлкайте в уме алгоритмические задачки — всё это незаметно тренирует мозг, увеличивает базу знаний, и вы даже не замечаете, как прокачиваетесь!

Совет 8: дерзайте!

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

Василий, Java-разработчик

Совет 9: слушайте с умом!

Я бы посоветовал фильтровать информацию и иметь своё мнение, оставаясь при этом гибким. Умение работать с информацией особенно много значит на первых порах: информации много, источники разные, точки зрения противоречивые… И пока до конца не усвоил фундаментальные вещи, кажется, что всё существенно; пока сам не попробовал несметное количество технологий и не понаписал велосипедов, уровень других разработчиков представляется нереально крутым. Это нормально, это проходит ? Важно критически относиться к информации, рассматривать проблему с разных точек зрения, а в качестве ориентира можно выбрать позицию более опытных товарищей, которые уже доказали свой авторитет на практике. Это совсем не технический навык, но удивительно важный в разработке.

Совет 10: учите матчасть!

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

Андрей, JS-разработчик, JS division manager

Совет 11: изучайте основы!

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

Совет 12: прокачивайтесь!

Никогда не переставайте учиться. Жизнь программиста как жизнь учёного: всё время необходимо изучать новое, иначе выйдешь в тираж. Старайтесь не только читать, но и практиковать новые навыки и знания. Курсы — отличный способ с помощью небольших статей и практических заданий изучить новую технологию. Дальше — только практика и стремление к совершенству.

Павел, старший web-разработчик

Совет 13: общайтесь!

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

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

Важно уметь не только работать самостоятельно, но и просить о помощи, если непонятен какой-то конкретный момент. Не уходить в себя.

Как видите, чтобы быстро освоиться в новой для себя IT-сфере, достаточно искреннего желания разобраться, не стоять на месте, быть самостоятельным в профессии. Начало — уже половина дела, и с каждым следующим шагом будет становиться всё легче. Удачи всем, кто пробует! Желаем стать суперпрофи своего дела!

Как эффективно изучить новый язык программирования? Вопрос, с которым сталкивается каждый разработчик. За 11 лет в ИТ я сам изучал 10 языков и на практике понял, какие моменты нужно учесть для лучшего освоения.

Цель первична

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

Язык может быть нужен, чтобы:

• устроиться на работу в компанию, где основной язык C#;
• написать ПО для межконтинентальной ракеты;
• создать свой сайт;
• оптимизировать запрос к базе данных на PostgreSQL в чужом проекте;
• получить статус Senior-разработчика.

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

Теория и практика

Теория нужна, чтобы как можно быстрее перейти к практике!

• Первым делом установите среду разработки — так будет проще писать код и запускать свои новые программы.
• Затем возьмите учебник. Не важно, из серии «для чайников» или толстенный справочник — ориентируйтесь на свой уровень и цели.
• Если учебники навевают тоску и воспоминания о школе — в сети есть огромное количество видеокурсов, лекций и вебинаров (ищите в YouTube).
• Ещё один хороший инструмент для изучения — интернет-площадки, которые предоставляют полноценные курсы с теорией и практическими заданиями. Например SoloLearn с мобильными приложениями.

Было бы желание, а способ изучения и материалы найдутся.

Окружение

Окружение становится турбокнопкой к эффективности.

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

Изучать синтаксис языка программирования исключительно в теории не стоит. Помню, когда я учился в 9-ом классе, когда у меня даже не было компьютера, я прочитал книгу про Algol-60 и ничего не понял. В освоении языков самое важное — практика! Поэтому на первых этапах надо изучать не синтаксис, а идиоматику — средства, которыми принято выражаться в этом языке. Надо научиться понимать, как правильно формулировать. Без этого код будут плохо понимать другие программисты, даже если синтаксис будет правильным.

Если говорить об алгоритме изучения языка, советую:

1. Сначала почитать об этом языке: его истории, синтаксисе и основных инструментах. На это человеку, который уже знает основы программирования, достаточно будет потратить один вечер.
2. Начать читать чужой код. Если надо научиться языку Scala или Clojure, я иду на GitHub, нахожу работающие проекты или известных людей, заслуживающих доверия, и изучаю их код. Как художник вдохновляется шедеврами признанных мастеров, программист может учиться идиоматике языка, читая код более опытных специалистов.
3. Уже через пару дней можно начать экспериментировать и делать попытки создать что-то своё. Если язык позволяет написать web-сервис, можно сделать записную книжку, прогноз погоды, что-то несложное. Меняя код, искать наилучшие варианты, постепенно усложняя задачи.
4. После этого нужно начать применять новый язык в решении реальных задач, углубляя в процессе его понимание и способы применения. Тут уже нет предела совершенству!

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

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

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

При этом очень важна самостоятельная работа. Чем больше упражнений будут сопровождать ваше пособие, тем лучше. С учётом того, что вы начинаете с маленьких упражнений, вам будет сложнее допустить ошибку и проще найти и понять, как её исправить.

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

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

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

Несколько слов стоит сказать о практической задаче. Лучше всего пробовать решать какую-то свою актуальную задачу (например реализовать приложение для управления компонентами «Умного дома»), максимально её упростив для начала. Как показывает мой опыт, это отлично мотивирует, ведь на выходе удаётся достичь сразу двух целей: и язык/технологию новую изучить, и реализовать давнюю идею.

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

Вы начинающий программист

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

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

Вы уже знаете один или несколько языков программирования

В этом случае достаточно прочитать книгу или посмотреть видеолекции по нужному языку программирования. Проходить курсы вряд ли необходимо, так как они в подавляющем случае разработаны для начинающих программистов, и темп изучения покажется вам слишком медленным. Единственное, что нужно помнить — в каждом языке есть свой подход к написанию кода. Например, если вы изучали JavaScript, а потом захотели освоить Golang, не пытайтесь писать код на Golang, используя практики программирования на JavaScript. Лучше потратить дополнительное время для изучения best coding practices изучаемого языка, чтобы не быть «белой вороной» и не вгонять в ступор других людей, когда они увидят получившийся код.

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

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

На мой взгляд, наиболее приближен к идеалу следующий алгоритм изучения языка:

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

И запомните одну вещь — учиться и совершенствоваться необходимо на протяжении всего своего пути. Это аксиома.

Если речь идёт о программисте, который уже умеет кодить и работать со сторонними библиотеками — это одно дело. Уже есть понимание механизма и нужно наращивать, что называется, «мясо» — добавлять знания новых языков к уже имеющимся. Если же речь о том, кто только учится, то не рекомендую начинать обучение с конкретных языков. Нужно учиться кодить в принципе. То есть строить алгоритмы.

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

Как для обучения, так и для развития новых компетенций у работающих программистов отлично подходят различные практические тренажёры. Например, полезно решать задачи по олимпиадному программированию, где знания определённого языка накладываются на решение задач с использованием другого. Среди резидентов технопарка популярна площадка Timus Online Judge — крупнейший архив задач по программированию с автоматической проверяющей системой. Особенность таких тренажёров в том, что для решения задач не используются фреймворки, сторонние библиотеки и методы сортировки. Ты должен сам писать код от и до. Отлично прокачивает умение строить алгоритмы.

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

Отличный вариант «прокачки» компетенций в том или ином языка — стажировка в сильной проектной группе, в IT-компании, специализирующейся на этом языке. Это самый экстремальный, но, пожалуй, самый эффективный способ быстро освоить язык программирования.

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

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

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

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

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

Какой бы способ изучения вы не выбрали, самым важным является практика! В программировании совершенно не важно, какие курсы или учебные заведения вы окончили. На любом собеседовании вам будут задавать предельно практичные вопросы. Поэтому во время или после прохождения какого-либо курса или по ходу изучения языка самостоятельно практикуйтесь как можно больше. Если перевести соотношение теории к практике в проценты, то, на мой взгляд, оно составит примерно 20/80. Работодателю важно сразу после найма получить работоспособного программиста, а не тратить время на перевод теоретических знаний в практические навыки и умения.

Вопрос достаточно сложный. Нельзя выбирать между теорией и практикой, должна быть гармония. Нужно учить синтаксис и понимать алгоритмы и основы. При этом без практики эти знания не имеют ценности. Нужно чередовать — прочитали некоторую часть, затем опробовали на практике. При этом, на мой взгляд, совсем не обязательно покупать платные подписки на курсы. Очень много материалов есть в открытом доступе. Большое количество интересных практических задач можно получить, задав в Google вопрос «олимпиадные задачи по программированию». На них вам придётся поискать и почитать теорию про алгоритмы, их сложность, структуры данных и прочее. При этом они дают возможность писать свой код, и потом при разборе увидеть свои ошибки и варианты решения из best practice.

Как только почувствовали уверенность — нужно браться за боевые задачи, чтобы увидеть реальный мир и реальные проблемы. Зачастую в учебнике и обучающих задачах многие сложные и интересные практические моменты пощупать не получится. Начните писать свой проект на GitHub. Ещё очень важный момент: ваш шанс на успех сильно повысит наличие ментора — более опытного друга/коллеги/наставника, который может помочь, если у вас «затык», что-то объяснить, проверить результат вашей работы и дать правильный вектор вашему развитию. Никогда не останавливайтесь на достигнутом. Удачи.

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

Следующие шаги помогут вам сделать это правильно.

Определитесь с конечной целью

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

А может, вы хотите уметь делать и то, и другое, и третье?  Такое тоже возможно.

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

Учите синтаксис небольшими порциями

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

Сразу применяйте знания на практике

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

Решайте задачи по программированию

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

Переходите к созданию проектов

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

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

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

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

Алгоритм может быть следующий:

1. Выбор языка (например Python), на основе широты его применения, актуальности и прогноз, где язык может быть использован (например Data Science).
2. Просмотр нескольких скрин-кастов (от простого к сложному), оценка барьера вхождения (достаточно ли у меня скилов на освоение языка, например хватит ли мне знаний математики для программирования на Python).
3. Поиск готовых решений и наработок для примера.
4. Подбор литературы (в рамках данного примера масса бесплатных вариантов).
5. Финальный шаг: идём в сторону Coursera, а потом уже наступает «инженерка» с реальными задачами и решением проблем в обнимку со StackOverflow.

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

Если говорить о фронтенде, то обязательные основы — HTML и CSS, нужные для вёрстки, и язык программирования JavaScript, который делает сайт интерактивным. Фронтенд-разработчику важно понимать на базовом уровне, как устроен бэкенд, поэтому нужно изучить, как происходит сборка проекта — подключение сайта к серверу и его «доставка» до пользователя.

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

Через месяц-полтора уже получится сверстать несложный сайт, ещё через два месяца — «оживить» сайт при помощи JavaScript и адаптировать его для разных устройств.

Чтобы учиться было интереснее, придумайте себе проект (сайт) и начните его воплощать — верстать, писать код. Дело пойдёт быстрее, потому что код не будет абстрактным, перед вами будут стоять конкретные задачи, решение которых вы будете искать. В Яндекс.Практикуме мы предлагаем студентам сделать пять проектов: четыре шаблонных и одна полностью индивидуальная дипломная работа. Эти проекты они смогут сразу положить в своё портфолио.

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

1. Изучение базового синтаксиса.
2. Некая математическая база (линейная алгебра), которая даёт понимание для пространственного мышления — помогает разбираться в матрицах, массивах, объектах, строить алгоритмы. Если база есть — двигаемся дальше, т.к. она одинакова для всех языков.
3. Далее уже изучаем архитектуру языка для написания классов, объектов.
4. Попутно узнаём методы отладки и дебага.
5. Те, кто дожил до этого момента, приступают к изучению паттернов, применяемых к архитектуре именно этого языка.
   Но перед всей этой кухней идёт очень важная вещь — настройка рабочей среды. В каждой ОС по-своему: установка самого языка, поиск удобного текстового редактора, установка всяких побочных программ типа Docker, веб-сервера и пакетных установщиков.

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

Ещё один вариант. Придумываете для себя простой, но интересный проект, а далее начинаете его пытаться делать, параллельно задавая вопросы в Google или StackOverflow. Там можно прояснить вопросы простого характера и найти в комментариях полезные мнения. Но тут есть и минус. Без понимания базовых концепций программирование может превратиться в «загугли решение». Некоторые девелоперы так и копируют асинхронные функции, не понимая, что такое вообще асинхронность.

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

Ответ во многом зависит от языка программирования и сферы его применения.

Допустим, человек занимается научными исследованиями, и сотрудники его лаборатории в проектах используют Fortran — это одна ситуация. Другой вариант — студент, изучающий машинное обучение, который хочет писать проекты на Python. Ещё вариант: разработчик решил изучить С++, чтобы устроиться на работу в коммерческую компанию. Эти и другие ситуации требуют разного подхода и объёма прилагаемых усилий для изучения языка.

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

1. Найдите хорошую книгу, освещающую основной синтаксис языка, с примерами и объяснением принципов работы. От правильного выбора книги зависит многое, она сформирует ваше первоначальное «видение» языка. Разумеется, в будущем оно будет корректироваться по мере накопления вашего личного опыта работы с ним.

2. Практика. В каждом языке есть свой «Hello, world!». Пытайтесь сразу же применять полученные знания на практике, закрепляйте освоенные конструкции языка.

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

4. Изучайте основы ООП, паттерны программирования, алгоритмы и структуры данных. Посмотрите, как устроены библиотеки внутри, загляните в их код. Великолепное формальное знание языка ещё не означает, что вы будете писать элегантный и эффективный код на нём.

5. Старайтесь, чтобы ваш код увидело как можно больше коллег, чтобы как можно раньше получить фидбэк на то, как вы пишете или оформляете код. Оформление кода или code style в крупных проектах — отдельная тема, и её тоже следует изучить. Также как и процесс code review.

6. Если вам требуется глубокое понимание языка (например если вы разработчик в крупной коммерческой компании), не ограничивайте себя изучением только его одного. Посмотрите вокруг на остальное: скриптовые языки, ассемблер. Задайте себе вопрос, чем они отличаются, почему устроены иначе, какую цель преследовали авторы этих языков? Изучайте различные фреймворки, библиотеки, погрузитесь немного в теорию компиляции, разберитесь с тем, как устроен процесс «сборки» проектов в разных средах.

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

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

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

10. Помните, что нельзя «изучить» какой-то язык «от и до». Язык не монумент, он живёт и развивается, это же справедливо и в отношении естественных языков. И если язык «живой», востребованный в мире, то процесс изменений в нём со временем становится всё более интенсивным.

На этом у меня всё. Ищите свой путь, не бойтесь наступать на «грабли». Чем раньше вы их «соберёте» — тем меньше «мин» будет в проектах, которые вы после себя оставите.

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

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

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

Следующий важный этап — выбор специализации и последовательное её освоение. Разные языки программирования позволяют писать код под разные платформы. Так, используя Java, можно создавать серверные и мобильные решения (например для Android). C# позволяет писать практически всё: серверные, мобильные, десктопные и веб-решения. Здесь также будет эффективным самообучение по книге. Однако параллельно с этим нужно задумываться о развитии собственных навыков с точки зрения архитектуры написания кода. Изучать мануалы по паттернам проектирования и пытаться применять знания на практике. Это, пожалуй, самый простой и надёжный алгоритм.

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

Если посвятить всё своё продуктивное время обучению, то полностью освоить язык программирования (не включая специализацию в разработке ПО) можно за один календарный месяц. Но это при условии, что человек не станет отвлекаться на постороннюю деятельность и будет практиковаться в написании кода, углубляясь в специализацию.

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

Итак, как лучше изучать язык программирования?

Каждый эксперт рекомендует свой алгоритм, но мы выписали и объединили общие пункты:

1. Определитесь, как и когда вы будете изучать язык: настройтесь на то, что на изучение в свободное от работы время уйдёт минимум несколько месяцев и старайтесь определить для себя постоянный график: лучше заниматься по часу каждый день, чем по 12 часов раз в неделю.
2. Если есть возможность, найдите себе ментора — более опытного программиста, который поможет определиться с планом изучения, будет отвечать на вопросы и делать code review.
3. Выберите и начните изучать курс или книгу с объяснением основ языка.
4. Параллельно с изучением выполняйте все предложенные практические задания и пробуйте себя на платформах вроде Codewars. Делайте упор на практику, а не теорию, потому что без решения задач вы не сможете разобраться в работе языка программирования.
5. Когда освоитесь с основами, придумайте какой-нибудь интересный лично вам проект, желательно имеющий практическое применение, и попытайтесь его реализовать. Его же потом можно будет сразу включить в своё портфолио.
6. Поищите в открытом доступе, например на GitHub, проекты других людей на выбранном языке и разберитесь, как в них всё устроено. Обращайте внимание на оформление кода и шаблоны его построения — это поможет писать более качественный и понятный другим людям код в будущем. Попробуйте изменить функциональность конечной программы, редактируя чужой код или дополнив программу своим.
7. Расширяйте кругозор: обращайтесь к другим книгам и людям на форумах, ищите нужную вам информацию в разных источниках.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

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

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

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

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

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

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

Этап 1. Тренироваться на простых задачах

В Сети есть множество сайтов, на которых начинающий специалист может прокачать свои навыки, решая задачки по программированию. Возьмём в качестве примера ресурс Codewars. После регистрации на сайте можно приступить к выполнению программистских задач, известных как «ката». Как и в боевых искусствах, откуда пришёл этот термин, «ката» предназначены для отработки определённых наборов движений (нажатий клавиш), с которыми можно столкнуться в реальной работе. Начать, конечно, стоит с решения самых простых заданий, а затем постепенно выбирать всё более и более сложные. Выполняя эти упражнения и оттачивая навыки работы с различными языками программирования, начинающий программист перестанет задумываться о том, какая последовательность действий приведёт его к решению той или иной задачи при написании кода. Кроме того, после выполнения каждого задания можно посмотреть, как с ним справились другие участники, и научиться у них чему-то ещё.

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

Этап 2. Написать что-то своё и выложить это в открытый доступ

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

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

Когда создадите проект, выложите его на GitHub (не забудьте добавить описание в README.md). При дальнейшем трудоустройстве вы сможете показать этот проект работодателю — наличие даже простого проекта в портфолио будет лучше, чем его отсутствие.

Этап 3. Наконец-то устроиться на работу

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

И самое главное — будьте целеустремленными! Как говориться, дорога возникает под шагами идущего.

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

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

К тому же, такой мини-проект отлично покажет начинающему программисту его пробелы в образовании.

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

Участие в open-source проекте прибавит знаний о правильно организованном процессе разработки, научит работать с системами отслеживания ошибок и т. п.

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

Компетентность в программировании, как и в любом другом направлении, можно условно разделить на 4 уровня:

1. Неосознанная некомпетентность — когда вы не знаете, как делать правильно, и не понимаете это.
2. Осознанная некомпетентность — когда вы не знаете, как делать правильно и понимаете это.
3. Осознанная компетентность — когда вы знаете, как делать правильно.
4. Неосознанная компетентность — когда правильные действия выполняются на «автопилоте» без обдумывания каждого шага.

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

1. Продолжать обучение по выбранному направлению. Сейчас существует очень много курсов по разным технологическим стекам на разных уровнях от новичка до эксперта. Очень много вариантов для дистанционного обучения в Интернете (лично я советую рассмотреть такие сервисы как, например, Udemy или Coursera).
2. Найти себе наставника. Важно найти одного или, ещё лучше, несколько более опытных людей, с которыми вы сможете советоваться и обсуждать, куда именно вам надо двигаться дальше. Это могут быть как ваши знакомые из различных IT-сообществ, так и коллеги на работе.
3. Решать практические задачи. Я убежден, что для всестороннего развития одного обучения недостаточно, и важно параллельно с обучением устроиться на начальную позицию разработчика и заниматься решением практических задач. Здесь, на мой взгляд, необходимо правильно договориться с работодателем о том, как будет организована ваша работа и развитие в компании: а) какой у вас будет план развития от младшего до среднего или старшего разработчика; б) кто и как из более опытных коллег будет контролировать результаты вашей работы и советовать, что нужно доработать. Очень часто начинающих разработчиков в IT-компаниях бросают один на один со сложными техническими задачами и смотрят: «выплывет или нет». Такой подход, по моему мнению, в корне неправильный и никого не приведёт к хорошим результатам.
4. Получить высшее образование по специальности. Если у вас непрофильное образование — идеальный, на мой взгляд, вариант в совокупности с предыдущими пунктами получить высшее образование по технической специальности. Я считаю, что есть существенная разница между тем, чтобы отдельно изучать язык программирования, и тем, чтобы в комплексе узнать, что в жизни не всё так просто, как кажется. Московские вузы, которые дают отличную техническую базу: Высшая Школа Экономики, МГУ, МФТИ, МГТУ и МИФИ.

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

После «Hello, world!» всегда следует вопрос: «Что делать дальше?». А дальше есть два варианта: учиться решать сложные задачи снизу вверх или сверху вниз.

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

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

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

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

1. Выберите сферу разработки, которая вас больше всего интересует в данный момент (веб-сайты, мобильные приложения, игры, бизнес-приложения, Data Science, искусственный интеллект и т. д.) При выборе нужно также учитывать специфику языка, потому что язык программирования чаще всего подходит не для каждой сферы.
2. Выберите IDE, в которой наиболее комфортно работать.
3. Выберите подходящие библиотеки / фреймворки в соответствии с выбранной сферой. 3–5 библиотек для начала будет достаточно. Возможно, также потребуется изучение дополнительных языков. Например, если планируется работа с реляционными базами данных, то нужно будет изучить один из диалектов языка запросов SQL (рекомендую порешать задачи на этом сайте). Параллельно неплохо бы изучить хотя бы самые простые команды оболочки операционной системы, в которой вы работаете или для которой будете писать приложение.
4. Поищите статьи, видеоуроки или курсы, в которых содержатся начальные сведения о выбранных библиотеках, а также разбираются несложные примеры или даже небольшие проекты для сферы разработки, выбранной в пункте
5. Разберите и изучите команды, встречающиеся в проектах или примерах из пункта 4. Для этого подойдёт документация по библиотекам, а также статьи по ним на других ресурсах.
6. Попробуйте повторить примеры или проекты из пункта 4. Добейтесь того, чтобы они заработали. Также учитесь писать программы, состоящие из нескольких файлов, разберитесь, как они связаны между собой.
7. Если в языке, который вы изучаете, используется ООП (объектно-ориентированное программирование), изучите его основы именно для этого языка. Если же в этом языке больше в ходу функциональное программирование, почитайте про него.
8. Попробуйте внести улучшения в изученные примеры или проекты или даже полностью перепишите их с нуля.
9. Изучите азы Git, а также заведите аккаунт на GitHub.
10. Найдите идею для собственного проекта и начните работу над ним, выкладывая его версии на GitHub.
11. Параллельно с работой над проектами изучайте алгоритмы и структуры данных, а также алгоритмы, характерные для выбранной сферы разработки.
12. Для дальнейшего развития имеет смысл получить опыт в рабочей обстановке, так как для программиста важно не только самостоятельно развиваться, но и получать живой опыт, взаимодействуя с коллегами-программистами.

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

Надо помнить, что любая самая сложная задача состоит из большого (иногда очень большого) количества простых задач. К любой задаче нужно сначала подходить с декомпозицией, другими словами: «Разделяй и властвуй». Если вам не ясно, как разложить задачу на составляющие, попробуйте её упростить. Если и это не поможет, то задачу стоит отложить — время для неё обязательно придёт позже.

А ещё лучше такие задачи решать не одному, а в компании единомышленников. Соревновательный эффект и помощь друзей — это очень сильные факторы, которые помогут сделать первые шаги в решении сложных задач.

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

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

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

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

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

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

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

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

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

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

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

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

Начинать легче с простых багов и переходить к фичам. Чтобы побороть страх, нужно делать как можно больше задач. Тут важна и поддержка коллег. Лучше, чтобы на начальном этапе был ментор, но можно обратиться к Google.

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

Самый простой способ — это декомпозировать задачу и постепенно её решать. Особенно в этом помогают разнообразные туториалы.

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

Начнём с декомпозиции. Что принципиально должен уметь блог в виде минимального прототипа?

• Мы должны уметь смотреть посты;
• Мы должны быть способны логиниться;
• Мы должны уметь делать и удалять посты.

Теперь давайте подумаем, что нам нужно для реализации этих фич.

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

Сначала бэкенд. Мне нужно выбрать какую-нибудь СУБД для хранения моих постов в блоге и бэкенд-фреймворк, мне нужно реализовать систему авторизации любым способом, который я придумаю, и мне нужно реализовать простое API, чтобы собственно делать и получать посты со стороны клиента. Включаем волшебную Google-машину и смотрим, какие СУБД есть и какие в них плюсы и минусы, какие фреймворки существуют, и как можно организовать авторизацию и API. После поисков мы выбираем MySQL, потому что нам нужно что-то предельно простое и заезженное, Express в качестве фреймворка (ищем в Google-машине Express MySQL tutorial/example), делаем авторизацию через куки (ищем Express authorization cookie tutorial/example) и организуем API в стиле REST (Express REST tutorial/example).

Теперь мне нужно написать на React’е (потому что на чём же ещё?) морду к моему блогу, что тоже довольно легко сделать, поскольку Интернет ломится от туториалов по данному вопросу (что гуглить, я думаю, вы сами догадаетесь).

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

Я не рекомендую бездумно копипастить решения, я рекомендую использовать туториалы на этом уровне как способ заполнить белые пятна в своих знаниях. Также хочу заметить, что в индустрии в целом рекомендуется думать во время написания кода и не прибегать к Stack Overflow driven development. Но когда у тебя нет практических познаний в определённой области, нет ничего плохого в том, чтобы посмотреть, как это делали люди до тебя.

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

Сложность возникающих перед новичком задач должна расти постепенно, чтобы старт карьеры не превращался в стресс. Когда появляется задание, масштабы и сложность которого расходятся с привычными, возникает страх. Чтобы не стушеваться, важно понять его природу: чаще всего под ним скрываются простые человеческие чувства — испуг перед неизвестностью и боязнь критики/осуждения.

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

Даже самый простой подход к планированию поможет. Сначала следует наметить границу, где задача завершается («Как я пойму, что я достиг цели?»). Потом декомпозировать её на подзадачи. И ключевые подзадачи, связанные с осязаемым промежуточным результатом, выделить как майлстоуны. В этих точках важно показать текущий прогресс, получить обратную связь, скорректировать ход разработки.

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

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

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

Итак, как перейти к решению сложных задач?

• Учитесь декомпозировать задачу на простые составляющие.
• Поставьте себе задачу написать какую-нибудь полезную программу. Обложитесь материалами для изучения нужных технологий и закрепляйте знания на практике в процессе создания вашего проекта.
• Если вы хорошо разбираетесь в технологии, то можно попробовать разобраться в коде людей, которые пишут сложные проекты с её использованием.
• Не стесняйтесь просить помощи у коллег и Интернета — нельзя знать всё и вся, тем более будучи новичком.
• Попробуйте найти какой-нибудь open-source проект и внести свой, пусть даже если и небольшой, вклад.
• Продолжайте учиться и решать практические задачи.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

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

Мои советы не сверхоригинальны, но и о них можно забыть, застряв в рутине. Поэтому:

• Смените на время рабочее окружение. Работаете дома? Марш в офис или в коворкинг на недельку-другую. Засиделись в офисе? Поработайте стоя (в прямом смысле, не садитесь) или в кафе.
• Пикабу, Хабр, соцсети, ютубчик, сериальчики, игрушки — долой! Вот действительно, удалите эти приложения с телефона и на компьютере ограничьте к ним доступ в рабочее время. И спойлеров не увидите, и отвлекаться будете гораздо меньше. В целом снижайте количество отвлекающих от работы факторов до минимума.
• Напишите себе на день три задачки. Ровно три, которые вы точно выполните. Только постарайтесь без самообмана, выпить за день три чашки кофе может каждый. А вот три задачи по основному делу, которое вы всё время откладываете, пусть даже небольшие, сделать можно. Написать письмо, прочитать документацию и создать каркас будущего класса не очень сложно, но это даст старт чему-то большему. Справляетесь с тремя задачами в день? Ставьте обязательными уже пять.

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

Раз удовольствие простое и моментальное, а задачи сложные, вот мои способы борьбы с прокрастинацией:

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

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

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

Повысить концентрацию на первостепенных задачах поможет «Помодоро» — это техника тайм-менеджмента, которая предполагает деление тасков на 25-минутные периоды, которые называются «помидорками». Между ними есть маленькие и большие перерывы. Суть техники заключается в том, что в течение 25 минут вы стараетесь максимально сконцентрироваться и работать только над своей задачей, не отвлекаясь ни на что постороннее. После этого необходимо взять пятиминутный перерыв, расслабиться и максимально отвлечься. Можно использовать таймер, а для большей эффективности составить список рабочих задач, расставив их в порядке приоритетности от более важных к менее важным. Техника подразумевает 4 отрезка по 30 минут (25 работы + 5 отдыха), после которых следует взять долгий получасовой перерыв.

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

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

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

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

Кроме того, есть известная техника управления временем под названием метод помидора. Это работа в течение дня короткими «спринтами» с небольшими перерывами между ними. Суть её в том, чтобы определиться с задачей, поставить таймер на небольшой отрезок времени (обычно около получаса) — и ни на что другое не отвлекаться, пока таймер не сработает. Затем сделать небольшой перерыв, повторить. После четырех подходов нужен перерыв подольше. Это помогает концентрироваться на задачах, не отвлекаясь и не прокрастинируя. Техника названа так в честь таймера в виде помидора (pomodoro timer), которым пользовался её создатель.

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

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

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

Поэтому с прокрастинацией надо бороться, и я поделюсь собственными методами.

Первое и, наверно, самое главное — взять отпуск. Если на работе вы готовы делать что угодно, но не работу, пора отдохнуть. Съездите на природу, отправьтесь в путешествие, доделайте модель корабля, которую начали собирать ещё в школе. Занятия не должны быть связаны с работой.

Сложная ситуация, если отпуск только что закончился, а прокрастинация на месте. Попробуйте записывать, на что отвлекаетесь, и переносить эти дела на вечер. Например, «посмотрю ленту Фейсбука после 18:00», «интересная статья — прочитаю перед сном».

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

Помогает здесь метод помидора: разбиваете работу на временные отрезки по 25 минут и контролируете себя таймером. Даже если залипните на постороннее во время «рабочего отрезка», будильник отрезвит. И не стоит слепо следовать правилам «25 минут», можно взять любые временные интервалы. Основная цель — чтобы вы решали задачи и, даже если отвлеклись, могли быстро вернуться в рабочий процесс по будильнику.

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

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

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

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

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

Что делать? Признать, что микроотдых необходим. Устраивать перерывы не во время выполнения задачи, а по завершению работы над ней (или этапом работы, если проект большой).

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

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

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

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

Программисты — творческие люди примерно на 70 %, остальное это рутина (отладка, тесты, написание документации). По-моему, к лени приводит как раз рутина, она как песок, попадая на отлично работающие «шестерёнки» в мозгу, подтачивает и замедляет механизмы. Поэтому задача номер один для программиста – это избавиться от рутины или автоматизировать её.

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

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

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

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

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

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

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

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

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

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

Вторая техника, которая мне кажется удобной для борьбы с прокрастинацией, — Pomodoro. Её сутью является интенсивная работа в течение 25 минут, после чего берётся перерыв на пять минут. Каждые три-четыре «помидора» берётся перерыв 10–15 минут. В сочетании с чек-листом можно увидеть, сколько времени тратится на задачу, а благодаря отметкам — сколько раз возникало желание бросить работу до окончания отведенного срока. Самоконтроль — наше всё. Чтобы наиболее эффективно бороться с прокрастинацей, надо не только использовать различные техники, но и вести работу над собой. Надо выработать в себе привычку, что когда нам тяжело и трудно — это не всегда плохо, это лишь путь наверх, тот период, когда мы растём и совершенствуемся. Чтобы добиться чего-либо, стоит чаще осознано вводить себя в состоянии «некомфорта», держать в лёгком стрессе.

Прокрастинация — это не просто лень. Отличительной чертой прокрастинации является наличие у человека беспокойства относительно того, что дело не делается. Ленивый человек не беспокоится, прокрастинатор переживает.

Корень беспокойства лежит в перфекционизме и/или неуверенности в своих силах. Человек хочет сделать дело на отлично и с первого раза, но не уверен, что получится. Неуверенность вызывает беспокойство, порой неосознанное. Чтобы меньше беспокоиться, он заполняет время простыми задачами, которые можно сделать «идеально» с первого раза.

Образ мыслей, при котором человек считает, что настоящий профессионал — это тот, кто делает любую новую задачу с первого раза идеально, называется в литературе «fixed mindset» и является ошибочным. Мастерство же достигается практикой, и многие произведения искусства или инженерной мысли, являются результатом проб и ошибок. См., например, видео, как рисовал и сколько раз менял картину Пикассо, прежде чем получился известный шедевр.

Мои рекомендации как победить привычку прокрастинировать

Меняйте образ мыслей. Хорошие книги для старта — это «Талант ни причем» Джеффа Колвина и «Поток» Михая Чиксентмихайии.

Из практического:

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

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

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

Я лично использую Метод помидора с 25 минутными интервалами.

Для достижения лучшей концентрации на задаче используйте технику эмоционального контроля опытных переговорщиков. Закройте глаза, медленно вдохните и выдохните, сосредоточившись на том, как воздух входит и выходит из легких. Откройте глаза и по порядку мысленно опишите, (1) что вы видите перед собой, (2) что слышите, (3) какой запах чувствуете, (4) какой вкус ощущаете, (5) что тактильно находится под ладонями. Это занимает 30-60 секунд и позволяет прервать поток мыслей, перенестись в «здесь и сейчас». После чего переключайтесь на задачу.

Мне помогает техника Pomodoro: нужно отключить все устройства и приложения кроме тех, на которых работаешь, и в течение 30 минут (или другого удобного количества времени) заниматься только запланированными делами. Далее следует 5-минутный перерыв на отдых, после которого идёт очередной блок интенсивной работы. Этот метод действительно помогает сосредоточиться, но только в том случае, когда факторы, мешающие работе, внешние, а не внутренние, например шум в Open Space или непрекращающийся поток сообщений.

Однако, очень часто прокрастинация свидетельствует о том, что человек занимается не родным делом. Мы склонны откладывать то, что нам не хочется выполнять вообще. Полюбить не своё не получится, поэтому лучшая стратегия в данной ситуации — выявить то, что нравится, и заниматься этим. Я в таком случае пользуюсь методом мемуарника: на протяжении трёх месяцев записываю одно действие, которое мне больше всего понравилось за день. Так можно узнать задачи, которые по каким-то причинам не нравятся. Я, например, благодаря мемуарнику поняла, что не люблю писать диссертацию, и без сожалений отказалась от этой идеи, направив свои силы на получение MBA. Ещё одна причина, по которой человек может откладывать выполнение даже любимого дела, — отсутствие знаний. Те, кто плохо знает английский, долго не могут взяться за переводы, те, кто не уверен в своих навыках программирования на Java, не принимается за соответствующие задачи. В таком случае нужно идти повышать квалификацию, а не откладывать бесконечно задачи в страхе выполнить их плохо.

Прокрастинация как явление существует давно, а вот имя она обрела сравнительно недавно — всего-то лет 40 тому назад, а популярной и обсуждаемой стала и вовсе недавно — не более 10 лет назад.

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

Человек устроен таким образом, что активное движение к цели возможно, когда он уверен, что цель для него важна. Как известно, нет более целеустремленного человека, чем тот, кому срочно нужно в туалет.

Достигать цели человек готов только в том случае, если вероятность и значимость успеха для него существенна. Если речь идёт о производственной задаче, то вкладывать силы и время человек готов, только понимая, для чего. Это вопрос стимулирования. И просто зарплата таким стимулом является далеко не всегда. Куда важнее бывает получить зримые и незримые бонусы от результата своего труда, к примеру, увидеть своё имя в списке авторов продукта.

Ещё один важный момент — насколько безупречным планируется выполнение задачи? Есть ли у исполнителя право на ошибку? Или его внутренние или внешние стандарты недосягаемо высоки?

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

1. Если мучительно долго не получается приступить к работе, нужно проверить цель на актуальность. Действительно ли это нужно в таком виде, в такие сроки? Или возможны варианты? Вариативность — это свобода, это выбор и уменьшение напряжения, а значит — больше сил для дела.
2. Протестируйте цель на достижимость/реализуемость. К недостижимой задаче приступить очень тяжело.
3. При жёстких стандартах переживание неудачи может быть очень болезненным. Прокрастинация — это механизм избегания неудачи (иллюзорной или воображаемой), отсюда и парализация деятельности. Как её обойти? Сначала осознать и признать, что есть жёсткие стандарты и есть избегание, а дальше можно начинать торг. Например, изначально определить максимально возможное количество ошибок в коде и принять их как стандарт качества.
4. Немаловажным аспектом в случае прокрастинации является физическое состояние, уровень энергии. Иногда прокрастинация — это защитный сигнал организма, что надо отдохнуть, перевести дух, может даже сдать анализы или просто больше спать. В общем, это просьба организма о помощи. Не пропустите!

Творческий человек — натура сложная и многогранная. Порой фокус внимания смещается, и вернуть себя обратно в продуктивное русло крайне сложно.

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

Но есть эффективный способ — метод «Счастливое планирование».

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

«Ну нет, давай не сегодня. Это же не срочно», — говорит нам мозг, и вопрос откладывается на неопределённый срок.

Попробуйте иначе. Напишите список из 5 действий, связанных с предстоящей работой. Но эти действия обязательно должны отвечать трём критериям:

1. Скорость.
2. Простота.
3. Удовольствие.

Подключайте творческое мышление — что можно сделать быстро, просто и с удовольствием в контексте вашей задачи?

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

Придумали? Запишите и cделайте. Сделали несколько? Придумайте новые.

Таким образом, в вашем списке всегда будет 5 простых, быстрых и классных задач, которые предстоит реализовать.
Какое-то дело зависло надолго и не делается? Смело вычёркивайте — очевидно, что оно не попадает под необходимые критерии.

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

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

Используя этот метод, мы не заставляем себя работать. Мы переводим нерешённые вопросы в плоскость игры — задачи решаются легко, быстро и с удовольствием.

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

Почему так происходит? Потому что эта мотивация наиболее понятна для большинства. Потому что стремление к идеалу — вторично, а материальные потребности — первичны. Главное — найти свой «двигатель».

Итак, выбираем способ мотивации.

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

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

Лучше всего мотивирует страх? Представьте самые ужасные последствия срыва дедлайна. Не бойтесь преувеличить — чем сильнее испугаетесь, тем лучше мотивация. Расскажите о своих проектах. Отступать будет стыдно и страшно. Результат — выполненная работа.

Есть и общие рекомендации, которые тоже помогают соблюсти сроки:

• Старайтесь разнообразить работу. Чередуйте задачи. Меняйте способы выполнения, чтобы было интересно.
• Отмечайте прогресс. Нарисуйте себе шкалу прогресса и регулярно отмечайте на ней текущее положение дел. Будет повод себя похвалить.
• Хвалите себя или делайте себе маленькие подарки. В идеале работает как «не ем шоколадку, пока не сделаю».
• Если что-то всё-таки не удалось, это не причина признавать поражение. У всех есть право на ошибку, главное — продолжать движение к цели.

Итак, как бороться с прокрастинацией?

• Попробуйте сменить рабочее окружение и/или текущие задачи.
• Ограничьте доступ к отвлекающим факторам вроде мессенджеров или развлекательных ресурсов.
• Регулярно составляйте список из нескольких небольших задач, которые вы точно в состоянии выполнить.
• Попробуйте использовать метод «помидора».
• Боритесь с прокрастинацей её же средствами — откладывайте ненужные дела на потом.
• Возможно, стоит взять отпуск и отдохнуть.
• Если вы всё время откладываете какое-то занятие, то, возможно, это повод задуматься о смене работы или рода деятельности.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

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

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

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

Для того, чтобы стать программистом, с моей точки зрения есть два важных этапа: первый из них — научиться программировать, освоить так называемые hard-skills. Для этого есть множество офлайн-курсов, направленных на получение первых проектов в своё портфолио. Также имеется огромнейший пласт онлайн-образования в данной сфере. Сейчас также набирает популярность методика обучения, пришедшая к нам из Америки — буткэмп. В отличие от других она направлена на интенсивное освоение знаний. Буквально за 2,5 месяца такие школы выпускают студентов уже с первыми проектами в портфолио, готовыми перейти ко второму этапу — научиться проходить собеседования. Это отдельное умение правильно самопрезентовать себя, научиться демонстрировать свои профессиональные навыки. Для того, чтобы освоить это, можно воспользоваться множеством ресурсов, представленных в интернете:

• Pramp — сервис для того, чтобы отработать живые интервью. Вы звоните, вас активно интервьюируют;
• Набор сервисов, которые предназначены для отработки решений задач с алгоритмами: Codewars, LeetCode, HackerRank, Coderbyte.

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

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

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

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

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

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

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

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

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

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

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

Как минимум — не останавливаться на достигнутом и продолжить саморазвитие. Это снова могут быть курсы, либо книги и интернет-ресурсы. Заведите открытый репозиторий (например GitHub или Bitbucket), и заполняйте его написанными вами программками.

Огромным плюсом для вас будет написанный вами (не на конструкторе сайтов) и развёрнутый на бесплатном хостинге сайт. Например, можно написать простой сайт, который показывает спортивные новости, используя любой бесплатный API, и красиво его оформить, используя фреймворк типа Bootstrap.

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

Лучше начать с конца: определитесь, вы себя готовите к работе по найму или на фрилансе? Набор технологий и востребованность инструментов на этих двух путях разная. Если найм обычно подразумевает хорошее знание ограниченного стека технологий, то на фрилансе больше востребовано быстрое решение задач в самых разных технологиях, для большинства из которых хватит прочтения нескольких статей и изучения примеров кода на StackOverflow.

Даже на позицию джуниора после обычных курсов вас скорее всего не возьмут. И дело даже не в наличии портфолио, а в вашем неглубоком знании технологий и опыте закрытия задач. Я бы посоветовал посмотреть несколько десятков вакансий в вашей сфере и составить список требований. По факту это ваш roadmap, то, чему вы должны научиться на практике за 1–4 месяца, чтобы успешно устроиться на работу. Нужно шаг за шагом выделять на каждую технологию 2–4 недели, читая всё, что есть в интернете, и пробовать её применить.

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

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

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

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

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

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

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

Во-вторых, набрать портфолио можно на биржах фриланса. Наиболее популярные биржи для входа в профессию — это FL, Weblancer, Фрилансим. Главное помнить, что нет плохой или неподходящей работы, если нужно набрать портфолио. Любой зафиксированный опыт ценится больше, чем рассказы о полученном где-то там образовании. При работе на биржах главное — не ждать, что заказы сами начнут падать, и проявлять инициативу, а также пользоваться официальными сервисами для проведения платежей — ведь даже за маленькую нехитрую работу хочется получить оплату.

После прохождения курсов можно попробовать устроиться стажёром в одну из компаний или хотя бы пройти несколько собеседований для опыта. Само прохождение собеседований является хорошей практикой для того, чтобы понять, что ожидает работодатель от начинающего специалиста, и проработать пробелы в знаниях. К сожалению, очень часто стажировка не оплачивается, но плюсы её в том, что в дальнейшем компания может взять такого специалиста на позицию джуниора, либо, отработав бесплатно 2–3 месяца и получив реальный опыт, можно делать попытки получить оплачиваемую должность в других компаниях. Как правило, стажировка не длится более 6 месяцев.

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

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

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

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

1. Упомяните в портфолио свои курсовые, дипломные или магистерские работы, особенно если в них есть новизна, интересные системотехнические решения, свежие алгоритмы, актуальная проблематика.
2. Включите pet projects, которые вы делаете для себя в свободное время. Покажите, как в них используются стек и архитектура, близкие к реальным. Код на GitHub, статистика использования, рабочий прототип и тому подобное подойдут в качестве контента.
3. Если вы активный участник командных open source проектов, инди-игр, стартапов — не забудьте про них. Будущий работодатель оценит ваше умение работать в команде, понимать чужой код, культуру написания кода. Чем популярнее и крупнее продукт, тем лучше.
4. Фриланс. Если в результате подработки появился завершённый продукт, который приносит пользу заказчикам и сам по себе интересен — включайте его в портфолио. Это демонстрирует, помимо прочего, самостоятельность и умение общаться с заказчиками.
5. Работа на реальных проектах. Передовые крупные компании охотно берут начинающих программистов на стажировку и дают шанс попробовать себя в «боевой» разработке под контролем наставников. Для вас такой опыт — одна из весомых строчек в портфолио. Опишите конкретную функциональность продукта, реализованную вами.

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

В том, что делать сразу после обучения, никакой особенной стратегии нет, почти все программисты после обучения находят работу, участвуют в проектах, совершенствуют технический бэкграунд, набираются опыта. Ключ к действительно хорошей карьере лежит в нетехнических навыках. Важно развивать проактивность, внимательность к требованиям, дипломатичность, пиетет к своей репутации. Поэтому мой совет звучит так: занимайтесь спортом, проводите больше времени с близкими, высыпайтесь, хорошо питайтесь, читайте интересные книги. Чего уж точно я бы не стал советовать, так это: «Выучите <technology name>, <development approach name> и <programming language name>».

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

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

Самое главное — практиковаться. Никому (в том числе и вам самому) не нужны теоретические знания, важны навыки.

Если нет реальных задач, на которых можно практиковаться — можно взять несколько самых известных самоучителей в выбранной вами сфере (для 1С это, например, книги Радченко и Хрусталёвой), пройти их и выполнить все практические занятия.

Закрепили знания о синтаксисе и применимости базовых механизмов языка? Рассмотрите основные фреймворки на нём (для 1С — библиотека стандартных подсистем, БСП). Умение не изобретать велосипед, а брать за основу уже работающие решения добавит вам очков в сравнении с другими начинающими специалистами.

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

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

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

Итак, что делать после прохождения курсов?

1. Не переставайте развиваться и набирать опыт — читайте книги, проходите курсы (да, ещё одни), решайте задачи из интернета, пишите свои проекты, учитесь обрабатывать ошибки и фиксируйте всё это, чтобы было потом что показать работодателю.
2. Составьте хорошее резюме или сопроводительное письмо, из которого работодатель сможет узнать о ваших интересах и опыте. Включите в него свои самые сложные и интересные проекты, опишите ваши интересы и направление, в котором хотите развиваться. И не забудьте проверить резюме на наличие ошибок.
3. Найдите стажировку в какой-нибудь компании. Не факт, что она будет оплачиваемой, зато в случае её успешного прохождения вас вполне могут трудоустроить. Альтернативой стажировке могут быть какие-нибудь курсы от компаний, которые проводятся для обучения программистов нужным компании технологиям.
4. Проходите собеседования, чтобы набраться опыта в этом деле и научиться правильно презентовать себя. Также можно прийти на мероприятие вроде митапа, где часто бывают представители компании, чтобы лично пообщаться с ними и создать хорошее впечатление.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Есть два варианта:

Случайный: вас позвал на работу ваш друг/знакомый, поскольку он знает, что вы раньше умели настраивать модем, сканер, принтер, устанавливать Windows и, возможно, сможете установить 1С и написать пару обработок/отчётов. Потом добавить новость и чуть позже новый раздел на сайт, написанный на PHP/MySql — и вот вы в деле.

И осознанный: когда вы твёрдо решили вновь стать, например, разработчиком. В этом случае вам, прежде всего, необходимо понять, какие специалисты востребованы на рынке труда в области разработки ПО на данный момент (поскольку на Clipper и Delfi, которыми вы в своё время хорошо владели, уже почти никто ничего не пишет).

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

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

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

На мой взгляд, бояться тут абсолютно нечего. Главное — соединить целеустремлённость с терпением, и всё обязательно получится. Сам же процесс восстановления квалификации может отличаться в зависимости от длительности и формы перерыва:

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

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

1. Анализ количества открытых вакансий на ресурсах по поиску персонала (например, HeadHunter, SuperJob и др.).
2. Анализ динамики запросов в поисковых системах (например, Яндекс Wordstat).

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

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

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

1. Geekbrains — российский ресурс с бесплатными IT-курсами.
2. Udemy — международный ресурс с большим количеством курсов и самые разные IT-темы (и не только IT). Тут часто проходят распродажи и все курсы продают по 10 долларов.
3. Многие производители ПО сами делают качественные бесплатные курсы по своим технологиям. Вот, например, ресурс для обучения технологиям Microsoft. Тут много курсов разного уровня по самым разным решениям с возможностью выполнения практических заданий на виртуальных машинах, которые запускаются прямо в браузере.

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

Вот несколько шагов, которые могут помочь вам вернуться в отрасль:

1. Установите внутренние ориентиры. Сформулируйте (лучше на бумаге):

• Чего вы хотите добиться, вернувшись в IT?
• Какой характер работы вас интересует?
• Какие ограничения и цели по заработной плате на первом шаге?
• Чего хотите добиться через год, два, три по части карьеры?
• Сколько времени и денег готовы вложить в свой «возврат»?

2. Обновите информацию по вашей специализации и отрасли в целом. Помогут новостные и тематические сайты, блоги (Tproger, ProgLib, Habr, Reddit, Hacker News, Medium), Telegram-каналы, сайты с вакансиями, аналитика рынка труда и соответствия вакансий вашим внутренним ориентирам, а также бизнес-новости индустрии (TechCrunch, The Verge, CNews).

3. Найдите профессиональное комьюнити в онлайне и в оффлайне по интересным вам направлениям. Сходите на митапы, узнайте о сложностях, получите рекомендации. Помните про soft skills. Сегодня сложно добиться успеха в ИТ сугубо техническими навыками, а живое общение — главный инструмент развития личных качеств.

4. Определитесь со специализацией и составьте программу обучения по своему бюджету, времени и дисциплине. Выбор есть — от очных и удалённых курсов до бесплатных или недорогих (Coursera, FreeCodeCamp, Udemy, Udacity и др.). Набирают популярность result-driven программы — такие как Lambda School, и новые форматы IT-образования — 42 School и Школа 21.

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

И, конечно, помните известную цитату: «Если боишься — не делай. Но если делаешь, то уже ничего не бойся».

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

Для остальных людей можно порекомендовать:

1. Бесплатные и платные курсы в интернете (они дают базовые знания).
2. Курсы от вузов (более дорогие, долгие, но дают более глубокие знания).
3. Самостоятельное изучение: чтение документации и технической литературы.
4. Найдите компании, которые занимаются интересующими вас технологиями и попроситесь на бесплатную стажировку.
5. Найдите форум со специалистами. IT-шники любят блеснуть знаниями и многие с радостью вам помогут.

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

Решила пойти учиться в магистратуру. Быстро подготовилась к вступительным экзаменам и поступила! Очень повезло, что мой ребенок был спокойным и общительным, легко переносил отсутствие мамы, оставаясь с папой, бабушками и дедушками. Родные меня поддерживали, не отказывали в помощи и нянчились с малышом, когда я убегала на пары. Два года учёбы пролетели, как один день, сын пошёл в садик, а полученные свежие знания с красным дипломом в комплекте стали новой отправной точкой.

Вышло так, что я не возвращалась в мир IT, а оставалась в нём. Конечно, на работе пришлось многое вспомнить и узнать. Здесь большую роль сыграл наш дружный коллектив. Ребята помогали, охотно делились своими знаниями, подсказывали нужные книги, интересные Интернет-ресурсы. Благодаря ощутимой поддержке коллег было легко влиться в работу.

Девушкам, которым длительный отпуск только предстоит, хочу дать один совет: старайтесь найти баланс между заботами о малыше и семье и своими личными профессиональными интересами. Чтобы легко вернуться на работу, лучше не уходить с головой в пучину новых материнских обязанностей, а находить ежедневно хотя бы небольшой кусочек свободного времени для себя и продолжать развиваться. Поддерживайте связь с коллегами, узнавайте от них новости, будьте в курсе того, что происходит на работе, и приходите иногда «в гости» в ваш офис. Так вы останетесь в потоке, и вернуться в стремительно меняющийся мир IT будет гораздо проще.

На самом деле все намного проще и легче, чем кажется. Главное, что есть у разработчика, базис его карьеры — это опыт, навыки и системный подход. Они долго не устаревают и не исчезают в никуда со временем. Важно помнить, что модные технологии и инструменты — это всего лишь надстройка, которую обычно несложно заменить. Чтобы актуализировать свои знания, можно пойти по самому простому пути: от тестовых заданий на вакансии в интересующей разработчика сфере. Многие компании либо публикуют их на своих сайтах, либо высылают по запросу. Стоит откликнуться на несколько вакансий и написать несколько писем, чтобы понять, что и в каком объёме от вас хотят на сегодняшний день.

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

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

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

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

3. Теперь идём на крупные порталы, такие как, например, habr. Ищем раздел с самыми популярными статьями, выбираем период, скажем, в полгода. Скорее всего, вы найдете там много интересного.

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

5. Как правило, практическое применение новых технологий вызывает много вопросов, в том числе и у опытных коллег. Можно воспользоваться сайтом stackoverflow и изучить новые популярные вопросы.

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

В 2011 году я ушёл из разработки С++ в управление IT-проектами, а потом на должность удалённого Sales Manager в московскую компанию. Несмотря на то, что моя работа так или иначе была связана с IT — в последнем случае это продажа IT-решений — я перестал быть программистом, и, признаться, меня это немного расстраивало. Шло время, и пропасть между мной и практикующими разработчиками росла. Технологии постоянно меняются, и даже когда я делал какие-то проекты для себя, осознавал, что тех навыков, которые у меня были на тот момент, не вполне достаточно, что они не до конца применимы в современных реалиях.

Когда я пришёл в GeekBrains (сначала преподавателем курса GNU/Linux, затем — руководителем образовательных проектов), после долгого перерыва вновь погрузился в атмосферу разработки. Я общаюсь с преподавателями и разработчиками, помогаю студентам выстраивать инфраструктуру, проектировать взаимодействие между приложениями на разных языках, при этом и сам постоянно узнаю что-то новое на уровне технологий.

Я понял, что накопленный опыт, системное мышление, общая компьютерная грамотность — это то, что не устаревает. К примеру, UNIX-подобные системы, используемые в облачных решениях, на 60 % остаются такими же, как и в 1970 годах, когда только появились, настолько хороша и удачна оказалась архитектура. Для того чтобы раскрыть эти знания, нужно вернуться в сферу разработки, почувствовать свою востребованность.

Безусловно, устройство по желаемому профилю в IT требует наличия новых навыков. Нужно подтянуть те знания, которые отсутствовали изначально, или заполнить пробелы, которые накопились за счёт прогресса языков и технологий. Тут я вижу два пути: либо самостоятельно учиться по учебникам и интернет-ресурсам (Coursera, Stepik), либо пройти наши образовательные программы.

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

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

Иногда люди кардинально меняют профессию и уходят из IT. Причины бывают разные: то ли потому, что не очень получалось, то ли потому, что показалось, что «там» будет ещё лучше. Но IT-сфера коварна и имеет свойство притягивать к себе многих из тех, кто расстался с ней, думая, что навсегда. И многие и рады бы вернуться, но страшно, потому что отрасль высоких технологий очень динамична. Что тут сказать…

Прежде всего могу обрадовать менеджеров и представителей большинства других IT-специальностей (по большому счёту всех, кроме программистов, системных дизайнеров и архитекторов). Их сегмент развивается достаточно умеренными темпами, значимые новинки (те, что затрагивают большинство представителей специальности и тем более меняют наше представление о ней) появляются даже не каждый год. Так что можно смело выставлять своё резюме на сайты по поиску работы, указывая в качестве цели свою прежнюю профессию — ну, разве что приставку «старший» убрав для подстраховки и придумав красивую и убедительную для рекрутеров и будущего начальства причину «измены» IT. Хотя и простое желание попробовать себя в другом бизнесе вполне может «прокатить» — ясно, что теперь-то человек точно будет достаточно стабильно работать IT-шником.

С программистами (и «вышестоящими» специалистами) всё сложнее. Полгода-год — вообще не вопрос, даже в этом сегменте всё не настолько быстро меняется. Хуже, когда это 2–3 года или даже больше. В этой ситуации многое из знаний и опыта уже может устареть. Но не в наших привычках опускать руки, верно?

Путь № 1: найти компанию, использующую известные вам технологии и инструменты. Поверьте, их не так уж мало, особенно в аутсорсинге, где решения по этим вопросам принимает заказчик, а многие из них весьма и весьма консервативны. Двое заказчиков моих знакомых до сих используют Cobol (кто-то ещё помнит — не то, что знает — этот язык программирования? ? ), а один — Turbo Pascal, и ничего — живут себе вполне нормально. Так что ищите и, вполне возможно, найдёте.

Если же нет — подумайте, как можно восстановить свою квалификацию на новом витке развития IT. Начнём с книг. Благо, сейчас не середина 80-х, когда не книги даже, а еле читаемые ксерокопии книг по программированию были на вес золота. Прочтите минимум одну, лучше две из «топа» списка наиболее уважаемых публикаций. Приправим всё это десятком-другим статей на авторитетных ресурсах (желательно англоязычных). Добавим пару отраслевых конференций типа РИТ++. Ну, и завершим приготовление «коктейля» парой толковых тренингов от признанных лидеров рынка. И всё у вас получится!

Итак, как вернуться в IT?

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

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

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

За 2018 год мы взяли в команду десять студентов и выпускников, провели две практики и два курса семинаров по бэкенд и фронтенд разработке. В 2019 году придут ещё двенадцать практикантов. Рекомендации в этой статье — это наш опыт и критерии, по которым мы отбираем ребят в команду.

Определитесь с направлением

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

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

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

Изучайте технологии и прокачивайте навыки самостоятельно.

В вузе преподают на Windows, хотя её век ушёл, SQL всё ещё из 1999, а на дворе 2019. Догонять разницу всегда придётся самому. Ниже несколько актуальных технологий:

• Подходы к разработке: экстремальное программирование, система непрерывной интеграции CI и система контроля версия Git.
• Языки программирования, фреймворки и библиотеки: С ++, Python, JavaScript, TypeScript, Angular, React и др.
• Технологии: LXD, Docker-контейнеры, кластеры Amazon и Google Cloud, мониторинг Docker Swarm.
• Навыки тестирования: ручное, автоматизированное, нагрузочное, приёмочное, AB, SHADOW, TDD и т. д.
• Прочее: работа в команде, оценка и декомпозиция задач, методы управления проектами Scrum и Kanban, KPI.

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

Как учиться самому? Когда в вуз приходят преподавать разработчики из IT-компаний, не пропускайте. У каждого инструмента есть мануалы и документация, гуглите. В свободном доступе можно найти записи полноценных курсов, например, Технопарка Mail.ru Group и МГТУ им. Баумана. Если есть возможность платить за обучение, загляните на Coursera, Академию Яндекса и Geekbrains. Учитесь даже тогда, когда едете в автобусе. В приложении Sololearn, например, вы найдёте краткие курсы почти по любому языку программирования с тестированием, практикой, сертификатами и даже ачивками.

Если есть вопросы и сомнения, всегда можно попросить совета у старших товарищей.

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

Делайте проекты

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

Где брать проекты? Лабораторные или курсовые работы — отличное поле для практики. Помимо этого, делайте сайты или разрабатывайте приложения для друзей и знакомых, а если никто не просит — фантазируйте. Пишите компьютерные игры, это и увлекательно, и полезно, так можно попробовать себя в сложных дисциплинах: разработке физических движков или работе с 3D-графикой. Собирайте команду на хакатоны или проходите курсы, результаты которых можно добавить в портфолио. Например, в Хекслет вы можете выбрать специализацию и за полгода обучения получить четыре реальных проекта.

На старте кода в стиле «работает, и ладно!» не достаточно, вникайте в особенности, ищите примеры на GitHub, GitLab или Medium. Изобретайте «велосипеды», так вы быстрее разберётесь в предметной области. В каждом проекте, изучая новую технологию, бросайте себе вызов. Не стоит стесняться тренировать инструменты, которые в спецификациях значатся «под разработкой» или «экспериментальное».

И только когда будете быстро делать проекты, почти не обращаясь к Google, Toster и StackOverflow, — можно пытаться зарабатывать. Идите на биржи фриланса и в агентства города.

Помните: пока вы спите и отсиживаетесь на парах, кто-то кодит и прокачивает портфолио.

Учите английский язык

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

Как учить? Здорово, если в вузе хорошо преподают английский и у вас не осталось проблем со школьных времён. Если нет, можно пойти на курсы или заниматься с преподавателем по скайпу, читать книги, статьи и документацию ко всем технологиям только в оригинале. Сначала придётся проверять в словаре каждое слово, но постепенно это пройдёт. И самая приятная часть — играйте на ПК и консолях без перевода и смотрите видео в оригинале. Это даст результат! В идеале нужно подтянуть уровень до В2 (средне-продвинутый) или С1 (продвинутый) и подтвердить это сертификатом.

Помните: без английского в IT совсем никуда. Хорошая новость — многим технический английский даётся легче, чем разговорный или деловой.

Прокачивайте soft skills

Сейчас в IT принято делить навыки на «жёсткие» (hard) и «гибкие» (soft). Первые — это профессиональные умения для решения технических задач: владение C++, Java, JavaScript, например. Ко вторым относят коммуникации, целеполагание, стресс-менеджмент, лидерство.

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

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

Станьте частью профессионального сообщества

Оставаться всегда «на волне» вам помогут новости из мира IT, статьи и переводы обо всём, что связано с разработкой. Их можно найти у Tproger и на Хабре, читайте регулярно. Подписывайтесь на сообщества IT-компаний, чтобы получать полезные материалы, информацию о стажировках и приглашения на мероприятия. Не ограничивайтесь местными компаниями и помните, что сейчас IT-специалисты нужны не только разработчикам, но и банкам, и мобильным операторам и т. д. Они ездят по стране с хакатонами в поисках талантов. Локальные сообщества — ещё один источник знаний и связей.

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

Общайтесь с работодателями

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

Создайте резюме на HeadHunter с тегом «Начало карьеры», тогда вам будут приходить подборки вакансий для начинающих специалистов. Из них как минимум можно понять, чего именно ждут работодатели. Откликайтесь и ходите на собеседования. Просите тестовое задание и отнеситесь к нему серьёзно, это ценный опыт. Если не получилось с первого раза, попросите дать вам обратную связь о плюсах и минусах решения, чтобы сделать выводы и прокачать слабые стороны. Кроме того, что вас запомнят, вы получите опыт прохождения собеседований и в будущем не будете волноваться.

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

Помните: присматриваться к работодателям и вакансиям нужно с первых курсов. Ваша работа на период учёбы — подготовить себя к требованиям рынка.

Будьте честными

Да, вначале кажется, что опыта недостаточно. Это нормально! Указывайте в резюме те навыки, которыми действительно владеете, и те технологии, с которыми работали, и на каком уровне с ними знакомы. На собеседовании обязательно об этом спросят, и преувеличить не получится. Лучше честно сказать, с чем не сталкивались и о чём не знаете.

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

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

• С фронтендом выбор очевиден. Здесь «рулит» JavaScript. Для этого языка создано множество мощных фреймворков. Также для разработки интерфейсов обязательно понадобится знание HTML и CSS.
• В бэкенде по-прежнему актуален C++, хоть некоторые и торопятся списать его со счетов. Также в топе здесь Java и C#. Обратите внимание и на перспективные Kotlin, Golang и Python.
• В области мобильной разработки всё зависит от платформы. Если IOS, то Swift, а если Android, то, в основном, Java. Развиваются и новые направления по созданию приложений с применением веб-технологий: HTML и JavaScript + CSS.
• Наконец, если планируете работать с базами данных, то обязательно нужно изучать SQL.

Создайте хорошую основу

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

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

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

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

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

Следите за лидерами рейтингов

Популярные языки – те, что на слуху. Даже люди, далёкие от программирования, наверняка слышали о Java, C++ и Python. Топовые ЯП периодически меняются местами в двадцатке, но состав их стабилен и отражает реальную картину. Выбрать себе язык из этого списка — неплохая идея.

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

Индекс PYPL более показательный. Чтобы попасть в зачёт, запрос должен содержать помимо имени ЯП слова «tutorial», «documentation» и т. п. Но и здесь есть минусы: программисты с хорошим знанием языка редко гуглят документацию.

Точно не стоит браться за технологии, которые умирают. Visual Basic, Delphi, Паскаль — это уже история, карьеру на них не построишь. Даже если пока ещё довольно легко можно найти работу со знанием Objective-C, скоро Swift вытеснит его. Поэтому если хотите создавать современные приложения, выбирайте современный ЯП.

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

Изучайте предложения на рынке

Лучший способ понять, знание каких ЯП сегодня приветствуется, — посмотреть сайты вакансий. Там же можно узнать и «вилку» предполагаемой зарплаты. HH даже ведёт блог на эту тему, ежегодно публикуя статистику.

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

Владение редкими ЯП, например Clojure, Erlang, Scala, зачастую оплачивается выше, но и работу с ними найти сложнее. Поэтому советую осваивать их как дополнительный скилл. К тому же при изучении популярного языка можно обратиться за помощью и разъяснениями к сообществу. С новыми ЯП эта функция работает хуже.

«Любимчик» российского рынка и лидер по числу вакансий по-прежнему 1С. Оклад у junior-разработчика с ним, возможно, будет выше, чем с теми же Java и С#, но при этом потолок — ниже. Так что не гонитесь за цифрами c самого начала. Думайте о перспективах и росте.

Посмотрите, какие специалисты требуются в компании, где вы хотели бы работать. Если это enterprise-разработка и банковский сектор, то в топе наверняка будет Java. Гиганты вроде Mail.Ru Group, «Лаборатория Касперского» и «Яндекс» предпочитают C++.

Планируете заниматься НИОКР и нейросетями, ваш язык — Python, мечтаете попасть в Microsoft — С#.

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

Получайте удовольствие

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

В итоге занял лишь 51-ое место и не получил даже футболки. Однако наспех полученных навыков хватило, чтобы заслать стратегию и посоревноваться. Кстати, всего там было 200 игроков, так что моё выступление не было полным провалом.

Выводы я сделал: Python мне не по душе, а не оказаться в числе замыкающих мне помог опыт в программировании на других языках. Это было, как минимум, весело!

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

Поверьте: писать на том, что нравится, гораздо приятнее, да и получается лучше. За этим подтянется и финансовое благополучие. Если, возвращаясь домой из офиса, вы пишете программы «для себя», значит, профессию выбрали правильно.

Начинающим предпринимателям кажется, что самое сложное — запуск стартапа. На самом деле, основные трудности связаны с ростом. Только одна компания из девяти выходит на устойчивый рост и становится прибыльной, подсчитали аналитики из Bain & Co. 85 % руководителей компаний-неудачников признают, что причиной кризиса были не действия конкурентов, а внутренние проблемы.

Сценарии кризиса

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

Стагнации подвержены как молодые стартапы, так и устоявшиеся компании. В какой-то момент руководители теряют связь с реальностью, перестают чувствовать рынок, после чего компания уже не может оправдать доверие клиентов. Когда с таким кризисом столкнулась Cisco, компания сократила время разработки продуктов и вывела на рынок новые решения в области виртуализации, что позволило ей ответить на вызовы со стороны Amazon, Huawei и других конкурентов. Netflix, занимавшийся когда-то рассылкой DVD по подписке, успел пересмотреть стратегию, сосредоточившись на стриминговом сервисе и создании собственного контента — в результате его доход приблизился к $16 млрд.

Еще один сценарий кризиса, падение, может быть обусловлен как внутренними (например пересмотр бизнес-модели или вывод на рынок нового продукта), так и внешними причинами (например появление сильного конкурента или революционной технологии). Классический пример выхода из падения — возвращение в Apple Стива Джобса, который возродил в забуксовавшей компании дух стартапа, сократил перегруженную продуктовую линейку и вывел новые продукты. Обратный пример — Nokia, которая потеряла лидерство на рынке из-за неспособности развиваться и реагировать на действия конкурентов.

Сохранить дух стартапа

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

Чтобы преодолеть кризис роста, основателю (или команде фаундеров) прежде всего нужно заметить эти симптомы и найти способ их преодолеть. Хорошо, если основатели смогут расти вместе со своим стартапом, но чаще они начинают тормозить его развитие, отказываясь адаптироваться к меняющимся условиям. Среди компаний, которые преодолели кризисы роста, сохранив при этом дух стартапов и ментальность своих основателей, — Google, IKEA и AB InBev. К примеру, пивоваренная корпорация AB InBev не тратит деньги на шикарные офисы и предпочитает нанимать молодых сотрудников.

Найти ментора

Эффективный способ справиться с кризисом роста — расширить управленческую команду, пригласив опытного менеджера, который будет не просто отрабатывать зарплату, а искренне «болеть» новым бизнесом. Бурный рост российского образовательного стартапа SkyEng начался после того, как к команде присоединился Александр Ларьяновский с опытом работы в Яндексе и других крупных компаниях.

Привлечь инвестиции

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

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

Кризис как путь в будущее

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

1. открыть календарь;
2. увидеть количество встреч и совещаний на день;
3. захотеть тихонечко заползти под стол и укрыться пледом, чтобы все отстали.

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

Есть такой специалист — Джозеф Аллен, директор Центра эффективности собраний в университете Небраски. Вместе с группой исследователей он изучил почти 200 научных исследований о совещаниях. Оказалось, что сотрудники проводят на собраниях в среднем 6 часов в неделю, менеджеры  — в среднем 23 часа. При этом многие жалуются на совещания, но никто не собирается исключать их из рабочего процесса.

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

Перед совещанием

1. Убедитесь, что есть чёткая цель, для достижения которой действительно нужно собрать сотрудников вместе.
2. Заранее объявите тему и лидера встречи, чтобы люди могли подготовиться к обсуждению, записать подходящие вопросы. Список приглашённых также имеет значение.
3. Составьте план с приоритетными задачами и разошлите его всем участникам не менее чем за 24 часа до встречи. Лучше максимально упорядочить план и указать рядом с каждым пунктом время, отводящееся на его обсуждение. Также полезно указывать имена сотрудников, которые ответственны за задачи в этих пунктах.
4. Постарайтесь заложить на всё совещание не более 52 минут – это оптимальное время для продуктивной работы без перерыва.
5. Если вы устраиваете собрание и слишком заняты для того, чтобы всё обстоятельно подготовить, лучше делегируйте эту задачу кому-то, у кого есть на это время. Вообще периодически меняйте руководителя собрания, чтобы встречи не становились однообразными. Если в вашей команде несколько равных по должности участников, попробуйте чередовать обязанности.

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

Во время собрания

1. Начните вовремя. Может показаться, что двухминутная задержка не будет большой проблемой, но это может разозлить участников и встреча пройдёт менее плодотворно.%save-sc1%
2. Как только начнёте, попросите людей убрать гаджеты, чтобы никто не отвлекался. Так сотрудники смогут следить за беседой и участвовать в обсуждении.
3. Дайте коллегам возможность свободно делиться идеями: поддерживайте обсуждение, но не опрашивайте всех как по журналу. Это создаёт безопасную доверительную среду.
4. Не превращайте собрание в место для жалоб. Прежде чем говорить, каждый должен подумать, ценно ли то, что он собирается сказать. Здесь пригодится план и подготовленные комментарии.
5. Научитесь определять, когда нужно заканчивать встречу. Это приходит с опытом. Если вы прошлись по всему плану, не стесняйтесь заканчивать раньше времени.%save-sc2%
6. Подведите итоги в конце собрания. Так люди выйдут со встречи, зная, чем им предстоит заняться и с кем это можно обсудить. Определите, достигли ли вы цели сегодняшней встречи.

После совещания

1. Не устраивайте сразу новое совещание, чтобы обсудить решения, принятые на предыдущем. Разорвите этот порочный круг! Проведите одно совещание, а после следите за прогрессом в работе. Можно добавить актуальные задачи на общую доску в инструментах вроде Trello, Asana или Basecamp; это особенно полезно, если команда удалённая. Руководители встречи могут добавить напоминания и дедлайны в общий календарь команды.
2. Соберите фидбек от команды, это поможет улучшить эффективность следующих совещаний. Это очень просто, хотя руководители часто упускают это из виду или избегают.%save-sc3%

Итак, что нужно учесть при организации совещания:

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

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

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

Идея (1 день)

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

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

Дизайн (2 дня)

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

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

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

Я знал, что в конечном продукте мне нужны:

1. Редактор для настройки стилей, который обновит пользовательский интерфейс.
2. Карусель со свежими примерами.
3. Место для экспорта кода путём копирования в буфер обмена.

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

Разработка (7 дней)

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

Я начал процесс разработки в Gatsby, потому что:

• я мог построить интерфейс используя React;
• легко преобразовать сайта в PWA добавив пару строк в файл конфигурации (смотрите этот твит);
• проще простого выложить на хостинг с развёртыванием только статических файлов;
• я избежал рутинной работы с шаблонами;
• Gatsby просто чертовски крут.

Я начал с gatsby-default-starter и без проблем собрал большую часть функциональности. Я использовал сторонние библиотеки, такие как react-color и react-slick, чтобы не создавать сложные слайдеры и компоненты цвета.

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

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

Я использовал GitHub-проект, чтобы отслеживать некоторые мелочи с более низким приоритетом, которые хотел сделать позже, и в конце концов предпринял некоторые меры, чтобы добавить в Gatsby plugins для Google Analytics некоторые метаданные и включить значки для браузеров, мобильных устройств, и конфигурации манифеста PWA.

Развёртывание (~45 минут)

…и запуск!

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

Пройти через все препятствия неопределенности было легко, так как я видел цель.

Я наконец понял, что могу посмотреть на свою тяжёлую работу и оценить действительно классную вещь, которую сделал:

Развёртывание было простым процессом. Я не хотел вкладывать деньги в домен для стороннего проекта, о котором мог забыть через год или два. Поэтому я воспользовался тем, что на Surge можно разместить сайт бесплатно. Своё приложение я назвал Card Surge, поэтому мне нужно было просто взять поддомен card, и получить бесплатный фирменный домен card.surge.sh. Я запустил gatsby build, а затем surge, и мой код был в сети и распределялся по CDN с поддержкой SSL.

Кроме того я слишком сильно люблю Netlify, чтобы не использовать его, поэтому я указал своему репозиторию GitHub на проект на Netlify, чтобы автоматически создавать любые запросы на получение или коммиты для Master (это пригодилось всего через пару часов после запуска, когда поступил первый pull-запрос).

Мой проект работал, и я не потратил ни цента.

Я сделал описание и несколько скриншотов и записей с использованием Kap и опубликовал Card Surge на Product Hunt.

Оглядываясь назад

Быстрая работа и стремление к дате завершения (которую я вырисовывал в календаре) были действительно полезны. Мне пришлось учитывать только важные проблемы, которые фактически мешали бы завершению и запуску к дате окончания.

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

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

Краткие выводы можно посмотреть в конце статьи.

Краткие выводы в конце статьи.

В то же время задачи, с которыми столкнутся люди в будущем, будут значительно отличаться от тех, что решает наше поколение. К тому времени, когда нынешние школьники закончат вузы, значительная часть полученных ими знаний уже будет неактуальна. Проведённое Оксфордским университетом исследование показало, что 47 % существующих в настоящее время профессий исчезнут в ближайшие 20 лет.

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

Понимание систем

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

Как указывает комплексный теоретик Сэм Арбесман (Sam Arbesman), у фактов есть период полураспада. По мере того как ускоряется накопление знаний, период полураспада уменьшается. Например, когда мы учились в школе компьютерному программированию, то, как правило, изучали BASIC — язык, который в настоящее время почти не используют. Сейчас самый популярный язык — Python, но совсем не факт, что он останется таковым спустя десятилетие.

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

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

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

Значение эмпатии и навыков проектирования интерфейсов

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

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

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

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

Способность обмениваться идеями

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

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

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

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

Взаимодействие и командная работа

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

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

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

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

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

Смотрите также: Важность самообразования в обучении разработчика

Особенности платформы:

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

Однако сначала несколько слов о самом проекте.

Проект Эйлер

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

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

Вот пример простой задачи, самой первой в списке:

Если выписать все натуральные числа меньше 10, кратные 3 или 5, то получим 3, 5, 6 и 9. Сумма этих чисел равна 23.Найдите сумму всех чисел меньше 1000, кратных 3 или 5.

А вот сложная задача, которую решило всего 157 участников:

Пусть G(a, b) — наименьшее неотрицательное целое число n, для которого НОД(n3 + b, (n + a)3 + b) имеет наибольшее возможное значение.Например, G(1, 1) = 5, так как НОД(n3 + 1, (n + 1)3 + 1) достигает максимального значения 7 при n = 5 и имеет меньшие значения при 0 ≤ n < 5.Пусть H(m, n) = Σ G(a, b) для 1 ≤ a ≤ m, 1 ≤ b ≤ n.Известно, что H(5, 5) = 128878 и H(10, 10) = 32936544.Найдите H(18, 1900).

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

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

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

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

Всё начинается с основ

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

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

Развиваем шестое чувство

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

Интуитивное решение, которое другим людям легче всего понять, часто является лучшим.

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

Улучшаем навыки программирования

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

Учимся документировать и впечатляем работодателя

Если вы хотите добавить в своё портфолио что-нибудь впечатляющее, создайте репозиторий на GitHub и сохраняйте в него решения задач.

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

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

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

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

Смотрите также: Задачи для программистов

Недостатки высшего образования

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

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

Поэтому полученная степень в университете не позволяет оценить знания разработчика. Работодателям стоит больше обращать внимание на личные проекты специалистов, портфолио и персональные навыки, чтобы понять ценность будущего сотрудника.

Ресурсы для самообразования

Студенты предпочитают использовать для обучения YouTube, а не Stack Overflow. Исследование показало, что 73 % студентов в возрасте от 18 до 24 лет используют первый ресурс. Второй же популярен у 64 % опытных разработчиков в диапазоне 25–34 года.

Таким образом, напрашивается вывод об изменении популярности ресурсов самообразования в сторону видеоблогов у «поколения Z» (это подтверждает исследование Pearson & Harris Poll).

Необходимость знаний JavaScript

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

На диаграмме выше видно, что в мире 48 % работодателей ищут владеющих JavaScript студентов, а их всего 42 %. Обусловлено это тем, что часто этот язык не включён в курс обучения в вузах. Разработчики осваивают его самостоятельно. По мнению специалистов, JavaScript отсутствует в программе обучения ввиду быстро меняющейся экосистемы.

Знание и изучение языков

Тем не менее, согласно опросу, JavaScript входит в топ-3 языков, которые  будущие разработчиками планируют изучать самостоятельно. Знание низкоуровневых языков программирования наподобие «Си» поможет им в освоении новых, с учётом того, что учащиеся предпочитают самообучение.

Фреймворки

AngularJS, React, Node.js и Spring возглавляют список фреймворков, знания которых компании требуют от разработчиков. И подобно предыдущему пункту, заметен недостаток специалистов в этой сфере, ввиду преподавания в университетах основ и теорий с минимумом практики. В связи с этим специалисты HackerRank советуют компаниям учитывать ситуацию и вкладываться в навыки специалистов.

Важность профессионального роста

Исследование показало, что первостепенными для разработчиков-соискателей являются:

• профессиональный рост и обучение (менторство);
• совмещение работы и личной жизни (удалённая работа, гибкий график);
• интересные задачи (участие в сложных проектах).

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

Вывод

Несмотря на то, что 76 % опрошенных стремятся получить учёную степень в вузе, 65 % будущих разработчиков ответили, что хотя бы частично обучались самостоятельно. Именно поэтому самообразование играет огромную роль при рассмотрении кандидата и его приёме на работу. Также следует отметить рост популярности YouTube, как одного из основных ресурсов для самообразования. При этом наиболее востребованный язык программирования — JavaScript и связанные с ним фреймворки, но ничто из упомянутого часто не входит в программу обучения в вузах.

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

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

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

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

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

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

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

Меня зовут Антон Попович. Более 15 лет я работаю в сфере IT, из них более 10 лет руковожу другими айтишниками. Последние несколько лет являюсь техническим директором — сначала наëмным в чужой компании, а теперь в собственном стартапе — лаборатории по исследованию искусственного интеллекта HINT Lab.

О важности делегирования

Многие боятся делегировать, потому что считают, что «сами всë сделают лучше». И небезосновательно — чаще всего, это действительно так.

Однако, делая всë самостоятельно, невозможно создать робота, написать социальную сеть или любую другую сложную систему. Сфера влияния, до которой можно «дотянуться», действуя в одиночку, весьма ограничена. Примеры систем, приведëнные выше, требуют для реализации

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

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

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

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

Поначалу вам может показаться, что попытки делегировать отнимают кучу времени — столько, что сам бы уже 100 раз сделал (да ещë и с лучшим качеством). Но будьте мудрее — доверяйтесь не эмоциям, а математике и здравому смыслу. Чтобы наладить процесс делегирования, нужно единовременно вложить много ресурсов, но сделав это, вы будете получать экономию времени при каждой новой итерации. Рано или поздно наступит точка окупаемости, после которой выигрыш времени от делегирования станет положительным и будет только расти.

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

Правила делегирования

Теперь опишу по пунктам правила, которыми я руководствуюсь при делегировании.

0. Устранение — автоматизация — делегирование

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

Если немного копнуть, часто оказывается, что какие-то действия вообще не приносят полезного результата, а являются рудиментами решений, принятых когда-то давно, при других обстоятельствах. К примеру, в компании, куда я пришëл техническим директором, проводились еженедельные «отчëтные» митинги, а также ежедневные стендапы по SCRUM. На еженедельных митингах было скучно, так как ребята по второму разу повторяли то, что рассказывали на стендапах. Когда начали копать, выяснилось, что еженедельные митинги появились ещë до внедрения ежедневных, а потом их просто забыли отменить.

Вспомните теорию о том, что 20 % действий приносят 80 % результата, и критически проанализируйте, не относится ли процесс, который вы хотите делегировать, к наименее продуктивным, дающим только 20 % результата. Если это так, то просто отмените его.

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

И только если первые два варианта не подходят, стоит задуматься о делегировании.

1. Самостоятельная проработка

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

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

Делегирование — это освобождение себя не от самых сложных, а от самых простых дел.

Когда вы прекрасно понимаете все аспекты процесса, знаете, что может пойти не так, и легко выполните задачу сами, но на это у вас уйдëт больше времени, чем необходимо на постановку этой задачи подчинëнному, — смело делегируйте!

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

2. Описание процесса

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

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

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

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

В этом вам помогут следующие установки:

• Когда человек не видит очевидных отклонений от того, как должно быть, — он не тупой. Просто он не знает, как должно быть. Вы видите одну и ту же картинку при каждом запуске и сразу замечаете, если что-то идëт не так. Он же запускает процесс первые разы и понятия не имеет, чего ожидать. Например, индикатор «306 ошибок за последний час» может моментально дать вам понять, что случилась нештатная ситуация, а другому сотруднику не сказать ничего, потому что он просто не знает, сколько ошибок бывает в норме.
• Когда человек делает не то, что написано, и поэтому получает непредсказуемый результат, проблема может заключаться и в том, что он криво прочитал, и в том, что вы криво написали. Пока нет статистики в пользу одного из этих вариантов, их априорную вероятность следует считать равной и критически посмотреть на своë творение.
• Если человек совершает странные действия — держите в голове, что большинство людей искренне стараются делать как лучше (пока их энтузиазм не убивается несправедливым наказанием). Скорее всего, вы оба достаточно рациональны, а разница в решениях обусловлена разными вводными. Вместо обвинений в иррациональности, сравните ваши вводные и локализуйте те, что отличаются.

Если же человек задаëт слишком много вопросов, на которые он мог бы ответить и сам, просто спросите: «А ты бы сам как сделал?». Это заставит его подумать.

Вообще, я уже давно придерживаюсь концепции «трëх вариантов ответа»: человек, идущий с вопросом к начальнику, должен прийти с тремя вариантами ответа, один из которых он рассматривает как предпочтительный. Секрет в том, что при таком подходе 90 % вопросов решаются без необходимости у кого-то спрашивать, а оставшиеся 10 % уж точно заслуживают обсуждения.

3. Мотивация

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

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

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

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

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

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

Если же работа выполняется не так хорошо, как могла бы, — обратите внимание сотрудника и на это. Но критикуйте так, чтобы не отбить желание исправиться:

• критика должна быть направлена не на человека, а на его работу (проблема не в «тебе», а в «результате твоей работы»). Если проблема в человеке, коррекция результата требует изменения свойств личности. Если же проблема в результатах, они исправляются без коррекции личности. Второй тип критики воспринимается человеком значительно более лояльно;
• критикуйте конструктивно — опирайтесь только на факты, а не ощущения, и предлагайте, что и как можно сделать иначе, чтобы результат в следующий раз стал лучше.

4. Контроль

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

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

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

5. Переход от делегирования задач к делегированию ответственности

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

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

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

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

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

6. Отладка на метауровне

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

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

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

1. Первым делом, конечно, мы восстановили работу сервера.
2. Интересуюсь у админа, как же так получилось, ведь бесперебойная работа сервера и моментальное реагирование на все отключения находятся в его ответственности.
3. Админ сообщает, что на такой случай он настроил уведомление на свой телефон, которое должно было разбудить его ночью, но сегодня оно почему-то не сработало.
4. Иду в сервис уведомлений и вижу, что он не оплачен. За своевременную оплату отвечает бухгалтерия.
5. Иду в бухгалтерию и узнаю, что бухгалтер в суматохе забыла его оплатить. Говорит, что впредь будет внимательней и больше не забудет.
6. Я спрашиваю, как они сейчас хранят информацию о том, когда что надо оплачивать, и получаю ответ, что регулярных оплат не так много, поэтому они просто держат в голове все даты регулярных платежей. Бухгалтер настаивает на том, что этот способ достаточно надëжный и менять ничего не требуется, просто единичный форс-мажор.
7. Прекрасно понимаю, что если один раз это произошло, то может произойти и в будущем. Особо пугает то, что текущий процесс не масштабируется и точно сломается при увеличении количества используемых сервисов.
8. Предлагаю завести регулярные напоминания на все оплаты в Google-календарь. Пусть напоминания приходят в тот момент, когда оплата уже должна быть совершена, но крайний срок ещë не наступил. Когда напоминание придëт, бухгалтер вспомнит, совершила ли она оплату к этому моменту, и если да, то просто проигнорирует его. Но если оплаты не было, это напоминание станет спасительным.
9. Бухгалтер сказала, что решение отличное и простое и она бы с удовольствием им пользовалась, просто ей это не приходило в голову.
10. Помогаю бухгалтеру настроить все напоминания и получаю обещание, что она таким же образом будет заводить напоминания на все новые сервисы, которые будут появляться в будущем. На всякий случай, пишу ей пошаговую инструкцию.

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

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

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

7. Переход от реактивных дел к проактивным

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

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

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

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

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

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

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

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

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

Вывод

Такой подход к делегированию выгоден всем сторонам в вашей компании:

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

Как делегировать процесс: порядок действий

0. Проверьте, нельзя ли от него просто отказаться, либо автоматизировать.
1. Выполняйте процесс самостоятельно, пока он не станет для вас рутинным.
2. По ходу дела документируйте основной алгоритм и все возможные отклонения от него.
3. Делегируйте выполнение процесса подчинëнному. Давайте обратную связь, хвалите, не судите строго.
4. Контролируйте качество выполнения процесса подчинëнным по автоматически собираемым метрикам, либо, если это невозможно, вручную.
5. Перейдите от делегирования отдельно взятой задачи к делегированию связанной с ней ответственности.
6. Обнаружив проблему, исправляйте не только еë симптом, но и причину, причëм старайтесь закапываться в поиск причины как можно глубже.
7. По мере освобождения времени от рутины, начинайте всë больше проактивно задумываться о важных делах.

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

Откуда появились сертификаты

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

Может ли сертификат что-то гарантировать?

Можно предположить, что естественный отбор сам определит, какие сертифицирующие организации полезны, а какие нет. Но в данном случае, как и во многих других, рынок не является идеальным механизмом регулирования в пользу клиента. Да, какие-то токсичные компании, как и токсичные бизнес-идеи, уходят: если люди это «пьют» и «умирают», то через некоторое время другие перестанут это покупать. Но, если мы посмотрим на рынок FMCG — товаров повседневного спроса — то увидим, как все пьют Coca-Cola или Pepsi — не самые полезные напитки. Просто их производители замечательно поставили производство и маркетинг. Поэтому мне кажется, что востребованность сертификации сама по себе не доказывает её пользы.

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

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

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

Теоретик VS практик

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

В вопросе о том, что важнее, подтвержденные теоретические знания или опыт, приобретённый во время работы, я смотрю на ситуацию со стороны. Допустим, я отвечаю за распределение ресурсов между проектами. Сейчас у меня параллельно запускается сразу два. В одном проекте будет много реверс-инжиниринга, придётся восстанавливать требования, разбираться, как существующая система работает. В другом нужен solution design. Причем последний запускает безумный стартапер, у которого есть деньги, но он не может нормально сформулировать идею и не знает точно, что ему нужно.

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

Представим другую ситуацию. Человек учился несколько лет бизнес-анализу в солидной организации, ходил на лекции и сдавал экзамены. Но диаграмму применительно к конкретному проекту он никогда не рисовал, просто прочитал, как это делать, понял, сдал, забыл. А сертификат остался. Есть, конечно, сертификаты с ограниченным сроком действия. Но так ли они нужны тем, кто уже работает? На мой взгляд, ограничение сроков действия — не более чем способ заставить человека платить за подписку, примерно так же, как покупать обновлённый iPhone.

Как же развиваться?

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

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

Через несколько лет я открыл BABOK, будучи Strong Middle, в надежде, что он наконец-то поможет систематизировать мои знания. Но, во-первых, это жутчайшее чтиво,  написанное в духе спецификации на ПО, во-вторых, оказалось, что 80 % того, что там есть, я уже знаю. Из оставшихся 20 % — три четверти совершенно бесполезны, и не вызывают вопросов только 5 % всего огромного документа. BABOK не ставит задачи показать, что, скажем, эти две техники используются в большинстве случаев, а вот эти 8 никому не нужны. Он просто описывает все 10. И ты неделями мучаешься, героически добивая 300 страниц, из которых 250, а то и больше, тебе просто никогда не пригодятся.

Помимо непосредственно профессиональных знаний есть ещё очень важный момент — обретение soft skills. Увы, ни одна программа подготовки БА этому не учит, и я не знаю сертификатов, которые смогли бы доказать, что человек умеет быстро принимать правильные решения, находить общий язык с клиентом, разрешать конфликтные ситуации и т. п.

Кроме того, когда мы говорим про сертификацию, нужно понимать, что вариантов тут масса, и не факт, что то, чему вы будете учиться, пригодится именно вам, особенно если вы только начинающий аналитик. Я бы выделил отдельно сертификации по фреймворку, сертификации IIBA и PMI, сертификации по инструментам UML и BPMN. Есть сертификации по доменной области: CFA, FRM и другие. Есть тренинги по soft skills. Опять же, если вы БA в финансовом проекте, было бы здорово получить CFA. Но, боже мой, вы видели эти книги? CFA — настолько огромная область знаний, что даже у крупной сервисной компании вряд ли найдётся достаточно проектов, чтобы возникла необходимость хотя бы в половине. Другое дело, если вам просто нравится учить всё подряд и получать красивые бумаги, подтверждающие ваши богатые знания.

Преимущества подхода, когда сам «выхватываешь» что-то, в том, что ты сразу это применяешь на практике и тратишь ресурсы только на то, чему такое применение гарантированно найдётся. Я соглашусь, что это требует селф-менеджмента, желания и способности учиться. Никто не поведёт тебя за ручку — что сам найдёшь, то и выучишь. Но зато эффективность усилий будет гораздо больше. Откуда кому-то со стороны знать, какой набор знаний пригодится именно мне в моих проектах?

Выводы:

• Сертификаты по бизнес-анализу нужны в первую очередь организациям, которые их выдают. Это довольно хорошо поставленный бизнес.
• Компаниям, которые нанимают специалистов, наличие сертификата у сотрудника в большинстве случаев ничего не гарантирует, кроме того, что сотрудник прослушал определённый курс лекций. Заменить проектный опыт никакие обучающие программы не могут.
• Если вы всё-таки думаете рано или поздно инвестировать в своё образование, то лучше чётко очертить круг интересующих вопросов и выбирать наиболее узко специализированные курсы с чётким  пониманием того, где, когда и, главное, зачем вам это пригодится. В противном случае 90 % того, что вам расскажут будет совершенно бесполезно.