Бунт против удаленки
Взято из моего телеграм-канала https://t.me/IN_head_IT
Взято из моего телеграм-канала https://t.me/IN_head_IT
Про наставников
За всю свою карьеру наставников (ну или людей, которых можно назвать наставником) было у меня всего лишь двое. И они мне помогали в первый год, как я пришел в АйТи.
Оба - высококлассные специалисты и просто отличные ребята, но наставничество у них, как может показаться с первого взгляда, было так себе.
Единственное, чем помог мне первый, так это показал, где в офисе туалет. Ну и сказал, чтобы я ему всякой ерундой мозг не делал и сидел гуглил.
И... я сидел и гуглил. К коллегам шел только тогда, когда идей не было.
Взято из моего телеграм-канала
https://t.me/IN_head_IT
До того как войти в IT, я считал айтишников толстыми задротами с засаленными пальцами и вечно грязными волосами. Но, когда вышел на работу (карьера моя началась в 2013 году), то понял, что 99% айтишников - молодые, энергичные и жизнерабодстные парни и девушки лет так до 30 (это в среднем).
Но это, конечно, не везде.
До 2022 года я работал с заказчиками из Западной Европы и Великобритании. Так вот там Айтишник - это взрослый дядька или тетька, которому хорошо так за 40, а то и больше. И многим из них вообще пофиг на какие-то там технологии, развитие карьерный рост и так далее. За 10 лет моей работы с кучей компаний, младше 30 я видел лишь пару человек.
Был один мужик, англичанин, который нам преподавал что-то по севрерной части. У него был специальный таймер, который показывал сколько ему до пенсии. И он нам честно говорил на курсах: "Ребят, единственное чего я хочу - это поскорее выйти на пенсию, купить ферму в Новой Зеландии и уехать туда жить. Ваш АйТи мне нахер не нужен."
Как-то так.
Взято из моего телеграмм-канала (читай еще больше житейских историй и новостей из айти тут):
https://t.me/IN_head_IT
Месяцев 7 назад мне позвонили со словами "вы тот кто нам нужен! Вас то мы и искали!" и пригласили на собеседование на должность полу программиста полу системного администратора. В назначенный час я приехал в центр города, подошёл к красивому зданию и засомневался, до боли всё было солидно и красиво. Войдя в нужный мне офис, мне предложили подождать минут 10 на комфортабельной табуретке, пока начальник не освободится.
Беглый осмотр натолкнул на мысль, что это очередной колл-центр с пятью девочками на минимальную зарплату. Но зачем же им нужен был я?
-Вас ждут, пройдите.
В кабинете руководителя было, как говориться, "дорого богато". Большое кресло, что бы взирать на вопрошающих, огромный стол, за которым можно было играть вдесятером в манчкин, ни к месту медный глобус на отдельной тумбочке (сейчас пишу и понимаю, что вероятно это был минибар), несколько солидных но скупых грамот и... одиноко стоящая в углу бита.
Риторически посмотрев взглядом Дона Корлеоне, начальник начал говорить...
-Короче, тут тема конкретная, реальные бабки заколачиваем.
-... - разница между внешним и внутренним вводила меня в ступор.
-И мне нужны серьезные люди, которые будут на меня работать.
-... - дар речи меня покинул окончательно.
-Итак, щас погоняем тебя по вопросикам, кто такой, почём стоишь, а потом проясним непонятки.
Далее была череда вопросов, от которых я начал сомневаться в том, а было ли у меня вообще высшее образование, опыт работы, что я вообще умею делать и зачем я сюда пришёл.
Среди вопросов были "Обрисуй мне свои навыки, чем ты лучше других?", "Сможешь отвёрткой в машину ГЛОНАС прикрутить?", "Обоснуй почему ты не знаешь С#.
-Ну в целом ты пацан толковый, я согласен тебе отсыпать нормальные такие деньги.
И вот настал мой черёд задавать вопросы.
-Сколько?
-Тебе хватит.
-А поконкретнее?
-У меня тут все за такое работают и не жалуются.
-Иии?
-20к в месяц первый год. Но дважды предупреждать не буду, один косяк и я тебя уволю. Я человек щедрый и если ты будешь хорошо работать, то через год подниму зарплату на 20%.
-24к?
-Именно. И учти, пол года испытательный срок, уволю в любой момент если что.
Выйдя из этого здания я ощущал смешанное чувство, с одной стороны было жалко денег на дорогу до этой серьезной фирмы, где можно обкашлять вопросики, а с другой стороны, сам бы не поверил, если бы не увидел такого чёткого динозавра вживую.
p.s. На днях я увидел вакансию этой же фирмы, после чего вспомнил о них. Оказалось что они так никого и не нашли за эти серьезные деньги.
Программирование - это фантастическая область, полная возможностей для творчества и инноваций. Однако, многие программисты сталкиваются с определенными страхами и мифами, которые окружают эту профессию. Давайте рассмотрим эти страхи и узнаем, насколько они реальными.
Один из самых распространенных мифов - это то, что программисты всегда должны быть "гениальными". Многие люди считают, что для того, чтобы стать программистом, необходимо обладать невероятным уровнем IQ и быть гуру математики. В действительности, это не совсем так. Хотя хороший уровень логического мышления и аналитических способностей являются важными, программированию можно научиться с любым уровнем интеллекта. Главное - это усидчивость и желание учиться.
Еще одним мифом о программистах является их постоянная занятость и отсутствие времени на отдых и личную жизнь. Конечно, работа программиста может быть очень интенсивной, но большинство программистов стремятся найти баланс между работой и отдыхом. Они понимают, что для сохранения своей продуктивности и креативности необходимо время на отдых и релаксацию.
Еще одним из наиболее серьезных страхов программистов является боязнь устареть и быть замененными автоматизацией. С развитием искусственного интеллекта и автоматизации процессов существует опасность, что некоторые аспекты программирования могут быть автоматизированы. Однако, не стоит паниковать. Программисты постоянно приспосабливаются к новым технологиям и изменениям в индустрии. Они могут сосредоточиться на более сложных и творческих задачах, в то время как задачи, которые могут быть автоматизированы, будут делегированы компьютерам.
Страх перед изменениями и неизвестностью также является распространенным среди программистов. Быть программистом означает быть готовым к постоянным изменениям. Технологии постоянно развиваются, новые языки программирования появляются, а старые устаревают. Программисты должны всегда заниматься самообразованием и быть открытыми для изменений. Однако, это может вызывать страх у тех, кто не любит перемен и предпочитает оставаться в зоне комфорта.
Помимо этих мифов и страхов, программисты также сталкиваются с рядом практических трудностей. Например, часто возникает страх сдачи некачественного кода или ошибок в работе. В программировании ошибки являются неизбежной частью процесса, и программисты должны уметь их исправлять и учиться на своих ошибках.
Также программисты иногда опасаются неясных требований и неправильных ожиданий заказчика. Они всегда должны быть готовы к коммуникации и уточнению деталей проекта, чтобы удовлетворить потребности заказчика.
Однако, несмотря на страхи и мифы, программисты все еще остаются одними из самых востребованных специалистов в наше время. Программисты играют важную роль во всех отраслях, начиная от разработки приложений и игр, до создания программного обеспечения для научных исследований и автоматизации бизнес-процессов.
В конечном счете, успех в программировании зависит от самоуверенности, усидчивости, постоянного обучения и приспособляемости к изменениям. Понимание реальности и преодоление страхов и мифов, связанных с программированием, помогут программистам стать успешными и креативными профессионалами в этой захватывающей области.
Хотите встать на место пользователя, и понять как юзеры страдают? Тогда эта игра для вас. Простая форма регистрации из 4 шагов и почти 8 минут, неплохо правда? А вы за сколько пройдете?
На досуге веду небольшой канал где пишу про интерфейсы и работу дизайнера. Забегайте на огонёк.
Мое начало в IT было с момента покупки старого лохматого Pentium 1, с 32мб оперативы и 960мб диском Caviar в далеком 2001 году. До этого компы я видел только в учебном центре, куда мы ходили на информатику. Свой первый комп я убил уже примерно через неделю, когда решил почистить без того маленький диск от ненужных файлов, каждый мегабайт был на счету. Вот так я узнал, что такое переустановка винды, на тот момент 95.
А потом понеслось, 98, ME, 2000. После мой комп сход, видимо мать или проц приказали долго жить. Так как я в этот момент уже получал образование в техникуме, родители купили мне новый системник, это был Celeron, 256 оперативы и 40гб диск. С этого момента моя жизнь разделилась до и после, систему я на нем сносил и ставил настолько много раз, что я помнил наизусть ключи от дистрибутива.
Примерно в 2002 году я познакомился с Visual Basic, а затем уже и с PHP. Как оказалось, делать сайты это очень интересное занятие. Затем в ход пошли базы данных, а в 2006 году я уже устроился сисадмином на завод, не имея никакого опыта в обслуживании серверов и рабочих станций, я не струхнул и рискнул. С этого момента мой мозг постоянно получал тонны новой информации, ведь все приходилось изучать методом тыка, проб и ошибок: Windows Server, Active Directory, сеть, роутеры, маршрутизация. К 2010 году у меня уже был достаточный опыт в системном администрировании, но хотелось чего-то нового, потому что было скучно.
В 2012 году я пошел работать веб-программистом и так до 2015 года, пока контора не развалилась. В итоге я пошел работать к знакомым сисадмином и разработчиком сайтов в едином лице в одну крупную компанию по производству строительных материалов, где и работаю по сей день, но уже в роли начальника it-отдела.
Так вот хотелось бы сказать, что за мой 20-летний опыт я прокачал мозг не только в плане системного администрирования, за это время у меня появился большой опыт в веб-разработке и разработке на JAVA. Ни дня не жалею, что упорно познавал чуждые мне вещи и не боялся браться изучать. А мой пост к тому, что проводя собеседование на вакансию системного администратора в нашей компании, когда человек узнает, с чем ему приходится работать (сложная сеть, куча оборудования, Linux на серверах, виртуализация), они просто боятся и уже на этапе собеседования сливают себя, боясь в своих силах.
Не бойтесь, получайте знания, они вам пригодятся в жизни!
Всем лучи добра! Меня зовут Николай Петров, но вы можете звать меня просто Вадим. Я работаю техническим писателем в одной компании компании. Мы разрабатываем систему электронного документооборота, а в статье я хочу поделиться тем, как мы один большой отдел поделили на несколько команд. Я не буду пересказывать очередную историю успешного успеха, а изложу процесс с моей субъективной точки зрения. Всё перевру, приправлю тупыми шутками и в таком духе.
Как у любой другой компании у нас была своя команда разработки, точнее две больших команды. Одна команда разрабатывала один продукт, другая — второй. Всё шло хорошо, приходили новые разработчики, команды постепенно разрастались, и к какому-то моменту стало понятно, что большие команды только усложняют процесс разработки и делают взаимодействие неудобным. Когда одни и те же ошибки исправляются по несколько раз разными людьми — это субоптимально. Также субоптимально, когда на утреннем стендапе 22 человека и пятиминутный разговор о проблемах выливается в получасовой сеанс психотерапии для одного-двух разработчиков. Так мы решили перейти от проектных команд к кросс-функциональным командам. Сейчас всё поясню.
TRIGGER WARNING: Прежде, чем я начну, прошу вас подготовиться к неожиданностям при прочтении статьи. Если текст кажется вам переполненным сарказмом, пожалуйста, не относитесь к нему слишком серьёзно. Если текст вас оскорбляет, не читайте его. Спасибо!
Сам понял, что сказал?
Сложное слово "кросс-функциональные" означает всего лишь, что все команды занимаются всем понемногу. Таким образом каждая команда выполняет задачи из разных проектов и владеет знанием обо всём продукте, а не только о его части. Почему так важно, чтобы каждый знал чуть-чуть обо всём, думаю понятно, но на всякий случай поясню:
- Каждый разработчик видит код разных проектов и немного понимает "как это устроено".
- Если кто-то заболел, ушёл в отпуск или уволился (и такое случается), кто-то другой подхватит его работу.
- Все вместе делают продукт, а не отдельную его часть.
Недолго думая, мы решили организовать встречу в лучших традициях демократии, где каждый может сам выбрать, что ему нравится больше всего. Встречу провели, конечно же, онлайн. Не все сейчас ходят в офис, да и офисы у нас в двух разных городах. Кто-то даже впервые показал своё истинное лицо. Не только аватарку, в смысле. Все дружно перешли по ссылке в Miro, где наш заботливый руководитель Денис заранее подготовил стикеры, на которых каждый записывал, чем он хочет заниматься.
Затем всем было предложено занять место за четырьмя столами. Столы были виртуальные, поэтому закусок не предполагалось, зато каждое место было подписано в духе "frontend-разработчик", "backend-разработчик", "бизнес-аналитик", "тестировщик", ой, простите, "QA-инженер", "технический писатель". Три обычных команды и одна типа сервисная — помогает другим и координирует работу. Всё потому, что бизнес-аналитиков у нас пока не так много да и технический писатель всего один (это я. Привет, мам!).
Где-то после этого была ещё встреча для каждой команды, где они долго и в лучших традициях древнегреческих мудрецов рассуждали о том, кто же должен быть "тимлидом", а кто должен ходить на общекомандные встречи и почему это могут быть разные люди.
После разделения каждая команда обладает всеми необходимыми атрибутами успешного коллектива:
- Дурацкие названия: Вжик, Горыныч, БЭМС (Боевые, Энергичные, Молодые, Симпатичные), Звёздочка
- Логотипы из картинок, найденных в интернете
- Командный дух, компетенции и опыт
Передел YouTrack
Команды есть, теперь надо как-то работать. Работаем мы в YouTrack, точнее с его помощью. Да-да, я знаю, что Agile, спринты, ежедневные стендапы и вот это всё от зарубежного диавола и вообще никому не надо. Если вы согласны, то пропускайте этот раздел и идите лесом дальше по статье.
Постараюсь кратко и на пальцах. Раньше у нас был один общий ютрек: все задачи в одной куче, которая распределялась нашим многозадачным руководителем Денисом. Теперь у нас по-прежнему один общий ютрек, но задачи распределяет маленький избранный народом тимлид.
Раньше каждые две недели мы планировали один общий спринт, на котором можно было просадить полтора часа времени, а теперь команды планируют спринты сами. А могут вообще отказаться от всего лукавого аджайла и планирования, если так проголосуют. Профит в том, что теперь на планирование тратится значительно меньше времени и нервов.
Мне так вообще в планировании не надо участвовать. А смысл? Всё равно каждое требование я потом должен буду задокументировать, вот я и документирую, а не планирую.
Раньше в ютреке было два проекта: платформа и web-клиент. Теперь у нас есть общие задачи производства, которые могут включать любой проект. Были задачи типа WebC и задачи DV5, а стали просто TSK (может быть как WebC, так и DV5, так и вообще что угодно). Раньше ошибки записывались как обычная задача, а теперь в специальную задачу типа ERR. Видишь заголовок и сразу понимаешь, где собака зарыта.
У каждой такой задачи есть поле "команда", в котором указаны ответственные. Приходишь такой в требование, смотришь, кто ответственный, сразу знаешь, на кого наехать, чтобы узнать инфу.
А ещё у меня появился свой тип TSK-задачи — задание на документацию. У моих особых задач нет ревью и тестирования, они сначала открыты, потом в работе, потом закрыты. Всё.
Расскажи ещё, как у вас круто получилось
Работать правда стало намного увлекательнее. Появился чёткий ритм. Утром стендап (5-15 минут) и обсуждение командных проблем, потом избранные приходят на синхронизацию и рассказывают проблемы на общекомандной встрече (обычно минут 5-7). Каждые две недели ретроспектива (как поработали) и планирование (что будет делать дальше) и общекомандное демо (показать всем, как работает сделанное за 2 недели). И это не полуторачасовые встречи как раньше, а реально динамичные и полезные события. Мне особенно нравится демо, потому что теперь мне не надо сидеть и втыкать в требования часами, включая воображалку "а что же тут подразумевалось? а как же это задокументировать". Команды всё покажут и объяснят сами!
Ладно, кого я обманываю, всё равно мне приходится втыкать в требования часами, потому что я тупой.
Команды стали максимально автономными и независимыми. Они не ограничены ничем кроме достижения поставленной цели — выпуск продукта. В своих маленьких коллективах коллеги разработали свои методики автоматизации, особенные алгоритмы взаимодействия и т.д. Например, в Звёздочке разработали систему ачивок за количество закрытых требований в спринте. Если они закроют XX, YY, NN требований, то получат одну, вторую и третью звёздочку соответственно. Причём именно полностью закроют, включая документацию. На вопрос "а что если я не успею задокументировать их требование, и оно не будет закрыто", мне ответили, что могут вежливо попросить меня поторопиться. Что даёт мне некоторую власть над целой командой. Власть опьяняет.
В любом случае получилось классно! Демократичность, открытость и самостоятельность — вот как бы я охарактеризовал нынешний процесс.
Гонишь, не может всё быть так гладко
Может и гоню, но совсем чуть-чуть. Вот настолько:
Дело в том, что у нас в компании налажено ревью кода. Это когда один разработчик приходит к другому и говорит: "смотри, какой классный код я сделал!", а второй ему отвечает: "почитай чистую архитектуру Мартина, тогда поговорим".
Короче, у нас было несколько вариантов организации ревью, и мы не знали, какой из них выбрать:
1. Итеративное ревью.
--- Взяли задачу. Ответвились, сделали доработки по фронту и по бэку.
--- Перед передачей на приёмку бизнес-аналитику делаем ревью фичи целиком. Заодно подмержили develop.
(Есть мнение, что разработка в отдельных ветках — это прошлый век. Вот и пусть будет.)
--- Сделали хорошо, довели ревью до одобрения и передали на приёмку.
--- Если нужна доработка, повторяем предыдущие пункты.
--- Если доработка не требуется, передаём на тестирование.
--- Проводим багфикс.
--- Когда готовы, делаем ревью изменений по багфиксу в целом, обратный мерж и вливаем в develop.
Вот видите, всё просто!
В таком случае ревью будет чуть масштабнее и сложнее, но делать его нужно будет реже. Одна команда сможет ревьюить другую, будет коллективное владение кодом, дети в Африке не будут голодать и будет рай на Земле. Только не спрашивайте, как это работает, моё дело — рассказать.
2. Ревью через merge-реквесты. Работает вот так:
--- Один разработчик написал код и перевёл его на ревью.
--- Автоматически создаётся отдельная ветка и назначается ревьюер.
--- Ревьюер должен обладать теми же знаниями, что и автор кода. Ну, типа клиентский разработчик не может ревьюить серверного, сишарпер не может ревьюить джаваскриптера и т.д.
--- В этой ветке коллеги обсуждают чистоту архитектуры, а затем ветка мержится в девелоп, и все довольны.
--- Можно организовать сразу через гитлаб, минуя upsourсe, в котором всё делалось до разделения.
Знаете, какой вариант мы выбрали? Никакой!
Код-ревью делается по каждой задаче или ошибке по возможности внутри команды. Если это не возможно, то кросс-командно. Ревью создаётся по коммитам для задачи или ошибки в любой ветке.
Неудобные вопросы после разделения на команды
- Как будет проходить регресс?
--- Ожидание: Все задачи регресса будут равномерно распределяться по командам. Или одна команда делает большую часть, а другие помогают.
--- Реальность: После разделения мы ещё не дошли до регресса, поэтому практического подтверждения нет.
- Кто будет брать случайно найденные ошибки из общего чата?
--- Ожидание: Под индивидуальную ответственность. Нашли, записали, а дальше задачу в работу берёт та команда, которой задача больше нравится. Или в зависимости от загруженности.
--- Реальность: Всё так и работает. До сих пор не было проблем.
- Как будут распределяться дежурства по ТП?
--- Ожидание: Очень просто. Дежурят не команды, а дежурят люди. Если загруженность по ТП большая, можно подключать людей из других команд. Если загруженность небольшая, то дежурные могут совмещать дежурство с повседневными задачами.
--- Реальность: В целом всё так. В крайнем случае особенно большой загруженности можно забить на SLA и решать задачи в комфортном темпе. Но это неправильно и мы так не делаем, конечно же. Честно-честно.
- И как полёт сейчас, спустя месяцы?
--- Ожидание: Никто не ожидал, что команды будут статичными.
--- Реальность: Кто-то ушёл, кто-то пришёл, кто-то перевёлся из соседнего отдела. Бизнес-аналитиков набралось на все команды по одному, как и задумывалось. Но есть некоторый недостаток разработчиков.
Выводы
Короче, разделение на команды — это прикольно и совсем безболезненно. Как ни странно, но после разделения мы узнали друг о друге больше, чем до этого. У каждого даже появилась своя карточка с основной информацией о человеке. Типа любимые занятия, почему он тут и к чему стремится. Очень интересно, обожаю такое.
Новичкам теперь легче влиться в небольшую команду, понять процессы и начать работать. Короче, недостаток людей — плохо, избыток — тоже плохо. Если у вас огромная команда и становится сложно управлять процессами, подумайте о разделении, это реально работает.
А если вам нравится стиль статьи, подписывайтесь на мой телеграм. Если стиль не нравился, всё равно подписывайтесь, вдруг телеграм понравится.