Работа в IT: ожидание vs реальность. 30 правдивых историй от айтишников. Часть 1

oblozhka-3-2
Ночевки в офисе, миллион долларов на рекламу и вся правда о генераторах случайных чисел

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

Задачи, которые удивили

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


Сергей Лукашкин,

эксперт по цифровой трансформации, реинжинирингу бизнес-процессов и стандартов обслуживания

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


Вадим И.,

Frontend Developer, IT-компания Holyweb

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

Потом выяснилось, что с VPN мне не одобрили вести разработку: доступ к просмотру задач есть, а к коду и бэку приложения — нет. Сделал новые заявки и ждал доступ к VDI (виртуальному рабочему столу).

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

Аллилуйя! Мне дали доступ, я скачал нужные файлы. Но установить по-прежнему ничего не мог, так как учетная запись не была админской. Отправил новую заявку. Дали админку, но в VDI опять оказалось, что я могу пользоваться не всеми ресурсами. Еще одна заявка.

В итоге через два месяца некоторых, не сильно нужных доступов еще не было. VPN вообще не использовал, VDI работал плохо и иногда сильно лагал. Доходило до абсурда: я получил доступ к Git, но не мог залить туда код. Отправлял заявку, давали доступ на заливку почти ко всем продуктам. Кроме тех, которые нужны.

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


Антон Губарев,

Senior Backend Engineer в компании «Авито»

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

Организация процессов сложнее, чем выглядит

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


Алексей Каньков,

Senior Backend Developer, компания Lokalise

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

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

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

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

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

Александр Дунай,

Frontend Tech Lead, Альфа-Банк

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

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


Мадина-Мишель Новикова,

Product Manager, компания WEEEK

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

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

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

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

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

А после того как продукт сформирован и сайт запущен, вступает в бой аналитический отряд IT. Если очень упростить, он собирает информацию о поведении пользователей на сайте и внешней конкурентной среде.

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

Постоянное развитие и учеба без остановок

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


Дмитрий Адмакин,

руководитель отдела архитектурных решений и перспективной разработки, компания «БАРС Груп»

Закончив обучение в университете, я считал себя квалифицированным специалистом, которого научили всему, из чего состоит программирование. Я знал C++, Java, SQL, HTML и много других аббревиатур на английском языке.

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

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

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


Анатолий Кабанов,

Software Engineer, Perforce

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

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

Поэтому самое неожиданное и приятное то, что в IT чувствуется жизнь.


Яков Кротов,

руководитель группы менеджеров по предоставлению услуг, компания ICL Services

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

Приведу пример из ITSM-области знаний. Чем CSA (Customer Solution Architect) отличается от СРА (Cross-Functional Processes Administrator) и как новичку, еще не сдавшему сертификацию ITIL Foundation, начать воспринимать эти две абсолютно разные позиции корректно? А зачем мне нужно почейзить кого-то из руководителей (англ. chase — преследовать) и почему мы не готовы коммититься (англ. commitment — обязательство) под новые условия по ключевой фазе проекта миграции в новый ЦОД? Сам факт неожиданности заключается в том, что не все сокращения и аббревиатуры носят энциклопедический характер. Все приходит из живых диалогов и встреч. Поэтому для новичков всегда найдется пара-тройка-десятка новеньких сокращений и адаптированных слов.


Игорь Лопушко,

Backend Team Lead в компании RBI Retail Innovation

Я проработал в IT много лет. И самым неожиданным стало то, что многие проекты, которые выглядят очень сложными, на самом деле не такие. Они состоят из множества простых подсистем, которые взаимодействуют друг с другом. Над проектом могут работать 200–300 человек, но по факту они занимаются отдельными подсистемами и не зависят друг от друга.

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

Артем Сутулов,

Software Engineer (Backend), компания Revolut

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

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

Ошибки как бесценный опыт

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


Андрей Добыш,

Senior iOS Developer, Godel Technologies Europe

Как-то мы всей стартап-командой общались с инвестором. Он был совладельцем небольшой продуктовой IT-компании. Мы пришли со своим приложением, хотели воспользоваться их возможностями закупки рекламы и делить прибыль пополам. Инвестор заявил, что, если приложение будет приносить прибыль, их компания может тратить до 1 млн долларов в месяц на рекламу. Это очень впечатлило меня, я никогда не был так близко к настолько большим деньгам. С приложением в итоге ничего не получилось, зато я получил ценный опыт.


Ранис Шарифуллин,

Product Manager, Центр нефтегазовых технологий АНО ВО «Университет Иннополис»

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

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

От идеи до контракта прошло порядка шести месяцев. Самым неожиданным препятствием было то, что руководители Центра не верили, что у продукта будут спрос и пользователи.

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

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

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


Кирилл Казаков,

ведущий DevOps-инженер в международной компании

Для меня было в новинку отношение к ошибкам в IT — в частности, к людям, которые их совершили.

В 2017 году GitLab потерял почти 300 Гб данных в продакшне из-за ошибки сисадмина. Но сотрудника, который допустил эту оплошность, не уволили. Более того, его даже не оштрафовали, т.к. у него теперь есть уникальный опыт работы с подобными инцидентами.

Кроме этого, в IT существуют лучшие практики, одна из которых — это Postmortem (дословно «постсмертный анализ»). В контексте IT это отчет об инциденте, содержащий все детали события, действия, без объявления виновных (это важно). Эта практика нужна, чтобы в будущем больше никогда не наступать на те же грабли и точно понимать причинно-следственную связь.


Александр Лозбень,

глава представительства майнинг-пула ViaBTC в Европе и СНГ, IT-предприниматель, эксперт по финансовым технологиям

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

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

Освойте новую профессию

(рейтинг: 5, голосов: 5)
Добавить комментарий