Рубрика «команда» - 4

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

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

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

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

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

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

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

Зачем нужен менеджер в IT проекте и что будет происходить когда его нет - 1

Роль ПМ-а — она есть всегда, и если не поручена отдельному человеку с нужной подготовкой, то перераспределяется.

Кому?

  1. Всем членам команды в равной степени.
  2. Одному члену команды готовому совмещать это со своей первичной ролью.
  3. Человеку извне, который в процессе толком не участвует, но как-бы управляет.

Все эти варианты вполне реальны, и встречаются на практике, в особенности в молодых компаниях, в которых еще нет структуры и процессов.

Держим сразу в уме вопросы:

  • Кто общается с клиентом?
  • Кто держит в уме всю картину проекта? А лучше документирует её.
  • Кто организовывает процесс?

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

Всем привет! Меня зовут Роман, и сегодня я поделюсь своим опытом работы в распределенной команде верстки. Расскажу о процессах, которые мы построили, и как команда из четырех человек покрывает потребности в верстке целого подразделения, состоящего из 30+ продуктов и 20+ продуктовых команд.

Как организовать эффективную работу распределенной команды верстки

Еще расскажу о том, как:

  • Контролировать работу распределенной команды;
  • Добиваться консистентности кода в разных проектах;
  • Справедливо распределять задачи;
  • Поддерживать высокое качество работы;
  • Не накапливать незавершенные задачи;
  • Проводить профилактику выгорания и развивать сотрудников.

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

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

Перевод

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

1. Введение

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

Байки переговорщика - 1

Привет!

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

С другой стороны, частые переговоры означают много поездок. Иногда везёт. Вот в Дубае выходные пятница и суббота, а воскресенье — рабочий. При этом рейсы на воскресенье дорогие, и куда выгоднее лететь в пятницу. Встреча по поводу наших разработок по машинному зрению для дронов была на воскресенье, и когда наш переговорщик прилетел, заказчик извинился и сказал, что не получается, и нужно перенести ещё на пару дней. Так у него получились незапланированные выходные. Ну а дальше он закономерно вышел на пляж и уснул. После чего всем говорил, что сгорел на работе. Но интересно не это: дело в том, что ещё один наш коллега как раз застрял посреди тундры. Это примерно два часа вертолётом от Нового Уренгоя, и, кроме вертолёта, там транспорта нет. У него была метель — и, как следствие, нелётная погода. Он прибыл, обследовал талевые тросы и не смог вылететь. К началу истории уже сидел там два дня. Синоптики обещали открыть площадку только ещё через три дня. Из развлечений у него там была еда в столовой на месторождении, настольный теннис с вахтовиками и SMS на телефоне. Вот они друг другу и жаловались, кто и где застрял. Читать полностью »

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

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

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

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

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

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

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

Как не дать идее погибнуть и собрать команду, которая ее не убьет - 1

Когда наше digital-агентство только открылось, возник вопрос: как все начать и не запороть. Мы хотели создать что-то большое. Что-то, вокруг чего объединились бы единомышленники. Здесь мы расскажем, как не дать идее умереть и как собрать команду, которая ее не убьет.

В самом начале мы определили для себя правило: делать все самим, найти тех, кто делает лучше, и не говорить им, что делать. Правило работает.

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

Мы уже поднимали тему коммуникации как важнейшего навыка управленца любого уровня. Эффективность коммуникаций в компании напрямую влияет на её развитие, поэтому сегодня подробно обсудим два понятия: развитие и рефлексию.

Поговорим, что такое развитие в команде, что такое развитие человека и что такое развитие управленца. Рассмотрим траектории роста разработчика от исполнителя до тимлида. Обсудим, с чем придется столкнуться, что понадобится преодолеть и кем можно стать. Выясним, какие инструменты помогут и выделим пять областей развития тимлида.

Главным инструментом для развития я считаю рефлексию. Это понятие обычно ассоциируется с ретроспективами, обратной связью, performance-review. Но в основе рефлексии лежит глубинный психологический процесс, поэтому предлагаю начать с основ и рассмотреть рефлексию подробнее.
Читать полностью »

Даже в очень крупных компаниях часто отношение к разработчикам, как к грибам: держат в темноте и кормят навозом. Пишите код, родные, и не высовывайтесь. Этот подход может быть удобен для многих (в том числе иногда — для самих разработчиков в случае не очень адекватного менеджмента), но с точки зрения бизнеса неоптимален. Моя позиция: разработчики должны иметь возможность узнавать всё то, что происходит в компании и на рынке, но без давления. Захотел — копнул и разобрался, не захотел — не надо.

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

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

Привет! Я Валерий Лаптев, руководитель разработки LM в России. За два года мне нужно было поднять огромный отдел, и это был довольно интересный опыт.

Дело в том, что «Леруа Мерлен» есть во многих странах. Головная компания — во Франции, называется ADEO. Там пишут код под Францию, Италию, Испанию и Россию. Бизнес-модели у нас разные: если на российском рынке мы держим минимальные цены (ниже всех конкурентов в мониторинге), то в Европе всё иначе. На самом деле отличий море — начиная от особенностей локали и заканчивая другим законодательством. Есть особенности инфраструктуры России (те же очень большие задержки до Хабаровска) и другой жизненный цикл оформления заказа. Всё это порождает вот такой адский код, состоящий из огромных блоков IF:

Зачем нам в «Леруа Мерлен» нужен собственный российский отдел разработки на 200 человек - 1

Два года назад у нас было 60 магазинов и много-много хотелок по фичам. Накатывались они примерно за полгода и не всегда правильно. Последней каплей после кучи отклонённых по низкому приоритету фич была просьба завести в заказ поле-строку, чтобы мы его уже потом сами парсили. Это нужно было для особенностей доставки в России, поскольку страна больше других стран присутствия LM. Нам отказали и в этом, точнее, сказали, что будет где-то через семь-восемь месяцев.

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


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