Рубрика «процесс»

Уверен, что многие представители бизнеса сталкивались с подобной ситуацией…

Вы решили провести обучение в своём подразделении: определились с темой, заявили участников, заполнили заявку в отдел развития персонала или привлекли внешнего специалиста с высокой экспертизой, арендовали зал, оплатили кофе-брейки, организовали обед, сделали приветственное слово, возможно даже присутствовали на тренинге и казалось бы, всё прошло просто прекрасно. Сам тренинг был разработан и проведен корректно, тренер отработал на 101%. Но вот обучение завершилось и вы с командой вернулись в привычный рабочий ритм.

Читать полностью »

Thinking in Bets (Принцип ставок) - книга чемпиона Мировой серии по покеру Анны Дьюк о принятии решений, где покер используется лишь как сквозной образ для связывания ключевых идей.

Принятие решений, когнитивные искажения, иррациональное поведение, человеческая психология - Thinking in Bets охватывает их все — ясно и достаточно увлекательно.

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

Привет! Меня зовут Дмитрий. Я являюсь руководителем группы в IT-компании. Если перевести на более доступный язык, то получится так: Team Lead Integration. Компания не самая крупная, но очень международная.

Знаете, я никогда не любил и не понимал такое сочетание англицизмов и русского языка. Особенно, когда в него закладывается некоторая двусмысленность. Особенно, когда используется proЧитать полностью »

Привет!

Правила игры простые: я рассказываю историю про аудит безопасности, а вы оцениваете, правда это или нет. Под спойлером — ответ.

Байки по кибербезопасности: играем в «Правда или ложь» - 1

1. «Суперпроводимость»

Читать полностью »

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

Что будет, если от разработчиков не отстать: умирающая команда - 1
Источник

15 человек, из них — один руководитель проекта, три фронта, два бэка, три аналитика, девопс. Симптомы обычные: процессы всем не нравятся, соседи — козлы, потому что не то и не так делают, а как нужно — не знают, ответственности ни на ком толком нет ни за что.

Вроде бы когда-то это был настроенный конвейер, но теперь его куски — как будто в разных зданиях. Особо не заботятся о том, что было «до» и что будет «после». А если всё падает, то люди поднимают руки: «Я не виноват. Я не знаю, как поднять».

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

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

Если обычные разработчики ходят на собеседования тренироваться и набирать опыт, то я пошёл выписывать все косяки. Чтобы их не было у меня, потому что я нанимаю людей. Собственно, стало интересно, как устроено в других компаниях — и я пошёл собеседоваться. Началось всё c базового набора: аккаунт зума, почта, резюме. Дальше можно пройти за неделю 10-12 собеседований, на что до тотальной удалёнки ушёл бы месяц.

 

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

 

image

 

Выложил на HH. Дальше ждать пришлось недолго. Первый час — уже несколько откликов и звонок. Всего за сутки было 20 откликов и пять звонков. Предложений много, все с самыми интересными проектами, стеком, ДМС и макбуком (которого пока нет, но обязательно пришлём через месяц-два).

 

На третий день я набрал примерно 30 проектов, которые были бы мне интересны, если бы я действительно искал работу (пост бы неожиданно закончился здесь, если бы нашёл что-то более интересное, чем уже есть), и начал описывать то, что попало в отсев.

 

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

Как воспитать здорового довольного червя: разбираем инструкцию 1910 года - 1
В общем, я давно хотел рассказать вам про шелкопряда

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

В стране были уже и единичные деревья, и плантации, но с 1720 года шёлка понадобилось в разы больше. Пётр I основал большие плантации шелковичных деревьев. Но несмотря на все старания, червь у нас часто болел, чах и вообще капризничал. Тем не менее, в Астрахани на местном сырье к концу восемнадцатого века работало 20 шелковых и 70 полушелковых фабрик.

В СССР в доперестроечные времена производилось до 900 тонн коконов в год. Потом постепенно шёлк вытеснили синтетические материалы. Но речь не об этом.

Сейчас я буду учить вас выращивать тутовое дерево и воспитывать червя. На самом деле, предлагаю почитать инструкцию 1885 — 1910 года по процессу. Обещаю, она прекрасна ровно как и захватывающа. По дороге нам встретятся Луи Пастер не с тем подвигом и другие интересные люди.

Ну и, конечно, я отсканировал свой экземпляр и, обсудив с юристами, могу сказать, что книга доступна для всеобщего пользования.
Читать полностью »

Портал тестовых сред, или Спасём наш девопс - 1

Пару лет назад мы чувствовали себя в каком-то сюрреалистическом сне. Все вокруг шли в облако для тестирования (удобно же разворачивать-сворачивать тестовые среды), а мы пытались выяснить, какие инструменты «из коробки» нужно поставлять. Для этого мы вместе с заказчиками разбирались, как устроены процессы девопса. И оказалось, что только единичные компании в России как-то грамотно применяют автоматизацию.

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

Производство обычно хорошо отлажено. Есть цикл, план релизов, есть цель, код идёт к цели вместе с разработчиками.

Тестирование и QA тоже хорошо отлажены чаще всего.

А между ними — пропасть. И её пытается заполнить DevOps. Этот супермен должен взять релиз (а в идеале — собрать в Дженкинсе или чём-то подобном), создать машину, развернуть там всё, проверить работу, может, провести пару претестов и отдать уже в QA. Читать полностью »

Очень хочу поделиться с вами переводом статьи про эксперимент с моб-программированием от одного из его создателей, Вуди Зила. Это когда вся команда сразу работает за одним компьютером. Как парное программирование, только групповое. Я бывший Java-разработчик и тимлид с 11-летним стажем, и раньше меня бы удивил такой подход. Оказалось, работает очень интересно. Внутри — как взаимодействуют участники, какие преимущества им это даёт, и с какими сложностями они столкнулись. Это отчёт об эксперименте, который уже три года успешно продолжается в команде Вуди. Полезно, если вы хотите настроить такое у себя.

Перевод

Оригинал: статья Вуди Зила.
Оригинальное название: «Моб-программирование — командный подход к работе».
Примечание: Статья переведена с согласия автора, в переводе максимально сохранена авторская стилистика.

1. Введение

Эксперимент — от парного программирования к программированию всей командой - 1 Моб-программирование или моббинг — это подход к разработке программного обеспечения, при котором вся команда целиком работает над одним и тем же, в одно и то же время и в одном и том же месте за одним компьютером. Это похоже на парное программирование [PAIR], где двое человек сидят за одним компьютером и совместно работают над одним и тем же кодом в одно и то же время. При моб-программировании эта совместная работа распространяется на всех в команде, при этом всё ещё используется только один компьютер для написания кода.Читать полностью »

Быстрая проверка десятков гипотез: как мы вырываемся из рутины и устраиваем себе обсуждение в другом городе - 1

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

У такой системы, кроме кучи плюсов, есть два очевидных недостатка:

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

В обычном режиме разбирать эти гипотезы сложно, потому что нужно взаимодействие продуктолога, бизнес-человека (обычно руководителя направления) и ещё пары человек из других команд разработки. То есть когда у тебя есть два свободных часа, всё равно не сделать. А поскольку мы часто зарабатываем на том, что протаптываем дорожку в бизнесе к новым интерфейсам и новым фичам, проверка гипотез — это жизнь.

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

Поэтому мы три раза уже выезжали в какой-нибудь иностранный город и работали там.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js