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

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

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

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

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

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

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

YouTube Vanced больше нет. Но есть ReVanced - 1

Статья навеяна этой новостью на Хабре

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

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

Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая старые файлы наткнулся на свои записи и решил все таки поделиться ими с Вами. Частое употребление ключевого слова к сожалению, неизбежно и не отделимо для целостности этого текста, прошу принимать или нет 'as is'. Итак...

Теория Жоп о вопросах карьерного роста

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

Тайна Дан, биохимик
Тайна Дан, биохимик

Об эволюционистской концепции Ивана Ефремова я писал ранееЧитать полностью »

Как мы теперь договариваемся о новом бизнесе на берегу: юнит-тесты в реальном мире - 1

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

Очень многие вещи из ИТ-сферы напрямую относятся к бизнес-процессам. Тойота в какой-то момент придумала промежуточные юнит-тесты на производстве в своей TPS («каждое следующее звено — внутренний заказчик с критериями приёмки»), но вот в областях типа переговоров истории сквозных проверок далеко не зашли. Вообще, в решении типовых переговорных ситуаций есть очень много гениальных механик вроде «русской рулетки» или «техасской перестрелки» при разделе имущества. Только мало кто договаривается подобное применять, потому что в конечном итоге нужно уметь декомпозировать ситуацию и отладить её.

Лет 7 назад я писал про очень простую модель того, как могут договариваться основатели небольшой компании на старте: кто за что отвечает, кто главный в ситуации клинча, как принимаются важные решения и так далее. Это была хорошая рабочая механика, но, как выяснилось за это время, случиться может вообще всякое. И все эти исключения надо обрабатывать. Например, я не думал, что у нас будет смерть соучредителя (и последовавшие проблемы для начала с почтой и доменом, зареганными на него, а потом ещё с кучей всего с наследством его доли).

И вот в какой-то момент к нам в гости завалился человек, который посвятил полжизни конфликтам учредителей. Первая мысль была: «Ну, это не про нас». А потом здравый смысл пересилил, и мы попробовали его механику договорки. И знаете, что? Отдаёт мазохизмом, но удивительно хорошо работает. В общем, давайте покажу, как выглядит очень далёкий, но всё же аналог юнит-тестов сотрудничества нескольких предпринимателей.
Читать полностью »

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

Итак, у нас есть экскурсии по Золотому кольцу России. Для пенсионеров это желанное приключение, для молодёжи — особый подвид предельно скучного и бессмысленного занятия. «20 храмов за 3 дня», «Самые нудные экскурсоводы, сыпящие датами», «Очереди в банальных местах вроде заселения в отель» — это из отзывов. Думаю, вы и сами можете себе всё это представить.

Золотое кольцо скучнейших экскурсий: как это пытаются исправить - 1
Вот так должно выглядеть заселение в отель: без людей и анкет, чёрт побери!

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

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

Привет! Я не разработчик, а менеджер. Меня некоторое время учили управлять людьми, а потом я погрузилась в мрачный мир разработки, где всё идёт не так, как говорят в университете. Сейчас я руковожу практикой управления жизненным циклом программного обеспечения и хочу рассказать несколько, возможно, важных для тимлидов и ПМ'ов вещей, которые касаются перехода на удалёнку. Потому что в наших командах люди было уже начинали так косячить. А потом покажу и расскажу про наш стек автоматизации для удалёнки, и о том, как мы аппрувим релизы из чатов на телефоне одной кнопкой, а не поднимая VPN в защищённый периметр, и это ускорило согласования, и это помогает согласовывать день в день.

Первый совет — хватит доставать своих людей!

Какие ошибки делают руководители на удалёнке - 1

Я знаю, звучит очень глупо, но многие руководители, не видя людей рядом, начинают как-то компенсировать своё желание убедиться, что они работают. Происходят вот такие чаты:

Какие ошибки делают руководители на удалёнке - 2
Дятел-менеджмент в чистом виде

Если стоит задача повысить эффективность команды сейчас и в перспективе — оставьте людей в покое. И установите 15-минутные дейли по утрам. Я уже успела увидеть и общепроектные синхры раз в четыре часа, и дейли по два часа, и впадающих во фрустрацию менеджеров, привыкших договариваться сидя лицом к лицу с кем-то. Читать полностью »

Опыт реализации сетевых фабрик на базе EVPN VXLAN и Cisco ACI и небольшое сравнение - 1
Оцените связки в средней части схемы. Ниже к ним вернёмся

В какой-то момент вы можете столкнуться с тем, что большие сложные сети на базе L2 неизлечимо больны. В первую очередь проблемами, связанными с обработкой BUM трафика и с работой протокола STP. Во вторую — в целом морально устаревшей архитектурой. Это вызывает неприятные проблемы в виде даунтаймов и неудобства управляемости.

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

Была возможность сравнить именно реализацию. Не эксплуатацию, про неё стоит говорить года через два-три.

Итак, что такое сетевая фабрика с наложенными сетями и SDN?
Читать полностью »

У каждого сотрудника Леруа Мерлен есть корпоративный телефон. Там два слота под симки: один — под корпоративную с пакетом в 100 минут и трафиком для корпоративных приложений и 3 Гб на мобильный интернет-трафик, во второй можно втыкать личную. На телефонах — мессенджеры, соцсети, личные звонки и корпоративный EMM с двумя десятками корпоративных же приложений. То есть если надо сказать что-то сотруднику в магазине, то он получит сообщение в Ватсапе. Заболел ребёнок — тоже жена дозвонится в рабочее время.

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

Я с командой провела исследование на 1000 человек про то, можно ли перенести наши основные процессы в мобильность, тогда ещё было не ясно нужен нам терминал или телефон. И если да — какой он должен быть. Будут ли сотрудники использовать свой личный телефон или устройство должно быть предоставлено компанией? Какой личный аппарат сейчас у сотрудника? После этого мы смотрели на мировые практики. В итоге выбор пал в сторону телефона от компании, чтобы не поддерживать зоопарк устройств. Телефон — потому что устройство должно быть у каждого в руках и доступно в любой момент, что нельзя обеспечить с терминалом.Читать полностью »

Хакатон на 200 человек — что нужно для организации - 1

Знаете, почему проекты в крупных компаниях делаются по полгода? Потому что один из самых медленных процессов — это общение с заказчиком для выявления деталей его потребностей. Простое уточнение ТЗ (на гвозди или на клей надо крепить) может занимать до трёх месяцев. Я сейчас, конечно, несколько утрирую, но реальность в том, что почти никогда нельзя просто взять написать или позвонить и получить прямой ответ. Надо дождаться всех из отпусков и собрать совещание.

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

Это понимали мы и понимало руководство СИБУРа, нашего мощного промышленного партнёра, который помогал с проведением и организацией хакатона. Надо было устранять зазор между тем, что уже сделано и тем, что можно и нужно сделать по автоматизации. Для этого мы решили собрать на одной площадке сразу четыре стороны:

  1. Крупнейшие промышленные компании страны.
  2. Вендоров технологий с меняющихся рынков.
  3. Молодых разработчиков.
  4. ИТ-инженеров с опытом работ в сфере или в конкретных нужных технологиях.

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

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


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