Работа в ИТ в России в бизнесе.

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

Далее со стороны разработчика.

Метафора.

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

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

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

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

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

Что же я хотел сказать?

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

Читаю я статьи замечательного такого ресурса ITmozg и скидываю руководству иногда. Мне понравилась цитата.

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

Это очевидно для успешного разработчика. Так вот у руководства не всегда есть понимание, что им тоже надо развиваться. А если на это нет времени, то необходимо нанять специалиста – бригадира (it-менеджера или тимлида). Иначе разработчики получают ад, который создается руководителем, который считает, что нормально вмешиваться в процесс разработки по несколько раз в день и устраивать панику и хаос, а так же от тех-поддержки, которая трезвонит каждые 10 минут в некоторые дни (да да, на тех поддержке сидят те же разработчики). Потому, что в коде куча багов, без тестов, ведь пишут его джамшуты, не контроллируемые и не проверяемые. И все попытки донести что-то до руководства безуспешны, просто не слушают или отвечают: "Мы лучше знаем, как вести свой бизнес". Нет понимания, что бизнес и должны существовать отдельно, даже если она для бизнеса. Нет понимания, что применяя даже самые смелые agile методологии – каждая итерация все равно должна проходить весь цикл разработки. Но обычно так – "Методология? Нет, не слышали".

Вопросы и ответы.
А вот еще одна статья с ITmozg в которой советуют разработчикам задать такие вопросы работодателю.

Просто дам ответы, возможно типичные для бизнес контор со своим ИТ отделом. Типичные для моей текущей (скоро бывшей) конторы, в том числе.

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

Следуете ли вы стандартным правилами? Есть ли у вас собственные правила для внутренних фреймворков?
  Правил нет, пиши как хочешь, чтобы работало.

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

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

Как часто происходит деплой кода? Как быстро? Как быстро происходит откат? Кто несёт ответственность за деплой?
  Как только написали, сразу деплой. Это может быть большой модуль или фикс одной строки. Сразу в продакшн. Не работает? Откати и исправь. И да, ты несешь ответственность за свой код.

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

Как часто меняется стек? Не слишком ли часто?
  А он вообще не меняется. Зачем нам новые технологии? Мы и так не плохо пишем. Работает же. А иногда даже хорошо.

Вывод.
Что делать, если ответы совпали хотя бы в 50%? Развиваться! Не дают? Бороться с руководством и развиваться и как можно скорее искать другую работу.
Главное не понять это слишком поздно, когда сил бороться уже не будет и полностью пропадет мотивация. И как следствие – начнется деградация как специалиста.

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