Привет!
Правила игры простые: я рассказываю историю про аудит безопасности, а вы оцениваете, правда это или нет. Под спойлером — ответ.
Рубрика «процесс»
Байки по кибербезопасности: играем в «Правда или ложь»
2022-11-24 в 7:11, admin, рубрики: аудит, байки, безопасность, Блог компании Инфосистемы Джет, защита, ИБ, инженер, информационная безопасность, процесс, управление проектамиЧто будет, если от разработчиков не отстать: умирающая команда
2022-11-17 в 11:01, admin, рубрики: банк, Блог компании Газпромбанк, задача, команда, проект, процесс, разработка, управление проектами, управление разработкойМне досталась команда, которая болела. Все понимали, что происходит, никому не нравилось, что творится в команде, и традиционно менеджеры такие команды сильно режут. Но здесь были шансы вылечить и без ампутаций.
15 человек, из них — один руководитель проекта, три фронта, два бэка, три аналитика, девопс. Симптомы обычные: процессы всем не нравятся, соседи — козлы, потому что не то и не так делают, а как нужно — не знают, ответственности ни на ком толком нет ни за что.
Вроде бы когда-то это был настроенный конвейер, но теперь его куски — как будто в разных зданиях. Особо не заботятся о том, что было «до» и что будет «после». А если всё падает, то люди поднимают руки: «Я не виноват. Я не знаю, как поднять».
Проект — внутренний банка, он нужен для улучшения работы внутри компании. Традиционных решений в кровавом энерпрайзе — два: нанять новую команду (но вгружать мидла на проект такой сложности — три-четыре месяца) или же оставить проект на поддержке, через два года найти ему замену, а команду тихо похоронить в подвале. Точнее, не так: те, кто плывет по течению и не заботится о карьере, остаются тихо сидеть «на пенсии», то есть в бесконечной поддержке проекта. А самые проактивные тут же перейдут в другие команды или другие компании.
Почему процессы разваливались? На первый взгляд, потому, что была куча ненужных совещаний и встреч с теми, кого разработчики вообще не должны были видеть. Плюс местами странноватые KPI. Как это ни странно, но если психологически давить на разработчика пару лет, то ничем хорошим это не закончится. Руководство подразделения дало мне карт-бланш на исправления, и я начал разбираться, что же случилось.
Читать полностью »
Как я ходил на удалённые собеседования JAVA-разработчика, чтобы лучше нанимать людей
2021-03-16 в 7:01, admin, рубрики: JAVA-разработчик, Блог компании КРОК, вакансии, Карьера в IT-индустрии, найм, позиции, процесс, собеседование, управление проектами, метки: Вакансии и работаЕсли обычные разработчики ходят на собеседования тренироваться и набирать опыт, то я пошёл выписывать все косяки. Чтобы их не было у меня, потому что я нанимаю людей. Собственно, стало интересно, как устроено в других компаниях — и я пошёл собеседоваться. Началось всё c базового набора: аккаунт зума, почта, резюме. Дальше можно пройти за неделю 10-12 собеседований, на что до тотальной удалёнки ушёл бы месяц.
С резюме я захотел проверить гипотезу, что рынок слегка перегрет и теперь можно накидать что-то за три минуты и просто ждать отзывов. Я указал одно место работы и шесть скилов (даже без спринга, но никто этого не заметил).
Выложил на HH. Дальше ждать пришлось недолго. Первый час — уже несколько откликов и звонок. Всего за сутки было 20 откликов и пять звонков. Предложений много, все с самыми интересными проектами, стеком, ДМС и макбуком (которого пока нет, но обязательно пришлём через месяц-два).
На третий день я набрал примерно 30 проектов, которые были бы мне интересны, если бы я действительно искал работу (пост бы неожиданно закончился здесь, если бы нашёл что-то более интересное, чем уже есть), и начал описывать то, что попало в отсев.
В отличие от многих других разработчиков я не клал трубку, когда слышал, что звонят из банка. Поэтому по итогу меня нашли банки, страховые, интеграторы и продуктовые компании. Читать полностью »
Как воспитать здорового довольного червя: разбираем инструкцию 1910 года
2020-04-27 в 12:03, admin, рубрики: Bombyx mori, биология, Биотехнологии, Блог компании Туту.ру, воспитание, книга, Луи Пастер, процесс, тутовник, Читальный зал, шёлк, шелковица, шелководство, шелкопряд
В общем, я давно хотел рассказать вам про шелкопряда
Стимпанк с дирижаблями и авиацией казался в Российской империи светлым будущим. Но вот только возможностей обычных материалов не хватало. В этот момент мы решили обратиться к биотеху — конкретно, шелковичному червю, способному делать нанонити того времени — шёлк.
В стране были уже и единичные деревья, и плантации, но с 1720 года шёлка понадобилось в разы больше. Пётр I основал большие плантации шелковичных деревьев. Но несмотря на все старания, червь у нас часто болел, чах и вообще капризничал. Тем не менее, в Астрахани на местном сырье к концу восемнадцатого века работало 20 шелковых и 70 полушелковых фабрик.
В СССР в доперестроечные времена производилось до 900 тонн коконов в год. Потом постепенно шёлк вытеснили синтетические материалы. Но речь не об этом.
Сейчас я буду учить вас выращивать тутовое дерево и воспитывать червя. На самом деле, предлагаю почитать инструкцию 1885 — 1910 года по процессу. Обещаю, она прекрасна ровно как и захватывающа. По дороге нам встретятся Луи Пастер не с тем подвигом и другие интересные люди.
Ну и, конечно, я отсканировал свой экземпляр и, обсудив с юристами, могу сказать, что книга доступна для всеобщего пользования.
Читать полностью »
Портал тестовых сред, или Спасём наш девопс
2020-03-19 в 6:51, admin, рубрики: автоматизация, Блог компании ТЕХНОСЕРВ, виртуальные среды, информационная безопасность, процесс, разработчик, тестировщик, тестовые среды
Пару лет назад мы чувствовали себя в каком-то сюрреалистическом сне. Все вокруг шли в облако для тестирования (удобно же разворачивать-сворачивать тестовые среды), а мы пытались выяснить, какие инструменты «из коробки» нужно поставлять. Для этого мы вместе с заказчиками разбирались, как устроены процессы девопса. И оказалось, что только единичные компании в России как-то грамотно применяют автоматизацию.
Сразу поясню, что мы по большей части общались или с теми, кто занимается разработкой в компании до 150–200 человек, или с производствами, где с ИТ традиционно тяжело. У компаний крупнее обычно есть и процесс, и собственное облако, и к нам они приходят за резервным размещением.
Производство обычно хорошо отлажено. Есть цикл, план релизов, есть цель, код идёт к цели вместе с разработчиками.
Тестирование и QA тоже хорошо отлажены чаще всего.
А между ними — пропасть. И её пытается заполнить DevOps. Этот супермен должен взять релиз (а в идеале — собрать в Дженкинсе или чём-то подобном), создать машину, развернуть там всё, проверить работу, может, провести пару претестов и отдать уже в QA. Читать полностью »
Эксперимент — от парного программирования к программированию всей командой
2019-12-03 в 6:50, admin, рубрики: Блог компании Туту.ру, Вуди Зил, команда, моб-программирование, обучение, практика, Программирование, проект, процесс, разработка, управление проектамиОчень хочу поделиться с вами переводом статьи про эксперимент с моб-программированием от одного из его создателей, Вуди Зила. Это когда вся команда сразу работает за одним компьютером. Как парное программирование, только групповое. Я бывший Java-разработчик и тимлид с 11-летним стажем, и раньше меня бы удивил такой подход. Оказалось, работает очень интересно. Внутри — как взаимодействуют участники, какие преимущества им это даёт, и с какими сложностями они столкнулись. Это отчёт об эксперименте, который уже три года успешно продолжается в команде Вуди. Полезно, если вы хотите настроить такое у себя.
Перевод
Оригинал: статья Вуди Зила.
Оригинальное название: «Моб-программирование — командный подход к работе».
Примечание: Статья переведена с согласия автора, в переводе максимально сохранена авторская стилистика.
Оригинальное название: «Моб-программирование — командный подход к работе».
Примечание: Статья переведена с согласия автора, в переводе максимально сохранена авторская стилистика.
1. Введение
Моб-программирование или моббинг — это подход к разработке программного обеспечения, при котором вся команда целиком работает над одним и тем же, в одно и то же время и в одном и том же месте за одним компьютером. Это похоже на парное программирование [PAIR], где двое человек сидят за одним компьютером и совместно работают над одним и тем же кодом в одно и то же время. При моб-программировании эта совместная работа распространяется на всех в команде, при этом всё ещё используется только один компьютер для написания кода.Читать полностью »
Быстрая проверка десятков гипотез: как мы вырываемся из рутины и устраиваем себе обсуждение в другом городе
2019-10-10 в 7:02, admin, рубрики: Блог компании Туту.ру, гипотеза, задача, команда, процесс, разработка, управление проектами, управление разработкой
У нас в каждой из шести команд разработки бэклог расписан примерно на два года вперёд с учётом почти неминуемого рефакторинга, фиксов, фич и хотелок продуктологов. Внутри всё может ездить по приоритетам, и некоторые большие блоки то становятся важнее, то убираются, то туда добавляется что-то новое. Но всегда есть понимание, куда копать в ближайшие месяцы.
У такой системы, кроме кучи плюсов, есть два очевидных недостатка:
- Это банально скучно, а скука — это не то, что мотивирует нас писать код.
- Накапливается много гипотез, которые по обычному процессу падают куда-то в конец бэклога, но каждая из которых может дать быстрый результат. А может и не дать. Некоторые из них интересные.
В обычном режиме разбирать эти гипотезы сложно, потому что нужно взаимодействие продуктолога, бизнес-человека (обычно руководителя направления) и ещё пары человек из других команд разработки. То есть когда у тебя есть два свободных часа, всё равно не сделать. А поскольку мы часто зарабатываем на том, что протаптываем дорожку в бизнесе к новым интерфейсам и новым фичам, проверка гипотез — это жизнь.
Сначала мы выделяли время внутри офиса и делали в общем рабочем процессе. Оказалось, что, если проверять как можно быстрее, получаются средние решения. Чтобы повысить качество, надо вырваться из общей рутины.
Поэтому мы три раза уже выезжали в какой-нибудь иностранный город и работали там.Читать полностью »
Как мы развивали ИТ в «Леруа Мерлен»: пересборка двигателя на ходу
2019-06-25 в 7:07, admin, рубрики: Leroy Merlin, Блог компании Леруа Мерлен, легаси, процесс, разработка, разработчики, розница, сервис, управление проектами, управление разработкой
Четыре года назад база клиентов велась отдельно в каждом магазине плюс ещё одна — на сайте.
В предыдущих сериях: три года назад мы решили, что нужно делать свою разработку в России. Два года назад начали писать собственный код вместо того, чтобы модифицировать форк кода материнской компании. Сегодняшняя история будет про то, как мы переключались с одного большого легаси-монолита на кучу маленьких микросервисов, соединённых своего рода шиной (оркестратор).
Самый простой юзеркейс: сделать заказ через сайт и забрать его в реальном магазине «Леруа Мерлен» в России. Раньше заказы интернет-магазина обрабатывались в другом приложении вообще и по другой схеме. Теперь нам нужна была омниканальная витрина, чтобы любой заказ был разбит на интерфейс: касса в магазине, мобильное приложение, терминал в магазине, сайт — что угодно. Если вы поставите Linux на микроволновку — пускай будет микроволновка. Главное, чтобы какие-то интерфейсы могли стучать по API к беку и говорить, что вот тут надо оформить такой-то заказ. И получали на это внятный ответ. Вторая история была с запросами наличия и свойств товара из его карточки.
На фронте (скоро и про это напишем) у нас монстр — AEM, а за ним в беке было два больших приложения: OPUS и MoVe. Первое — это база данных свойств каждого товара (от габаритов до описания), второе — отвечает за чекаут, то есть монолит касс. Если сильно упростить.Читать полностью »
Зачем нам в «Леруа Мерлен» нужен собственный российский отдел разработки на 200 человек
2019-06-13 в 7:03, admin, рубрики: Leroy Merlin, Блог компании Леруа Мерлен, команда, легаси, процесс, разработка, разработчики, розница, сервис, управление проектами, управление разработкойПривет! Я Валерий Лаптев, руководитель разработки LM в России. За два года мне нужно было поднять огромный отдел, и это был довольно интересный опыт.
Дело в том, что «Леруа Мерлен» есть во многих странах. Головная компания — во Франции, называется ADEO. Там пишут код под Францию, Италию, Испанию и Россию. Бизнес-модели у нас разные: если на российском рынке мы держим минимальные цены (ниже всех конкурентов в мониторинге), то в Европе всё иначе. На самом деле отличий море — начиная от особенностей локали и заканчивая другим законодательством. Есть особенности инфраструктуры России (те же очень большие задержки до Хабаровска) и другой жизненный цикл оформления заказа. Всё это порождает вот такой адский код, состоящий из огромных блоков IF:
Два года назад у нас было 60 магазинов и много-много хотелок по фичам. Накатывались они примерно за полгода и не всегда правильно. Последней каплей после кучи отклонённых по низкому приоритету фич была просьба завести в заказ поле-строку, чтобы мы его уже потом сами парсили. Это нужно было для особенностей доставки в России, поскольку страна больше других стран присутствия LM. Нам отказали и в этом, точнее, сказали, что будет где-то через семь-восемь месяцев.
Полугодовой цикл неспешной головной компании нам не подходил. Естественно, мы предложили написать свой код, отдать на ревью и подождать внедрения… Правда, из этого ничего хорошего не вышло.Читать полностью »
Как мы сделали форк российского Леруа Мерлен на Казахстан
2019-05-13 в 7:04, admin, рубрики: Leroy Merlin, адаптация, Блог компании Леруа Мерлен, Казахстан, процесс, розница, сервис, строительство, управление проектами
Нужно было успеть адаптировать все ИТ-системы до конца строительства магазина.
В 2016 году было решено открыть магазин в Казахстане (в Алматы). В логике группы компаний Adeo (это все магазины Leroy Merlin по всему миру) на каждую новую страну нужно создавать отдельный бизнес-юнит со своей инфраструктурой и всем-всем-всем. Например, Украина — это отдельный юнит из пяти магазинов со всеми собственными подразделениями, службами и ИТ-процессами.
На Казахстан мы решили (впервые в истории развития компании) сделать форк российской инфраструктуры, фактически расширяя наши системы на новый регион. Почему? Потому что закупки, цепи поставок, юридические и финансовые службы централизованы. Рынки близки. Законодательство близкое, хотя и есть свои особенности (каждый департамент выявлял для себя отличия с помощью коллег из юротдела). Это евразийский Таможенный союз. У нас было 90 магазинов в России, и можно было закупать на условиях, которых в Казахстане поставщики просто не дадут, да и местного производства не так много. У нас много отлаженных процессов, работающее ПО и так далее.
Осталось только чуть-чуть докрутить пару ИТ-систем. Простая работа года на полтора, потому что переписать пришлось не всё, но очень-очень многое. Началось с того, что, оказывается, надо подписать дополнительные соглашения с 800 поставщиками, чтобы их товары правильно маркировались и сертифицировались при необходимости. Чтобы в Казахстане их можно было правильно учесть, соответственно и правильно напечатать ценник, на котором по закону наименование товара должно быть на казахском и русском языках.
На этом сюрпризы только начинались. Читать полностью »