Если вы думаете, что у айтишников все как у других, эта статья для вас. Мы спросили про самые странные и удивительные случаи в работе. Оказалось, IT — совсем не то, чем иногда кажется. А понять, с какими сложностями можно столкнуться, получится только на реальном опыте. Читайте в первой части 15 историй о рабочих задачах, процессах и непрерывном развитии.
Задачи, которые удивили
Набор знаний, обязанностей у каждого IT-специалиста свой, но у всех есть истории о задачах, которые привели в недоумение или запомнились своей оригинальностью. Одни стали отличным челленджем, а другие наглядно показали: важны не только сами задачи, но и организация работы и понимание своих обязанностей. Это еще раз доказывает, что учиться ради знаний — хорошо, но лучше — ради опыта.
Генератор случайных чисел не выдает по-настоящему случайные числа 🙂 Помню, что, когда писал кандидатскую диссертацию, для меня это стало настоящим открытием. Моя задача была написать программу, в которой должна была происходить генерация случайных чисел. Встроенные генераторы не подходили, потому что нужны были сотни тысяч рандомных чисел, которые являются функцией от таймстампа, т.е. системного времени. И у меня получались закономерные результаты. Стало очевидно, что генерация по-настоящему случайных чисел — это серьезная проблема. Пришлось искать другие, более сложные варианты. Например, решением стал специально написанный генератор чисел на ассемблере. Рабочие задачи тоже бывают неожиданными, но этот момент я запомнил навсегда.
Ссылка на вторую часть в конце статьи.
Наверное, большинство разработчиков сталкивались и сталкиваются с тем, что от них хотят, как от «компьютерщиков» лет 20 назад, и принтер настроить, и ноутбук почистить от вирусов. Только сегодня это приобрело более современную форму. Когда я пришел в одну из своих первых компаний на поддержку новостного портала на PHP, меня внезапно попросили разработать для него мобильное приложение. И не важно, что это совсем другое направление разработки. И приставали с этим все время, сколько я там работал.
Организация процессов сложнее, чем выглядит
О процессах в IT много стереотипов. Некоторые до сих пор думают, что один программист с нуля может создать соцсеть за неделю. Но и для тех, кто лучше понимает, как все устроено, масштабы процессов могут стать неожиданностью: даже простые на первый взгляд вещи на поверку оказываются сложными. Только на опыте можно почувствовать, как устроена профессиональная среда, которую выбираешь. Порядки в каждой компании тоже свои: от тотального контроля и ночевок в офисе до гибкой методологии, поощрения творчества и свободы в принятии решений.
В начале своей карьеры, примерно восемь лет назад, я попал на работу в веб-студию. Там мы занимались разработкой веб-сайтов для местного бизнеса и городской администрации.
Один из моих коллег ночевал в офисе для того, чтобы ночью успеть закончить разработку сайта. И, как оказалось, это было нормой в компании. Процессы шли так, что сначала придумывался функционал сайта, затем детально прорабатывался дизайн, верстались HTML-шаблоны в соответствии с дизайном. В конце концов наступал этап, когда программисту нужно было сделать так, чтобы все это работало. Но времени уже не оставалось, проект должен был быть готов еще вчера. Как итог — бессонные ночи и кое-как завершенная работа.
Я старался быстро схватывать новые знания, писать качественный код и в целом делать так, чтобы продукт получился хорошим. Мое следующее удивление было, когда начальник вызвал меня к себе в кабинет и сказал, что мне нужно уволиться.
Мне объяснили, что я делаю качественную работу и результат получается хорошим, но никому не нужно качество. Нужна только скорость. А над качеством они, возможно, поработают потом, после сдачи проекта.
Конечно, я рад, что тогда меня уволили. Неизвестно, сколько бы времени я потерял на работу, которая приносила разочарование заказчикам и не давала мне развиваться.
Первое время я работал в маленьких компаниях и на низких позициях. Там происходит тотальный контроль. К вам приходят руководители, лиды, менеджеры и говорят, что и как нужно делать. Никакого простора для творчества. Но потом я перешел в крупную компанию, работающую по Agile-методологии, где каждая команда отвечает за свой продукт, и эта команда практически полностью самостоятельна.
Вы в ней отвечаете за свою часть продукта и в основном сами решаете, что и как будет реализовано. Первые дни я был просто шокирован процессом планирования и разбора задач. Мы собирались в переговорке, каждый говорил свое мнение насчет той или иной фичи, как он будет ее разрабатывать, сколько на это нужно времени (раньше только мне говорили, как быстро я должен выполнить ту или иную задачу). Через пару лет работы я начал чувствовать свободу и важность того, что делаю.
В IT я попала весной 2021 года на позицию продакт-менеджера. У меня, как и у большинства людей, не связанных с IT, было представление о том, что в этой сфере работают исключительно «программисты».
Но большим открытием оказалось то, что создание сайтов — сложный многоступенчатый процесс, в котором задействованы как минимум четыре разные профессии. Это дизайнер, frontend- и backend-разработчики, тестировщик, менеджер и пр.
Меня начали вводить в процесс со стадии наполнения и тестирования. Затем шаг за шагом я понимала, как происходит вся цепочка разработки, и начинала модерировать процессы: с дизайна и до тестирования уже залитой фичи.
Вскоре после того, как я разобралась с процессом разработки, я перешла на сторону продукта. В этом мне помогли курс профессиональной переподготовки и мой любимый босс. Здесь ждало еще одно открытие. Дело не начинается с разработки и точно ей не заканчивается!
Поясню. Если продукта или фичи раньше не было на рынке, то над разработкой того, что вы увидите на сайте в итоге, работает целая команда специалистов, которые формируют продукт. А еще — общаются с потенциальными клиентами, узнают их боли, рассчитывают экономику, риски.
А после того как продукт сформирован и сайт запущен, вступает в бой аналитический отряд IT. Если очень упростить, он собирает информацию о поведении пользователей на сайте и внешней конкурентной среде.
Простые с виду процессы оказываются очень сложными.
Постоянное развитие и учеба без остановок
IT — не та сфера, где можно один раз выучиться и потом пользоваться одними и теми же знаниями всю жизнь. В этой отрасли стремительно меняются технологии, приходят новые стандарты: приходится постоянно учиться, даже чтобы оставаться на месте. Но обратная сторона этой вечной гонки — постоянное развитие, новые интересные задачи и челленджи, профессиональный рост. IT живое и динамичное, работа не даст заскучать.
Закончив обучение в университете, я считал себя квалифицированным специалистом, которого научили всему, из чего состоит программирование. Я знал C++, Java, SQL, HTML и много других аббревиатур на английском языке.
Наступили дни собеседований, меня позвали поговорить. И тут меня ожидало огромное разочарование: будущий работодатель прервал мой рассказ о навыках и опыте, полученном в вузе, фразой «Все понятно, абсолютно всему нужно будет учить заново!».
Вот так началась моя карьера в программировании. Я разочаровался в системе образования, так как то, чему учат в вузах, в большинстве случаев устаревает еще до того, как вы закончите обучение.
Лично меня после учебы ожидали бессонные ночи, когда материал лился со всех сторон и все время нужно было развиваться, обучаться, двигаться вперед, познавать новое: языки, технологии, подходы. Я постоянно находился в роли догоняющего, мозг ежедневно разрывался от потока новой информации и пытался ее усвоить. Это было серьезное испытание, требующее самодисциплины и силы духа.
Самое неожиданное было в том, что в IT нужно постоянно меняться. Здесь часто выходят новые продукты, фреймворки или совсем маленькие библиотеки и пр. Чтобы быть на одной волне с окружающим IT-миром, как минимум нужно интересоваться новостями, посещать конференции, митапы. И если даже вы захотите работать только с одним языком, с одной технологией, стать в ней экспертом, то вам все равно потребуется обновлять свои знания. Сама технология/язык не стоит на месте. Например, после того как я выбрал направление в IT, я все равно сталкиваюсь со смежными направлениями, в которых мне необходимо развиваться, чтобы вырасти как специалист. Это может быть дизайн, простое администрирование или задачи в DevOps-области. И даже в масштабах бизнеса IT-сфера ведет к изменениям, к обучению чему-то новому.
Работать в IT я начал в небольшой компании. Там программист — это «компьютерщик», который не только знает, как писать код, но и любит администрировать, обожает разговаривать с клиентами, выясняя их потребности и проблемы. Я познакомился с различием бизнес-потребностей для малого бизнеса, у которого разработка ПО — это лишь часть продукта.
Поэтому самое неожиданное и приятное то, что в IT чувствуется жизнь.
Меня удивил уникальный язык общения айтишников и всестороннее использование непонятных аббревиатур и слов. Если к англицизмам все более-менее привыкли, то множество их адаптаций и специфичных сокращений сбивает с толку в первые месяцы работы.
Приведу пример из ITSM-области знаний. Чем CSA (Customer Solution Architect) отличается от СРА (Cross-Functional Processes Administrator) и как новичку, еще не сдавшему сертификацию ITIL Foundation, начать воспринимать эти две абсолютно разные позиции корректно? А зачем мне нужно почейзить кого-то из руководителей (англ. chase — преследовать) и почему мы не готовы коммититься (англ. commitment — обязательство) под новые условия по ключевой фазе проекта миграции в новый ЦОД? Сам факт неожиданности заключается в том, что не все сокращения и аббревиатуры носят энциклопедический характер. Все приходит из живых диалогов и встреч. Поэтому для новичков всегда найдется пара-тройка-десятка новеньких сокращений и адаптированных слов.
Я проработал в IT много лет. И самым неожиданным стало то, что многие проекты, которые выглядят очень сложными, на самом деле не такие. Они состоят из множества простых подсистем, которые взаимодействуют друг с другом. Над проектом могут работать 200–300 человек, но по факту они занимаются отдельными подсистемами и не зависят друг от друга.
Также неожиданностью или даже разочарованием стало то, что многие технологии и языки программирования не являются сложными, когда овладеешь ими. Большинство из них не несут какие-то инновации, а просто упрощают работу разработчика, убирая все лишнее, на основе ошибок предыдущих технологий.
Самая неожиданная вещь, к которой я никак не был готов и до сих пор не могу привыкнуть, — мгновенная устареваемость опыта. То, что было актуально совсем недавно, сейчас уже прошлый век.
Также неожиданным для меня является то, как многогранно может быть устроен проект, из скольких вариаций библиотек и фреймворков он может состоять. Так, когда я решил перейти в другую компанию, я столкнулся с новой неожиданностью. С трудом полученный опыт со многими инструментами оказывается не нужен из-за устаревания или по другим причинам. В моем портфолио больше 50 инструментов, но на текущем месте работы я использую 10. В итоге спустя какое-то время почти все забывается и оказывается ненужным.
Ошибки как бесценный опыт
Еще одно серьезное отличие IT от других сфер — отношение к ошибкам. Если много где ошибки считаются чем-то недопустимым, то айтишники относятся к ним как к полезному опыту. Неверное решение — это возможность узнать что-то новое и научиться справляться с неожиданными сложностями.
Как-то мы всей стартап-командой общались с инвестором. Он был совладельцем небольшой продуктовой IT-компании. Мы пришли со своим приложением, хотели воспользоваться их возможностями закупки рекламы и делить прибыль пополам. Инвестор заявил, что, если приложение будет приносить прибыль, их компания может тратить до 1 млн долларов в месяц на рекламу. Это очень впечатлило меня, я никогда не был так близко к настолько большим деньгам. С приложением в итоге ничего не получилось, зато я получил ценный опыт.
Опыт работы в одной международной нефтесервисной компании позволил увидеть реальное положение дел в нефтегазовой промышленности, актуальные проблемы и запросы.
В Центре нефтегазовых технологий разрабатывалось программное обеспечение для крупнейших российских нефтегазовых компаний. Я знал потребности рынка и смог реализовать минимальный жизнеспособный продукт, который заинтересовал стейкхолдеров.
От идеи до контракта прошло порядка шести месяцев. Самым неожиданным препятствием было то, что руководители Центра не верили, что у продукта будут спрос и пользователи.
Написание технического задания, расчет Unit-экономики, календарный план развития, составление договора — вся эта работа была осуществлена мной, сотрудником, который никогда этого не делал. Приходилось учиться на ходу, и не обошлось без ошибок. Эти ошибки замедлили процесс согласования условий, что отложило старт работ.
После этого начались работы. И здесь не было никакого менторства. Взаимодействие с командой разработки происходило на инстинктивном уровне. Первые постановки задач были максимально убогими. Однако команда разработки была уникальной, и благодаря им я научился правильно описывать задачи.
Резюмируя, я хочу сказать, что благодарен за этот бесценный опыт, который позволил мне погрузиться в продуктовую разработку буквально с места в карьер. Возможно, многим такая форма обучения не очень нравится и/или подходит, однако я из тех людей, кто быстро обучается, тем более в стрессовых ситуациях.
Для меня было в новинку отношение к ошибкам в IT — в частности, к людям, которые их совершили.
В 2017 году GitLab потерял почти 300 Гб данных в продакшне из-за ошибки сисадмина. Но сотрудника, который допустил эту оплошность, не уволили. Более того, его даже не оштрафовали, т.к. у него теперь есть уникальный опыт работы с подобными инцидентами.
Кроме этого, в IT существуют лучшие практики, одна из которых — это Postmortem (дословно «постсмертный анализ»). В контексте IT это отчет об инциденте, содержащий все детали события, действия, без объявления виновных (это важно). Эта практика нужна, чтобы в будущем больше никогда не наступать на те же грабли и точно понимать причинно-следственную связь.
В 2017 году ко мне пришла идея разработать софт для мониторинга и аналитики работы майнинг-оборудования. Но по неопытности было впечатление, что с помощью легких Backend-фич и красивого UI-дизайна мы быстро сможем делать суперпродукт. Я обладал базовыми навыками программирования, но почему-то не предполагал, что разработка — это бесконечный процесс, который никогда не заканчивается.
В итоге мы превысили заложенный бюджет в десять раз и нам пришлось привлекать дополнительные инвестиции. Изначальная бизнес-модель строилась на том, что мы инвестируем, выпускаем продукт и получаем результаты, но по факту мы постоянно что-то допиливали, фиксили и вкладывали в это дополнительные ресурсы. Сейчас для меня максимально очевидно, что готовый продукт по определению невозможен, его необходимо постоянно поддерживать и совершенствовать. Это происходит со всеми программами, которыми мы пользуемся. Даже самые простые и стабильные приложения на телефоне регулярно обновляются, чтобы устранять недочеты предыдущих версий.
Читайте также: Ожидание vs реальность. 30 правдивых историй от айтишников. Часть 2
